WO2001046917A2

WO2001046917A2 - Identity authentication using transaction history

Info

Publication number: WO2001046917A2
Application number: PCT/US2000/034802
Authority: WO
Inventors: Ric B Richardson
Original assignee: Richardson, Ric, B.
Priority date: 1999-12-20
Filing date: 2000-12-20
Publication date: 2001-06-28
Also published as: AU2732101A

Abstract

A verification system to permit a person to use fully, or continue using, a product based upon the person's past dealings with a supplier. A method according to principles of the present invention involves obtaining a product, on a trial basis, from a supplier that implements the verification system in product transactions. The product is utilized to determine if the person would like to use the product indefinitely and transaction data is submitted to the verification system that pertains to the person, including data regarding past transactions of the person with the supplier. The transaction data is analyzed by the verification system to determine prior transaction codes that the verification system has generated regarding previous transactions between the person and the supplier, and a new transaction code is generated by the verification system, regarding the current transaction, the code being at least partially dependent upon the prior transaction codes that were generated by the verification system.

Description

TITLE: IDENTITY AUTHENTICATION USING TRANSACTION HISTORY

FIELD OF THE INVENTION

The present invention relates to authenticating identity of the purchaser of a product, and more particularly to a system and method for using the transaction history of a customer to authenticate the identity of the user.

BACKGROUND

Advances in network technology have created a financial incentive to use computer networks for a wide variety of transactions, including commercial transactions such as the buying and selling of software. Because of the proliferation of commercial transactions, and the subsequent structuring of computer networks to facilitate such transactions, the security of data that passes through a computer network is becoming more important. In addition to an increasing financial incentive for third parties to violate security measures and to misappropriate confidential data associated with commercial transactions, the tools that may be obtained by such third parties are also becoming more common. For example, a customer that purchases software from a particular software company may encounter a third party that attempts to impersonate the customer using data intercepted from the customer either over the network or from other sources. The third party may then attempt to make additional unauthorized purchases from the company after assuming the identity of the customer. Likewise, such third party may make a valid purchase of an item such as software, then transmit electronic copies of the validly purchased item to other third parties for a reduced fee, thus siphoning off potential valid purchasers.

An exemplary network in which such problems can be found is the Internet. Data passed during an Internet transaction may be captured by unauthorized third parties. Such Internet transactions are also growing riskier with each new development of network tools available to third parties that assist in the unauthorized obtaining of data passing across the network. Many other problems and disadvantages of the prior art will become apparent to one skilled in the art after comparing such prior art with the present invention as described herein.

SUMMARY OF THE INVENTION Various aspects of the present invention may be realized through a secure transaction system comprising previous transaction data, a first processing system that stores the previous transaction data, and a second processing system that stores the previous transaction data. The second processing system has at least one disabled function and the first processing system uses at least the previous transaction data to generate a current transaction code. The second processing system uses the current transaction code and the previous transaction data to enable one or more of the at least one disabled functions of the second processing system. In certain embodiments, the previous transaction data of the secure transaction system comprises at least one transaction code. Further, the first processing system of the secure transaction system may comprise a merchant system and the second processing system of the secure transaction system may comprise a customer system.

Various other aspects of the present invention may be realized through a method for a verification system to permit a person to continue using a product based upon the person's past dealings with a supplier. The method involves obtaining a product, on a trial basis, from a supplier that implements the verification system m product transactions. The product is utilized to determine if the person would like to use the product indefinitely and transaction data is submitted to the verification system that pertains to the person, including data regarding past transactions of the person with the supplier. The transaction data is analyzed by the verification system to determine prior transaction codes that the verification system has generated regarding previous transactions between the person and the supplier, and a new transaction code is generated by the verification system, regarding the current transaction, the code being at least partially dependent upon the prior transaction codes that were generated by the verification system.

The method may further comprise supplying the new transaction code to the product, and verifying, by the product, with the new transaction code, that prior products obtained by the person through previous transactions with the supplier are associated with the product. Further, obtaining the product may comprise obtaining a software program. In addition, generating the new transaction code may comprise combining with an algorithm, the transaction data and any immediately prior transaction codes. Still further, generating the new transaction code may comprise generating a software license code and submitting transaction data to the verification system may further comprise submitting at least one transaction code that was generated from a previous transaction between the person and the supplier.

