MXPA00012779A - Stored value transaction system including an integrated database server - Google Patents

Abstract

An integrated database and information server are provided that efficiently share information and tasks between various stored value programs. A server is configured to provide reusable objects and data structures that are suitably shared between various stored value products. A database at the server allows data to be shared between various programs so that each consumer associates with only one database record even though that consumer may use multiple sharedvalue products. An exemplary common record for a consumer includes information relating to mailing addresses, preferred language, and the like. By integrating modules and avoiding duplicate records, the record communicates with all stored value programs, so the information does not need to be repeatedly entered into the database. Moreover, new stored value products are quickly and easily created through selection and arrangement of various shared objects preferably maintained within the database.

Description

STORED VALUE TRANSACTION SYSTEM THAT INCLUDES AN INTEGRATED DATABASE SERVER DESCRIPTION OF THE INVENTION • The present invention is generally related to financial operations systems and more particularly, to an architecture and computer server to handle financial operations involving stored value products such as smart cards. ™ 10 Financial systems using stored value products are well known in the art. An example of a stored value product is a prepaid phone card, typically a cardboard or plastic card with a unique identification code. The code may be printed on the front of the card, or it may be stored electronically on a magnetic strip that is affixed to the card. To access the value of the card, consumers can, for example, dial a predetermined phone number and enter the unique code, with this identifying the card and allowing the consumer to have access to a service (such as a long-distance telephone service). In spite of the telephone services, the cards with magnetic strips have been used for the prepayment of, among other things, gasoline or merchandise in department stores. In these industries, special card reader machines like those found in many stores (for example, point of sale (POS) terminals) are typically configured to read the magnetic strips incorporated in the card. A relatively new stored value technology is the smart card that typically replaces the magnetic strip with a microprocessor. Other products with stored value include, for example, cards for ATMs, banking operations performed at home and many commercial products over the Internet. Products with stored value have been suggested as replacement for cash in many operations because such products have proven to be safe and convenient without compromising user privacy. Consumers often buy cards with stored value for predetermined amounts, or, alternatively, the card can be configured to have an electronic representation of the value that the consumer has purchased. However, unlike cash operations, stored value operations typically use an administrator to facilitate the creation of the card, the distribution of the card, the handling of operations, and / or the like. Administration institutions frequently support several products with stored value through computer systems that they are configured to track information such as card balances, consumer email addresses, financial operations and / or the like. The interfaces and components associated with each product with stored value (smart cards, telephone cards, ATM, etc.) very often require that each product be managed by a dedicated computer system. Therefore, when management institutions support several products with stored value, they very often support multiple computer systems. As shown in Figures IA and IB, these computer systems are often disjoint systems configured to support only one product with particular stored value. These disjoint systems are usually inefficient because they very often incorporate substantial data duplication and administrative expenses. For example, the functions that are commonly implemented in each administration system include, among other things: adding new cards, registering customers in new accounts, issuing personal identification numbers (PINs), adding value to smart cards and other accounts. , management operations (mercantile, ATM, telephone, etc.), and generate reports (such as account statements and letters to consumers). An example of such prepaid card systems is described in U.S. Patent No. 5,577,109 issued on 19 November 1996 to Stimson et al. Likewise, a system to support multiple functionalities in a single card is described in US Patent No. 5,574,269 issued November 12, 1996 to Mori et al. A system for achieving payment mediation between a payment container selling cards with stored value, and other vendors providing the services for which the card is used as payment is described in WO 98/08175. A system for supporting stored value accounts that are identified by anonymous account holders is described in WO 97/0560. Recently, as shown in Figure IB, some disjoint administrative systems have somehow been integrated through the ability to share limited functionalities such as card authorization and operation processing. Although this arrangement is better compared to that in Figure IA because it is somewhat less redundant, the arrangement in Figure IB still includes substantial duplication of information and administration because each program incorporates data record and for general methods such as of currency, language used, etc. An additional disadvantage that disjoint systems exhibit is that each management system is typically and individually constructed, thereby requiring excessive labor, time and expenditure for its operation. creation, maintenance and operation. Accordingly, there is a need for a card handling system B that simultaneously supports several products with stored value and their associated functions. 5 This system is necessary to reduce implementation times, to improve the efficiency of data processing and to reduce administrative expenses for each system. An integrated database is provided and information server that efficiently compacts information and tasks between different stored value programs. A server is configured to provide reusable data structures objects that are common to multiple stored value programs. A data base on the server allows data to be shared between different product programs with shared value so that each consumer associates it with only one database record although the consumer can use multiple products with stored value. A common exemplary record for a consumer includes information related to email addresses, preferred languages, and the like. By integrating modules and avoiding duplicate records, the registry communicates with all stored value programs, so that the information does not need to be repeatedly entered into the database. On the other hand, new value programs stored are created quickly and easily through the selection and arrangement of several shared fB reusable objects stored in the database. BRIEF DESCRIPTION OF THE DRAWINGS The foregoing and other objects, features and advantages of the present invention will be described later in the following detailed description of the illustrative modalities to be read in conjunction with the accompanying drawings, in which like reference numerals are used. ^? W 10 to identify the same or similar parts in similar views and: Figure IA is an exemplary entity relationship diagram of prior art administration servers for products with stored value; Figure IB is an exemplary entity relationship diagram of prior art administration servers for products with stored value with sharing capability with limited functionality; Figure 2A is an entity relationship diagram 20 of a first exemplary embodiment of the present invention; Figure 2B is an entity relationship diagram of a second exemplary embodiment of the present invention; Figure 3 is an entity relationship diagram showing exemplary data flows to create e initialize a new stored value account; Figure 4 is an entity relationship diagram showing exemplary data flows for processing operations; Figure 5 is an entity relationship diagram showing exemplary data flows to inform its generation; Figure 6 is an entity relationship diagram of an exemplary mode of a database server based on the operations system; Figure 7 is a pyramid of functionality that shows an exemplary array for a database server; Figure 8 is an entity relationship diagram showing data flows for an exemplary implementation of the database authorization; Figure 9 is an entity relationship diagram showing an exemplary relationship among several objects in the database; Referring to Figure 2A, a preferred embodiment of the invention suitably includes a system 20 that includes a database server 116 that suitably supports a number of products with stored value, such as, for example, several brands of smart cards, cards with magnetic strips, ATM, Internet transaction accounts, or other products with value stored. The database server 116 generally provides centralized management of the different products, and preferably includes a database (such as a relational or object-oriented database) that centralizes the data and procedures to be shared with the database. Through the different products with stored value As shown in Figure 2A, a client system 138 is any device or entity that is suitably configured to include functionalities. • 10 individuals and interfere with a common server. Preferred client systems 138 include only the functionality that is unique to the particular customer system 138, such as, for example, sales and pricing information and interference handling. In other words, the The most common functionality is located and is shared in the database server 116 as, for example, the creation of card / accounts, sum of funds, account information, report information and / or the like (the details of the functionality will be described later with respect to the Figure 8). In a particularly preferred embodiment, a client system 138 represents a particular brand of smart card. The client systems 138 suitably transmit data to the database server 116 corresponding to the creation of new ones cards / accounts with stored value and the addition of funds in the stored value account. In the alternative embodiments of the invention, the client systems 138? they adequately receive data as account information and report information from the database server 116. Alternatively, as can be seen in Figure 2B, the database server 116 interacts with the client systems 138 through intermediation modules such as the report generator 136 and the card production system 128. In other modalities, the client 138 resides in the HP 10 database server 116, operating as a separate process. In still other embodiments, customers 138 are eliminated in their entirety and consumers and business entities interact directly with the database server 116. The server 116 preferably supports two modes of interaction with the clients 138. The first mode of the system 20 (shown by the clients 138A, 138B and 138C in Figure 2A) is typically referred to as a "rear end". • centralized "or" a centralized backup pool "due to to which the client 138 simply acts as a "front end" (i.e., interface) for the database server 116 that primarily handles data handling functions. In the modalities where the customer 138 is a business entity, the representatives of the business entity of The client provides information to the database server 116. data electronically, through an online CSR entry, or other means. Í? The second system mode 20 (commonly referred to as the "centralized back end" or "centralized backup office 5") suitably incorporates a franchise server 142 between the client D-E systems 138 and the database server 116. The franchise server 142 is properly interfaced with the stored value products of different organizations while retaining • 10 centralized data handling in the database server 116. In a particularly preferred embodiment, the franchise server 142 supports a business entity that has several clients corresponding to the clients 138. As can be seen in Figure 2A, a single server 116 of The preferred database is configured to simultaneously support the centralized and multiple centralized backup office client systems 138. Alternatively, the database servers 116 • Multiple are configured to interface with any combination of franchises 142 of centralized or centralized. The different clients and servers mentioned above are connected in an appropriate way through any means of electronic communication including, for example, telephone links, leased lines, connections Asynchronous transfer mode or relays of structures, local area networks, or networks of wide coverage area. Alternatively, the client systems and servers are suitably interconnected through any combination of two or more data communications means. Although communication links between the client server systems of preference are available at any time, some embodiments of the invention use batch processing or polling schemes whereby the servers and client systems interact only in predetermined time periods. . Alternatively, persons representing business entities provide information to the database server 116 through any form of communication including telephone, Internet, mail or other suitable means. As can be seen in the exemplary embodiment shown in Figure 3, in use, a client 138 preferably notifies the database server 116 of a consumer 100 the request for a new card. In other embodiments of the invention, the client 138 is diverted and a new consumer card request 100 is provided to the database server 116 electronically, or through a customer service representative or through other means. After processing the new card request as will be discussed later, the base server 116 preferably data sends a message to the card production system 128 that properly creates a new IB card by known card creation methods and the new card is sent to the customer 100. The card production system 128 also properly notifies the customer 138 relevant (applies) that a card has been created. After the card is created and the consumer 100 is sent, in the preferred embodiment of the invention, the client 100 activates the card before using it. the activation is achieved through an activation server 132 that receives information about new cards from the database server 116, preferably either in real time as the cards are created, or alternatively, the The activation server 132 receives information in batches in predetermined time periods. Several activation servers are known in the prior art and the activation server 132 may be implemented internally • or external to the present invention. To activate the card, the consumer 100 suitably makes contact with the activation server 132 by means of a telephone, Internet or other connection to verify the consumer's identification. The consumer is verified through any appropriate verification method, including recitation of a number printed on the card (or sent with the card) or the recitation of some identifying information about the client 100 such as the consumer's social security number or the names of the parents. If the identity of the consumer 100 is properly verified, then the activation server 132 appropriately identifies the transaction authorization system 108 that the card has been approved for use. Several prior art authorization systems are known and the operations authorization systems 108 can be implemented internally or externally to the present invention. If the card is rejected, the consumer 100 preferably connects by telephone, by Internet or by other means to a representative 134 of customer service.

