CA2310151A1 - Internet-based zero intrinsic value smart card with value data accessed in real time from remote database - Google Patents

Internet-based zero intrinsic value smart card with value data accessed in real time from remote database Download PDF

Info

Publication number
CA2310151A1
CA2310151A1 CA 2310151 CA2310151A CA2310151A1 CA 2310151 A1 CA2310151 A1 CA 2310151A1 CA 2310151 CA2310151 CA 2310151 CA 2310151 A CA2310151 A CA 2310151A CA 2310151 A1 CA2310151 A1 CA 2310151A1
Authority
CA
Canada
Prior art keywords
customer
card
vendor
data
merchant
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.)
Abandoned
Application number
CA 2310151
Other languages
French (fr)
Inventor
Yada Schneider
Ian Mcdonald
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Individual
Original Assignee
Individual
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Individual filed Critical Individual
Publication of CA2310151A1 publication Critical patent/CA2310151A1/en
Abandoned legal-status Critical Current

Links

Abstract

A card-based system electronically transfers funds in real time. A customer card stores digital data representing a unique customer account number associated with a unique, remotely located customer account having at least one vendor-associated subaccount. A merchant terminal having a merchant IP address designating a unique merchant is affiliated with at least one unique vendor for transmitting to a system control center customer transaction data including the merchant IP address, the customer account number read from the customer card and account adjustment data designating either the value of a credit to be added to the vendor-associated subaccount reflecting a customer pre-payment or the value to be subtracted from the vendor-associated customer subaccount reflecting a customer purchase.
The system control center maintains a vendor account database and a customer account database. The customer account database associates each customer account number with the unique customer account number, stores the subaccount credit balance corresponding to the specified vendor, receives the customer transaction data transmitted by the merchant terminal, adjusts the customer subaccount value up or down in response to the customer transaction data, transmits to the merchant terminal customer account status information and adjusts the vendor account database to reflect credits resulting from vendor-associated customer transactions.

Description

1 INTERNET-BASED ZERO INTRINSIC VALUE SMART CARD 4~lITH VALUE DATA
5~~BACKGROUND OF THE INVENTION
7 1. Field of the Invention 9 This invention relates to Internet-based zero intrinsic value smart card with value data accessed in real time from 11 remote database. This application claims the benefit of prior 12 filed co-pending U.S. Provisional Application Serial No.
13 60/137,784, filed June 2, 1999, entitled "INTERNET-BASED ZERO

FROM REMOTE DATABASE" by Ian McDonald and Yada Schneider and is 16 a Continuation-in-Part of a United States Patent application 17 filed on 4/17/00 and entitled "REAL TIME INTERNET-BASED TRANSIT
18 MANAGEMENT AND CONTROL SYSTEM WITH WIRELESS VEHICULAR DATA LINK."

DESCRIPTION OF THE DRAWINGS

22 The invention is pointed out with particularity in the 23 appended claims. However, other objects and advantages together 24 with the operation of the invention may be better understood by reference to the following detailed description taken in 26 connection with the following illustrations, wherein:

1 FIG. 1 represents a block diagram illustrating the 2 interconnections between system control center and specified 3 vehicle data communications elements.

FIG. 2 represents a block diagram illustrating card user 6 account database access by the system control center.
8 FIG. 3 represents a block diagram illustrating the client 9 system access/control management and control signals/data flow tc and from the individual vehicles.

12 FIG. 4 represents a block diagram illustrating account 13 access and credit card adjustment by a transit card user.

FIG. 5 represents a summary chart illustrating 16 representative data transferred from the mobile system elements 17 to the system control center.

19 FIG. 6 represents a summary chart illustrating representative data transferred from the system control center to 21 the mobile system elements.

23 FIG. 7 represents a summary chart illustrating 24 representative client management data capable of being generated by the system control center.

1 FIG. 8 represents a more detailed block diagram of one 2 embodiment of the transit management control system of the 3 present invention.

FIG. 9 represents an expanded block diagram of the Tranz:Act 6 Server illustrated in FIG. 8.

8 FIG. l0A illustrates the configuration of ISO format data as 9 stored on commercial credit cards and transit system cards.
11 FIG. 10B illustrates the data format specifically configured 12 for processing by the Tranz:Act Server of the present invention.

14 FIG. 11 illustrates the operation of the Dispatch element of the Tranz:Act Server illustrated in FIG. 8.

17 FIG. 12 represents a generalized block diagram of another 18 embodiment of the invention illustrating certain specific items 19 of system hardware.
21 FIG. 13 represents a block diagram representation of various 22 software features of the invention.

24 FIG. 14 represents a software related flow chart according to the present invention.

1 FIG. 15 represents a diagram relating to the software call 2 to automation server blocking method.

4 FIG. 16 represents a diagram relating to the software call to automation server non-blocking method.

7 FIG. 17 represents a block diagram illustrating a 8 modification of the system according to the present invention.

FIG. 18 represents a diagram represents a diagram 11 illustrating a representative customer subaccount balance 12 distribution.

14FIG. 19 illustratesa system configuration diagram 15explaining of value o a defined customer's the addition t 16subaccount.

18FIG. 20 represents a diagram illustrating how a card number 19in combinatio n with the IP addressof a merchant card reader 20designates specific stomer ount and vendor subaccount.
a cu acc 22FIG. 21 represents a diagram illustrating how a customer's 23subaccount debited the time of purchase.
is at 25 FIG. 22 represents a diagram illustrating the configuration 26 of a vendor authorized merchant network.

1 FIG. 23 represents a system diagram illustrating how value 2 is added to a customer subaccount by credit card.

4 FIG. 24 illustrates the configuration of a system-wide card seller interface.

7 FIG. 25 illustrates multiple merchant categories for a 8 single city vendor.

FIG. 26 illustrates multiple merchant categories for 11 multiple city vendors.

13 FIG. 27 illustrates a multiple merchants/multiple vendor 14 configuration.
16 FIG. 28 illustrates a merchant to vendor fund transfer via a 17 banking agent.

19 FIG. 29 illustrates a multiple merchant/multiple vendor system configuration.

22 FIG. 30 illustrates a wireless merchant system interface.

24 FIG. 31 illustrates system customer to vendor money flow paths.

27 FIG. 32 illustrates card-related system functions and 28 advantages.

lIIDESCRIPTION OF THE PREFERRED EMBODIMENT

3II1. The Transit Management And Control Application In order to better illustrate the advantages of the 6 invention and its contributions to the art, a preferred 7 embodiment of the invention will now be described in some detail.

9 FIG. 1 represents a block diagram indicating how the system control center located at a single central office interfaces with 11 a variety of mobile system elements located in geographically 12 distributed cities or other locations.

14 Each bus within a system includes a commercially available wireless Mobile Data Console (MDC) such as a Mentor Mobile Data 16 Computer by Mentor Engineering of Calgary AB, Canada which 17 provides a wireless radio frequency (RF) link between the mobile 18 system element or bus and existing CDPD data link networks 19 installed and operating in most localities which provide cellular voice telecommunication systems. Each MDC includes an internal 21 card reader for reading conventional magnetically encoded cards 22 such as commercial credit cards. An outboard card reader is 23 attached to the MDC or to the bus fare box to facilitate customer 24 usage. The outboard MDC card reader may also be configured to optically scan cards having bar code encoded data or to function 26 in combination with wireless radio activated proximity cards.
27 The MDC can be configured to receive card swipe data from all 28 categories of card readers. Some states are planning to use 1 driver's licenses having bar code data identifying the licensed 2 driver and supplying additional data. System specific or 3 proprietary transit cards having magnetically encoded data 4 represents presently represents the most readily available, lowest cost form of card identification system. The system of 6 the present invention can also access system data by MDC readout 7 from conventional magnetic stripe credit cards.

9 FIG. l0A indicates the data storage format for data tracks 1 and 2 of a standard magstripe commercial credit card or other 11 card such as the transit card for use in connection with the 12 present invention. In response to a card swipe, the outboard 13 card reader reads the card data, decodes the card data and sends 14 the decoded card data to the MDC. The MDC internally reformats the data for use in connection with the system of the present 16 invention in accordance with the data format indicated in FIG.
17 lOB. As will be explained below, the MDC transmits the 18 reconfigured FIG. lOB data format string to the system control 19 center. Appendix A illustrates how the Mentor MDC software used in connection with the preferred embodiment of the invention is 21 specially configured for use in connection with the system of the 22 present invention.

24 The transit card element of the system includes stored digital data which identifies the person to whom the card 26 belongs. As will be explained below, additional data is stored 27 in a database located at the system control center and includes 28 substantial additional user-related data. When a fare paying 1 passenger elects to utilize a conventional VISA, MasterCard, 2 American Express or other commercial credit card, the system 3 control system data processing software will detect that fact anc 4 procure the necessary additional information directly from the credit card customer database by communicating with the credit 6 card provider's offsite database.

8 As illustrated in the FIG. 1 system block diagram, each 9 individual bus within a single mobile system maintains a radio frequency data link with a local CDPD data link network which is 11 interconnected with the local telephone network via an 12 appropriate interface. As an element of that telephone network 13 interface, the system control center will typically utilize at 14 least one and preferably at least two leased T-1 high speed data communication channels to provide both high speed data 16 communication capabilities as well as system fault tolerance.

18 When a transit passenger enters a particular bus, that 19 individual performs a conventional card swipe operation allowing the passenger's card data to be read by to the MDC mounted in the 21 bus.

23 As illustrated in the FIG. 2 block diagram which represents 24 a continuation of the FIG. 1 block diagram, transmission of card swipe data from the bus MDC to the system control center allows 26 the system control center to access and evaluate information 27 relating to the card user, whether the card being read represents _g_ 1 a proprietary or use specific transit card or a standard 2 commercial credit card.

4 The system control software evaluates the received card data and determines first whether the card number represents a 6 proprietary card number corresponding to information stored in 7 the onsite transit user database or another specified form of 8 card data where the necessary additional user data must be 9 procured from remote credit card customer databases.
11 The system utilizes the first four bytes of the incoming 12 card swipe data to identify the appropriate database to access.
13 The identified database is then accessed to determine whether the 14 card swipe data corresponds to an authorized user number stored in the database and whether that authorized user has a sufficient 16 amount of credit on account to pay the bus fare charges indicated 17 by the system for assessment against the user s credit balance.
18 When the card swipe data corresponds to an authorized user with a 19 sufficient credit balance, the system control center transmits control data back to the bus MDC over dedicated telephone lines 21 and CDPD data link network to communicate an ~~ACCEPTED~~ message 22 which is displayed both to the card holder and to the bus driver.