In other variations, submitting transaction data to the verification system may further comprise submitting a request to purchase the product obtained on the trial basis, or submitting transaction data may include submitting an expiration date for termination of the person' s use of the product. Also, the method may comprise associating the new transaction code with the product to modify a current expiration date of the product. Modifying the current expiration date may comprise extending the expiration date, removing the expiration date, or shortening the expiration date.

Various aspects of the present invention may also be found in a verification system that, based upon at least a person's past dealings with a supplier, permits the person to continue using a product. The verification system often comprises a processor associated with a processor memory containing processor commands and a data memory containing data regarding transactions that a person has entered with a supplier. In addition, the verification system includes a first module disposed in the processor memory that receives data from the data memory such as transaction data regarding at least one transaction between the person and the supplier, the first module enabling the processor to generate a transaction code for the person, the transaction code being influenced by the transaction data of the at least one transaction between the person and the supplier, and the transaction code, when supplied to the product, enables the person to use the product.

Further, the verification system includes a controller that controls the flow of data from the data memory to the first module according to the processor commands. It should be noted that the transaction data of the verification system may comprise data regarding a purchase of a product by the person from the supplier.

Still other aspects of the present invention may be found m a method for a verification system to permit a person to use a software program indefinitely. The method comprises obtaining a software program, on a trial basis, from a vendor that operates with the verification system; utilizing the software program to determine if the person would like to use the software program other than on the trial basis; submitting transaction data to the verification system that pertains to the person, including data regarding past transactions of the person with the vendor; analyzing the transaction data, by the verification system, to determine prior transaction codes that the verification system has generated regarding previous transactions between the person and the vendor; and generating a new transaction code, by the verification system, regarding the current transaction, the code being at least partially dependent on the prior transaction codes that were generated by the verification system.

In this embodiment, submitting transaction data to the verification system comprises submitting data regarding a length of time that the person desires to use the software program. In addition, the method may further comprise supplying the new transaction code to the software program, verifying, by the software program, with the new transaction code, that prior software programs exist on a computer system associated with the software program, and configuring the software program according to predetermined permissions identified by the new transaction code. Also, submitting transaction data may further comprise submitting at least one transaction code that was generated from a previous transaction between the person and the vendor.

Other aspects of the present invention will become apparent with further reference to the drawings and specification which follow.

BRIEF DESCRIPTION OF THE DRAWINGS A better understanding of the present invention can be obtained when the following detailed description is considered in conjunction with the following drawings, in which: FIGURE 1 is a block diagram of an secure transaction system in accordance with an exemplary embodiment of the present transaction;

FIGURE 2 is a block diagram of a secure transaction system operating with respect to products other than software programs, in accordance with an exemplary embodiment of the present invention;

FIGURE 3 is a flow diagram of a method for a verification system according to an exemplary embodiment of the present invention; FIGURE 4 is a flow diagram of a method for providing secure transactions in accordance with an exemplary embodiment of the present invention;

FIGURE 5 is a secure transaction client-server system in accordance with an exemplary embodiment of the present invention;

FIGURE 6 is a flow chart of a method for providing for secure retail transactions in accordance with an exemplary embodiment of the present invention.

DETAILED DESCRIPTION OF THE DRAWINGS FIGURE 1 is a block diagram of a secure transaction system 100 operating across the Internet 102 with regard to the sale of software programs, m accordance with an exemplary embodiment of the present invention. The secure transaction system 100 includes at least a merchant system 104 and a customer system 106 (operated by a customer) . In the secure transaction system 100, software programs are available to the customer system 106 from various locations, including the merchant system 104 itself, a remote application server 108, or a storage media 110 (e.g., diskette, CD-ROM, etc.). Regardless of the source of the software program, the customer stores the program in a customer storage 112 of the customer system 106. Of note, although the software programs are available for the customer's use on the customer system 106, the software programs have limited functionality until "unlocked." If the customer desires greater functionality from the software program, the customer must unlock the software program. Unlocking a software program requires a code (herein referred to as a "transaction code") to be submitted to a customer application program 114 which, under the control of programming circuitry 116 of the customer system 106, unlocks the software program. Thus, to unlock a software program, the customer must first obtain a transaction code for that software program. In one embodiment, the customer contacts the merchant system 104 and submits a request to unlock some or all of the locked functionality of the software program. Programming circuitry 118 of the merchant system 104 receives this request and through a merchant application program 120 stored in a merchant storage 122, generates a transaction code for tne customer. The transaction code is generated both from the information supplied to the merchant system 104 and from a history of previous transaction code numbers 124 that have been generated for the customer. If the customer has entered previous transactions with the merchant system 104, generating a new transaction code requires the customer' s request to include the most recent previous transaction code. Thus, a new transaction code will not be generated by the merchant system 104 unless the customer supplies at least the previous transaction code. The merchant system 104 keeps a record of each transaction code that is generated for a customer and security of transactions is increased by requiring the customer to have the old transaction codes.

