JP2008541206A - Network commerce - Google Patents

Abstract

  The current embodiment provides online commerce authorization and payment between the buyer and merchant, including verification of the buyer's identity and verification of the buyer's ability to pay for the transaction, where the identity provider and payment provider Are often different network entities. Other embodiments include a protocol, computing system, enabling identity authentication and payment authentication using a mobile module that establishes a single level or multiple levels of security over an untrusted network (eg, the Internet), And other mechanisms are also provided. A further embodiment is between merchants, consumers, and payment providers, where the merchant becomes fully convinced of the consumer's ability to pay for the requested purchase while sensitive account information is opaque to the merchant. It also provides 3-way secure communication. In another embodiment, electronic billing information is used for authorization, auditing, payment federation, and other purposes.

Description

  The present invention relates to a networked transaction system and method for conducting online transactions.

  The proliferation of networked computers has opened up new possibilities for how companies and individuals conduct business. For example, an end user connected to a network (eg, the Internet) through a networked device such as a computer, PDA, cell phone, etc., may conduct commercial transactions over the network to purchase services and / or goods. You can conduct, conduct financial transactions on the network, conduct business, or perform personal transactions. A unique problem associated with online transactions is security, particularly when the transfer involves the transfer of money, funds, and / or financial information, personal information, or other sensitive information.

  Many conventional online transactions are performed by one of two different but related models. Both models use a browser as an interface to handle the transfer of information between the parties involved in the transaction. In the first model, a merchant provides goods (goods) or services online via a browser. The term “merchant” as used herein generally refers to any entity that provides goods and / or services for purchase. The term “merchant” is not used to describe a particular commercial status or licensed seller unless specifically stated. Rather, the term comprehensively describes all sellers or entities that provide goods and / or services for purchase or sale. The term service provider is used herein interchangeably with the term merchant and has the same meaning unless stated otherwise.

  In traditional online transactions, merchants may have web sites that describe, display, or otherwise provide goods and / or services for sale. An end user indicates that he or she wants to purchase one or more goods or services by selecting an item, usually via a browser interface. The browser then displays a transaction page that allows the end user to select one or more payment types and enter the information necessary to complete the transaction. For example, the transaction page displayed by the browser allows the end user to select a payment type such as a credit card (eg, VISA, MasterCard, American Express, etc.) and transaction information such as a credit card number, card expiration date, etc. Can be entered. The transaction page can also query the end user for personal information such as name, billing address, shipping address, and the like. The end user then submits the information, and the merchant processes the submitted information.

  In this first model, the merchant typically “owns” the web site. That is, the merchant maintains its web site, is responsible for content, and receives and processes transaction information supplied by end users. The merchant can establish an account for the end user prior to making the first transaction, after which the end user can log in via a login and password established by the user each time he / she conducts a transaction with the merchant. You can access your account. That is, the end user typically selects a login name and password to be used in subsequent sessions or transactions. After the end user submits the information queried by the transaction page, the merchant can process the information and verify that the information is sufficient to complete the transaction. For example, the merchant can ensure that the credit card number is valid and has sufficient funds to cover the cost of goods and / or services.

  The second model typically includes a third party transaction provider that processes the payment portion of the transaction. This third party forms a relationship with both the end user and the merchant. Specifically, an end user can establish an account for that third party that can be accessed via login and password as described above. To establish an account, an end user can provide personal information and payment information to a third party (ie, the end user can identify the user with personal information and one or more Multiple credit card numbers, payment information such as expiration dates can be given). The end user can also establish an electronic funds account by supplying money to a third party trading provider, and the balance of the electronic funds account is used to purchase online goods and / or online services. Can be used. The third party archives account information provided by the end user and / or maintains the end user's balance account.

  The third party also establishes a relationship with the merchant, where the third party handles the payment processing of the transaction. Specifically, the third party agrees to make payments to the merchant when an end user with an account requests a transfer of funds to make a purchase. . Merchants can provide this option by signaling the availability of an option to use a third party on a web site where goods and services are sold. For example, when a user visits a merchant's website and decides to make a purchase, the user is presented with an option to pay for the purchase using a third party transaction provider. be able to.

  When an end user selects an option to pay for a purchase using a third party transaction provider, the end user's browser is redirected to a web site belonging to the third party transaction provider. The end user then logs into his / her account via a login / password combination and selects the payment type (eg, credit card) to use for the transaction, or the merchant account from the user ’s funding account. Request transfer of funds to. If the merchant determines that the payment has been properly transferred by the transaction provider, the merchant can proceed to ship the purchased product or provide the purchased service to the end user. In this second model, the third party is responsible for maintaining the end user's personal and financial information and processing the transaction.

  In the drawings, each identical or nearly identical component that is illustrated in various figures is represented by a like numeral. For clarity of illustration, all components may not be numbered in all drawings.

  Traditional online transactions, such as the purchase of goods and / or services over a network, are vulnerable to security breaches that result in loss of personal information, financial information, and / or other sensitive information. Furthermore, in untrusted networks (eg, the Internet), both merchants and buyers are at risk of entering into a deal with a bad actor and losing one side of a sales contract. Traditional online transaction models may also require the merchant to archive the buyer's sensitive information and may require the merchant to process the payment aspects of the transaction. Furthermore, traditional online trading models are cumbersome for buyers and generally provide a non-intuitive trading experience. For example, traditional online transactions are conducted through a browser using a login / password paradigm that is confusing and difficult to manage.

  Applicants are more likely to delegate at least part of the transaction burden handled by buyers and browsers in traditional models to lower level (and away from browsers and end users) systems. Confirmed and understood that it could facilitate a simpler and more secure online commerce framework. For example, one or more trading tasks may be handled by an end user and / or merchant operating system where the information is safer and safeguarded. By embedding one or more tasks in the operating system, the user may be reduced for some of the burden of transferring transaction information, making the experience more intuitive, and enhancing security. it can. Further, merchants can be freed from maintaining buyer information, processing payment information, and / or processing transactions.

  Applicant has further recognized that the problems associated with validating a buyer's identity can be mitigated by leveraging technology that is more secure and convenient than the login / password model. . In one embodiment, the identity information about the purchaser is provided by a subscriber identity module (SIM) card that stores identity information about the end user, which can be issued programmatically, and more A misleading and simpler purchasing experience (straightforward purchasing experience). Further, some embodiments are configured for single-level or multi-level authentication using SIM devices over an otherwise untrusted or non-secure network (eg, the Internet). Protocols, methods, computing systems, and other mechanisms are provided.

  Applicant further recognizes that using various third party parties that are totally uninteresting to provide the various trading elements of online commerce reduces the risks for both buyers and merchants. did. In one aspect of the invention, the first network entity provides verification of the purchaser's identity and the different network entities provide verification of the user's solvency for the purchase, thereby not knowing each other. Provided is a commercial transaction system that enables merchants and purchasers to conduct transactions relatively safely.

  Further embodiments include three-way secure commerce between merchants, consumers, and payment providers, where sensitive billing account information is used by merchants or third parties. In a way that makes it opaque. In such an embodiment, a payment token is passed between the merchant and the payment provider via the consumer. Such payment tokens are encrypted or signed in such a way that merchants and others have no control or access to consumer sensitive account information. Nevertheless, the merchant can confidently validate a payment token that indicates the consumer's ability to pay for the services and / or goods provided.

  In another embodiment, electronic billing information is used for payment authorization, auditing, and other purposes. In this embodiment, various network entities (eg, consumers, merchants, payment providers, etc.) are given a machine readable electronic bill, which is an automatic payment Used for billing and validation, transaction history creation, more accurate description of paid services / goods, and other purposes in online commerce. This billing information can also be used for single-payment payment federation from the consumer to the merchant's various business associates. For example, a merchant may have a contractual relationship with various business associates that provide services and / or goods in a commercial transaction. The electronic billing information does not require any user interaction or any separate audit and payment mechanisms, so that payment federation can occur automatically so that payment federation can occur. It can contain multiple payment parts to be distributed between.

  This document also provides automated decision making capabilities for commerce using rules or constraints defined by any number of network entities including consumers, merchants, payment providers, and the like. For example, payment options accepted by the merchant can be compared to payment options available to the consumer. Based on such comparisons, only matching options can be presented to the consumer. Instead, payment options can be automatically selected based on such comparisons and / or based on additional rules or constraints. For example, the consumer can limit the types of payments based on established trust with the merchant. Of course, there can be many other types of rules and / or constraints that determine the various actions that can occur in a commercial transaction.

  The traditional model of networked commerce is as an interface for requesting and submitting personal and financial information between end-user buyers and merchants or service providers, either directly through merchants or through third parties. The focus is on the browser, either through a trading provider. In the first example, a merchant creates the burden of creating and maintaining an infrastructure that can query, obtain, handle and process personal and financial information, usually with some minimum level of security. Bear. In addition, merchants may be responsible for maintaining accounts and account information (typically including both confidential personal information and confidential financial information) for each of their customers.

  The buyer must provide personal information (eg, name, address, phone number, etc.) and financial information (eg, debit and credit card numbers and expiration dates, banking account number, etc.) to complete the transaction. I have to pass it. At some level, buyers must trust that the merchant is an honest broker, operates in good faith, and uses information only in an authorized manner. Similarly, the merchant must trust that the purchaser is the person the purchaser claims and that the payment information provided is truly associated with the end user making the purchase. There may be no reliable way for the merchant to validate the purchaser's identity and / or payment information. In a distributed network environment, the purchaser may have to rely on the merchant's reputation, which can limit the source from which the purchaser is willing to do business. Merchants may have to operate without the belief that the purchaser is an honest good-will purchaser. In untrusted networks, this model may present undue risk to one or both parties.

  Even when established legitimate trust is deployed between the buyer and merchant, the database that stores customer information maintained by the merchant is hacked, information theft, and otherwise Even the bad guys in a business that are honest and trustworthy can be susceptible. Third-party transaction providers may also be susceptible to electronic theft and security breaches. More sophisticated “spyware” programs allow hackers to record damaged (failed) computer keystrokes and obtain screen shots, especially for browser-based transactions Make it vulnerable to electronic theft. Accordingly, buyers who conduct online commerce using conventional methods and models may be vulnerable to the dissemination and unauthorized use of their sensitive personal and financial information.

  Conventional commerce models typically require the purchaser to establish an account (provide an account at the customer) for each merchant (customer) that the buyer wishes to conduct business transactions with. Generally, an account is protected and accessed via a login name and password, and the purchaser manages multiple logins and passwords and maintains which login / password combination corresponds to which account. Need. Some customers use a means of storing their login / password combination locally on their computer or using the same login / password combination for all accounts. Both attempts to manage multiple accounts are vulnerable to theft, hacking, and / or other security breaches.

  For example, a customer is at risk of breaking all of the customer's account if a single login / password combination is obtained by electronic theft. In addition to the inherent security risks associated with the traditional login / password paradigm, the purchaser may find that the account login procedure is an inconvenient trading experience. Specifically, requiring an account login when a purchase is desired requires that the transaction be created in some way before the buyer can complete the transaction, Make it inconvenient. Further, when using a third party transaction provider, the purchaser is redirected from the merchant's web site to the third party transaction provider's web site. This step is not intuitive and, at best, cumbersome and confuses the buyer.

  Applicants can simplify by delegating (separate from browsers and end users) at least a portion of the transaction burden handled by buyers and browsers in the traditional model to lower level systems. Confirmed and recognized that it could facilitate a more secure online commerce framework. In one embodiment, one or more trading tasks are handled by the operating system (or some other trusted subsystem) at one or both of the end user and merchant, where the information is more secure Can be protected. By embedding one or more tasks in the operating system, the user can be relieved from some of the burden of transferring transaction information, making the experience more intuitive and enhancing security. Further, merchants can be freed from maintaining buyer information, processing payment information, and / or processing transactions.

  Applicants have further realized that the problems associated with validating a user's identity can be mitigated by leveraging technology that is more secure and convenient than the login / password model. In one embodiment, the identity information about the purchaser is provided by a subscriber identity module (SIM) card that stores identity information about the end user that can be issued programmatically. In another embodiment, the identification information is provided by a smart card that is incorporated into or otherwise coupled to the network device where the purchaser conducts online commerce. By using any of a variety of chip-based or card-based identity means, the purchaser links the purchaser's identity to a specific device, such as a cell phone or networked computer It becomes possible to do.

  The terms “programmatically” and / or “automatically” refer to actions that are performed substantially without manual or operator intervention. Specifically, programmatically or automatically refers to an action initiated and / or performed by one or more computer programs. For example, the provision of identification information by requiring a user (eg, a purchaser) to provide login and / or password information is considered programmatic because the substance of the action is performed by the user. Should not be. However, the action when the program issues identification information (eg, SIM number, network address, hardware ID, etc.) without requiring the user to enter information should be considered programmatic. . It should be noted that such automatic operation can be implemented by either software components or hardware components.

  Applicants have further recognized that distributing various trading elements of online commerce across different network devices facilitates more secure commerce over untrusted networks. In one embodiment, the identity provider and payment provider are both separate users and end users and merchants and separate network entities, but provide validation support during commerce. The term “network entity” as used herein refers to network presence and may be one or a combination of end-user / buyer, identity provider, payment provider, merchant, and the like. A network entity may have a presence on the network via one or more network nodes. For example, a single networked device such as an identity provider that uses multiple servers to conduct online business, or an end user connected to the network via a cell phone and personal computer Can operate under the direction of a network entity. The network entity can be a company such as a bank or retailer, or an individual such as an end user.

  In one embodiment, the various elements of online transactions are distributed across separate independent network entities. For example, an identity provider can provide identity validation in the form of an identity token, and a merchant can use this identity token to verify the purchaser's identity. The identity token may include one or more identity credentials of the end user. The identity token is the identity information supplied by the end user / buyer, eg, subscription number from SIM card, network address (eg, network interface card (NIC) identification, world wide name (WWN), etc.) ) And can be issued based on login information. Similarly, payment providers can provide end-user payment capability verification in the form of payment tokens. In addition, the payment provider can process payment transactions on behalf of the purchaser in payment for purchases of goods and / or services from the merchant. The framework described above, as will be described in more detail in the various exemplary embodiments provided below, is particularly relevant for buyers and merchants who do not know each other to compare online commerce in an unreliable network environment. Makes it possible to do so in a trusted manner.

  For example, one embodiment provides a three-way secure communication between a merchant, a consumer, and a payment provider for commerce for purchasing services and / or goods in either an online or retail environment. As described in more detail below, a payment token is passed from the payment provider to the merchant via the consumer. Such payment tokens provide proof of the consumer's ability to pay for services and / or goods by allowing merchants to directly validate the authenticity of the token using a payment provider. Such payment tokens uniquely identify authorization to pay for services and / or goods, but sensitive information about the consumer's billing account is not included in the token or otherwise invisible to the merchant. It is either encrypted in the form of Thus, consumer sensitive information is opaque to the merchant, so that even when there is no trusted relationship between the consumer and the merchant, the consumer can confidently send items from the merchant. It becomes possible to purchase. In addition, merchants can validate payment tokens directly with a payment provider, so merchants can maintain financial information about consumers (eg, credit card numbers, account information, etc.) Items can be delivered with confidence about the consumer's ability to pay for such services and / or goods. In addition, the payment provider can validate the authenticity of the incoming payment token from the consumer, so the payment provider can transfer (transfer) funds to the merchant with confidence, thus 3 way secure commerce is completed.

  As previously mentioned, other embodiments of the framework provided herein move portions of the transaction to a more secure subsystem (eg, operating system) of the computing device. It includes an abstract model that allows legacy applications to provide an in-band online commercial transaction experience, additional types of fraud protection, auditing and payment federation ( payment federation), and bill capture and presentation for other payment or authentication purposes, service provider code execution for additional security and merchant-specific functionality, multi-level authentication, and other A number of functions are advantageously possible, including functions. For example, such an abstract model is such that legacy applications and other applications are such that such transactions are performed directly within the application, even though parts of the transaction are performed out of band. In addition, the user can be provided with an online purchase function and an online payment function. Examples include catalog purchases (eg, Amazon, Sears, etc.), direct purchase of multimedia content from within multimedia applications, software / game downloads in trial mode and in-band payment models Including their automatic unlocking, allowing payments for subscription based services such as simple message services via email.

  Furthermore, in another embodiment, capturing electronic invoices in the three-way secure (and other) commerce described above as a mechanism for additional authentication, auditing, payment federation, and other purposes; The presented framework is described in more detail below. Further, by moving the commerce transaction to a more secure part of the subsystem, other embodiments allow the merchant to use certain codes on the machine (eg, additional user authentication, payment rules / mechanisms, user experiences (user Experience), etc.) can be executed with confidence that such code will not be hacked or otherwise compromised. Of course, as described in more detail below, Applicants have further realized other advantageous functions through the use of the abstract model provided herein.

  In another embodiment, Applicants also provide an overall system and protocol that uses mobile modules for secure communications and authentication for identity and payment capabilities for a variety of different services. For example, a subscriber identity module (SIM) (or other similar mobile module) authenticates a user and / or device (service or server) to a service or server in a multi-level validation environment. To prove that the user and / or device are trustworthy). In such an embodiment, the mobile module (and possibly even the user) is authenticated via a network independent of that mobile module's network mobile infrastructure. Thus, the system validates the ownership of the mobile module through authentication of the active billing account in the mobile infrastructure. This is a service that uses a computing device connected to the mobile module and an existing secure protocol (eg, WS-Authentication, WS-Security, and other similar protocols) (WS)) is established. Such secure communications can also be used to authenticate users via other protocols and data exchanges between mobile modules and mobile infrastructure, as described in more detail below. In addition, other embodiments provide protocols and state machines that abstract computing devices (used for communication over independent networks) from the mobile infrastructure. Thus, the mobile module itself becomes a mobile terminal and the computing device becomes a peripheral device and therefore follows current wireless standards such as 3GPP (3rd Generation Partnership Project).

  FIG. 1 shows a block diagram of a commerce system 100 comprising a plurality of network nodes including an end user (buyer) computer 110, a merchant computer 140, an identity provider computer 120, and a payment provider computer. Each of the nodes can include one or more computing devices interconnected via a network 105. It should be appreciated that end user computers, merchants 140, identity providers 120, and payment providers 130 can be associated with network entities such as individuals, companies, or merchants. For example, end user computer 110 is typically associated with an individual who uses that computer to access resources on the network, and merchant computer 140 may be a company or company that provides goods and / or services for sale. Can be associated with a store. The one or more computing devices that form each mentioned component in the commerce system 100 are media (by which entry points, computing platforms, and / or associated network entities communicate thereby over the network). vehicle).

  Note that although the embodiments provided herein can be described in an online purchasing environment, the embodiments can also be used in direct retail transactions. For example, the above and following descriptions of commerce can be applied to consumers who purchase products in a retail store, where payment, identity, authorization, and other embodiments are used. Accordingly, the use of the online experience to describe the embodiments herein is for illustrative purposes only and limits the scope of the embodiments, unless otherwise expressly claimed, or otherwise It is not intended to narrow in shape.

  Note also that the network 105 can be any type of network in any type of configuration that interconnects the nodes connected to the network and allows these nodes to communicate. A node or device can be connected to the network via a copper (eg, category 5) cable, optical connection, wireless, or any combination thereof. Information can be transferred using any low level protocol such as Ethernet and / or any information protocol such as TCP / IP. The network 105 can have any number of devices connected to it, and can be a trusted network (eg, an intranet) or an untrusted network (eg, a LAN / WAN, the Internet, etc.), or a combination of both. it can. The computer connected to the network is any type of device, including but not limited to one or any combination of mobile phones, desktop computers, tablet personal computers, servers, workstations, etc. be able to.

  FIG. 2 shows a diagram of a system and method for initiating and performing identity verification in an online transaction according to one embodiment of the present invention, and FIG. 3 illustrates payment negotiation in an online transaction according to one embodiment of the present invention. FIG. 2 shows a diagram of a system and method for performing verification and / or certification. These methods can be used separately or in combination to perform online transactions between end users / buyers and merchants. In the following description, no distinction is made between network entities and associated network devices unless specifically noted. For example, an “identity provider” is an identity provider (for example, a bank, government agency, agency, etc.) as an entity and an entity that performs various network functions such as providing identity verification for end users. It is used generically to describe an identity provider as a computing device that utilizes or otherwise acts on behalf of an entity.

  The end user computer 110 can place (issue) an order 242 to the merchant 140. The order 242 may be any indication that the end user wishes to purchase one or more goods and / or services from the merchant 140. For example, order 242 may result from the end user selecting goods or services via a web browser that displays a page that resides on the merchant's web site, as described in more detail below. Or it may result from selecting an option from a locally running application. As a first illustrative example, merchant 140 may provide a web site that displays or otherwise provides goods and / or services offered by the merchant for sale or otherwise. Can provide an online catalog. Order 242 can be any type of indication that an end user wishes to purchase one or more goods and / or services from merchant 140.

  As an example of a second example and as an alternative to selecting one or more goods and services from the merchant's web site, order 242 may be received from an application or other program local to end user computer 110. It can be emitted. For example, an end user can create, produce, or edit a document through a word processing application, design a slide show using a presentation application, and / or use an imaging application. You can manipulate posters or brochure images or graphics. The application allows the document to be printed by a third party under the print menu, for example to take advantage of printing features that may not be available locally or to take advantage of professional printing services in other ways Options to include. When this option is selected, the application can send an order 242 to the merchant 140 over the network. It should be appreciated that order 242 can be any indication for purchasing any goods and / or services, as aspects of the invention are not limited in this regard.

  In response to order 242, merchant 140 provides an indication of end user 110's identity of the end user and / or that the end user is actually the person he / she claims. Can be requested (step 205). For example, merchant 140 may not know anything about the source of order 242, information about the end user's identity, and / or that the end user has not impersonated his / her identity. Warranty, can ask for. Instead, the merchant 140 can send a notification or indication that payment is required for the service and request that a payment token be provided. In order to obtain a payment token, it may be necessary to first establish an identity via an identity token, as described in more detail below. In either case, end user 110 can respond to the request by merchant 140 by seeking the service of identity provider 120 (step 215).

  To obtain the identity token, end user 140 provides identity information to identity provider 120. Identity information allows the identity provider 120 to distinguish between the end user utilizing the end user computer 110 and the various other end users that the identity provider can provide services for. Any information can be included. For example, the identity information can include a unique identifier associated with the hardware of the end user computer 110. In one embodiment, the identity information is provided by a SIM card that issues a unique identifier to the subscriber. The identity information may include a unique hardware number of the network interface card (NIC) of the end user computer 110, a world wide name (WWN), or other network address of the end user computer 110, or Providing any other means by which the end user computer 110 can be identified, including an established login name / password combination (in some embodiments).

  The identity provider 120 uses the identity information to locate an identity credential associated with the end user. For example, the identity provider 120 can include a database that stores identity information and credentials for multiple end users. The identity information can be used to index into the database to obtain the correct identity credentials. The identity provider 120 can be any type of entity. For example, the identity provider 120 may be a mobile phone company that uses the subscriber number supplied by the end user's SIM card to locate the appropriate identification information. In one embodiment, the subscriber number is used to locate and obtain information provided by the end user when subscribing to a cell phone or other device that utilizes SIM technology. Identity provider 120 may be a bank, government agency (such as a registry of motor vehicles (RMV)), or any other facility that maintains identity or credentials associated with the end user. It can be.

  In response to the identity information provided by the end user, the identity provider 120 provides the end user computer 110 with an identity token that provides identity authentication and / or credentials for the end user (steps). 225). This identity token can be any type of electronic message that another network device can use to authenticate, verify, and / or determine the end user's identity. For example, the identity token can include the end user's identity credentials. Identity credentials may include, but are not limited to, name, date of birth, address, telephone number, email address, etc., or any combination thereof.

  The identity token can include an electronic signature from the identity provider 120 that proves that the identity credentials are correct. In this manner, the merchant and / or payment provider may not be represented by an arbitrary end-user, but rather by a disinterested third party (ie, an identity provider). ) Can be trusted. The identity token is encrypted before being sent over the network and decrypted when received by the desired network device (eg, merchant, payment provider, etc., as described in more detail below) It is possible to protect against eavesdroppers on the network. In other embodiments, the payment token is simply a certification of the end user's identity without accompanying identity information.

  The identity provider 120 can send an identity token to the end user computer 110 for transfer (step 235) to the merchant 140 and / or the identity provider 120 can send the identity token. It can be sent directly to the merchant 140. The merchant 140 can then process the identity token to identify the end user and / or verify that the end user is the person he / she claims. An identity token can be used to authenticate certain information about the end user that can affect the transaction. For example, merchant 140 may provide a service that requires the end user to be a certain age. The identity credentials sent with the identity token can be used to ensure that the end user is of an appropriate age and meets this requirement. Merchants 140 may offer discounts to specific end users who are frequent buyers, or to specific end users who received coupons, promotional offers, and the like. The merchant 140 indexes the end user's database to determine whether the end user should qualify or otherwise be specially treated based on the supplied identity credentials. be able to.

  Optionally, the merchant 140 can request validation of the identity token by sending a request to the identity provider 120 (step 245). The request for validation of the identity token can include transferring the identity token from the merchant 140 to the identity provider 120. Upon receiving a request for validation of the identity token, the identity provider 120 can validate the identity token and thereby determine whether the identity token is authentic. The identity provider 120 can then forward an indication of validity of the identity token to the merchant 140 (step 255). Alternatively, the merchant 140 simply validates the identity token itself (step 265) (eg, by assuming that the identity token is valid or otherwise processing the token). ). Optionally, a response can be returned from the merchant 140 to the end user computer 110, where the present invention is not limited in terms of the following, but whether the identity token is valid for this response: Messages, any applicable discount or promotional offer messages, and / or any other type of message (step 265).

  After the merchant 140 processes the identity token and / or receives an identity token validation from the identity provider 120, the merchant 140 provides the end user with a payment verification or validation. And / or provide an indication of how the end user wants to pay for goods or services. The merchant 140 can make this request via a request for a payment token (step 305 of FIG. 3). In response to the request for a payment token, end user computer 110 may request payment provider 130 services. Payment provider 130 can be associated with a third party that maintains financial and payment information for various end users, such as financial institutions, or with a third party broker that processes financial transaction and payment procedures. .

  The end user computer 110 can charge the payment provider 130 for the payment token by sending the identity token to the payment provider 130 (step 315). Alternatively, the end user may use an identifier such as a SIM subscriber number, NIC address, etc. and / or use a login / password combination in a manner similar to that described for the identity provider 120 The payment token can be requested by logging in on the payment provider 130. It should be appreciated, although the present invention is not limited in this regard, that end users can request payment tokens in other ways. Further, the end user can send information about the purchase, such as the price and nature of the purchase, so that the payment provider can verify that the end user can pay. However, it is not necessary to supply purchase information. This is because purchase information may not be required, or purchase information may be processed in subsequent steps of the transaction.

  The payment provider 130 processes the identity token (or other supplied identifier) to find information about the end user. For example, payment provider 130 may access a database of payment information based on identity credentials sent with the identity token. The payment provider 130 can determine what payment capabilities and options are available to the identified end user. Next, the payment provider 130 verifies that the end user has the ability to pay and, in response, generates a payment token and sends it to the end user computer 110 (step 325). The payment token can indicate the end user's ability to pay and / or authentication that the payment provider 130 is willing to process the transaction on behalf of the end user. Next, end user computer 110 may transfer the payment token to merchant 140 (step 335).

  The merchant 140 processes the payment token so that the merchant 140 is satisfied that the end user can pay for goods or services (step 365). For example, merchant 140 can ask payment provider 130 to validate the payment token (steps 345, 355), or simply validate the payment token by itself (step 365). ) (Eg, by assuming that the payment token is valid or otherwise processing the token). The merchant 140 can then begin the process of providing goods and / or services to the end user. Since payment provider 130 can be a third party with no interest, merchant 140 can treat the payment token as essentially payment and eliminate the need to wait until the transaction is fully processed. it can.

  When a merchant trades directly with an end user in a traditional trading model, the merchant may have to ensure that the payment information provided by the end user is correct and sufficient. For example, a merchant applies a supplied credit card number to a credit card system and the number is valid, the card is valid, there is sufficient funds, and / or the card is supplied by an end user. You may need to ask if it is correctly associated with the identity. If something does not match correctly, the transaction may have to be canceled, terminated or abandoned. Further, the closing of the transaction may occur after the end user perceives that the transaction has been completed and is no longer accessing the network and / or no longer accessing the merchant's web site. .

  The merchant may then have to notify the end user that there was a problem with the transaction, and the end user may correct the problem (for example, by entering payment information correctly). By specifying a different card with enough funds, etc.) you will have to do the transaction all over again. In some cases, the end user may not be notified and the business transaction may remain uncompleted.

  In various embodiments discussed herein, payment tokens are not issued unless the end user payment information is correct and sufficient funds are available, and / or otherwise, the payment provider can provide the end user with the payment token. The merchant can proceed with the transaction immediately because it proves in other ways that it pays instead of. Any shortfall in the transaction can be identified and dealt with in real time so that all parties can have some certainty that their expectations regarding the completion of the transaction are met Become.

  In addition, the payment provider can process financial transactions (eg, credit card processing, funds transfer (transfer), etc.), so merchants can process credit card numbers or payment procedures, for example. It can be freed from establishing and maintaining the necessary infrastructure for processing, transferring funds. Payment tokens, in some cases, allow payment providers to send specified funds, for example by establishing a money transfer or electronic transfer of money to a merchant. Works as a guarantee. A payment token can also be a guarantee that payment is made by non-electronic means, such as a contract to issue a check or other transferable security to the merchant.

  From the merchant's point of view, commerce involves end user identity and payment verification handled by a third party, thus fraud, spoofing, and even innocent errors in providing personal and financial information. Because it is more difficult to receive, it is virtually risk-free. Thus, merchants may be aggressive in conducting online commerce with unknown end users over untrusted networks. From the end user's point of view, personal and financial information resides in either the entity that already maintains that information and / or the entity with which the end user has established a relationship. The end user's confidential personal and financial information need not be provided to the merchant, reducing the vulnerability of confidential information being misused or misappropriated. As a result, the end user does not have to worry about whether the merchant is trustworthy or may be aggressive in conducting business transactions with unknown merchants.

  In some conventional commerce models, identity information and payment information are entered by the user and processed by either a third party or merchant. As mentioned above, these models are inconvenient, inefficient and time consuming for the user. In addition, traditional models pose a number of issues related to the security of end user sensitive information, in addition to making merchants vulnerable to fraud and / or being subject to payment defaults by end users. Applicants have recognized that commerce software installed on each of the computers used for various commerce transactions can alleviate or eliminate security and fraud concerns. In addition, many of the actions handled by end users and merchants in the traditional model are performed by commerce software, allowing transactions to be made simpler and more intuitive by end users.

  FIG. 8 illustrates some examples of the use of the functions described above with respect to three-way secure communications and the various trust boundaries that can be established during commerce. As described in more detail below, this model can be applied to single or subscription payments (payment federation) that allows service providers or merchants to aggregate payments for smaller companies. single or subscription payments), which allows customers to pay a single invoice. As shown, distributed system 800 is configured to facilitate business transactions between consumers 810, merchants 830, and payment providers 805. A payment trust boundary 815 divides the merchant 830 from the consumer 810 / payment provider 805 so that there is a trusted relationship between the payment provider 805 and the consumer 810 or customer computing device. (I.e., using any of the available mechanisms described herein, the consumer properly identifies or authenticates itself to the payment provider. (Proves trustworthiness)). Thus, the consumer 810 can utilize this trusted relationship to authorize payments to the merchant 830 for different types of payments and different types of services.

  For example, assume that merchant 830 requires reserve payment for a product that consumer 810 desires to purchase (eg, a custom item that requires a prepayment, such as a car, computer, etc.). However, prior to requesting payment authorization, the user of the consumer 810 computing device may require appropriate authentication as described herein. Once the user authenticates, the consumer 810 computing device can properly request payment from the payment provider 805, also through any of the various mechanisms described herein. For example, the consumer 810 may provide billing information or other request information to the payment provider that is signed or encrypted by the consumer's 810 computing system. This is the ability of the account owner (ie, the consumer) to pay appropriately (ie, the user is charged with other billing accounts such as prepaid accounts, credit accounts, or mobile subscriptions as described below). Authenticate the request for validation. If the authentication is successful, a payment token is issued and then the funds are reserved to guarantee payment. Such payment tokens are typically signed by a payment provider (eg, the mobile web server described herein) and / or otherwise encrypted and passed to the consumer 810 client. . The consumer 810 passes this payment token to the merchant 830 who verifies the token against the payment provider and completes the order if successful.

  Once the item is ready for delivery (eg, finished creating a custom item), the merchant 830 can request payment from the payment provider 805 using the reserve payment token. Note that the amount requested for payment may differ from the amount secured. Nevertheless, payment provider 805 validates and returns a payment response to merchant 830 and / or consumer 810. Once approved, the merchant 830 can ship (or otherwise supply) the order to the consumer 810, and the payment is provided. On the other hand, if payment is rejected or further user interaction is required, merchant 830, payment provider 805, and / or consumer 810 can choose which action to take. For example, if the amount requested by merchant 830 does not match the funds secured, payment provider 805 and / or merchant 830 can request permission from consumer 810 for the new amount. Alternatively, payment provider 805 can request user input to allow the transfer of funds regardless of any changes in the reserved amount and the requested payment amount. Of course, other actions and procedures for completing a commercial transaction are also contemplated herein.

  Note that although the above three-way secure payment mechanism has been used to purchase reservation items, a single payment can also be applied to other services and / or goods. For example, this single payment mechanism can be applied to software programs that are ready to be downloaded immediately. Alternatively or in conjunction, this single payment can unlock various levels of the downloaded program (eg, student version, professional version, or other separate functionality). Indeed, as will be appreciated, the above single payment can be used for a variety of different types of purchases, sometimes with slightly modified payment formats.

  For example, a consumer 810 may have a continuous service (eg, a newspaper or magazine subscription, a mobile subscription, a gaming application, or other pay-as-you go goods and / or services) Suppose we want to set up a subscription with merchant 830. Thus, the merchant 830 requests the consumer 810 for a payment token, and thus the consumer 810 client interacts with the user, requests permission, and proceeds as described herein. Similar to above, the consumer 810 signs a request for payment or encrypts the request (eg, using the electronic billing information described below) and sends such request to the payment provider 805 ( (E.g., mobile operators, credit card companies, prepaid or other types of third party services). This authenticates the request and verifies that the account owner (ie, consumer or customer) has sufficient initial funds. If successful, a payment token is issued, signed, and / or otherwise encrypted and returned to the consumer 810 client, which returns the payment token to the subscription merchant 830. hand over. The merchant 830 then verifies the authentication of this token and completes the subscription setup.

  Note that payment tokens are typically stored at the merchant 830 side and are used periodically when requesting payment payment from the payment provider 805. Thus, when processing a subscription payment, the merchant 830 retrieves the payment token and sends it to the payment provider 805 for payment settlement. Payment provider 805 validates and returns a payment response to merchant 830 and / or consumer 810. If an authorization response is returned, the subscription merchant 830 receives payment during the next payment provider 805 account payment execution. However, if the payment request is rejected, payment provider 805 and / or merchant 830 can respond accordingly. For example, the merchant 830 (or payment provider 805) can contact the user or consumer 810 (eg, via email) and inform the user or consumer 810 about outstanding payments. The consumer 810 can then make the single payment described above or set up another subscription payment either through the same or different payment provider 805. Of course, the merchant 830, payment provider 805, and / or consumer 810 may have other rules or requirements regarding these and other payment authorizations, as described in more detail below.

  As previously mentioned, other embodiments allow federation of a single consumer 810 payment to multiple business associates or subsidiaries in a contractual relationship. To. Often, business relationships are complex and require the distribution of payments for various services and / or goods provided within a particular business model. For example, when purchasing a trip from a travel agent 830, the consumer 810 may be given a package deal that includes airline arrangements, hotel accommodation, transportation services, and the like. A merchant 830, who typically outsources many of such services and / or goods, must leave a detailed account of such business transactions in order to make appropriate payments to his business associates. To reduce the complexity of such accounting tasks and other tasks, the embodiments herein provide automatic payments on a per transaction basis to certain types of business associates. Provide federation.

  For example, a car rental service (eg, business associate “A” 820) may request payment from merchant 830 as part of a holiday package sale. An insurance company (eg, business associate “B” 825) may charge the merchant 830 on a per transactional fee basis. Based on a business associate trust boundary 835, payment is automatically made to each business associate (eg, “A” 820 and “B” 825) when a single payment is made to the merchant 830. Federated. In other words, the consumer 810 or payment provider 805 makes a single payment to the merchant 830, but all subsidiaries that have a business relationship with the business model trust boundary 835 get paid appropriately. be able to. Note that such payments are typically tied to an electronic billing statement, as described in more detail below. More specifically, the various parts of the electronic invoice for capture, presentation, and other purposes correspond to which part of the payment must be federated to each business associate. can do. In addition, each of these portions is signed and / or encrypted, so that specific information regarding payments can be made to the consumer 810, payment provider 805, as defined by various trust boundaries 815 and 825. Or between the various business associates 820 and 825.

  Although the above payment federation model has been described in terms of a travel agency experience, it should be noted that there are other business relationships that can use this embodiment. For example, companies that make items with multiple components purchased through various vendors, product providers that purchase product materials and pay for each item, payments for multimedia products that pay royalties based on each sale Alternatively, any other type of business model that can be bulk sold or otherwise calculated and paid to a merchant for each item can also use the embodiments described herein. it can. Accordingly, the use above of a travel agency to describe various embodiments herein is for illustrative purposes only, limiting the embodiments described herein, or other It is not intended to narrow in shape.

  FIG. 4 illustrates a networked computer system for processing business transactions according to one embodiment of the present invention. Networked computer system 400 may be similar to computer system 100 shown in FIG. However, in FIG. 4, each of the computers in system 400 includes a local installation of commerce software 485 (locally installed software). Specifically, end user or consumer computer 410, identity provider 420, payment provider 430, and merchant 440 each include commerce software 485a-485d. The commerce software installed locally on each computer of this system can be the same, or the role that the computer plays in the transaction (ie, the computer is an end user node, merchant node, identity node, It can be customized for a particular computer in view of a provider node, a payment provider node, etc., or any combination of the above. In either case, each installation is configured to communicate with installations on other networked computers to perform online transactions. For example, each installation can be configured to communicate with an installation on a networked computer to perform the method illustrated in FIGS. 2 and / or 3.

  In one embodiment, local installation of the commerce software 485a on the identity provider 420 can create an identity token that identifies the end user utilizing the end user computer 410. In addition, the present invention includes, but is not limited to, commerce software 485a on identity provider 420 transfers this identity token to end user computer 410, payment provider 430, merchant 440, and / or any other computer. can do. The local installation of the commerce software 485b on the end user computer 410 responds to an indication of conducting an online transaction between the end user and the merchant (identifies the end user). Identity information can be issued. A local installation of commerce software 485c installed on payment provider 430 receives the identity token and generates a payment token (eg, payment token) that verifies the ability of the end user to pay for the online transaction. A local installation of commerce software 485d installed at merchant 440 may receive a verification of the end user's ability to pay before proceeding with the online transaction.

  In one embodiment, each of the computers in system 400 operates using the same or similar operating system 495 local installation. For example, each of the computers in system 400 can operate using the Microsoft Windows® operating system. Commerce software 485 can be a subsystem of its operating system. In this way, the various computers used for commerce communicate in a consistent and known manner. Because commerce software communicates directly over the network and handles validation, verification, and security, end users and merchants do not need to know anything about each other, and more importantly, There may be no need to establish any trust relationship. In addition, because some part of the transaction is handled by the operating system, many of the transactions can be executed substantially invisible to the user, causing confusion and often troublesome by the end user. Does not require intervention.

  By having commerce software on each computer, various encryption techniques can be used to transfer information from one computer to another. In addition, additional security features can be included such as identity tokens and / or payment tokens that are valid for a limited time period. For example, an identity token is a time period, after which all components that receive and process the token must consider the token invalid and use it as a verification of identity and / or payment. A time component can be included that specifies a time period that should not be respected. The commerce software component can process any time limit associated with the token programmatically. This can prevent tokens obtained by “phishing” from being used inappropriately at a later date.

  It is understood that the commerce software need not be part of the operating system, but can be any program or group of programs local to the computer used for commerce that can communicate with each other over a network. I want. For example, the commerce software can be an application developed by a third party that can be installed on a computer to operate on or independently of the operating system installed on the computer. This application can be used from any computer or device that has a wide range of functions and configurations and is not limited to a particular operating system, processor, instruction set, etc. It can be configured to work with the combination.

  FIG. 5 illustrates a business transaction that is initiated by an end user selecting one or more desired goods and / or services, where the multiple transaction components for the purchase are at least in part, Processed by a trading software subsystem distributed as part of various computer operating systems associated with one or more transactions. An end user connected to the network 505 via the end user computer 510 may be running the application 555. Application 555 may be a browser that displays a company's web site that provides goods or services for sale. Application 555 may be an application that provides options for online transactions, such as an imaging editing program that allows a user to manipulate an image.

  The end user can select one or goods or services to purchase via application 555. For example, an end user may wish to have the edited image professionally printed on photo quality paper. Application 555 may include such options under the print menu. This print option, when selected, can generate a window or dialog box that lists all of the available print options, including services available over the network. For example, service providers 540a, 540b, and 540c may be listed as options for providing print services in the print options. When a user selects one of these service providers, the online commerce described above can be initiated. Specifically, the service provider can request that the end user supply an identity token. In response, application 555 (or an application embedded in commerce software 585) can generate a dialog box or interface that lists the available identity providers. For example, as described in more detail below, this dialog box lists identity providers 520a, 520b, and 520c as possible identity providers that a user can select to handle identity verification. it can.

  FIG. 9 illustrates the use of trusted commercial subsystems and other functions in a distributed system, according to an example embodiment. As shown, local computing device 920 in distributed system 900 is configured to provide online or local retail transactions in accordance with the embodiments described herein. Note that although the trusted commerce subsystem 965 is illustrated only as part of the local computing device 920, similar subsystems may reside in other network entities. Additionally, although various components or modules may be described herein as residing on any particular network entity, such components or modules are distributed throughout the computing system and are optional. Note that multiple portions may reside on one or more network entities (ie, multiple portions may reside on one or more network entities). Accordingly, the particular aesthetic layout of a particular module and the use of that module by a network device or network entity is used herein for illustration purposes only and is within the scope of the embodiments herein. It is not intended to limit or otherwise narrow.

  Regardless of the distribution and aesthetic layout of the system 900, there is a trust boundary 906 that separates the trust relationships between the various components, as previously described. Although this relationship can be divided differently, in the current example, a trust relationship exists between the payment provider 990 and the trusted commerce subsystem 965. This advantageously allows a number of functions that current commercial systems cannot provide. For example, trust boundary 906 abstracts application 925 from a commercial transaction with a merchant. Thus, legacy applications and other applications 925 can provide an end-user 940 with an in-band experience, although much of its functionality appears out of band. For example, in the above example that enables professional image printing on photo quality paper, selections in the pull-down menu, identity validation, payment options, and other components to assist users in such service purchases Appear as part of application 925. Thus, upon receipt of input to purchase services and / or goods, application 925 can make a purchase call 930 to trusted commerce subsystem 965, and trusted commerce subsystem 965 can Thereafter, as described herein, a dialog box is generated and used to receive user 940 input 935 or automatically communicate with merchant 905 and / or payment provider 990.

  In other words, the user 940 does not necessarily have to trust the application 925 or the merchant 905 in a commercial transaction. Instead, trust is limited to the subsystem 965 of the present framework, which reduces the degree or level of trust required to securely and securely execute a business transaction. That is, account details 950 of user 940, which includes sensitive information 955 (eg, credit card information, personal information, username / password, etc.) that user 950 disagrees with or is uneasy about sharing. Accessed either directly through user input 935 to subsystem 965 or from a secure (960) account information store 945. Thus, application 925, merchant 905, and other components are abstracted from financial and other billing account details 955 controlled by subsystem 965, as described herein. This is very different from the current commerce model described above, where the application 925 or merchant 905 maintains and controls account information. Thus, this and other embodiments described herein advantageously provide an additional layer of security during such commerce. This is a more fine-grained trust relationship to minimize the number of companies or organizations that have access to or handle highly sensitive financial data.

  Similarly to the three-way secure commerce shown in FIG. 9 and described above, the trust boundary 906 also indicates secure communication between the payment provider and the trusted commerce subsystem 965. Accordingly, subsystem 965 authenticates to payment provider 990 (s) in any one of a number of ways described herein (provides trust to payment provider 990 (s)). And enable secure communication with the payment provider 990. Similar to the above, it can be a local computing device (a handheld portable device described below for local retail transactions, a personal computer for online transactions, or other similar devices described herein) ) Requests various services and / or goods provided by merchant 905. In this example, billing information 910 is presented to local computing device 920 for authentication, auditing, and other purposes used in the example embodiments described herein. Is done. Such billing information includes, but is not limited to, the cost of goods and / or services, a detailed description of the transaction, information specific to the merchant 905, federation payment information, the type of transaction (eg, single payment, subscription Etc.), or other types of billing information. The billing information 910 may also include other information such as merchant constraints and payment options, as described in more detail below.

  In one embodiment, billing information 910 is an electronic bill configured to be machine readable, which provides a number of advantageous capabilities of current commerce systems. For example, one embodiment provides that the billing information 910 can be part of the previously described payment token request 980 (or can be delivered to the payment provider 990 in a separate communication). Thus, bill information can be used by payment provider 990 for payment token validation 940. More specifically, billing information 910 supplied from a consumer or local computing device 920 can be compared with payment token 985 information supplied from merchant 905 at payment token validation 904. . Accordingly, if the billing information 910 for the payment token validation 904 matches the billing information 910 from the token request 980, the payment provider 990 further increases the authenticity and merchant validity of the payment token 985. You can be confident.

  Note that how billing information 910 from the merchant is relayed to payment provider 990 (as well as other components herein) varies. For example, billing information 910 sent from merchant 905 to payment provider 990 may be a copy of billing information 910 sent to trusted commerce subsystem 965 or client 920. Alternatively or in conjunction, the billing information 910 is a signed and / or encrypted version from the payment provider 990 routed through the consumer or local computing device 920. There is. In either case, the payment provider can make the comparison described above with respect to authentication of the payment token 985.

  Further, the billing information 910 used by the payment provider 990 can also be used to subsequently provide a more detailed description of the billing amount associated with the bill presented to the user 940 regarding the amount billed to the user's account. Note that you can. This can also be a machine readable bill 910 so that the local computing device 920 has previously received the bill information 910 for further authorization of payment to the merchant 905 by the merchant 905. Can match with invoice information. In other words, if the invoice information 910 in the invoice from the payment provider 990 does not match any of the invoice information received from the merchant 905, the amount charged can be considered a fraud.

  In another embodiment, the merchant 905 can use the bill information 910 for auditing, user and other authentication purposes, payment federation, and the like. For example, the merchant can sign or encrypt portions of the bill information 910. This allows a number of advantageous functions in the embodiments described herein. For example, bill information 910 may be part of a payment token 985 that is received by a payment provider via a local computing device 920. The merchant 905 can check the validity of the bill information 910 to authenticate that the payment token 985 came from the client 920 or the trusted commerce subsystem 965. Similarly, during payment token validation 904, merchant 905 validates payment provider 990 and / or local computing device 920 using billing information 910 received from payment provider 990. Or can be authenticated. In other words, because the bill information 910 is routed to the payment provider via the subsystem 965 or the consumer 920, the billing information received from the payment provider that matches the billing information sent to the client 920 is Both the client 920 and the payment token 985 from the payment provider 990 can be authenticated.

  Note that in another embodiment, the invoice information 910 can also be used for payment federation by the merchant, as briefly described above. In this embodiment, various parts of the bill information 910 must be distributed to the merchants as previously described which part of the funds from the payment provider 990 (during successful payment authorization). Can be machine readable to determine. In this embodiment, portions of bill information 910 are typically encrypted or not part of a business relationship with user 940 (or consumer client 920), payment provider 990, or merchant 905. Note that it is made opaque to other components. This also uniquely identifies the merchant within the billing federation and can therefore be used for authentication purposes. More specifically, various portions of bill information 910 that are unique to a merchant can be encrypted using a key that is unique to such merchant, and therefore, a payment request. Information is only viewable by merchant 905 and its particular business associate. However, in other embodiments, the portion of the bill related to payment distribution or federation is only signed by the merchant 905 to make it opaque to other components in the system 900 thereafter.

  Of course, as will be appreciated, other uses of billing information 910 can be used for various purposes. For example, billing information 910 may be used for audit purposes, product distribution reconciliation, or any other well-known business purpose or other purpose. Accordingly, the above usage of billing information 910 for authorization, identification, payment federation, or any other purpose is used for illustrative purposes only and unless explicitly stated otherwise, It is not intended to limit or narrow the scope of the embodiments.

  Note that trust boundary 906 and subsystem 965 also have other advantageous functions in other embodiments described herein. For example, as shown in FIG. 9, payment provider code 970 in subsystem 965 allows one or more payment providers 990 specific code to be executed securely. Such codes may be used for further authorizations specific to payment providers, such as biometric, radio frequency identification (RFID), username / password, or any number of additional authentication techniques. it can. In other words, due to the trusted relationship that payment provider 990 has with respect to subsystem 965, the payment provider can execute trusted code for its own business purposes.

  Use of such code 970 also allows for a more integrated in-band user experience that can be controlled by payment provider 990 or by any other component that has a trusted relationship with subsystem 970. For example, although not shown, a trusted relationship exists between several merchants 905 and the subsystem 965, allowing that trusted code to be executed by the subsystem 965. Can do. Thus, merchant 905, payment provider 990, or any other component used for commerce appears to run from within application 925 (legacy or other form), but many of the events are out of band. An integrated user experience that occurs can be provided. For example, in the above example for photo quality printing of an image by a professional service, a dialog box, payment options, or any other plurality presented (eg, in response to user input) to a user or application functionality Can be controlled by code 970 specifically provided by various trusted network entities (eg, payment provider 990, merchant 905, etc.). Accordingly, this code can also be used when evaluating payment options and other constraints from merchant 905 and / or payment provider 990, as described in more detail below.

  As noted above, in one embodiment, the chosen service provider or merchant sends any requirements to the identity provider along with a request for identity verification. For example, a service provider may sell goods or services that require a minimum age or are restricted to certain geographic locations. Thus, identity provider listings can be limited to those that can supply identity credentials that meet the requirements of the service provider. For example, the list of identity providers can be limited to those that can provide age verification or current address information, such as RMV.

  Similarly, a dialog box can be generated that lists options for a payment provider. For example, the dialog box can list payment providers 530a, 530b, and 530c, which include credit card companies, banks that provide electronic debit services, respectively. Or a private third party that provides financial services. As with the identity request, the selected service provider can include any payment requirements related to the purchase. For example, a service provider may accept only certain types of credit cards. This payment requirement can be reflected in the available payment providers listed in or enabled in the payment provider selection dialog box. After a payment provider is selected, payment authorization can proceed and the transaction can be completed.

  Note that other embodiments allow for comparison of consumer rules and merchant constraints (eg, available payment options, age limits, etc.) that determine the various actions that can be taken. FIG. 10 illustrates such an embodiment where the distributed system 1000 is configured to programmatically determine actions based on merchant constraints 1010 and / or consumer rules 1035 and the like. For example, the merchant 1020 may define within the merchant constraint 1010 a payment provider 1005 or type of payment that can be accepted for the merchant's service and / or purchase of goods. The decision module can then present such constraints to the user, eg, at a user interface that requires user input 1040 to select one or more available payment options. Based on user input 1040, an appropriate payment provider 1005 can be contacted for proper funding of services and / or goods.

  In another embodiment, consumer rules 1035 may be used in addition to or instead of merchant constraints 1010. For example, the consumer rule 1035 can indicate that only certain types of payments can be made for certain types of merchants 1020. More specifically, the consumer rule 1035 determines from the merchant 1020 only payments that can be reversed if the merchant 1020 is not registered or otherwise trusted. It can be shown that it can be used for purchases made.

  Of course, as described above, other merchant rules 1010 and consumer constraints 1035 can be used by the decision module 1030 when determining actions to be taken in a commercial transaction. Indeed, merchant constraints 1010 and consumer rules 1035 can be compared for compatibility and other purposes. For example, when presenting a selection of payment provider 1005 to the user, available payment options from merchant 1020 can be compared to payment provider 1005 that is available or acceptable by the consumer. Of course, payment selection can also be made automatically based on default settings, provider ratings or preferences, or any other optional settings. In fact, any number of actions can be taken based on the implementation of various merchant rules 1010 and / or consumer rules 1035. For example, if a rule (merchant 1010 or consumer 1035) does not pass or is otherwise violated, additional input from merchant 1020 or user 1040 (automatically based on either additional rules or settings) ) May be required to resolve conflicts or other discrepancies. Accordingly, the specific actions taken when implementing the defined constraints and / or rules are used herein for illustration only and limit the embodiments provided herein. Or intended to narrow.

  Furthermore, it should be noted that as described above, merchant constraints 1010 can be included in billing information or provided separately to consumers. It should also be noted that all of the various rules and comparisons of actions taken thereby can occur hidden, i.e., unknown to the user and / or other system components. Furthermore, it should be noted that the system is not limited to only constraints or rules defined by either consumers or merchants. For example, the payment provider can also define various constraints that can be considered in conjunction with or in place of consumer rules and / or merchant rules. Thus, the use of merchant and consumer constraints to determine various actions (such as payment provider options) is used herein for illustration purposes only and is not expressly stated otherwise. It is not intended that the scope of the embodiments be limited or otherwise narrowed unless otherwise claimed.

  In traditional online transactions, it may be difficult for both the end user and / or service provider to reliably know when the transaction is completed and whether the goods or services have been successfully delivered. For example, an end user may select a software package for download over a network, or an end user may purchase songs, music, or other electronic media. Often, the network connection may be interrupted before completing the download. In such a situation, the end user may be tempted to select the item again, but the end user hesitates because he or she does not know if he or she will be charged twice for the purchase. there is a possibility. Similarly, service providers may not know if the download was successful and completed, and can be charged twice when the user tries to repair the interruption by selecting the item again There is sex.

  Applicants have recognized that some of the uncertainties associated with electronic downloads can be eliminated by providing a logging or auditing function in commerce software. For example, the final execution of the payment option may be based on a signal that the download from the audit function is complete. That is, if the download is interrupted, the end user can be confident that the selected payment option has not progressed to completion. For example, the commerce software 585 of FIG. 5 (or other subsystem or network entity component described herein) includes a logging function that records all of the various steps of commerce performed by the machine. Can do. The logging information can be used as proof of purchase or as a commemorative transaction. In addition, the final payment may be made only after the transmission of this verification, including a monitoring function for electronic downloads that sends the commercial transaction software 585 a verification of the successful download. By subjecting the payment to a signal that the transfer of goods or services has been successfully completed, the problem of double billing can be addressed and substantially eliminated.

  The software is developed by multiple companies, from well-known word and document processing, spreadsheets, imaging editing, video editing, computer graphics software, web content development applications, portfolio management software and more Handle a wide variety of tasks, including specialized tasks. However, having software that handles each task that an end user may wish to perform can be prohibitively expensive. Software packages can cost anywhere in the range of hundreds to thousands of dollars, tens of thousands of dollars, and even hundreds of thousands of dollars to obtain a single license. In addition, end users may need services for a particular application only occasionally or sporadically, and the cost of purchasing that application may not be justified.

  Applicants have recognized the benefits of allowing end users to use software in a pay-as-you-go environment. Specifically, the end user spends time using the application rather than paying the retail price of the software (if many of the features and / or applications remain rarely used) Can only be claimed for. FIG. 6 illustrates a networked computer system having a commerce framework that allows end users to pay for the amount of time spent using an application. Networked computer system 600 includes a network 605 that interconnects end user nodes 610 to a plurality of identity providers 620, a plurality of payment providers 630, and a plurality of service providers 640.

  End user node 610 may be a computer running on operating system 695. A plurality of software applications 655 can be installed on the end user computer. Software applications may have been bundled with the computer at the time of purchase, downloaded for free over the network, or in other forms (often by the application seller) , Distributed free of charge, at nominal charges, or in exchange for vendor registration. The application 655 can be any type of application, and any number of applications can be installed on this computer. Service provider 640 may be associated with one or more applications installed on end user computer 610. For example, service provider 640a may be one or more computers owned by the developers and sellers of application 655a. Similarly, service providers 640b and 640c can be associated with applications 655b and 655c, respectively.

  In the on-use payment model, the service provided by the service provider is a license to use its associated application installed on the computer. For example, when software (eg, application 655) is distributed free of charge, the software is initially disabled so that the user cannot run the application without first obtaining a license from the seller of the application. Can. The license can be obtained by initiating a commercial transaction with one or more of the service providers 640. For example, application 655a can be a desktop publishing application that an end user wants to use for two hours to design a card or brochure. When the end user opens the application 655a, the end user is notified that he needs to purchase a license to use the application. For example, a dialog box can be displayed that lists the characteristics and prices of various used licensing functions.

  The license may be for a specified length of time, for example 1 hour or 1 day. This license can expire when the application is closed, or the license can remain active until the period expires. A license can be based on an action or task that allows an end user to complete one or more jobs or use one or more desired functions. The additional functions used can increase the cost of the license. It will be appreciated that licenses having any desired duration can be negotiated. However, aspects of the invention are not limited in this regard.

  If an end user selects a licensing option, he can instruct the end user to select an identity provider and / or payment provider to initiate an online transaction, or either Or the other can be selected by default. The transaction can be processed by the commerce software 685 substantially as described in any of the previous or subsequent embodiments. When the service provider receives a payment token from one of the payment providers 620, the service provider can send a license according to the terms agreed upon at the start of the transaction.

  The received license can be processed by a generic license service 690 so that appropriate accessibility to the application can be invoked. The comprehensive license service can then issue an enable key to the application 655 so that the user can run the software and take advantage of its functionality in accordance with the license. The enable key can include all information that the application may need to provide the necessary services for the period indicated in the license. The enable key can include a password supplied by the service provider that allows the application to know that the license is valid and / or a comprehensive license that a valid license has been obtained. You can simply rely on the petition from the generic license service 690. Once the application is in operation, the metering engine 694 is always aware of the passage of time and can be notified to indicate to the application when the license has expired. Instead, the application can be programmed to periodically query the metering engine and disable itself when the license expires. Further, by querying the metering engine, the application can give the user a periodic warning or update regarding the length of time remaining in the purchased license if the license includes a period.

  When finished, the end user can choose to have the finished product professionally print and select a print option that initiates another online transaction, such as the transaction described with respect to FIG. Pay-per-use licenses provide users with much greater flexibility and should not have previously had access (rights) due to the cost of purchasing software packages with lifetime licenses. Give users access to the software. In addition, software vendors are unwilling to pay the total retail price, but can take advantage of revenue from users who are willing to pay for limited use and / or limited functionality.

  Software piracy affects revenue across the entire software industry. The user's unlicensed software causes the industry to lose a relatively significant amount each year. If a software product is purchased, the merchant has little control over where and how many computers the software is installed. The illegal provision of software for download purposes on the Internet provides a more ubiquitous way for end users to distribute and obtain unpaid software. Applicants alleviate the problem of piracy by providing a relatively secure and simple commerce network with a pay-per-use licensing scheme, such as the framework described in the embodiment shown in FIG. I understand that it can be removed. Since the software is distributed free of charge by the merchant, the end user can occupy the software in whatever form the end user deems appropriate. Because the software is only enabled through paying for term licenses or task licenses, end users are substantially limited in their ability to exploit the software.

  As previously described, embodiments herein use a mobile module (eg, a subscriber identity module (SIM)) tied to a specific billing account or operating system of the mobile infrastructure. Enabling authentication for identity and / or payment purposes. Unlike normal standards for mobile communications that occur over trusted wireless networks (eg, Global Systems for Mobile communications (GSM), 3rd Generation Partnership Project, and other similar protocols), Authentication according to embodiments is performed over an independent untrusted data network (eg, the Internet). As a result, embodiments herein address many of the additional security concerns imposed by the use of such mobile modules (SIMs) in web services and other independent network protocol environments. . Such security concerns include, among other things, the determination of trusted network end points for server authentication, authentication of clients to mobile modules or SIM devices, authentication of users to SIM devices, and SIM Authentication of the authentication server, establishing a secure network connection between the mobile module and the network authentication server, and authenticating the user to the network authentication server.

  Furthermore, in order to comply with GSM, 3GPP, and other standards, additional requirements are imposed on terminal equipment that interacts with the mobile module or SIM device. More specifically, GSM, 3GPP, and other similar standards require that the SIM restrict access to certain types of information, including encryption keys, to mobile terminals. To meet these requirements, embodiments of the present invention provide an abstract security profile that delegates certain message processing and decoding and security to the SIM device itself. For example, as shown in FIG. 11, when the firewall 1090 communicates over the independent network 1060, the firewall 1090 provides a state machine and protocol message that abstracts the SIM 1085 from the host device 1075. Define. More specifically, the firewall 1090 provides a formal state machine that limits or constrains the number and / or sequence of commands sent from the read driver in the host 1075 to the SIM 1085 itself. use. Thus, a SIM device 1080 (eg, cell phone, SIM interface, etc. “Mobile module” represents the generic term “SIM”, but is used herein interchangeably unless expressly claimed otherwise. (Note that it is used) becomes a mobile terminal and the host device 1075 becomes a peripheral device compliant with the communication protocol 1055 of the mobile network 1050. The following describes in more detail some of the state machines and protocols used to address some of the additional security requirements and concerns outlined above.

  The embodiments herein are independent of untrusted independent networks (eg, independent of wireless networks corresponding to the mobile module infrastructure or operating system) for the various security levels that a given security token can represent. A security profile for authentication over the network. The various security levels include, but are not limited to, device security level, network security level, user security level, and service security level. Each level has different requirements and procedures for obtaining a security token. Thus, as described in more detail below, each security level represents a different level of authentication within the security model, each with certain requirements and / or guarantees. Furthermore, it should be noted that each security level may or may not be independent of other security levels. For example, it may not be necessary to establish a device security level before network security level or user security level can be achieved, but such a hierarchical procedure may be desirable for proper assurance. is there.

  The device security level indicates the physical ownership of a SIM device such as a mobile module, eg a cell phone. A device token (ie, a SIM security token with a device security level) is typically issued locally by the mobile module or SIM device upon correct authentication to it by the user. Such requirements for user authentication to the mobile module are usually set by the mobile infrastructure or mobile operator. Furthermore, device authentication is typically performed by a SIM device, but other embodiments can provide for the use of other components in the authentication process. For example, a SIM or other device may require a password before the mobile module or other device issues a device token. Of course, other forms of credentials for device level authentication are also contemplated herein.

  In one embodiment, the SIM device authenticates itself to the mobile module (provided that it is trusted to the mobile module) before the device security token is issued. Require that you identify) In addition, the lifetime of the device token is typically controlled by the mobile module or SIM device using policies set by the mobile infrastructure. In one embodiment, the lifetime or other requirements set by the mobile operator can be dynamically configured via an independent network and / or a wireless network. If the device token does not have a lifetime or other constraints, the SIM typically re-authenticates the user multiple times to the mobile module (provides trust to the mobile module) Do not request.

  The network security level indicates an authenticated connection between the mobile module or SIM and the mobile infrastructure or mobile network via an untrusted independent network. The network security level can be established without user presence or user interaction, assuming that the unlocked SIM device is accessible by the client or host computer. Typically, the network security level is single-factor authentication that asserts proof of ownership of the SIM device to the mobile infrastructure or mobile operator. Typically, the mobile infrastructure issues a network security token through a challenge response type mechanism through an authentication server before issuing a network security token to the client or host computing device. To do. This network security level token can be used in a subsequent authentication phase, encrypts further interactions between the client and the authentication server and / or mobile infrastructure, and / or Provides signing transport level security.

  FIG. 7A shows an independent network 700 configured to issue a network level security token to establish transport level secure communication between a client and an authentication server. Typically, a client or host computing device 710 (which can be a personal computer, mobile phone, or other portable or non-portable computing device) is an authentication / trusted server. ) Initiate an authentication request by sending a network security token request 725 to the mobile infrastructure 720 via 715 (but this request can also be initiated by another device, such as the SIM 705 itself) Please note.) Normally, the request 725 is not signed when received by the authentication server 715, and the authentication server 715 sends the request to the mobile infrastructure 720 for validation that the request comes from the authentication server 715. This request can be signed and / or encrypted before it is sent to. The trusted server 715 then queries the mobile infrastructure 720 or mobile operator for a challenge 730, which is then sent to the mobile module 705. The mobile module 705 uses the secret 740 shared between the mobile module 705 and the mobile infrastructure 720 to generate the challenge response 735, which is then sent to the client 710. Transferred. Note that this secret is typically SIM 705 specific and is set by the mobile operator 720.

  Client 710 uses challenge response 735 to generate a request security token response, which can also include a SIM identity and challenge 730 for authentication. Typically, the client requests that the mobile module 705 sign and / or encrypt the requested security token with another key, such as the device 705 shared secret 740 or SIM device token. However, this may or may not be necessary. The request security token response and the challenge response 735 therein can be validated using, for example, a shared secret 740. As previously mentioned, the request security token response may be signed and / or encrypted with the same key that was used to generate the challenge response 735. Please keep in mind. In any case, if the mobile infrastructure 720 validates the challenge response 735 (ie, the challenge response is valid and the mobile module has an active billing account), the mobile infrastructure The structure 720 and / or the authentication server 715 can respond by generating a message that includes the network security token 745 along with the encrypted session key, which uses the shared secret 740. Signed and / or encrypted. In addition to this message, either using the security token of the authentication server 715 itself (eg, X.509 certificate, Kerberos certificate, etc.) or using the security token of the mobile infrastructure 720 Can sign. Next, client 710 can verify the signed message and pass the encrypted network session key to SIM 705 for decryption. Using the shared secret 740, the mobile module 705 can then return the decrypted session key 750 (s) to the client 710.

  Note that in issuance over the network security token 745, the mobile module 705 typically requires a good active billing account in the mobile infrastructure 720. Thus, when challenge response 735 and such an active billing account are verified, trust can be established between SIM 705 and mobile infrastructure 720 and a virtual secure channel is created. . Session key 750 is then delegated (if necessary) from mobile module 705 to a software platform or software stack on host computing device 710 and from mobile infrastructure 720 to authentication server 715, or Passed. Physical proximity of the mobile module 705 to the host computing device 710 (which can be connected to it via a USB port, Bluetooth, or other wireless or wired connection), and mobile infrastructure Note the trusted relationship between structure 720 and authentication server 715. These session keys 750 are then used by client 710 and trusted server 715 to establish secure communication 755.

  Note that there can be a second mode of operation for authenticating the mobile module 705 that can be used by the mobile infrastructure 720. In this case, the client host 710 can request that the SIM 705 generate and sign its own challenge (usually in the form of a nonce). The client 710 can then attach this information as part of the device token when requesting the network security token 725 from the trusted server 715 or the mobile infrastructure 720. If the mobile operator 720 can verify that the device token includes a valid challenge response 735, the mobile operator 720 can directly pass the network token 745 to the client 710 for decryption of the session key described above. Can be issued.

  As described in more detail below, this network level security token 745 is typically required to allow a client to access an authenticated service token and this authenticated service Tokens can be used to request services and / or goods from third party services. Also, in order to obtain a network token, it is assumed above that the client or host computer device 710 has successfully determined the network endpoint of the authentication server 715 and / or the mobile infrastructure 720. Please note that. Furthermore, it is assumed above that the client 710 and the user (not shown) have already been authenticated against the SIM device 705. As explained above, the network security level token 745 is used in a subsequent authentication phase to encrypt and sign further interactions between the client 710 and the trusted server 715. Provides port level security. The lifetime of network token 745 (and other tokens) is controlled by authentication server 715 or mobile operator 720. Since the network token 745 serves as a session context between the SIM device 705 and the mobile infrastructure 720, the lifetime can be limited to the number of bytes passed in hours or days, and / or Alternatively, it can be effective only when the mobile module 705 is correctly connected to the client 710.

  As previously mentioned, the user security level is determined by the network (trusted server 715, by the user supplying information that is normally stored outside of the SIM 705 or host computing device 710. Indicates that the authentication has been completed for the mobile infrastructure 720 or other service. Thus, the user security level, along with the network security level, establishes multifactor authentication based on proof of ownership of SIM 705 and some external knowledge (eg, username / password). Typically, only a trusted server 715 or mobile infrastructure 720 is a component that issues user level security tokens, but in some instances, third party services may also use such user tokens. Can be issued. Thus, the mobile infrastructure 720 (or other service, as appropriate) verifies the user through a challenge response mechanism before issuing a user security level token to the client 710. Note that the user security token is used by the client to sign and / or encrypt a request for a service token, as described below. Sending a user security token to a service other than a trusted server may not be recommended (usually because other services cannot validate / use it). Similar to the network token 745 above, the user token may have a limited lifetime controlled by the mobile operator 720, including the time duration, number of bytes passed, And / or may be limited by the presence of a connection between the mobile module 705 and the client 710.

  FIG. 7B shows an independent network 700 configured to issue a user level security token to establish multilevel secure communication between a client 710 and an authentication server 715. The user network authentication phase allows the mobile operator 720 (or other server) to verify that a known person has a known device 705. In effect, the user's network phase is a two-factor authentication phase that prevents the network from distributed denial of service attacks (DDoS attacks). Furthermore, this phase protects the user by preventing the stolen SIM device 705 from being used improperly.

  The host computing device 710 can issue a user token request 765 that is sent to the mobile infrastructure 720 via the trusted server 715. Normally, the request 765 is not signed when received by the authenticated / trusted server 715, and the authentication server 715 sends the request to the mobile for validation that the request comes from the authentication server 715. This request can be signed and / or encrypted before being sent to infrastructure 720. The trusted server 715 then queries the mobile infrastructure 720 or mobile operator for a challenge 770, which is then sent to the mobile module 705. Note that challenge 770 can be generated using a different algorithm than challenge 730 used to authenticate device 705 to the network. Client 710 extracts challenge 770 from the token message and passes it to mobile module 705 to indicate that this is user authentication. Accordingly, the SIM 705 requests the user credential 775 from the client 710. The host computer 710 then queries the user 760 for user input 780 and returns the user input 780 to the mobile module 705. The SIM 705 or client 710 may optionally determine that the user input 780 or credentials must be encrypted using a previously obtained network security key (ie, session key 750). it can.

  Using user input 780, the mobile module 705 generates a challenge response 785 and returns it to the client 710, which includes a request security token response that includes, for example, a SIM identifier, challenge 770, and challenge response 785. Generate and send. Typically, the client 710 allows the mobile module 705 to sign and / or encrypt the requested security token response with a network security token 745, a shared secret key 740, or a SIM 705 unique key. Request. Similar to above, the request security token response and the challenge response 785 therein can be validated using, for example, a shared secret 740 or other mobile module 705 unique key. As previously mentioned, the request security token response may be signed and / or encrypted with the same key that was used to generate the challenge response 785. Please keep in mind. In any case, if the mobile infrastructure 720 validates the challenge response 785 (ie, the supplied user credentials are correct), the mobile infrastructure 720 and / or the authentication server 715 Can be responded by generating a message containing the user security token 795 with the encrypted user key, which is signed using the shared secret 740 or other device 705 unique key, And / or encrypted. In addition to this message, either using the security token of the authentication server 715 itself (eg, X.509 certificate, Kerberos certificate, etc.) or using the security token of the mobile infrastructure 720 Can sign. Client 710 can verify the signed message and pass the encrypted user session key to SIM 705 for decryption. Next, using the shared secret 740 (or other key if appropriate), the mobile module 705 can return the unencrypted user key 790 to the client 710, which results in: The user is authenticated to the network (792).

  The authentication phase for the user's service provides a mechanism for the mobile network operator 720 that implements authentication on behalf of the third party service. Similar to the user's network security level, the user's service phase is a multi-factor authentication phase, where there is a user 760 during at least one phase of authentication. Prevent the network from issuing service tokens without doing so. Normally, there are two modes of operation of the authentication server 715 with respect to how the service token is issued. First, if the user 760 has previously acquired a user token, the trusted server 715 thinks that the user 760 must be authenticated and automatically issues a service token (service (Assuming that the request for the token is correctly signed with the user tokens 790, 795). On the other hand, if the mobile infrastructure 720 has not issued user tokens 790, 795, the user 760 can resemble the one outlined above with respect to the user tokens 795, 790 request. You are required to authenticate.

  FIG. 7C illustrates how various network entities communicate on the independent network 700 when establishing secure communications between the client 710 and the third party server 728. As stated above, mobile device 705 and user 760 authenticate to mobile operator system 720 as described previously (provide trust to mobile operator system 720). be able to. Thus, secure communication exists between the authentication server 715 and the client 710 based on proper validation of the mobile device 705 billing account, authentication of the mobile device ownership by the user 760. Thereafter, the trusted server 715 (or mobile infrastructure 720 in this case) may be responsible for various services when the client 710 wishes to purchase services and / or goods from a third party service 728, for example. Service token 724 can be issued. Thus, the client 710 can issue a service token 726 to a third party server, which validates the token 722 via the authentication server 715. Note that the third party server 728 may or may not require additional authentication, and can use the various mechanisms previously described for performing such validation. Also, the use of service token 726 not only establishes secure communication between client 710 and third party server 728, but also in a manner similar to that described above, one or more services and Note that the user 760's ability to pay for goods may also be indicated.

  Note that typically, until a service token is issued to the client 710, the issued security token is not valuable to any other service other than the authentication server 715. The reason is that the security hierarchy can prevent all external parties from correctly decoding device tokens, network tokens, or even user tokens. This is because all of these tokens are derived from a root key or shared key 740 that only the SIM device 705 and the mobile infrastructure 720 know. Typically, any third party 728 web service can use the security token 724 after the authentication server 715 issues the service token 724. It should also be noted that the above security tokens and messages (eg, challenges, challenge responses, etc.) can have a variety of formats or schemas. For example, tokens and / or messages can be in XML, binary, or other similar encoding format, which would like to reveal certain elements of the network to the SIM communication to the intermediate party Issued by mobile operator 720, which may or may not.

  The use on portable hardware device 705 for authentication, identity, and / or payment validation can be used for online or local retail services and / or goods (eg, online newspapers, music, software applications, or other Goods and services) or access to applications running on a local PC or client 710 (eg, Word®, Adobe Photoshop, printing programs, on-demand software, etc.) Can be used. Thus, the above embodiment can be used to unlock free protected protected software or content (eg, music, video, games, etc.) on multiple hosting devices 710. Particularly advantageous. In other words, the license is now tied to the portable mobile device 705, which can be authenticated as described above and limited to the computing device Allows portable digital identities that are not tied to a set. Thus, the user 760 need not go to a friend's house and take all of his / her programs or other protected content, all of them accessed via the portable device 705 Possible and authenticated.

  As will be appreciated from the foregoing, there are various aspects to the invention described herein, including: an identity token, a payment token, a choice of multiple identity providers, multiple payment providers And the presence of commerce software on end-user systems, service provider systems, identity provider systems, and payment provider systems, and can be used independently of each other. Also, the present invention is not limited, and in some embodiments, all of the features described above can be used together, or any combination or subset of the features described above can be implemented in a particular implementation. Please understand that can be used together.

  The embodiments described above of the present invention can be implemented in any of a number of ways. For example, embodiments can be implemented using hardware, software, or a combination thereof. When implemented in software, the software code executes on any suitable processor or collection of processors, whether provided within a single computer or distributed across multiple computers. be able to. It should be understood that any component or collection of components that performs the functions described above can be considered generically as one or more controllers that control the functions described above. The one or more controllers may be general purpose hardware (eg, one or more) programmed using dedicated hardware or using microcode or software to perform the functions listed above. Can be implemented in a number of ways.

  It should be appreciated that the various methods outlined herein can be coded as software executable on one or more processors using any of a variety of operating systems or platforms. . Further, such software can be written using any of a number of suitable programming languages and / or conventional programming or scripting tools and can be compiled as executable machine language code. . In this regard, when one embodiment of the present invention is executed on one or more computers or other processors, one performs a method for implementing the various embodiments of the present invention described above. Or one or more computer-readable media encoded with multiple programs (eg, computer memory, one or more floppy disks, compact disks, optical disks, magnetic tapes, etc.) I want to be. The one or more computer readable media may be transportable and the one or more programs stored thereon may be one or more for implementing the various aspects of the invention described above. It can be loaded on a different computer or other processor.

  The term “program” as used herein refers to a set of all types of computer code or instructions that can be used to program a computer or other processor to implement the various aspects of the invention described above. It should be understood that it is used in a generic sense to refer to. Furthermore, according to one aspect of this embodiment, the one or more computer programs that, when executed, perform the method of the present invention need not reside on a single computer or processor; It should be understood that the various aspects of the present invention can be distributed in a modular fashion among multiple different computers or processors.

  The various aspects of the invention can be used alone, in combination, or in various arrangements not specifically described in the embodiments described above, and the aspects of the invention described herein. Is not limited in its application to the details and arrangement of components set forth in the foregoing description or illustrated in the drawings. Aspects of the invention are capable of other embodiments and can be practiced or carried out in various ways. Various aspects of the invention can be implemented in connection with any type of network, cluster, or configuration. There are no restrictions on the network implementation. Accordingly, the foregoing description and drawings are merely examples.

  In the appended claims, the use of the words “first”, “second”, “third”, etc., to modify a claim element, alone, to another claim element Rather than implying the priority, precedence, or order of a claim element, or the temporal order in which the actions of a method are performed, a claim element having a name is simply used to distinguish claim elements. Used as a label to distinguish from other elements with the same name (except for the use of ordering words).

  In addition, the terminology and terminology used herein are for the purpose of description and should not be construed as limiting. The use of “including”, “comprising”, or “having”, “containing”, “with” and variations thereof herein is listed below. It is intended to encompass items and their equivalents as well as additional items.

1 is a block diagram illustrating a networked computer system that performs online transactions according to one embodiment of the invention. FIG. FIG. 2 illustrates a system and method for initiating and performing identity verification in an online transaction according to one embodiment of the present invention. FIG. 2 illustrates a system and method for performing payment negotiation, verification, and / or proof on online transactions according to one embodiment of the present invention. FIG. 2 illustrates a networked computer system for conducting online transactions in which transactions are processed, at least in part, by transaction software installed on a computer connected to the network. FIG. 6 illustrates a networked computer system for conducting online transactions in which transactions are processed, at least in part, by transaction software installed on a computer connected to the network, according to another embodiment of the present invention. is there. FIG. 2 illustrates a networked computer system that provides licensing for applications installed on end user computers, where licenses are obtained via online transactions, according to one embodiment of the invention. FIG. 3 illustrates a system used to authenticate a mobile module to a network to establish secure communication with the network, according to an example embodiment. FIG. 3 illustrates a system used to authenticate a user to a network using a mobile module when establishing a secure communication channel, according to an example embodiment. FIG. 3 illustrates a system configured for single-level verification or multi-level verification of various different services using mobile modules, according to an example embodiment. FIG. 6 illustrates a 3-way secure exchange of payment information and payment federation, according to an example embodiment. FIG. 6 illustrates various uses of a commerce subsystem and billing presentation, according to an example embodiment. FIG. 4 illustrates the use of payment options and rules to determine what type of payment provider should be used for a commercial transaction, according to an example embodiment. FIG. 2 illustrates a subscriber identity module (SIM) device configured with a firewall according to an established wireless network communication protocol when used for commerce, according to an example embodiment.

Claims (190)

A method of allowing online transactions between buyers and merchants,
Providing the verification of the purchaser's identity via an identity provider and providing the verification of the purchaser's ability to pay for the transaction via a payment provider, the identity provider And the payment provider is a different network entity.   The method of claim 1, further comprising providing identification information via the purchaser to facilitate the identity provider to verify the identity of the purchaser.   The method of claim 2, wherein the act of providing identification information comprises an act of providing a subscriber identity module (SIM) number, a network address, or a unique hardware identification number (ID). .   The act of providing identification information includes programmatically providing identification information via an end user computer associated with the purchaser, the identification information being purchased by the purchaser. 3. The method of claim 2, wherein the method is provided based on an indication by at least one application running on the end user computer.   The method of claim 1, wherein the act of providing verification of the ability of the buyer to pay is performed by the payment provider only after the identity of the purchaser has been verified.   The method of claim 5, wherein the payment provider uses the identity verification to perform the payment verification.   The method of claim 1, wherein the identity provider is a bank or a government agency.   The identity provider provides identity verification via an identity token that will be received by the payment provider, and the payment provider performs payment verification via a payment token that will be received by the merchant. The method of claim 1, wherein the method is provided.   The identity token includes a predetermined interval of time during which the identity token can be processed, and the identity token is considered invalid when the predetermined interval of time expires. 9. The method according to 8.   The payment token includes a predetermined interval of time during which the payment token can be processed, and the payment token is considered invalid when the predetermined interval of time expires. the method of. A computer system having a plurality of nodes interconnected via a network and adapted to conduct online transactions between a buyer and a merchant,
A first node configured to provide verification of the purchaser's identity and a second node configured to provide verification of the purchaser's ability to pay for the transaction; The computer system wherein the second node and the second node are associated with different network entities.   And further comprising a purchaser node associated with the purchaser, wherein the purchaser node is adapted to provide identification information to facilitate the first node to verify the identity of the purchaser. The computer system of claim 11, wherein:   The computer system of claim 12, wherein the purchaser node provides a subscriber identification module (SIM) number, a network address, or a unique hardware identification number as the identification information.   The buyer node includes the end user computer that programmatically provides the identification information when a signal to initiate the transaction is issued by at least one application running on the end user computer. The computer system according to claim 12.   The computer of claim 11, wherein the second node provides verification of the ability paid by the purchaser only after the first node has verified the identity of the purchaser. system.   16. The computer system of claim 15, wherein the second node uses the identity verification to perform the payment verification.   The computer system of claim 11, wherein the first node is associated with a network entity that is a bank or a government agency.   The first node provides identity verification via an identity token that will be received by the second node, and the second node receives a payment token that is to be received by the merchant. The computer system of claim 11, wherein payment verification is provided through a computer.   The identity token includes a predetermined interval of time during which the identity token can be processed, and the identity token is considered invalid when the predetermined interval of time expires. 18. The computer system according to 18.   The payment token includes a predetermined interval of time during which the payment token can be processed, and the payment token is considered invalid when the predetermined interval of time expires. Computer system. A distributed program for performing online transactions, the program comprising a plurality of software components distributed on a computer system having a plurality of nodes interconnected via a network, each of the plurality of components Is configured to communicate with at least one other software component of the plurality of software components via the network;
A first component installed on a first node from which an end user accesses the network, wherein the network is responsive to an indication to conduct a transaction between the end user and a merchant. A first component adapted to provide an identifier associated with the end user and / or the first node via
At least one second component of the distributed program installed on at least one second node configured to receive the identifier and provide verification of the ability of the end user to pay for the transaction At least one second component, and a third component of the distributed program installed on a third node associated with the merchant, prior to proceeding with the online transaction, the end user's A distributed program comprising: a third component configured to receive the verification of the ability to pay. The at least one second component is:
An identification component of the distributed program installed on an identifier node associated with at least one identity provider, the identity component receiving the identifier and verifying the identity of the end user based on the identifier An identification component configured to provide, and a payment component of the distributed program installed on a payment node associated with at least one payment provider, wherein the payment component receives the identity token and receives an identity A payment component configured to provide a payment token based on the token, including the verification of the ability of the end user to pay. Distributed program according to claim 21. A computer having a plurality of nodes interconnected via a network and adapted to facilitate online transactions between a purchaser and a merchant providing one or more goods, services, or both A system,
A first network device associated with the purchaser that is not a purchaser established password indicating the purchaser based on an indication to initiate the transaction from the purchaser A first network device adapted to issue information programmatically, and a second network device associated with an identity provider, receiving said identification information and said buyer regarding said transaction A computer system comprising: a second network device adapted to issue an identity token that verifies the identity of the computer. A method of allowing online transactions between buyers and merchants,
Generating an identity token that provides verification of the purchaser's identity based on identifying information other than the password established by the purchaser, and a payment token that provides verification of the buyer's ability to pay for the transaction Generating the method. A computing device in a distributed network environment that allows users to access services, goods, or both by validating the mobile module over a wireless network independent of the mobile infrastructure. A method of authenticating a mobile module of a portable device as being associated with the mobile infrastructure billing account to enable:
Receiving a request to authenticate the mobile module when attempting to gain access to services, goods, or both;
Receiving one or more credentials from the mobile module for use by a mobile infrastructure in validating billing account information of the mobile module;
Sending the one or more credentials to the mobile infrastructure via an independent network separate from the mobile infrastructure wireless network; and the mobile module on the mobile infrastructure; Receive authentication information corresponding to the activation status of the billing account via the independent network, thereby allowing a portable digital identity to control access to the service, goods, or both A method characterized by comprising:   The mobile module is a subscriber identification module (SIM) of the mobile infrastructure, and the one or more credentials are information based on challenges from the mobile infrastructure as well as the SIM and the mobile 26. The method of claim 25, including a key shared with the infrastructure.   The SIM is included in a part of hardware other than a wireless transmission device, and is connected to the computing device via one or more wired connection ports or wireless ports. The method described.   27. The method of claim 26, wherein the SIM is connected directly to the computing device via a special hardware connection specifically designed for the SIM.   26. The method of claim 25, wherein the service, goods, or both are required for a remote service connected to the independent network.   30. The method of claim 29, wherein the independent network includes the Internet.   The service, goods, or both are distributed free on the Internet and reside on a local computing device, and the authentication of the mobile module is such that the content of the service, goods, or both is local The method of claim 30, wherein the method is allowed to be unlocked on a computing device. The service, goods, or both
A software program on the computing device;
A piece of hardware connected to the computing device;
The method of claim 25, wherein the method is one or more of multimedia content consumed by the computing device, or access to the computing device itself.   The service, goods, or both have multiple levels of available access, and one or more of the available levels are activated based on authentication of the mobile device 35. The method of claim 32. Based on the activation status of the mobile module, a contract agreement between the merchant and the mobile infrastructure for the service, goods, or both is one to authenticate the user. Or further determining whether the user needs to enter credentials entered by a plurality of users, and if further required,
Sending to the user a request to enter the one or more user-entered credentials, and whether the user is allowed to access protected services based on the user input 26. The method of claim 25, comprising determining.   The method of claim 34, wherein the user-entered credentials are stored in one or more of the mobile module, the mobile infrastructure, or a server corresponding to the merchant. Method. If the mobile module is not authenticated by the mobile infrastructure,
The method of claim 25, further comprising: receiving a deactivation message to deactivate the mobile module via the independent network. A mobile infrastructure in a distributed network environment allows a user to service, collect goods, or both by validating the mobile module of the portable device over a network independent of the mobile infrastructure's wireless network A method for authenticating the mobile module as being associated with a billing account of the mobile infrastructure to allow access to
A mobile infrastructure wireless network refers to a request to authenticate a mobile module corresponding to a mobile infrastructure billing account when a user attempts to gain access to services, goods, or both. Receiving via a separate independent network,
Receiving one or more credentials from the mobile module via the independent network, and based on the validation of the one or more credentials, a billing account of the mobile module Authentication information corresponding to the activation status of the user is transmitted via the independent network, so that the portable digital identity controls access to the service, goods, or both via two independent networks A method comprising: enabling to do. The mobile module is a subscriber identification module (SIM) of the mobile infrastructure, the method further comprising:
Sending a challenge to the SIM device via the independent network;
Receiving a response including the information in the challenge and the one or more credentials corresponding to a key shared between the SIM and the mobile infrastructure, and based on the response to the challenge 38. The method of claim 37, further comprising: authenticating the activation status of the SIM according to information related to the billing account.   The request, the one or more credentials and an authentication method are routed to the mobile infrastructure via a trusted server, and the authentication is a trust between the SIM and the trusted server. 40. The method of claim 38, wherein the established communication is established.   The method of claim 38, wherein the SIM is part of a device that is unable to communicate over the mobile infrastructure wireless network.   38. The method of claim 37, wherein the service, goods, or both are required by a remote service connected to the independent network.   The method of claim 37, wherein the independent network includes the Internet.   The service, goods, or both are distributed free on the Internet and reside on a local computing device, and the authentication of the mobile module is such that the content of the service, goods, or both is local 43. The method of claim 42, wherein the method allows to be unlocked on a computing device. The service, goods, or both
Software programs on computing devices,
A piece of hardware connected to the computing device;
The method of claim 37, wherein the method is one or more of multimedia content consumed by the computing device, or access to the computing system itself. Based on the activation status of the mobile module, a contract agreement between the merchant and the mobile infrastructure for the service, goods, or both is one for the user to authenticate the user. Or determining whether it is necessary to enter credentials entered by a plurality of users, and if further required,
Sending a request to the mobile module to prompt the user to enter the one or more user-entered credentials, and based on the user input, providing access to a protected service The method of claim 37, comprising: determining whether the user is authorized.   The method of claim 34, wherein the user-entered credentials are stored in one or more of the mobile module, the mobile infrastructure, or a server corresponding to the merchant. Method. If the mobile module is not authenticated by the mobile infrastructure,
38. The method of claim 37, further comprising: sending a deactivation message over the mobile infrastructure wireless network, the independent network, or both to deactivate the mobile module. the method of. Local computing used to authenticate the mobile module as having a valid billing account in the mobile infrastructure to allow the user to access services, goods, or both A portable device used to interface the mobile module to a machine, the portable device comprising:
Have a billing account in the mobile infrastructure that is used to validate the mobile module when trying to gain access to services, goods, or both on a local computing machine A case holder for securing the holding of the mobile module, and an interface, the portable device comprising:
Sending one or more credentials from the mobile module to the local computing device to authenticate the mobile module to the mobile infrastructure;
An interface that enables to receive authentication information from the local computing device to validate the status relating to the billing account, the interface being independent of the mobile infrastructure wireless network. Enabling the transmission and reception of information over a network, thereby allowing a portable digital identity to control access to the service, goods, or both over two independent networks. Features portable device.   The mobile module is a subscriber identification module (SIM) of the mobile infrastructure, and the one or more credentials are information based on challenges from the mobile infrastructure as well as the SIM and the mobile 49. The portable device of claim 48, comprising a key shared with the infrastructure.   The case holder is part of hardware other than a wireless transmission device, and the interface allows the portable device to connect to the local computing device via one or more wired connection ports or wireless ports. 50. The portable device of claim 49, wherein the portable device is capable of being connected.   50. The portable device of claim 49, wherein the independent network includes the Internet.   The service, goods, or both are distributed free on the Internet and reside on the local computing device, and the authentication of the mobile module is such that the content of the services, goods, or both is 50. The portable device of claim 49, allowing the device to be unlocked on a local computing device. The service, goods, or both
A software program on the local computing device;
A piece of hardware connected to the local computing device;
The portable content of claim 49, wherein the portable content is one or more of: multimedia content consumed by the local computing device, or access to the local computing device itself. device.   The service, goods, or both have multiple levels of available access, and based on the authentication of the mobile device, one or more of the available levels are activated 54. The portable device of claim 53.   50. The portable device of claim 49, wherein the interface is further used to receive a user credential that validates the user.   56. The portable of claim 55, wherein user entered credentials are stored on one or more of the mobile module, the mobile infrastructure, or a server corresponding to the merchant. ·device. Configure a computing device in a distributed network environment to authenticate a portable device as tied to the mobile infrastructure billing account via a network independent of the mobile infrastructure wireless network A method of enabling access to free-distributed services, goods, or both on a connected computing device, comprising:
At a local computing device, receive one or more free distributed services, goods, or both that contain protected content that only authorized computing devices are allowed to access thing,
Receiving from the mobile module one or more credentials used by the mobile infrastructure in validating the mobile module billing account information;
Sending the one or more credentials to the mobile infrastructure via an independent network separate from the mobile infrastructure wireless network;
Receiving authentication information corresponding to an activation status of a billing account of the mobile module on the mobile infrastructure via the independent network, and based on the authentication information, the local computing device Receive a license that allows access to at least a portion of the protected content, thereby limiting the number of computing devices licensed to access the protected content Enabling a portable digital identity to access the service, goods, or both on a plurality of different computing devices.   58. The freely distributed service, goods, or both are received via the independent network or purchased at a store and installed directly on the local computing device. The method described in 1.   58. The method of claim 57, wherein the license is limited in lifetime, whether the mobile module is connected to a local computing machine, or both.   The mobile module is a subscriber identification module (SIM) of the mobile infrastructure, and the one or more credentials are information based on challenges from the mobile infrastructure as well as the SIM and the mobile 58. The method of claim 57, comprising a key shared with the infrastructure.   The SIM is included in a part of hardware other than a wireless transmission device and is connected to the computing device via one or more wired connection ports or wireless ports. The method described.   58. The method of claim 57, wherein the SIM is connected directly to the local computing device via a special hardware connection specifically designed for the SIM.   The method of claim 57, wherein the service, goods, or both are required by a remote service connected to the independent network.   58. The method of claim 57, wherein the independent network includes the Internet. The service, goods, or both
A software program on the local computing device;
58. A piece of hardware connected to the local computing device or one or more of multimedia content consumed by the local computing device. The method described in 1.   The service, goods, or both have multiple levels of available access, and based on the license, one or more of the available levels are activated 58. The method of claim 57. In computing systems tied to distributed networks, a single to enable access to protected services, goods, or both that require either single-factor authentication or multi-factor authentication A method of using a portable hardware device, comprising:
If the mobile module has an active billing account in a mobile infrastructure that is also configured to authenticate users in a multi-factor process, the local computing device can be a protected service, goods, or both One or more credentials from the mobile module to the local computing device that requires access to the protected service, goods, or both to allow access Transmitting over an independent network separate from the mobile infrastructure wireless network;
Receiving authentication information corresponding to the activation status of the billing account of the mobile module from the local computing device, and based on the authentication information, the protected service, goods, or both Determining whether further user authentication is required, in which case the method further comprises:
Sending a request for one or more user-entered credentials for comparison with its securely stored version, and based on the information regarding the comparison, to enable the user Determining whether to be allowed to access the protected service, goods, or both. The one or more user-entered credentials are encrypted using a key shared between the mobile module and the mobile infrastructure, the method further comprising:
Send the encrypted one or more user-entered credentials to the local computing device for transfer to the mobile infrastructure via the independent network for comparison To do,
Allows the mobile infrastructure to receive information about the comparison indicating that the user is properly authenticated, and allows the user to access protected services, goods, or both 68. The method of claim 67, comprising: sending a license to make to the local computing device. The license is limited based on lifetime, proximity of the mobile module to the local computing device, or both, and when the license expires, the user and the mobile module are: 69. The method of claim 68, wherein re-authentication is required for the mobile infrastructure to gain further access to the protected service, goods, or both.   The one or more user-entered credentials are specific to the merchandise, the service, or both, and the merchant has the one or more user-entered credentials for authentication purposes. 69. The method of claim 68, wherein the method has a trusted contractual relationship with the mobile infrastructure that indicates that it is required.   The method of claim 68, wherein the protected service, goods, or both correspond to an application running on the local computing device connected to the mobile module.   The protected service, goods, or both correspond to an application running on the local computing device connected to the mobile module and the one or more user-entered credentials 68. The method of claim 67, wherein the method is stored at the local computing device.   The protected service, goods, or both are controlled remotely by a service in a distributed system, and the one or more user entered credentials are stored at a remote server. 68. The method of claim 67.   The mobile module is a subscriber identity module (SIM) and the one or more credentials are shared between the mobile infrastructure challenge and the SIM device and the mobile infrastructure 68. The method of claim 67, wherein the method is determined based on a key to be played.   75. The SIM is included in a portion of hardware other than a wireless transmission device and is connected to the computing device via one or more preferred connection ports or wireless ports. The method described.   The method of claim 74, wherein the SIM is connected directly to the local computing device through a special hardware connection specifically designed for the SIM. The service, goods, or both
A software program on the local computing device;
68. One or more of hardware connected to the local computing device or multimedia content consumed by the local computing device. Method. A single portable to enable access to protected services, goods, or both that require either single-factor authentication or multi-factor authentication in a mobile infrastructure tied to a distributed network A method of using a hardware device,
From a mobile module indicating a request for access to the protected service, goods, or both to allow a local computing device to access the protected services, goods, or both Receiving one or more credentials via an independent network separate from the mobile infrastructure wireless network;
Using the one or more credentials to authenticate the mobile module as having an active billing account in the mobile infrastructure that is also configured to authenticate a user in a multi-factor process And determining whether the protected service, goods, or both further require user authentication, and if so, the method further comprises:
Sending a request for one or more user-entered credentials over the independent network for comparison with its securely stored version;
Receiving via the independent network the one or more user-entered credentials that are encrypted using a key shared between the mobile module and the mobile infrastructure; And indicating the user's authentication to the mobile infrastructure based on the comparison of the encrypted one or more user-entered credentials with the securely stored version thereof, and Transmitting information enabling a local computing device to issue a license that provides access to the protected service, goods, or both. The license is limited based on lifetime, proximity of the mobile module to the local computing device, or both; and
When the license expires, the user and the mobile module may re-authenticate to the mobile infrastructure to gain further access to the protected service, goods, or both. 79. The method of claim 78, wherein the method is required.   The one or more user-entered credentials are specific to the merchandise, the service, or both, and the merchant has the one or more user-entered credentials for authentication purposes. 79. The method of claim 78, wherein the method has a trusted contractual relationship with the mobile infrastructure that indicates that it is required.   The method of claim 78, wherein the protected service, goods, or both correspond to an application running on the local computing device connected to the mobile module.   The mobile module is a subscriber identity module (SIM) and the one or more credentials are shared between the mobile infrastructure challenge and the SIM device and the mobile infrastructure 79. The method of claim 78, wherein the method is determined based on a key to be played.   The shared key that encrypts the one or more user-entered credentials is the shared key used for the one or more credentials from the mobile module. The method of claim 82, wherein the methods are different. In a distributed system, a mobile module is connected to the host computer to label the host computer as a peripheral device rather than a mobile terminal subject to the strict requirements of the mobile operator system. A computing framework sometimes used to abstract the host computer from the mobile operator system,
A subscriber identity module (SIM) containing information associated with the mobile operator system billing account;
A host computer connecting the SIM to the mobile operator system via a network independent of the mobile operator system's wireless network to authenticate the billing account information for the SIM;
A SIM driver belonging to the host computer that reads information from the SIM used to authenticate the SIM to the mobile operator system at least via the independent network; and the SIM and the SIM An interface that acts as a firewall to and from the driver, by constraining one or more of the number, sequence, or length of commands sent between the SIM driver and the SIM A computing framework comprising an interface defining a protocol used to protect the SIM from attack.   85. The computing framework of claim 84, wherein the SIM is connected to the host computer via a hardware port, a wireless port, or both.   85. The computing framework of claim 84, wherein the interface is part of a portable device used in connecting the SIM to the host computer.   87. The computing framework of claim 86, wherein the portable device is not configured for wireless communication over the network of mobile operator systems.   87. The computing framework of claim 84, wherein the authentication of the SIM over the independent network is used to gain access to a host computing device.   85. The computing framework of claim 84, wherein the authentication of the SIM is used to gain access to services, goods, or both provided via the independent network.   The authentication of the SIM device is for services, goods, or both provided via the independent network, and software that runs on the host computer separate from the web browsing application The computing framework of claim 84, wherein the computing framework is associated with an application.   The protocol includes a formal state machine used to store one or more of the number, sequence, or length of communications between the SIM driver and the SIM. 85. The computing framework of claim 84. In a computing system tied to a distributed network, connected to the client to delegate a session key to at least a software stack on the client for one or more of encryption or signing purposes Transport level secure communication between the client and server over an otherwise insecure network by establishing secure tunneling between the mobile module and its associated mobile infrastructure A method of establishing
Identifying one or more credentials for the mobile module connected to the host computer;
Passing the one or more credentials to a mobile infrastructure for authentication of a valid billing account for the mobile module, via a separate network separate from a wireless network corresponding to the mobile infrastructure Based on the authentication, receiving from the mobile module a session key used in transport level secure communication between the host computer and the server via the independent network. A method characterized by comprising.   The mobile module is a subscriber identification module (SIM) of the mobile infrastructure, and the one or more credentials are information based on challenges from the mobile infrastructure as well as the SIM and the mobile 94. The method of claim 92, comprising a key shared with the infrastructure.   94. The SIM of claim 93, wherein the SIM is included in hardware other than a wireless transmission device and is connected to the computing device via one or more wired connection ports or wireless ports. Method.   94. The method of claim 93, wherein the independent network includes the Internet.   The server has a trusted relationship with the mobile infrastructure such that the session key is also passed from the mobile infrastructure to the server for transport level secure communication with the host computer. 94. The method of claim 93, wherein the method is part of a framework having: Requesting a connection to a third-party server that is not part of the framework;
Receiving another session key for secure communication between the host computer and the third party server, and transport level secure communication with the third party server. 97. The method of claim 96, further comprising using one session key. Before using the other session key for communication with the third party server,
Sending the other session key and token to the third party server so that the third party server authenticates the token through a trusted server that is part of the framework; Validating the another session key by and using the other session key for secure communication with the third-party server based on the authentication of the token. 98. The method of claim 97.   The third party server is a merchant of services, goods, or both, and the user must also authenticate to the third party server by providing user entered credentials 99. The method of claim 98, wherein:   Authentication of the SIM against the mobile infrastructure by validating the billing account of the SIM is used as a verification of payment funds for the service, goods, or both when making a purchase from the merchant. 100. The method of claim 99, wherein:   The session key is based on one or more of the number of messages based on the lifetime of the session key, or encrypted, signed, or both using the session key, Upon expiration, upon expiration, the SIM is required to be re-authorized using the mobile infrastructure for further secure communication between the host computer and the server. 94. The method according to Item 93.   94. The method of claim 93, wherein the SIM is externally connected to the host computer and is maintained in close physical proximity to the host computer.   105. The method of claim 102, wherein the physically close proximity is within 10.144 meters (10 yards).   104. The method of claim 103, wherein the external connection is a wireless connection.   94. The method of claim 93, wherein the session key is derived from the SIM and the mobile infrastructure based on a secret shared between the SIM and the mobile infrastructure. The session key is received from the mobile infrastructure encrypted with a key shared between the SIM and the mobile infrastructure, the method before receiving the session key from the SIM ,
In order to provide the session key to the host computer without compromising the shared key, the encrypted key is sent to the SIM for its decryption using the shared key 94. The method of claim 93, further comprising: Trust session keys for one or more of encryption or signing purposes within a mobile infrastructure tied to a distributed network via an insecure network independent of the mobile infrastructure's wireless network By establishing secure tunneling between the mobile infrastructure connected to the client and the mobile infrastructure for delegation to the server to be transferred, via the non-secure network between the client and the server. A method for establishing port level secure communication comprising:
Receiving one or more credentials of a mobile module connected to a host computer via an independent network separate from a wireless network corresponding to the mobile infrastructure;
Authenticating the one or more credentials as being part of a valid billing account for the mobile module, and based on the authentication, between the host computer and a server Transmitting to the server a session key used in transport level secure communication over an independent network.   The mobile module is a subscriber identification module (SIM) of the mobile infrastructure, and the one or more credentials are information based on challenges from the mobile infrastructure as well as the SIM and the mobile 108. The method of claim 107, comprising a key shared with the infrastructure.   109. The method of claim 108, wherein the independent network includes the Internet.   The server has a trusted relationship with the mobile infrastructure such that the session key is also passed from the mobile infrastructure to the server for transport level secure communication with the host computer. 109. The method of claim 108, wherein the method is part of a framework comprising:   Authentication of the SIM against the mobile infrastructure by validating the billing account of the SIM is used as a verification of available payment funds for services, goods, or both when making purchases from merchants 109. The method of claim 108, wherein:   The session key is based on one or more of the number of messages based on the lifetime of the session key, or encrypted, signed, or both using the session key, 109. The method of claim 108, wherein upon expiration and upon expiration, the SIM re-authorizes with the mobile infrastructure for further secure communication between the host computer and the server. .   109. The method of claim 108, wherein the session key is derived from the SIM and the mobile infrastructure based on a secret shared between the SIM and the mobile infrastructure. By using a protocol at the host computer in a distributed computing system to authenticate the subscriber identity module (SIM) to the mobile infrastructure via a network connection independent of the associated wireless network , A method for establishing secure communication between the host computer and a server, comprising:
A mobile infrastructure that holds a calculated challenge response from a subscriber identity module (SIM) connected to a host computer that attempts to establish secure communication with a server, and that holds billing status information for the SIM Creating a request for a session key including a challenge response used to authenticate the SIM to a structure;
Transmitting the request for a session key to the server having a trusted relationship with the mobile infrastructure over a network independent of a wireless network associated with the mobile infrastructure;
A response to the request for a session key, wherein the SIM includes the session key and is signed and / or encrypted by a mobile infrastructure using a shared key; Receiving a response indicating proper authentication to the mobile infrastructure using a challenge response;
Establishing tunneled communication between the SIM and the mobile infrastructure, sending the session key to the SIM for validation using the shared key; and Allowing the host computer to use a decrypted session key for secure communication with the server based on validation.   115. The method of claim 114, wherein the response to the request for the session key is signed by the server, the mobile infrastructure, or both.   115. The challenge response of claim 114, wherein the challenge response includes a nonce signed by the SIM using the shared key such that the challenge response is self-generated by the SIM. Method.   115. The method of claim 114, wherein the shared key is SIM specific.   115. The method of claim 114, wherein the request for the session key is signed and / or encrypted using a token specified by the server.   115. The method of claim 114, wherein the request for the session key is signed and / or encrypted using a token unique to the host computer.   115. The method of claim 114, wherein before sending the challenge response, a challenge is received and used by the SIM to generate the challenge response. To authenticate a user to the mobile infrastructure via the independent network when the SIM is authenticated to the mobile infrastructure;
Creating a request for a user token to be used in authenticating a user to one or more of the mobile infrastructure, the server, or other third party services;
Sending the request for the user token to the server via the network independent of the wireless network associated with the mobile infrastructure;
Receiving a response to the request for a user token, including a generated challenge from the mobile infrastructure;
Sending the challenge to the SIM indicating that it supports user authentication to prompt the SIM to request one or more user credentials;
Receiving user input specifying the one or more user credentials that will subsequently be forwarded to the SIM to determine an appropriate challenge response;
Sending the challenge response including the one or more user credentials to the server;
Receiving a user token indicating that the user has been properly authenticated, signed and / or encrypted using the shared key by the mobile infrastructure;
Sending the user token to the SIM for validation using the shared key, and based on the validation of the session key, the host computer makes the server or third party 115. enabling the user token to be used for subsequent communication to the server or the third party service for secure communication with a party service. the method of.   The user token is used to request a service session key that is sent to a third party service, and the third party service validates the service session key via the server. 122. The method of claim 121, wherein:   122. The service session key is provided by the server in a token separate from the user token upon request from the host computer and upon authentication of the user to the server. The method described in 1. A mobile operator system in a distributed computing environment with a subscriber identity module (SIM) for the mobile operator system via a network connection independent of a wireless network associated with the mobile operator system A method for establishing secure communication between a host computer and a server by using an authenticating protocol comprising:
Calculated challenge response from a subscriber identity module (SIM) connected to a host computer attempting to establish secure communication with a server having a trusted relationship with the mobile infrastructure corresponding to the SIM Receiving a request for a session key comprising a network independent of a wireless network associated with the mobile infrastructure;
Using the challenge-response to authenticate the SIM with a valid billing account in the mobile infrastructure;
By signing, encrypting, or both using a shared key indicating that the SIM has been properly authenticated to the mobile infrastructure using the challenge response; Protecting the session key;
In order to allow the connected SIM to validate the session key using the shared key that establishes the tunneled communication between the SIM and the mobile infrastructure, Sending a response to the request including the session key to the host computer and the session key to the server to establish network level secure communication between the server and the host computer. A method comprising: transmitting a message.   The method of claim 124, wherein the response to the request for the session key is signed by the server, the mobile infrastructure, or both.   127. The challenge response of claim 124, wherein the challenge response includes a nonce signed by the SIM using the shared key such that the challenge response is self-generated by the SIM. Method.   The method of claim 124, wherein the shared key is SIM specific.   129. The method of claim 124, wherein the request for the session key is signed and / or encrypted using a token specified by the server.   The method of claim 124, wherein the request for the session key is signed and / or encrypted using a token unique to the host computer.   125. The method of claim 124, wherein before sending the challenge response, a challenge is received and used by the SIM to generate the challenge response. To authenticate a user to the mobile infrastructure via the independent network when the SIM is authenticated to the mobile infrastructure;
Receiving a request for a user token to be used in authenticating a user to the mobile infrastructure via the network independent of the wireless network;
Sending a challenge generated from the mobile infrastructure requesting the SIM to obtain one or more user credentials;
Receiving a challenge response including the one or more user credentials;
Based on the validation of the one or more user credentials, signing with the shared key indicating that the user has been properly authenticated to the mobile infrastructure, and encrypting And / or both to protect the user token, and the host computer to the server or the third party service for secure communication with the server or the third party service. Sending the user token to the SIM for validation using the shared key to allow the user token to be used for subsequent communications. The method of claim 124. For online purchases of services, goods, or both, by establishing a three-way exchange of data between consumer, merchant, and payment provider computing devices at a consumer computing device in a distributed system A method for providing secure commerce for
Submit an online request to purchase one or more services, goods, or both provided by the merchant;
Receiving billing information from the merchant that includes costs associated with the purchase of the one or more services, goods, or both;
Sending a payment authorization request for the cost from a consumer computing device to at least one payment provider on which the consumer has a billing account;
A payment token as proof of the consumer's ability to pay for at least a portion of the one or more services, goods, or both, without providing sensitive information regarding the consumer's billing account Receiving from the at least one payment provider a payment token that uniquely identifies a payment authorization for the at least part of the cost;
Sending the payment talk from the consumer computing device to the merchant, wherein the merchant uses the payment token to validate a payment with the payment provider and the payment provider Validating the payment token that makes the sensitive information about the billing account opaque to the merchant and indicates an appropriate transfer of the one or more services, goods, or both from the merchant to the consumer Receiving a sexual acknowledgment.   The claim information further includes one or more of a description of the service, goods, or both, available payment options from the merchant, or merchant specific information. 132. The method according to 132.   134. The method of claim 133, wherein the billing information is presented to the at least one payment provider when requesting payment authorization for the service, goods, or both.   The payment token includes the billing information, the billing information validating the payment token and matching the token with the request for payment authorization from the consumer. 135. The method of claim 134, wherein the method is signed and / or encrypted by a payment provider.   That the request for payment authorization, the presentation of the billing information to the at least one payment provider, and the transmission of the payment token to the merchant occur automatically without interaction from the consumer. 140. The method of claim 135, wherein Based on the available payment options provided by the merchant,
Presenting the consumer with a user interface indicating one or more of the available payment options;
Receiving user input from the consumer to select the at least one payment provider, and requesting the payment authorization based on the user input, the consumer computing device and the at least one payment provider; 134. The method of claim 133, comprising establishing communication between the two.   135. The method of claim 132, wherein the at least one payment provider is selected based on a default payment provider that is preset by the consumer.   The at least one payment provider is a mobile infrastructure having billing account information for a SIM device owned by the consumer, the consumer's credit card company, the consumer's prepayment service, or the consumer 135. The method of claim 132, wherein the method is one of:   The commerce is a seamless in-band experience in that the payment and selection of the service, goods, or both are integrated into a single application that is not part of a web browser. 135. The method of claim 132.   135. The method of claim 132, wherein the payment token expires after a predetermined period of time, frequency of use, or both, set by the at least one payment provider.   135. The method of claim 132, wherein the cost is variable and is presented as a range of values within the billing information.   The method of claim 132, wherein the payment token is revocable by the consumer, the at least one payment provider, or both.   135. If the cost exceeds a predetermined amount allowed by the at least one payment provider, additional user interaction is required for authorization of the payment token. the method of.   The payment token is signed and / or encrypted by the at least one payment provider, and the validation of the payment token against the at least one payment provider includes the signature, the encryption, or 135. The method of claim 132, comprising validating both.   135. The 132, wherein the one or more services, goods, or both require a subscription or multiple payments, and the payment token can be used multiple times for such payments. The method described.   The one or more services, goods, or both require a subscription or multiple payments, and the payment token is valid only for a single payment of the subscription payment or multiple payments 135. The method of claim 132, wherein an additional token is required for subsequent payments. A merchant computing device in a distributed system enables the purchase of services, goods, or both by establishing a three-way exchange of data between consumer, merchant, and payment provider computing devices A method of executing secure commerce when
Receiving an online request to purchase one or more services, goods, or both provided by the merchant;
Sending billing information to the consumer including costs associated with the purchase of the one or more services, goods, or both;
Providing sensitive information about a billing account for the consumer's payment provider from the consumer as providing proof of the consumer's ability to pay for at least a portion of the one or more services, goods, or both; Without receiving a payment token that uniquely identifies authorization of payment by the payment provider for the at least a portion of the cost;
Sending a request for validation of the payment token to the payment provider, thereby enabling the merchant to securely validate a payment of at least a portion of the cost, while simultaneously requesting the payment Making the sensitive information about the account opaque to the merchant, and appropriate transfer of the one or more services, goods, or both from the merchant to the consumer based on validation of the payment token Sending an acknowledgment of the validity of the payment token indicating.   The claim information further includes one or more of a description of the service, goods, or both, available payment options from the merchant, or merchant specific information. 148. The method according to 148.   The payment token includes the payment request information, wherein the payment request information validates the payment token and matches the token with a request for payment authorization from the consumer. 150. The method of claim 149, wherein the method is signed and / or encrypted by a provider.   149. The method of claim 148, wherein the payment token expires after a predetermined period of time, frequency of use, or both, set by the payment provider.   150. The method of claim 148, wherein at least a portion of the cost is variable and is presented as a range of values within the billing information.   149. The method of claim 148, wherein the payment token is reversible by the consumer, the payment provider, or both.   149. The method of claim 148, wherein additional user interaction is required for authorization of the payment token if the cost exceeds a predetermined amount allowed by the payment provider.   148. The one or more services, goods, or both require a subscription payment or multiple payments, and the payment token can be used multiple times for such payments. The method described in 1. Purchase of services, goods, or both by establishing a three-way exchange of data between the consumer, merchant, and payment provider computing devices at the payment provider computing device in the distributed system A method of authorizing payment in a commercial transaction relating to
Receiving a request for payment authorization from a consumer purchasing one or more services, goods, or both from a merchant, including billing information for costs associated with the purchase;
Sensitive to the consumer's billing account to the consumer as proof of the consumer's ability to pay for the one or more services, goods, or both based on the consumer billing account information Sending a payment token that uniquely identifies a payment authorization for the one or more services, goods, or both without providing information;
Receiving the request from the merchant to validate the payment token and comparing the payment token with the billing information from the request for payment authorization, the one or more services, goods, Or sending an acknowledgment of the validity of the payment token indicating that payment will be provided to the merchant upon appropriate transfer to the consumer, or both. Method.   The claim information further includes one or more of a description of the service, goods, or both, available payment options from the merchant, or merchant specific information. 156. The method according to 156.   The at least one payment provider is a mobile infrastructure having billing account information for a SIM device owned by the consumer, the consumer's credit card company, the consumer's prepayment service, or the consumer 156. The method of claim 156, wherein the method is one of the following banking accounts.   157. The method of claim 156, wherein the payment token expires after a predetermined period of time, frequency of use, or both, set by the payment provider.   157. The method of claim 156, wherein the cost is variable and is presented as a range of values within the billing information.   157. The method of claim 156, wherein the payment token is reversible by the consumer, the payment provider, or both.   157. The method of claim 156, wherein if the cost exceeds a predetermined amount allowed by the payment provider, additional user interaction is required for authorization of the payment token.   The payment token is signed and / or encrypted by the payment provider and validation of the payment token against the payment provider validates the signature, encryption, or both 156. The method of claim 156, comprising:   156. The one or more services, goods, or both require a subscription payment or multiple payments, and the payment token can be used multiple times for such payments. The method described in 1.   The one or more services, goods, or both require a subscription payment or multiple payments, and the payment token is only for a single payment of the subscription payment or multiple payments. 157. The method of claim 156, wherein the method is valid and an additional token is required for subsequent payments. In a distributed computing system for performing online commerce, a method for authorizing payment based on an electronic invoice presentation that maintains a record of said online transaction for auditing, fraud protection, and other purposes, comprising:
A consumer computing device that includes an electronic invoice containing a description and costs of purchasing the one or more services, goods, or both from a merchant during online commerce of one or more services, goods, or both And receiving a copy of the electronic invoice to a payment provider to authorize payment for the one or more services, goods, or both.   One or more portions of the electronic bill are encrypted by the merchant to make the one or more portions opaque to the consumer, payment provider, or both 166. The method of claim 166.   166. The method of claim 167, wherein the one or more portions of the electronic bill that are encrypted are used for automatic payment federation to the merchant's one or more merchants. Storing a copy of the electronic bill at the consumer computing device;
Receiving a payment request from the payment provider, including a copy of the electronic invoice from the merchant, for a billing amount corresponding to a payment to the merchant, and auditing appropriate payments made to the merchant 166. The method of claim 166, further comprising: comparing the stored copy of the electronic bill with the copy received from the payment provider. A copy of the electronic invoice is signed by the merchant;
Receiving a payment token from the payment provider, including the signed copy of the electronic invoice, authorizing the payment of the one or more services, goods, or both; and for authorizing payment Sending the payment token to the merchant, wherein the merchant validates the payment token as coming from the consumer based on the signed copy of the electronic bill. it can In a distributed computing system that conducts online commerce, relating to services, goods, or both from merchants based on electronic invoice presentations that maintain online transaction records for auditing, fraud protection, and other purposes A method of authorizing payment,
Receiving at the payment provider an electronic invoice containing instructions and costs for one or more services, goods, or both by a consumer computing device during online commerce, and said from the merchant Transmitting to the consumer a payment token that includes a copy of at least a portion of the electronic invoice for authorizing payment of one or more services, goods, or both.   One or more portions of the electronic bill are encrypted by the merchant to make the one or more portions opaque to the consumer, payment provider, or both 171. The method of claim 171.   173. The method of claim 172, wherein the one or more portions of the electronic bill that are encrypted are used for automated payment federation to the merchant one or more merchants. Storing a copy of the electronic invoice at the payment provider computing device;
Receiving a payment request from the merchant, including a copy of at least a portion of the electronic invoice from the merchant for payment of a billing amount corresponding to the one or more services, goods, or both; and Comparing the stored copy of the electronic bill with the copy of at least a portion of the received electronic bill from the merchant to authorize appropriate payment to the merchant. 181. The method of claim 171 characterized by. The copy of the electronic invoice is signed by the merchant, and the method further includes a payment token that includes the signed copy of the electronic invoice, for a transaction that occurs between the merchant and the consumer. Sending a payment token to the consumer that can be used by the merchant to validate that it is part of the
Receiving a request from the merchant to authorize the payment token for the one or more services, goods, or both; and the merchant provides the one or more services, goods, or both to the consumer 171. The method of claim 171 comprising: sending a validation acknowledgment of the payment token to the merchant to allow for transfer to the merchant. A method of validating payment authorizations based on electronic invoice presentations that maintain online transaction records for auditing, fraud protection, and other purposes within a distributed computing system that conducts online commerce. And
A consumer computing device that includes an electronic invoice containing a description and costs of purchasing the one or more services, goods, or both from a merchant during online commerce of one or more services, goods, or both And receiving the payment token including at least a portion of the electronic invoice to validate that the payment token is part of a business transaction that originates between the merchant and the consumer A method characterized by comprising:   One or more portions of the electronic invoice are encrypted by the merchant to make the one or more portions opaque to the consumer, the payment provider, or both 177. The method of claim 176.   180. The method of claim 177, wherein the one or more portions of the electronic bill that are encrypted are used for automatic payment federation to the merchant's one or more merchants. Sending the payment token to the payment provider, including the signed copy of the electronic invoice that authorizes the payment of the one or more services, goods, or both;
Receiving from the service provider a validation of the payment token indicating the consumer's ability to pay for the one or more services, goods, or both; and completing the transaction based on the authorization 178. The method of claim 176, further comprising: sending the one or more services, goods, or both to the consumer for purposes. In a distributed system, a method of automatic payment distribution to a set of business associates associated with a predefined business relationship based on a single payment from a consumer for online commerce,
A single online payment for said service, goods, or both provided by a merchant having a contract business relationship with at least one other business associate who assists in providing at least a portion of the service, goods, or both ( single online payment),
Identifying a portion of the single online payment as belonging to the at least one merchant based on the defined contractual relationship, and based on a trusted relationship and its associated policy, Automatically transferring the portion of the payment to the account of the at least one merchant to federate payment to the merchant and at least one merchant.   The portion is further identified based on a portion specified in bill information generated by the merchant that is presented to a consumer who has authorized the single payment. 181. The method of claim 180.   187. The method of claim 181, wherein the portion is signed by the merchant to make the payment federation transparent to the consumer. A method of presenting payment options to consumers based on an analysis of electronic invoices and policies or rules defined by merchants, consumers, or both, in a distributed online system that performs business transactions,
Receiving an electronic invoice at the consumer device containing information about purchase requests for merchandise goods, services, or both;
Comparing information from within the electronic invoice with one or more predefined rules from the consumer, merchant, or both, and based on the comparison, the one or more predefined rules Determining a suitable action that satisfies the requirements of the rule.   The one or more predefined rules are a list of available types of payment options for the merchant, consumer, or both, and the action is one from the list for presentation to the user. 184. The method of claim 183, further comprising selecting a plurality of payment options.   The one or more predefined rules limit the type of payment based on a trust relationship with the merchant, and the information in the electronic invoice can be signed, encrypted, or both from the merchant 185. The method of claim 184, wherein the trust relationship is identified based on.   184. The one or more predefined rules restrict payment types based on the consumer's available payment types compared to the payment types accepted by the merchant. The method described in 1.   185. The method of claim 184, wherein the one or more predefined rules limit a type of payment based on a total cost of the one or more services, goods, or both.   185. The method of claim 184, wherein the information in the electronic bill further identifies the merchant rule such that the merchant rule is compared to the consumer rule.   189. All inconsistencies between the rule for the merchant and the rule for the consumer are resolved in favor of the merchant, otherwise the commercial transaction is canceled. Method.   184. The commercial transaction is a pay-for-use subscription, and the one or more rules limit the duration of the subscription based on payment amount, time period, or both. The method described.

Images