MX2008000714A - - Google Patents

Description

SYSTEM AND METHOD FOR THE ESTABLISHMENT OF RULES THAT GOVERN SON ACCOUNTS Cross Reference to Related Requests This application has been submitted as a Request for International Patent of PCT on July 14, 2006, in the name of Gratis Card, Inc., a national corporation of the USA, applicant for the designation of all countries except the United States, and Jason Jude Hogg and Patrick Graf, both citizens Americans, applicants for designation only from the United States, and claims priority to the EUA Application Series No. 60 / 700,049 filed on July 15, 2005.

Technical Field The present invention relates generally to the field of financial transaction and data systems, and more particularly to a system and method for executing financial and data transactions through an open network.

BACKGROUND Figure 1 illustrates a typical credit card transaction, as it is currently performed. As shown in Figure 1, the process begins with a credit card holder 100 who provides his credit card to an assistant located in a point-of-sale device (e.g., a cash register) within a merchant establishment 102 , as presented by step 101. In response, the assistant typically "slides" the card through a magnetic stripe reader that is coupled to the point of sale device. In this way, the information of the cardholder, including the name of the cardholder and the credit card number, is transferred from the storage medium on the card to the point of sale device. The point-of-sale device combines the information of the cardholder with transaction information, (including the total price of the sale and identification of the merchant), and sends the combined data group to an acquisition or third-party processor. , as represented by the operation 103. The third-party processor 104 responds by sending the data group to the transaction network owned by the card association (for example, Visa, American Express, etc.) 106 (operation 105) , so that the data group is directed to the issuing bank 108, as shown in step 107. After receiving the data set, the issuing bank 108 checks the proposed financial transaction against a set of credit rules and either approves or denies the financial transaction. If approved, the approval crosses the identical path, in reverse sequence (operations 109, 111 and 113) to reach the point of sale device at the location of the merchant 102. Then, the card issuing bank 108 sends an equal monetary amount. at the sale price to the merchant bank 110 through a similarly complex group of data transactions, as represented by step 115 (typically, a processor is used as an intermediary that sends the monetary amount to merchant bank 110). At the end of the billing period, the credit card holder 100 pays the sales price (plus interest and finance charges) to the card issuing bank 108 (operation 17). The aforementioned scheme exhibits certain disadvantages. For example, by virtue of using an owner network to communicate data between the merchant 102 and the authorization entity (the card issuing bank 108, in this case), the expense is incurred in the establishment and maintenance of that network. This expense is finally borne by the merchant 102. Another disadvantage of using an owner network is that relatively small amounts of data can be transmitted from the merchant's point-of-sale device, due to infrastructure and cost limitations. This means that, for example, the cardholder can not be presented with detailed information regarding a transaction given in this monthly statement. In certain circumstances, existing credit card technologies provide occasional inclusion of information regarding the content of a given transaction. However, such information does not meet at a point in time that is contemporary with the execution of the transaction. Rather, it meets well after the execution of the transaction. Given this delay in data collection, certain advances presented here today are not possible in the context of existing credit card technologies.