(CSR) who verifies (preferably through online access to either the customer 138 or the database server 116) the consumer's ability to use the stored value card or the account. If the account is rejected by the CSR 134, then the card or account will remain blocked and the authorization system 108 will reject any use of the card or account. If the CSR is available to verify the consumer 100 and the card / account then the CSR 100 preferably sends a "remove block" or a message comparable to the authorization system 108 so that the consumer 100 can properly use the verified and activated account.

If the consumer 100 wishes to add value to the previously created card / account, the consumer generally provides the funds added to the customer 138 (via any means of communication such as telephone, Internet, POS terminal, ATM machine, or the like) which in turn suitably pass the information to the database server 116, causing the database server 116 to update the consumer's account. In alternative embodiments, the consumer 100 provides a value directly to the database server 116 in the form of a check or credit card number that can be electronically entered, or manually entered by a CSR. Alternatively, the consumer 100 adds value to the card / account via, for example, a point of sales terminal, ATM machine, Internet connection or telephone connection. The funds are preferably registered in the database server 116 through a real-time batch processing scheme. Figure 2A shows an exemplary direct bidirectional flow of information between the client 138 and the database server 116. By comparison, the exemplary embodiments shown in Figures 2B and 3 show the database server 116 receiving information directly from the databases. 138A-C clients while providing data to 138A-C clients through systems 128 and 136 intermediate For example, the database server 116 provides information to the client 138 preferably by sending a "generated report" or similar message with a necessary parameter of the data necessary to report the generator 136 as shown in Figure 3. Alternatively, the server 116 The database provides the report directly to the customer 138 through a telephone, Internet or other connection. The processing of preference operations is handled through the interaction between the database server 116, the authorization system 108, and an operations capture and routing server 112. As can be seen in Figure 4, the database server 116 appropriately communicates the status information of the card / account to the authorization system 108. The status information generally includes updates of account balances, status changes and the like for the different card accounts. For example, preferably the new cards are assigned a "stop" status in the authorization system 108 until the consumer 100 initializes and validates the card as described above, at which time the preference authorization system changes the state of "stop" to "pass" (or similar terms). A state of "stop" is also assigned preferably if an account balance decreases below a minimum amount, or if a card is lost or stolen or similar. The accounts / cards that are assigned with a status of "stop" preferably are rejected by the authorization system 108 in any subsequent request for an operations approval. The point of sale terminal 104 is any device that is capable of identifying and joining data of any stored value product. For example, point of sale terminal 104 may be increased as a current terminal in a store, an Internet server, a telephone system, a card reader in a dispatch machine, an ATM or any other device that is capable of accepting information with value stored in financial transactions, the point of sale terminal 104 conveniently communicates with the authorization system 108 to approve or reject the operations' based on the information available in the authorization system 108 of the database server 116 . Alternatively, the authorization system 108 supplements information from the database server 116 with information obtained from other external sources (not shown) such as external authorization systems, credit information offices, etc. The authorization of preference is carried out in real time, but in some modalities the authorization is carried out using a notice of batch processing or polling. In a preferred embodiment, at a consumer 100 presents a card with stored value or enters an account at a terminal point 104 of sales, the terminal sends an authorization request for the operation to the authorization system 108. Additionally, for some operations (such as those involving very small amounts of money) the point-of-sale system 104 may not even transmit an authorization request. Although the authorization can be carried out by any means of communication, the preferential authorization occurs through a data communications link such as a telephone link, a leased line, the Internet, a wide area coverage network, or the like. If the operation is authorized, the operation is preferably completed in the terminal 104 of the point of sale. The point of sale terminal 104 generally requests information such as the transaction amount and the entity of the stored value product used to pay for the operation and this information is then transmitted in an appropriate manner to the module 112 for capturing operations for collection. To facilitate batch processing of billing requests, merchants generally store multiple operations information. Alternatively, the collection requests are properly transmitted in real time or are suitably polled by the module 112 of capture of operations. Still referring to Figure 4, the module | B 112 capture properly captures data from financial operations of the 104 POS terminal and routes this information to the database server 116. During a purchase transaction involving a product with stored value, the funds are properly transferred from an account associated with a stored value card to the merchant's account. The records of the merchant's accounts ^ w 10 the card can generally be accessed by the database server 116, and preferably are kept within the database 142 (not shown in Figure 4). A system 118 of balances of preference is located between the server 116 of the database and the processing module 112 operations to verify the operations data. The balance system 118 is any computer system that provides a review based on the data received from the database server and the operations processing module 112. As best shown in Figure 5, a single preference report generator 136 generates reports (1) for customers 138 that use the products with stored value, as described above; (2) for traders 140 who accept product with stored value as compensation for the goods or services; or (3) for consumers who receive, for example, periodic account statements of their accounts and operations. Alternatively, report generators 136 create several reports. As another alternative, the database server 116 internally generates some or all of the reports without the use of an external report generator 136. In some embodiments of the invention, the reports are generated in real time (ie, as requested by the account manager, the consumer, the database server 116, or another entity), alternatively, the reports are they process in the different modalities in batches, at predetermined times when they are polled by the report generator 136, or by any other synchronization arrangement. The preference report generator 136 retrieves relevant data from a database associated with the database server 116. In other embodiments, the database server 116 provides data necessary for the report generator 136 as part of a report generation request. Alternatively, the database server 116 appropriately sends an indicator (such as a memory address that can be accessed via a shared bus, or a uniform source locator (URL or any other indicator) to the information that is stored. After obtaining data from the report request, the report generator 136 formats the data and provides the data to the appropriate customer system 138. Various report generation systems are known in the prior art, and any report formatting system can be used in accordance with the present invention. Figure 6 shows an exemplary mode of a combined system for adding cards, managing operations and processing reports. As can be easily seen in Figure 6, a preferred embodiment of a stored value operations system includes a database server 116 that supports products with multiple stored value, each transfer product being associated with a particular client 138. The database server 116 preferably receives input information from the client 138 and a financial capture / operation routing module 112, as well as optional online input data from the consumers 100 or the customer service representatives 134. . The cards and accounts with stored value preferably are registered with an authorization server 108 that is configured to test or deny individual operations at various point of sale terminals such as terminal 104 in the drawings. Preferably, the database server 116 communicates with a report generating system 136 that is configured to assemble data in the reports for the 138 customer, dealer 140, and / or consumer systems 138. 100, with this formatting and simplifying the data output from the database server 116. As mentioned above, the database server 116 includes common operations and data for the different products with stored value. The database server 116 preferably retains at least central information 192 and local information 190, as shown in Figure 7. the central information 192 generally includes all functions, data, software and infrastructure that are common to all stored data products including database management, interface formatting, operation management and various product features. Information 190 is generally non-standard information that is specific to a particular product, country or consumer that does not provide shared value for other applications, local information includes, for example, language details, local currency, taxes, customs, filing formats, addresses and local interface data, the separation of the local information 190 from the central information 192 allows flexibility to implement the coding (shortcuts) that can provide the most effective solution for certain individual tasks. Shortcuts are possible since certain local information 190 can not be applied to the central information 192. On the other hand, local information is located at the base of the base organizational pyramid. of data shown in Figure 7 indicating that the local data substantially does not update or modify the central information 192. The central information 192, however, frequently modifies the local information. Thus, by separating objects and business rules with high value (ie, central information 192) from the low-level technical infrastructure (ie, local information), implementation independence is promoted, and with this The sharing of data and resources between products with disjoint stored value is greatly facilitated. The database server 116 generally retains information substantially within a database 142 which is preferably an object-oriented or relational database. In a generally preferred embodiment, the database server 116 is an AS / 400 computer running a DB / 2 database server software obtainable from IBM Corporation of Armonk, New York. In other exemplary embodiments, database 142 is implemented using an SQL server (obtainable from Microsoft Corporation of Redmond, Washington), an ORACLE database server (obtainable from Oracle Corporation of Redwood Shores, California). ) or an ADAPTIVE server (obtainable from Sybase Corporation of Emeryville, California) that runs in any form of computer hardware. In a preferred embodiment, database 142 is separated into several logical subsystems by generally identifying particular classes of objects. Object classes, usually include,. in ter alia, functions and attributes. "Functions" corresponds to operations formed by objects of the particular class. "Attributes" corresponds to characteristics that exhibit objects of that class. For example, a "smart card" class usually contains functions to create new cards and add value to existing cards, as well as attributes that identify cardholders and accounts. The subsystem classes as shown in Figure 7, then, generally contain objects that perform related functions and / or retain related information. The database 142 preferably contains a "key" field that divides the database according to a class of high level objects. An example of a "key" field is class 188 of "business unit" shown in Figure 8. In the exemplary mode shown in Figure 8, class 188 of "business unit" organizes the database into divisions which correspond to, for example, a company organizational structure. Alternative embodiments of the invention organize the database 142 in radically different ways using different key fields. For example, the key can be used to logically separate the database 142 according to geographical region (for example "North America", "Europe" and "Asia") or according to product classes (for example "smart cards", "ATM cards", "Internet account", and the like), or in accordance with any other appropriate differentiated. The key object class 188 substantially defines many of the implicit values for several dependent classes because the objects that depend on the key object class 188 generally inherit substantially all of the defined attributes and functions of the parent class. In a modality that uses "business unit" as key class 188, for example, all database objects that reside in the same business unit generally share common currencies, languages, product details, address masks, and similar implicit . Despite the particular key field 188 selected, in the preferred embodiments, the key field 188 logically separates the objects contained in the database 142. Objects with different "key" values 188 are preferably separated by software "firewalls" or hardware that divide the database 142 based on the key. A firewall is any mechanism that prevents access through a logical limit. Although the firewalls are preferably implemented as software access controls, alternative modes include schemes of user identification / passwords or hardware controls such as access restrictions implemented by the router.5 Alternatively, multiple firewall techniques such as remote control controls are combined. Physical access and software controls Firewalls generally retain the autonomy of the business unit and the integrity of the data by isolating the data according to, for example, the key field. In a preferred embodiment, secondary classes 186 that depend on the key class 188 are created to substantially define programs with individual stored value. Each of these secondary classes 186 usually depends on the class 188 key. Alternatively, the intermediate classes (corresponding to the geographical region, business subunits, or another suitable form of differentiator) exist between the higher level key class 188 and the "product" class 186. In the modality shown in Figure 8, the secondary object class 186 differentiates several products belonging to the same key class 188. Objects that belong to the secondary "product" class 186 inherit attributes and functions from class 188 of the applicable "business unit" parent. 25 The exemplary mode shown in Figure 8 includes a "business unit" key 188 that separates database 142 in Business Unit One (BUI) 146 and Business Unit Two (BU2) 148. Objects BUI 146 and BU2 148 in Figure 8 are instances of class 188 of the "business unit" key, and elements 150, 152, 154, 156, and 158 are instances of a class 186 of secondary "product". In the example shown in Figure 8, the objects 150, 152, and 154 depend on the object BUI 146, and the objects 156 and 158 depend on the object BU2 148. Each of the objects 150, 152, 154, 156, and 158 of product represent a product with separate stored value as a particular smart card program, an ATM card program, ATM, or the like. For example, both the product object 150 and the product object 156 can define the smart card products, although these two objects depend on different business units, although the two kinds of "smart cards" are different from one another and each preferably contains local data, independent attribute functions, the two object classes of preference compact functions and attributes as will be described later. Still referring to Figure 8, the database 142 preferably includes an object repository 144 that generally functions as the object library. The objects held within the tank 144 properly perform various functions or retain particular data formats, as will be described later. These objects are used appropriately by the objects of key class 188 and secondary class 186, as well as any intermediate class (not shown). The objects contained in the deposit 144 generally provide a central functionality required by the different product objects 186. Because each product object 186 has access to the entire repository 144 of the central information, the objects stored in the repository 144 are effectively shared and the secondary objects 186 are reused by the different key objects 188, thereby giving as a result, a time of implementation and effort of programs are substantially reduced. On the other hand, many objects contained within the reservoir 144 suitably use other objects in the reservoir. The different modalities organize the different classes depending on the class 188 key in several ways. Although the deposit 144 is shown in Figure 8 as distinct from the objects belonging to the key class 188 and the secondary class 186, this distinction is a logical distinction made for the purposes of explanation only. For example, the database 142 may be organized hierarchically, sequentially or in any other suitable manner. The objects in database 142 preferably they are organized in a way that provides optimum performance while efficiently using the resources of (fl) hardware as a storage space and memory in the database server 116. The deposit 144 generally includes several groupings of objects (called "subsystems") which have similar attributes or perform similar functions. For example, any of the groupings presented here could be eliminated, or could be added to additional groupings On the other hand, different objects can be accommodated in a variety of subsystems. The different subsystems of an exemplary preferred embodiment of the repository 144 will be discussed below. Still referring to Figure 8, it is now will describe the different subsystems within the deposit 144. The bottom subsystem 158 within the deposit 144 generally includes objects that add value to the stored value cards, the background characteristics • are usually selected with the product classes relevant for the funds of many resources can be applied to many products with different stored value without requiring individualized programming for each product. For example, an "ATM account transfer" object defines a process for transferring money from the account of checks from a consumer to a card with stored value in response to the introduction of ATM consumer data. Once defined, this object of preference is used by multiple product objects, so that the same software code facilitates ATM transfer to smart cards, telephone cards, and other products with stored value. The fund subsystem of preference includes such features as delay of funds, introduction of funds by lot, application of fund shares, application of funds on a card or account level, or handling of suspended / withheld phones. The customer records of preference are maintained in a client data subsystem 172 which generally implements a single database record for each client although the client may use several products with stored value. The card data, account data, customer data, consumer data and the like generally reside within the subsystem 172 of customer demographics, which frequently communicates the objects of the product subsystem, funds, operations processing and addresses. described in the present. Additionally, many user interface elements such as screens and access controls are generally contained within the customer demographic subsystem. The objects associated with subsystem 168 of Merchant data generally allow for specific merchant processing options. Other objects of preference store contract information in relation to product offers from specific merchants, such as special offers or joint marketing efforts such as discounts, loyalty certificates, etc. Preferred merchant data subsystem 168 also includes accounts payable objects that allow merchants to capture stored value transactions for collection. The addresses (including, for example, customer billing addresses, merchant addresses and the like) are preferably contained in the address subsystem 160. The address subsystem 160 generally hosts address information and provides an interface with all the other subsystems that need address information, or as the client and merchant data subsystem 172 and 168, respectively. The address subsystem 160 suitably provides a single point to maintain substantially all address information stored in the database 142, and preferably supports multiple addresses for each person (e.g., Internet addresses, businesses and addresses, among others). ). Other objects in the address subsystem 160 of preference supports temporary addresses, optionally with an associated "effective date" so that shipping addresses, travel addresses, and the like can be supported. The operations processing subsystem 170 generally includes objects to store and manage non-financial and financial operations. Preferably, many objects associated with the operations processing subsystem 170 contain mechanisms for providing substantially real-time access to financial data by, for example, a customer service representative 134 as described above to solve the online operations questionnaires. . Preferably, the operations processing subsystem 170 can also be accessed by at least clients and merchants. Transactions are generally formatted by type (for example, airline, car rental, discount purchase, and the like) so that transaction records can be easily searched. Preferably, deposit 144 includes an expense management subsystem 176 that includes objects that implement various product-specific expense management rules. For example, spending management rules may allow certain cards to be used only at specific stores within a particular geographic region, or during a specific period of time.