In another embodiment, the customer again contacts the merchant system 104 and submits a request to unlock some or all of the locked functionality of the software program. In this embodiment, the merchant system 104 generates a new transaction code for the customer without requiring the customer to submit an old transaction code. However, the new transaction code is generated, at least in part, from the prior transaction codes generated for the customer. The customer receives this new transaction code and then submits the new transaction code to the customer system 106. The customer application program 114 verifies that the customer has the prior transaction codes somewhere in the customer storage 112 and unlocks the software program on the customer system 106. Thus, a third party that fraudulently obtains a customer number will not be able to unlock software without having a complete transaction history of the customer. In addition, to unlock the software program, the third party could be required to have copies of software programs that were the subject of prior transactions between the customer and the merchant . With the secure transaction system 100, a customer is able to try out a software program without purchasing the program. The software program may cease operating after a particular time period, but the customer is aware that further use of the program can be purchas ϊd from the merchant. For example, the software program could be purchased (or licensed) for additional time, additional functionality, additional upgrades, etc. The secure transaction system 100 causes transactions to depend upon prior transactions that occur between the customer and the merchant system 104. Of course, although the secure transaction system 100 pertains to the sale of software programs, similar systems operate according the same principles. A general transaction according to principles of the present invention is illustrated in FIGURE 2.

FIGURE 2 is a block diagram of a secure transaction system 200 operating with respect to products other than software programs, in accordance with an exemplary embodiment of the present invention. The secure transaction system 200 includes a merchant system 202 and a customer system 204. Information is passed between the two systems in numerous manners, a telephone line 206 being shown for illustrative purposes.

For example, in operation, the secure transaction system 200 includes at least one product 208 in the customer system 204. This product 208 has at least partially locked functionality that the customer desires to unlock. In this example, the customer collects previous transaction codes 210 that have been generated for the customer by the merchant system 202. The codes could be gathered from papers, from a computer system, or otherwise. Regardless, the codes are submitted to the merchant system 202 for generation of a new transaction code. In this example, the codes are submitted across the telephone line 206 and a new transaction code is generated and passed to the customer across the telephone line 206. Once the new transaction code is received by the customer, the customer uses unlock functionality 212 to unlock the product. Of course, the customer system 204 and the unlock functionality 212 have an appropriate interface for operating an unlock processing 214 of the customer system 204. For example, the unlock processing 214 could be a computer and its interface is a keyboard. The customer enters the new transaction code into the unlock processing 214 and the new product is then unlocked by the customer system 204.

In this embodiment, secure transaction system 200 requires either the customer to provide prior transaction codes to the merchant system 202 to obtain a new transaction code, or the customer system 204 to contain reference to the prior transaction codes m order for the new transaction code to enable the disabled functionality of the product. In this manner, authentication of customer identity is enhanced and verification of the customer' s identity is required prior to enabling the product. FIGURE 3 is a flow diagram of a method for a verification system according to an exemplary embodiment of the present invention. In this embodiment, a customer obtains a product and tries it out 300. Frequently, when a customer is not sure whether he or she wants a product, a supplier provides the product to the customer on a trial basis. This enables the customer to actually hold or use the product in the environment that the product is to be used and, thus, make a decision based on actual use whether to purchase the product 302. If the customer decides not to purchase the product, the customer obtains a different product and tries it out 300. In the embodiment of FIGURE 3, the product operates for a predetermined period of time prior to ceasing operation for the customer. For purposes of the present disclosure, a product is said to be "locked" when its operation ceases. If the customer decides to purchase the product, the customer submits information to an unlocking facility 30^ . Typically, this information includes at least the following: a request for purchase of the product that the customer is using on a trial basis, the date and time of the person's decision to purchase the product, and a previous transaction code ("unlocking number") that the user obtained from the unlocking facility from a previous purchase. Thus, the unlocking facility is able to determine if the customer previously ordered from the supplier 306.