24 The system control center software also Gross checks the date and time data corresponding to the last use of the transit 26 card. If the last use falls within a designated time window, for 27 example, one hour since the last account charge, the system can 1 be programmed to presume that the second, close in time charge 2 corresponds to an authorized bus to bus transfer such that the 3 system will generate an "ACCEPTED" message without charging the 4 user's credit balance.
6 The search speed of the proprietary transit user database i~
7 enhanced by assigning sequential, non-overlapping card serial 8 number sequences to different geographically distributed cities 9 which will be simultaneously accessing the data stored in the system database.

12 As illustrated by the FIG. 1 block diagram, a single system 13 control center located at a single central office location can 14 process and control data from a virtually unlimited number of buses or other transit vehicles operating within the jurisdiction 16 of a single mobile system while simultaneously processing data 17 from and managing transit systems operating in a virtually 18 unlimited number of additional jurisdictions.

The FIG. 3 block diagram illustrates how clients of the 21 transit management system of the present invention can both 22 access and control their own transit systems through the single 23 centrally located system control center. The data interface 24 between each transit management organization and the system control center will typically be provided at low cost by the 26 Internet.
1 The FIG. 5 summary chart specifies and illustrates some of 2 the various different types of data which can be transferred fron 3 each vehicle within each mobile control system to the system 4 control center. In connection with each data transmission, the time of day and GPS (Global Positioning System) location will 6 always be communicated so that each data transmission will be 7 time tagged to allow for subsequent data processing and analysis.

9 When the driver reports for duty on a particular transit vehicle, the driver performs a card swipe operation with his own 11 driver transit card to identify himself to the system. After 12 proper authentication by the system control center, an authorized 13 driver is allowed to operate the vehicle. Via appropriate 14 electronic interface circuitry between the MDC and the vehicle engine and engine control systems, the system of the present 16 invention can take a variety of steps to prevent the driver from 17 starting the engine, to shut down the vehicle engine or to 18 prevent brake release. The identification of each vehicle is 19 continuously provided on a real time basis since the bus-mounted MDC represent a dedicated piece of hardware which identifies 21 itself with each burst of data transmitted.

23 In all applications, a GPS receiver will be provided for 24 each vehicle and interfaced with each MDC to allow the MDC to provide continuous real time position information to the system 26 control center. The data transmitted by the GPS receiver through 27 the MDC to the system control center will typically also include 1 vehicle speed data, direction of travel data and other 2 conventional commercially available forms of data to allow the 3 vehicle position to be mapped in real time both at the system 4 control center as well as at the transit client management location.

7 As a user boards the bus and performs the card swipe 8 operation on the MDC, a burst of packet data is transmitted to 9 the system control center to communicate at least the card user ID as well as the vehicle entry time and vehicle location. The 11 system control center then determines the appropriate fare to be 12 assessed against the transit user's credit account based on 13 predefined route and fare data as defined by the transit manager.

A key advantage of the present invention is that the fare 16 structure can be accessed and controlled by a transit system 17 management client on a real time basis to specify fare charges 18 based on the day of the week, the time of the day, holidays or 19 special promotions. For example, a transit client may wish to run a special promotion where females over the age of sixty could 21 ride either at no charge or for a reduced fare between twelve 22 P.M. and three P.M. on the first Wednesday of each month. Such 23 customized fare control parameters can be instantaneously 24 formulated at the transit client's Internet interconnected PC
terminal, transmitted to the system control center software and 26 take effect immediately. In the past, such fare change notices 27 were manually implemented into even the most state of the art 1 buses having card reader fare assessment systems on board each 2 bus. If the transit client desires, a specially customized 3 message may be displayed on the MDC LCD readout to note both the 4 "ACCEPTED" status of the user's transit card as well as the reason or code name corresponding to the special promotional 6 II fare .

8 A transit manager might also charge a special promotional oz 9 reduced fare for affiliated groups such as designated employers, schools, or other organizations which would benefit from reduced 11 rates either at all times or at specified times. These discounts 12 could be correlated with efforts to increase use of a client's 13 mass transit system, to reduce the need for school buses or to 14 subsidize selected categories of transit system customers such as the indigent or physically impaired.

17 As further summarized in FIG. 5, the real time collection of 18 fare data where a single collected fare corresponds to a single 19 boarding passenger allows transit managers to collect passenger count information and total fare collections in real time on a 21 bus to bus basis.

23 More sophisticated versions of the present system can offer 24 options to communicate vehicle system operating data such as readouts or graphs of bus speed, measured as a function of time 26 of day, cumulative daily vehicle mileage, vehicle fuel and oil 27 quantity, engine RPM and engine temperature, system failure 1 alerts such as over temperature or low oil pressure, a door 2 position warning indicating a door is open when the vehicle is it 3 motion, safety warning signals falling within a variety of 4 categories and total vehicle weight which would indirectly reflect passenger loading. By interconnecting a video camera to 6 the system MDC, a snapshot capture video signal may be 7 transmitted from the vehicle to the transit client to assist 8 management in verifying bus status, passenger load factor as well 9 as other information communicated most clearly by an image rather than by pure data.

12 The MDC may be configured to include a keyboard to allow the 13 driver to transmit customized messages to transit management as 14 well as a series of "hot keys" for transmitting predetermined, canned messages such as "driver on break" by requiring the driver 16 to push only a single hot key. Similarly, customized text 17 messages may be formulated by a transit manager, transmitted via 18 the Internet to the system control center and communicated to the 19 MDC of a specified bus on a real time basis. Such messages could be used to notify a driver that his bus was being taken out of 21 service at the next stop due to an engine system malfunction, 22 that the interval between his bus and the next proceeding bus had 23 been reduced to five minutes less than the scheduled time 24 interval or that the driver should contact his manager by telephone at the next stop.

1 As further noted on the FIG. 5 summary chart, a 2 comprehensive variety of end of day operating data can be 3 summarized by the on board MDC and transmitted via the system 4 control center to the local transit management operation. Such operating day data summary could include the total passenger 6 count for the day, an hourly breakdown of passenger count, the 7 on-duty/off-duty times for each drivers, the vehicle operating 8 time and mileage for the day, a listing of vehicle system 9 failures and warnings that predefined vehicle operating parameters have been exceeded, passenger demographics showing, 11 for example, how many passengers boarded at each stop and a real 12 time analysis of the vehicle loading and capacity status. Since 13 each bus within each mobile system can be configured to transmit 14 the same end of operating day data summary to the appropriate transit management facility, that facility can completely 16 evaluate the day's operations and fare collections on a real time 17 basis as well as vehicle maintenance requirements.

19 FIG. 6 summarizes the various classes of data which can be transferred from the system control center to individual vehicles 21 operating within a single mobile system. As discussed above, 22 fare control data can be formulated by the appropriate transit 23 manager and transmitted on a real time basis to the MDC in each 24 vehicle to adjust fares based on the time of day, day of week, holidays or special promotional discounts or other discounts.
26 Promotional fares can be further broken down by customer 27 identification, employer identification, vehicle location entry 1 point or by a promotional card sponsor such as customers of 2 McDonalds° or Burger King~ restaurants or Mobile~ or Chevron°
3 service stations. Special discounts can be provided to 4 individual customers based on volume purchasers or by the user's employment affiliation. Employers may also realize tax 6 incentives from participation in the Federal employee ridership 7 program.

9 The system can be configured to automatically reconfigure the bus head sign based upon its GPS position data such that whey.
11 a driver reaches a predetermined location, the head sign 12 indicating the bus destination can be automatically reconfigured 13 or reversed without driver input.

As further noted on the FIG. 6 summary chart, the system 16 control system may be programmed to compare the actual bus 17 position versus time with the scheduled bus position versus time 18 to provide the driver with a real time readout of minutes ahead 19 of schedule or minutes behind schedule to assist the driver in decreasing that unwanted time differential to zero. The system 21 may also provide the driver and the transmit manager with a 22 schedule compliance warning in the event the bus location versus 23 time falls outside a designated maximum allowable time window.
24 Similarly, an excessive vehicle speed warning can be communicated to the transit manager in real time as can an excessive vehicle 26 weight warning. Such data allows the transit manager to take 27 appropriate steps to decrease the passenger load of a 1 predetermined vehicle by providing a second bus to meet an 2 overloaded first bus at a specified meeting point. If a 3 particular bus deviates from a designated route as identified by 4 GPS data, the transit manager can be alerted immediately of a potential problem. If desired, the system can prepare 6 comparative information regarding the schedule compliance of one 7 bus relative to a preceding vehicle or to a following vehicle to 8 assist the bus drivers or the transit manager in ironing out 9 unwanted compression or expansion of bus position. The system will also indicate to management when drivers make unauthorized 11 pickups or drop offs.

13 When the system of the present invention is utilized for 14 shuttle vans such as airport rental car or hotel vans or for medical transport vehicles for transporting patients from one 16 medical facility to another, managers of such systems can 17 communicate specialized messages directing a shuttle driver to 18 change his route, to pick up a passenger or to provide a listing 19 of future pickups. The GPS/MDC system may be programmed by the transit manager to provide the vehicle driver with either 21 directions or with a map showing the location of a specified 22 pickup point and the best route to proceed from the vehicle's 23 present position to the selected pickup position. The system 24 will also indicate to management when a driver makes an unauthorized pick up or drop off.

1 FIG. 7 summarizes some but not all of the advantages of the 2 present system from the point of view of transit client 3 management. The system provides transit managers with both real 4 time vehicle location mapping as well as real time vehicle schedule compliance as a result of the real time comparisons 6 between vehicle location and scheduled vehicle location. Real 7 time fare collection data summarizes can be provided by vehicle, 8 by route or by geographic area to substantially facilitate 9 management. and operating efficiency enhancements. System capacity utilization can be analyzed based on time of day, day of 11 the week or time of year as can the load factor and load factor 12 changes on a route by route basis. Managers may also utilize the 13 real time data to compare current load factor data with 14 historical load factor data and predict changing trends or observe that trends are not changing. System software can be 16 configured to advise management of route overload warnings, 17 system overload warnings or vehicle overload warnings.

19 Based on the comprehensive real time data input from each bus within a single transit system, management will be able to 21 observe schedule compliance in real time, to define maximum 22 allowable schedule compliance time windows and to be 23 automatically advised by the system software when those preset 24 time windows have been exceeded.
26 By comparing real time vehicle passenger boarding statistics 27 with passenger boarding statistics for the same route for the 1 prior day, prior week, prior month or prior year, the system can 2 be programmed to alert management to an imminent vehicle, route 3 or system overload to provide management with an advance overloac 4 prediction and an opportunity to attempt to remedy the predicted overload.

