Transactional security over a network
9 claims: 2 independent, 7 dependent
- 1Claims 1. A method comprising:encrypting customer information in an encryption stream (414), wherein said customer information comprises at least one of a name identifier, a customer age identifier, an address identifier, and a customer agreement identifier (steps 702, 704);causing said encryption stream to be transferred from a customer (410) to a merchant (450) in a purchase transaction fór a purchased electronic item (step 706);causing said encryption stream to be routed to EP 2 191 406 Β1 a verification entity (420) (step 708);producing, by said verification entity (420), a unique transaction identifier comprising at least one ofan identity verification and a payment authorization, based on said encryption stream (steps 710, 712);modifying, by said verification entity (420), said encryption stream to include said unique transaction identifier;transferring, by said verification entity (420), the modified encryption stream and said unique transaction identifier to said merchant (450), wherein said modified encryption stream and said unique transaction identifier are devoid of personal payment information ofsaid customer (410) (step 714);causing said modified encryption stream (414) to be added, by said merchant (450), to said purchased electronic item to create a personalized electronic item (454) (steps 716, 718);and causing said personalized electronic item to be supplied from said merchant (450) to said customer (410) (step 720), wherein each personalized electronic item (454) supplied to different customers is different because ofa uniqueness of each modified encryption stream.
- 9A system comprising:an encoder (412) positioned within a customer computer (410), wherein said encoder is adapted to encrypt customer information in an encryption stream (414), wherein said customer information comprises at least one of a name identifier, a customer age identifier, an address identifier, and a customer agreement identifier;a transfer agent (416) positioned within said customer computer, said transfer agent causing said encryption stream (414) to be transferred from said customer computer to a merchant computer (450) in a purchase transaction for a purchased electronic item;a verifier (424) operatively connected to said merchant computer, wherein said verifier is separate from said customer computer and from said merchant;and a database (430) comprising said customer information operatively connected to said verifier, wherein said transfer agent (456) is adapted to cause said encryption stream to be transferred from said merchant computer to said verifier, wherein said verifier (424) is adapted to gener18 EP 2 191 406 Β1 ate a unique transaction identifier comprising an identity verification and/or a payment authorization, based on said database, to modify said encryption stream to include said unique transaction identifier, and to transfer the modified encryption stream and said unique transaction identifier to said merchant (450), wherein said modified encryption stream and said unique transaction identifier are devoid ofsaid personal payment information ofsaid customer, wherein the modified encryption stream (414) is adapted to be added, by said merchant, to said purchased electronic item to create a personalized electronic item (454) to be supplied from said merchant to said customer (410), and wherein each personalized electronic item (454) supplied to different customers is different because ofa uniqueness of each modified encryption stream.
Independent claims4
169 paragraphs in 4 sections, as filed
(54)
Tranzakciós biztonság egy hálózaton
Az európai szabadalom ellen, megadásának az Európai Szabadalmi Közlönyben való meghirdetésétől számított kilenc hónapon belül, felszólalást lehet benyújtani az Európai Szabadalmi Hivatalnál. (Európai Szabadalmi Egyezmény 99. cikk(1))
A fordítást a szabadalmas az 1995. évi XXXIII. törvény 84/H. §-a szerint nyújtotta be. A fordítás tartalmi helyességét a Szellemi Tulajdon
Nemzeti Hivatala nem vizsgálta.
(12) (45) (19)
<img file="HUE034341T2_D0001.tif" />
Eurepaisehes Patenta mi
European Patent Office
Office européen des brevets
<img file="HUE034341T2_D0002.tif" />
EP 2 191 406 Β1
EUROPEAN PATENT SPECIFICATION (21) (22)
<td> Date of publication and mention</td><td> (51)</td><td> IntCI.:</td>
<td> of the grant of the patent:</td><td></td><td> G06F 21100 <<sup>2013 01</sup>></td>
<td> 19.04.2017 Bulletin 2017/16</td><td> (86)</td><td> International application number:</td>
<td> Application number: 07841796.1</td><td></td><td> PCT/US2007/077503</td>
<td> Date of fiiing: 04.09.2007</td><td> (87)</td><td> International publication number: WO 2009/029116 (05.03.2009 Gazette 2009/10)</td>
(54) TRANSACTIONAL SECURITY OVER A NETWORK TRANSAKTIONSSICHERHEIT ÜBER EIN NETZWERK SÉCURITÉ DES TRANSACTIONS SUR UN RÉSEAU (84) Designated Contracting States: (72)
AT BE BG CH CY CZ DE DK EE ES FI FR GB GR HU IE IS IT Ll LT LU LV MC MT NL PL PT RO SE Sl SK TR (74) (30) Priority: 24.08.2007 US 844408
Inventor: CARROTT, Richard, F. Moorpark, CA 93021-3552 (US)
Representative: Gill Jennings 8i Every LLP The Broadgate Tower 20 Primrose Street London EC2A 2ES (GB) (43) Date of publication of application:
02.06.2010 Bulletin 2010/22 (73) Proprietor: Benedor Corporation Moorpark, CA 93021-3552 (US) (56)
References cited:
EP-A- 0 773 490 US-A- 6 078 902 US-A1-2003 161 473
WO-A-98/40809 US-A1-2002 069 177
ΕΡ2 191 406 Β1
Note: Within nine months ofthe publication ofthe mention ofthe grant ofthe European patent in the European Patent Bulletin, any person may give notice to the European Patent Office of opposition to that patent, in accordance with the Implementing Regulations. Notice of opposition shall nőt be deemed to have been filed until the opposition fee has been paid. (Art. 99(1) European Patent Convention).
Printed by Jouve, 75001 PARIS (FR)
EP 2 191 406 Β1
Description
Cross-Reference To Related Applications [0001] This application is a continuation-in-part of presently pending U.S. Application Serial Number 10/970,051, entitled METHOD AND APPARÁTUS TO PROVIDE SECURE PURCHASE TRANSACTION OVER A COMPUTER NETWORK, filed on October 21, 2004, which is a continuation of U.S. Patent Application Serial Number 09/726,304 filed on December 1, 2000, which has issued as U.S. Patent Number 6,839,692. [0002] This application alsó claims the priority of presently pending provisional application 60/890,230 entitled ENCRYPTED INDIVIDUAL AGREEMENT IDENTIFIERS TO ACQUIRED MEDIA OR MEDIA CONTENT, filed on February 16, 2007.
BACKGROUND AND SUMMARY
Field of the Invention [0003] The embodiments ofthe invention generally relate to securing eCommerce and similartransactional relationships, including the sales of goods and Services, between parties over computer networks such as the Internet and to tracking of distributed electronic items, such as electronic documents, electronic presentations, electronic works and to methods and systems forstoring encrypted individual agreement identifiers within the distributed electronic items.
[0004] US-A-6078902 discloses a transaction method wherein a user transmits encoded personal payment information relating to a transaction to a clearing Office. The clearing Office issues a transaction identification code to the user, who then forwards the code to the vendor. The vendor retransmits the code to the clearing Office which checks that the code is valid and, if so, sends an acknowledgement to the vendor, allowing the transaction to proceed.
[0005] US-A-2003/0161473 discloses a system fordistributing encrypted content wherein a content distributor watermarks contentwith arhitrary data so thatthe content can be traced.
I. Background and Summary of Original Disclosure Application Serial Number 10/970,051 and U.S. Patent Number 6,839,692 Priority Date: December 1, 2000 [0006] The present invention generally relates to a system for providing security for purchase transactions made over a network and more particularly to an improved security system that only Stores and provides encrypted information. Additionally, the invention relates to a system for providing customer controlled rules, including time and value limits, for purchase transactions made over a network.
[0007] The increase in popularity of personal computers and of networks connecting personal computers has caused a dramatic increase in electronic commerce (eCommerce) in recent decades. One example of a very popular network is the World Wide Web (WWW) or Internet. However, one aspect that has been hampering ecommerce is the inability to provide a convenient and secure payment system.
[0008] Many conventional e-commerce payment systems require elaborate passwords/encoding algorithms that are cumbersome and nőt user-friendly. Other conventional e-commerce payment systems require all parties involved to agree on a security formát. Such systems sufferfrom the disadvantage that only those parties that have joined the club and have agreed to the specific encoding formát can participate. Considering the rate at which merchant sites are being added and withdrawn from current networks (e.g., Internet), requiring merchants to agree on a specific formát is unrealistic. [0009] Other e-commerce payment systems require prepayments to a third-party vendor that, in turn, issues a coded credit against that deposit. Besides creating yet another layer to online transactions, these wallet and Internet cash programs alsó create another layer of exposure forthe customer’s information. Additionally, these systems require that both the customer and merchant register to participate in the various versions of these systems.
[0010] Still other e-commerce payment systems require the userto purchase specific hardware (e.g., a credit card reader) that is proprietary in natúré and awkward to install and use. In addition, the user is required to transport the hardware device if purchases are to be made at other computers, which hampers this type of payment system.
[0011] No matter the payment system, the common thread shared by conventional systems is that the customer must provide priváté information in order to complete a transaction -- to the merchant, to a potential thirdparty, and to the merchant’s financial institution. This requirement is the biggest impediment to conventional systems because ofthe exposure to the customer, perceived or otherwise. Whether the customer obtains additional hardware or merely entrusts priváté information to thirdparty vendors, the customer’s information ends up stored in someone else’s database. The vulnerability of these stored records is a matter of deep concern to potential customers and to policy makers.
[0012] The problem is a matter of how many times a customer must expose priváté, sensitive, and/or confidential information in order to transact business over a network environment such as the Internet.
[0013] lt is, therefore, an object ofthe present invention to provide a structure and method of securing purchase transactions over a computer network. The invention encrypts customer information as a customer code on a storage device on a customer computer (the customer computer is connected to the computer network). Then the invention supplies the customer code to a merchant
EP 2 191 406 Β1 in a purchase transaction over the computer network and forwards.orallows the merchant to forward, the customer code to a financial institution over the computer network. The financial institution decrypts the customer code, verifies the information, and returns a purchase authorization decision to the merchant over the computer network. [0014] An important feature ofthe invention is that encoded customer information, such as credit card numbers (customer code), is nőt available to merchants and, therefore, is nőt vulnerable to the merchant’s security or privacy entrustments. The customer code is stored on the customer’s storage device only, and it is in encrypted form. This ailows the customer to complete merchant transactions without revealing certain of the encrypted information to the merchant, such as credit card numbers. The financial institution compares, inter alia, the customer address with historic address information of the customer maintained by the financial institution. Customers may maintain more than one authorized shipping address. The purchase authorization decision is approved only ifthe customer address and the historic address are consistent. If authorization is nőt approved, on the basis of incorrect address information, the options to the financial institution include: 1) approving the transaction with the corrected address; 2) approving the transaction subject to the customer updating his/her address information prior to the issuance of the authorization code; and, 3) declining authorization.
[0015] Securing the customer’s information before it is exposed to a network environment ailows the customer to retain control and expand the use of his/her credit facility online. This is a paramount difference between the present invention and conventional e-commerce payment systems.
[0016] The present invention ailows the customer to access his/her information by means of a personal key, oraccess code, howeveronly the financial institution and its agents possess the decryption key, or code. Thus, the invention provides secure use ofthe customer’s information without adding layers or third-parties and without exposing that information to a myriad of databases. In the preferred embodiment, the customer code includes encrypted credit card information.
[0017] In an additional embodiment, the invention can encrypt many customer codes on the storage device. Each of the customer codes can include a unique payment method. Alternatively, one group of the customer codes can identify a single credit organization for payment, wherein each customer code in the group includes a different user name. This ailows each customer code in the group to include unique credit limits and ailows the customer to authorize additional users for a single credit organization orfacility. The invention alsó uses a password on the customer computer to unlock the customer code.
[0018] In another embodiment, the invention comprises a system that operates on a customer computer. The inventive system includes an encrypter adapted to encrypt customer information as a customer code on a storage device on the customer computer and a populator adapted to supply the customer code to a merchant in a purchase transaction over the computer network. The customer computer includes a network connection adapted to forward the customer code to a financial institution over the computer network. The financial institution decrypts the customer code and returns a purchase authorization decision to the merchant over the computer network.
[0019] The customer code preferably includes encrypted customer address information, and the system further comprises a comparator located at the financial institution. The comparator compares the customer address with a historic address ofthe customer maintained by the financial institution. The purchase authorization decision is approved only ifthe customer address and the historic address are consistent.
[0020] The system can optionally include an intermediate code confirmation site, external to the customer computer, and connected to the computer network. The intermediate code confirmation site receives the customer code prior to forwarding the customer code to the financial institution over the computer network. The intermediate confirmation site confirms whether the customer code has a proper encryption formát.
[0021] The encrypter can alsó encrypt a plurality of customer codes on the storage device. As mentioned above, each ofthe customer codes can include a unique payment system or a group of the customer codes can identify a single credit organization for payment. Each customer code in the group can have a different user name and unique credit limits. The inventive system alsó includes a graphic user interface that can récéivé a password on the customer computer to unlock the customer code.
II. Background and Summary of Continuation-ln-Part Disclosure Claiming Priority to U.S. Provisional Application 60/890,230 Priority Date: February 16, 2007 [0022] The Internet has changed the way people communicate and the way they do business. With that change, the way of doing things on the Internet has alsó evolved. As computers and technology opened a new éra, software was packaged on disks and sold. Downloadable or otherwise transferable média, such as digital musicand movies, soon followed. This activity led certain individuals and groups to seek ways to profit from the unauthorized copying and sale of these products, which became two basic businesses - one that sought to profit by pirating the works of others and another that tried to prevent the pirates’ activity. As the Internet continues to evolve, more and more of this média content is being downloaded and shared, creating another layer of complexity and another area of concern.
[0023] Similarly, content sensitive websites, such as those related to the aduit industry and, until recently, the
EP 2 191 406 Β1 gaming industry, both gained in popularity and have become a bane to regulation because ofthe natúré ofthe Internet and its lack of a single jurisdiction and enforceable standards. Efforts have been launched - expensive and complex efforts - to impose self-regulation and prosecution; however, protecting minors and regulating commerce overwhat is arguably an international jurisdiction has proven difficult at best. The compound problem is how to regulate a structure that does nőt have a conventional piacé of business without violating the rights of the individuals and of the groups who, depending upon the jurisdictions in which they reside, may have varying degrees of privacy rights and legal protections that must be balanced against any effort to regulate virtual-jurisdiction and commerce over the Internet. Virtual commerce over a Virtual environment creates a need to establish agreements as to rights and jurisdiction for the protection and prosecution of those rights. However, the natúré of eCommerce creates an additional need to identify the consumer, while protecting that consumer’s identity from identity theft and identity fraud, and while protecting the transaction for both the consumer and the merchant.
[0024] Currently, the vendor bares much of the risk in an Internet transaction. lf a minor has borrowed a parent’s credit card, debit card, or prepáid card, if someone has stolen another person’s identity, if someone has misrepresented their age as a ploy to enter a restricted site; then, the vendor’s claim for payment may be denied. All of these things represent a reál problem for the eCommerce merchant who seeks compensation for what they offer because that merchant assumes the risk for a transaction, nőt the issuing bank, where there is no signed receipt - no signature present. The result from this is millions of dollars of fraud, repudiation, and chargebacks of transactions, which raise the costs and risks for all. [0025] In view ofthe foregoing, this disclosure presents a method, system, and structure that creates, records, verifies, and makes a storable version of a consumer’s encrypted individual agreement identifiers that can be, among other things, embedded with média purchased or otherwise acquired over a computer network and onto the transactional authorization, receipt and/or record of sale, creating a person present/signature present verifier.
[0026] The method includes the use of any or all user encrypted agreement identifiers, which are created before or during storage to the user’s hard drive orotherwise similar purpose computer storage system. The method and system includes allowing encrypted agreement identifiers to be used without revealing certain ofthe encrypted information, such as name, address, or credit/debit/prepaid card numbers, to the vendorwithwhom a transaction, for instance the purchase of média, is being conducted. In other words, the need to consistently register and expose a consumer’s identity and information with vendors and their databases is eliminated with embodiments herein.
[0027] The method and system allows the encrypted agreement identifiers to be used as a means of verifying user acceptance of qualified terms of use and purchase, in a way that can alsó be embedded in downloadable média. The method and system creates and Controls subaccounts with unique user reporting and corresponding password identifiers. The method and system places the control responsibility for an account and any sub-accounts with the primary authorized/registered user. The encrypted identifiers enable a method and system for securing and limiting the access and use of the média acquired to the use, terms, and privilege for which itwas acquired, thus allowing for the agreed enforcement of copyrights and other protections.
[0028] More specifically, this disclosure presents a system and method offacilitating computerized purchase transactions of electronically storable items (which are sometimes referred to herein as electronic items) such as literary works, musical works (recordings), and videó works (movies, shows, videós, etc.) wherein the consumer agrees to enforcement ofadhering rights, such as copyrights.
[0029] The embodiments herein encrypt customer information in an encryption stream (which is sometimes referred to as a customer identifier (CID) code). Such customer identifier information may comprise a name identifier (which may or may nőt be the customer’s formai name), a possibie customer age identifier (which can be a birthdate, a specific age, an age rangé, an age classification), a possibie address identifier (which can be a customer’s address or a different address), and a customer agreement identifier that contains or identifies the contractual agreement between the customer and a verification entity or financial institution (credit issuer) that will facilitate the purchase transaction.
[0030] lt is possibie that once the elements of an encryption stream are identified and agreed upon, a single, unique identifier may be employed by the verification entity to locate and identify that specific stream of customer information (including a computer identifier). The customer information is stored only in the verification database and only the identifier and the at-point-of-sale computer identifier can be transmitted as the encryption stream (together with non-encrypted BIN or credit issuer routing number) to the vendor.
[0031] One intent ofthe program and the participants is to create a signature present verified transaction that may be relied upon by all parties to the transaction while allowing identity protection for the customer.
[0032] The embodiments herein cause the encryption stream to be transferred from the customer to a merchant in the purchase transaction for the purchased electronic item. The verification entity, which may be the credit issuer or the credit issuer’s processor or agent (e.g., the verification entity), receives the encryption stream which (in combination with the purchase price) is sent by the merchant for identity verification and payment authorization prior to payment Processing. Then, the verification
EP 2 191 406 Β1 entity cross-references the encryption stream against a separate database containing the customer information to produce the identity verification and payment authorization. Then, the verification entity transfers the identity verification and payment authorization to the merchant, who completes the transaction with the customer and processes the transaction for payment as a signature present verified transaction by pre-agreement of all parties.
[0033] The identity verification and payment authorization confirms to the merchant the actual presenee of the customer in the purchase transaction, such that the merchant is provided assurance that the merchant is nőt transacting with any entity other than the customer and that the customer has agreed to be bound by the terms ofa transaction verified under the custom er-credit issuer agreement. The customer-credit issuer agreement anticipates the use of and reliance upon that agreement in third party transactions, in part, in exchange for identity protection and the convenience of the embodiments herein.
[0034] With embodiments herein, the encryption stream contains identifiers - nőt necessarily the personal customer information - that have been agreed upon by and between the customer and the credit issuer (e.g., bank), and the identity verification and payment authorization contains information limited to a unique transaction, as anticipated and agreed upon by and between the customer and the credit issuer. Such identifiers would be of little use even ifthe encryption stream is decrypted. [0035] Another feature of embodiments herein is that the encryption stream, or transaction verification, may be added, by the merchant, to a purchased electronic item, such as downloadable digital média, to create a personalized electronic item. The encryption steam or unique transaction verification (collectively or separately sometimes referred to herein as the transaction identifier) can be hidden, so that the customer is unable to remove the transaction identifier from the personalized electronic item. Further, the personalized electronic item could be made non-functional (so that the personalized electronic item cannot be opened, or cannot be played, etc.) ifthe encryption stream or transaction identifier, in part or in whole, is ever removed. Thus, the personalized electronic item always maintains the transaction identifier and allows the customer who purchased the electronic item to be identified (through the verification entity). Additionally, the transaction identifier is added in such a way that all copies ofthe purchased electronic item will have the transaction identifier. Thus, because all copies ofthe personalized electronic item will have the transaction identifier, the customer who originally purchased the electronic item from the merchant (the source of the copies) can always be identified through reference to the verification entities secure database. The transaction identifier is what is returned by the verifying entity and, because it is a unique identifier, may alsó be usable as a média embedded identifier.
[0036] After the transaction identifier is added to the purchased electronic item to create the personalized electronic item, the personalized electronic item is supplied from the merchant to the customer. Each personalized electronic item distributed to different customers is different because ofthe uniqueness ofeaeh different transaction identifier, which allows the customer who originally purchased the electronic item to be identified in copies of the item. Further, the uniqueness of each transaction identifier permits the source of unauthorized copies ofthe purchased electronic item to be identified through the secure database maintained by the verification entity.
[0037] During customer registration (when the customer is setting-up or modifying their account with the credit issuer) and during the purchase of electronic items, the customer can be provided with a notice or warning that their information will always remain with copies of any personalized electronic items. In addition, during the purchase of an electronic item, a similar notice or warning can be displayed informing the customer that he/she is agreeing to be bound bytheterms and penalties provided for unauthorized use or copying of the electronic item; and, each time (or the first few times) the personalized electronic item is opened, played, etc. the same warning may be displayed. Such continuous warnings may or may nőt be applicable to certain downloadable média such as music. Such warnings are intended to discourage the customerfrom supplying copies ofthe personalized electronic item to others in violation ofthe rights ofthe merchant (e.g., illegally uploading or copying) because the customer is made aware, through the warnings, that the illegal uploading or copying can be traced back to them through the verification entity using the transaction identifier and/or encryption stream and is agreeing to be bound by the conditions and terms setforth in those warnings. Similar authorized use and acceptance warnings may alsó be employed for access based upon age, sale pricing based upon age or residence, etc. The embodiments herein allow for a wide rangé of customer identifiers that encourage, promote, and protect eCommerce and the parties engaging in it.
[0038] The copyright warnings, etc., may nőt be applicable to audio média after it is downloaded. These warnings are important prior to any downloading, however, to the extent that the customer is agreeing to be bound by the terms and conditions contained in such warnings as a condition of the transaction, he/she is agreeing to be bound under the adhesion provisions of his/her agreement with the credit issuer and is agreeing to be liable for breach of terms and conditions. The parties are agreeing to be responsible for their actions and intensions. [0039] The encrypting ofthe customer information can be, for example, performed as follows. First, the customer connects with the credit issuer using a first computerized device and the credit issuer downloads software to the first computerized device. Vendors (which are interchangeably sometimes referred to herein as mer5
EP 2 191 406 Β1 chants) may alsó act as a registering agent for a credit issuer by redirecting a customerto the credit issuer’s site for registration with the verification entity. The advantage to this, for example, is that once an existing credit card user registers his/her card under the program, that user/customer may elect to restrict the use ofthe card on a computer network such asthe Internet to embodiments herein, protecting the card from unauthorized use by others. The customer supplies or agrees to allow storage of existing sensitive information, such as valid shipping addresses, their date of birth (for age group classification), their bank account numbers, credit card numbers, etc. Certain items ofthe customer information (such as bank account numbers and credit card numbers) are nőt stored on the customer’s computerized device, bút instead are only maintained in the databases ofthe credit issuer orthe verification entity, though coded orun-coded identifiers may be used to specifically reference such information. Other items or identifiers (name, address, age reference, etc.) ofthe customer information may be encrypted to create the encryption stream, which is stored on the customer’s computerized device and which may be coded or un-coded prior to encryption, in part or in whole.
[0040] The term credit issuer herein is a shorthand term for the entity that extends credit to the customer. This can be a merchant, vendor, bank, financial institution, etc. Further, any such credit issuers can include a verification entity and can act through an agent. Therefore, the term credit issuer is used to represent any and all of the foregoing. The credit issuer, as discussed in this document, may be one of several types. One type is a credit card, debit card, or similar type of issuer. Another type of issuer could be an entity that allows existing credit vehicle holders, such as existing credit card holders, to register all of the cards they wish to use with a single entity which would then act as the processor. Another type could be a non-card/non-bank type of credit issuer, such as a Microsoft® or a Yahoo!® or a Google®, that determines a line-of-creditforan individual, on a case by case basis, and extends to them an identifiable credit amountthat may be used bythe individual overa network such asthe Internet. Oneordinarily skilled intheartwould understand that there are many other types of credit issuers that are nőt listed here, bút that could be components of embodiments herein.
[0041] Credits are processed by the credit issuer or its processor, sometimes acting as the verifier, with participating vendors that do business over the network (this alternative recognizes that conventional credit cards may nőt be necessary on a computer type of network and that what is necessary is the need to protect the parties to the transaction while tracking the fiow of legitimate commerce). The vendors may choose to promote this program by referring customers to their credit issuer for enrollment. This protects the customer and his/her identity, improves the marketability of the vendor, assures the vendor of payment, and reduces chargebacks and fraud;
all serving to improve the vendor’s bottom-line.
[0042] Banks and software companies are capable of reading and verifying a computer’s identity without downloading software onto a visitor’s computer; however, software can be downloaded or otherwise installed in order to perform the other tasks. With the customer’s authorization, the credit issuer reads and registers the unique hardware identifiers (such as serial numbers from the motherboard, the hard drives, the processor, etc.) from the first computerized device. These unique hardware identifiers are alsó incorporated intő the encryption stream. Then, the same steps are repeated for any additional computerized devices the customer desires to authorize and register for use in future purchase transactions, if, for example, the customer owns or has access to multiple computers and computerized devices. Such processes can be done when the customer is setting up or modifying their account with the credit issuer.
[0043] The verification entity, financial institution, and/or credit issuer, (e.g., a bank), sets up the elements ofthe encryption stream with the customer, including the initial contract/agreement that will be relied upon by any vendor supporting this program. It is the agreement between the credit issuer and the customer that is relied upon by the vendor under the terms of its merchant bank/acquirer agreement. Alsó, the verifying entity may be the credit issuer, or it may be a processor or agent used by the credit issuer, which processor or agent has access to the database containing the customer’s information.
[0044] Somé examples of customer types include: 1) new customer (applying for computer network credit; a new credit card; a new debit card orotherform of loaded card such as a payroll debit card); 2) existing relationship (holder of an existing credit vehicle, such as the types in number 1, above, that may be used for purchases over a computer network such as the internet); or 3) new customer with existing credit vehicle (a person with existing credit vehicles/cards, such as the type described in number 1, above, may chose to register somé or all of those cards with a single entity that would allow the program to be attached to all ofthe registered cards). [0045] The credit may be in the form of an existing credit card, debit card, etc., or it may take the form of a newly issued credit from somé other source willing to extend such credit to an identifiable individual - a sort of electronic-letter-of-credit, or eCredit - subject to various rules and regulations. It is during the proeess of registering the customer’s identifiers and other information with this credit issuer- a bank will presumably have an existing customer’s information in its database-that the customer and the credit issuer form the agreement of what identifiers are to be present, along with the hardware information ofthe registered device(s), to confirm the customer’s presence.
[0046] Elements ofthe customer information such as age identification can be extrapolated from the database, rather than being stored in the encryption stream, al6
EP 2 191 406 Β1 though a date-of-birth or a unique word may be part of the encryption stream.
[0047] In another embodiment, as one process of further verifying that the merchant is dealing with no one else other than the customer, at the approximate time of transfer of the encryption stream to the merchant, bút before the actual transfer ofthe encryption stream to the merchant (as part of the process of transferring the encryption stream) the method can incorporate, intő the encryption stream, a second set of computer hardware identifiers and a time and date stamp from the computerized device making the actual transfer of the encryption stream. Thus, if an unscrupulous person were able to obtain an improper copy ofthe encryption stream, and was using the improper copy ofthe encryption stream on a computer (other than one ofthe customer’s computers that are registered with the verification entity) possibly together with the necessary credit issuer supplied encryption stream creation and transfer software, the second hardware identifiers that are read just prior to the transfer of the encryption stream would nőt match the hardware identifiers in the encryption stream and the transaction would nőt be approved by the verification entity. Similarly, the time and date stamp could be used to make the encryption stream that is supplied to the merchant only valid for a limited time period (e.g., minutes, hours, days, etc.). Such processes further enhance the customer presence verification process performed by the verification entity to provide additional assurances to the vendor that they are actually dealing with the customer and nőt someone other than the actual customer. In addition to verifying the customer’s presence and agreement to terms whenever the customer uses the encryption steam/signature, the embodiments herein permit the credit issuer to disallow a specific vendor intő the program, where vendor fraud is, or has been, an issue. This further serves to protect the customer, as well as reputable vendors.
[0048] The use ofa standard credit issuersoftware program for creation of the encryption stream on the customer’s computerized device and the transfer the encryption stream to the merchant for the verification step ensures that the device upon which the software resides will be identified. Thus, if that identifier does nőt match the identifier in a hypothecated encryption stream, the transaction will nőt be approved.
[0049] Embodiments herein alsó comprise one or more systems that use an encoder that is positioned within the customer’s computer by the credit issuer. The encoder encrypts the customer identifier information in the encryption stream. In addition, the credit issuer positions a transfer agent within the customer’s computer and with the merchant. The transfer agent causes the encryption stream to be transferred from the customer’s computer to the merchant’s computer in the purchase transaction forthe purchased electronic item.
[0050] The verification entity has a verifier that is operatively connected to both the customer’s computer and/or the merchant’s computer during the verification stage ofa transaction. In embodiments herein, in order to enhance the security ofthe customer information, the verifier is maintained separate from the customer’s computer and from the merchant by being maintained in the verification entity. A database ofthe customer payment information can be maintained within the verification entity or separate from the verification entity. In either situation, the database is operatively connected only to the verifier, and neither the customer nor the merchant have access to the database.
[0051] To perform the method steps herein, the transfer agent is adapted to cause the encryption stream to be transferred from the merchant’s computer to the verifier for payment verification. The verifier is further adapted to generate the identity verification and payment authorization, based on the database information, and to transfer the identity verification and payment authorization to the merchant. Again, the encryption stream orthe unique identity verification and payment authorization is adapted to be added, by the merchant, to the purchased electronic item to create the personalized electronic item that is supplied from the merchant to the customer. [0052] These and other aspects of the embodiments ofthe invention will be better appreciated and understood when considered in conjunction with the following description and the accompanying drawings. It should be understood, however, that the following descriptions, while indicating preferred embodiments ofthe invention and numerous specific details thereof, are given by way of illustration and nőt of limitation.
BRIEF DESCRIPTION OF THE DRAWINGS [0053] The embodiments ofthe invention will be better understood from the following detailed description with reference to the drawings, in which:
FIG. 1 is a schematic architectural diagram of one embodiment ofthe invention;
FIG. 2 is a flow diagram illustrating an embodiment of the invention;
FIG. 3 is a flow diagram illustrating an embodiment of the invention;
FIG. 4 is a schematic diagram of a system embodiment herein;
FIG. 5 is a schematic diagram of a system embodiment herein;
FIG. 6 is a schematic diagram of an encryption stream according to embodiments herein;
FIG. 7 is a flow diagram illustrating a method embodiment herein;
FIG. 8 is a flow diagram illustrating a method embodiment herein;
FIG. 9 is a flow diagram illustrating a method embodiment herein; and
FIG. 10 is a schematic diagram of a system embodiment herein.
EP 2 191 406 Β1
DETAILED DESCRIPTION OF EMBODIMENTS [0054] The embodiments ofthe invention and the various features and advantageous details thereof are explained more fully with reference to the nonlimiting embodiments that are illustrated in the accompanying drawings and detailed in the following description. It should be noted that the features illustrated in the drawings are nőt necessarily drawn to scale. Descriptions of wellknown components and Processing techniques are omitted so as to nőt unnecessarily obscure the embodiments ofthe invention. The examples used herein are intended merely to facilitate an understanding of ways in which the embodiments ofthe invention may be practiced and to further enable those of skill in the art to practice the embodiments of the invention. Aceordíngly, the examples should nőt be construed as limiting the scope ofthe embodiments ofthe invention.
I. Detailed Description of Original Disclosure Application Serial Number 10/970,051 and U.S. Patent Number 6,839,692 Priority Date: December 1,2000 [0055] Referring now to the drawings, and more particularly to Figure 1, a schematic diagram of a preferred embodiment ofthe invention is illustrated. More specifically, Figure 1 illustrates a personal computer 100 connected to a network 170. In addition, a code confirmation site 130, merchantsite 140, financial institution 150, and credit agency 160 are alsó connected to the network 170. The arrangement of features shown in Figure 1 is arbitrarily selected in order to illustrate the invention. One ordinarily skilled in the art would understand that many other arrangements of items could be utilized with the invention.
[0056] The personal computer 100 (which is sometimes referred to herein has the customer’s computer) comprises any form of computing device that is capable of connecting with the network 170. Therefore, the customer’s computer 100 can comprise a standard desktop personal computer, a mobile computer, a personal digital assistant, a celi phone, etc. In a preferred embodiment, the customer’s computer 100 includes a graphic user interface (GUI) 110, and a storage device 112, such as a magnetic hard drive or other read/write storage device. In addition, the customer’s computer 100 includes an encrypter 114, a network connection 116, a populator 118 and Central Processing unit (CPU) 120.
[0057] The financial institution 150 includes a database of historical address 154 obtained from the credit agency 160 and a comparator 152 that is utilized to check customer addresses, as discussed below.
[0058] The operation ofthe system shown in Figure 1 is illustrated in flowchart form in Figure 2. More specifically, the inventive system is added to the customer’s computer 100. Using the graphic user interface 110, the customerpreferably createsa password as shown in item 200 that will allow future access to the inventive system.
The customer then supplies personal information such as Social Security number, address, date of birth, relatives’ names, credit card information, banking information, employment information, etc. to the inventive system through the graphic user interface 110. The encrypter 114 immediately encrypts this information and Stores the encrypted information as a customer code on the storage device 112, as shown in item 202.
[0059] An important feature ofthe invention is that the customers’ personal information is only stored in encrypted form. Therefore, if an unauthorized user were able to access the user’s storage device 112, the customers’ personal information would be secure because of its encrypted natúré.
[0060] The encryption process has three elements: 1) the encryption code itself, which is pared to the decryption code maintained by the financial institution; 2) the customer’s priváté key, password and/or personal access code, which is created and controlled by the customer foraccessing the encrypted information; and, 3) the customer’s computer’s system identifier that requires that the encrypted information may only be accessed on the customer’s computer. Once the customer’s information is entered, these three elements and the need to re-enter any ofthe information become transparent to all parties during any e-commerce transaction (e.g., dual key or public key).
[0061] Ifthe encryption code were tofall intő the hands ofan unauthorized party, access to the information would still require the customer’s priváté key plus access to the information from customer’s specific storage system (e.g., customer’s computer’s system identifier). An unauthorized user would need the decryption code to access the information, which code is maintained only by the financial institutions (credit issuers) and their authorized agents. This element ofthe public key ordual key formát ofthe preferred embodiment ofthe present invention enhances the security ofthe customer’s information. [0062] Even if an unauthorized user overcomes the foregoing safeguards, the present invention requires the userto supply an authorized shipping address; a procedure that requires a separate secured transaction with the financial institution, confirmed by e-mail to the customer. Such steps make impractical the unauthorized access.
[0063] In another embodiment ofthe invention, the user can create multiple customer eodes, each of which could include a different credit agency (e.g., a different credit card). Therefore, the invention allows the user to create a customer code for each of the credit cards the user owns.
[0064] In addition, many customer eodes can be created for the same credit card. These additional customer eodes can include different spending limits. This allows the user to establish different customer eodes for budgetary or other similar reasons. For example, with the invention, a user could create customer eodes for different items of a personal or business budget. Upon reaching
EP 2 191 406 Β1 a spending limit, no additional transactions (purchases) could be performed until the budget information is changed or updated. The budget plán could be updated automatically to allow periodic budgets to be automatically implemented. An example of this could include one customer code that uses a credit card to pay monthly chargesto an internet service provider(ISP) for a specific period, e.g., one year. The customer code would include a monthly limit ofthe monthly ISPfee and a twelve-month limit on the transaction. The additional advantage to the customer of this embodiment is the ability to amend or cancel the transaction at any time by changing the stated limits.
[0065] Similarly, parents could create customer codes for each of their children, where each customer code potentially includes a different spending limit. In one embodiment, the spending limits can be updated periodically to provide a periodic allowance. This aspect ofthe invention allows parents to establish a monthly Internet-allowance for a child. The parents establish a separately authorized customer code togetherwith periodic limits (e.g., monthly or weekly). The effect of this is that the parent would control the establishment and use of authorized sub-accounts.
[0066] The effect of these aspects of the invention is that the financial institution would continue to control qualifying a customer for credit. However, the customer would enjoy an increased control and use of that credit. [0067] The customer codes preferably include the name, address and credit card number of the user in encrypted form. Once the customer codes have been established and stored in encrypted form on the storage 112, the invention operates in the background on the customer’s computer 100 until the customer desires to make a purchase over the network 170. At the time of a purchase, the graphic user interface 110 provides the user with different payment options (customer codes). After the user selects the appropriate customer code, the populator 118 prepares to send the customer code to the merchant’s site 140 by issuing an instruction to send the customer code out on the network 170 directed to the merchant site 140, as shown in item 204.
[0068] The operation of the functions in item 204 is shown in greater detail in Figure 3. More specifically, the invention provides for the customer code to automatically populate the appropriate checkout box ofthe merchant site 140 using the populator 118. As shown in Figure 3, when the customer gets to a checkout (purchase) window of a merchant site, (300) the customer places the cursor intő the appropriate box (e.g., the credit card number field, customer code data fieids, etc.) 302. Many merchant sites 140 may nőt have space for the customer code date field. Therefore, the invention allows the credit card number (or other similar payment filed) to be used by the merchant site. The encrypted customer code data field is longer than credit card numbers. Therefore, the only modification needed by the merchant site 140 to accommodate the invention is to allow longer encrypted data strings to be accepted by the credit card number field.
[0069] Once the user places the cursor in the appropriate box, they press a preestablished function key on the keyboard (or selects a button on the graphic user interface) (304) which brings up a user ID and password entry pop-up window (306). Upon entry ofthe proper user ID and password, the entire customer code is populated (written to) the field on the merchant site. The user does nőt need to enter their name, address, etc. because all that information is contained in the customer code. As discussed below, upon approval ofthe credit transaction, the financial institution 150 will return name, shipping address and credit authorization number (nőt credit card number) to the merchant site 140 so that the user does nőt need to input such information.
[0070] If multiple customer codes are established for different credit cards, the user can select a customer code, which includes information as to a credit card with a sufficient credit limit, desirable interest rate, etc. to make the purchase. The customer code itself is the encrypted personal information data stream and can be somewhat lengthy. Therefore, the graphic user interface provides a user-friendly selection menü with abbreviated names. For example, in one embodiment, a pull-down menü with credit card abbreviations is provided to allow the user to select the customer code to be used. If the user has established only one customer code, the puli down menü will include only that single customer code abbreviation. In a similar manner, different budget categories or children’s names could alsó be utilized as the abbreviated names in the pull-down menü to select the appropriate customer code.
[0071] The user ID’s are the customer codes abbreviations. An error message is generated ifthe user ID/password is incorrect (310) and Processing returns to box 304 to retry the user ID/password. As is well-known a limited numberof retries ofthe user ID/password will be allowed. [0072] Ifthe password/user ID is correct (308), the customer has the option to set up rules regarding payment (312), such as the automatic monthly ISP payments discussed above. If no special rules are to be established for payment, a single direct payment scheme is assumed and Processing proceeds to box 316. On the other hand, if payment rules are to be established, another window pops-up (314) to lead the customer through a wizard to setup payment options such as transaction amounts, totál credit limits, and/or time frames, etc.
[0073] In item 316, the invention then takes the previously encrypted sensitive customer data, and adds to it a purchase specific transaction number and rules (if any). The invention alsó encrypts such additional data (transaction number, rules, etc.) before attaching necessary routing information, and automatically populates the complete customer code intő the customer code data field or credit card field 302. As mentioned above, the customer code is the encrypted data string of a number of data pieces including credit card number, rules, trans9
EP 2 191 406 Β1 action number, customer name and address, etc.
[0074] Referring again to Figure 2, in one embodiment the invention sends the customer code directly to the merchant site 140, as shown in item 208. In another embodiment, a code confirmation site 130 is utilized (item 206). In this embodiment, the customer code is directed to the code confirmation site 130 instead of to the merchant site 140 by the populator 118. The code confirmation site 130, controlled by the credit agency, determines whether the customer code has the proper formát by allowing the credit agency to periodically update or change the public keys (e.g., the encryption and decryption codes). Ifthe customer code is determined to be improper by the code confirmation unit 130, an error report is issued explaining that the customer code is improper, as shown in item 212. If the customer code is proper, it is sent to the merchant site 140 by the code confirmation unit 130, as shown in item 214.
[0075] Upon receipt of the customer code, the merchant site 140 forwards the customer code to the 150. An important feature of the invention is that confidential information is nőt provided to the merchant in unencrypted form at any time. Thus, the merchant is relieved of the responsibility for that information.
[0076] As shown in item 218, the decrypts the customer code. Next, while checking whether the credit transaction is acceptable (e.g., whether the customer has sufficient credit available), the alsó compares, using the comparator 152, the shipping address to which the goods are to beshipped against a historical database of acceptable shipping addresses 154 that is provided to the by the credit agency 160. This aspect ofthe invention prevents items from being improperly diverted by criminals to addresses other than the customer’s address.
[0077] In one embodiment of the invention, the customer is able to establish multiple authorized shipping addresses directly with the credit agency. These addresses may include such alternatives as Office or home. Each address is entered and stored on the customer’s storage device with a separate encryption sequence as a separate customer code. At the time the customer is setting up new customer codes, new authorized addresses for the customer are sent (via e-mail or similar electronic transfer) directly from the customer’s computer 100 to the credit agency 160 over the network 170 and are augmented tothe list of authorized addresses associated with the customer in the credit agency’s 160 databases. [0078] As shown in item 220, ifthe shipping address is consistent with an address in the database 154 and the customer has sufficient credit, a confirmation code, name, address, and other required information is sent to the merchant 140, as shown in item 224. In this instance, the term consistent means that the two addresses must be substantially matching. Thus, if a small portion ofthe Street number or zip code is incorrect or ifthe spelling of the Street name is slightly off, the transaction is approved and a corrected address is provided to the merchant. However, ifthe shipping address is directed toan address that is nőt consistent with an authorized address for that customer (e.g. different state, different city, different Street, etc.), an error report is issued to the merchant site 140 and an e-mail is sent to the customer explaining the improper transaction.
[0079] Credit agencies currently use addresses to help determine authorization; However, their criteria for what constitutes a consistent address varies. The present invention creates a system for eliminating error and fraud in these authorizations by correcting the address. It is then the merchant’s responsibility to ensure that the product only ships to the authorized or corrected address. This aspect of the present invention adds a layer of security, allowing the customerto intercept and return any unauthorized shipments.
[0080] In one embodiment ofthe invention, the customer uses the rule wizard [314] to temporarily add a non-permanent shipping address, allowing the customer to send gifts, etc., to others. The customer’s computer’s system identifier and password are required to access the wizard for this non-recurring change. Additionally, a confirmation ofthis shipment to a non-authorized address is e-mailed to the customer so that the customer may be alerted if a fraudulent transaction were being áttérni pted.
[0081] As mentioned above, the merchant site 140 preferably includes an input field (which may be the current credit card field) properly formatted to récéivé the customer code. The formát ofthe inputfield is established by the credit agency 160 and is similarly required by the financial institution 150. There are a relatively small number of national credit agencies 160 (Visa®, MasterCard®, American Express®, etc.). The credit agency 160 can generally dictate the formát of information that must be supplied by the more numerous financial institutions 150 that deal with the credit agency 160. In turn, merchant sites 140 that desired to deal with the financial institutions 150 must comply with the data formát requirements of the financial institution 150 (and, in turn, the credit agency 160). Therefore, the invention is applicable to a network that continually adds and drops large numbers of merchant sites 140, such as the Internet. More specifically, as merchant sites 140 are added to the network, each merchant site 140 will comply with the requirements of the financial institution 150 and will include the specialized formát of the customer code data field in their merchant sites 140. Therefore, the user should find the customer code data field on the vast majority of Web sites that allow customer purchases.
[0082] In otherwords, the invention works with the relatively small number of national credit agencies 160 to establish a formát (that can potentially vary from credit card agency to credit card agency) that will be made available by the merchants 140. Because a limited number of credit agencies 160 control the majority of the online credit purchase transactions, the formát ofthe customer code input field will be provided upon the vast majority of merchant sites 140. Thus, the invention provides the
EP 2 191 406 Β1 user with access to virtually all merchant sites 140 that desire to deal with financial institutions (which is virtually all merchant sites that desire to com plete purchase transactions).
[0083] The credit agencies [160] are in the business ofgetting customers to use credit (e.g., their credit cards). Where the present invention creates security for the customer, together with additional control and use features, the credit agencies dérivé a promotional benefit for their credit facilities. Moreover, these beneficial features do nőt require extra steps. A benefit ofthe present invention is that it eliminates steps that include repeated entry of customer information or the posting of that information on third-party databases.
[0084] An important safety feature of the invention is that the merchant site 140 never gains access to the customer’s confidential information, such as credit card numbers. To the contrary, the merchant site 140 only receives the encrypted customer code from the customer 100 and the transaction confirmation code (and possibly a corrected address) from the financial institution 150. Therefore, if any ofthe foregoing transactions over the network 170 are intercepted or if the merchant site suffers an unauthorized access of its records, the customer’s credit card information will be secure.
[0085] Further, the invention avoids many ofthe problems associated with conventional secured network transactions. More specifically, all elements of the present invention must be in piacé for a transaction to be completed. Conventional systems provide one level of security to all transactions, so that if a database is breached all of the records on that secured site are accessible. The present invention protects individual records creating an additional level of security.
[0086] The benefits that flow from the present invention, as detailed above, include security to an individual customer’s online credit and the customer’s control and flexible use of that credit.
II. Detailed Description of Continuation-ln-Part Embodiments Claiming Priority to U.S. Provisional Application 60/890,230 Priority Date: February 16, 2007 [0087] The present invention solves the problem of regulation over the many reál jurisdictions covered by the Virtual worldwide natúré of the Internet by providing a system and method for creating individual covenants on individual transactions - covenants that create defined rightsand protections for each party engaging in Internet commerce. By creating enforceable terms of agreeing between parties, each ofwhom have a valid expectation of reliance on each other (e.g., an expectation that each is of age or is otherwise the person authorized to engage in and take responsibility for such a transaction) and by creating a way of adhering to such agreements, including the agreement to be bound by the terms of all purchases verified under such agreements and to each transactional activity between the parties, the invention creates jurisdictional and enforceable rights based upon an asset jurisdiction of each party rather than upon the Virtual environment of their commercial activity.
[0088] One embodiment herein is centered around a contract (customer agreement) created between a customer and credit issuer. The customer agreement allows the credit issuer, either acting as a verifier or acting through an authorized processor or agent, to authorize and verify transactions between the customer and various participating vendors. Various to customer-vendor agreements are anticipated and allowed under the customer-credit issuer agreement and various, direct or indirect, credit issuer-vendor agreements are alsó anticipated and allowed under the customer-credit issuer agreement. There are alsó agreements or contracts between the verification entity, which can be a stand alone entity or combined with the financial institution that issues credit, debit and/or prepáid cards, or other capable financial provider and the individual customer/consumer. [0089] The customer agreement is the center of all activity in embodiments herein. lt sets the rules and terms by which a customer is bound - i.e., the priceforsecuring an individual’s identity over a computer Network is that individual’s agreement to be legally bound by his/her transactions whenever all agreed elements that establish the individuals online identity (e.g., his/her registered computer with the other identifiers that distinguish this individual from others that may use or have access to that computer). This agreement covers the purchase (i.e., agreement to be responsible and pay) and agreement to terms, such as honoring any copyright or trademarks attached thereto and agreement to be legally and personally accountable forthe criminal and civil penalties covering those registered rights. Most importantly, this credit issuer-customeragreement/contractgives permissión to the credit issuer to reference the customer agreement and adhere its terms to any verified customer-vendor agreement/transaction. The customer agreement, applied to any credit issuer-vendor agreement, direct or indirect, allows the vendor to rely upon the credit issuercustomer agreement in verifying the customer-vendor agreement. In other words, the vendor’s payment is assured for employing this payment device and does nőt require the individual to disclose, register, or otherwise give up his/her secure identity.
[0090] The customer agreement serves as the center for the related transactional activities that may be controlled under the embodiments herein. These related activities include: any verifiable transaction between the customer and the merchant over a computer network, which transaction may be for such things as goods or Services; and, the transaction ultimately facilitated by the contract, directly or indirectly, between the vendor and the financial entity (vendor agreement), under which the vendor’s consideration for the customer-vendor transaction may be guaranteed or bonded. Under the terms of the customer agreement, the merchant’s consideration may take the form ofsuch things as payment,
EP 2 191 406 Β1 credit worthiness, agreement to terms of sale or use of the merchant’s offering, or any other terms ofsuch agreement between the customer and the merchant that the contract may cover and that the verification entity confirms during the initial transaction to the merchant. [0091] The contracts formed under the embodiments herein create, inter alia, terms of use, third party reliance, and legal jurisdiction. Thus, using embodiments herein, the parties could agree that the proper jurisdiction for adjudicating disputes is the business location ofthe merchant, the location of a customer dealing with a merchant, or any other location of choice. Terms of use include a person present guarantee (akin to signature present) to ensure that the merchant is only dealing with the identified customer and to assure that the merchant will be paid without suffering from chargebacks. This person present guarantee is accomplished when all registered customer identification elements are present at the time ofthe transaction, which is confirmed by the verification entity.
[0092] The verification entity certifies both sides ofthe transaction underthe terms ofthe customer-credit issuer agreement and the vendor-credit issuer agreement, allowing all terms, e.g., confirmation of purchase/signature present, agreement of copyright protection, or representation age verification to be enforced and relied upon. In essence, any customer information that the credit issuer holds could be relied upon by a third party, without actually revealing the customer’s information or customer’s identity. In this respect, the credit issuer acts as a holder of trust on behalf of both the customer and the merchant, and the verifying entity certifies this with each individual transaction. This could be a bonded or escrowed type of element to the transaction that protects the identity of the customer and the rights of the merchant, and an element upon which the vendor may separately rely.
[0093] The common terms of purchase over networks, such as the Internet, involve the use of a bank issued credit card or debit card - in essence, whether the transaction is based upon a credit or prepáid type of card, the issuing bank acts to extend credit based upon the card until the payment is actually received, if at all, by the vendor. In common practice, this payment procedure has the bank wearing two hats: that ofan issuing bank; and, that ofan acquiring bank. As an issuing bank, the bank issues credit and a card to a customer for use in purchasing goods, Services, etc. As an acquiring bank, the bank agrees to acquire (and to pay for) the debt created by the use of those credit cards. Under terms of a conventional credit card transaction over the Internet, a bank, acting as an issuing bank, uses its agreement for use ofthe card according to terms that require payment and interest on any unpaid balance. Under a separate type of agreement, a bank, acting as an acquiring bank, requires merchants, among things, to verify the identity of the credit card user and to get the cardholder to sign a receipt for whatever is purchased. This over-simplified explanation of credit card transactions is sufficient to point out the problem of unauthorized credit card use and identity verification for transactions over the Internet, or any similar system of computer conneeted commerce. [0094] The vendor-credit issuer agreement takes the additional role of screening qualified vendors. One component of eCommerce fraud is vendor fraud. Vendors with known or suspected fraudulent histories can have their agreements cancelled and otherwise be denied access to the signature-present payment terms provided herein and other protections, such as copyright. This vendor qualifying step is neeessary both to protect the customer and to limit fraud.
[0095] In view ofsuch problems, the system and process embodiments herein use an encrypted code (encryption stream) that allows a third party verification entity to verify the presence ofthe customerto the merchant, and to verify the customer’s agreement with the credit issuer, the terms ofwhich allow the verification entity to confirm the customer’s identity and agreement to be bound by the terms of the transaction with the vendor, including signature present payment. Alternatively, rather than just referencing an identifier of the customer agreement in the encryption stream, the entire receipt and terms ofthe transaction could be encrypted and included in the encryption stream.
[0096] The customer-vendor agreement is verified under terms of the credit issuer-customer agreement and, in reliance upon it, the credit issuer-vendor agreement, which secure the terms of the customer-vendor agreement through agreed adhesion of the first two agreements. The customer-vendor agreement is the anticipated result any purpose ofthe othertwo agreements, which anticipate that all parties will be bound by their part ofthe separate agreements once at such point as the credit issuer or its agent, such as a processor, verifies the customer’s presence and agreement to terms of the transaction - according to the customer’s request, which is triggered by presentation of the verifiable encryption stream.
[0097] Thus, in somé embodiments herein, the separate customer agreement (between the verification entity or credit issuer and the customer) and the separate merchant agreement (between the merchant and its merchant bank) require the customer and the merchant to enter intő the customer agreement (between the merchant and the customer) that is created at the time of the purchase transaction between the merchant and the customer. The embodiments herein provide the ability ofthe credit issuer to screen vendors as a further protection to customers. With embodiments herein a new customer agreement can be created for each purchase transaction between a merchant and a customer, which, inter alia, binds the customer, if applicable to a specific transaction, toobserve the intellectual property rights ofthe merchant or média and which makes binding statements, if applicable to a specific transaction, regarding the presence, identity, age, etc. ofthe customer.
EP 2 191 406 Β1 [0098] The verification entity is bound under the terms ofthe credit issuer’s agreement with the customer, and through that agreement the other parties, to protect the identity and transaction of the customer and to verify, authorize, and protect the payment and other terms of the transaction (such as age, identity, area of residence, agreement to honor/be bound by copyright terms, etc.) on behalfofthe merchant.
[0099] Before an encryption stream is created (at the time ofthe purchase transaction) certain elements must be present to confirm the individual customer’s identity and to verify that the customer has agreed to be bound by the terms of the instant customer agreement. This sequence of elements may include, among other things, a name (nőt necessarily the cardholder’s name), an address for shipping or confirming residential status (nőt necessarily the cardholder’s biliing address), the customer’s unique credit number or ID with the financial entity, and the registered hardware identity ofthe computer, or computers, that the customer intends to authorize for such transactions. The encryption stream is created from somé of these elements, such as name, address, customer agreement identifier, computer hardware identifier, etc. bút does nőt include sensitive information, such as the customer’s credit card number or bank account numbers. In addition, the BIN (Bank Identification Number) or other routing identifier, such as an IP address, which is nőt encrypted, is added to the encryption stream for routing purposes.
[0100] Under the terms of the contract between the credit issuer and the customer, which is created during this registration, all required elements ofthe encryption stream must be present in orderfor the verification entity to confirm a customer’s presence during a transaction with a merchant. The merchant may nőt be aware ofthe customer’s identity because such information is encrypted. Once the verification has confirmed the presence of all coded elements, the transaction is confirmed, the merchant is instructed where to ship, if that information is required, and the merchant’s requirement for receiving a signature and verifying the identity ofthe customer are satisfied (i.e., the merchant will be paid, and/or will have recourse for such terms of the transaction as age verification and/or copyright).
[0101] The invention uses the terms created by the customer in forming his/her agreement with the credit issuer. This agreement has the customer assume responsibility for all transactions where all required elements of any of the customer’s encryption streams are present. The agreement alsó allows the encryption stream to be downloaded along with any digital média being acquired by the customer as a record ofthe agreement to the terms of use, such as copyright proteetion. [0102] One aspect ofthis invention is that it is a system and method for creating, verifying, and imbedding (when necessary) a contractually agreed upon eode that, when used with all elements present, acts as a signature, unique to the individual customer, confirming the presence ofthe customer in the transaction. The merchant has the right to rely upon the terms agreed to by the customer (which alsó confirms identity and jurisdiction) for the transaction in the customer agreement. This invention offers identity proteetion in exchange for contractually binding all parties to the terms ofsuch transactions. Thus, the invention provides the ability to protect the privacy and identity of a customer initiating an Internet purchase transaction, while alsó protecting the rights and commercial benefits ofthe merchant providing the product, service, etc. The embodiments herein protect the identity ofthe customer, which remains encrypted and/or otherwise protected unless the terms ofthe agreement are breached or otherwise violated.
[0103] Removal ofthe eode would render the média unusable, as described in U.S. Patent Publication 2007/0061580 where the absence of a watermark or eode prevents the purchased product from being accessed from electronic storage média. The presence of the eode in multiple copies ofthe média, in violation of the terms of purchase and the copyright protections, would give the merchant the ability to hold the customer responsible for the multiple copies under the agreement terms and jurisdiction ofthe credit issuer. Thus, the customer agreement is a vehicle for prosecution of the violation of the copyright protections specifically agreed to during the purchase.
[0104] In sum, the invention creates a method, system, structure, and apparátus for promoting, protecting, and verifying commerce over computer networks, such as the Internet, by protecting the rights ofthe customer, including the customer’s identity and financial information, and the rights ofthe merchant, including the merchant’s payment and the merchant’s control and ownership of its product and/or service, in part, by establishing an agreed upon jurisdiction for the proteetion and prosecution of those various rights. Thus, the embodiments herein create a binding contract between the parties to a transaction by giving the credit issuer and verification entity the contracted ability, by consent ofthe customer and merchant. The embodiments herein confirm that the identity and creditworthy elements ofthe transaction have been met, while protecting the identity ofthe customer and guaranteeing the merchant that it will be compensated. Thus, the invention may be used to establish a verified presence element to the transaction, establish a signature present element to the transaction, establish the customer’s age (e.g., in terms of over 18 or over 21 or over 65), establish a residential or delivery element, establish a customer/seller nexus to the customer agreement, and establish the customer’s identity (without necessarily revealing it or storing it online) all, in part, by requiring that all components of the encryption stream be present and be verified in order for a transaction to be completed.
[0105] Referring now to the drawings, the present embodiments provide a method and system of securing transactional rights over a computer network 404. As
EP 2 191 406 Β1 shown in Figure 4, the terms ofthe agreements 422 that are created between thecustomer402the merchant 450, and the verification entity 420 and/or the financial institution 440 are stored by the verification entity 420. The verification entity 420 can be included within the financial institution (credit issuer) 440 as shown in Figure 5, or be separate therefrom, as shown in Figure 4. While Figure 4 illustrates a single customer’s computer 410, a single verification entity 420, a single financial institution 440, and a single merchant 450, as would be understood by those ordinarily skilled in the art, Figure 4 is oniy one example of how the invention could be implemented and there could be (and most likely would be) multiple customer’s computers 410, multiple verification entities 420, multiple financial institutions 440, multiple merchants 450, etc. as shown in Figure 5. Therefore, the verification entity 420 Stores multiple agreements 422, one for each purchase transaction.
[0106] The method includes registering and storing the customer agreement(s) 422 with the credit issuer/verification entity 440/420. The customer information is stored in a database 430, which can be within the credit issuer/verification entity 440/420 as shown in Figure 5, or as shown in Figure 4, separate from the credit issuer/verification entity 440/420. As would be understood by those ordinarily skilled in the art, while oniy one database 430 is illustrated in Figure 4, there could be multiple databases 430, somé of which could be included within the credit issuer/verification entity. Further, the customer’s computer 410 is connected to the merchant 450 and the verification entity 420 over one or more computer networks 404.
[0107] A password is used to access an encoder 412 on the customer’s computer 410. The encoder 412 is downloaded to the customer’s computer 410 by the verification entity 420 during the customer registration process. The encoder 412 encrypts the customer information to form the encryption stream 414 which is stored on the customer’s computer 410. The customer information is nőt stored on the customer’s computer in non-encrypted form. Further, the encryption stream does nőt include any personal financial customer information relating to credit card numbers, bank account numbers, etc. and such information is stored oniy in the database(s) 430. [0108] In addition, the verification entity downloads transfer agents 416, 456 to the customer’s computer 410 and to the merchant 450. The transfer agent 416 causes the encryption stream 414 to be transferred from the customer’s computer to the merchant’s computer 450 in the purchase transaction for the purchased electronic item 454.
[0109] The verification entity 420 hasa verifier 424 that is operatively connected to both the customer’s computer 410 and the merchant’s computer 450. In embodiments herein, in orderto enhance the security ofthe customer information, the verifier 424 is maintained separate from the customer’s computer 410 and from the merchant by being maintained in the credit issuer/verification entity
440/420. The database 430 of the customer payment information can be maintained within the credit issuer/verification entity 440/420 or separate from the verification entity 420. In either situation, the database 430 is operatively connected oniy tothe verifier424, and neíther the customer nor the merchant have access to the database.
[0110] To perform the method steps herein, the transfer agent 416 is adapted to cause the encryption stream 414 to be transferred (along with the monetary amount ofthe transaction) from the merchant’s computer 450 to the verifier 424 for payment verification. The verifier 424 is further adapted to generate the payment verification, based on the database 430, and to transfer the payment verification to the merchant 450. Again, the encryption stream 414 and/or a transaction identifier is adapted to be added, by the merchant, to the purchased electronic item to create the personalized electronic item 454 (as shown in Figure 6) that is supplied from the merchant 450 to the customer’s computer 410.
[0111] The encryption stream 414 can include such information as the customer’s name, a customershipping address, customer’s date of birth and customer’s hardware computer identifier. The customershipping address can comprise one ofa plurality of valid shipping addresses that depend upon which encryption stream 414 is supplied to the merchant 450. Thus, the method can allow the customerto select from a plurality of stored encryption streams 414, each having a different valid shipping address. The method supplies the selected encryption stream 414 togetherwith the computer identifier as part ofthe identifier code (the CID and routing identifier 416) to the merchant 450 in a transaction over the computer network 404.
[0112] The encryption stream 414 is forwarded, by means ofthe routing identifier 416, to the verification entity 420 over the computer network 404. The verification entity 420 decrypts the encryption stream 414 and compares the customer shipping address identifier, name identifier, age identifier, or other identifiers with the authorized corresponding identifiers ofthe customer maintained by the verification entity 420 such as identifiers of name, age, address, etc., can be actual names, addresses, etc., or can be alpha-numeric codes that are used by the verification entity 420 to look up the name, address, age, etc., in the database 430. If all is in order, the verification entity 420 returns an authorization decision tothe merchant 450 over the computer network 404. Thus, the verification entity 420 can produce (and return tothe merchant) the identity verification, payment authorization, etc. The verification entity 420 verifies that the terms ofthe customer’s verified presenee and electronic signature have been met according to customer’s agreement 422 with the verification entity 420, which confirms to the merchant 450 that the customer has assumed responsibility for the transaction.
[0113] In addition, each ofthe encryption streams 414 can include a unique payment method that is different
EP 2 191 406 Β1 from payment methods of other encryption streams 414. Alternatively, a group ofthe encryption streams 414 can identify a single credit organization for payment, bút each encryption stream 414 in the group can include a different user name, a different authorized and registered device/computer, different age verification method, and/or different customer address.
[0114] For purchase transactions that include Services or tangible goods (such as stereo equipment, filters, books, groceries, clothing, furniture, computers, etc.), the embodiments herein can subside in supplying a verification ofthe customer and a payment authorization. However, for purchase transactions that include electronic items which have the potential to be improperly shared over computer networks, the embodiments herein can add the encryption stream or a transaction identifier to the electronic item. Thus, as part of the agreement 422, the customer agrees to allow the encryption stream 414 and routing identifier 416 to be imbedded, imprinted, and/or otherwise affixed to média or média content 454 acquired from the merchant 450, as shown in Figure 6. Before transferring the encryption stream 414 to the merchant 450, the verification entity can add the encryption stream, which can contain a customer agreement or customer agreement identifier, or the transaction identifier to the encryption stream 414 to allow the customer agreement 422 between the customer 402 and the merchant 450 to be readily accessed.
[0115] This proeess alsó establishes the jurisdiction for enforcementofthe merchant’s 404 rights as established in the customer’s agreement 422. The authorization decision is approved only ifthe encryption stream 414 and the customer information within the database 430 are consistent. The method can send an e-mail confirmation ofthe transaction to the customer 414 from the verification entity 420. The encryption stream 414/CID is stored on the customer storage device 408 only in encrypted form.
[0116] As shown in flowchart form in Figure 7, the disclosed method facilitates the computerized purchase transactions of electronically storable items (which are sometimes referred to herein as electronic items) such as literary works, musical works (recordings), videó works (movies, shows, videós, etc.), etc.
[0117] First, in item 700, the customer enters intő the customer agreement with the verification entity. Then, in item 702, the embodiments herein encrypt customer information to produce an encryption stream 704. Techniques for data encryption are disclosed in, for example, U.S. Patents 7,257,225 and 7,251,326 and the details of such processes are nőt provided herein to maintain focus on the disclosed embodiments. Such customer information may comprise a name identifier (which may or may nőt be the customer’s formai name), a customer age identifier (which can be a specific age, an age rangé, an age classification), an address identifier (which can be a customer’s address or a different address).
[0118] In item 706, the embodiments herein cause the encryption stream to be transferred from the customer to a merchant in the purchase transaction for the purchased electronic item. The verification entity receives the encryption stream which is sent by the merchant for payment verification in item 708. Then, the verification entity cross-references the encryption stream against a separate database containing customer payment information (item 710) to produce the unique transaction identifier comprising the identity verification and/or payment authorization in item.
[0119] The verification entity transfers the unique transaction identifier from the verification entity to the merchant in item 714. The identity verification and payment authorization confirms to the merchant the actual presence of the customer in the purchase transaction, such that the merchant is provided assurance that the merchant is nőt transacting with any entity other than the customer.
[0120] As mentioned above, the encryption stream 704 and the identity verification and payment authorization 710 are devoid of personal payment information ofthe customer, such as credit card information, bank account information, etc., and can take the form ofa unique transaction identifier. Thus, even if the encryption stream is decrypted, the customer’s payment information would nőt be disclosed or usable. Thus, the encryption stream supplied from the customer can be modified by the verification entity before being supplied to the merchant to include data or information specific to the purchase transaction being conducted orthe encryption stream can be accompanied by the unique transaction identifier. Such a modified encryption stream or unique transaction identifier can be used in piacé of the original encryption stream in embodiments herein. Thus, theoriginal encryption stream, the modified encryption stream, and/or the unique transaction identifier can be added to the electronic item before being provided to the customer. [0121] Forembodiments that deal with electronic items that have the potential of being improperly copied and distributed over computerized networks, asshown in item 716, the encryption stream and/or unique transaction identifier is added, by the merchant, to the purchased electronic item to create a personalized electronic item 718. The encryption steam or transaction identifier can be hidden, so that the customer is unable to remove the encryption stream or transaction identifier from the personalized electronic item. Techniques for embedding information in a digital work are well-known (see U.S. Patent Numbers 6,691 ,229 and 5,809,160). Further, the personalized electronic item could be made non-functional (so that the personalized electronic item cannot be opened, or cannot be played, etc.) if the encryption stream or transaction identifier is ever removed. Techniques for controlling access to digital works through encryption streams or watermarks are alsó well-known (see U.S. Patent Number 7,062,069).
[0122] Thus, the personalized electronic item always maintains the encryption stream and allows the customer
EP 2 191 406 Β1 who purchased the electronic item to be identified (through the verification entity) and all copies ofthe purchased electronic item will have the encryption stream or transaction identifier. Thus, because all copies ofthe personalized electronic item will have the encryption stream, the customer who originally purchased the electronic item from the merchant (the source of the copies) can always be identified.
[0123] After the encryption stream or transaction identifier is added to the purchased electronic item, the personalized electronic item is supplied from the merchant to the customer in item 720. Each personalized electronic item distributed to different customers is different because of the uniqueness of each different encryption stream ortransaction identifier, which allows the customerwho originally purchased the electronic item to be identified in copies ofthe electronic item. Further, the uniqueness of each encryption stream or transaction identifier permits the source of unauthorized copies of the purchased electronic item to be identified through the verification entity. Thus, as shown in item 722, the method potentially includes the step of identifying the customer from the encryption stream that is included within the personalized electronic item.
[0124] During customer registration (when the customer is setting-up or modifying their account with the credit issuer) and during the purchase of electronic items, the customer is provided a notice or warning that their information will always remain with copies of any personalized electronic items. In addition, during the purchase of an electronic item, a similar notice or warning is displayed informing the customer that he/she is agreeing to be bound by the terms and penalties provided for unauthorized use or copying ofthe electronic item; and, each time (or the first few times) the personalized electronic item is opened, played, etc. the same warning may be displayed. Such warnings are intended to discourage the customerfrom supplying copies ofthe personalized electronic item to others in violation ofthe rights ofthe merchant (e.g., illegally uploading or copying) because the customer is made aware, through the warnings, that the illegal uploading or copying can be traced back to them through the verification entity using the encryption stream and is agreeing to be bound by the conditions and terms set forth in those warnings. Similar authorized use and acceptance warnings may alsó be employed for access based upon age, sale pricing based upon age or residence, etc. The embodiments herein allow for a wide rangé of customer identifiers that encourage, promote, and protect eCommerce and the parties engaging in it. [0125] The encrypting ofthe customer information 702 is performed as shown in Figure 8. First, the customer connects with the credit issuer using a first computerized device 800 and the verification entity downloads somé software to the first computerized device 802. The customer supplies or agrees to allow access to existing sensitive information, such as valid shipping addresses, their date of birth (or age group classification), their bank account numbers, credit card numbers, etc. to the verification entity 804. Certain items ofthe customer information (such as bank account numbers and credit card numbers) are nőt stored on the customer’s computerized device, bút instead are only maintained in the databases of the credit issuer and/or verification entity, though eoded or un-coded identifiers may be used to specifically reference such information. Other items or identifiers (name, address, age reference, etc.) ofthe customer information may be encrypted to create the encryption stream, which is stored on the customer’s computerized device and which may be eoded or un-coded prior to encryption, in part or in whole.
[0126] With the customer’s authorization, the credit issuer reads and registers the unique hardware identifiers (such as serial numbers from the motherboard, the hard drives, the processor, etc.) from the first computerized device in item 806. These unique hardware identifiers are alsó incorporated intő the encryption stream in item 808. Then, the same steps are repeated for any additional computerized devices the customer desires to authorize and registerforuse in future purchase transactions. Such processes can be done when the customer is setting up or modifying their account with the credit issuer.
[0127] Use of a public or unregistered computer is alsó covered under this application. It is possible to allow emergency access to an individual if they access their issuer account form the unregistered computer and arrange for a limited approval of that computer under their existing account, which approval could be timelimited (e.g., 15-minutes for a single purchase) or uselimited (e.g., one-time use/single purchase).
[0128] In another embodiment, as one process of further verifying that the merchant is dealing with no one else other than the customer, at the approximate time of transfer of the encryption stream to the merchant, bút before the actual transfer ofthe encryption stream to the merchant (as part of the process of transferring the encryption stream) the method can incorporate, intő the encryption stream, a second set of hardware identifiers and a time and date stamp from the computerized device making the actual transfer of the encryption stream. Therefore, as shown in Figure 9, after the hardware identifiers have been added to the encryption stream in item 900, the method reads a second set of hardware identifiers from the actual computer that is connected to the merchant in item 902. This second set of hardware identifiers (and potentially a time and date stamp) are then added to the encryption stream in item 904 and the modified encryption stream (having both sets of hardware identifiers) to the merchant in item 906.
[0129] Thus, if an unscrupulous person were able to obtain an improper copy ofthe encryption stream, and was using the improper copy ofthe encryption stream on a computer (otherthan one ofthe customer’s computers that are registered with the merchant) togetherwith the necessary credit issuer supplied encryption stream creation and transfer software the second hardware identi16
EP 2 191 406 Β1 fiers that are read just prior to the transfer ofthe encryption stream would nőt match the first hardware identifiers in the encryption stream and the transaction would nőt be approved by the verification entity. Similarly, the time and date stamp could be used to make the encryption stream that is supplied to the merchant only valid fór a limited time period (e.g., minutes, hours, days, etc.). Such processes further enhance the customer presence verification process performed by the verification entity to provide additional assurances to the merchant that they are actually dealing with the customer and nőt someone other than the actual customer.
[0130] The embodiments ofthe invention can take the form of an entirely hardware embodiment, an entirely software embodiment or an embodiment including both hardware and software elements. In one embodiment, the invention is implemented in software, which includes bút is nőt limited to firmware, resident software, microcode, etc.
[0131] Furthermore, the embodiments ofthe invention can take the form ofa computer program product accessible from a computer-usable or computer-readable médium providing program code fór use by or in connection with a computer or any instruction execution system. Fór the purposes of this deseription, a computer-usable or computer readable médium can be any apparátus that can comprise, store, communicate, propagate, or transport the program fór use by or in connection with the instruction execution system, apparátus, or device. [0132] The médium can be an electronic, magnetic, optical, electromagnetic, infrared, orsemiconductor system (or apparátus or device) or a propagation médium. Examples of a computer-readable médium include a semiconductor or solid state memory, magnetic tape, a removable computer diskette, a random access memory (RAM), a read-only memory (ROM), a rigid magnetiedisk and an optical disk. Current examples of optical disks include compact disk - read only memory (CD-ROM), compact disk - read/write (CD-R/W) and DVD.
[0133] A data Processing system suitable fór storing and/or executing program code will include at least one processor coupled directly or indirectly to memory elements through a system bús. The memory elements can include local memory employed during actual execution ofthe program code, búik storage, and cache memories which provide temporary storage of at least somé program code in order to reduce the number of times code must be retrieved from búik storage during execution. [0134] Input/output (l/O) devices (including bút nőt limited to keyboards, displays, pointing devices, etc.) can be coupled to the system either directly or through intervening l/O controllers. Network adapters may alsó be coupled to the system to enable the data Processing system to become coupled to other data Processing systems or remote printers or storage devices through intervening priváté or public networks. Modems, cable modem and Ethernet cards are just a few of the currently available types of network adapters.
[0135] A representative hardware environment fór practicing the embodiments of the invention is depicted in FIG. 10. This schematic drawing illustrates a hardware configuration of an information handling/computer system in accordance with the embodiments ofthe invention. The system comprises at least one processor or Central Processing unit (CPU) 10. The CPUs 10 are interconnected via system bús 12 to various devices such as a random access memory (RAM) 14, read-only memory (ROM) 16, and an input/output (l/O) adapter 18. The l/O adapter 18 can connect to peripheral devices, such as disk units 11 and tape drives 13, orother program storage devices that are readable by the system. The system can read the inventive instructions on the program storage devices and follow these instructions to execute the methodology ofthe embodiments of the invention. The system further includes a user interface adapter 19 that connects a keyboard 15, mouse 17, speaker24, microphone 22, and/or other user interface devices such as a touch sereen device (nőt shown) to the bús 12 to gather user input. Additionally, a communication adapter 20 connects the bús 12 to a data Processing network 25, and a display adapter 21 connects the bús 12 to a display device 23 which may be embodied as an output device such as a monitor, printer, or transmitter, fór example. [0136] The foregoing deseription of the specific embodiments will so fully reveal the generál natúré of the invention that others can, by applying current knowledge, readily modify and/or adapt fór various applications such specific embodiments without departing from the generic concept, and, therefore, such adaptations and modifications should and are intended to be comprehended within the meaning and rangé of equivalents of the disclosed embodiments. It is to be understood thatthe phraseology or terminology employed herein is fór the purpose of deseription and nőt of limitation. Therefore, while the embodiments ofthe invention have been deseribed in terms of preferred embodiments, those skilled in the art will recognize that the embodiments of the invention can be practiced with modification within the scope of the appended claims.
Contents4
2 sheets
Sheet 1 Sheet 2
37 members in 12 offices
Priority claims1
| Document | Office | Kind | Date |
|---|---|---|---|
| 84440807 | United States of America | A |
Members37
| Document | Office | Kind | |
|---|---|---|---|
| US2002069177A1 | United States of America | A1 | |
| US6839692B2 | United States of America | B2 | |
| US2005055317A1 | United States of America | A1 | |
| US2007288394A1 | United States of America | A1 | |
| US2008319914A1 | United States of America | A1 | |
| AU2007358254A1 | Australia | A1 | |
| CA2690529A1 | Canada | A1 | |
| CA2933130A1 | Canada | A1 | |
| WO2009029116A1 | World Intellectual Property Organization (WIPO) | A1 | |
| MX2010001951A | Mexico | A | |
| WO2010027657A1 | World Intellectual Property Organization (WIPO) | A1 | |
| KR20100036313A | Republic of Korea | A | |
| EP2191406A1 | European Patent Office (EPO) | A1 | |
| CN101785012A | China | A | |
| EA201000310A1 | Eurasian Patent Organization (EAPO) | A1 | |
| JP2010537308A | Japan | A | |
| US2011040685A1 | United States of America | A1 | |
| KR101067191B1 | Republic of Korea | B1 | |
| US8260719B2 | United States of America | B2 | |
| US8260723B2 | United States of America | B2 | |
| JP5052673B2 | Japan | B2 | |
| US2012296773A1 | United States of America | A1 | |
| US2012296831A1 | United States of America | A1 | |
| US8463713B2 | United States of America | B2 | |
| EA018277B1 | Eurasian Patent Organization (EAPO) | B1 | |
| AU2007358254B2 | Australia | B2 | |
| US2013246282A1 | United States of America | A1 | |
| BRPI0721942A2 | Brazil | A2 | |
| CN101785012B | China | B | |
| US9400979B2 | United States of America | B2 | |
| CA2690529C | Canada | C | |
| US9607299B2 | United States of America | B2 | |
| EP2191406B1 | European Patent Office (EPO) | B1 | |
| EP2191406B8 | European Patent Office (EPO) | B8 | |
| US2017300981A1 | United States of America | A1 | |
| HUE034341T2This record | Hungary | T2 | |
| CA2933130C | Canada | C |
Numbers
- Publication
- E034341
- Application
- 7841796
Titles2
- Hungarian
- Tranzakciós biztonság egy hálózaton
- English
- TRANSACTIONAL SECURITY OVER A NETWORK
Classification
- CPC, 10
- G06Q20/3823
- G06F21/10
- G06Q20/0855
- G06Q20/12
- G06Q20/40
- G06Q20/4014
- G06Q30/0603
- G06F21/40
- G06F21/106
- H04L63/0823
- IPC, 1
- G06F21 00