If the customer has not previously ordered from the supplier, the unlocking facility generates an initial unlocking number 308 for the customer. On the other hand, if the customer has previously ordered from the supplier, the unlocking facility generates a new unlocking number based on previous unlocking numbers 310. Regardless of whether the unlocking number is an initial unlocking number or a combination of previous unlocking numbers, the unlocking facility passes the unlocking number to the customer 312. The customer then uses this unlocking number to unlock the product 314 and use the product for a different amount of time than allowed by the trial basis parameters.

In this manner, the verification system enables a customer to obtain greater protection when purchasing a product from a supplier. For example, prior to unlocking the product, the unlocking number could be configured to verify that the customer has in their possession all prior products that have been purchased from the supplier. In other words, in one embodiment, the unlocking number is used to verify that the customer is the person they claim when the verification system locates other unlocking numbers on the customer' s premises that correspond to the other products that have been purchased by the customer. FIGURE 4 is a flow diagram of a method for providing secure transactions in accordance with an exemplary embodiment of the present invention. The method begins when a customer obtains a software program and tries it out at 400. Of course, the software program is typically installed onto the customer' s computer and the customer is able to use the software almost as though the customer purchased the software. In this manner, the customer is able to make a more educated decision as to whether to actually purchase the product at 402. If the customer decides not to purchase the software, the customer can obtain a different software program and try it out. On the other hand, if the customer decides to purchase the software, the customer must submit order information to an unlocking facility at 404.

Order information is not limited to, but could include information such as a request to purchase the software program for unlimited use, a request to purchase a license to use the product with certain restrictions, a request to discontinue use of the product, etc. The order information also contains prior purchase information regarding purchases that the customer has made from the vendor. This order information allows the verification system to determine whether the customer has previously ordered from the vendor at 406 and to either generate an initial locking number at 408 or a new unlocking number based on previous unlocking numbers at 410. Regardless of the type of unlocking number, the unlocking facility passes the unlocking number to the customer at 412 and the customer unlocks the software program using the unlocking number at 414. In this manner, the customer is able to create a transaction path with the vendor that makes future transactions between the customer and vendor simple to carry out yet more difficult to misappropriate. The transactions are simple to carry out because the verification system is able to create a new verification code (unlocking number) based on the immediately previous verification code. The transactions are more difficult to misappropriate because a third party cannot use a software program without duplicating each of the transactions that the cjstomer ever entered with the vendor and obtaining verification codes available only to the customer and the vendor.

In another embodiment, a customer that wants to make a purchase from a supplier uses traditional methods to verify their identity and to verify payment for the product. As a result, the customer is given a receipt number that is calculated from the data involved m the transaction, e.g., name, address, payment details, product details, and time and day of the transaction. In all additional transactions involving the customer, the customer supplies the same details as the first transaction along with the receipt number from the previous transaction. Since it is only the two parties that have the record of the initial transaction, the receipt number is not only a transaction-tracking tool but also a means of identification with the result that less information is needed to verify the customer's identity.

FIGURE 5 is a secure transaction client-server system 500 in accordance with an exemplary embodiment of the present invention. Secure transaction client-server system 500 may be used to conduct secure transactions over an unsecured network such as the Internet .

Secure transaction client-server system 500 includes secure transaction server 502, which is coupled to unsecured communications medium 504. Secure transaction client 506 is also coupled to unsecured communications medium 504. Secure transaction client 506 is operable to engage in a transaction with secure transaction server 502 in a manner that prevents a third party from intercepting confidential data from unsecured communications medium 504 that may be used to misappropriate goods or services from secure transaction server 502 or secure transaction client 506. Although a single secure transaction server 502 and secure transaction client 506 are shown, network principles may be used to accommodate a suitable number of secure transaction servers 502 and secure transaction clients 506. For example, multiple secure transaction clients 506 may be used, and server functionality may be divided between two or more secure transaction servers 502.