Other disadvantages are also inherent in the aforementioned scheme. Personally identifiable information is typically both printed and highlighted on the credit card and encoded on its magnetic stripe. This requires a delay between the point in time at which a credit card applicant is approved for a credit card and the point in time at which the applicant can receive the credit card (the applicant's personal information is printed and coded on the card in the intervention period). In addition, since the storage mechanism used by credit cards is a magnetic stripe, a magnetic stripe reader must be connected to the point-of-sale device. This generates an additional expense, which tends to discourage small businesses from accepting such credit cards. In addition, there is currently preparing to introduce a radio frequency identification (RFID) device in credit cards. This initiative also involves an important infrastructure investment, which, again, tends to discourage small businesses to accept such credit cards.

Brief Description of the Invention According to one embodiment, a computerized method may include associating, in a database, a first transaction card through which access to monetary funds is extended with a second transaction card through the which extends access to these monetary funds. Also, in said database, said second transaction card is associated with one or more rules that govern access to the monetary funds through said second transaction card. Finally, an individual who has said first transaction card can specify those rules that govern access to the monetary funds by the second transaction card. According to another embodiment, a system includes a first transaction card through which access to monetary funds is extended and a second transaction card through which access to said monetary funds is extended. The system also includes a database in which the first transaction card is associated with the second transaction card, and wherein the second transaction card is associated with one or more rules governing access to the monetary funds for said second. transaction card. In addition, the system includes a computer system programmed to allow an individual who has the first transaction card to specify those rules that govern access to the monetary funds by the second transaction card. According to another embodiment, a computerized method includes assigning a first card number to a first transaction card through which access to monetary funds is extended. The method also includes assigning a second card number to a second transaction card through which access to money funds is extended, wherein the second card number is different from the first card number. Finally, in a database, the first transaction card is associated with the second transaction card, so that the monetary funds accessed through the second transaction card are the same monetary funds as those issued through the first transaction card. According to another embodiment, a system includes a first transaction card through which access to money funds is extended, said first transaction card having a storage means that encodes a first number that individually identifies said first transaction card. The system also includes a second transaction card through which access to monetary funds is extended, the second transaction card having a storage medium that encodes a second number that individually identifies said second transaction card. Finally, the system includes a database associating the first transaction card with the second transaction card, so that said monetary funds are accessed through the second transaction card and are the same monetary funds as those accessed through the first transaction card.

Brief Description of the Drawings Figure 1 illustrates a typical credit card transaction.

Figure 2 illustrates a credit card transaction, according to one embodiment of the present invention. Figure 3 illustrates a method by which a transaction card can be activated almost simultaneously with the point in time at which an application associated with it was approved.

Figure 4 illustrates an illustrative network environment in which the core of Figure 5 can be displayed. Figure 5 illustrates an illustrative embodiment of a core that can be displayed in the illustrative network mode of Figure 4. Figure 6 illustrates an illustrative mode of a message communicated from the core of Figure 5 to the software system of Figure 7 Figure 7 illustrates an illustrative embodiment of a software system that can be executed by one or more servers operated through a transaction platform. Figure 8 illustrates an illustrative embodiment of a scheme implemented by the database of Figure 7. Figure 9 illustrates illustrative mode of a message communicated from the software system of Figure 7 to the core of Figure 5. Figure 10 shows an illustrative embodiment of a message communicated from the core of Figure 5 to the software system of Figure 7. Figure 11 illustrates an illustrative embodiment of a method for rewarding a credit card holder for distributing anonymous cards, not assigned to prospective applicants. Figure 12 shows an illustrative embodiment of a method for allowing a cost associated with an article to be disputed within a transaction. Figure 13 shows an illustrative embodiment of a method for establishing or changing rules governing the use of a child card. Figure 14 illustrates an illustrative embodiment of a method for establishing or changing fraud detection rules selectable by the user. Figure 15 shows an illustrative embodiment of a method for establishing or changing algorithmic PIN modification rules selectable by the user. Figure 16 shows an illustrative modality of a scheme to allow exchange of goods between merchants. Figure 17 shows an illustrative modality of a person-to-person exchange of funds. Figure 18 shows another illustrative modality of a person-to-person exchange of funds.

Detailed Description Various embodiments presented herein will be described in detail with reference to the drawings, in which like reference numbers represent similar parts and assemblies across the various views. The reference to the various modalities should not be construed as limiting the scope of the subject matter covered, which is limited only by the scope of the appended claims thereto. In addition, any group of examples established in this specification is not intended to be limiting and merely establishes some of the many possible modalities. Figure 2 illustrates a financial transaction, for example, credit card transaction, debit card transaction, stored value card transaction, pre-paid card transaction, etc., according to one embodiment of the present invention . As shown in Figure 2, a cardholder 200 initiates the transaction by presenting a credit card to a point of sale device 202 or to a merchant operating said device 202 (operation 201). Of course, the transaction can be initiated in the course of an ordinary online transaction, such as by virtue of the entry of cardholder information on a website designated for online commerce. By illustration only, the transaction as described with reference to the Figures herein is described as occurring in a point-of-sale device (in a merchant store) handled by an attendant. As well, the card can be referred to here as a "credit card", "card", or "transaction card" to make a family reference. Actually, as discussed below, the card can operate as a credit card, a debit card, a stored value card and / or a data access card that allows access to various forms of data, such as health care data, data of a club membership, etc. The card can exhibit the following characteristics. The same card may include a substrate (i.e., the card body), which may be polymeric or of any suitable material. A storage medium can be arranged, embedded inside and / or printed on the substrate. The storage medium can be read-only, such as a barcode printed on the substrate, or it can be readable and writable, such as a magnetic storage medium (e.g., magnetic stripe). According to some modalities, the credit card can have both a bar code and a magnetic band in it. According to some embodiments, a card number that uniquely identifies the card is encoded in the magnetic stripe and / or in the bar code. Also, the credit card may include an RFID device having a card number stored therein. According to one embodiment, the storage medium, whether it is a bar code, a magnetic stripe, or an RFID device, contains, encodes and / or stores any personal information with respect to the cardholder. According to some modalities, the storage medium (s) on the card encodes, contains and / or stores only a card number only identifying the card. According to some modalities, the storage medium (s) of the card does not contain, codify and / or store any personal identification number (PIN). After receiving the card, the assistant provides the card to an input device, such as a bar code reader device, magnetic stripe reader, or RFID transceiver. The information encoded in the storage medium of the credit card is then read. Then, the cardholder can be prompted for a personal identification number (PIN), which can be entered into the point-of-sale device, either by the cardholder or by the assistant through a device appropriate input, such as a keyboard, numeric keypad, touch screen presentation, and / or any suitable device for PIN input. The credit card data, the PIN, and the transaction information of the point of sale device are used to fill a plurality of data packets, which can be "packaged" as an individual unit that constitutes an application for the authorization of a proposed transaction. The various packages are discussed in more detail later. The packaged unit is cryptically encoded according to a scheme generally described below, and is transmitted through an open network, such as the Internet, to the transaction platform 204, as shown in step 203.

As described in more detail herein, the transaction platform 204 can maintain a degree of integration with the issuing bank of the card, in order to be able to authorize or deny all, almost all or some of the transactions (for example, transactions less than a dollar threshold amount), without needing additional communication with the issuing bank of the card to obtain an authorization decision. After the arrival of an authorization or denial decision, the authorization / denial is returned through the open network (for example, the Internet) to assistant 202, as shown in step 205. The modalities described above exhibit certain advantages that are to be observed, but are not essential for the practice of the various modalities described here. For example, communication between the assistant 202 and the transaction platform 204 occurs through an open network, such as the Internet. By making use of an open network, the need for proprietary network elements and / or lines is eliminated and / or reduced, meaning that the execution cost of each transaction is reduced. Also, since communication through an open network, such as the Internet is free of charge, a relatively larger amount of data can be exchanged between the merchant 202 and the transaction platform 204, allowing a higher resolution in declarations of billing, as described below. In addition, the administration of bank rules as defined by a side, such as available credit, interest charges and rights are managed by the platform reducing the need for constant communication between the information association 202 and the various issuing banks of the card. 206, which is conducted through consolidation / synchronization of programmed system, which can also be conducted through the open network, thus obtaining the same benefits. It should also be noted that, in some modalities, the credit card does not contain personal information. Specifically, no personal information is printed, recorded, or otherwise presented on the face of the card (for example, the face does not bear the name of the cardholder), nor does it have personal information encoded therein, stored inside it. of the same or contained in the storage medium on the card. This arrangement allows the almost instantaneous placement of an activated transaction card in the hands of a possible cardholder. For example, as shown in Figure 3, a supply of anonymous, unassigned cards can be provided, for example, in a point of sale device in a merchant store (operation 300). By "anonymous", it is meant to imply that the card does not contain, or code, and / or store any information that identifies an individual to whom the card belongs. In other words, it does not bear the name of an individual on its surface, nor does it have the name or other identifying information regarding an individual stored or encoded in the card's storage medium. The storage medium of the card may contain only a card number that only identifies the card, not the account number. As shown in step 302, an anonymous card is distributed to an applicant. This can happen, for example, at a point in time where a customer is close to making a transaction of a purchase of a good or service. Assuming that a source of anonymous, unassigned cards is kept in a point-of-sale device, an assistant there can ask a customer if they want to request a credit card or open a pre-paid / stored value card. If the client responds in the affirmative, then the assistant can supply a card to the client. Of course, an applicant could obtain an anonymous card from any source, including friends or other cardholders (discussed later). Then, the server of the transaction platform (discussed in more detail below) is provided with the applicant's request information and the card number that uniquely identifies the card (operation 304). Assuming once the anonymous card is distributed to a customer in a point-of-sale device, the customer's request information can be entered by the assistant in the point-of-sale device, so it is communicated through a network, such as the Internet or telephone network, to the server of the transaction platform. In addition, the request information can be received by an employee of the transaction platform (for example, through a telephone call with the applicant), and can be entered into the server through the employee (or can be entered in a computer in communication with the server). Furthermore, the applicant can be directed to a web page or a kiosk in the warehouse (for example, the card can carry the web address of a web page) that is structured to allow the entry of request information. The applicant can directly enter his request information on the web page, thus communicating his request information to the server. In general, the request information can be received by the server in any way. The same application information may include the information typically necessary to conduct a credit check, in order to determine the creditworthiness of an individual. For example, such information may include identification information, such as the name, address, telephone number, and / or social security number of the applicant, and may also include information about employment such as place of employment, number of years worked in said place, etc. The request information may constitute a minimum group of information necessary for the server to properly handle financial transactions for the applicant. According to some modalities, the server has access to a database that can store a wide variety of information regarding the applicant. Such information may include health information, emergency contact information, family information, etc., (these other forms of information are discussed below). At the time the application information is received, the other above-mentioned forms of information may not be received by the server of the transaction platform. In this way, the server uses the request information to fill one or more tables in the aforementioned database in relation to the request of the requester, and also fills out in a minimal form other tables in relation to the requester and other subjects. If the application is finally approved, other types of information from the applicant / cardholder can be collected in a later time, and the various tables in the database can be filled out completely. After receiving the request information, the server enters information in the database to associate the applicant's card number with the applicant's request information (operation 306). Then, an evaluation of the request is made (operation 308). According to some modalities, a credit check can be performed on the applicant. The request information may include a sufficient amount of information to consult a credit rating service (e.g., Fair Issaac Co.) to obtain a credit rating for the individual (e.g., FICO classification). For example, the information association server may communicate, through a network such as the Internet, with a credit rating service to determine the credit rating associated with the individual.

If the credit rating exceeds a particular threshold, then the application is approved, otherwise it is denied. According to other modalities, the request information of the applicant is communicated through a network such as the Internet, to one or more banks issuing the card. Each bank issuing the card individually uses the request information to conduct its own analysis and independently conclude if it denies or approves the request. According to some modalities, the transaction platform server compares the credit terms offered by the issuing card banks that approve, and selects the card issuing bank that offers the best credit terms as the bank associated with the card number. . According to other modalities, each card issuing bank can communicate a proposal, for example, a monetary amount willing to pay in the transaction platform to acquire the account, and the transaction platform can select the bank that offers the highest proposal. , for example. According to other modalities, more than one bank may be associated with the card number, and the future cardholder / applicant may select from among the banks for the extension of credit, with each purchase. Regardless of how the analysis is conducted, if the evaluation indicates that the request was approved, then the server enters information in the database to associate rules with the applicant's card, as shown in step 310. For example, a limit spent determined based on the credit rating can be associated with the card (or, the issuing bank of the card can determine the limit and communicate the limit to the bank of the transaction platform), you can also associate generic anti-fraud data with the card, etc. (operation 312). Then, the card can be activated (operation 314), meaning that the card can be used to execute a transaction, for example, it can be used to buy a good or service on credit (or, as discussed below, can be used). in another form, such as to be a transaction of a purchase such as a debit card, stored value card, etc.). To facilitate the execution of a transaction, the PIN assigned to the transaction card is communicated to the approved applicant. For example, the PIN can be communicated to the cardholder through a short message service message, through an email received by a wireless device or other device, through the point of sale device, etc. This PIN can be either a permanent PIN, or it can be active only for a particular period of time, for a particular number of uses, or together with a transaction that has a monetary value less than a particular amount. On the other hand, if operation 310 indicates that the request has been denied, then the card is not activated (316), meaning that the card can not be used to execute a transaction. Operations 300-314 can be performed almost instantaneously. For example, according to some modalities, operations 300-314 can be performed in less than one minute, and according to other modalities said operations can be performed in less than 30, 15 and / or 5 seconds. For example, an applicant may request a card while initiating a purchase at a point-of-sale device in a merchant store, and may actually have the card activated, so that the applicant can use the card for the transaction of that purchase ( and other purchases at other stores, too). Since the card is anonymous, there is no need for the card to carry the identification of the cardholder, nor is there a need for the card storage means to have said identification information or PIN encoded therein. In this way, after the application process, there is no waiting period for the card to be printed on or for the means of storing it to be encoded with information that identifies the applicant. As described with reference to Figure 2, in order to make the transaction of a purchase using the transaction card described herein, a point-of-sale device (e.g., cash register) can read a given card, and can communicate the information to through a network open to the transaction platform server. Figure 4 shows an illustrative network environment, where the point of sale device 202 of Figure 2 can reside. As seen in Figure 4, a given merchant store may have a plurality of point of sale devices 202 located there. Each point of sale device 202 may be coupled to a local area network (LAN) 400. The LAN of Figure 4 is illustrated as being an Ethernet network, by illustration only. The LAN 400 can be of any structure and use any protocol. The various point of sale devices 202 communicate with a server 402 via LAN 400. The server 402 maintains a database 404 that stores information regarding all transactions conducted through each of the point devices. of sale 202. (Typically, each transaction is identified by a transaction identifier, as discussed further below). The server 402 can transfer information to / from an open network 408, such as the Internet, through a router 406. The network environment of Figure 4 is illustrative, and is presented by illustration only. Many other environments exist and are known to those skilled in the art. Figure 5 illustrates a transaction core that is deployed, i.e., the various software units are stored and executed in either either the point of sale devices 202, the server 402, some combination of the two, and / or any computing device in communication with any of the point of sale devices and / or server 402. Here, the core of Figure 5 is discussed based on the assumption that it is deployed in the network environment of Figure 4. , but their modules are adaptable to be used in any network environment, as understood by any expert in the art. Returning to Figure 5, the point of sale device 202 is coupled to an input device 500, such as a magnetic stripe or a bar code reader, or an RFID transceiver. During the transaction of a purchase, the magnetic stripe reader 500 is used to read the magnetic stripe on the card. Of course, if the storage medium of the card is a bar code, then the input device 500 can be modalized as a barcode scanner. Similarly, if the storage medium of the card is an RFID integrated circuit, then the input device 500 can be modalized as an RFID transceiver. When the input device 500 reads the storage medium of the card, a card number is read only identifying the card. The input device 500 may also include a numeric keypad, which can be used by the cardholder to enter a personal identification number (PIN). The PIN code and the card number are communicated from the input device 500 to the point of sale device 202. A point of sale device 202 has the structure of a general purpose computing device. In other words, the point-of-sale device 202 includes the components typically found in a general-purpose computer, that is, it includes a processor that is coupled to one or more memory stages that store software and data. The processor communicates, through a common input / output (I / O) conductor with several input devices, output, and communication, including a presentation, such as a monitor, and can communicate with a keyboard, a mouse or other pointing device, such as a touch pad, and / or speakers, to name a few of these devices. Various peripheral devices can also communicate with the processor through the common 1/0 driver, including a network interface card, a hard disk drive, or other massive data storage device, removable media drives, such as a CD-ROM drive or a DVD drive (which can be both readable and writable), a wireless interface, a magnetic stripe reader, a barcode reader, an RFID transceiver, etc. It is understood that computers currently employ many integrated circuit groups and architectures. The point of sale device 202 broadly represents all of these groups and integrated circuit architectures, and the various core modes and the various software methods described herein can be executed in all of these groups of integrated circuit architectures. A PIN code and a card number extractor module 502 may be resident in the memory of the exit point device 202 or any other device in communication therewith and / or networked thereto, and executed by its processor. By "module" is meant a unit or portion of software, such as a function, object, group of functions and / or objects, and / or a group of computer instructions (e.g., machine code) that is they can be executed by the processor of the point of sale device 202. Of course, the functionality provided by a module can also be used by the cooperative efforts of one or more specific application integrated circuits (ASICs), or by cooperative efforts of one or more ASICs and software modules stored in a device memory and executed by a processor. After the input device 500 communicates the PIN code and the card number to the point of sale device 202, the extractor module 502 reads the card number and the PIN code of the data group communicated from the input device. 500 to the point of sale device 202. As discussed below, the extractor module 502 communicates the PIN code and the card number information to other software modules and can, according to some modalities, be stored and executed by the server 402. The point of sale device 202 communicates with a database 404 which is handled by the server 402. An application inferium (API) 504 is provided to allow the point of sale device 202 to interact with the database 404. According to some modalities, the database 404 is organized according to a scheme that includes a plurality of structured tables for storing information with respect cto items that have been sold in the store. The 404 database can store other information as well. For example, if the particular merchant operates many stores, the 404 database may store information regarding items that have been sold in all merchant stores, or all merchant stores within a region. In addition, the 404 database can store information in relation to a merchandise inventory, supplier information, and other useful information to operate the particular business. As the network structure of Figure 4, the scheme of the database 404 varies from merchant to merchant and may vary from store to store, as understood by one skilled in the art. Although the scheme used by the 404 database may vary from merchant to merchant, it is customary for the database to include a table that stores records describing the details of each transaction. Said table is described herein as a "transaction table" 506. A transaction table 506 is typically organized to uniquely identify each transaction with a transaction identifier 508., i.e., transaction identifier 508 may be the primary key for transaction table 506. A plurality of fields 510 may be associated with each transaction identifier 508. These fields 510 provide storage of information with respect to each item included in the transaction. For example, the fields may include one or more of the following: (1) a Matter Maintenance Unit (SKU) number of each item included in a transaction; (2) the price of each item included in the transaction; (3) an internal description of each item included in the transaction; (4) an external description of each item included in the transaction; (5) a general description for each item included in the transaction; (6) a category in which each item included in the transaction, enters; (7) the sales tax associated with each item included in the transaction; (8) the date on which the transaction occurred; (9) the time at which the transaction occurred; (10) an identifier that indicates the particular store where the transaction occurred; (11) an identifier indicating the particular point-of-sale device in which the transaction occurred; (12) an identifier indicating the employee who operates the particular point-of-sale device at the date and time of the transaction; (13) an indication of the payment method used to make the transaction of a particular transaction, for example, cash, credit card, etc .; (14) the total price of the transaction; (15) an indicator of the type of transaction, for example, purchase, refund, return, data investigation, etc .; and / or (16) any other information that describes the issues and / or circumstances of the transaction. The information usually of the variety only presents, that is, the information that goes beyond the total price, the date, the time, and / or the location (for example, identification of the merchant and city / state) of the transaction, denominated as "data of three levels".

After a point of sale device 202 has scanned each item involved in a transaction, a payment technique can be selected. The point of sale device 202 can present a screen that ascertains the type of transaction that will be executed through the transaction card, for example, if the card to be used is a credit card, a debit card, and / or a stored value card (as previously mentioned, the transaction card can be used as a credit card in the context of a transaction, such as a debit card in another transaction, and as a value card stored in a transaction. the context of another transaction more). The point of sale device 202 uses API 504 to create a new transaction identifier 508 to only reference the transaction that is being executed. The type of transaction and the data of three levels with respect to the transaction can then be stored in the transaction table 506 together with the transaction identifier 508. According to some modalities the PIN and the 502 card number extractor also they capture the type of transaction, and deliver the transaction type data to the second cryptic encoding module 522, as described below. A monitor module 512 interacts with the API 504 to observe the creation of a new transaction identifier 508 within the transaction table 506. After observation of the creation of a new transaction identifier 508, the monitor module 512 calls the data extraction module 514 to start its operation. According to some embodiments, the data extraction module 514 interacts with the API 504 to extract data from three levels, including the transaction identifier, associated with the new transaction. According to other embodiments, the data extraction module 514 interacts with the API 504 to extract less than a full degree of the data from three levels. For example, the data extraction module 514 can obtain only the transaction identifier and the total transaction price of the database 404. By illustration only, this document describes the data extraction module 514 as obtaining the degree complete of the data from three levels of the database 404. To allow the data extraction module 514 to obtain data from the database 404, at the time of installation of the core illustrated in Figure 5, the module Data extraction is provided with information allowing said extraction. For example, the code and / or data space of the data extraction module 514 can be altered in view of the name of the transaction table 506, and the names of the various fields 510 in it from which the data is captured. data. As the data extraction module 514 captures the data of three levels, it is introduced into a memory region 516 to be transferred to a first cryptic encoding module 520. Before the transfer of the first cryptic encoding module 520, a module Proficiency 518 examines the captured data and interacts with the PIN and 502 card number extractor to ensure that: (1) the data extraction module has captured at least a total price and a transaction identifier; and (2) the PIN and card number extractor 502 has captured the card number and PIN. If the aforementioned data has not been captured, an error is indicated, and the kernel operation vis-à-vis the transaction is hidden. If, on the other hand, the aforementioned data has been captured, then the data stored in the memory 516 is passed to the first cryptic encoding unit 520. The first cryptic encoding unit 520 cryptically encodes the data of three levels and the data of transaction type (the transaction type data is received from the PIN and the 502 card number extractor, as shown in Figure 5) using the PIN captured by the PIN and card number extractor 502 as the cryptic encoding key, thereby creating a first cryptically encoded object 600. The first cryptically encoded object 600 is illustrated in the Figure 6. The first cryptically encoded object 600 is passed from the first cryptic encoding module 520 to the second cryptic encoding module 522. The second cryptic encoding module 522 receives the first cryptically encoded object 600 and appends the card number thereto, creating a group of appended data. (The card number is received from the PIN and 502 card number extractor, as shown in Figure 5). Then, a merchant password is used as a key to cryptically encode the group of appended data, thereby obtaining a second cryptically encoded object 602. The second cryptically encoded object 602 is illustrated in Figure 6. The second object cryptically encoded 602 is it passes from the second cryptic encoding module 522 to the third cryptic encoding module 524. According to some embodiments, the merchant password is a value of 64, 128, 256, 512-bits, or a value of another appropriate length to protect the second object cryptically encoded 602 to be cryptically decoded by an intruder, when it is transmitted through an open network. The merchant password typically remains a secret known only to a selected group of employees needed in the merchant and the transaction platform. According to some embodiments, the merchant password is entered into the code and / or kernel data space at the time of kernel installation on the merchant server 402. The third cryptic encoding module 524 receives the second cryptically encoded object 600 and attaches a merchant identifier, a store identifier, and a point of sale device identifier thereto, thereby creating a group of appended data. The merchant identifier is a value that uniquely identifies the merchant (for example, a value that indicates that the transaction occurred in a Target store). The warehouse identifier is a value that only indicates the particular store in which the transaction was made (for example, a value that indicates in which Target store the transaction is occurring). The point of sale device identifier is a value that uniquely identifies the particular point of sale device 202 in which the transaction is occurring (for example, a value indicating in which cash register the transaction is occurring). The merchant identifier, a storage identifier, and a point of sale device identifier are obtained from the 404 database, through the API 504. According to some modalities, at the time of the installation of the kernel Figure 5 on a commodity server 402, the name of the table (s) and fields within the database 404 containing said information are entered into the third cryptic encoding module 524 (eg, entered into the space of code and / or data of the third cryptic encoding module 524), so that it can interact with the API 504 to obtain said information. The third cryptic encoding module 524 then cryptically encodes the group of data appended with a public key associated with the transaction platform 204, producing the transport object 604. The transport object 604 is illustrated in Figure 6. According to some embodiments, the public key has a value of 64, 128, 256 or 512-bits, or a value of another appropriate length to protect the transport object 604 from being cryptically decoded by an intruder, when it is transmitted through an open network . The transport object 604 is passed to a secure socket layer (SSL) module 526, together with a cryptic SSL encryption key for use by the SSL module 526. According to some embodiments, the aforementioned cryptic SSL encryption key is generated by a random number generator, and the public key can be directly hard coded in the third cryptic encoding module 524. The SSL module 526 receives the transport data object 604 and uses the cryptic SSL encryption key to cryptically encode the transport object, producing a cryptically encrypted transport object 606. The cryptically encrypted transport object 606 is illustrated in Figure 6. Although Figure 5 illustrates the cryptic SSL encryption key as being generated by a random number generator in the third cryptic encoding module 524, according to other embodiments, the SSL cryptic encryption key can be generated by the SSL 526 module. The SSL 526 layer passes the transport object cryptically encoded to the transmission control protocol / internet protocol (TCP / IP) module 528 to communicate through the open network 408 to the server of the transaction platform. (In accordance with the illustrative network environment of Figure 4, the transport object is communicated as one or more packets routed through the router 406 to the open network 408). An illustrative embodiment of a software system running on the server of the transaction platform is illustrated in Figure 7. The transaction platform server is structured so as to include at least similar elements such as a computing device of purpose. general. In other words, the server of the transaction platform includes the components typically found in a general-purpose computer, that is, it includes a processor that is coupled to one or more memory stages that store software and data. The processor communicates, through a common input / output (I / O) conductor, with various input, output, and communication devices, including a presentation, such as a monitor, and can communicate with a keyboard, a mouse or other pointing device, such as a touch pad, and / or speakers, to name a few of these devices. Several peripheral devices can also communicate with the processor through the common I / O driver, including a network interface card, a hard disk drive, or other massive data storage device, removable media drives such as a drive. CD-ROM and a DVD drive (which can be readable or writable), a wireless interface, a magnetic stripe reader, a barcode reader, an RFID transceiver, etc. It is understood that servers currently employ many groups and integrated circuit architectures. Through this document, the server of the transaction platform is called singular, that is, as thinking that it is a singular machine. Of course, the server can actually be composed of a plurality of servers that cooperate to perform the functionality described here. For example, two or more servers individually can perform all the functionality described here, and can handle clients (ie, several transaction cores installed in several sites), as assigned by a load balancer. Also, two or more servers may cooperate in the sense that a first server may perform a subset of operations described herein, and may communicate with a second server performing another subset of the operations described herein. The description of the functionality of Figure 7 is provided with reference to a credit transaction, by illustration only. As described here below, the same infrastructure can be used to process debit transactions, stored value transactions, data access transactions, and combinations thereof. The software system of Figure 7 includes a TCP / IP 700 module that receives one or more packets, the combined payload from which the cryptically encrypted transport object 606 is formed. The TCP / IP 700 module reconstitutes the cryptically encoded transport object 606 from one or more packets, and passes the cryptically encrypted transport object 606 to the SSL 702 module. The SSL 702 module uses the cryptic SSL encryption key to cryptically decode the transport object cryptically encoded, producing the transport data object 604. (The SSL 702 module has access to the cryptic SSL encryption key under the negotiation that initiated the secured SSL session, as understood by one skilled in the art). The transport data object 604 is then passed to the first cryptic decoding module 704. The first cryptic decoding module 704 has access to a database 706 via an API 708. The database 706 contains financial data of Each cardholder, and other data, as described in more detail later. According to some embodiments, the first cryptic decoding module 704 has access to the database 706 to obtain the private key of the transaction platform, and then cryptically decodes the transport object 604, producing the second object cryptically encoded 602 and the merchant identifier attached, storage identifier, and registration identifier. According to other embodiments, the first cryptic decoding module 704 has the aforementioned private key hard coded in its code space, or has access to the private key from a region of the memory. In any case, the second cryptic encoded object 602 and the attached merchant identifier, storage identifier, and registration identifier are passed to the second cryptic decoding module 710. The second cryptic decoding module 710 also has access to the base. data 706 through API 708. The second cryptic decoding module 710 uses the merchant identifier which is passed to it from the first cryptic decoding module 704 to obtain the merchant's password. For example, the merchant identifier can be used as a key to access a table in the database 706 to find the merchant's password. In this manner, the second cryptic decoding module 710 may have access to a table that refers to the merchant identifier with the merchant password, and may use the merchant identifier as a key to obtain the merchant's password. The merchant password is then used to cryptically decode the second cryptically encoded object 602, producing the first cryptically encoded object 600 with the card number, merchant identifier, storage identifier, and registration identifier appended thereto. The first cryptically encoded object 600 and the aforementioned appended data are passed to the third cryptic decoding module 712. The third cryptic decoding module 712 receives the just mentioned data, includes the card number, and accesses to the database 706 through the API 708. The third cryptic decoding module 712 uses the card number to obtain the card identifier and a database PIN 706. The card number can be used as a key to access a table in relation to the card number with a card identifier and, either directly or indirectly, with the PIN. For example, the card number can be used to access a table that associates the card number with a card identifier and a PIN code identifier. After, using the PIN code identifier, you can have access to a table that relates the PIN code identifier to the PIN, in order to obtain the PIN. As one skilled in the art will understand, the PIN can be stored in a cryptically encoded format, so that it can not be misused. After recovery of the table where it is stored, the PIN is cryptically decoded, assuming that the requested task has an appropriate level of access to request such cryptic decoding. After receiving the PIN, the third cryptic decoding module 712 cryptically decodes the first cryptically encoded object 600, producing the data of three levels, along with the card number, merchant identifier, storage identifier, and registration identifier. (Of course, as discussed with reference to Figure 5, the payload of the first cryptically encoded object 600 may, in some cases, only include the total price and a transaction identifier).

The aforementioned data is passed to the balance verification module 714, which, like the various cryptic decoding modules 704, 710 and 712, has access to database 706 through API 708. First, the verification module balance 714 obtains the current balance and the credit limit associated with the card number of the database 706. For example, the balance check module 714 may have access to a table containing detailed card information related to a Card dentifier. Then, when using the card identifier, which was obtained by the third cryptic decoding module 712, as a key to find the current balance values and credit limit, they are obtained. The sum of the current balance and the total price of the proposed transaction is compared to the credit limit. If the sum exceeds the credit limit, the proposed transaction may be denied (discussed later). Otherwise, the process flow is passed to the fraud verification module 716. The fraud verification module 716 has access to the database 706 through the API 708. The fraud verification module 716 obtains rules of fraud. fraud indicator associated with the card number of the database 706. According to some modalities, some or all of the rules can be determined by the cardholder (this is discussed below). Also, some or all of the rules may be system rules that are generated without entry by the cardholder. The parameters of the proposed transaction and recent transactions can be compared with the fraud indicator rules. If one of the fraud indicator rules proves to be positive, the cardholder can be contacted. The cardholder can be contacted via telephone through an employee of the transaction platform (note that the contact information of the cardholder, including the cardholder's phone number is stored in an associated table) with the master account and a card identifier, as shown in Figure 8). The cardholder may be asked to confirm their identity (for example, the individual who answers the phone may be asked to identify themselves, and they may be asked for the PIN associated with the card number), and You are also asked to confirm that the transaction is legitimate. In addition, the cardholder can be contacted through the operation of a short message service (SMS) module 718. For example, the SMS 718 module can send an SMS message to the cardholder's cell phone (this number is stored in the database 706 in association with the card number), asking the cardholder to confirm that the proposed transaction must be approved. To allow the confirmed transaction to be approved, the cardholder must respond affirmatively, and must also enter their PIN code. The SMS 718 module receives the response message, and returns it to the fraud verification module 716. If the return message indicates that the proposed transaction will not be approved, then the proposed transaction is rejected (discussed below), and the card is frozen (also discussed later). If the return message indicates that the transaction is legitimate, and also contains the PIN associated with the card, the execution flow is passed to the profile verification module 720. The profile verification module 720 operates on child cards. A "child" card is a card that is associated with the same master account (discussed with reference to Figure 8) to which a parent card is associated. The effort of this association is that the parent card and any number of associated child cards carry the same funds, that is, carry the same line of credit, in the same stored value, in the same balance of pre-paid services or goods, and / or in the same checking or bank account. The cardholder associated with the parent card receives a statement presenting transactions from all accounts associated with the master account. Meaning that the cardholder of the parent card receives a statement presenting transactions executed through the parent card as of any of the child cards. The parent card can impose rules on the time permissions of the child card, as discussed in more detail later. For example, assume the circumstance where a parent card is a cardholder. The parent can create a child account to be used by their son or daughter. The invoice generated by the child account is presented in the invoice of the parent's account. The father can assign rules to the child's account. For example, the parent can associate a rule with the child account by allowing the child account to incur a debt of a selected level per selected unit of time (for example, $ 250 per month). Other rules include, without limitation: (1) deactivating purchases of certain SKUs or SKU classes (for example, not allowing purchases of SKUs indicating that the item purchased is alcohol); (2) not allow purchases that occur in certain businesses, types of businesses and / or trade categories; (3) allow only purchases that occur in certain businesses, types of businesses, and / or trade categories. Up to this point, according to some modalities, the database 706 stores one or more tables associating a type of commerce and / or category of commerce for the various merchant identifiers stored there. The profile verification module 720 operates by retrieving the rules (if any) associated with a card number, and testing the proposed transaction against the rules. If any of these rules is violated, the cardholder of the parent card can be contacted, as described with reference to fraud verification module 716, to allow the transaction. For example, the profile verification module 720 may operate having access to a table associating a card identifier of the child card (s) with the parent card controlling it. The profile verification module 720 can examine the table to determine if the card identifier (initially recovered by the third cryptic decoding unit 712) is presented there as corresponding to a parent card. If it is not there, the card is not a child card, and no rule imposed by a parent card is associated with it. Alternatively, if it is there, it is a child card, and may have rules associated with it. In such circumstance, the aforementioned table can associate the child card with a value that can be used as a key for another table that associates the aforementioned value with a pointer that points to the executable code that implements the rules selected for the card. The executable code is then executed to determine if any of the rules are violated, as described above. Either if the balance verification module 714, the fraud verification module 716, or the profile verification module 720 indicates that the transaction should not be allowed, then the control goes to the deny / freeze module 722. The module to deny / freeze 722 denies the transaction, and sends a message to the point-of-sale device indicating that the proposed transaction has been denied (details regarding the structure of said message back to the point-of-sale device are presented later ). In addition, if the fraud verification module 716 indicates that the purchase is fraudulent, then the account associated with the card is frozen, representing that no future transaction will be allowed until the card is re-activated. If each of the balance verification module 714, the fraud verification module 716, and the profile verification module indicate that the transaction should be allowed, then the control passes to the registration transaction module 724. The transaction module The registration data introduces the data retrieved by the three cryptic decoding modules 704, 710 and 712, including the data from three levels, to the database 706. For example, a transaction identifier, different from that assigned by the merchant, is assigned to the transaction. A new record is created, identified by the newly assigned transaction identifier in a table that relates details that relate to a transaction with a newly assigned transaction identifier. Then, the various fields of the new record are filled using the data retrieved by the three cryptic decoding modules 704, 710 and 712, including the three-level data. (The merchant's transaction identifier is also stored in the aforementioned table together with the newly assigned transaction identifier, thus preserving the association between the transaction identifier of the transaction platform and the merchant's transaction identifier). As previously mentioned, the point of sale device located in the merchant is notified of the denial / approval of the transaction. According to some embodiments, a structured message as shown in Figure 9 is transmitted through the SSL module 702 and the TCP / IP module 700 to the previously described kernel running on the merchant server 402. As shown in Figure 9, the message includes an indication of whether the proposed transaction was approved or denied 900, the transaction identifier 902 assigned by the merchant's database, and the merchant identifier, storage identifier. , and register identifier 904. If the message of Figure 9 is received by the TCP / IP module 528 of the core (Figure 5), it is passed to the SSL module 526, and there it is decoded cryptically. Your payment load is transferred to the recognition module 530, which uses the API 504 to update the 404 database with information regarding the approval or denial. (The indication 900 of whether the proposed transaction was approved or denied is associated with the transaction identifier 902 of the merchant, which is included within the message of Figure 9). According to some embodiments, at the time when the kernel is installed on the merchant server 402, the recognition module 530 is altered to include the appropriate table and field name for the entry of said information (for example, the code and / or data space of the recognition module 530 is altered to include the name of the table and field name of the appropriate location for the entry of said information). Then, the merchant identifier, storage identifier, and registration identifier 904 are used to determine how to direct the information regarding denial / approval to the appropriate point of sale device 202, and the transaction identifier is used to deny / Approve the appropriate transaction. As described in the previous discussion, according to some modalities, the data of three levels that are the subject of a given transaction are gathered, communicated to the software system of Figure 7, and stored in the database 706, in a point in time that is contemporary with the execution of the transaction. This provides certain advantages which, while remarkable, are not essential to practice the invention. For example, since the three-level data is captured and entered into the database 706 during the execution of the transaction (as opposed to after execution in the transaction), the software system can examine the data at three levels and comparing said data of three levels against several rules, to determine if a proposed transaction must be approved or denied. As discussed below, a cardholder can select fraud detection rules that, for example, identify a proposed transaction as being potentially fraudulent if a good or class or categories of particular goods are the subject of the transaction. Clearly, such rules can not be enforced if the data regarding the identity of the goods that are the subject of the transaction are either absent or have not been collected until after the transaction was executed. Also as discussed below, a cardholder can adapt rules governing the allowed spending of a "child card". For example, a cardholder can specify that a child card can not execute a transaction where a good or class of particular goods is its subject. Again, such rules can not be imposed if the data regarding the identity of the goods are the subject of a given transaction whether they are absent or not collected until after the transaction has been executed. Finally, since the data of three levels have been gathered and are stored contemporarily with the transaction, a cardholder can be presented with information regarding the identity of items purchased with any associated card or card (including, for example, items purchased through a child card) and the identity of which the number of card conducted such transactions. Said information can be provided in real time or in almost real time, such as through a website or a call center. According to some modalities, the database 706 can be organized as shown in Figure 8. As seen in Figure 8, the database can be organized in order to associate a 800 card number, ie , a group of data that is encoded / stored / contained in a storage medium of a transaction card and that uniquely identifies that card, with a card identifier 802. A card identifier 802 is a group of data (e.g. an integer) that is only associated with a card number 800 in the database 706. The card identifier, in turn, is associated with a master account number 804.

The master account number 804 is a group of data that is only associated with all account information 806 of each account that can be accessed through the transaction card, and is also associated with all cardholder information 808. which can be accessed through the card. For example, the master account number is associated with the balance of each account that can be accessed through the card. In this way, it can be associated with a credit balance (such as when the card is used as a credit card), a bank account balance (such as when the card is used as a debit card), and / or a balance of stored value (such as when the card is used as a stored value card, for example, gift card, asset card and / or pre-paid services, etc.). The master account number 804 is also associated with all the details, for example, data of three levels, of all the transactions executed through each account that can be accessed through the card. In addition, the master account number 804 is associated with each rule that governs the card, for example, rules of interest, final payment rules, fraud detection rules, child account spending rules, etc. Furthermore, the master account number 804 is associated with information related to the financial institution attached to each account that can be accessed through the card, for example, the bank that extends the credit line in addition to the use of the card as a credit card, etc. In general, each unit of data required and / or associated with the capacity of the card such as a credit card, debit card and / or stored value card is associated with the master account number, either directly or indirectly. The aforementioned provision has certain advantages that are notable, but not essential to the practice of the invention. For example, assume that the transaction card associated with the 800 card number was stolen, another card, having another card number, such as the card number 810 can be re-associated with the master account number (through a new card identifier 812). By doing this, all account information 806 and cardholder information 808 remains in place, and such information is not lost. Another advantage is inherent in the arrangement of Figure 8, which is important but not essential for the practice of the invention. As shown in Figure 8, more than one card number 800 and 810 can be associated with the same master account number 804. Consequently, a cardholder can choose to have two transaction cards, one for personal use, and one for business use, for example. (Although this example describes two 800 and 810 card numbers associated with a particular master account number 804, any number of card numbers 800 and 810 may be associated with the same master account number 804). In this way, an individual declaration or web page may present a breach of account 814 to the cardholder, showing, for example, the total expense of each card, or even presenting, on a transaction-by-transaction basis, all the data of three levels (for example, each item and cost associated with it) for each card. According to some modalities, a transaction can be conducted without the use of a transaction card, and is conducted, rather, through a wireless device, such as a cell phone and / or a personal digital assistant. By illustration only, the following illustrative mode is described with reference to a cellular phone. As previously described, the transaction can be initiated in a point of sale device 202, where the bar codes associated with the items to be purchased are scanned by a wizard. At this point, the assistant asks the cardholder for his cell phone number (or so he acquires the cell phone number, for example, has the cardholder calling a specific number that captures the cellular telephone number of the cardholder and communicates it to the point of sale device 202, the merchant server 404, or to a computer system in communication with either the point of sale device 202 and / or with the merchant server 402), and the telephone number is entered into the point of sale device 202. The point of sale device 202 then enters the data of three levels in the database 404, as previously described with reference to Figure 4, again, this causes the monitor module 512 to observe the creation of a new transaction identifier 508 in the transaction table 506, thus propagating the group of events described previously, with the following exceptions. The first cryptic encoding module 520 is instructed to use the telephone number of the cardholder's cell phone to cryptically encode the three-level data, producing a first object cryptically encoded 1000, as shown in Figure 10. Then, the second cryptic encoding module 522 append the cell phone number to the first cryptically encoded object (instead of placing the card number there), and cryptically encode the group of data appended with the merchant's password, as previously described, yielding the second data group 1002 encoded cryptically. The rest of the nucleus works as previously described. In the server of the transition platform, much of the handling is similar to that previously described with reference to Figure 7, with the following exceptions. When the first cryptically encoded object and the appended data are passed, the third cryptic decoding unit 712 detects that a cellular telephone number has been inserted instead of the card number (for example, said detection can be made by virtue of the fact that the cell phone number and a transaction card number are different sizes). After detecting that a cellular telephone number has been inserted in place of the card number, the third cryptic decoding unit 712 uses the cellular telephone number as the cryptic decoding key to cryptically decode the first cryptically decoded object. Then, the third cryptic decoding unit 712 invokes the SMS 728 module with the cellular telephone number. The SMS 728 module sends an SMS message to the telephone number provided there. The SMS message indicates the total price of the transaction and the name of the merchant store where the proposed transaction will be conducted. The message prompts the user to either confirm or deny the transaction. If the user confirms the transaction, he enters his PIN in the phone, and a small application and / or another form of executable code links the PIN with the user card number (the small application and / or another form of executable code was altered previously to include the card number in your code or data space), generating a response indicating that the proposed transaction is going to be confirmed, and including with it the user's card number and the PIN associated with it. According to some modalities, the response message that confirms or denies the transaction is communicated through a wireless Internet connection established by the device and is cryptically encrypted through the SSL protocol. The response message is returned to the third cryptic decoding unit 712. If the response message negates the transaction, then the transaction is denied, as previously described with reference to Figure 7. On the other hand, if the response message approves the transaction, then the third cryptic decoding module 712 has access to the database 706 to retrieve the user's PIN, based on the card number, as previously described. If the recovered PIN matches the PIN entered in the cell phone and passes to the third cryptic decoding module 712 through the SMS 728 module, then the process continues as previously described with reference to Figure 7 (ie, the verification of balance, fraud verification, and profile verification are done, in a usual way). The effect of the above is that a cardholder can make a transaction of a purchase simply by providing his cell phone number to an assistant in a point of sale device 202. After the item (s) to be purchased has been scanned by the assistant, the cardholder receives an SMS, requesting the card holder to confirm the correct aspect of the total price. The cardholder confirms by replying to the SMS affirmatively and entering his PIN. According to some modalities, a cardholder can use a wireless device, such as a cell phone, to make the transaction of a purchase of a good or service from a vendor that does not have a point of sale through cable arranged to interact with the core of Figure 5. The wireless form is programmed with a small application to allow the entry of a total monetary amount of the transaction, a merchant identifier, and a PIN number associated with the cardholder's transaction card. According to some modalities, the small application is configured in the installation to access the card number of the card holder. The small application then combines the card number, merchant identifier, total amount of the transaction, and a transaction type data unit that describe the type of transaction in a packet that is first cryptically encoded using the PIN as a transaction key. cryptic encoding, and then encoded cryptically using SSL. In the software system of Figure 7, the packet is cryptically decoded, first the SSL module 702, and then the third cryptic decoding module 712. Subsequently, the process proceeds as previously described. As mentioned before, the core of Figure 5 and the software system of Figure 7 can cooperate to execute several series of transactions, and can achieve said variety of transactions by varying the data carried in the cryptically encoded transport object of the Figure 6. For example, the aforementioned infrastructure can cooperate to make a "private club purchase". A private club purchase is a purchase conducted with a merchant that requires a membership (for example, Sam's Club, a movie rental store, etc.). For example, consider the scenario where an individual wishes to rent a movie from a movie rental store. Said store typically requires the presentation of a membership card, in order to conduct a purchase. The membership card typically carries a storage medium (bar code, magnetic stripe, etc.) encoding a number associated with a membership account. This membership card is obsolete in view of the infrastructure hereof. As an initial step, a cardholder can associate their membership account number (or other identification number associated with it, such as the number encoded on the storage medium of their membership card) with their master account. When you rent your movie, the card holder presents a transaction card of the group described here both to purchase the movie rental and to present his membership account. The employee can "slide" the card as previously described, setting in motion the previously described events. However, in this context, the transaction type data is set to a value to indicate that a private club purchase is being made. (Three-level data carries data that describes the title of the movie that is being rented, etc.). In this way, a cryptically encoded transport object having a merchant identifier identifying the movie rental merchant, a store identifier identifying the particular store, a point of sale identifier identifying the particular point of sale device, the card number of the transaction card, the data of three levels as described, and the transaction type data as just described, are communicated to the software system of Figure 7. After receiving the coded transport object cryptically, the system behaves as described previously, with the following exception: the system has access to a table in the database 706 that refers to the private club membership number (or other number associated with it) with the master account and card identifier. The system acquires the aforementioned membership number and returns that number in the response package of Figure 9, in addition to the items shown there. In this way, the point of sale device is provided with approval / denial information with respect to the financial transaction, and the membership number of the cardholder is also provided. In this way, the need to complete a private club transaction with two cards is eliminated. The aforementioned infrastructure can also be used to conduct a data acquisition transaction. A data acquisition transaction is a transaction in which the card is used to obtain information associated with the card identifier and with the master account. This information retrieved can be simple. For example, the information retrieved may give an indication of whether an individual is actually a member of an organization (for example, if an individual is a member of a health club). Alternatively, the information may be complex, such as indicating the health information of the cardholder. In the context of a data acquisition transaction, the infrastructure behaves as described previously, with the following exceptions, which are described with reference to a cardholder who uses his card to provide health care to a care institution of health (hospital, clinic, etc.). As an initial matter, the cardholder establishes a group of rules within the database 706 that identify what type of data can be retrieved. For example, the rules describe the type of health care data that can be retrieved from the card through various institutions identified by their respective merchant identifiers. In the health care facility, the card is "slid" to read the storage medium in it, and the series of previously described events occurs. However, in this context the cardholder may not be aware, so the PIN that is going to be entered may be "911", or some other pre-defined PIN. The transaction type data is set to a value to indicate that a data acquisition transaction is being performed. (The data of three levels must be canceled or can be filled with obsolete data, such as the warehouse identifier and the point of sale identifier), however, in some cases, these fields are filled in such a way that a message of Response can be directed to the appropriate transaction execution device within the health care facility. In this way, a cryptically encoded transport object having a merchant identifier identifying the health care facility, the card number, and the transaction type data as described, is communicated to the software system of the merchant. Figure 7. (Again, in certain cases, the warehouse identifier and the point of sale identifier can be filled out). After receiving the transport object cryptically encoded, the system behaves as described previously, with the following exceptions. After identifying that the merchant identifier corresponds to a health care facility and that the transaction type data corresponds to a data acquisition transaction, the third cryptic decoding module is derived, as the data of three levels are canceled. Then, the software system has access to the database 706 to obtain the rules governing access to the data associated with the merchant identifier. For example, the database 706 may contain a table that relates each merchant identifier, master account, and card identifier to the cardholder data that may be returned thereto in response to a data acquisition transaction. The software system then implements the rules, returning the allowed data that are returned to the health care facility, given the rules. In this way, the transaction card described here can be used to provide any variety of information to any variety of organization. To allow the above transactions, the front end module of Figure 7 can provide a website where a cardholder can be registered. The website may present one or more structured web pages to allow the cardholder to associate any data with their card, including health care data, insurance data, club membership data, or any other data , including data specified by the user. The website may also present one or more web page structures to allow the cardholder to associate rules that govern access to such data, for example, on a merchant-by-merchant basis (entity by entity). Some aspects of the system described with respect to Figures 2-10 are of importance, but not essential for the practice of the invention. As can be seen in Figure 2, for example, the transaction system does not include any exchange actor and therefore eliminates system components and financial charges related to it. For example, as compared to the system of Figure 1, it can be seen that the system of Figure 2 does not require any private network element or line. In this way, the exchange actors responsible for the creation and maintenance of said network lines and elements are eliminated from the process of executing a transaction. Therefore, the costs ordinarily borne by merchants for the provision of their exchange services are eliminated. However, according to some modalities, a minimum number of network lines and / or elements can be used. The database maintained by the transaction platform includes tables that have fields for the inclusion of credit limits, fraud rules, and other rules ordinarily imposed on a bank basis by bank or association by association. The software system of Figure 7 includes a front end 726 that allows access to the database by card holders and card issuing banks. A card issuing bank may establish rules, for example, credit limit rules, fraud detection rules, etc., associated with a given card number through the front end module 726. The rules established by the issuing bank of cards are housed in the database 706, together with the card number to which the rules apply. Therefore, the server of the transaction platform does not need to communicate with the information systems of the card issuing bank with each proposed transaction in order to deny or approve the transaction. Rather, the transaction platform server can periodically update the information system of the card issuing bank (e.g., on a daily basis), after having independently approved one or more transactions during the period. Also of importance, but not essential to the practice of the invention, is that the database 706 may contain a table that relates the card identifier to a side identifier. The bank identifier indicates the identity of the financial institution that corresponds to a given card. By simply changing the bank identifier in the aforementioned table, the bank associated with a given card is altered. In this way, a cardholder can effectively transfer his balance from one bank to another, without having to change credit cards (the transaction platform simply changes the bank identifier). Similarly, the database 706 may include a table that associates a card type identifier with a card identifier. The card type identifier identifies the type of financial transaction (s) that is supported by the card. In other words, the card type identifier indicates whether the card is a credit card, debit card, stored value card, health care management card, another form of card, or a combination of some or all previous. In this way, an individual transaction card can be used as a credit card in one context and a debit card in another context, for example. Stated another way, the database schema presents a mechanism through which a card number stored in a storage medium of a card and entered in the database 706 is related to a card identifier; the card identifier is related, in turn, to a card type identifier that identifies the type of transaction that will be supported by the card or information that will be accessed through the card; the card type identifier and the card identifier cooperate to relate a group of organized and filled tables to allow the card to act as a credit card, debit card, stored value card, health information card, etc. For example, as noted previously, the database includes a group of tables that contain enough information to allow the card to act as a credit card. These tables include, among other information, information regarding the credit limit of the card, the rules of interest related to the card, the latest rules of rights related to the card, the identity of the issuing bank of the card in relation to the card, address information that allows contact with the information systems of the card issuing bank (for example, IP address, port information, physical address, etc.), and information of this type. The data in these tables can be associated with a given card through the use of a card identifier, that is, the card identifier can be used as a key in these tables. A second group of tables allows the card to act as a debit card. These tables include, among other information, information regarding the checking account number and routing number of the account associated with the card, the balance of the checking account, and information of this type. Again, the data in these tables can be associated with a given card through the use of a card reader, that is, the card identifier can be used as a key in these tables. A third group of tables allows the card to act as a stored value card. A stored value card is a card that provides access to a pre-paid good or service (for example, a pre-paid phone call card, a gift card, etc.). These tables include, among other information, information regarding the available balance, the store (s) of the merchant where the balance can be spent, rules regarding any restrictions after the balance is spent, and other information of this type. Again, the data in these tables can be associated with a given card through the use of a card identifier, that is, the card identifier can be used as a key in these tables. Still another group of tables allows the card to act as a health record access card. A health registration access card is a card that allows access to health information stored in a database, such as database 706 of Figure 7. These tables include, among other information, information regarding the health insurance maintained by the cardholder, dental insurance maintained by the cardholder, vital statistics of the cardholder, medications taken by the cardholder, cardholder allergies, surgical procedures experienced by the cardholder cardholder, information regarding the doctor and other health care providers of the cardholder, personal health record, electronic medical record, payment adjudication, calculation and co-payment statement, and other information of this kind. Again, the data in these tables can be associated with a given card through the use of a card identifier, that is, the card identifier can be used as a key in these tables. As discussed with respect to Figure 3, a scheme for the rapid placement of an activated transaction card in the possession of an applicant was previously described. Figure 11 presents a method by which the holders of real cards can distribute transaction cards in favor of the transaction platform, and may receive an incentive to do this. A cardholder who wishes to act as a distributor of transaction cards may request a supply of anonymous, unallocated transactions. In response, the transaction platform provides the cardholder with said supply of unallocated anonymous cards (operation 1100). The cardholder distributes one of the anonymous cards to a person who is right who believes he or she might be a cardholder (for example, a friend, a partner, etc.), as shown in operation 1102. Either before said distribution or thereafter, the distributed card is associated with the cardholder in the database 706 (operation 1104). For example, a table can be filled to associate the card numbers of each of the anonymous cards distributed and the card identifier that corresponds to the cardholder to whom the cards were delivered. The table may also be filled out to include information identifying the person to whom the cardholder distributed the unassigned transaction card (ie, the prospective applicant). The operation 1104 may be conducted, for example, by the cardholder, on a website presented by the front end module 726. After the operation 1104, the procedure for the application proceeds as described with reference to the Figure 3. However, as shown in transaction 1106, in the event that the person to whom the cardholder provides an anonymous card is approved, incentive points are added to the account of the cardholder who distributes it, assuming that the information Identification of the applicant matches the identification information provided by the cardholder in operation 1104 (this prevents a cardholder from requesting a large number of unassigned transaction cards and leaves a stack of them, for example, in a shopping center hoping to be accredited by some applications that result from it). Also, in addition to, or as an alternative to incentive points, the cardholder's account can be credited with a monetary sum. The association operation performed in operation 1102 allows the server of the transaction platform to identify the appropriate card to which the incentive points are added. After the approval of an applicant card, the software system of the transaction platform can examine a table that relates to the card numbers not assigned with the card identifiers of the cardholders who received and distributed the cards. , in order to determine if the card number of the card just approved is associated with the card identifier of said cardholder. If it is associated, then the corresponding card identifier is obtained. Then, a table that associates the card identifier with a master account can be accessed to obtain the master account of the card holder who distributed the card. Then, you have access to a table that relates an incentive point balance to the master account number, and the incentive point balance is updated to reflect the added incentive points. According to some modalities, the cardholder account that he distributes is supplied with points, even if the person to whom the card holder provides the card is rejected (operation 1108). According to some modalities, the incentive points can be spent on items designated for such use by merchants, or they can be used in the context of a generic rewards program. If a monetary amount is granted to the account of the cardholder, then the monetary amount can be spent on any good or service. As discussed with reference to Figure 6, some modalities of the transaction system allow the communication of three level data describing a given transaction. For example, assuming that a cardholder makes a transaction of a purchase of soap, soda, and paper towels for a total of $ 15, the information communicated from the core of Figure 5 to the software system of Figure 7 includes information that identifies the transaction including soap at a cost of $ 8, soda at a cost of $ 4, and paper towels at a cost of $ 3, for a total of $ 15. The software system in Figure 7 receives the information and, as previously described, creates a transaction identifier, identifying the $ 15 transaction. Each purchased item (and cost associated with it) is associated with the transaction identifier. In this way, according to such modalities, the database 706 contains data associating a particular merchant, merchant store, registry, each item purchased, the cost of each item purchased, and the total cost of the transaction. The conservation of said data of three levels allows some functionality that until now is impossible. An example of the functionality allowed by the preservation of three-level data refers to improved dispute resolution. Currently, if a credit card holder reviews your account statement and believes that a particular charge is too large, the cardholder can dispute the charge. Continuing with the previous example, assume that the account statement received by the cardholder presented that transaction for a total of $ 25, instead of $ 15, the cardholder could contact his credit card company, and say that the transaction must be a total of $ 15, and not $ 25. Consequently, the entire $ 25 transaction could be identified as being disputed, despite the fact that only $ 10 of the $ 25 is in the issue, that is, the cardholder recognizes that he owes $ 15, but does not believe he owes $ 25. The entire transaction must be disputed, in some cases, since a traditional credit card company does not receive detailed information regarding the contents of a transaction, and in other cases because the software systems used by traditional credit card companies they do not allow the dispute of a cost associated with a particular item. In response to the dispute, the bank issuing the card removes the $ 25 transaction from the cardholder's balance (until the dispute is resolved), and does not transfer any funds to the merchant's bank for the transaction, not until The cardholder recognizes that he really owes $ 15. In this way, the merchant fails to receive the $ 15 that both parties recognize that the merchant must, until the disputed amount of $ 10 is resolved. According to the method of Figure 12, disputes can be recorded on an article-by-article basis, as opposed to merely on a transaction-by-transaction basis. As shown in Figure 12, information regarding the disputed item can be obtained from the card holder (operation 1200). For example, a cardholder can call an employee of the transaction platform and describe the disputed item. For example, the cardholder can describe the date, the merchant, and the disputed item. In general, the cardholder can submit any amount of data from three levels to identify only the disputed item. The employee has access to the database using the information provided level, until the specific transaction and the dispute article of the same are identified. (The process of identifying the particular cost associated with a particular item that is the subject of a transaction can be done through a website presented by the front end module 726. For example, after entering, a cardholder can select an option to dispute an article within a transaction.The website can then present a series of fields, allowing the cardholder to identify the particular item that will be disputed. For example, the website may present a first field allowing the cardholder to see all transactions within a particular time period, for example, occurring on a given day. In response the user is presented with a group of transaction summaries, for example, a list of transactions identified by date, merchant, and total amount. The selection of a particular summary makes a list of each item that is a subject of the transaction, and the cost associated with it, is presented. To dispute a particular cost, the cardholder can select the item to dispute, and can introduce an explanation of the dispute in a field associated with it). Returning to the example where the dispute is entered through a telephone conversation with an employee, the transaction identifier of the transaction for which the disputed article is a constituent is found (operation 1202). Next, a record is created within one or more tables, in order to dispute the cost associated with an identified item of the identified transaction (operation 1204). For example, the record may dispute the cost associated with an item since the statement reflects a purchase price of an item at a different cost than the cardholder believes is the true cost. Also, the record may dispute the cost associated with an item, since the cardholder denies having purchased the item. The record describing the dispute may include data fields for the description of the disputed item, and the reasons for the cardholder to dispute the cost associated with a given item. The cost associated with the disputed item is removed from the balance associated with the card (operation 1206), until that time is resolved as the dispute. After the resolution of the dispute (beyond the scope of this description, but understood by those skilled in the art), an appropriate monetary amount may be added back to the balance associated with the card. Finally, as shown in step 1208, a reference to the record created in step 1204 can be entered into a table of disputes that will be resolved. Another function that results from the collection of three-level data is the resolution of billing account statements that can be received. According to some modalities, some or all of the data of three levels can be included in billing account statements. According to some modalities, a cardholder can select the amount of data from three levels presented in the account status associated with this card. For example, the front end 726 (Figure 7) can present a website that allows a cardholder to select the level of detail that will be presented in their account statement. The website may allow, for example, that the cardholder indicate that all data from three available levels are presented. In this case, the account statement presents all the data of three levels gathered for each transaction presented in the statement. The website may also allow the user to select only certain types of data from three levels that will be presented, for example, only the description of goods / services, or classification of goods / services, or SKUs of goods / services, etc. In this way, a statement of account can present, for each transaction, a description of each of the goods / services that constitute each transaction, a classification of each good / service that constitutes each transaction, the SKU of each good / service that constitutes each transaction, etc. Of course, the website can also allow the user to choose not to have any data of three levels presented in his account statement, in this case, the account statement presents typical transaction information (merchant, date, total amount of the transaction). Figure 13 illustrates a method for establishing one or more rules that govern a child card. As previously mentioned, a child card corresponds to an account that is a sub-account of a parent card. A cardholder of a parent card can establish one or more rules for a child card, for example, register in a website presented by the front end module 726 of the software system of Figure 7 (operation 1300). For example, according to some modalities, the website presents a field for the entry of the card number of the owner of the card that is registered on the website. The website also presents a field for entering a password and / or PIN that corresponds to the card number. The cardholder enters their card number, password and / or PIN for registration. The software system of Figure 7 in this way identifies the particular user of the website that corresponds to a particular card number. Alternatively, the website can present a field for the entry of a username associated with the card holder (and therefore, associated with your card number, etc.), and another field for entering a password . The registration procedure is executed after data entry in these fields. After registration, the cardholder is presented with a menu of options that belong to their account. For example, the cardholder can be presented with a menu that allows the cardholder to review a real-time presentation of their account status, including their balance, recent review transactions related to any account that, at their Once, it is related to your card number, review and / or enter information, such as medical information, insurance information, etc., related to your card number, establish custom fraud rules to govern your card number, establish rules to automatically alter your PIN from time to time, and / or to establish rules governing a child account that corresponds to your parent account. As shown in step 1302, the cardholder selects an option to establish rules governing a child account. In response to such selection, as shown in step 1304, the website presents a list of child card numbers corresponding to the parent card number entered in operation 1300. For example, the software system of Figure 7 examines a particular table in the database 706 that associates, either directly or indirectly, child card numbers with parent card numbers. All child card numbers associated with the parent card numbers entered during operation 1300 are identified and presented. According to some modalities, the name of the card holder associated with the child card is also presented. The owner of the parent card then selects a card number from the list (operation 1306).

Next, the website presents fields to adapt rules that can be applied to the child card. For example, the website may present fields that allow the parent to associate a rule with the child account, which allows the child account to incur up to a level debt selected by a selected unit of time (for example: $ 250 per month) . Other rules include, without limitation: (1) not allowing purchases of certain SKUs or classes or categories of SKUs (for example: not allowing purchases of SKUs that indicate that the item purchased is alcohol); (2) not allow purchases to occur in certain merchants, merchant types and / or merchant categories; and / or (3) only allow purchases that occur in certain merchants. The cardholder selects the rule for application to the child card, and enters the relevant rule data (for example, if the cardholder wishes to limit the child card to a limit of $ 250 per month, then "250" is entered in a spent limit field, and "month" is entered in a time field unit, for example, it can be selected from a frequency shift menu) (operation 1310). Finally, as shown in step 1312, the rules selected during operation 1310 are associated with the child card. As mentioned with reference to Figure 13, a cardholder can select fraud activations that will be assigned to his card and / or to a child card. As was the case with the establishment of rules for a child card, fraud triggers can be established, for example, by registering on a website presented by the front end module 726 of the software system of Figure 7 (operation 1400, FIG. 14). As described, according to some modalities, the website presents a field for the entry of the card number of the owner of the card that was registered on the website. The website also presents a field for entering a username, password and / or PIN that corresponds to the card number. The cardholder enters their card number, password, and / or PIN to register. The software system of Figure 7 thus identifies the particular user of the website as corresponding to a particular card number. As discussed with reference to Figure 13, after registration, the user selects an option to allow the adaptation of fraud triggers. Then, the website responds by presenting the cardholder with several categorizations of fraud triggers that can be applied to the card (operation 1402). For example, as shown in Table 1404, the website may present to the cardholder a group of fields that allow data entry for the designation of: (1) a maximum number of dollars that can be spent per unit of time, with any expense over the limit being assumed as fraudulent, for example, any expense over $ 5000 in a day is assumed to be fraudulent; (2) a maximum purchase price for a single transaction, with any expense over the maximum purchase price being assumed to be fraudulent, for example, any expense over $ 5000 is assumed to be fraudulent; (3) Private classes of products that are assumed to be fraudulent, for example, a transaction that includes data from three levels having a SKU indicating that the jewelry is trying to be purchased, is assumed to be fraudulent; (4) an increase in expenses that exceed a given percentage, for example, the software system of Figure 7 can track the expenses of a given cardholder during the last N days (N = 30,60,90, etc. .). and can calculate the average or average amount spent per day, with expenses in one day exceeding the average and / or average spending for more than a selected percentage is assumed to be a fraud; (5) A class of merchants may be designated, for example, any purchase in a jewelry store is assumed to be fraudulent; (6) Private merchants can be designated, for example, any transaction that has a merchant identifier that corresponds to a selected merchant is assumed to be fraudulent; (7) you can designate particular goods or services, for example, any transaction that includes data from three levels having an SKU corresponding to a good and / or selected service is assumed to be fraudulent; (8) geographic regions can be assigned, for example, any transaction that has three-level data indicating that the merchant's store is located in a given region (state, country, continent, etc.) is assumed to be fraudulent. The cardholder can enter data in any of the fields corresponding to the fraud rules that he wishes to apply to the card (operation 1406). For example, to establish that an expense exceeds $ 5000 must be considered fraudulent, the cardholder can enter "5000" in a field labeled "maximum allowable expense (in dollars)". Finally, as shown in step 1408, the software system of Figure 7 associates the selected rules with the card number entered during operation 1400. As mentioned with reference to Figure 13, a cardholder can select a scheme through which a PIN associated with your card is modified. As described with reference to Figures 13 and 14, the cardholder can begin the selection of the PIN modification scheme by entering the website (operation 1500). The software system of Figure 7 in this way identifies the particular user of the website as corresponding to a particular card number. As discussed with reference to Figures 13 and 14, after registering, the user selects an option to allow automatic modification of the PIN associated with his card. Then, the website responds by presenting the cardholder with several modification schemes that can be applied to the card (operation 1502). For example, as shown in Table 1504, the website can present to the cardholder a group of fields that allow data entry for the designation of: (1) a selected amount through which the PIN for a selected unit of time, for example, increase the PIN by an amount of 5 per week; (2) a selected amount through which the PIN is reduced by a selected unit of time, for example, reduction of the PIN by an amount of 5 each week; (3) a selected group of PINs, each of which is active for a selected period of time, for example, a selected group of 5 PINs, the first PIN in the group being active for one week, the second PIN in the group group being active in the following week, and so on; (4) the option to perform a rotary right operation on a PIN for each unit of time, for example, after a week the PIN 4305 becomes 5430, after the next week it becomes 0543, and so on; (5) the option 'to perform the rotary left operation on a PIN every unit of time, for example, after a week the PIN 4305 becomes 3054, after the next week it becomes 0543, and so on; (6) a selection of a period of time during which a PIN is active, after the expiration of that time, a new PIN is randomly selected, for example, a new PIN is randomly selected each week (the cardholder can register on the website to learn the new PIN, or you can request a phone number and learn the new PIN through an interactive voice recognition and / or send you the PIN, for example); (7) a selected amount through which the PIN is multiplied with the passage of a selected period of time, for example, multiplying the PIN by 2 each day; (8) a selected amount through which the PIN is divided with the payments of a selected period of time, for example, divide the PIN by 2 each day; and / or (9) selecting a static portion of a PIN that will be appended or pre-appended to a dynamic portion of a PIN that changes according to any algorithm, including the aforementioned algorithms, for example, a static portion, 12345, to which a dynamic portion, 99, is appended producing a PIN of 1234599, which may change to be 12345100, if the dynamic portion is selected to be altered by incrementing by one. When performing a mathematical operation on the PIN, for example, multiplying the PIN by a selected quantity N, it is understood that the resulting quantity may be truncated, or otherwise operated, to arrive at a number of the appropriate number of digits. However, it should be noted that, according to some modalities, the PIN is not of a prescribed length, but rather can be of any length within a predetermined scale, for example, between four and fifty-six digits. Also, when performing a mathematical operation on the PIN, for example, dividing the PIN by a selected amount N, it is understood that the resulting amount can be rounded to a closer number, or otherwise operated, to obtain an entire amount . The cardholder can enter data in any of the fields corresponding to the PIN modification scheme that he wishes to apply to the card (operation 1506). For example: to establish that the PIN associated with your card must be increased by 5 each week, the cardholder can enter "5" in a field marked as "amount by which PIN is increased and" weekly "in a marked field as "period during which the PIN is increased." Finally, as shown in step 1508, the software system of Figure 7 associates the selected rules with the card number entered during operation 1500. According to another mode , the software system of Figure 7 can support the selection of a PIN that is used only once.For example, the cardholder can select a PIN that is always associated with his card number (through the use of a website provided by the front end module 726, as previously described.) In addition to this, the cardholder can select a PIN that can be used once (again, through the use of a web site provided by the front end module 726, as previously described). When, in the context of executing a transaction, the software system of Figure 7 receives a cryptically encoded transport object, as such in Figure 6, the third cryptic decoding module 712 may initially attempt its cryptic decoding using the PIN " "ordinary", as described with reference to Figure 7. Assuming that the cryptic decoding fails, the third cryptic decoding module 712 attempts the cryptic decoding with the "one-time" PIN associated with the card number. If successful, the transaction is performed as previously described, and the PIN in time is disabled from an additional use. Said PIN of a time is useful for parameters where the cardholder is prompted about providing his "ordinary" PIN to a merchant, such as when the cardholder may be using an unfamiliar e-commerce website, or when you believe that the entry of your PIN may be under observation. Since the PIN can only be used once, it does not matter if the PIN entry is observed or captured by a website. According to another embodiment of the invention, the aforementioned transaction scheme can be used to allow return of goods between merchants, as illustrated with reference to Figures 16A and 16B. For example, Figure 16A illustrates a typical online shopping arrangement, wherein a cardholder 1600 orders an article from an online merchant 1602. The cardholder 1600 receives the article from the online merchant (operation 1601). In response, card issuing bank 1604 sends the price of the item to the online merchant bank (operation 1603). Then, at the expiration of the billing period, the card holder 1600 pays a sum of money equal to the price of the item to bank 1604 (operation 1605). Figure 16B presents an example of a return of goods between merchants. For each arrangement of Figure 16B, the cardholder 1600 returns the item to a partition and mortar retailer 1606 (operation 1607). At the time of return, the holder of the 1600 card presents his receipt to the partition and mortar trader 1606, who uses the information of this to indicate to the transaction platform that a return of a particular item by a particular merchant to through a particular card holder is going to be made in the retailer shop of partitions and mortar 1606. Using the information mentioned above, the transaction platform has access to a database of rules to determine a sum of money that will be transferred from the retailer of partitions and mortar to the online merchant. The server of the transaction platform then invites a transfer of funds from the bank of the partition and mortar merchant to the online merchant bank equal to the determined sum (operation 1609). The aforementioned rule base amount may be agreed in advance by individual traders, and may be a function of a particular item that will be exchanged, or class of items that will be exchanged, or it may also be a function of the two merchants individuals involved in the exchange between merchants. Then, the online merchant 1602 transfers a sum of money equal to the price of the item to the card issuing bank 1604 (operation 1611), and the card issuing bank 1604 credits the cardholder's account with a sum of money equal to the price of the article (operation 1613). In this way, the 1600 cardholder is free to conduct a purchase with a merchant (such as the online merchant 1602), and return the item to a second merchant (such as the merchant of partition and mortar 1606). This return arrangement is made possible due to an agreement on the amount that will be transferred from one merchant to another merchant in the event that an exchange of a particular item or classes of items is stored in a database in communication with the server of the transaction platform. Figure 17 illustrates a wireless exchange of funds scheme among cardholders. The scheme involves a small application that runs on a processor inside a cell phone. The small application includes a 1700 prompting module that asks a cardholder to enter the following information: (1) the amount of money you wish to transfer to another cardholder; (2) the PIN code of the cardholder; and (3) the receiver's cellular telephone number. The aforementioned data are agglomerated in a data set, and are cryptically encoded by the cryptic encoding unit 1702, which can operate in accordance with the principles described above. The group of cryptically encoded data is then communicated through the SSL Internet connection transaction platform of Figure 7. At the front end, the telephone number from which the transaction originated is extracted, and is used to query a database 1704 that associates the telephone numbers of the card holder with PIN code. The corresponding PIN code, therefore, is returned to the module 1706, and is provided to the cryptic decoding module 1708, which uses the PIN code as a cryptic decoding key. Afterwards, the availability of funds in the account corresponding to the PIN is verified. According to one embodiment, the PIN or telephone number can be used to access a 1710 database that relates a card identification number with a PIN or telephone number. The recovered card identification code is then sent to the funds verification module 1712, which determines whether the account corresponding to the PIN / telephone number has sufficient funds to allow the proposed exchange. If so, the exchange is made, and an SMS is sent through module 1714 to the receiver's telephone number, informing him of the exchange of funds. A person-to-person exchange of funds can also be conducted online through a website presented from the front end module 726, generally proceeding as described with reference to Figure 17. Figure 18 illustrates an illustrative embodiment of a person-to-person transaction as already discussed. As shown in Figure 18, the 1800 transaction platform extends access to monetary funds (line of credit, debit account, checking account, savings account, stored value, and / or pre-paid account) through each of the two banks 1802 and 1804. In the beginning, the 1800 platform can extend access to funds through any number of banks. For illustration only, a transfer of funds from person to person is described with reference to the transfer of a credit card. The transfer of funds can be executed from any type of account to any type of account. Again, just for illustration, it is assumed that the transaction platform handles eight parts, each of which has a transaction card that functions like a credit card. Four of the cardholders have access to a line of credit through bank 1802, while the other four have access to a line of credit through bank 1804. In this way, as shown in Figure 18, maintains an account for each cardholder through each card issuing bank 1802 and 1804. One of these accounts is identified with the reference number 1806, and the other of these accounts is identified with the reference number 1808. Assume that the cardholder associated with the 1806 credit account wishes to transfer funds to the party associated with account 1808, said funds can be made instantly available to the party associated with account 1808. The transaction platform maintains an account 1810 and 1812 in each bank 1802 and 1804. All cardholders who have accounts in bank 1802 have funds from their pre-paid accounts stored in account 1810, while all the cardholders of the cards that have accounts in the bank 1804 have the funds of their pre-paid accounts stored in the account 1812. The platform maintains a database 706 that keeps track of each share of cardholder funds held in the pre-paid accounts 1810 and 1812. A transfer of a 1806 credit account to the cardholder associated with the 1808 credit account is transferred from the 1806 credit account to the pre-paid account 1812, and the database 1706 is immediately updated to: (1) reflect that the 1812 account increased in the monetary amount that has been transferred; and (2) reflects that the cardholder associated with the 1808 credit account has a pre-paid account sharing that is increased by the monetary amount that was transferred. In this way, the cardholder associated with the 1808 monetary account can immediately extract his portion of the pre-paid account 1812, for example, can conduct a purchase of a good or service by making the transaction of said purchase as a pre-paid transaction. -paid, this means that the funds were withdrawn from that pre-paid account 1812, and the database 706 is immediately updated to reflect that transaction. Alternatively, the cardholder associated with the 1808 credit account may specify that the funds received were transferred to his 1808 credit account, or any other account. Said transfer is then completed, for example, at the end of the day when the database 706 and the bank's computer system 1804 are synchronized, in order to reflect that the monetary sum will be withdrawn from the pre-paid account 1812 and deposited in the 1808 credit account.

The various embodiments described above are provided by way of illustration only and should not be construed as limiting the invention. Those skilled in the art will readily recognize various modifications and changes that may be made to the present invention without following the illustrative embodiments and applications illustrated and described herein, and without departing from the true spirit and scope of the present invention set forth in the following claims.

Claims (34)

1. A computerized method comprising: associating, in a database, a first transaction card through which access to monetary funds is extended with a second transaction card through which access to said monetary funds is extended; associating, in said database, the second transaction card with one or more rules that govern access to said monetary funds through the second transaction card; and allowing an individual who has the first transaction card to specify the rules governing access to monetary funds through the second transaction card.

The method according to claim 1, wherein said individual can specify a maximum number of dollars per specified period of time that can be spent from said monetary funds by the second transaction card.

3. The method according to claim 1, wherein the individual can specify one or more products or services that may not be purchased with the second transaction card.

The method according to claim 1, wherein the individual can specify one or more store maintenance units (SKUs) that may not be associated with any product purchased with the second transaction card.

The method according to claim 1, wherein the individual may specify one or more kinds of products or services that may not be purchased with the second transaction card.

The method according to claim 1, wherein the individual can specify one or more kinds of store maintenance units (SKUs) that may not be associated with any product purchased with the second transaction card.

The method according to claim 1, wherein the individual can specify one or more merchants to whom the payment from said monetary funds may not be extended by the second transaction card.

The method according to claim 1, wherein the individual can specify one or more types of merchant to whom the payment from said monetary funds may not be extended by the second transaction card.

The method according to claim 1, wherein the individual can specify one or more merchant categories to which the payment from said monetary funds may not be extended by the second transaction card.

The method according to claim 1, wherein the individual can specify one or more merchants to whom the payment from said monetary funds can be extended by the second transaction card.

The method according to claim 1, wherein the second transaction card comprises a credit card.

12. The method according to claim 1, wherein the second transaction card comprises a debit card.

The method according to claim 1, wherein the second transaction card comprises a stored value card.

14. A system comprising: a first transaction card through which access to money funds is extended; a second transaction card through which access to money funds is extended; a database wherein the first transaction card is associated with the second transaction card, and wherein the second transaction card is associated with one or more rules governing access to said monetary funds by the second transaction card; and a computer system programmed to allow an individual who has the first transaction card to specify the rules that govern access to the monetary funds through the second transaction card.

The system according to claim 14, wherein the computer system is programmed to allow said individual to specify a maximum number of dollars per specified period of time that can be spent from said monetary funds by the second transaction card.

16. The system according to claim 14, wherein the computer system is programmed to allow said individual to specify one or more products or services that may not be purchased with the second transaction card.

The system according to claim 14, wherein the computer system is programmed to allow said individual to specify one or more store maintenance units (SKUs) that may not be associated with any product purchased with the second card. transaction.

18. The system according to claim 14, wherein the computer system is programmed to allow said individual to specify one or more kinds of products or services that may not be purchased with the second transaction card.

The system according to claim 14, wherein the computer system is programmed to allow said individual to specify one or more kinds of store maintenance units (SKUs) that may not be associated with any product purchased with the second transaction card.

The system according to claim 14, wherein the computer system is programmed to allow said individual to specify one or more merchants to whom the payment from said monetary funds may not be extended by the second transaction card .

The system according to claim 14, wherein the computer system is programmed to allow said individual to specify one or more merchants to whom the payment from said monetary funds can be extended by the second transaction card.

22. The system according to claim 14, wherein the computer system is programmed to allow said individual to specify one or more types of merchant to whom the payment from the monetary funds can be extended by the second credit card. transaction.

23. The system according to claim 14, wherein the computer system is programmed to allow said individual to specify one or more merchant categories to which the payment from said monetary funds can be extended by the second credit card. transaction.

24. The system according to claim 14, wherein the second transaction card comprises a credit card.

25. The system according to claim 14, wherein the second transaction card comprises a debit card.

26. The system according to claim 14, wherein the second transaction card comprises a stored card.

27. A computerized method comprising: associating a first card number with a first transaction card through which access to money funds is extended; assigning a second card number to a second transaction card through which access to money funds is extended, wherein the second card number is different from the first card number; and associating, in a database, said first transaction card with the second transaction card, so that the monetary funds can be accessed through the second transaction card and are the same monetary funds as those accessed through the first transaction card.

28. The method according to claim 27, wherein the first and second transaction cards are credit cards.

29. The method according to claim 27, wherein the first and second transaction cards are debit cards.

30. The method according to claim 27, wherein the first and second transaction cards are stored value cards.

31. A system comprising: a first transaction card through which access to money funds is extended, said first transaction card having a storage medium that encodes a first number only by identifying said first transaction card; a second transaction card through which access to money funds is extended, said second transaction card having a storage medium that encodes a second number only by identifying the second transaction card; a database that associates the first transaction card with the second transaction card, so that the monetary funds accessed through the second transaction card are the same monetary funds as those accessed through the first transaction card.

32. The method according to claim 31, wherein the first and second transaction cards are credit cards.

33. The method according to claim 31, wherein the first and second transaction cards are debit cards.

34. The method according to claim 31, wherein the first and second transaction cards are stored value cards.