7 By keeping track of the real time position of all vehicles 8 on a route, the interval between two buses following the same 9 route can be monitored and compared with appropriate schedule compliance data. The system can then either automatically or 11 enable management to manually transmit customized messages to the 12 drivers of the conflicting buses to request that they attempt to 13 either increase or decrease the vehicle to vehicle time interval.

Because the vehicle can be configured to transmit 16 maintenance-related data through the MDC to transit management, 17 approaching routine preventative maintenance, mileage points or 18 time intervals can be predicted days or weeks in advance to 19 facilitate vehicle maintenance and scheduling.
I
21 The system also allows transit management to issue driver 22 transit cards to allow the MDC to communicate driver information 23 to transit management. The system software can be programmed to 24 Gross-check the identification of a scheduled driver with the driver seeking to sign on at a particular vehicle. If the actual 26 driver data does not Gross-check with the scheduled driver data, 27 the vehicle ignition system can be disabled either prior to start 1 or prior to allowing the new driver to commence vehicle 2 operation.

4 The FIG. 4 diagram illustrates how the system provides for customer database access. As illustrated in that diagram, a 6 customer can access the system control center database using an 7 appropriate PIN number and the user's card number to perform any 8 one of the following functions:

1. Check credit balance;
11 2. Add credit by charging an additional amount to the 12 customer's commercial credit card;
13 3. Transfer credit on a first transit card to a 14 different transit card;
4. Deactivate or suspend the activation status of an 16 existing transit card; and 17 5. Cancel an existing transit card.

19 These customer control features demonstrate how the transit card dramatically differs from existing smart card products 21 which utilize a microprocessor chip to store data and value on 22 the card itself in that the transit card has no intrinsic value 23 whatsoever. If a customer loses his transit card, he simply 24 contacts the system control center via any of the techniques illustrated in the FIG. 4 diagram and either deactivates or 26 cancels the lost or stolen card. The card deactivation can be 27 accomplished immediately and if an unauthorized user attempts to 1 use the card even within a few seconds later, the bus MDC will be 2 advised by the system control center that the card has been 3 "DECLINED." Even if a particular transit card represents a 4 universal card usable on any transit system anywhere under the control of the system control center, the card will be 6 deactivated and rendered useless in all systems on a simultaneous 7 basis.

9 As further indicated in the FIG. 4 diagram, transit cards can either be sold or have the existing account credit balance 11 increased by authorized sales outlets having data terminals 12 configured to communicate with the database stored at the system 13 control center. Such data terminals can either be connected to 14 the system control center by standard telephone lines, by Internet, or by wireless CDPD modem.

17 Referring now to FIGS. 8, 9, 10 and 11, the hardware and 18 specific software contemplated for use in connection with the 19 preferred embodiment of the invention will now be described.
21 The overall system diagram illustrated in FIG. 8 coordinates 22 with and is consistent with the general system diagram 23 illustrated in FIGS. l, 2, 3 and 4. FIG. 12 generally 24 corresponds to the FIG. 8 block diagram and more specifically designates the manufacturer and model number of certain elements 26 of the invention utilized within the block diagram of FIG. 8 27 designated as the system control center. As illustrated in the 1 FIG. 8 block diagram, the heart of the system control center is 2 designated as the Tranz:Act Server. FIG. 9 illustrates the 3 XGate, Dispatch, Tranz:Act Engine and Tranz:Act card holder 4 database which are implemented by software applications within a conventional network server. FIG. 9 illustrates that the 6 incoming card swipe data is communicated from a particular bus tc 7 the XGate system element where the data is converted from its 8 encrypted form into a standardized data format identifying the 9 card number and the amount charged. The System may be configures to accept and transmit additional statistics or survey data as ar 11 element of the card swipe data. As explained above, the data 12 response transmitted by the Tranz:Act Server to the system MDC
13 communicates either an "ACCEPTED," status or a "DECLINED" status.
14 An "ACTIVATE" status represents a different form of information which is communicated to a sales outlet data terminal in response 16 to a card sale or credit enhancement transaction.

18 The FIG. 10 diagram indicates the format of a typical data 19 sequence which might be used to implement a system according to the present invention. Typically, either an ISO or AAMVA data 21 format will be used for standardization purposes.

23 The software based Dispatch element receives the converted 24 card swipe data from the XGate element and performs analysis of the first four bytes of the incoming MDC data. Those first four 26 bytes are used to identify the received data into one of the 27 following categories:

11. Card swipe data;

22. GPS position information;

33. Driver sign on;

44. Driver sign off;

55. Hot key messages;

66. Custom text messages;

77. End of day data summary.

9 The foregoing list is not all-inclusive, but is provided merely to illustrate the function of the Dispatch element of the 11 II Tranz : Act Server .

13 FIG. 11 illustrates a situation where the first four bytes 14 of MDC data correspond to card swipe data and demonstrates how the Dispatch element of the invention functions to parse the data 16 into an appropriate category. As will be explained below, the 17 particular card swipe data content may inform the Dispatch 18 element that the card swipe data is an American Express card, a 19 VISA card or some other commercial credit card. The Dispatch element responds to that commercial credit card identification by 21 sending the card swipe data to the remote credit card customer 22 database as illustrated in the FIG. 2 block diagram to identify 23 the card user and card credit status. As illustrated in FIG. 11, 24 a particular data content such as, for example, "3333" can be used to designate to the Dispatch element that the card swipe 26 data has designated a proprietary transit card where the relevant 27 data is found within the transit user database stored in the 28 Tranz:Act Server as illustrated in FIGS. 2 and 9.

1 In the preferred embodiment of the invention, the Tranz:Act 2 Server database search engine takes the form of Microsoft SQL
3 Server V6.5. Each incoming fare assessment transaction is 4 configured in software as a separate program referred to in the software art as a "thread." Each thread receives the incoming 6 card swipe data and performs a separate search process 7 independent of all ongoing or subsequently received search 8 processes. Each new incoming transaction starts a new thread.
9 The transit user database is configured within the Microsoft SQL
database into four separate columns designated Column 1, Column 11 2, Column 3 and Column 4. Each thread is configured to perform a 12 parallel search of each column simultaneously resulting in 13 nearly instantaneous search completion where the response of a 14 search of a one million record database can be achieved in less than one millisecond. The implementation of such a thread 16 database processing routine allows essentially an unlimited 17 number of transaction to be processed simultaneously by the 18 server on the transit user database with a less than one 19 millisecond response time for each inquiry.
21 When the transit card user number being searched for is 22 located, the credit status is evaluated and compared with the 23 amount to be charged. If the credit on account exceeds the 24 amount to be charged, the system software generates "ACCEPTED"
output which is immediately transmitted to the bus MDC. At the 26 same time, the database software reduces the customer's credit 27 balance by the amount of the fare charge. As part of this 28 database search, the time of the inquiry is recorded and the 1 software compares the time of the current search with the time of 2 the last data transaction relating to that same record. If the 3 time differential between those two record access times is less 4 than a predetermined time window such as one hour, the system will assume that the user is implementing a bus to bus transfer 6 which is typically processed as a no-charge transaction. In such 7 cases, the card user's credit balance is not reduced.

In response to an MDC card swipe, the system of the present invention can accomplish all data transmission and database 11 search activity and retransmit a response to the bus MDC in a 12 period typically no longer than about one second. When the card 13 swipe data corresponds to a non-proprietary commercial credit 14 card and the system is required to access a remote credit card customer database, the processing time will be increased from one 16 second or less to a time on the order of about two to four 17 seconds. From the standpoint of the bus operator and passenger, 18 the response to a card swipe is essentially instantaneous.

The FIG. 13, 14, 15 and 16 diagrams further describe and 21 illustrate the preferred embodiment of the software used to 22 implement the preferred embodiment of the invention.
23 Approximately two gigabytes of the server hard drive is allocated 24 in the prototype system for use by the Microsoft SQL server software and its database.

2~ The basic embodiment of the present invention actually 28 tested to date provides only two tables within the SQL software:
1 the CardHolderInfo and CardInfo tables. The CardHolderInfo table 2 contains information about the card holder such as: card holder 3 name, address, phone number, etc... The CardHolderInfo table is 4 keyed to an unique integer value for each record in the table.
This table has a relationship to key in the CardInfo table. This 6 table is used to obtain information about the card holder. The 7 CardInfo table contains the card number, the available balance 8 and key to the CardHolderInfo table. The card number is stored 9 as four sequences of integers which accommodates standard sixteer.
character card numbers as well as any other type of card number.
11 The four integer sequences are stored as clustered key values to 12 increase the search speed. The database is tuned to allow the 13 MaxNumber of worker threads to be matched to available RAM on the 14 server. Available connections is presently set at 302.
I
16 The Tranz:Act Engine currently uses Microsoft Visual C++
17 Version 5.0 and is referred to as a Microsoft Foundation Class 18 based Dialog application. The software supports only one main 19 window with a limited user interface.
21 As the Tranz:Act Engine is started, an IP connection is 22 established with the Hypercom NAC/IEN box. Also, database 23 connections to the Tranz:Act Server Database are allocated.
24 Three hundred connections have been allocated for the prototype system. The Tranz:Act Engine maintains a TCP/IP connection to 26 the Hypercom NAC/IEN box. The TCP/IP session is maintain using 27 the MFC (Microsoft Foundation Class) CAsycronousSocket Class. As 1 data is received over the IP Connection, the data is parsed.
2 After the parsing is complete, a new thread is started.

4 For each new thread that is started, a connection to the database is passed to thread. Each thread takes the parsed data 6 and performs a database select. The select is based on the Card 7 Number sequences. For example, SELECT balance FROM
8 CardHolderInfo WHERE CardNum Seql=1111 AND CardNum-Seq2=2222 AND
9 CardNum-Seq3=3333 AND CardNum Seq4=4444. This select statement is very fast using the low level ODBC Direct calls instead of any 11 other types of API's such as MFC ODBC, ADO or DAO. Once the 12 Balance has been retrieved, a simple check is done on the 13 transaction and the acceptance or decline status is sent over a 14 new separate IP connection. The database table is then updated.
I
16 Although each new thread is instantiated on the STACK, the 17 data that is parsed and passed to threads is allocated on the 18 HEAP which increases the speed of the systems. All required 19 elements for the database connections are acquired at startup time. This includes the HANDLE to the statement (HSTMT) and the 21 database connection which makes database access very rapid.