Secure transaction server 502 may be implemented in hardware, software, or a suitable combination of hardware and software, and may be one or more software systems operating on a general-purpose server platform. Secure transaction server 502 is operable to receive a code request and identification data from secure transaction client 506 over unsecured communications medium 504, and to generate a transaction data packet that includes the code and identification data in an encoded format. Secure transaction client 506 is operable to receive the transaction data packet, extract the identification data and code, and to use the code to perform a transaction.

Secure transaction server 502 includes request receiver 510. Request receiver 510 may be implemented in hardware, software, or a suitable combination of hardware and software, and may be a software system operating on a general purpose server platform and network interface device. Request receiver 510 is coupled to unsecured communications medium 504, and is operable to receive the transaction data packet from unsecured communications medium 504 and to transfer the transaction data packet to key generator 512. Request receiver 510 may also remove header data, routing data, and other data that may be used to transfer the transaction data packet over unsecured communications medium 504. Request receiver 510 may continuously monitor unsecured communications medium 504 for transaction data packets.

As used herein, the term "couple" may include a physical connection (such as a copper wire or data bus), a logical connection (such as through logical devices of a semiconductor component) , a virtual connection (such as through randomly assigned memory locations of a memory device) , or other suitable connections. Coupling may likewise be accomplished through a suitable combination of such connections, and may including intervening components.

Secure transaction server 502 also includes key generator 512. Key generator 512 may be implemented in hardware, software, or a suitable combination of hardware and software, and may be a software system operating on a general-purpose server platform. Key generator 512 is coupled to request receiver 510, code and data storage 508, and key transmitter 514, and receives the transaction data packet from request receiver 510. Key generator extracts the code request and the identification data from the transaction data packet, and first verifies whether the identification data is present m code and data storage 508. If the identification data is present, key generator uses previous codes that have been transmitted to the secure transaction client 506 that is presently requesting the new code to encode the key that contains the new code that will be transmitted to the secure transaction client. Key generator 512 also stores the new code in a relational database, such that it will be possible to determine that the new code has been transmitted for future code requests.

If the identification data is not present in code and data storage 508, key generator 512 stores the identification data in a relational database with the new code. Key generator 512 then uses the code data and identification data to generate a key for transmission to the secure transaction client 504. For example, key generator 512 may concatenate the code data and the identification data into a data string, and then may perform data processing on the data string to reduce it to a predetermined number of characters. Alternatively, key generator 512 may perform data processing on each of the codes and the identification data, and may concatenate the processed data into a data string having a variable length and predetermined format. Other suitable processes may also or alternatively be used. Key generator 512 transfers the key to key transmitter 514.

Key transmitter 514 may be implemented in hardware, software, or a suitable combination of hardware and software, and may be a software system operating on a general purpose server platform and network interface device. Key transmitter 514 is coupled to unsecured communications medium 504, and is operable to receive the key from key generator 512 and to transfer the key over the unsecured communications medium to secured transaction client 505. Key transmitter 514 may also append header data, routing data, and other data that may be used to transfer the key over unsecured communications medium 504.

Unsecured communications medium 504 may be the Internet, a wide-area network, a local-area network, or other suitable communications media that are characterized by a technical constraint on the ability to prevent third parties from accessing communications channels. For example, unsecured communications medium 504 may include a wireless communications medium having synchronous transfer mode channels that can be intercepted by third parties, an asynchronous transfer mode medium having variable-sized packets that can be intercepted by third parties, or other suitable unsecured communications media .

Secure transaction client 506 may be implemented in hardware, software, or a suitable combination of hardware and software, and are preferably one or more software systems operating on a general purpose-computing platform. Secure transaction client 506 is coupled to unsecured communications medium 504, and is operable to generate a code request and to transmit the code request to a secure transaction server 502 over unsecured communications medium 502. Secure transaction client 506 is also operable to receive a key from secure transaction server 502, and to extract the requested code from the key after performing predetermined operations on the key.

Secure transaction client 506 includes code requester 520.