Alternatively, the expense management subsystem 176 may also provide balance information available to the customers or to the external authorization system 108. Preferably, the expense management subsystem 176 includes objects that are configured to track cardholder, consumer card spending patterns to help determine the effectiveness of the product. The repository 144 preferably includes an input / output (I / O) management subsystem 174 that includes objects to channel the interface data to and from the database system 116. Preferably, the I / O annex subsystem 174 includes objects that track, manage and catalog the data sent and received by the database system 116. In a preferred embodiment, the I / O management subsystem 174 contains mechanisms for having real-time access to the database information that is used by, for example, clients and CSRs that need to have access to the operations processing subsystem 170. of data retention. The financial control subsystem 164 generally includes objects that are configured to substantially protect the financial integrity of the database system 116. Generally, the financial control subsystem 164 receives data from the external financial capture system 112, as does the fund system 158 maintain accurate account balance information. The financial control system 164 optionally includes objects that implement an interface for adjustments and disputes subsystem (not shown). The data that is compacted between the different objects and classes of preference is facilitated by a structure system 166 that suitably combines groups of cards, accounts or merchants into common classes. Structure subsystem 166 is established and maintains hierarchical relationships established by clients, societies, governments and the like, defining the data structures that correspond to these relationships. These data structures are used appropriately to group members of a particular hierarchy through several products with stored value. In a preferred embodiment, the subsystem 166 of structures suitably allows to see and report said classes according to the predefined hierarchies. By defining the different relationships in structures, several advantages can be presented over the treatment entities within the hierarchy individually. First, data structures facilitate easy movement, copying and transfer of information from one entity to another because only the data structure (and not each individual member) needs to be moved. Second, the structures can be modified in a way that each as a class, thereby reducing the need for changes to the individual objects that correspond to the members of the class. For example, if a data structure represents individuals belonging to a hierarchy (such as a company report structure) and the name of the hierarchy changes, the change only needs to be entered once (in the data structure object) and not in each object that corresponds to each member of the hierarchy. The database server 116 preferably includes a security subsystem 162 that includes objects to handle security controls through the database. Generally, users are assigned one of several levels of authority based on the user's need to obtain information. the security constraints of preference are implemented at many levels in the database 142, including at the class level 188 keys and the product class level 186. The objects in the security subsystem 162 generally implement the aforementioned firewalls. The objects of the output subsystem 178 generally provide control and formatting of output data from the database 142. In a preferred embodiment, the output information is administered by three separate optional subsystems corresponding to letters 180, reports 182 and states of output. account 184. In other modalities, a single Outlet 178 subsystem provides all outputs. The module 180 of preference cards contains objects to generate and produce letters such as, for example, automated letters, letters by events (for example, negative balances, collections, etc.), letters initiated by CSR (service, resolution of disputes, etc.). .) and legal notifications (change of clauses, legal provisions, etc.). The preference report module includes objects to form schedules, create and maintain all the reports in the database. In a preferred embodiment, the objects included in the report module 182 are interfaced with the external report generator 136 for a current report creation. Alternatively, the objects included in the report module 182 substantially prepare and format reports, thereby incorporating the functionality of the external report generator 136. Objects associated with module 184 of preference account statements create or format database account statements like all recurring accounts. The objects included in the subsystem 178, 180, 182 and 184 of generating output information preferably produce output information by means of a means that can be selected as a fax, paper, Internet or any other means of transmitting information. Referring now to Figure 9, products 186 with stored value are created using various objects of deposit 144. Generally speaking, users create new products according to a particular business unit 188 by selecting the appropriate objects of deposit 144 corresponding to those attributes and functionalities desired in new product 186. For example, a user can select, among others, an object to create a card, several objects to store value in an account associated with the card (or on the card itself), an object to handle financial transactions, and an object to generate reports to clients. When these objects are selected, the database server 116 suitably assembles a product structure that references the different objects requested. In a preferred embodiment, the product structures are indicator tables for the various objects in the repository 144, but any suitable method for organizing the different objects (such as in a data structure or in a database record) can be used. When the product executes, the database server 116 retrieves the particular objects requested. Because this method of constructing products substantially reuses the objects of a prewritten code, the design and implementation times are significantly reduced. The structures, materials, actions and corresponding equivalents of all the elements in the The following claims are intended to include any structure, material or actions to perform the functions in combination with other elements claimed as claimed specifically.