23 As illustrated in the FIG. 13 - FIG. 16 diagrams, the system 24 utilizes a variety of sockets. The Dispatch Client OCX or .exe Message Send Socket is configured as follows: This socket will 26 open a connection to the Dispatch Server Client Receive Socket.
27 The data sent by this socket will be provided via a public 1 interface from the OCX or .exe. The public interface will be 2 exposed to a client application. Once the data has been 3 provided, it will be sent to the Dispatcher Client Receive Socket 4 and the socket connection will be closed by the MDC Client OCX of .exe Send Socket. Before the data is sent over this socket 6 connection it will be formatted via the OCX or .exe to the 7 acceptable XGate software excluding the job number which will be 8 furnished by the Dispatch server application.

The MDC Client OCX or .exe Messages Receive Socket is 11 configured as follows: This socket will be opened and listening 12 at all times. It will receive data from the Dispatch Server 13 Client Send Socket. The Dispatch Server Client Socket will close 14 the connection once the data has been sent. The data will be the raw data received from the XGate application. This data will be 16 parsed by the MDC Client OCX or .exe and made available via a 17 public interface method/event.

19 The Dispatch Server XGate Socket is configured as follows:
This socket will be connected to the XGate application at all 21 times the Dispatch Server application is running. This socket 22 will be used for both receiving and sending messages to the XGate 23 application. The only parsing of the data received will be for 24 the Unit Number. The Unit Number received from XGate will be mapped to an IP address corresponding to a Dispatch Client OCX or 26 .exe. Once the Unit Number has been parsed, the Dispatch Server 27 will instantiate a new thread. The thread will create a separate 28 Client Send Socket.

1 The Dispatch Client Send Socket is configured as follows: A
2 new Dispatcher Client Send Socket will be created for each 3 message received from the XGate application. This socket will 4 send the raw message to the appropriate Dispatch Client OCX or .exe Receive Socket. Once the data has been sent, this socket 6 will close the connection.

8 The Dispatch Client Receive Socket is configured as follows:
9 This socket will listen to accept connections at all times the Dispatch Server application is running. It will receive data 11 correctly formatted to pass off to XGate application. Once a 12 complete message has been received from a Dispatch Client Send 13 Socket, it will be sent to the XGate application via the Dispatch 14 Server XGate Socket.
16 In connection with an authorized vendor's sale of a transit 17 card as outlined in the FIG. 4 block diagram, the Tranz:Act 18 Engine will receive card swipe data from the merchant. As 19 illustrated in FIG. 9, the Tranz:Act Engine will identify the IP
address of the card swipe terminal as a "merchant" terminal as 21 distinguished from a vehicle-mounted MDC. The system will then 22 process the transaction as a transit card purchase by activating 23 the account number of the pre-encoded number on the transit card 24 being sold. The initial card credit balance is keyed in by the merchant along with a PIN number and custom defined information 26 as required by the merchant or by the transit authority.
1 The merchant terminal utilizes a card reader which decodes 2 the card swipe data stored in the FIG. l0A ISO data format and 3 directly transmits that ISO format data either by land line or b~
4 wireless CDPD modem to the NAC/IEN box depicted in the FIG. 12 system diagram. When the Tranz:Act Engine receives such FIG. lOF
6 ISO format data, the system is configured to bypass the XGate anc 7 Dispatch elements and directly process the ISO format data.

9 The foregoing explanation clearly demonstrates the nearly instantaneous real time operation of the present invention which 11 allows a mobile transit vehicle to receive passengers using 12 transit cards which essentially instantaneously communicates the 13 "ACCEPT" or "DECLINED" status of the transit card via the bus 14 MDC. Through appropriate security measures, the holder of a transit card can conveniently access his account maintained on 16 the system control center database to determine its current 17 credit balance, to add credit or to deactivate the card. Transit 18 management is provided on a real time basis with comprehensive 19 data and analysis regarding every one of its vehicles within its system by accessing and receiving data from a single centrally 21 located Internet-connected system control center. All data and 22 data analysis is accomplished by software on a real time basis 23 rather than by wage earning employees and the system is 24 maintained operational at relatively low cost on a twenty-four hour by seven day basis. The transit system pays a fee for use 26 of the present system on a per-transaction basis or, 27 alternatively, on the basis of a pre-negotiated fixed fee per 28 month, per quarter or per year. Both an unlimited number of 1 buses as well as an unlimited number of transit systems can be 2 operated and managed by means of a single system control center.

4 Using the same system elements and software, the system of the present invention can be readily adapted to other analogous 6 uses. For example, the system can be adapted to function as a 7 wireless airliner arrival and departure tracking system by 8 providing a an MDC at airline terminal gates and providing the 9 flight crew with the airline counterpart of a transit card to allow the system to identify the airline company and the flight 11 number corresponding to a particular aircraft and crew. The 12 wireless MDC transmits the card data supplemented by time of day 13 and gate location data to advise airline management in real time 14 via the Internet of the exact flight arrival and departure information for all aircraft within its entire potentially global 16 route system.

18 The system of the present invention may also be readily 19 adapted for use with crew shuttles, delivery trucks, tour coaches and rental cars and trucks. For the rental vehicle application, 21 a renter may use either a prepaid or a post pay card to check out 22 and check in rental vehicles. The vehicle-based MDC allows the 23 system to automatically monitor vehicle location, mileage driven, 24 and other data in real time. The rental vehicle check-in process may be fully automated by having the customer swipe his card 26 through the vehicle MDC. The software can readily be configured 27 to advise management when a rented vehicle is approaching the 28 pre-designated vehicle turn-in location or where a rented vehicle 1 is located at the scheduled turn in time to provide advance 2 notice that a rented vehicle will either be turned in early, on 3 time or late. Rental vehicle utilization rates may be 4 substantially increased as a result of such real time vehicle location data.

7 The system of the present invention can not only be used in 8 connection with transit systems, but may also be readily adapted 9 to a wide variety of smaller, less complex transit providers including airport rental car shuttle services, airport hotel 11 shuttle services and medical transport vehicles. The FIG. 17 12 block diagram illustrates yet another modification or variation 13 of the inventive system where transit client management can 14 utilize a mobile CDPD miniature or laptop computer to access the system control center rather than relying upon a hardwired 16 connection to the Internet. Satellite based RF data link systems 17 such as the proposed Teledesic system can also be used to link 18 the mobile system elements to the system control center.
19 Although the present invention has been described in connection with the use of prepaid transit cards, the system can readily 21 accommodate post pay cards and incorporate a conventional 22 periodic customer billing system based on actual card usage.
23 Numerous additional variations and modifications of the system of 24 the present invention would be readily apparent to one of ordinary skill in the art.
lll2. The REMOTE SMARTCARD~

3 Figures 1-17 illustrate the initial embodiment of the 4 invention as applied to the real time, Internet-based transit management and control system using a wireless vehicular data 6 link. The second, subsequently developed, broader embodiment of 7 the invention encompasses an Internet-based zero intrinsic value 8 smart card where the value data associated with the card is not 9 carried on the card, but is instead accessed in real time from a remote database. This broader embodiment of the applicant's 11 invention is identified by the trademark REMOTE SMARTCARDT~~ and 12 will be periodically referred to by that shorthand trademark 13 reference.

As illustrated in the FIG. 18 diagram, the REMOTE
16 SMARTCARDT"~ embodiment of the invention can include account 17 balance data corresponding to credit balances capable of being 18 applied to either services or products purchased from as few as 19 one vendor to as many as an essentially infinite number of vendors. Each of these discrete account credit balances 21 represents a customer "subaccount" or "purse" which allows a 22 particular customer to use his specifically issued REMOTE
23 SMARTCARDT"~ for the purpose of paying for services or merchandise 24 supplied by a wide variety of vendors. In the FIG. 18 chart, a wide variety of vendors have been identified to assist in 26 explaining the configuration of the REMOTE SMARTCARDT"~ invention 27 and its use as viewed from the standpoint of the customer/card 28 holder, the vendors and transaction processing "merchants." The 1 FIG. 19 diagram illustrates how a customer/cardholder can add 2 value to a designated subaccount.

4 As illustrated in FIGS. 18 and 19, Vendor-1, abbreviated "V-1," might correspond to a city transit provider such as Phoenix 6 Transit of Phoenix, Arizona. An existing holder of city transit 7 REMOTE SMARTCARDT"~ visits an authorized V-1 "merchant" which 8 might take the form of a special purpose kiosk for both issuing 9 transit-related REMOTE SMARTCARDT"~ products or for adding value to such REMOTE SMARTCARDST"~. The FIG. 19 diagram assumes that the 11 customer already possesses a REMOTE SMARTCARDT"' and wishes to add 12 value to the V-1 account for the purpose of receiving additional 13 services from the city transit organization. The customer either 14 pays the V-1 merchant the amount to be credited in cash, or by check or credit card. The merchant swipes the customer's REMOTE
16 SMARTCARDT"~ through a conventional card reader which includes a 17 keypad adaptable to indicating the amount of credit to be added 18 to the customer's REMOTE SMARTCARDT~~ V-1 account. If the 19 customer wishes to charge this transaction to his credit card, FIG. 19 illustrates that, as explained in detail above in 21 connection with FIG. 2, a remote credit card database is accessed 22 via what has been labeled in FIG. 19 as the "credit card data 23 link," a data transfer operation requiring approximately an 24 additional four second processing time. When the system control center receives confirmation from the remote credit card database 26 that the requested amount of credit is available on the 27 customer's conventional credit card (e.g., VISA, MasterCard), the 28 system control center internally credits the specified value to 1 the customer's V-1 subaccount and transmits an appropriate signa:
2 over the merchant data link to the V-1 merchant indicating that 3 the requested amount of credit has been added to the customer's 4 V-1 subaccount. When a cash or a cash equivalent transaction (e.g., personal check) is implemented between the customer and V-6 1 merchant, the system control center processing time is reduced 7 to a time interval of less than one second since use of the 8 credit card data link is not involved in the transaction. At the 9 conclusion of this customer/merchant transaction, the system control center customer account database is updated and that 11 updated account information can be accessed directly by the 12 vendor via the vendor data link.

14 As illustrated in FIG. 19, the subsequent transfer of the cash or cash equivalent customer payments by the customer to the 16 V-1 merchant takes place between the V-1 merchant and Vendor-1.
17 Where the V-1 merchant is owned outright by Vendor-1, this 18 customer funds transfer can be accomplished internally. If the 19 V-1 merchant is an independent contractor, the merchant may be allowed to maintain the control of the customer funds received 21 for an agreed period of time. The funds may by agreement be 22 transferred between the V-1 merchant and Vendor-1 on a daily or 23 weekly basis or on another mutually agreed basis.

