Registers – Systems controlled by data bearing records – Credit or identification card systems
Reexamination Certificate
1999-08-05
2004-10-26
Lee, Michael G. (Department: 2876)
Registers
Systems controlled by data bearing records
Credit or identification card systems
C235S379000, C235S381000, C235S383000, C705S041000, C705S043000
Reexamination Certificate
active
06808111
ABSTRACT:
FIELD OF THE INVENTION
The present invention relates generally to smart card terminals. More specifically, the present invention relates to a terminal software architecture that allows terminal applications to be portable to multiple terminals.
BACKGROUND OF THE INVENTION
In today's technologically advanced society, businesses often issue cards to consumers for making transactions and so that their purchases and other transactions may be tracked. For example, many businesses currently make use of so-called “loyalty” programs that reward customers for frequent purchase of the business's products or services. Well known loyalty programs include frequent flyer mileage programs, frequent guest programs at hotels, programs to reward frequent purchases at food markets, etc. Such loyalty programs may make use of a plastic card with an embossed customer number to help keep track of a customer's purchases. Others use a magnetic stripe card which can magnetically store information such as customer name and identification number, number of purchases, points awarded, etc. Still other loyalty programs have been implemented using a smart card in conjunction with a terminal at a loyalty operator's place of business. Other software programs that implement stored-value applications, debit applications, etc., (“applications”) are also implemented using consumer smart cards and terminals at businesses. It is therefore important to ensure that the cards and corresponding terminals are compatible. Although such compatibility has been successfully tested to date, there are a number of disadvantages to the way the testing is currently being performed.
Traditionally, card and terminal suppliers have independently received a functional specification for a new smart card-based application. Working asynchronously and semi-autonomously, the suppliers create card and terminal application programs from the functional specification. However, considerable latitude in the interpretation of the functional specification exists, often resulting in incompatible card and terminal implementations. As a result, additional development and testing time has been required to resolve the discrepancies.
The traditional situation is further aggravated by the complexity of programming chip cards and their low-level interface to the terminal. Therefore, demand for chip card-based applications places considerable pressure on a scarce pool of qualified people generally resulting in an extended time-to-market period.
Typically, the cards and terminals are designed, tested, and produced in parallel. More particularly, the production of a terminal includes manufacture of the back-end system for handling the data for the terminal as well as the terminal application that runs on the terminal. Similarly, the production of a card such as a smart card includes creating the card application (i.e., code) that is to be loaded onto the smart card. Together, the back-end system, terminal application and card application implement the overall application, such as a loyalty application.
FIG. 1
is a diagram illustrating a conventional method of producing compatible card and terminal applications. As shown, an application designer
102
(such as Visa International) produces separate specifications for the card application, the terminal application, and the back-end system that are given to the different corresponding manufacturer and systems developers. The back-end system specification
104
is given to a back-end system developer
110
, the terminal application specification
106
is given to a terminal manufacturer
112
, and the card application specification
108
is given to a card manufacturer
114
for independent development. Once the back-end system, the terminal application, and the card application are completed, the completed products are provided to the application designer for certification testing. Certification testing
116
is then performed to test the functionality and compatibility of the completed products. Once testing is completed, the products are produced
118
.
While the certification process may appear to be straight forward, it is important to note that it is typically desirable to design a card application that is compatible with terminals manufactured by a variety of terminal manufacturers. As a result, the conventional certification process is repeated for each such terminal to verify the functionality of the terminal as well as the compatibility of the terminal with the card application. Accordingly, since the certification process is performed for each different terminal, the certification process is a long and tedious process.
In addition, although the specifications for each of the products (e.g., terminal and card applications) are written such that the resulting products will be compatible, there are often multiple interpretations for a given specification. As a result, there may be discrepancies between the interpretation of a specification and the resulting implementation by a given manufacturer (e.g., terminal and card manufacturers). It is therefore necessary to repeat the certification process until all discrepancies are resolved. This method of production is therefore a time-consuming and expensive one.
As described above, each terminal application is designed and written for use with a specific terminal. That is, a conventional terminal application is typically written using proprietary libraries and software maintained by the terminal manufacturer.
FIG. 2
is a diagram illustrating a conventional terminal architecture for terminal A. As shown, a terminal application
202
is specifically designed and written for use with terminal A. In addition, the terminal application
202
directly uses operating system
204
. While libraries
206
may serve to standardize such terminal applications, the libraries typically include files that are proprietary to the manufacturer's development, including hardware
208
. As a result, such a terminal application
202
cannot easily be altered to accommodate different terminals.
Although terminal applications cannot easily be altered to be compatible with different terminals, the number and capability of terminals are expanding. In addition to electronic point of sale systems, EFT/POS terminals and ATMs, non-traditional points of interaction require card acceptance in kiosks, personal computers, network computers and consumer applicances such as smart phones, television set-top boxes and advanced electronic game systems.
As described above, while libraries may provide some standardization for the production of terminals and terminal applications, each terminal application must still be written such that it is compatible with a specific operating system and hardware. For instance, a diagram illustrating a conventional terminal architecture for terminal B is illustrated in
FIG. 3. A
terminal application
210
is written specifically for terminal B, which interacts directly with the operating system
212
provided in terminal B. Similarly, the application
210
uses libraries
214
that are specific to terminal B and the associated hardware
216
. Therefore, even where different terminal applications are designed and written to be compatible with the same card application, the terminal applications must also be compatible with the operating system and hardware of the specific terminals. As a result, it is impossible to run the same terminal application on terminals manufactured by different terminal manufacturers. Thus, for a given loyalty application, while there may be a single card application, there may be multiple terminal applications required due to the different types of terminals. For example, terminal applications
202
and
210
are different, yet still implement the same loyalty application.
In view of the above, it would be beneficial if a terminal architecture were developed that would permit terminal and card applications to be developed in parallel such that the resulting applications are guaranteed to be compatible. Moreove
Billon Jean-Paul
Colas Christophe
Kashef Forough
Nakamura Lance Shigeo
Sak Thomas H.
Beyer Weaver & Thomas LLP
Kim Ahshik
Lee Michael G.
Visa International Service Association
LandOfFree
Terminal software architecture for use with smart cards does not yet have a rating. At this time, there are no reviews or comments for this patent.
If you have personal experience with Terminal software architecture for use with smart cards, we encourage you to share that experience with our LandOfFree.com community. Your opinion is very important and Terminal software architecture for use with smart cards will most certainly appreciate the feedback.
Profile ID: LFUS-PAI-O-3329260