Code requester 520 may be implemented in hardware, software, or a suitable combination of hardware and software, and may be a software system operating on a network interface device and general purpose computing platform. Code requester 520 is coupled to program storage 526, code and data storage 524, and unsecured communications medium 504. Code requester 520 is operable to receive user-entered data, such as a software package selection, and to assemble a transaction data packet to request an access code in response to the user-entered data. For example, code requester 520 may interface with program storage 526 to present a user with a menu of available programs, and with code and data storage 524 to show the user which programs have already been purchased. After the user selects a program, code requester 520 formulates a code request for that program and transmits the code request to the secure transaction server 502 in the form of a transaction data packet. The code request may include identification data, such as the name, address, telephone number, and other similar data of the user, program name and serial number, and other suitable data .

Program storage 526 may be implemented in hardware, software, or a suitable combination of hardware and software, and may be an optical or magnetic storage media that holds one or more encoded software systems. Program storage 526 may allow a user to access limited functionality of one or more software systems, so as to allow the user to test the software system for applicability, ease of use, or other features. Code and data storage 524 may be implemented in hardware, software, or a suitable combination of hardware and software, and may be a magnetic data storage device. Code and data storage 524 is coupled to code requester 520 and code verifier 522, and is operable to store codes that are used to unlock features of software systems, user information, and other suitable commerce-related data.

Key receiver 516 may be implemented in hardware, software, or a suitable combination of hardware and software, and may be a software system operating on a network interface and general purpose computing platform. Key receiver 516 is coupled to unsecured communications medium 504 and key analyzer 518, and is operable to receive the key from unsecured communications medium 504 and to transfer the key to key analyzer 518. Key receiver 516 may also remove header data, routing data, and other data that may be used to transfer the key over unsecured communications medium 504. Key receiver 516 may continuously monitor unsecured communications medium 504 for keys, or may alternatively be configured to monitor unsecured communications medium 504 for a key at a predetermined time after the transmission of the transaction data packet with the code request from code requester 520.

Key analyzer 518 may be implemented in hardware, software, or a suitable combination of hardware and software, and may be a software system operating on a general purpose computing platform. Key analyzer 518 is coupled to key receiver 516 and code verifier 522, and receives the key from key receiver 516.

Key analyzer then performs a predetermined operation on the key so as to extract the identification data and the code data. For example, the identification data and code data may be concatenated and data processed, in which case key analyzer performs an inverse data processing function on the key to extract the identification data and the code data. Alternatively, the identification data and code data may be separately processed, such that key analyzer 518 first parses the key, then processes each part of the parsed key to extract the identification data and the code data. The identification data and code data are then transferred to code verifier 522.

Code verifier 522 may be implemented in hardware, software, or a suitable combination of hardware and software, and may be a software system operating on a general purpose computing platform. Code verifier 522 is coupled to key analyzer 518, code and data storage 524, and program unlocker 530. Code verifier 522 receives the code or codes and identification data from key analyzer 518, and verifies whether all existing codes in code and data storage 524 are present. For example, the key received from secure transaction server 502 may include three codes that were previously transmitted to the secure transaction client 506. All three of these codes will be present in code and data storage 524. Code verifier 522 is operable to receive these codes from code and data storage 524, to compare the codes, and to transmit the new, requested code to the program unlocker if all codes are present. A similar process may also be performed using the identification data. In this manner, the only secure transaction client 506 that may use the transmitted code is the secure transaction client 506 that requested the code. Program unlocker 530 may be implemented m hardware, software, or a suitable combination of hardware and software, and may be a software system operating on a general purpose computing platform. Program unlocker is operable to interface with operating system 528 such that operating system 529 may implement the requested program from program storage 526. For example, program unlocker 530 may transmit a run command that contains the name of the program and the code to operating system 528. Operating system 528 may then retrieve the program from program storage 526 and may initiate the program using the code such that the fully-functional program runs instead the limited functionality program, for those situations where a limited functionality program is provided for a trial period. Program unlocker 530 may also store the key in the unlocked program such that any subsequent unauthorized duplications may be tracked to the user that requested the key.

Operating system 528 may be implemented in hardware, software, or a suitable combination of hardware and software, and is preferably an operating system of a general purpose computing platform. Operating system 528 performs standard operating system functions, such as loading programs, allocating hardware and software resources, monitoring program execution, and de-allocating resources after program completion.