Because the system control center maintains continuously 26 updated customer account balance data and tracks the funds 27 received by all merchants, Vendor-1 may issue periodic billings 28 to all authorized V-1 merchants based on the funds received 1 information generated by the system control center. For customer 2 funds received via credit card charges, Vendor-1 can make 3 arrangements to receive credit card derived payments either from 4 the V-1 merchants or directly from the credit card providers.
6 The FIG. 20 diagram illustrates that as a direct result of 7 the card swipe operation performed by an authorized merchant, the 8 system control center receives data specifying the customer's 9 card or account number as well as the merchant IP which indirectly specifies the identity of the vendor affiliated with 11 that merchant. The card number/merchant IP address data 12 specifies a single customer account and a single vendor 13 subaccount within the system's overall customer account database 14 to either add or subtract a specified transaction amount value.
16 The FIG. 21 diagram illustrates how a particular customer's 17 subaccount is debited when the customer purchases a service 18 (e. g., a bus ride) or merchandise. The V-1 merchant either 19 manually or electronically enters into its card reader the amount of the purchase. In response to the card swipe performed with 21 the customer's REMOTE SMARTCARDT~~, appropriate data is 22 transmitted to the system control center via the merchant data 23 link which results in a specified amount of credit being 24 subtracted from the designated customer's V-1 subaccount. If the amount of credit remaining in the customer's designated 26 subaccount exceeds the amount charged, the merchant's card reader 27 displays "ACCEPTED." If the customer's subaccount credit balance 28 is insufficient, the system control center causes the merchant's 1 card reader to display the message "DECLINED."

3 As illustrated in the FIG. 22 diagram, a single vendor will 4 typically operate through a plurality of geographically disperses authorized merchants designated in FIG. 22 as M-1, M-2 ... M-N.
6 This merchant network system operates exactly as explained above 7 in connection with the FIG. 18 - FIG. 21 diagrams except that 8 each authorized merchant can accept customer credit or debit 9 transactions on behalf of Vendor-1. Because as illustrated in FIG. 18, the system of the present invention can accommodate a 11 virtually unlimited number of vendor accounts, the single vendor 12 FIG. 22 diagram should be visualized as being extrapolated to 13 encompass a plurality of vendors.

Based on the configuration of the system control center and 16 pursuant to the terms of agreements between vendors and 17 merchants, the FIG. 22 system configuration may be configured to 18 encompass a group of single purpose merchants and single purpose 19 vendors where only a specified group of merchants can interact with a single vendor.

22 Another category or group of merchants within the overall 23 system merchant network could by agreement interface with a wide 24 variety of different vendors. Some merchants may be configured solely as card issuing merchants who either issue cards or add 26 value to existing cards while other merchants may serve the dual 27 purpose of issuing and adding value to cards as well as debiting 28 customer subaccounts for purchases made. The status of each 1 merchant will be defined on the system control center to prevent 2 unauthorized merchant transactions. For example, for the 3 situation when Vendor-1 represents a specific city transit 4 organization (e. g., Phoenix Transit), the system would prevent use of that customer's city transit subaccount on Chicago transit 6 buses when a customer travels to Chicago. The system could, 7 however, be readily configured to accommodate a V-1 subaccount 8 corresponding to Phoenix Transit and a V-2 subaccount 9 corresponding to Chicago Transit such that a customer could utilize a single REMOTE SMARTCARDT"" product in both Phoenix and 11 Chicago. While customer subaccounts have been designated by the 12 shorthand notation "V-1," and "V-2," the vendor and vendor 13 subaccount identifications are implemented by substantially 14 longer data strings to accommodate access to a wide variety of vendor accounts by a single customer REMOTE SMARTCARDTM.

17 The FIG. 23 diagram supplements the FIG. 19 diagram and 18 explains in greater detail how a customer might directly 19 interface with the system control center without the intervention of a merchant to add value to designated customer subaccounts by 21 credit card. The data link between the customer and the system 22 control center could be provided by an interactive voice response 23 system described above in connection with the FIG. 1 - FIG. 17 24 embodiment where that system is operated by either voice recognition software, by touch tone telephone inputs or by 26 equivalent customer to system control center communication 27 systems. An appropriate customer data link could readily be 28 established by Internet data transfer accessed either from the 1 customer's home personal computer, by an office personal compute 2 or by any other Internet terminal which might be supplied by 3 various vendors or credit card organizations to enhance the 4 vendor or credit card supplier link with its customers.
6 Appropriate security could be provided during such customer 7 subaccount value adding operators. Typically, security may be 8 enhanced by requiring as a condition on system access the use of 9 one or several of the following confidential information: 1) a PIN number, 2) the customer's telephone number, 3) the last 11 four digits of the customer' Social Security Number, or 4) othez 12 similar security information typically known only to the 13 customer. For the customer's home or office computer, 14 appropriate encryption software could provide the necessary degree of system security to prevent unauthorized charges on the 16 customer's credit card.

18 Once the appropriate data has been supplied by the customer 19 to the system control center, the system control center contacts the remote database, requests authorization for a specified 21 amount of credit and receives authorization for that amount.
22 Upon receipt of that authorization, the system control center 23 distributes the total amount of the requested credit to the one 24 subaccount or plurality of subaccounts designated by the customer data input. When accessing the system control center via the 26 Internet, the customer computer screen might display a series of 27 subaccounts with a plus or minus symbol in each subaccount. By 28 placing the cursor over the plus symbol or the minus symbol, the 1 customer could specify that the balance of a specified subaccount 2 should be either increased or decreased where the increased 3 amount would be transferred from funds received via credit card 4 authorization. When the customer designates that an account balance is to be decreased or potentially zeroed out, customer-6 directed software inputs will designate where those funds are to 7 be redistributed. As illustrated in the FIG. 23 diagram, the 8 system control center would at the completion of such a customer 9 initiated transaction allow vendors access to such account redistribution data on a real time basis via the vendor data 11 link. All system vendors would thus possess on a real time basis 12 information specifying the total amount of funds held on account 13 for each vendor on REMOTE SMARTCARDs~ in the hands of customers 14 as well as the occasional use of, addition to or transfer of the various subaccount credit values on the entire REMOTE
16 SMARTCARDT~~/system control center platform.

18 The FIG. 24 diagram supplements the FIG. 19 diagram by 19 illustrating that certain merchants may be authorized to add value to customer REMOTE SMARTCARDT~~ subaccounts for the benefit 21 of all system vendors or at least for a defined and relatively 22 large subset of system vendors. A bank ATM machine might be 23 configured to function as a system-wide card seller having the 24 capability of either issuing an initial REMOTE SMARTCARDT"~ to a particular customer or to add value to designated subaccounts of 26 a previously issued REMOTE SMARTCARDT"". Such a system-wide card 27 seller "merchant" category might be staffed by an employee or, as 28 in the case of a bank ATM, operated by a computer. During the 1 transaction between the customer and the system-wide card seller 2 the customer would designate the amount of value to be added to 3 each designated subaccount. The customer's specified information 4 is communicated via the merchant data link to the system control center which, as a result of the card swipe data from the 6 customer, selects the specific customer account being accessed 7 and distributes the appropriate credit values to each designated 8 subaccount. This new customer account data is accessible to the 9 vendors via the vendor data link from the system control center.
11 The FIG. 25 diagram represents a more specific 12 implementation of the system of the present invention where the 13 system merchants are subdivided into two separate 14 classifications: 1) card debit merchants, and 2) card credit merchants. As illustrated in the FIG. 25 diagram, the card debit 16 merchants correspond to the plurality of buses utilized within a 17 single transit system which accept customer cards for fare 18 payment purposes. For such a city transit application, the 19 credit card merchants take the form of a plurality of merchants authorized to receive payment or credit in exchange for bus fare 21 credit for the designated city transit system. As illustrated in 22 the FIG. 25 diagram, both categories of merchants are 23 interconnected with the system control center via the merchant 24 data link. For mobile bus applications, the merchant data link includes a wireless system component as explained in connection 26 with the FIG. 1 - FIG. 8 diagrams. The card credit merchants 27 illustrated in the FIG. 25 diagram can be linked to the system 28 control center by wireless data transfer, by telephone or 1 Internet data link. Although it would be possible to configure 2 the system card debit merchants installed on buses to accept 3 customer payment and to add credit to customer card subaccounts, 4 a transit vendor would typically elect to avoid that option to prevent delays and to allow the bus driver to do nothing but 6 operate the bus. The city transit related card debit merchants 7 could be configured as illustrated in the FIG. 19 diagram to 8 allow access to a customer s remote credit card database to add 9 credit to the city transit subaccount, but once again typically a city transit customer would configure its system to avoid the 11 additional processing time (approximately four seconds) and 12 possible driver involvement in implementing such more complex 13 card-based transactions although the system would readily 14 accommodate such additional transaction categories.
16 In the FIG. 25 diagram, the plurality of credit card 17 merchants might represent a series of systems specific merchants 18 authorized to add value solely to the city transit subaccount of 19 REMOTE SMARTCARDST~~ or might represent system-wide card seller merchants of the type discussed in connection with the FIG. 24 21 diagram. Vendors such as a city transit organization might 22 utilize both system specific merchants as well as a secondary 23 subset of merchants such as 7-11~ or Circle K~ convenience 24 outlets. The universe of merchants selected by a particular vendor will be determined primarily by economic issues relating 26 to the cost of providing vendor specific merchants and the fees 27 to be paid by non-owned card merchants such as 7-11° or Circle K~
28 convenience stores.
1 As illustrated in the FIG. 1 diagram illustrating transit-2 related applications, the system of the present invention 3 contemplates having a central office with a single system control 4 center for accommodating data input from a wide variety of geographically distributed mobile system elements. The same is 6 the case for the FIG. 25 system which is adapted to serve 7 numerous city transit systems geographically distributed 8 throughout the world. All such systems could readily be 9 accommodated and managed by a single system control center interconnected by the Internet, by telephone line or by global 11 wireless systems such as Teledesic or Iridium wireless systems.

13 The FIG. 25 system configuration might also be implemented 14 by numerous other business categories such as, for example, McDonalds~ and Burger King° restaurant chains. Such restaurant 16 chains might wish to implement two categories of merchants such 17 as card debit merchants and card credit merchants as illustrated 18 in FIG. 25. For food purchases, REMOTE SMARTCARDT~~ customers 19 would utilize card debit merchants stationed at the McDonalds° or Burger King° checkout counters. Funds could be added to a 21 customer's card credit at a separate credit card merchant station 22 located within the restaurant or by generic card credit merchants 23 such as authorized bank ATM machines.