Claims (27)

1. CLAIMS 1. A system for managing a plurality of products with stored value, the system characterized in that it comprises: a database server comprising a database, the database comprises a plurality of objects so that at least one of the objects simultaneously is associated with one or more of the plurality of products with stored value; and a point of sale terminal in communication with the database server, the point of sale terminal receives the operation data of at least one of the products with stored value, and to provide the operation data to the server of database.
2. 2. The database server according to claim 1, characterized in that it further comprises an authorization server in communication with the database server and the point-of-sale terminal.
3. 3. The database server according to claim 2, characterized in that the point of sale terminal questions the authorization server to have operations approval.
4. 4. The database server according to claim 1, characterized in that it also comprises a plurality of clients, each client corresponds to one of the plurality of products with stored value, and each client is in communication with the database server.
5. 5. The system according to claim 4, characterized in that the client is implemented in a digital computer.
6. The system according to claim 1, characterized in that the plurality of objects comprises data structure objects.
7. 7. The system in accordance with the claim 1, characterized in that the plurality of objects comprises customer information that is available to each of the plurality of products with stored value.
8. The system according to claim 1, characterized in that the plurality of objects comprises merchant information that is available to each of the plurality of products with stored value.
9. The system according to claim 7, characterized in that the plurality of objects comprises merchant information that is available to each of the plurality of products with stored value.
10. 10. A database server for the plurality of products with stored value, the database server comprises a digital computer and a database, the database comprises: a key field that has attributes; a secondary field that has a plurality of instances, each instance inherits the attributes of the key field; and a deposit having a plurality of objects, each object provides a functionality and is associated with each of the plurality of instances.
11. 11. The database server according to claim 10, characterized in that the secondary field identifies one of the products with stored value.
12. The database server according to claim 10, characterized in that the plurality of objects comprises client information.
13. 13. The database server according to claim 12, characterized in that the customer information is accessible to each of the plurality of product with stored value.
14. 14. The database server according to claim 11, characterized in that the plurality of objects comprises client information.
15. 15. The database server according to claim 14, characterized in that the customer information is accessible to each of the plurality of products with stored value.
16. 16. The database server according to claim 10, characterized in that the plurality of objects comprises merchant information.
17. 17. The database server according to claim 14, characterized in that the merchant information can be accessible to each of the plurality of products with stored value.
18. 18. The database server according to claim 15, characterized in that the plurality of objects comprises merchant information.
19. 19. The database server according to claim 18, characterized in that the merchant information is accessible to each of the plurality of products with stored value.
20. A method for operating an operations server comprising the steps of: selecting a first plurality of objects from an object repository to form a first stored value program, the first stored value program corresponds to a first financial product; selecting a second plurality of objects from the object pool to form a second stored value program, the second stored value program corresponds to a second financial product; and provide a database on the server of operations, the database comprises consumer information and merchant information, wherein the first and second stored value programs interact with the database by means of the first and second plurality of objects, respectively, to implement the first and second financial product, respectively.
21. 21. The method according to the claim 20, characterized in that it also comprises the step of receiving an operation request from a point-of-sale terminal, the operation request corresponds to one of the financial products.
22. 22. The method of compliance with the claim 21, characterized in that it also comprises the step of determining a financial product that corresponds to the operation request in the operations server.
23. 23. The method according to the claim 22, characterized in that it also comprises the step of processing the operation request according to the first plurality of objects if the operation request corresponds to the first financial product.
24. 24. The method of compliance with the claim 23, characterized in that it also comprises the step of processing the operation request according to the second plurality of objects if the operation request corresponds to the second financial product.
25. 25. A system for managing a plurality of financial programs, the system characterized in that it comprises: a database server comprising a database, the database includes a plurality of such objects, so that at least one of the objects simultaneously it is associated with more than one of the plurality of stored value products, wherein each of the plurality of stored value products is affiliated with one of the plurality of financial products; and a point of sale terminal in communication with the database server, where the point of sale terminal is configured to receive operation data from at least one of the products with stored value and to provide operating data. to the database server.
26. 26. The system in accordance with the claim 25, characterized in that the plurality of objects comprises merchant information that is available to each of the plurality of products with stored value.
27. 27. The system in accordance with the claim 26, characterized in that the plurality of objects comprises consumer information that is available to each of the plurality of products with stored value.