EP1103140A4 - Point of sale activation and deactivation of pre-paid telephone calling cards - Google Patents
Point of sale activation and deactivation of pre-paid telephone calling cardsInfo
- Publication number
- EP1103140A4 EP1103140A4 EP99942644A EP99942644A EP1103140A4 EP 1103140 A4 EP1103140 A4 EP 1103140A4 EP 99942644 A EP99942644 A EP 99942644A EP 99942644 A EP99942644 A EP 99942644A EP 1103140 A4 EP1103140 A4 EP 1103140A4
- Authority
- EP
- European Patent Office
- Prior art keywords
- telephone calling
- card
- paid telephone
- transaction
- calling card
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Withdrawn
Links
Classifications
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04M—TELEPHONIC COMMUNICATION
- H04M17/00—Prepayment of wireline communication systems, wireless communication systems or telephone systems
- H04M17/20—Prepayment of wireline communication systems, wireless communication systems or telephone systems with provision for recharging the prepaid account or card, or for credit establishment
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
- G06Q20/00—Payment architectures, schemes or protocols
- G06Q20/22—Payment schemes or models
- G06Q20/28—Pre-payment schemes, e.g. "pay before"
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
- G06Q20/00—Payment architectures, schemes or protocols
- G06Q20/38—Payment protocols; Details thereof
- G06Q20/40—Authorisation, e.g. identification of payer or payee, verification of customer or shop credentials; Review and approval of payers, e.g. check credit lines or negative lists
- G06Q20/403—Solvency checks
- G06Q20/4037—Remote solvency checks
-
- G—PHYSICS
- G07—CHECKING-DEVICES
- G07G—REGISTERING THE RECEIPT OF CASH, VALUABLES, OR TOKENS
- G07G1/00—Cash registers
- G07G1/12—Cash registers electronically operated
- G07G1/14—Systems including one or more distant stations co-operating with a central processing unit
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04M—TELEPHONIC COMMUNICATION
- H04M17/00—Prepayment of wireline communication systems, wireless communication systems or telephone systems
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04Q—SELECTING
- H04Q3/00—Selecting arrangements
- H04Q3/0016—Arrangements providing connection between exchanges
- H04Q3/0029—Provisions for intelligent networking
Definitions
- the present invention relates to systems and methods that are used to activate and deactivate prepaid telephone calling cards.
- 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.).
- pre-paid telephone calling cards 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.
- additional services and features e.g., stock quote services, etc.
- pre-paid telephone calling cards are not without their problems.
- pre-paid telephone calling cards often are immediately active and usable once displayed for retail sale.
- pre-paid telephone calling cards reside on a store shelf they are susceptible to theft and fraudulent use by consumers and store employees.
- distributors of pre-paid telephone calling cards have incurred extra packaging costs for packaging an otherwise unusable plastic card.
- retailers often have to keep active cards under lock and key and distribute them as sales are made.
- 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.
- a method for processing a prepaid telephone calling card during a point-of-sale transaction 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.
- 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.
- a method for processing a prepaid telephone calling card during a point-of-sale transaction is provided.
- 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.
- 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
- 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.
- FIG. HIS is a continuation flowchart of the flowchart started in FIGS. HIA-R.
- 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.
- 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) .
- 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) .
- 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.
- PIN personal identification
- 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 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.).
- 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.
- 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 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.
- 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.
- 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.
- PSTN publicly switched telephone network
- POS devices e.g., cash register systems, credit card terminals (e.g.
- 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.
- SCF integrated service control functionality
- an SSCP 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.
- 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.
- POS devices e.g., cash register units, VERIFONE terminals, etc.
- 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
- 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.
- SDP 112 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.
- 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) ) .
- VRU voice response
- 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.
- IN 120 may also include other structures to perform other functions including, but not limited to, service management and application systems (SMASs) .
- SMASs service management and application systems
- IN 1N20 will support other functions such as call processing and management to enable end-user (consumer use) of cards.
- 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) .
- 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.
- 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
- a 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).
- a card may be placed in an ACTIVE STATE (ready for use) upon purchase, refresh (telephone calling unit addition) , etc..
- 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.).
- 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.
- FIG. 2B 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.
- 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.
- 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 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.
- 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.
- 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.
- 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,
- 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.
- 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.
- SNA Data Communication Protocol
- X.25 X.25
- TCP/IP Transmission Control Protocol
- SDP 112 Database Server
- 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.
- M MANDATORY DATA
- 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:
- 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.
- 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.
- 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.
- 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.
- activation- related messages e.g., PIN Activation Status Response, etc.
- SDP 112 card service provider
- 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.
- 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:
- 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.
- 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.
- 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.
- 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.
- a card service provider e.g., SDP 112
- 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
- FIGS. 7-18 illustrate message flows in a host- to-host communications arrangement
- 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) .
- 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.
- 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.
- 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) .
- 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.
- 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..
- 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.
- the SDP will log transaction details and generate a corresponding responsive message and submit/transmit the same to a requesting POSC system.
- 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.
- a failure on PIN activation will occur when the POS controller attempts to activate a suspended PIN, which was suspended because of fraud, etc..
- 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.
- 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.
- FIG. 11 depicted therein is a message- flow diagram for PIN charge.
- FIG. 12 depicted therein is a message-flow diagram for PIN charge failure conditions.
- 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
- FIG. 13 depicted therein is a message- flow diagram for PIN refresh.
- 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.
- FIG. 15 depicted therein is a message-flow diagram for PIN refund.
- 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.
- 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.
- FIG. 18 depicted therein is a message- flow diagram related to Echo Transaction
- error codes or notes will be contained in a reason code response area of the message.
- error conditions include database server unavailability, etc..
- 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.
- FIG. 19 depicted therein is a message- flow diagram for 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.
- FIG. 21 depicted therein is a message- flow diagram for PIN deactivation.
- 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.
- FIG. 23 depicted therein is a message- flow diagram for PIN charge transactions.
- 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
- FIG. 25 depicted therein is a message-flow, diagram for PIN refresh transactions.
- 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.
- 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.
- FIG. 29 depicted therein is a message- flow diagram for Echo Transactions.
- 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
- 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.
- 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.
- 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.
- 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.
- FIG. 31 depicted therein is a data-flow diagram related to successful authorization validation.
- FIG. 32 depicted therein is a data flow diagram for validation authorization failure.
- FIG. 33 depicted therein is a data flow diagram for POS featured in transactions.
- 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.
- a PIN and an access telephone number e.g., a 1-800 number
- 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.
- FIGS references to PTN in FIGS.
- FIG. 34 depicted therein is a data-flow diagram for batch transactions via DTMF communications .
- FIG. 35 depicted therein is a data-flow diagram for PIN activation of multiple PINs according to a preferred embodiment of the present invention.
- FIG. 36 depicted therein is a data-flow diagram for responding to a DTMF sequence for activation of a non- existing PIN.
- 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.
- 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.
- a customer e.g., retailer/reseller personnel
- 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.
- FIG. 40 depicted therein is a data-flow diagram that illustrates a DTMF sequence that attempts to activate an already active card.
- FIG. 41 depicted therein is a data-flow diagram that illustrates a DTMF sequence that attempts to activate an expired card.
- FIG. 42 depicted therein is a data-flow diagram that illustrates a DTMF sequence that attempts to activate a suspended card.
- 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.
- 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.
- 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.
- FIG. 46 depicted therein is a data-flow diagram that illustrates a DTMF sequence that attempts to activate non-existing PINS.
- FIG. 47 depicted therein is a data-flow diagram that illustrates a DTMF sequence that attempts to activate locked PINS.
- 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.
- FIG. 49 depicted therein is a data-flow diagram corresponding to a DTMF sequence that attempts to activate used PINS.
- FIG. 50 depicted therein, is a data-flow diagram that illustrates a corresponding
- FIG. 51 depicted therein is a data-flow diagram illustrating a DTMF sequence that attempts to activate an expired card/PIN.
- FIG. 52 depicted therein is a data-flow diagram illustrating a DTMF sequence that attempts to activate suspended cards .
- 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) .
- FIG. 54 depicted therein is a data-flow diagram illustrating a DTMF sequence for batch activation of batch PINS.
- FIG. 55 depicted therein is a data-flow diagram illustrating a caller's attempt to activate a non- existing batch of PINs/cards.
- FIG. 56 depicted therein is a data-flow diagram illustrating a caller's attempt to activate a locked batch of PINs.
- 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.
- FIG. 58 depicted therein is a data-flow diagram of a caller's attempt to activate an already active batch of PINs.
- 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.
- FIG. 60 depicted therein is a data-flow diagram illustrating a range batch activation transaction in accordance with a DTMF instruction for the same.
- 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).
- FIG. 62 depicted therein is a data-flow diagram illustrating a caller's attempt to activate non -existing batches.
- FIG. 63 depicted therein is a data-flow diagram illustrating a caller's attempt to activate locked batches in accordance with a DTMF sequence.
- 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.
- FIG. 65 depicted therein is a data-flow diagram illustrating a caller's attempt to activate already active batches.
- 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.
- FIG. 67 depicted therein is a data-flow diagram illustrating PIN deactivation for multiple PINs.
- FIG. 68 depicted therein is a data-flow diagram that illustrates a caller's attempt to deactivate a non- existing PIN.
- FIG. 69 depicted therein is a data-flow diagram that illustrates a caller's attempt to deactivate a locked PIN.
- 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.
- FIG. 71 depicted therein is a data-flow diagram that illustrates a caller's attempt to deactivate a used PIN.
- FIG. 72 depicted therein is a data-flow diagram illustrating a caller's attempt to deactivate a generated card.
- FIG. 73 depicted therein is a data-flow diagram illustrating a caller's attempt to deactivate an expired card/PIN.
- FIG. 74 depicted therein is a data-flow diagram that illustrates a caller's attempt to deactivate a suspended card.
- 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.
- FIG. 76 depicted therein is a data-flow diagram that illustrates a range PIN deactivation transaction.
- 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.
- FIG. 78 depicted therein is a data-flow diagram that illustrates a caller's attempt to deactivate non- existing PINS.
- FIG. 79 depicted therein is a data-flow diagram that illustrates a caller's attempt to deactivate locked PINs.
- 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.
- FIG. 81 depicted therein is a data-flow diagram that illustrates a caller's attempt to deactivate used PINs via DTMF entry.
- FIG. 82 depicted therein is a data-flow diagram that illustrates a caller's attempt to deactivate generated cards via DTMF entry.
- FIG. 83 depicted therein is a data-flow diagram that illustrates a caller's attempt to deactivate expired cards via DTMF entry.
- FIG. 84 depicted therein is a data-flow diagram that illustrates a caller's attempt to deactivate suspended cards via DTMF entry.
- 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.
- FIG. 86 depicted therein is a data-flow diagram that illustrates batch deactivation for multiple batches of PINs via DTMF communications.
- FIG. 87 depicted therein is a data-flow diagram that illustrates a caller's attempt to deactivate a non- existing batch of PINs/cards.
- FIG. 88 depicted therein is a data-flow diagram that illustrates a caller's attempt to deactivate a locked batch of PINs .
- 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) .
- FIG. 90 depicted therein is a data-flow diagram that illustrates a caller's attempt to deactivate an inactive batch of PINs .
- 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 .
- 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.
- FIG. 93 depicted therein is a data-flow diagram illustrating range batch deactivation via DTMF communications.
- 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.
- FIG. 95 depicted therein is a data-flow diagram that illustrates a user's attempt to deactivate non- existing batches.
- FIG. 96 depicted therein is a data-flow diagram that illustrates a caller's attempt to deactivate locked batches of PINs.
- 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.
- FIG. 98 depicted therein is a data-flow diagram that illustrates a caller's attempt to deactivate inactive batches.
- FIG. 99 depicted therein is a data-flow diagram that illustrates a caller's attempt to deactivate batches containing active PINs.
- 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.
- FIG. 101 depicted therein is a data-flow diagram that illustrates a PIN refund transaction via DTMF communications.
- 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.
- FIG. 103 depicted therein is a data-flow diagram that illustrates a situation in which caller attempts to refund on a locked PIN.
- 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.
- FIG. 105 depicted therein is a data-flow diagram that illustrates a caller's attempt to refund a generated card.
- FIG. 106 depicted therein is a data-flow diagram that illustrates a caller's attempt to refund an expired card.
- FIG. 107 depicted therein is a data-flow diagram that illustrates a caller's attempt to refund a suspended card.
- 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.
- 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.
- 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.).
- HIA-HIS 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.
- 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.
- processing and call flow start at SI and immediately proceed to S2.
- S2 At S2 and after a caller has called a 1-800 access to engage in
- 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.
- system routines will wait for user input.
- 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.
- HIB 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.
- S10 a voice prompt asking a caller to press a DTMF sequence for activating PTN batches, deactivating PTN batches or for refunding a PTN.
- 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.
- 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.
- processing proceeds at the top of FIG. Ill E.
- a voice response to the caller requesting the caller to enter the card tracking number to be activated i.e., the PIN.
- 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.
- the state change of the card will be set to active within an SDP.
- a voiced response to the caller directing the caller to press certain digits to go to certain menu options will be played.
- 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.
- 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.
- processing proceeds at the top of FIG. HIF.
- a voice response is played to the caller requesting the entry of the first card number of the cards to be activated.
- 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.
- a second voiced response requesting the caller to enter the last card number to be activated will be played.
- a familiar waiting for input routine will commence.
- a determination will be made whether the last number and entered is greater than the first number.
- 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.
- processing proceeds to 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.
- 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.
- 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.
- FIG. 1111 is directed to processes and corresponding call flows for activating a range of batches of cards.
- 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.
- 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,
- 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.
- steps S171, S172, S173, S174, S175, S176, S177, S178, S179, S180, S181, S182, S183, S184, S185, S186, and S187 are carried out to enable a caller to engage in batch range deactivation for multiple batches of PINs/cards.
- steps S188, S189, S190, S191, S192 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.
- 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.
- FIG. HIS further processes are carried out to enable refund transactions to be performed via DTMF communications.
- 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.
Landscapes
- Engineering & Computer Science (AREA)
- Business, Economics & Management (AREA)
- Computer Networks & Wireless Communication (AREA)
- Accounting & Taxation (AREA)
- Computer Security & Cryptography (AREA)
- General Physics & Mathematics (AREA)
- Physics & Mathematics (AREA)
- Strategic Management (AREA)
- General Business, Economics & Management (AREA)
- Theoretical Computer Science (AREA)
- Signal Processing (AREA)
- Finance (AREA)
- Meter Arrangements (AREA)
Abstract
Description
Claims
Applications Claiming Priority (3)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
US8981598A | 1998-06-03 | 1998-06-03 | |
US89815 | 1998-06-03 | ||
PCT/US1999/012182 WO1999063744A1 (en) | 1998-06-03 | 1999-06-02 | Point of sale activation and deactivation of pre-paid telephone calling cards |
Publications (2)
Publication Number | Publication Date |
---|---|
EP1103140A1 EP1103140A1 (en) | 2001-05-30 |
EP1103140A4 true EP1103140A4 (en) | 2003-02-26 |
Family
ID=22219715
Family Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
EP99942644A Withdrawn EP1103140A4 (en) | 1998-06-03 | 1999-06-02 | Point of sale activation and deactivation of pre-paid telephone calling cards |
Country Status (4)
Country | Link |
---|---|
EP (1) | EP1103140A4 (en) |
JP (1) | JP2002517957A (en) |
CA (1) | CA2334405A1 (en) |
WO (1) | WO1999063744A1 (en) |
Families Citing this family (7)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
EP1096772A3 (en) * | 1999-08-21 | 2004-01-07 | Lucent Technologies Inc. | Pre-paid telephone calling card service implemented via switch-based intelligent network |
AU2001222368A1 (en) * | 2000-11-17 | 2002-05-27 | Maikona Corporation N.V. | Method and system for revaluing prepaid telephone accounts |
US7243076B1 (en) * | 2000-11-24 | 2007-07-10 | Cardenas Frank A | Computer network system for shopping and method therefor |
JP4859882B2 (en) * | 2008-06-30 | 2012-01-25 | 靖 佐藤 | Content distribution system and content distribution method |
US11301799B1 (en) * | 2014-10-09 | 2022-04-12 | Aeris Communications, Inc. | Tracking physical delivery of products through a fulfillment system |
US20170140358A1 (en) | 2015-11-18 | 2017-05-18 | Andrew Orrock | Network Bridge for Local Transaction Authorization |
US11847634B2 (en) * | 2020-01-30 | 2023-12-19 | Jacob James Nicks | Systems and methods for conditionally gifting funds |
Citations (3)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US5577109A (en) * | 1994-06-06 | 1996-11-19 | Call Processing, Inc. | Pre-paid card system and method |
WO1996041462A1 (en) * | 1995-06-07 | 1996-12-19 | Electronic Data Systems Corporation | System and method for dispensing of a receipt reflecting prepaid phone services |
WO1998047112A1 (en) * | 1997-04-15 | 1998-10-22 | Stratex/Paradigm (Uk) Limited | Method for electronically vending, distributing, and recharging of pre-paid value, a vending machine and an electronic system for use therein |
Family Cites Families (3)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US5903633A (en) * | 1995-03-27 | 1999-05-11 | Smarttalk Teleservices, Inc. | Method and apparatus for prepaid phone card activation and billing |
NL1001659C2 (en) * | 1995-11-15 | 1997-05-21 | Nederland Ptt | Method for writing down an electronic payment method. |
US5777305A (en) * | 1996-01-24 | 1998-07-07 | Incomm | Package assembly and method for activating prepaid debit cards |
-
1999
- 1999-06-02 CA CA002334405A patent/CA2334405A1/en not_active Abandoned
- 1999-06-02 JP JP2000552838A patent/JP2002517957A/en not_active Withdrawn
- 1999-06-02 WO PCT/US1999/012182 patent/WO1999063744A1/en not_active Application Discontinuation
- 1999-06-02 EP EP99942644A patent/EP1103140A4/en not_active Withdrawn
Patent Citations (3)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US5577109A (en) * | 1994-06-06 | 1996-11-19 | Call Processing, Inc. | Pre-paid card system and method |
WO1996041462A1 (en) * | 1995-06-07 | 1996-12-19 | Electronic Data Systems Corporation | System and method for dispensing of a receipt reflecting prepaid phone services |
WO1998047112A1 (en) * | 1997-04-15 | 1998-10-22 | Stratex/Paradigm (Uk) Limited | Method for electronically vending, distributing, and recharging of pre-paid value, a vending machine and an electronic system for use therein |
Non-Patent Citations (1)
Title |
---|
See also references of WO9963744A1 * |
Also Published As
Publication number | Publication date |
---|---|
EP1103140A1 (en) | 2001-05-30 |
WO1999063744A1 (en) | 1999-12-09 |
CA2334405A1 (en) | 1999-12-09 |
JP2002517957A (en) | 2002-06-18 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
US10915887B2 (en) | System and method for electronic prepaid account replenishment | |
CA2222749C (en) | Methods and apparatus for providing a prepaid, remote entry customer account | |
EP1442404B1 (en) | System and method for supplying communication service | |
US7292998B2 (en) | System and method for adding value to a stored-value account | |
US6056194A (en) | System and method for networking and controlling vending machines | |
CA2618235C (en) | Value insertion using bill pay card preassociated with biller | |
AU2003218178B2 (en) | A system and method for purchasing goods and services through data network access points over a point of sale network | |
US20030119554A1 (en) | Method and arrangement for performing a cashless payment transaction | |
US20090228364A1 (en) | Intelligent transaction router and process for handling multi-product point of sale transactions | |
US20020152177A1 (en) | Method and arrangement for electronically transferring an amount of money from a credit account memory | |
US20080257953A1 (en) | System and method for the transferring an electronic sum of money from a credit memory | |
US20030154165A1 (en) | Method and arrangement for the transmission of an electronic sum of money from a credit reserve | |
EA003766B1 (en) | Dynamic currency conversion for card payment system | |
US20020156746A1 (en) | Method and arrangement for the transmission of an electronic sum of money from a credit reserve | |
US20070094129A1 (en) | System and method for adding value to a stored-value account using provider specific pin | |
JP2007179539A (en) | Inserting value into customer account at point of sale using a customer account identifier | |
KR20030038350A (en) | Method for circulating an electronic gift certificate in online and offline system | |
EP1096449A2 (en) | Tokenless vending system | |
WO1999063744A1 (en) | Point of sale activation and deactivation of pre-paid telephone calling cards | |
MXPA00012002A (en) | Point of sale activation and deactivation of pre-paid telephone calling cards | |
WO2002019186A2 (en) | Method of doing business |
Legal Events
Date | Code | Title | Description |
---|---|---|---|
PUAI | Public reference made under article 153(3) epc to a published international application that has entered the european phase |
Free format text: ORIGINAL CODE: 0009012 |
|
17P | Request for examination filed |
Effective date: 20001215 |
|
AK | Designated contracting states |
Kind code of ref document: A1 Designated state(s): BE CH CY DE FR GB IE IT LI NL SE |
|
A4 | Supplementary search report drawn up and despatched |
Effective date: 20030114 |
|
RIC1 | Information provided on ipc code assigned before grant |
Ipc: 7G 07F 7/02 B Ipc: 7G 07F 7/08 B Ipc: 7G 07F 19/00 B Ipc: 7H 04Q 3/00 B Ipc: 7H 04M 15/00 B Ipc: 7H 04M 17/00 A |
|
STAA | Information on the status of an ep patent application or granted ep patent |
Free format text: STATUS: THE APPLICATION IS DEEMED TO BE WITHDRAWN |
|
18D | Application deemed to be withdrawn |
Effective date: 20030327 |
|
REG | Reference to a national code |
Ref country code: HK Ref legal event code: WD Ref document number: 1037825 Country of ref document: HK |