Numerous additional business categories would normally 26 choose to segregate business affiliated merchant terminals into 27 card debit merchants and card credit merchants to maintain high 28Ilspeed customer handling at card debit merchant terminals without 1 the time delays caused by the more lengthy account credit 2 transactions implemented at the card credit merchant terminals.
3 For example, the ABC Parking Company vendor illustrated in the 4 FIG. 18 subaccount diagram might own or operate a plurality of city parking garages which must accommodate huge rush hour 6 customer vehicle exit demands through multiple gate exit ramps.
7 Each exit ramp would include a single card debit merchant 8 terminal which might be configured to utilize a proximity type 9 card reader capable of reading the account data from a customer's REMOTE SMARTCARDTM from a distance by means of radio frequency 11 scanning, laser-based barcode scanning or by other types of 12 remote card data reading systems which provide for high speed 13 data acquisition without requiring physical contact with a 14 customer's REMOTE SMARTCARDT"~. Whatever form of card reading system used, the system of the present invention would within 16 less than one second transmit to the gate lift actuator for the 17 exit ramp as well as to the customer an "ACCEPTED" OR "DECLINED"
18 status allowing vehicles to exit the garage exit ramps with 19 almost imperceptible delays attributable to the card reading function. The application of the high speed transaction 21 processing system of the present invention to fast food 22 restaurants, cafeterias, parking garages and related high 23 customer volume businesses would vastly enhance the customer flow 24 rates of such businesses.
26 When using conventional credit cards for processing food or 27 parking charges, approximately one minute and twenty seconds to 28 one minute and thirty seconds is incurred during the transaction 1 which involves performing each of the following transaction 2 steps: 1) exchange of the physical credit card, 2) the card swipe 3 operation, 3) implementation of telephonic access with the remote 4 credit card database, 4) procurement of authorization for the amount to be charged, 5) receipt printing, 6) customer signature, 6 and 7) issuance of a duplicate receipt to the customer. Since 7 the system of the present invention operates essentially in real 8 time, does not require a customer's signature and does not 9 provide the customer with a hard copy receipt, utilizing the system of the present invention saves approximately one and one 11 half minutes of employee and customer time in comparison to 12 conventional credit card transaction processing.

14 Even when a customer pays cash to a vendor such as a McDonald's° restaurant cashier or a parking garage attendant, a 16 substantial processing delay is incurred during implementation of 17 the following processing steps: 1) announcing to the customer the 18 amount of the charge, 2) waiting for the customer to locate and 19 extract the appropriate amount of paper and coin currency, 3) handing the money to the cashier, 4) sorting the money into the 21 proper cash register drawer receptacles, and 5) making change and 22 handing a receipt to the customer. Although somewhat shorter in 23 duration than credit card transactions, cash transactions also 24 cause substantial delays. Using the REMOTE SMARTCARDT"~ to avoid cash transaction from thirty seconds to more than a minute and 26 can thereby vastly accelerating cash transactions.
1 The foregoing explanation taken together with the FIG. 25 2 diagram illustrate the advantages of separating merchant 3 terminals into debit and credit terminals where debit terminals 4 are restricted to accepting vendor payment transactions while debit terminals are restricted to receiving customer funds or 6 credit card charges and transferring those funds to designated 7 customer subaccounts stored on the system control center.

9 The FIG. 26 diagram is related to the FIG. 25 system diagram, but illustrates the application of the present invention 11 where a single business organization such as Southwest Airlines 12 provides services or sells merchandise in many different cities.
13 The FIG. 26 business model will apply to large chain-type vendor 14 such as Home Depot, V~Ial-Mart, Sears, Costco, etc. as well as parking lot operations which may operate from either a single 16 city or from multiple cities and restaurant chains which may 17 operate from either a single city or from multiple cities.

19 Southwest Airlines has been selected to explain the FIG. 26 business model because its operating mode and related problems 21 are well known. As illustrated in FIG. 26, Southwest Airlines 22 has a single Dallas, Texas headquarters which interfaces with the 23 system control center via the vendor data link.

REMOTE SMARTCARDT"" users hand over their REMOTE SMARTCARDS~
26 at the Southwest Airlines ticket counters at Phoenix, Nashville 27 and other Southwest Airlines bases to pay for ticket charges 1 using the real time system transaction speed. Vendors such as 2 Southwest Airlines could restrict the use of select ticket agents 3 for REMOTE SMARTCARDT"" users only due to the transaction speed as 4 well as to provide an incentive for customer use of REMOTE
SMARTCARDS° where the value has been prepaid. Via the real time 6 merchant data link, Southwest ticket agents will be advised in 7 less than one second after the card swipe operation whether the 8 customer's REMOTE SMARTCARDT"~ has been "ACCEPTED" or "DECLINED."

As illustrated in FIG. 26, Southwest Airlines can provide 11 other facilities for credit card merchant terminals to either 12 issue or add value to REMOTE SMARTCARDS~. Any elected incentive 13 or cost discount could take place at these merchant terminals 14 where more than one dollar of airline travel could be transferred to the designated Southwest Airlines customer subaccount in 16 exchange for one dollar of actual charge based on the fact that 17 the airline immediately receives possession of the customer's 18 funds even though those funds cannot be spent until a ticket has 19 been used for air travel. When in-house credit card merchant terminals are used, the transfer of a customer's payment present 21 an essentially internal operation. When outside credit card 22 merchant terminals are used, any one of the various alternative 23 methods of transferring customer funds from the merchant to the 24 vendor can be implemented 26 The FIG. 27 diagram illustrates a multiple merchant/multiple 27 vendor system configuration for accommodating numerous, 1 geographically distributed vendors. Although the group of 2 merchants M-l, M-2 ... M-N shown associated with each vendor are 3 depicted as a single category of merchants, the system of the 4 present invention will more typically be implemented with two sets of merchants as illustrated in the FIG. 25 and FIG. 26 6 diagrams. The dual purpose merchant configuration where a single 7 merchant using a single merchant terminal both issues and adds 8 value to REMOTE SMARTCARDS° as well as subtracts value at the 9 time of sale will most often be used at lower volume sales outlets such as convenience stores, camera shops and smaller 11 retail outlets rather than at high customer volume organizations 12 such as retail chain stores, fast food restaurants and parking 13 lot operations. Although the same symbols have been used to 14 designate the network of merchants M-1 through M-N for each of the vendors, many different merchant families or categories will 16 be defined and implemented to serve a single vendor as well as 17 various different groups of vendors. It would be possible to 18 establish a single universal system-wide card seller to issue and 19 add value on behalf of all system vendors or for a relatively large group of vendors.

22 For the FIG. 27 system configuration, various local networks 23 may be set up to interconnect merchants with the system control 24 center or vendors or designated groups of vendors with the system control center.
1 The FIG. 28 diagram illustrates that the merchant to vendor 2 fund transfer may be handled by an intermediary such as a banking 3 agent. In such an application, the V-1 merchant would either 4 electronically or physically transfer funds received from a customer to an authorized banking agent. As a result of a 6 similar relationship being set up between Vendor-1 and the 7 banking agent, customer funds could be either physically or 8 electronically transferred from the V-1 merchant to Vendor-1. If 9 a group of merchants and a group of vendors all share the same banking agent or cooperating banking agents, a substantial 11 portion of the customer payment funds could be electronically 12 transferred from the merchants to the vendors with minimal 13 complexity.

The FIG. 29 diagram illustrates one preferred configuration 16 for a multiple merchant/multiple system configuration showing one 17 particular hardware embodiment. The FIG. 8 diagram discussed 18 above in connection with transit application for the REMOTE
19 SMARTCARDT"~ of the present invention has been more broadly configured in the FIG. 29 diagram for more generic applications.

22 A Hypercom T7C card reader has been found to function 23 satisfactorily with the system of the present invention because 24 it includes compatible software and a multiple telephone number dialing capability. Such card reader terminals are typically 26 utilized for procuring telephone authorization for standard VISA, 27 MasterCard and other credit cards. When using a REMOTE
1 SMARTCARDT"~, the Hypercom terminal must be configured to dial a 2 telephone number suitable for contacting the system control 3 center of the present invention. The Hypercom card reader 4 operator pushes a button or performs some other task which enables the terminal REMOTE SMARTCARDT~~ function for system 6 control center verification as opposed operates as a conventional 7 credit card. When a customer's conventional credit card has been 8 set up to function as a REMOTE SMARTCARDT"~ according to the 9 present invention, the Hypercom terminal operator must press the same button or perform the same system configuration to cause the 11 Hypercom terminal to be interconnected with the system control 12 center. As explained above in connection with the FIG. 1 - FIG.
13 17 embodiment of the invention, the dispatch element of the 14 system control center accepts conventional credit card data and allows it to function as a REMOTE SMARTCARDT~~.

17 The FIG. 30 diagram is related to the FIG. 29 system 18 diagram, but illustrates the use of a wireless merchant system 19 interface. Such a wireless interface might be provided by LAN-based CDPD modem facilities or by satellite-based wireless 21 systems such as the Teledesic or Iridium wireless data link 22 systems.

24 The FIG. 31 diagram illustrates the various available systen customer money flow paths. FIG. 31A illustrates a FIG. 19 type 26 system where the customer's funds are transferred directly from 27 the merchant to the vendor. FIG. 31B illustrates the FIG. 28 1 system configuration where the customer's funds are transferred 2 form the merchant to a bank to the vendor. The FIG. 31C diagram 3 generally illustrates the FIG. 28 money flow path where the funds 4 are authorized by a customer, but actually paid to the vendor by the customer's credit card company.

7 In all three situations illustrated in FIG. 31, money or 8 funds are transferred from the customer to the vendor such that 9 the system control center of the present invention is never required to either take title to any money or funds or to 11 actually handle any currency or credit card funds. Instead, the 12 system of the present invention performs a bookkeeping or record 13 keeping function on a high speed real time basis which allows it 14 to utilize a card having zero intrinsic value where the value data is accessed in real time from the remote database stored on 16 the system control center computer, computer memory and computer 17 database. The system of the present invention thereby avoids the 18 requirement for bank-type security since no cash is handled and 19 similarly avoids liability for loss or theft of currency. The system of the present invention is instead entirely data driven, 21 does not legally represent a bank, and is not subject to banking 22 regulations. While the system can be configured to periodically 23 submit billing statements to merchants who have collected 24 customer funds for the purpose of having the merchant pay the vendor money received by merchants on behalf of the vendor, even 26 in that application the system of the present invention does not 27 take title to or handle customer funds at anytime.
1 FIG. 32 briefly summarizes some of the many card-related 2 system function discussed above. As noted in FIG. 32, the syste~
3 may be configured to suspend or cancel a card upon receipt of 4 appropriate password protected instructions from a customer who has either lost a card or had a card stolen. Value on an 6 existing card can be transferred to a new card when a prior card 7 has been suspended or canceled in response to customer 8 instructions or when a card has simply become physically worn out 9 from extended periods of use.
11 As noted above, the system can be configured to transfer 12 account value from one subaccount to a different subaccount. In 13 some instances, the system will be configured such that it is 14 incapable of refunding card value to a card holder and instead requires that the card value be actually spent by the card 16 holder. Since the system of the present invention never handles 17 or takes title to the customer's funds, it is impossible for the 18 system itself to refund money to a customer who has canceled or 19 suspended his account. Refund activities, if set up at all, would be handled directly between the customer seeking the refund 21 and either a merchant or the appropriate vendor. The system of 22 the present invention would merely continue to perform its 23 accounting function and would be advised by either the vendor or 24 the merchant that that card value had been refunded to the customer causing the system to zero out and cancel the customer's 26 account.
1 The business model described above encompasses an Internet-2 based zero intrinsic value REMOTE SMARTCARDT~" where the account 3 value data is accessed in real time from a remote database. The 4 system can accommodate multiple vendor accounts by use of a single REMOTE SMARTCARDT~~. New vendors and new merchants can be 6 added to the system by software revisions implemented solely on 7 the system control center. The system of the present invention 8 is compatible with either moving or stationary merchants or 9 vendors, and provides worldwide access, including access to remote areas without normal communications system infrastructure 11 due to its ability to accommodate satellite-based wireless data 12 link systems.