In operation, secure transaction client-server system 500 is used to control confidential data by using historical data that is common to secure transaction server 502 and secure transaction client 506 to authorize additional transactions between secure transaction server 502 and secure transaction client 506. In this manner, the key transmitted to any secure transaction client 506 may only be used by that specific user.

If the key is stored in the enabled program, it is also possible to track unauthorized copies of the program back to the last authorized user. In this manner, unauthorized use and duplication of programs may be prevented or detected.

FIGURE 6 is a flow chart of a method 600 for providing for secure retail transactions in accordance with an exemplary embodiment of the present invention. Method 600 may be used to allow consumers to make repeated retail purchases without requiring them to repeatedly transmit sensitive data, such as a credit card number, over an unsecured communications medium. Method 600 begins at 602, where a customer places an order for a product, such as by transmitting an order message from a computing platform that, is coupled to a communications medium such as the Internet to a transaction server. The method then proceeds to 604, where it is determined whether an order has previously been placed by the customer. For example, a software system operating on the customer' s computing platform, such as HTML code, may check for the presence of a data file on the customer's computing platform data storage mechanism. Alternatively, the transaction server may receive the customer order and determine whether the customer has previously ordered based upon data included in the customer order. If it is determined at 604 that the customer has not previously ordered, the method proceeds to 606. At 606, the customer is registered. For example, a display containing registration questions may be generated, and the customer may be prompted for suitable information, such as name, address, telephone number, and other secondary contact information. The method then proceeds to 608, where payment data is received over a secure communications medium. For example, the payment data may be a credit card number and expiration data that is encrypted and transmitted over the Internet, that is transmitted over a dedicated public switched telephone network connection, or other suitable secure communications media. The method then proceeds to 610 where purchase data and an associated code are transmitted to the purchaser. For example, the purchase data may be a product number, and the code may be a randomly generated code. The method then proceeds to 612, where the purchase data and code are stored at the customer location, such as in a data file on a computing platform. The purchase data and code are also stored at the transaction server. If it is determined at 604 that the customer has previously ordered, the method proceeds to 614 where an authorization code is transmitted to the customer that is based on previous purchases and associated codes. For example, the previous purchases and codes transmitted to the customer may be stored at the transaction server and on the customer' s computing platform, such that the transaction server can determine the codes and purchases that should be on the customer's computing platform. The method then proceeds to 616 where the customer generates a response based on the previous purchases and transaction codes. For example, the customer may receive HTML code such as by receiving a web page for execution on an Internet web browser software system. This HTML code may be executed by the customer' s computing platform to create a software system that extracts purchase data and codes and generates the response for transmission to the transaction server. The method then proceeds to 618.

At 618, the authorization response is received, and it is determined at 620 whether the response is acceptable. For example, the response may be compared to the expected response at the transaction server. If it is determined that the response is acceptable, the method proceeds to 622 where the purchase is charged to the account that has previously been provided by the user. The method then proceeds to 624 where the product is shipped.

If it is determined at 620 that the response is not acceptable, the method proceeds to 626 where an error message is sent. For example, the transaction server may transmit an error message notifying the consumer that the system is temporarily busy. The method then proceeds to 628 where the customer is contacted via a secondary medium to determine whether the attempted purchase was made by an unauthorizeα user . In operation, method 600 is used to provide for secure retail transactions using the transaction history of the consumer. When a consumer purchases a product or products, a code is transmitted with product data. The code and product data are stored by the consumer, such as on a data storage device of the consumer' s computing platform. The code and product data are also stored at a centralized location, such as a transaction server. When the consumer makes another purchase, an authorization code is generated using the product data and codes associated with the consumer' s previous purchases. In this manner, the consumer may be identified without having to provide sensitive data, such as a credit card number and expiration data, over a communications medium.

These embodiments m no way limit the customer from trying out multiple products at the same time and deciding to purchase some products while deciding not to purchase other products.

The above-listed sections and included information are not exhaustive and are only exemplary. The particular sections and included information in a particular embodiment may depend upon the particular implementation and the included devices and resources. Although a system and method according to the present invention has been described in connection with the preferred embodiment, it is not intended to be limited to the specific form set forth herein, but on the contrary, it is intended to cover such alternatives, modifications, and equivalents, as can be reasonably included within the spirit and scope of the invention as defined by the appended claims.