14 The high speed, real time system of the present invention yields extremely low transaction processing costs such that 16 vendors can be charged a fixed cost per transaction independent 17 of the purchase amount. Depending on vendor transaction volume, 18 availability of local infrastructure and numerous other 19 considerations, a vendor might be charged a transaction processing fee of as low as five cents per transaction. Use of 21 the business model described above avoids involvement with the 22 two element, variable credit card charges involving typically a 23 fifteen to twenty cent per transaction fixed fee together with a 24 one and one half to four percent discount fee which is directly related to the amount of the purchase. The low transaction cost 26 resulting from the business model described above results from 27 the use of a single site system control center, computerized real 1 time processing in combination with low cost, high speed data 2 link infrastructure interconnecting the system control center 3 with its affiliated customers, merchants and vendors. When a 4 conventional magstripe credit card product is used as a REMOTE
SMARTCARDT"~ as an element of the present system, such magstripe 6 card is compatible with many existing card readers which are 7 commercially available at relatively low cost.

9 When viewed from the standpoint of the merchant and vendor, the high speed real time transactions available from the system 11 of the present invention dramatically reduce processing time and 12 hence cost. After the merchant has entered the transaction data 13 such as product cost and has swiped the customer's REMOTE
14 SMARTCARDT"" through the card reader, the system yields a response in less than one second, essentially in real time. Use of the 16 REMOTE SMARTCARDT"~ represents a paperless cash transfer 17 transaction with no customer signature required. Although a 18 paper receipt can be printed in one second and delivered to the 19 customer, provision of a hard copy receipt is not a necessary element of the present invention. When the merchant's card 21 reader displays an "ACCEPTED" status, that status display 22 confirms that the customer is using an authorized REMOTE
23 SMARTCARDT"~ and that the subaccount value is sufficient to cover 24 the purchase cost. As a result, the merchant is guaranteed that he will be paid in full for the service or merchandise delivered.
1 The system accommodates prompt settlement because the systen 2 control center operates in real time. As between the merchant 3 and the vendor or as between the vendor and a credit card agency, 4 settlement can most conveniently take place on an overnight basis so that the vendor promptly receives the funds in relationship tc 6 the time of the customer transaction.

8 With the system of the present invention, responsibility for 9 reporting loss or theft of the REMOTE SMARTCARDT~~ is placed on the card holder. Neither the merchant nor the vendor is 11 responsible for any unauthorized use of the card because that 12 responsibility has been placed on the card holder. When a 13 customer wishes to report a lost or stolen card, the customer 14 contacts the system control center by interactive voice response equipment activated by conventional touch tone telephone 16 equipment or by Internet to promptly suspend or cancel the card 17 account. When a canceled or suspended card is attempted to be 18 used after it has been suspended or canceled, the merchant 19 receives a "DECLINED" indication, but is not forced to confiscate the card since it has been deactivated and will never again 21 function in the system.

23 The REMOTE SMARTCARDT"~ of the present invention is distinct 24 in many ways from conventional smart card products which include complex built in electronic circuitry which allows specified 26 value to be stored on the card itself. First, REMOTE SMARTCARDT"~
27 products can be configured as a thirty-five cent cost per card 1 plastic card with data encoded on a conventional magstripe. A
2 conventional smart card with its electronics and on-board batter 3 currently sells for from five to seven dollars per card.

With a conventional smart card, the card cash value is 6 assigned by special electronic smart card interface equipment 7 operated by trained personnel. If a customer desires to add 8 value to a smart card, the card must be delivered back to an 9 authorized location having the special interface equipment and trained personnel for the purpose of reprogramming the internal 11 smart card electronics.

13 If a conventional smart card is lost or stolen, the stored 14 card value can be used without restriction on a same as cash basis by whoever possesses it. When the holder of a conventional 16 smart card desires to use that device to implement a transaction, 17 the merchant requires special equipment for interfacing with, 18 reading and modifying the stored contents of the smart card 19 electronics. It is possible that conventional smart card products could be acquired and programmed with unauthorized 21 equipment on a decentralized basis and used on a same as cash 22 basis the same as counterfeit currency. The security risks with 23 a conventional smart card are therefore substantial.

Conventional smart card products are susceptible to loss, 26 theft and misuse because such equipment lacks a centralized 27 system control center capable of maintaining a real time link 1 between an authorized customer/card holder and the related 2 customer account. As a result, the holder of a conventional 3 smart card cannot take action to suspend or cancel the smart care 4 after it has been lost or stolen. The system of the present invention by operating from a single system control center 6 provides an unchanging, specified point of contact for a card 7 holder for the purpose of manipulating, canceling or suspending a 8 REMOTE SMARTCARDT"~ at any t ime .

Because the REMOTE SMARTCARDT~~ of the present invention 11 utilizes a system of vendor subaccounts as illustrated in the 12 FIG. 18 diagram, a REMOTE SMARTCARDT~~ customer can utilize the 13 customer account data stored on and accessible from the system 14 control center for budget tracking or budget compliance purposes.
By accessing his account via the Internet, the customer can 16 procure and print out a spending summary over a defined period of 17 time on a subaccount by subaccount basis to track spending habits 18 and possible spending deficiencies. The system may be configured 19 at customer request or automatically to mail out printed expense summaries to customers for an additional charge. The system 21 software may also be configured to export to customers account 22 data and history to a Quicken~ financial software compatible 23 database for storage or analysis by the customer.

Although the REMOTE SMARTCARDT"' has been described above 26 essentially as a prepay system where card value cannot be spent 27 before it has been paid for in advance, the system can be 1 reconfigured in certain circumstances to function as a post-pay 2 system if and when authorized by selected vendors. For example, 3 in connection with a city transit application, a transit 4 authority may elect that for designated card holders who have done business with the transit organization for at least one 6 year, system overcharges within a defined amount, such as up to 7 ten dollars, might be authorized. The transit agency would then 8 either arrange for or directly bill its card holder/customer for 9 the account deficit while allowing that particular card holder to continue using the transit services even with a zero subaccount 11 value. If payment for the overdrawn amount was not received by a 12 specified time, the transit authority could take action to 13 suspend the customer's authorization to charge from the transit 14 subaccount. Numerous variations and permutations of this particular deficit spending feature of the present invention 16 would be readily obvious to those skilled in the art.

18 The REMOTE SMARTCARDT~" of the present invention can be used 19 anywhere where cash or value changes hands as well as anywhere a credit card either has been used or could be used. A REMOTE
21 SMARTCARDT"" is particularly valuable where a nearly instantaneous 22 real time response is required and where a vendor or merchant 23 wishes to avoid prolonged interaction with a customer by either 24 receiving and providing change for a currency payment or by utilizing a standard credit card. The following additional 26 applications fall directly within the scope of the maximum 27 benefit for use of REMOTE SMARTCARDT~~ products: subway fare 1 cards, taxicabs, movie theaters, car washes, retail outlets, fast 2 foot restaurants, bookstores, etc.

4 The United States Government has recently sought to reduce welfare fraud by reducing use of food stamp-type welfare payments 6 where a piece of paper possesses a monetary value. The 7 Government has recently commenced implementing an electronic 8 benefit card which presumably could be used as a substitute for 9 food stamps, for welfare payments, for Medicare payments and possibly for check-type payments such as providing Social 11 Security payments to Social Security recipients.

13 By issuing an electronic benefit card configured as a REMOTE
14 SMARTCARDT"", the relevant government or state agencies could by communicating with the system control center of the present 16 invention set up and transfer credits to defined subaccounts of 17 electronic benefit cards issued to intended beneficiaries. The 18 system would be further configured such that only authorized 19 merchants could access the electronic benefit card subaccount value. The system could also readily be configured in a 21 situation where a supermarket selling both authorized and 22 unauthorized, welfare-qualified goods could refuse to allow 23 unauthorized charges to be taken from an electronic benefit card.
24 For example, at a Safeway~ grocery store, an electronic benefit-type REMOTE SMARTCARDT"~ can be configured to process charges only 26 for food items and not for unauthorized items such as beer, wine, 27 liquor, cigarettes, magazines, light bulbs, etc. Because such 1 supermarkets typically use barcode scanning devices at the 2 checkout counter and print receipts which specifically identify 3 each product purchased, an appropriate database software could be 4 configured to disallow unauthorized product purchases at the point of sale.

7 The system of the present invention may also provide 8 enhanced management and marketing data to the vendors and 9 merchants who elect to utilize the REMOTE SMARTCARDT"~ system.
First, a large volume of customer purchase data may be derived 11 from the merchant and vendor data links from the system control 12 center on a real time basis in response to customer purchase 13 activities. Either a vendor or a merchant could provide data 14 indicating customer traffic on a customer per hour basis, amount spent per customer per hour basis, on the basis of gross receipts 16 per hour, per day, per week or per month.

18 By using appropriate database software, both merchants and 19 vendors could acquire highly useful inventory and marketing information by blending together merchant transaction data with 21 REMOTE SMARTCARDT"~-related data. By using barcode scanning 22 information, the merchant and vendor both have the capability of 23 tracking the product identified contents of all cash register 24 receipts, including time of day, cash register number, card reader identification, Internet IP address as well a transaction 26 amount. By using the REMOTE SMARTCARDT"~, the system control 27 center receives as a result of each transaction the following 1 data: time of day, IP address of card reader, merchant identity, 2 subaccount to be accessed together with vendor identification, 3 card holder account number, card holder identification, includinc 4 name, address and additional data, together with the total amount purchased.