Claims

CLAIMS What is claimed is:

1. A secure transaction system comprising: previous transaction data; a first processing system that stores the previous transaction data; a second processing system that stores the previous transaction data; the second processing system having at least one disabled function; the first processing system using at least the previous transaction data to generate a current transaction code; and the second processing system using the current transaction code and the previous transaction data to enable one or more of the at least one disabled functions of the second processing system.

2. The secure transaction system of claim 1 wherein said previous transaction data comprises at least one transaction code.

3. The secure transaction system of claim 1 wherein the first processing system comprises a merchant system.

4. The secure transaction system of claim 1 wherein the second processing system comprises a customer system.

5. A method for a verification system to permit a person to continue using a product based upon the person' s past dealings with a supplier, \:he method comprising: obtaining a product, on a trial basis, from a supplier that implements the verification system in product transactions; utilizing the product to determine if the person would like to use the product indefinitely; submitting transaction data to the verification system that pertains to the person, including data regarding past transactions of the person with the supplier; analyzing the transaction data, by the verification system, to determine prior transaction codes that the verification system has generated regarding previous transactions between the person and the supplier; and generating a new transaction code, by the verification system, regarding the current transaction, the code being at least partially dependent upon the prior transaction codes that were generated by the verification system.

6. The method of claim 5 further comprising: supplying the new transaction code to the product; and verifying, by the product, with the new transaction code, that prior products obtained by the person through previous transactions with the supplier are associated with the product.

7. The method of claim 5 wherein said obtaining the product comprises obtaining a software program.

8. The method of claim 5 wherein said generating the new transaction code comprises combining, with an algorithm, the transaction data and any immediately prior transaction codes.

9. The method of claim 5 wherein said generating the new transaction code comprises generating a software license code.

10. The method of claim 5 wherein said submitting transaction data to the verification system further comprises submitting at least one transaction code that was generated from a previous transaction between the person and the supplier.

11. The method of claim 5 wherein said submitting transaction data to the verification system further comprises submitting a request to purchase the product obtained on the trial basis.

12. The method of claim 5 wherein said submitting transaction data includes submitting an expiration date for termination of the person's use of the product.

13. The method of claim 12 further comprising associating the new transaction code with the product to modify a current expiration date of the product.

14. The method of claim 13 wherein modifying the current expiration date comprises extending the expiration date.

15. The method of claim 13 wherein modifying the current expiration date comprises removing the expiration date.

16. The method of claim 13 wherein modifying the current expiration date comprises shortening the expiration date.

17. A method for a verification system to permit a person to use a software program indefinitely, the method comprising: obtaining a software program, on a trial basis, from a ^■vendor that operates with the verification system; utilizing the software program to determine if the person would like to use the software program other than on the trial basis; submitting transaction data to the verification system that pertains to the person, including data regarding past transactions of the person with the vendor; analyzing the transaction data, by the verification system, to determine prior transaction codes that the verification system has generated regarding previous transactions between the person and the vendor; and generating a new transaction code, by the verification system, regarding the current transaction, the code being at least partially dependent on the prior transaction codes that were generated by the verification system.

18. The method of claim 17 wherein said submitting transaction data to the verification system comprises submitting data regarding a length of time that the person desires to use the software program.

19. The method of claim 17 further comprising: supplying the new transaction code to the software program; verifying, by the software program, with the new transaction code, that prior software programs exist on a computer system associated with the software program; and configuring the software program according to predetermined permissions identified by the new transaction code .

20. The method of claim 17 wherein said submitting transaction data further comprises submitting at least one transaction code that was generated from a previous transaction between the person and the vendor.

21. A method for providing for secure retail transactions comprising: transmitting product data to a consumer when a first purchase is made; using the product data to generate an authorization code; transmitting the authorization code to the consumer when a second purchase is requested; receiving a response from the consumer; and verifying that the response is acceptable.

22. The method of claim 21 wherein verifying that the response is acceptable comprises: generating an expected response; comparing the expected response to the response received from the consumer; and determining that the response received from the consumer is acceptable if the expected response is identical to the response received from the consumer.

23. The method of claim 21 further comprising charging the second purchase to a stored account if it is determined that the response is acceptable.