7 By blending together the merchant transaction data with the 8 REMOTE SMARTCARDT~~-related data, both the merchant as well as the 9 related vendor would receive sales data linked to specific customers to allow for highly refined customer product purchase 11 data mapped out by customer address or by zip code allowing for 12 targeted or highly focused post-sale customer contact or follow 13 up marketing.

As an additional management and marketing benefit of the 16 present invention, vendors and merchants could provide incentive 17 based discounts to encourage persons to acquire and use REMOTE
18 SMARTCARDTM products for the purpose of expediting transaction 19 processing at fast food restaurants, cafeteria lines or parking garages as well as many of the other applications discussed 21 above. For these merchants and vendors, expediting transaction 22 processing time saves money, reduces staffing requirements and 23 reduces waiting time in lines.

A vendor such as a dry cleaner or grocery store could 26 provide time of day defined promotional discounts for REMOTE
27 SMARTCARDT"~ users to influence customer traffic flows to specific 1 days or times of days when the merchant or vendor experiences 2 reduced traffic flows. For example, a dry cleaner could give a 3 five or ten percent discount for use of REMOTE SMARTCARDs~ on 4 Tuesdays. A grocery store could provide a two percent discount at all times for using REMOTE SMARTCARDT"" products, a larger 6 discount for card based purchases made at specific days and times 7 or a ten percent discount for REMOTE SMARTCARDTM senior citizens.
8 Grocery stores might also run discounts on special items for 9 REMOTE SMARTCARDT"~ users only and for specified items.
11 Chain stores such as K-Mart° could run a "blue light 12 special" on a defined product on a store by store basis but only 13 for REMOTE SMARTCARDT~~ holders.

When used as a loyalty card, a fast food restaurant such as 16 a Burger King~ could provide a free meal if a REMOTE SMARTCARDTM
17 customer made three purchase transactions within one week where 18 each transaction exceeded five dollars. The system control 19 center software could readily be programmed in response to input vendor Burger King° to provide such loyalty-related promotional 21 benefits. Video stores and other retail establishments which 22 rely on repetitive customer visits could similarly benefit from 23 the ability to reconfigure and modify promotional or discount 24 fare structures via the single site system control center.
26 Use of the REMOTE SMARTCARDT~~ of the present invention 27 provides substantial security benefits. Because the account 1 value is stored on the system control center and not on the card, 2 loss or theft of the card does not result in loss of the stored 3 card value. The real time processing speed provide by the REMOTE
4 SMARTCARDT~~ simulates the use of a conventional smart card with the value stored on the card without suffering from the cost and 6 security shortcomings of conventional smart card products.

8 The ability of the system to utilize standard credit cards 9 once they have been activated to operate with the system substantially simplifies the card issuing task and provides a 11 special form of security. Since a criminal cannot distinguish a 12 conventional credit card from a conventional credit card 13 configured to operate as a REMOTE SMARTCARDT"~, there is no 14 greater incentive to steal conventional credit cards configured to operate as REMOTE SMARTCARDs~.

17 Improper use of a REMOTE SMARTCARDT"" is extremely difficult 18 since the card account number data reveals no information about 19 the value stored on the system control center corresponding to that card or the subaccount identity or subaccount balances for 21 that particular account number. Only the legitimate owner of a 22 REMOTE SMARTCARDT"~ having access to the appropriate PIN number 23 and related password security data can contact the system control 24 center and download the subaccount identity and subaccount balance data. The fact that the REMOTE SMARTCARDT~" system 26 operates through a single site system control center 27 substantially enhances the overall system security.
1 Unauthorized use of a REMOTE SMARTCARDT~~ is further reduced 2 by the fact that a particular subaccount value can only be 3 accessed by an authorized merchant who must be identified to the 4 system control center by the IP address of an authorized card reader. Access is limited at all times to the customer's stored 6 subaccount value as maintained by the system control system.

8 Since a card swipe of an authorized and active REMOTE
9 SMARTCARDT"' on an authorized merchant card reader yields only an "ACCEPTED" or "DECLINED" output, an unauthorized user learns 11 nothing more about the contents of the authorized customer's 12 account balances by successfully using a stolen customer's card 13 one time.

The system of the present invention could be programmed to 16 automatically suspend or cancel a REMOTE SMARTCARDT~" which was 17 activated at an authorized system merchant where the card holder 18 had no subaccount value relationship or when the REMOTE
19 SMARTCARDT~~ was accessed a specified number of times and received a "DECLINED" response indicating either a zero subaccount balance 21 or the absence of a corresponding subaccount. Numerous different 22 categories of Gross-checking or security analysis could be 23 implemented to automatically deactivate a REMOTE SMARTCARDT"" when 24 the system detected an excessive amount of improper card usage.
26 It will be apparent to those skilled in the art that the 27 disclosed Internet-based zero intrinsic value smart card with 1 value data accessed in real time from a remote database may be 2 modified in numerous ways and may assume many embodiments other 3 than the preferred forms specifically set out and described 4 above. Accordingly, it is intended by the appended claims to cover all such modifications of the invention which fall within 6 the true spirit and scope of the invention.

Claims (10)

1. A card-based system for electronically transferring funds in real time comprising:
a. a customer card for storing digital data representing a unique customer account number associated with a unique, remotely located customer account having at least one vendor-associated subaccount;
b. a merchant terminal having a merchant IP address designating a unique merchant affiliated with at least one unique vendor for transmitting to a system control center customer transaction data including the merchant IP address, the customer account number read from the customer card and account adjustment data designating either the value of a credit to be added to the vendor-associated subaccount reflecting a customer pre-payment or the value to be subtracted from the vendor-associated customer subaccount reflecting a customer purchase; and c. the system control center for maintaining a vendor account database and a customer account database, the customer account database associating each customer account number with the unique customer account number, for storing the subaccount credit balance corresponding to the specified vendor, for receiving the customer transaction data transmitted by the merchant terminal, for adjusting the customer subaccount value up or down in response to the customer transaction data, for transmitting to the merchant terminal customer account status information and for adjusting the vendor account database to reflect credits resulting from vendor-associated customer transactions.
2. The card-based system of Claim further including a vendor datalink for transmitting data between the vendor and the system control center for enabling a vendor to access and review the vendor database.
3. The card-based system of Claim 2 wherein the vendor datalink is established via the Internet.
4. The card-based system of Claim 1 further including a wireless datalink network for transmitting data between the merchant terminal and the system control center.
5. The card-based system of Claim 1 further including an Internet datalink for transmitting data between the merchant terminal and the system control center.
6. The card-based system of Claim 1 further including a remote credit card database and a credit card datalink for transmitting data between the system control center and the credit card database.
7. The card-based system of Claim 6 wherein the credit card database is coupled to the system control center via the Internet.
8. The card-based system of Claim 7 further including an Internet data interface for enabling a customer having a customer card to access the customer account database on the system control center via the Internet and for enabling the customer to transfer funds from the remote credit card database to the customer account database.
9. The card-based system of Claim 1 wherein the merchant terminal designates a merchant affiliated with first and second vendors.
10. The card-based system of Claim 1 wherein the customer account database includes multiple subaccounts wherein each subaccount corresponds to a unique vendor and wherein the credit valance of each subaccount can be adjusted independently of the credit balances of the other subaccounts.
CA 2310151 1999-06-02 2000-05-30 Internet-based zero intrinsic value smart card with value data accessed in real time from remote database Abandoned CA2310151A1 (en)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
US13778499P 1999-06-02 1999-06-02
US60/137,784 1999-06-02

Publications (1)

Publication Number Publication Date
CA2310151A1 true CA2310151A1 (en) 2000-12-02

Family

ID=22479030

Family Applications (1)

Application Number Title Priority Date Filing Date
CA 2310151 Abandoned CA2310151A1 (en) 1999-06-02 2000-05-30 Internet-based zero intrinsic value smart card with value data accessed in real time from remote database

Country Status (1)

Country Link
CA (1) CA2310151A1 (en)

Cited By (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US9218600B2 (en) 2006-12-07 2015-12-22 Smart Systems Innovations, Llc Mass transit fare processing system
US9558487B2 (en) 2006-12-07 2017-01-31 Smart Systems Innovations, Llc Public transit system fare processor for multi-balance funding
CN110046786A (en) * 2018-01-15 2019-07-23 玉山商业银行股份有限公司 Visualization is presented Automatic Teller Machine and layouts the method for operational regime

Cited By (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US9218600B2 (en) 2006-12-07 2015-12-22 Smart Systems Innovations, Llc Mass transit fare processing system
US9558487B2 (en) 2006-12-07 2017-01-31 Smart Systems Innovations, Llc Public transit system fare processor for multi-balance funding
CN110046786A (en) * 2018-01-15 2019-07-23 玉山商业银行股份有限公司 Visualization is presented Automatic Teller Machine and layouts the method for operational regime

Similar Documents

Publication Publication Date Title
US6648222B2 (en) Internet-based zero intrinsic value smart card with value data accessed in real time from remote database
US6732922B2 (en) System enablement of automatic fare collection devices using a network
CA2518895C (en) System and method for sales and inventory reconciliation
US8025223B2 (en) System and method for mass transit merchant payment
US6736317B1 (en) Real time internet-based transit management and control system with wireless vehicular data link
US20170330168A1 (en) Method and portable apparatus for settling transaction
AU2002303848B2 (en) Community concept for payment using RF ID transponders
USRE44467E1 (en) Wireless telephony for collecting tolls, conducting financial transactions, and authorizing other activities
CA2113805C (en) Pocketsize electronic travel and commuter pass and a plurality of accounting systems.
US7182252B1 (en) Methods and systems for transferring funds
US20060085308A1 (en) System and method for sales and service reconciliation
US20060261153A1 (en) Automated payment system with additional capability
US20080033880A1 (en) Techniques for authorization of usage of a payment device
EP1357527A2 (en) A payee account payment system
AU2002309828A1 (en) System enablement of automatic fare collection devices using a network
JPH03102597A (en) Credit card apparatus
AU2002303848A1 (en) Community concept for payment using RF ID transponders
US7725351B1 (en) Point of sale system interface for processing of transactions at a secondary transaction payment network
Turban et al. Smart card-based electronic card payment systems in the transportation industry
CA2310151A1 (en) Internet-based zero intrinsic value smart card with value data accessed in real time from remote database
AU2014287163A1 (en) Shared video vendor
JP2002056338A (en) Purchase price payment method and purchase price payment system
JP2003006681A (en) System for selling ticket
KR20030042201A (en) On-board wireless transaction system and method

Legal Events

Date Code Title Description
FZDE Dead