KR20070120125A - Online transaction authorization methods, systems and devices - Google Patents

Abstract

This embodiment provides for the authorization and payment of online commerce between a buyer and a merchant, including confirmation of the buyer's identity and the buyer's ability to pay for the transaction, wherein the ID provider and payment provider are often different network entities. Other embodiments also provide protocols, computing systems, and other mechanisms that enable identity and payment authentication using mobile modules to establish single or multiple levels of security over untrusted networks (eg, the Internet). Still other embodiments also provide three-way secure communication between the merchant, consumer and payment provider to ensure that the merchant is fully capable of paying for the requested purchase without the merchant knowing the sensitive account information. In another embodiment, electronic billing information is used for authorization, auditing, payment federation, and other purposes.

Description

Online transaction authorization method, system and device {NETWORK COMMERCIAL TRANSACTIONS}

The present invention relates to a networked trading system and method for performing online transactions.

The proliferation of networked computer systems has opened up new possibilities for how companies and individuals operate their businesses. For example, through networked devices such as computers, PDAs, cellular phones, and the like, end users connected to a network (eg, the Internet) may conduct commerce over the network to purchase services and / or goods, You can conduct financial transactions, run your business in other ways, or conduct personal transactions over the network. An essential problem with online transactions is security, especially when the transaction involves the transfer of money, funds and / or financial, personal or other confidential information.

Many conventional online transactions are performed according to 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 a first model, a merchant provides goods or services online via a browser. The term "merchant" refers herein to any entity that generally provides goods and / or services for purchase. The term 'merchant' is not used to describe any particular commercial status or describe a licensed seller unless explicitly stated. Rather, the term generally describes any seller or entity that provides 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 otherwise noted.

In a conventional online transaction, a merchant may have a website that describes, displays or otherwise provides goods and / or services for sale. The end user may indicate that he or she wishes to purchase one or more goods or services by selecting the item via the 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 needed 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 (e.g., Visa, MasterCard, American Express, etc.) Etc., it allows you to enter transaction information. The transaction page can also ask the end user questions about personal information such as name, billing address, shipping address, and the like. The end user then transmits the information and the merchant processes the transmitted information.

In this first model, the merchant generally "owns" the website. That is, the merchant maintains the website, is responsible for the content, and receives and processes the transaction information provided by the end user. The merchant may establish an account with the end user prior to conducting the first transaction, and then whenever the end user conducts a transaction with the merchant, the end user may access the account through a user-defined login and password. Can be. That is, the end user typically chooses a login name and password to be used in subsequent sessions or transactions. After the end user has sent the information queried by the transaction page (s), the merchant processes the information to confirm that the information is sufficient to complete the transaction. For example, a merchant may verify that a credit card number is valid and has sufficient funds to cover the cost of goods and / or services.

The second model generally includes a third party transaction provider that handles the payment portion of the transaction. The third party has relationships with both the end user and the merchant. Specifically, the end user can open an account that can be accessed through a login and password with a third party as described above. To open an account, an end user may provide personal and payment information to a third party (ie, the end user may provide personal information identifying the user and payment information, such as one or more credit card numbers, expiration dates, and the like. Can be provided). The end user may also open an electronic funds account by providing money to a third party payment transaction provider, the balance of which may be used to purchase goods and / or services online. have. This third party may archive the account information provided by the end user and / or maintain the end user balance.

This third party also establishes a relationship with the merchant, who handles the payment of the transaction. Specifically, this third party agrees to pay the merchant when an end user with an account requests a transfer of funds to make a purchase. The merchant may offer the option by notifying through his website where the goods and services are being sold that an option to use a third party is available. For example, when a user visits a merchant's website and decides to make a purchase, the user may then be provided with an option to pay for the purchase using a third party trading provider.

When an end user selects an option to pay for a purchase using a third party trading provider, the end user's browser is redirected to a website belonging to the third party trading provider. The end user then logs in to his account via a login / password combination and selects the type of payment (e.g., credit card) to use in the transaction or requests a transfer of funds from the user's money account to the merchant's account. If the merchant determines that the payment has been properly transferred by the transaction provider, the merchant may begin shipping the purchased product or providing the purchased service to the end user. In the second model, third parties are responsible for maintaining end user personal and financial information and processing transactions.

Conventional online transactions, such as the purchase of goods and / or services over a network, are vulnerable to security breach resulting in the loss of personal, financial and / or other confidential information. In addition, in an untrusted network (eg, the Internet), both the merchant and the buyer are at risk of dealing with the bad guys and one side of the transaction is not supported. In the traditional online trading model, the merchant must also keep the buyer's confidential information and the merchant must handle the payment aspect of the transaction. In addition, conventional online trading models are inconvenient for buyers and generally result in an unintuitive trading experience. For example, conventional online transactions are conducted through a browser using a confusing and unwieldy login / password paradigm.

Applicant believes that entrusting at least some of the transactional responsibilities handled by buyers and browsers in conventional models to lower-level systems (away from browsers and users) may facilitate a simpler and more secure online commerce framework. Confirmed and recognized. For example, one or more transactional tasks may be processed by the operating system at one or both of the end user and the merchant, in which case the information may be more secure. By embedding one or more tasks into the operating system, the user can relieve some of the burden of conveying transaction information, making the experience more intuitive and improving security. In addition, the merchant may be free from maintaining buyer information, processing payment information, and / or processing a transaction.

Applicant has also found that problems associated with verifying the buyer's identity can be mitigated by using more secure and convenient techniques than the login / password model. In one embodiment, the ID information about the buyer is provided by a subscriber identity module (SIM) card that stores ID information about the end user that can be issued programmatically, thereby creating a less confusing and simpler buying experience. Done. In addition, embodiments herein may employ protocols, methods, computing systems, and other mechanisms configured to perform single or multi-level authentication using a SIM device over an otherwise untrusted or unsecured network (eg, the Internet). to provide.

Applicant has also found that using various third parties, which are generally not of interest, to mitigate the risks associated with both buyers and merchants to provide various elements of the transaction of online commerce. In one aspect of the invention, the first network entity provides confirmation of the buyer's identity and the other network entity is capable of the user paying for the purchase, so that the merchant and the buyer who knows each other can conduct the transaction relatively safely. A commerce system is provided that provides confirmation.

Still other embodiments enable three-party secure transactions between merchants, consumers, and payment providers so that sensitive billing account information is not known to merchants or third parties. In this embodiment, the payment token is passed between the merchant and the payment provider via the consumer. These payment tokens are encrypted or signed so that merchants and others do not control or obtain any sensitive account information of the consumer. Nevertheless, the merchant can still confidently verify the payment token indicating that the consumer is capable of paying for the services and / or goods provided.

In other embodiments, 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 provided with machine readable electronic bills, which, in online commerce, automatically request and verify payments and It is also used for other purposes to create a transaction history and to provide a more accurate description of the service / product paid for. This billing information can also be used for payment consolidation that pays at once from the consumer to the various business partners of the merchant. For example, a merchant may have contractual relationships with various business partners who provide services and / or goods in commerce. The electronic billing information may include those payment portions that must be distributed among various affiliates so that payment integration can occur automatically without requiring user interaction or separate auditing and payment mechanisms.

Also provided herein is a mechanism for making automated decisions of commerce using rules or constraints defined by any number of network entities, including consumers, merchants, payment providers, and the like. For example, the payment method accepted by the merchant may be compared to the payment method available to the consumer. Based on this comparison, the consumer may only be offered those methods that match. As another alternative, the payment method may be automatically selected based on this comparison and / or based on additional rules or constraints. For example, the consumer may limit the type of payment based on the merchant and the established trust. Of course, there can be many types of rules and / or constraints that determine the various actions that can occur in commerce.

1 is a block diagram of a networked computer system for conducting online transactions, in accordance with an embodiment of the present invention.

2 illustrates a system and method for initiating and performing identity verification in an online transaction, in accordance with an embodiment of the present invention.

3 illustrates a system and method for performing payment negotiation, verification and / or certification in an online transaction, in accordance with an embodiment of the present invention.

4 is a diagram of a networked computer system for performing online transactions, in accordance with one embodiment of the present invention, wherein the transactions are processed at least in part by transaction software installed on a computer connected to the network.

5 is a diagram of a networked computer system for performing online transactions, in accordance with another embodiment of the present invention, wherein the 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 that performs licensing for an application installed on an end user computer, in accordance with one embodiment of the present invention, wherein the license is obtained through an online transaction. .

FIG. 7A 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.

FIG. 7B 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.

7C illustrates a system configured to perform single or multilevel verification of various different services using a mobile module, according to an example embodiment.

8 illustrates a three-party payment information security exchange and payment integration, according to an example embodiment.

9 illustrates various uses of a commerce subsystem and bill presentation, in accordance with an exemplary embodiment.

10 illustrates the use of payment methods and rules to determine which type of payment provider should be used for commerce in accordance with an exemplary embodiment.

11 illustrates a subscriber identity module (SIM) device in a configuration with a firewall to conform to a wireless network communication protocol established when used for commerce, in accordance with an exemplary embodiment.

In the drawings, each identical or nearly identical component that is illustrated in various figures is represented by a like numeral. For clarity, not every component may be labeled in every drawing.

The traditional model of networked commerce focuses on the browser as an interface for requesting and transmitting personal and financial information between end-user buyers and merchants or service providers, whether directly through merchants or third party trading providers. have. In the first case, merchants typically have the burden of establishing and maintaining an infrastructure that can query, obtain, handle and process personal and financial information with some minimum level of security. In addition, the merchant may be responsible for maintaining account and account information (which typically includes both confidential personal and financial information) for each of his clients.

Buyer must pass on personal information (e.g. name, address, phone number, etc.) and financial information (e.g. cash and credit card number and expiration date, bank account number, etc.) to complete the transaction. . At some level, the buyer must think that, using only authorized information, the merchant is an honest broker and will operate in good faith. Similarly, a merchant must think that the buyer is himself and that the payment information provided is really associated with the end user making the purchase. There may be no sure way for the merchant to validate the buyer's ID and / or payment information. In a distributed network environment, the buyer may have to rely on the merchant's reputation, which may limit the source from which the buyer is willing to trade. The merchant may have to operate with much less confidence that the buyer is a sincere and bona fide buyer. In untrusted networks, this model can provide excessive risk to one or both parties.

Even when the natural trust established between buyers and merchants has evolved, databases storing customer information maintained by merchants are vulnerable to hacking, information theft, and otherwise bad guys in sincere and reliable businesses. can do. Third party trading providers are also vulnerable to electronic theft, security breaches, and so on. More sophisticated "spyware" programs allow hackers to record keystrokes and take screenshots of compromised computers, making browser-based transactions particularly vulnerable to electronic theft. Thus, a buyer performing online commerce in accordance with conventional methods and models may be vulnerable to the dissemination and illegal use of his confidential personal and financial information.

In the conventional commerce model, the purchaser generally has to set up an account with each merchant who wishes to do business. In general, accounts are protected and accessed through login names and passwords, whereby the buyer must manage multiple logins and passwords and maintain which login / password combination corresponds to which account. Some customers may rely on storing their login / password combination locally on his 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 breaching all of his accounts if a single login / password combination is obtained by electronic theft. In addition to the inherent security risks associated with conventional login / password paradigms, buyers may find the account login procedure an inconvenient transaction experience. Specifically, having to log in to an account when making a purchase makes the transaction less convenient because the buyer must somehow present this information before the transaction can be completed. In addition, if there is a third party trading provider, the buyer is redirected from the merchant's website to the third party trading provider's website. This step is not intuitive and, at best, cumbersome and confusing for buyers.

Applicant believes that entrusting at least some of the transactional responsibilities handled by buyers and browsers in conventional models to lower-level systems (away from browsers and users) may facilitate a simpler and more secure online commerce framework. Confirmed and recognized. In one embodiment, one or more transactional tasks may be processed by the operating system (or some other trusted subsystem) at one or both of the end user and the merchant, in which case the information may be protected more securely. By embedding one or more tasks into the operating system, the user can relieve some of the burden of conveying transaction information, making the experience more intuitive and improving security. In addition, the merchant may be free from maintaining buyer information, processing payment information, and / or processing a transaction.

Applicant has also found that problems associated with verifying a user's identity can be mitigated by using more secure and convenient techniques than the login / password model. In one embodiment, the ID information about the purchaser is provided by a subscriber identity module (SIM) card that stores ID information about an end user that can be issued programmatically. In another embodiment, the identification information is provided by a smart card embedded therein or otherwise connected to a network device from which the buyer conducts online commerce. The use of any of a variety of chip or card based ID means allows the buyer to associate his ID with a particular device, such as a cellular telephone or a networked computer.

The terms "programmatically" and / or "automatically" refer to the operation being performed with little manual or operator intervention. In particular, 'programmatic' or 'automatic' means that an operation is initiated and / or performed by one or more computer programs. For example, it is not considered programmatic to provide ID information by asking a user (eg, a buyer) to provide login and / or password information, since the substance of the operation is performed by the user. Because. However, the operation of the program issuing ID information (eg, SIM number, network address hardware ID, etc.) without asking the user to enter the information is considered programmatic. Note that this automatic operation can be implemented by either software or hardware components.

Applicant has also recognized that distributing the various transactional elements of online commerce across different network devices facilitates more secure commerce over untrusted networks. In one embodiment, the identity provider and payment provider (both are end users, merchants, and separate network entities from each other) provide verification support during commerce. The term "network entity" refers herein to network presence and may be one or a combination of end users / buyers, ID providers, payment providers, merchants, and the like. The network entity may have a presence on the network through one or multiple network nodes. For example, multiple networked devices can operate under the protection of a single network entity, such as an identity provider who uses multiple servers to run an online business, or an end user connected to the network through cellular telephones and personal computers. . The network entity may be a business such as a bank or retailer or an individual such as an end user.

In one embodiment, the various elements of an online transaction are distributed across separate and independent network entities. For example, the identity provider can provide ID verification in the form of an identity token, and the merchant can use this ID token to verify the buyer's identity. The ID token can include one or more identity credentials of the end user. ID information provided by the end user / buyer, for example, subscriber number from SIM, network address (eg, Network Interface Card (NIC) ID, World Wide Name (WWN)) , Etc.), login information, etc. may be issued an ID token. Similarly, the payment provider may provide confirmation in the form of a payment token that the end user is capable of paying. In addition, the payment provider may process payment transactions on behalf of the buyer as payment of the purchase of goods and / or services from the merchant. The above-described framework, among other things, allows buyers and merchants who have no knowledge of each other to conduct online commerce relatively confidently in an untrusted network environment, as described in more detail in the various exemplary embodiments provided below. do.

For example, one embodiment provides three-party secure communication between merchants, consumers, and payment providers during commerce to purchase services and / or goods in an online or retail environment. As described in more detail below, the payment token is passed from the payment provider to the merchant via the consumer. These payment tokens enable the merchant to verify the authenticity of the token directly against the payment provider, providing evidence that the consumer is capable of paying for the service and / or product. While these payment tokens uniquely identify the authorization of payment for services and / or goods, sensitive information about the consumer's billing account is not included in the token or otherwise encrypted so that the merchant cannot see it. Thus, the sensitive information of the consumer is invisible to the merchant, so that even if there is no trust relationship between them, the consumer can confidently purchase items from the merchant. In addition, since the merchant can verify the payment token directly against the payment provider, the merchant may not be able to maintain such services and / or without maintaining financial information about the consumer (eg, credit card number, account information, etc.). The goods can be delivered with confidence that the goods can be paid. In addition, since the payment provider can verify the authenticity of the payment token from the consumer, the payment provider can transfer funds to the merchant with confidence, thus completing the three-party secured commerce.

As mentioned above, other embodiments of the framework provided herein move a portion of the transaction to a more secure subsystem of the computing system (eg, an operating system). This is beneficially an abstraction model that allows legacy applications to provide an in-band online commercial transaction experience, additional types of fraud prevention, audits and payments. It enables numerous features such as bill capture and presentation for integration and other payment or authentication purposes, service provider code execution for additional security and merchant related functions, multi-level authentication, and other features. For example, this abstraction model allows legacy and other applications to provide users with online purchases and payments as if these transactions were occurring directly within the application, but part of the commerce was out-of-process. -band) is performed. Examples include catalog purchases (e.g., Amazon, Sears, etc.), direct purchase of multimedia content from within a multimedia application, and download software / games in trial mode. The in-band payment mode automatically unlocks them and enables payment for subscription-based services, such as short message services via email.

In addition, in another embodiment, the framework captures and presents electronic invoices as a mechanism for additional authentication, auditing, payment consolidation, and other purposes in the three-party (and other) transactions described above, as described in more detail below. Describe. In addition, by moving commerce to a more secure part of the subsystem, other embodiments allow merchants to be confident that certain code (e.g., additional user authentication) on a machine with the confidence that such code will not be hacked or otherwise compromised. , Payment rules / mechanisms, user experiences, etc.). Of course, as described in more detail below, the Applicant has also realized other beneficial features through the use of the abstraction model provided herein.

In another embodiment, Applicant also provides an overall system and protocol for using a mobile module for secure communication and ID authentication and payment functions for a variety of different services. For example, a subscriber identity module (SIM) (or other similar mobile module) can be used to authenticate a user and / or device to a service or server in a multilevel verification environment. In this environment, the mobile module (perhaps even a user) is authenticated via a network independent of the network mobile infrastructure for the mobile module. Thus, the system verifies ownership of the mobile module through authentication of an active billing account in the mobile infrastructure. It uses secure communication protocols (e.g., WS-Authentication, WS-Security, and other similar protocols) to securely communicate with computing devices and services (e.g., Web Services, WS) connected to mobile modules. Set. Such secure communication may also be used to authenticate users through other protocols and data exchange between the mobile module and the mobile infrastructure, as described in more detail below. In addition, other embodiments provide protocols and state machines that abstract computing devices (used in communication over independent networks) from the mobile infrastructure. Accordingly, the mobile module itself becomes a mobile terminal, and the computing device becomes a peripheral device, thus conforming to current wireless standards such as 3rd Generation Partnership Project (3GPP).

1 is a block diagram of a commerce system 100 including 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 130. It is shown. Each of the nodes may include one or more computing devices interconnected via a network 105. It will be appreciated that end user computers, merchants 140, ID providers 120, and payment providers 130 may be associated with network entities such as individuals, companies, or businesses. For example, end user computer 110 is generally associated with an individual who uses a computer to access resources on the network, and merchant computer 140 may be associated with a company or business that provides goods and / or services for sale. May be related. One or more computing devices that form each of the aforementioned components within the commerce system 100 may include a point of entry, computing platform, and / or vehicle through which the associated network entity is used to communicate over the network. Can function as

Note that although the embodiments provided herein can be described in an online purchasing environment, the embodiments can also be used in a direct retail transaction. For example, the above description and the following description of commerce may apply to a consumer purchasing a product at a retail store, where payment, identity, authentication, and other embodiments are used. Accordingly, the use of the online experience in describing the embodiments herein is for illustrative purposes only and is not intended to limit or otherwise narrow the scope of the embodiments unless explicitly claimed otherwise.

It should also be noted that the network 105 may be any type of network in any type of configuration that allows nodes connected to the network to communicate with each other at the same time. The node or device may be connected to the network via copper (eg, Category 5) cable, optical connection, wireless or any combination thereof. Information may be transmitted using any low level protocol such as Ethernet and / or any information protocol such as TCP / IP. The network 105 may be any number of devices connected to it and may be a trusted network (eg, an intranet) or an untrusted network (eg, LAN / WAN, the Internet, etc.), or a combination of both. Can be. The computers connected to the network may be any type of device, including, but not limited to, mobile phones, desktop computers, tablet personal computers, servers, workstations, and the like.

2 is a diagram illustrating a system and method for initiating and performing ID verification in an online transaction, according to an embodiment of the present invention, and FIG. 3 is a diagram illustrating payment negotiation, verification and in an online transaction, according to an embodiment of the present invention. And / or a diagram illustrating a system and method of performing a warranty. These methods can be used individually or in combination to conduct online transactions between end users / buyers and merchants. In the following description, unless specifically noted, network entities and their associated network devices are not distinguished. For example, an "identity provider" generally refers to an identity provider as an entity (eg, a bank, a government agency, a government office, etc.) and that entity provides various network functions (identity identification for end users or entities). It is used to describe as a computing device that is used to perform other methods, such as to operate in a different manner).

End user computer 110 places an order 242 with merchant 140. This order 242 can be any indication that the end user wants to purchase one or more goods and / or services from the merchant 140. For example, this order 242 may be the result of an end user selecting a product or service via a web browser displaying a page residing on the merchant's website, or the result of selecting an option from a locally running application. This may be described in more detail below. As an example of the first case, merchant 140 may provide a website to display or otherwise present for sale the goods and / or services offered by the website, or provide an online catalog of goods. . Order 242 may be any type of indication that a user wishes to purchase one or more goods and / or services from merchant 140.

As an example of the second case and as an alternative to selecting one or more goods and services from the merchant's website, the order 242 may originate from an application or other program local to the end user computer 110. For example, end users can create, create, or edit documents through word processing applications, design slideshows using presentation applications, and / or use posters or imaging applications Manipulate images or graphics in brochures. This application prints an option that allows a document to be printed by a third party, for example, to take advantage of printing features not available locally or in other ways to use a professional-grade print service. Can be included below the menu. When this option is selected, the application can send the order 242 to the merchant 140 via the network. As aspects of the present invention are not limited in this respect, it will be appreciated that order 242 may be any indication to purchase any goods and / or services.

In response to the order 242, the merchant 140 may request that the end user 110 provide the end user's ID and / or confirmation that the end user is actually himself (step 205). For example, merchant 140 may not know anything about the origin of order 242 and may want information about the end user's ID and / or guarantee that the end user is not deceiving his ID. Alternatively, merchant 140 may send a notification or indication that a payment is needed for the service and may require that a payment token be provided. In order to obtain a payment token, it may first be necessary to verify the identity via an identity token. In either case, the end user 110 may respond to the merchant 140's request by enlisting in the service of the identity provider 120 (step 215).

To obtain an ID token, end user 140 provides ID information to ID provider 120. The ID information may include any information that allows the ID provider 120 to distinguish between the end user using the end user computer 110 and the various other end users for which the ID provider may provide a service. For example, the ID information may include a unique identifier associated with the hardware of the end user computer 110. In one embodiment, the ID information is provided by the SIM card issuing an identifier unique to the subscriber. The identification information may be 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 (in some embodiments). ) Providing any other means by which the end user computer 110 can be identified, including the established login name / password combination.

ID provider 120 uses the ID information to find an identity credential associated with the end user. For example, the ID provider 120 may include a database that stores ID information and credentials for a plurality of end users. The ID information can be used to index the database to obtain correct ID credentials. ID provider 120 may be any type of entity. For example, the identity provider 120 may be a mobile phone company that uses the subscriber number provided by the end user's SIM card to find appropriate ID 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 using SIM technology. ID provider 120 may be a bank, a governmental agency (registry of motor vehicle (RMV), etc.), or any other facility that maintains ID information or credentials associated with the end user.

In response to the ID information provided by the end user, ID provider 120 provides the end user computer 110 with an ID token that provides ID authentication and / or credentials for the end user (step 225). The ID token can be any type of electronic message that other network devices can use to authenticate, verify, and / or determine the identity of the end user. For example, the ID token can include the end user's ID credentials. ID credentials may include, but are not limited to, any one or combination of names, birthdays, addresses, phone numbers, email addresses, and the like.

The ID token can include an electronic signature from ID provider 120 that proves the ID credentials must be wrong. As such, merchants and / or payment providers may rely on non-interested third parties (ie, identity providers) rather than on behalf of any end user. The ID token is encrypted and received by the desired network device (e.g. merchant, payment provider, etc., as described in more detail below) prior to being sent over the network to protect it from eavesdropping on the network. Can be decrypted. In other embodiments, the payment token is merely a certification of the end user's ID without involving ID information.

ID provider 120 may send the ID token to end user computer 110 for delivery to merchant 140 (step 235) and / or ID provider 120 may send the ID token directly to merchant 140. Can be. The merchant 140 then processes the ID token to identify the end user and / or confirm that the end user is himself. The ID token can be used to authenticate any information about the end user that may affect the transaction. For example, merchant 140 may provide a service that requires an end user to be of a certain age. The ID credential sent with the ID token is used to ensure that the end user is of an appropriate age and meets this requirement. Merchant 140 may offer a discount to a particular end user who is a regular buyer or who has received a coupon, promotional offer, and the like. The merchant 140 may index the end user's database to determine if the end user is eligible and should be treated specially in other ways based on the provided ID credentials.

Optionally, merchant 140 may request verification of the ID token by sending a request to ID provider 120 (step 245). The verification request of the ID token may include passing the ID token from the merchant 140 to the ID provider 120. Upon receiving the request for verification of the ID token, the ID provider 120 may verify the ID token and thereby determine the authenticity of the ID token. ID provider 120 may then communicate an indication of the validity of the ID token to merchant 140 (step 255). As another alternative, the merchant 140 may simply verify the ID token itself (step 265) (eg, assuming that the ID token is valid or otherwise processing the token). Optionally, the response may be returned from the merchant 140 to the end user computer 110, in which case, since the present invention is not limited in this respect, the response may or may not be valid if the ID token is valid. Messages of applicable discounts or promotional offer discounts, and / or any other type of message (step 265).

After merchant 140 processes the ID token and / or receives verification for the ID token from ID provider 120, merchant 140 provides confirmation or verification that the end user is capable of paying and / or Or, you can ask the end user to provide an indication of how they want to pay for the goods or services. Merchant 140 may make the request via a payment token request (step 305 of FIG. 3). In response to the payment token request, the end user computer 110 may register with the service of the payment provider 130. Payment provider 130 may be associated with a third party that maintains financial and payment information about various end users, such as financial institutions, or a third party broker that processes financial transactions and payment procedures. .

End user computer 110 may request payment token from payment provider 130 by sending an ID token to payment provider 130 (step 315). As another alternative, the end user may log in to payment provider 130 in a manner similar to that described with respect to ID provider 120 (ie, provide an identifier such as a SIM subscriber number, NIC address, and / or login / By using cryptographic combinations). As the present invention is not limited in this respect, it will be appreciated that end users can request payment tokens in other ways. In addition, the end user may send information about the purchase, such as the price and characteristics of the purchase, such that the payment provider can confirm that the end user is capable of paying. However, it is not required to provide the purchase information because it may not be necessary or may be processed at later stages of the transaction.

Payment provider 130 processes the ID token (or other provided identifier) to find information about the end user. For example, payment provider 130 may access a database of payment information based on the ID credentials sent with the ID token. Payment provider 130 may determine which payment capabilities and options are available to the identified end user. The payment provider 130 may then verify that the end user is capable of paying and, in response, generate a payment token and send it to the end user computer 110 (step 325). The payment token may indicate the end user's ability to pay and / or the assurance that the payment provider 130 is willing to process the transaction on behalf of the end user. The end user computer 110 may then pass the payment token to the merchant 140 (step 335).

The merchant 140 processes the payment token so that the merchant 140 is certain that the end user is capable of paying for the goods or services. For example, merchant 140 may require payment provider 130 to verify payment tokens (steps 345 and 355), or by processing the tokens (eg, assuming payment tokens are valid or otherwise). ) Itself can simply verify the payment token (step 365). The merchant 140 may then begin the process of providing goods and / or services to the end user. Since payment provider 130 may be an uninterested third party, merchant 140 may treat payment tokens as essentially payments and may not need to wait until the transaction is fully processed.

When a merchant deals directly with an end user in a conventional trading model, the merchant may have to be sure that the payment information provided by the end user is accurate and sufficient. For example, a merchant may query a credit card system to query whether a provided credit card number is valid, the card is valid, there is sufficient funds and / or that the card is correctly associated with the ID provided by the end user. You may need to use that number. If something does not check out, the transaction may have to be canceled, terminated or abandoned. In addition, termination of the transaction may occur after the end user perceives the transaction as complete and no longer accesses the network and / or no longer accesses the merchant's website.

Subsequently, the merchant had a problem with the transaction and the end user would have to end the transaction again (e.g. by entering payment information correctly, specifying another card with sufficient funds, etc.) to correct the problem. You may have to notify the end user. In some cases, the end user may not be notified and the commerce may never complete.

In various embodiments described herein, payment tokens are provided unless the end user payment information is accurate, sufficient funds are available, and / or the payment provider otherwise guarantees that payment will be made on behalf of the end user. Since this will not be issued, the dealer can start the deal immediately. Any defect in a transaction can be identified and resolved in real time so that all parties can be relatively confident that the expectations regarding the completion of the transaction will be met.

In addition, because the payment provider can process financial transactions (e.g., process credit cards, transfer funds, etc.), the merchant can, for example, process credit card numbers or perform payment procedures and transfer funds. You can get away with building and maintaining the infrastructure you need to handle it in other ways. In some cases, the payment token serves as a guarantee that the payment provider will transfer the designated funds, for example by sending money or performing electronic money transfer to the merchant. The payment token may also be a guarantee that payment will be made by non-electronic means such as a promise to issue a check to the merchant or other negotiable means.

From the merchant's point of view, commerce is almost without risk because fraud, deceit and even malicious mistakes in the end user's identification and payment verification are processed by a third party and thus provide personal and financial information. Because it is less affected. Thus, merchants are more willing to conduct online commerce with unknown end users via untrusted networks. From the end user's point of view, personal and financial information is present in an entity that already holds that information and / or has a relationship with the end user. The end user's confidential personal and financial information need not be provided to the merchant, mitigating that confidential information is prone to misuse or misappropriate. As a result, the end user can be more willing to conduct business with unknown merchants without having to worry about whether the merchant is reliable.

In some conventional commerce models, ID information and payment information are input by a user and processed by either a third party or a merchant. As mentioned above, these models are inconvenient for the user, inefficient and time consuming. In addition, the conventional model raises a number of problems with the security of the end user's confidential information as well as with the merchant being prone to fraud and / or vulnerable to the end user's failure to pay. The Applicant has recognized that commerce software installed on each of the computers used in various commerce can alleviate or eliminate security and fraud concerns. In addition, many of the operations handled by end users and merchants in conventional models can be performed by commerce software, making transactions simpler and more intuitive to the end user.

8 illustrates an example of using some of the features described above for three-party secure communication and various trust boundaries that may be established during a commerce. As will be described in more detail below, this model enables one-time or subscription payments as well as payment consolidation, allowing the service or merchant to collect payments for smaller companies, thereby allowing the customer to Allows you to pay your bill. As shown, distributed system 800 is configured to facilitate commerce between consumer 810, merchant 830, and payment provider 805. The payment trust boundary 815 separates the merchant 830 from the consumer 810 / payment provider 805 (ie, the consumer so that a trust relationship exists between the payment provider 805 and the consumer 810 or customer computing device). Uses any of the available mechanisms described herein to properly prove its identity or authenticate itself to the payment provider). As such, the consumer 810 may use this trust relationship to authorize payment to the merchant 830 for various types of payments and various types of services.

For example, merchant 830 reserves a deposit for a product (eg, custom item requiring prepayment, such as a car, computer, etc.) that consumer 810 wants to purchase. Assume a payment is required. However, prior to requesting payment authorization, the user of the consumer 810 computing device may require proper authentication as described herein. Once the user is authenticated, the consumer 810 computing device may appropriately request payment from the payment provider 805 through any of the various mechanisms also described herein. For example, the consumer 810 may provide the payment provider with billing or other request information that is signed or otherwise encrypted by the computing device of the consumer 810. This authorizes the verification request of the account holder (i.e. the consumer) for proper payment capability (i.e., the user has a prepaid account, a credit account, or a mobile subscription described below). Have other billing accounts). If successful, a payment token is issued, which is then reserved to ensure payment. This payment token is then generally signed and / or otherwise encrypted by the payment provider (eg, mobile web server as described herein) and passed to the consumer 810 client. The consumer 810 passes the payment token back to the merchant 830, which verifies this token with the payment provider and, if successful, completes the order.

If the article is ready for delivery (eg, when the order article is made), the merchant 830 requests the payment provider 805 to pay using a reserve payment token. Note that the payment request amount may be different from the amount reserved. Nevertheless, payment provider 805 confirms the payment response and sends it to merchant 830 and / or consumer 810. If approved, the merchant 830 may deliver (or otherwise provide) the order to the customer 810 and be provided with its payment. On the other hand, if payment is declined or additional user interaction is required, merchant 830, payment provider 805, and / or consumer 810 may choose which course of action to take. For example, if the amount requested by merchant 830 does not match the funds reserved, payment provider 805 and / or merchant 830 grants consumer 810 permission for the new amount. You can request As another alternative, payment provider 805 may require user input to permit transfer of funds regardless of any change in the reserved payment amount and the requested payment amount. Of course, other actions and procedures for completing a commerce are contemplated herein.

Note that while the above-mentioned three-party secure payment mechanism was used to purchase an ordered item, a single payment may be applied to other services and / or goods. For example, a single payment mechanism can be applied to a software program that is ready to be downloaded immediately. As another alternative, or in this regard, a single payment can unlock various levels of downloaded program (eg, student version, professional version, or other separate function). Indeed, as is well known, the above single payment may be used for various different types of purchases, and some may be in the form of slightly modified payments.

For example, the consumer 810 may provide for on-going services (e.g., newspaper or magazine subscriptions, movie subscriptions, game applications, or other pay-as-you-go goods and / or services). Assume that you want to establish a subscription with merchant 830. As such, merchant 830 will request a payment token from consumer 810, so that consumer 810 client can interact with a user who challenges permission to continue as described herein. . Similar to the foregoing, the consumer 810 signs or otherwise encrypts a payment request (eg, using electronic billing information as described herein below) and encrypts the request with a payment provider. 805 (eg, mobile carrier, credit card company, prepaid or other type of third party service, etc.). This verifies the request and verifies that the account holder (ie consumer or customer) has sufficient initial funds. If successful, the payment token is issued, signed and / or otherwise encrypted and returned to the consumer 810 client, which passes the payment token back to the subscription merchant 830. Then, the merchant 830 confirms the authentication of the token and completes the subscription setting.

Note that payment tokens are generally stored at merchant 830 and used periodically when requesting subscription payments from payment provider 805. As such, when processing a subscription payment, merchant 830 retrieves the payment token and sends it to payment provider 805 for payment settlement. The payment provider 805 confirms the payment response and returns it to the merchant 830 and / or the consumer 810. If the approved response is returned, the subscription merchant 830 will receive payment during the next payment provider 805 account payment being executed. However, if the payment request is denied, the payment provider 805 and / or the merchant 830 may respond appropriately. For example, merchant 830 (or payment provider 805) may contact the user or consumer 810 (eg, via email) to inform them about outstanding payments. The consumer 810 may then make a single payment as described above or set up another subscription payment through the same or another payment provider 805. Of course, merchant 830, payment provider 805, and / or consumer 810 may have other rules or requirements for handling these and other payment authorizations, which will be described in more detail below.

As mentioned above, other embodiments allow for the integration of a single consumer 810 payment to multiple business partners or subsidiaries in a contractual agreement. Often, business relationships are complex and require the distribution of payments for various services and / or products offered within a particular business model. For example, when purchasing a trip from a travel agency 830, the consumer 810 may be provided with a package deal, including flight bookings, hotel accommodations, transportation services, and the like. In general, the merchant 830 contracting out many of these services and / or products must maintain detailed accounting of such commerce in order to make appropriate payments to his business associates. To mitigate the complexity of these accounting and other tasks, embodiments herein provide automatic payment federation for business partners who are in a particular type of relationship for each transaction.

For example, a car rental service (eg, business partner “A” 820) may require payment from the merchant 830 as part of a holiday package sale. An insurance company (eg, business affiliate “B” 825) may bill the merchant 830 for a transaction fee. Based on business affiliate trust boundary 835, for each business affiliate (eg, “A” 820 and “B” 825) when a single payment is made to merchant 830. Payment is automatically integrated. In other words, the consumer 810 or payment provider 805 makes a single payment to the merchant 830, but all subsidiaries with a business relationship according to the trust boundary 835 for the business model may be properly paid. Note that this payment is generally linked to an electronic billing statement described in more detail below. More specifically, various parts of the electronic invoice for capture, presentation, and other purposes may correspond to which part of the payment should be integrated for each business partner. In addition, each of these portions is not known to the consumer 810, the payment provider 805, or between the various business partners 820, 825 as specific information about the payment is defined by various trust boundaries 815, 835. May be signed and / or encrypted.

Note that although the above payment integration model is described in relation to the travel agent experience, there are other business relationships in which this embodiment can be used. For example, companies that manufacture goods with multiple components purchased through various sellers, multimedia products that purchase materials for their products, pay for each item, or pay royalties based on each sale. A product provider making a payment, or any other type of business model that can bundle, calculate, and fulfill payments for a business partner by item, can also use the embodiments described herein. As such, the use of a travel agency to describe the various embodiments of the present disclosure above is for illustration only, and is not intended to limit or otherwise limit the embodiments described herein.

4 illustrates a networked computer system for processing commerce according to one embodiment of the invention. The networked computer system 400 may be similar to the computer system 100 shown in FIG. 1. However, in FIG. 4, each computer in system 400 includes a local installation of commerce software 485. Specifically, end user or consumer computer 410, ID provider 420, payment provider 430, and merchant 440 include commerce software 485a-485d, respectively. The commerce software installed locally on each of the computers in the system may be the same, or what role (s) the computer plays in the transaction (ie, the computer is an end user node, merchant node, identity provider node, payment provider node, Etc. or some combination thereof) may be customized for a particular computer. In either case, each installation is configured to communicate with what is installed on another networked computer to conduct online transactions. For example, each installation may be configured to communicate with an installation on a networked computer to perform the method shown in FIGS. 2 and / or 3.

In one embodiment, local installation of commerce software 485a on ID provider 420 may generate an ID token that identifies an end user using end user computer 410. In addition, commerce software 485a on ID provider 420 may pass the ID token to end user computer 410, payment provider 430, merchant 440, and / or any other computer, because the present invention This is because it is not limited in this regard. Local installation of commerce software 485b on end user computer 410 may issue ID information (to identify the end user) in response to an indication to conduct an online transaction between the end user and the merchant. Local installation of commerce software 485c installed on payment provider 430 may generate a payment token (eg, a payment token for online transactions) that receives an ID token and verifies the end user's ability to pay for online transactions. Can be. Local installation of commerce software 485d installed on merchant 440 may receive confirmation of the end user's ability to pay before continuing an online transaction.

운영 체제를 사용하여 동작할 수 있다. 상거래 소프트웨어(485)는 운영 체제의 서브시스템일 수 있다. 이와 같이, 상거래에서 이용되는 여러가지 컴퓨터들은 일관성있고 공지된 방식으로 통신을 하고 있다. 상거래 소프트웨어가 네트워크를 통해 직접 통신을 하고 검증, 확인 및 보안을 처리하고 있기 때문에, 최종 사용자 및 상인은 서로에 관해 아무것도 알 필요가 없으며, 보다 중요한 것은, 어떤 신뢰 관계도 수립할 필요가 없을 수도 있다는 것이다. 게다가, 거래의 어떤 부분이 운영 체제에 의해 처리되기 때문에, 거래의 많은 부분이 혼란스럽고 종종은 불편한 최종 사용자의 개입을 필요로 하지 않고 사용자에게 거의 보이지 않은 상태에서 수행될 수 있다.In one embodiment, each of the computers in system 400 operate using a local installation of the same or similar operating system 495. For example, each of the computers in system 400 may be Microsoft Windows.

Can be operated using an operating system. Commerce software 485 may be a subsystem of an operating system. As such, the various computers used in commerce communicate in a consistent and known manner. Because commerce software communicates directly over the network and handles verification, verification and security, end users and merchants need not know anything about each other, and more importantly, they may not need to establish any trust relationships. will be. In addition, since some portion of the transaction is handled by the operating system, much of the transaction can be performed in a state that is almost invisible to the user without requiring confusion and often inconvenient end user intervention.

By having commerce software on each computer, various encryption techniques can be used during the transfer of information from one computer to another. In addition, additional security features may be included, such as ID tokens and / or payment tokens that are valid for a limited period of time. For example, an ID token may then specify a time period during which no component receiving and processing that token should consider the token invalid and not respect that token as confirmation of ID and / or payment. It may include a time component. The commerce software component can programmatically handle any time restriction associated with the token. This can prevent tokens obtained by "fishing" from being used improperly later.

It will be appreciated that the commerce software need not be part of the operating system, but may be any program or group of programs local to computers involved in commerce that can communicate with each other over a network. For example, commerce software may be an application developed by a third party that may be installed on computers to operate on or independant of an operating system installed on the computer. This application is not limited to any particular operating system, processor, instruction set, or the like, and can be used with any one or combination of operating systems to make them available to computers or devices of a wide variety of functions and configurations. It can be configured to work together.

5 illustrates a commerce initiated by an end user selecting one or more desired goods and / or services, wherein a transactional component of a purchase is, at least in part, an operating system of various computers involved in one or more transactions. It is handled by the trading software subsystem distributed as part of. An end user connected to the network 505 via the end user computer 510 may be running the application 555. The application 555 may be a browser that displays a website of a business that provides goods or services for sale. The application 555 may be an application that provides an option to participate in an online transaction, such as an image editing program that allows a user to manipulate the image.

The end user may select one or more products or services to purchase through the application 555. For example, the end user may want the edited image to be professionally printed on photo quality paper. The application 555 may include these options under the print menu. The print option, when selected, may generate a window or dialog box listing all of the print options available, including services available over the network. For example, the print options may enumerate service providers 540a, 540b, 540c as options for providing print services. When the user selects one of the service providers, online commerce as described above may be initiated. In particular, the service provider may request the end user to provide an ID token. In response, application 555 (or an application built into commerce software 585) may generate a dialog or interface listing the available ID providers. For example, as described in more detail below, the dialog may list the ID providers 520a, 520b, and 520c as possible ID providers that the user may choose to handle ID verification.

9 illustrates use of a trusted commerce subsystem and other features in a distributed system, in accordance with an example embodiment. As shown, local computing device 920 in distributed system 900 is configured to provide an online or local retail transaction in accordance with embodiments described herein. Note that although the trust commerce subsystem 965 is only shown as part of the local computing device 920, similar subsystems may exist on other network entities. In addition, it should be noted that various components or modules may be described herein as being on any particular network entity, but such components or modules may be distributed throughout the computing system and may include any number of networks. May exist on an entity (ie, a portion may exist on one or more network entities). As such, the specific aesthetic layout of a particular module and the use of that module by a network device or entity is used herein for illustrative purposes only and is not intended to limit or otherwise narrow the scope of the embodiments herein.

Regardless of the distribution and aesthetic layout of the computing system 900, there is a trust boundary 906 that distinguishes trust relationships between the various components, as described above. Although this relationship may be distributed differently, in this example, a trust relationship exists between payment provider 990 and trust commerce subsystem 965. This advantageously enables many features that current commerce systems cannot provide. For example, trust boundary 906 abstracts application 925 from commerce with a merchant. As such, although many of the functions appear to be out-of-band, legacy and other applications 925 may provide an in-band experience for the end user 940. . For example, in the above example that enables professional image printing on photo quality paper, selection within a pull-down menu, ID verification, payment method, and other components that assist the user in purchasing such a service may include an application 925. Seems to be part. As such, application 925 may make a purchase call 930 to trusted commerce subsystem 965 when it receives an input to purchase a service and / or product, which subsystem 965 may: As described herein, it is used to generate a dialog, receive a user 940 input 935, and otherwise automatically communicate with merchant 905 and / or payment provider 990.

In other words, user 940 does not necessarily have to trust application 925 or merchant 905 in commerce. Instead, this trust is limited to the subsystem 965 of the present framework, which lowers the level or level of trust required to conduct commerce confidently and securely. That is, the account details 950 of the user 940 (the sensitive information 955 (e.g., credit card information, personal information, username / password, Etc.) are accessed via direct user input 935 to subsystem 965 or from secure 960 account information store 945. As such, application 925, merchant 905, and other components may be abstracted from financial and other billing account details 955 controlled by subsystem 965 as described herein. have. This is quite different from the current commerce model described above, where the application 925 or merchant 905 maintains and controls account information. Thus, this embodiment and other embodiments described herein advantageously provide an additional layer of security during such commerce. This is a much more directed trust relationship to minimize the number of components or organizations that access or access very sensitive financial data.

In addition, as shown in FIG. 9, similar to the three-party secure commerce described above, trust boundary 906 also represents secure communication between the payment provider and trusted commerce subsystem 965. As such, subsystem 965 is authenticated to payment provider (s) 990 in any of the numerous ways described herein to enable secure communication with them. Similar to the foregoing, the local computing device (which may be a handheld portable device described below in a local retail transaction, a personal computer in an online transaction, or other similar device described herein) may be a variety of services and / or It is desired that a product be offered by merchant (s) 905. In this example, as used in the example embodiments described herein, charging information 910 is provided to local computing device 920 for authentication, auditing, or other purposes. Such billing information may include prices of goods and / or services, detailed descriptions of commerce, merchant 905 related information, consolidated payment information, transaction type (eg, single payment, subscription, other) or other types of billing information. It may include, but is not limited to. The billing information 910 may also include other information, such as merchant restrictions and payment methods, described in more detail below.

In one embodiment, the billing information 910 is an electronic bill configured to be machine readable, providing many of the beneficial functions of current commerce systems. For example, one embodiment defines that the charging information 910 may be part of the payment token request 980 as described above (or otherwise communicated to the payment provider 990 in another communication). . As such, the charging information may be used by payment provider 990 for payment token verification 940. More specifically, the charging information 910 provided from the consumer or local computing device 920 may be compared with the payment token 985 information provided from the merchant 905 at payment token verification 904. Accordingly, if the charging information 910 for payment token verification 904 matches the charging information 910 from the token request 980, the payment provider 990 may authenticate the authenticity of the payment token 985. And the validity of the merchant.

Note that the charging information 910 from the merchant may be relayed to the payment provider 990 (as well as other components herein). For example, the charging information 910 sent from the merchant 905 to the payment provider 990 may be a copy of the charging information 910 sent to the trusted commerce subsystem 965 or the client 920. As another alternative or in this regard, the charging information 910 may be a signed and / or encrypted version from the payment provider 990, routed via the consumer or local computing device 920. In either case, the payment provider may perform the comparison described above for authentication of the payment token 985.

It should also be noted that this billing information 910 used by the payment provider 990 provides a more detailed description of the charge associated with the bill subsequently presented to the user 940 as the charge for the user's account. It can also be used to. Since this may also be a machine readable invoice 910, the local computing device 920 may receive the billing information 910 from that previously received by the merchant 905 for further authorization of payment to the merchant 905. You can contrast it. In other words, if the billing information 910 in the bill from the payment provider 990 does not match that received from the merchant 905, the bill may be considered fraud.

In other embodiments, merchant 905 may use billing information 910 for auditing, user and other authentication purposes, payment consolidation, and the like. For example, a merchant may sign or otherwise encrypt a portion of billing information 910. This enables a number of beneficial features in the embodiments described herein. For example, the charging information 910 may be part of a payment token 985 received by the payment provider via the local computing device 920. The merchant 905 may validate the charging information 910 to authenticate whether the payment token 985 came from the client 920 or the trusted commerce subsystem 965. Similarly, during payment token verification 904, merchant 905 may receive billing information 910 received from payment provider 990 to verify or authenticate payment provider 990 and / or local computing device 920. ) Can be used. In other words, since the billing information 910 is sent to the payment provider via the subsystem 965 or the consumer 920, the billing information received from the payment provider that matches that sent to the client 920 is sent to the payment provider 990. Both payment token 985 and client 920 may be authenticated.

Note that in other embodiments, as briefly described above, charging information 910 may also be used by the merchant for payment integration. In this embodiment, various portions of the billing information 910 may be machine readable to determine which portion of the funds from the payment provider 990 should be distributed to the business affiliate as described above (at the time of successful payment verification). Can be. Note that in this embodiment, portions of the billing information 910 are generally encrypted or otherwise associated with the user 940 (or consumer client 920), the payment provider 990, or the merchant 905. It is invisible to other components that are not part of a business relationship. It also uniquely identifies business partners in billing federation and can be used by him for authentication. More specifically, various portions of the billing information 910 associated with a business partner may be encrypted using a key associated with that business partner, such that the billing information is visible only to the merchant 905 and the associated business partner. have. However, in other embodiments, portions of the bill for payment distribution or consolidation are only signed by merchant 905 to be invisible to other components in system 900.

Of course, as is well known, other uses of the charging information 910 may be used for various purposes. For example, charging information 910 may also be used for auditing purposes, product distribution reconciliation, or any other well-known business and other purposes. Accordingly, this use of billing information 910 for authentication, identification, payment consolidation, or any other purpose is used for illustration only and, unless expressly stated otherwise, limits the scope of embodiments or otherwise. It is not intended to be narrowed in any way.

Note that trust boundary 906 and subsystem 965 also have other beneficial features in the other embodiments described herein. For example, as shown in FIG. 9, payment provider code 970 in subsystem 965 enables the secure execution of code specific to one or more payment providers 990. This code may be used for additional authorization associated with the payment provider, for example biometrics, radio frequency identification (RFID), username / password, or any of a number of additional authentication techniques. In other words, due to the trust relationship that payment provider 990 has with subsystem 965, payment provider may execute a trusted code for its specific business purpose.

The use of such code 970 also enables a more integrated in-band user experience that can be controlled by payment provider 990 or any other component that has a trust relationship with subsystem 965. For example, although not shown, a trust relationship may exist between a merchant 905 and the subsystem 965 to allow its trust code to be executed by the subsystem 965. As such, merchant 905, payment provider 990, or any other component involved in a commerce can provide an integrated user experience that appears to be running within application 925 (legacy or otherwise). However, many of the events occur out-of-band. For example, in the above example of photo quality printing of an image by a professional service, a dialog box, a payment method, or any provided to a user or application function (eg, in response to user input). Other number of features of may be controlled by code 970 specifically provided by various trusted network entities (eg, payment provider 990, merchant 905, etc.). As such, as described in more detail below, this code may also be used when evaluating payment methods and other constraints from merchant 905 and / or payment provider 990.

As noted above, in one embodiment, the selected service provider or merchant sends any requirement to the ID provider with a request for ID verification. For example, a service provider may be selling goods or services that require a minimum age or are restricted to some geographic location. As such, the list of ID providers may be limited to those that can provide ID credentials that meet the requirements of the service provider. For example, the list of ID providers may be limited to those that can provide current address information or age verification, such as RMV.

Similarly, a dialog may be generated listing the options for the payment provider. For example, the dialog box may include a credit card company, a bank that provides an electronic debit service, or a private third party that provides financial services, respectively. 530a, 530b, and 530c. As in the ID request, the selected service provider may include any payment requirement associated with the purchase. For example, a service provider can only accept certain types of credit cards. The payment requirements can then be reflected in the available payment providers listed or enabled in the payment provider selection dialog. After the payment provider is selected, payment certification can continue and the transaction can be completed.

Note that it may provide for comparing merchant constraints (eg, available payment methods, age restrictions, etc.) with consumer rules to determine various actions that other embodiments may also take. 10 illustrates such an embodiment, the distributed system 1000 is configured to programmatically determine behavior based on such things as merchant constraints 1010 and / or consumer rules 1035. For example, merchant 1020 may define a payment type in merchant constraint 1010 that is acceptable for purchasing a service and / or product of payment provider 1005 or merchant. The decision module may then provide this constraint to the user, for example, in a user interface requesting user input 1040 to select one or more of the available payment methods. Based on the user input 1040, the appropriate payment provider 1005 may be contacted for proper funding of the service and / or product.

In other embodiments, consumer rules 1035 may also be used in addition to or instead of merchant constraints 1010. For example, the consumer rule 1035 may indicate that only certain types of payments may be made to certain types of merchants 1020. More specifically, the consumer rule 1035 may indicate that if the merchant 1020 is not registered or otherwise trusted, only payments that can be canceled for purchases made from the merchant 1020 may be used.

Of course, as noted above, other merchant rules 1010 and consumer constraints 1035 may be used by decision module 1030 to determine the action to take in the commerce. Indeed, merchant constraints 1010 and consumer rules 1035 may be compared for compatibility and other purposes. For example, when providing various payment providers 1005 to a user, the available payment methods from merchant 1020 may be compared with payment providers 1005 available or acceptable to the consumer. Of course, payment selection may also be made automatically based on such things as default settings, provider ratings or preferences, or any other number of option settings. Indeed, there may be any number of actions based on the implementation of various merchant rules 1010 and / or consumer rules 1035. For example, if a rule (merchant rule 1010 or consumer rule 1035) is not observed or otherwise violated, the merchant (automatically based on additional rules or settings) to resolve conflicts or other inconsistencies Additional input from 1020 or user 1040 may be needed. Accordingly, any particular action taken when implementing the defined constraints and / or rules is for illustration only and is not intended to limit or otherwise limit the embodiments provided herein.

It should also be noted that, as noted above, the merchant constraint 1010 may be included in the charging information or provided separately to the consumer. It should also be noted that the comparison of the various rules and the actions taken by them can all be done in secret, ie without notifying the user and / or other system components. In addition, it should be noted that the system is not limited to only the constraints or rules defined by the consumer or merchant. For example, a payment provider may also define various restrictions that may also be considered in connection with or instead of consumer and / or merchant rules. As such, the above use of merchant and consumer constraints to determine various behaviors (such as payment provider options) is for illustration only and, unless expressly stated otherwise, restricts or otherwise modifies the embodiments described herein. It is not intended to be limited to.

In conventional online transactions, it can be difficult for both end users and / or service providers to know for sure when the transaction is completed and whether the goods or services have been successfully delivered. For example, the end user may select a software package for downloading over the network, or the end user may purchase a song, movie, or other electronic media. At times, the network connection may be interrupted before the download can be completed. In this situation, the end user may be tempted to reselect the product, but hesitant, because the user does not know whether the purchase is double charged. Similarly, the service provider may not know if the download has completed successfully and may be charged twice when the user attempts to heal the interruption by reselecting the product.

Applicants have found that providing logging or auditing functionality within commerce software can remove some of the uncertainty associated with electronic downloads. For example, the final execution of the payment method may depend on a signal from the audit function that the download is complete. As such, if the download is interrupted, the end user can be sure that the selected payment method has not been completed. For example, commerce software 585 (or other subsystem or network entity component described herein) from FIG. 5 may include a logging function that records all of the various stages of commerce performed by the machine. . The logging information can be used as evidence of purchase or in other ways to commemorate the transaction. In addition, commerce software 585 may include a monitoring function for electronic downloads that sends confirmation of successful downloads (final payments are made only after this download). By making a payment according to a signal that the transfer of goods or services has been successfully completed, the problem of double billing can be solved and almost eliminated.

The software is created by the company to handle a wide range of tasks, including familiar word and document processing, spreadsheets, image editing, and more specialized tasks such as video editing, computer graphics software, web-content development applications, portfolio management software, and so forth. Developed. However, owning software that handles each task that an end user might want to perform can be very expensive. Software packages can cost hundreds to tens of thousands and even hundreds of thousands of dollars to obtain a license. In addition, the end user may only need the service of a particular application only occasionally or sporadically, so the cost of purchasing the application cannot be justified.

Applicants have seen the benefits of enabling end users to use the software in a pay-as-you-go environment. Specifically, the end user may only be billed for the amount of time it took to use the application, rather than paying the retail price of the software (in this case many of the features and / or the application is generally not used). 6 illustrates a networked computer system with a commerce framework that enables 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 ID 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 may be installed on the end user computer. The software application may come bundled with a computer at the time of purchase, may be downloaded free of charge over the network, or in other ways by the seller of the application (often free or for a small fee or by registering with the seller). Can be distributed. The application 655 can be any type of application and any number of applications can be installed on the computer. The service provider 640 may be associated with one or more applications installed on the end user computer 610. For example, service provider 640a may be one or more computers owned by the developer and seller of application 655a. Similarly, service providers 640b and 640c may be associated with applications 655b and 655c, respectively.

In the pay-as-you-go model, the service provided by the service provider is a license to use the associated application installed on the computer. For example, when software (e.g., application 655) is distributed free of charge, it is initially disabled so that users cannot run the application without first obtaining a license from the seller of the application. It may be. This license may be obtained by initiating a commerce with one or more of the service providers 640. For example, application 655a may be a desktop publishing application that an end user would like to use for two hours to design a card or brochure. When the end user opens the application 655a, the end user is informed that the end user must purchase a license to use the application. For example, a dialog box may appear listing properties and prices of licensing functions for various uses.

The license can be for a specified time, for example, for one hour or one day. The license may expire when the application terminates, or the license may remain active until the term expires. The license may be based on an action or task that allows an end user to complete one or more tasks or to access one or more desired functions. The additional functions to be used may increase the cost of the license. As aspects of the present invention are not limited in this respect, it will be appreciated that a license with any desired condition may be negotiated.

If the end user has selected a license option, the end user may be instructed to select an identity provider and / or payment provider, or one or the other may be selected by default to initiate an online transaction. This transaction may be substantially processed by the commerce software 685 as described in any of the above or below embodiments. When the service provider receives a payment token from one of the payment providers 620, the service provider may transmit a license in accordance with the terms agreed upon at the commencement of the transaction.

The received license can be handled by a generic license service 690 so that appropriate accessibility to the application can be invoked. The generic license service may then issue an enable key to the application 655 so that the user can execute the software and use its functions according to the license. This enable key may contain any information that an application may need to provide the necessary services during the period indicated in the license. The enable key may include a password provided by the service provider so that the application knows that the license is valid and / or may only rely on a representation from the generic license service 690 that a valid license has been obtained. Can be. If the application is running, the metering engine 694 may be notified to track the time and to inform the application when the license has expired. As another alternative, the application program can be programmed to periodically query the metrology engine and disable itself when the license has expired. In addition, if the license includes a deadline, by querying the metrology engine, the application can provide periodic alerts or updates to the user regarding the amount of time remaining in the purchased license.

When the end user finishes, the end user may wish to select a printing option to print the finished product professionally and initiate another online transaction, such as the transaction described in connection with FIG. Prepaid licenses can provide users with much more flexibility and can provide access to software that they have not previously accessed due to the cost of purchasing a software package with a lifetime license. In addition, software vendors may use revenue from users who are not willing to pay the full retail price but are willing to pay for limited use and / or limited functionality.

Software piracy affects revenue across the entire software industry. Users of unlicensed software lose a relatively significant amount of money each year. When a software product is purchased, the seller has little control over where the software is installed and how many computers it is installed on. The illegal provision of software for download over the Internet provides a much more prevalent way of distributing and acquiring software that is not paid by the end user. Applicant is well aware that providing a relatively secure and simple commerce framework with a prepaid license scheme, for example, the framework described in the embodiment shown in FIG. 6, can mitigate or eliminate copyright infringement issues. . Since the software is distributed free of charge by the seller, the end user can divert the software in any way he deems appropriate. Because the software is only enabled by paying for a term license or a task license, the end user is severely limited to being able to exploit the software.

As described above, embodiments herein may use a mobile module (eg, a subscriber identity module (SIM)) associated with a specific billing account of a mobile infrastructure or operating system to provide for identification and / or payment. Enable authentication. Unlike general standards for mobile communications (e.g., Global Systems for Mobile communications (GSM), 3rd Generation Partnership Project (3GPP), and other similar protocols) performed in trusted wireless networks, according to embodiments herein Authentication is done via an independent untrusted data network (eg, the Internet). As a result, the embodiments herein address many of the additional security issues imposed by the use of such mobile modules (SIM) in Web Services and other independent network protocol environments. These security issues include, inter alia, determining a trusted network endpoint for authenticating the server, authenticating the client to the mobile device or SIM device, authenticating the user to the SIM device, SIM and authentication server. Authentication, establishment of a secure network connection between the mobile module and the network authentication server, and authentication of the user to the network authentication server.

In addition, in order to be compliant with GSM, 3GPP and other standards, additional requirements are placed on the terminal equipment that will interact with the mobile module or SIM device. More specifically, GSM, 3GPP and other similar standards require that SIMs restrict access to certain types of information, including encryption keys, to mobile terminals. To meet this requirement, embodiments herein provide an abstraction security profile that delegates the processing and decoding and security of certain messages to the SIM device itself. For example, as shown in FIG. 11, firewall 1090 defines a state machine and protocol message that abstracts SIM 1085 from host device 1075 when communicating over an independent network 1060. . More specifically, firewall 1090 is a formal state machine that limits or limits the number and / or order of commands sent from a read driver in host 1075 to SIM 1085 itself. ). Accordingly, SIM device 1080 (eg, cellular telephone, SIM interface, etc. Note that "mobile module" refers to the generic term for "SIM", but is not specifically mentioned otherwise herein. Being used interchangeably), the host device 1075 becomes a peripheral device that conforms to the communication protocol 1055 for the mobile network 1050. The following describes some state machines and protocols used to address some of the additional security requirements and issues summarized above.

Embodiments herein provide for authentication over an untrusted independent network (i.e., a network independent of the wireless module corresponding to the infrastructure or operating system of the mobile module) in terms of the various security levels that a given security token can represent. Define security profile for These include, but are not limited to, device security levels, network security levels, user security levels, and service security levels. Each level has different requirements and procedures for obtaining a security token. As such, as described in more detail below, each security level represents a different authentication level in the security model, each with some requirements and / or assurance. In addition, it should be noted that each security level may or may not be independent of other levels. For example, it may not be necessary to set the device security level before a network or user security level can be achieved, but for proper assurance, this hierarchical procedure may be desirable.

The device security level represents the physical possession of a SIM device, such as a mobile module, for example a cellular telephone. A device token (ie, a SIM security token with a device security level) is generally issued locally by the mobile module or SIM device when the user authenticates properly to the mobile module or SIM device. This requirement for authenticating a user to a mobile module is typically set by the mobile infrastructure or mobile operator. In addition, device authentication is usually performed by a SIM device, but other embodiments may 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 authentication at the device level are also contemplated herein.

In one embodiment, before the device security token is issued, the SIM device requests to authenticate or reveal itself to the client or host computer mobile module. In addition, the lifetime of the device token is generally controlled by the mobile device or the SIM device using a policy set by the mobile infrastructure. In one embodiment, the lifetime or other requirements set by the mobile carrier may be dynamically configured through independent and / or wireless networks. If the device token does not have a lifetime or other limitation, the SIM generally does not require the user to re-authenticate more than once for the mobile module.

The network security level represents an authenticated connection between the mobile module or SIM and the mobile infrastructure or network through an untrusted independent network. Assuming that the unlocked SIM device is accessible by the client or host computer, the network security level can be set without user presence or user interaction. In general, the network security level is single factor authentication that asserts proof of ownership of the SIM device to the mobile infrastructure or mobile carrier. In general, the mobile infrastructure issues network security tokens through an authentication server and through a challenge responsive mechanism before issuing the network security token to a client or host computing device. This network security level token can then be used in subsequent authentication steps, providing transport level security to encrypt and / or sign additional interactions between the client and the authentication server and / or the mobile infrastructure.

FIG. 7A illustrates an independent network 700 configured to issue a network level security token to establish transport level security communication between a client and an authentication server. In general, the client or host computing device 710 (which may be a personal computer, mobile phone, or other portable or non-mobile computing device) is connected to the mobile infrastructure 720 via the authentication / trust server 715 to the network security token. Initiate the authentication request by sending request 725 (but note that this request may be initiated by another device, such as SIM 705 itself). Normally, this request 725 is not signed when received by the authentication server 715, and the authentication server 715 later passes to the mobile infrastructure 720 to verify that the request is from the authentication server 715. The request can be signed and / or encrypted before sending. The trust server 715 may then query the mobile infrastructure 720 or the mobile carrier for a challenge 730 that is later sent to the mobile module 705. The mobile module 705 generates a challenge response 735 using the secret key 740 shared between it and the mobile infrastructure 720, which is then forwarded to the client 710 ( Note that generally the secret key is associated with the SIM 705 and is set by the mobile carrier 720).

The client 710 uses the challenge response 735 to generate a request security token response, which may also include a SIM identity and challenge 730 for authentication. In general, the client requests the mobile module 705 to sign and / or encrypt the request security token response with other keys, such as the device's shared secret key 740 of the device 705 or the device token of the SIM, but this is necessary or necessary. You may not. This request security token response and challenge response 735 therein can be verified using, for example, a shared secret key 740. Note that, as mentioned above, the request security token response may or may not be signed and / or encrypted with the same key used to generate the challenge response 735. In any case, if mobile infrastructure 720 verifies challenge response 735 (ie, the challenge response is valid and the mobile module has an active billing account), mobile infrastructure 720 and / or authentication server 715 May respond by generating a message that includes a network security token 745 having encrypted session key (s) (signed and / or encrypted using shared secret key 740). This message can be further signed using the authentication server 715's own security token (eg, X.509 certificate, Kerberos certificate, etc.) or using the security token of the mobile infrastructure 720. The client 710 then verifies the signed message and passes the encrypted network session key (s) to the SIM 705 for decryption. Using the shared secret key 740, the mobile module 705 can then return the unencrypted session key (s) 750 to the client 710.

Note that in the above issuance of the network security token 745, the mobile module 705 generally needs an active billing account that is in good standing on the mobile infrastructure 720. Accordingly, upon confirmation of the challenge response 735 and such active billing account information, trust may be established between the SIM 705 and the mobile infrastructure 720 to form a virtual secure channel. The session key (s) 750 are then passed (if necessary) from the mobile module 705 to the software platform or stack of the host computing device 710 and from the mobile carrier 720 to the authentication server 715 (delegate). Pass. The mobile module 705 is in physical proximity to the host computing device 710 (which may be connected to the mobile module via a USB port, Bluetooth, or other wireless or wired connection) and the mobile infrastructure 720 and the authentication server 715. Note the trust relationship between These session key (s) 750 are then used by client 710 and trust server 715 to establish secure communication 755.

Note that there may be a second mode of operation for authenticating mobile module 705, which may be used by mobile infrastructure 720. In this case, client host 710 may request SIM 705 to generate and sign its own challenge (typically in the form of a nonce). The client 710 may then attach this information as part of the device token when requesting the network security token 725 from the trust server 715 or the mobile infrastructure 720. If the mobile carrier 720 can verify that the device token contains a valid challenge response 735, the mobile carrier 720 issues a network token 745 directly, as described above, to determine the session key (s). And send back to client 710 for decryption.

As described in more detail below, this network level security token 745 is typically used to allow client access to an authenticated service token that can be used to request services and / or merchandise from third party services. Required. It should also be noted that, in order to obtain a network token, it is assumed in the above description that the client or host computer device 710 has successfully determined the network endpoint for the authentication server 715 and / or the mobile infrastructure 720. Is that. In addition, assume that client 710 and user (not shown) are already authenticated to SIM device 705. As noted above, network security level token 745 is used in subsequent authentication steps, providing transport level security that encrypts and signs additional interactions between client 710 and trust server 715. The lifetime of network token 745 (and other tokens) is controlled by authentication server 715 or mobile carrier 720. Since the network token 745 functions as a session context between the SIM device 705 and the mobile infrastructure 720, this lifetime may be limited to hours or days, the number of bytes delivered and / or mobile. Only valid if module 705 is properly connected to client 710.

As mentioned above, the user security level is typically determined by providing information stored outside the SIM 705 or the host computing device 710 so that the user can access the network (trust server 715, mobile infrastructure 720, or other). Service). As such, the user security level establishes multifactor authentication based on evidence of possession of the SIM 705 and some external knowledge (eg, username / password) with respect to the network security level. In general, trust server 715 or mobile infrastructure 720 is the only component that issues user level security, but in some cases, third party services may also issue such user tokens. As such, mobile infrastructure 720 (or, optionally, other services) identifies the user via a challenge response mechanism before issuing a user security level token and sending it back to client 710. Note that the user security token is used by the client to sign and / or encrypt the service token request as described below. It may not be advisable for the client to send the user security token to any service other than the trust server (since no other service can normally verify / use it). As with the network token 745, the user token may have a limited lifetime controlled by the mobile carrier 720, by period of time, by the number of bytes transferred, and / or with the mobile module 705. It may be limited by the presence of a connection between clients 710.

7B illustrates an independent network 700 that is configured to issue a user level security token to establish multilevel security communication between the client 710 and the authentication server 715. The user network authentication step allows the mobile carrier 720 (or other server) to verify that the person at the site owns the device 705 at the site. In fact, the user-network phase is a two factor authentication phase and protects the network from distributed denial of service attacks. In addition, this protects the user by preventing the stolen SIM device 705 from being used improperly.

The host computing device 710 may issue a user token request 765, which is sent via the trust server 715 to the mobile infrastructure 720. Normally, this request 765 is not signed when received by the authentication / trust server 715, and the authentication / trust server 715 is then used to verify that the request is from the authentication server 715. The request may be signed and / or encrypted prior to sending the request to the mobile infrastructure 720. The trust server 715 may then query the mobile infrastructure 720 or the mobile carrier for the challenge 770 that is later sent to the mobile module 705. Note that this challenge 770 may be generated using a different algorithm than the challenge 730 used to authenticate the device 705 to the network. The client 710 extracts the challenge 770 from the token message and passes it to the mobile module 705, indicating that this is a user authentication. Accordingly, SIM 705 requests user credential (s) 775 from client 710. The host computer 710 then queries the user 760 for user input 780 and returns it to the mobile module 705. The SIM 705 or client 710 may optionally have to have the user input 780 or credential (s) encrypted with a network security key (ie, previously obtained session key (s) 750). Can be determined.

Using user input 780, mobile module 705 generates a challenge response 785 and returns it to client 710, which may, for example, have a SIM identifier, challenge 770, and the like. Generate and send a request security token response including a challenge response 785. In general, the client 710 requests the mobile module 705 to sign and / or encrypt the request security token response with a network security token 745, a shared secret key 740, or a SIM 705 related key. Similar to the above, the request security token response and challenge response 785 therein can be verified using, for example, a shared secret key 740 or other mobile module 705 related key. Note that, as mentioned above, the request security token response may or may not be signed and / or encrypted with the same key used to generate the challenge response 785. In any case, once mobile infrastructure 720 verifies challenge response 785 (ie, provided user credentials are appropriate), mobile infrastructure 720 and / or authentication server 715 may share shared secret key 740. Or by generating a message including the user security token 795 with encrypted user key (s) that are signed and / or encrypted using other device 705-related keys. This message may also be signed using the authentication server 715's own security token (eg, X.509 certificate, Kerberos certificate, etc.) or using the security token of the mobile infrastructure 720. Client 710 may then verify the signed message and pass the encrypted user session key (s) to SIM 705 for decryption. Using the shared secret key 740 (or, optionally, other key), the mobile module 705 then returns the unencrypted user key (s) 790 to the client 710 and thus the network. User can be authenticated for 792.

The user-network authentication step provides a mechanism by which mobile network operator 720 provides authentication on behalf of a third party service. Similar to the user-network security level, the user-service phase is a multifactor authentication phase and prevents the user 760 from issuing a service token without the user 760 present during at least one authentication phase. There are generally two modes of operation of the authentication server 715 in terms of how the service token is issued. First, if user 760 previously obtained a user token, trust server 715 considers user 760 authenticated (as long as the service token request is properly signed with user tokens 790, 795). ) You can automatically issue a service token. On the other hand, if mobile infrastructure 720 did not issue user tokens 790, 795, user 760 must authenticate in a similar manner as described above for requesting user tokens 795, 790.

7C illustrates how various network entities communicate over an independent network 700 when establishing secure communications between a client 710 and a third party server 728. As described above, the mobile module 705 and the user 760 may authenticate to the mobile carrier system 720, as described above. As such, there is a secure communication between the authentication server 715 and the client 710 upon proper verification of the charging account for the mobile device 705 and authentication of ownership of the mobile module 705 by the user 760. . Trust server 715 (or, in some cases, mobile infrastructure 720) may then be, for example, when client 710 wishes to purchase a service and / or product from third party server 728. In addition, service tokens 724 may be issued for various services. As such, client 710 may issue a service token 726 to the third party server, which third party server then verifies 722 via authentication server 715. Note that third party server 728 may or may not require additional authentication and may use various mechanisms as described above to perform this verification. It should also be noted that the use of the service token 726 establishes secure communication between the client 710 and the third party server 728 as well as the user for one or more services and / or products in a manner similar to that described above. 760 may represent a payment capability.

Note that generally, until the service token is issued to the client 710, the issued security token is useless on any other server except the authentication server 715. This is because the security layer may prevent any external party from properly decoding device tokens, network tokens, or even user tokens, all of which are known only to SIM device 705 and mobile infrastructure 720. This is because it is derived from the root or shared key 740 that exists. In general, after authentication server 715 issues service token 724, any third party 728 web service may use security token 724. It should also be noted that the above security tokens and messages (eg, challenges, challenge responses, etc.) may take on various formats or schemas. For example, tokens and / or messages that may be issued by the carrier 720 that may or may not wish to expose certain elements of the network to SIM communications to intermediate parties may be in XML, binary, or other similar encoding format. Can be.

, Adobe Photoshop, 인쇄 프로그램, 선불제 소프트웨어, 기타)에의 액세스를 허용하 기 위해 사용될 수 있다. 그에 따라, 상기 실시예들은 복수의 호스팅 장치(710) 상의 무료로 배포된 피보호 소프트웨어 또는 컨텐츠(protected software or content)(예를 들어, 음악, 비디오, 게임, 기타)를 잠금 해제하는 데 특히 유익하다. 환언하면, 라이센스는 이제 휴대용 모바일 장치(705)에 연계되며, 이 장치(705)는 상기한 바와 같이 인증되어, 제한된 일련의 컴퓨팅 장치에 연계되지 않은 휴대용 디지털 ID를 가능하게 해줄 수 있다. 그 자체로서, 사용자(760)는 친구의 집에 가서 그의 프로그램 또는 기타 피보호 컨텐츠 전부를 가져올 필요가 없으며, 그 모두는 휴대용 장치(705)를 통해 액세스가능하고 인증된다.The use of portable hardware device 705 for authentication, identification and / or payment verification may be used to provide online or local retail services and / or merchandise (eg, online newspapers, music, software applications, or other merchandise and services). Applications for purchase or running on a local PC or client 710 (e.g. Word

, Adobe Photoshop, print programs, prepaid software, etc.). As such, the embodiments are particularly beneficial for unlocking freely distributed protected software or content (eg, music, video, games, etc.) on a plurality of hosting devices 710. Do. In other words, the license is now associated with the portable mobile device 705, which may be authenticated as described above to enable a portable digital ID that is not associated with a limited set of computing devices. As such, the user 760 does not have to go to a friend's house and bring all of his programs or other protected content, all of which are accessible and authenticated via the portable device 705.

As will be appreciated from the above, an ID token, a payment token, selecting one of a plurality of ID providers, selecting one of a plurality of payment providers, and an end user system, service provider system, ID provider system and Numerous aspects of the invention described herein, including those relating to the presence of commerce software on a payment provider system, may be used independently of one another. In addition, in some embodiments, since aspects of the invention are not limited in this respect, it is understood that all of the above features may be used together, or that a combination or subset of the features described above may be used together in a particular implementation. You will know well.

The above-described embodiments of the present invention can be implemented in any of numerous ways. For example, these embodiments may be implemented using hardware, software, or a combination thereof. When implemented in software, software code may be executed on any suitable processor or collection of processors, whether provided on a single computer or distributed among multiple computers. It will be appreciated that any component or collection of components that performs the functions described above may generally be considered as one or more controllers that control the functions described above. These one or more controllers may be implemented in a number of ways, such as with dedicated hardware programmed to perform the above functions using microcode or software, or with general purpose hardware (eg, one or more processors).

It will be appreciated that the various methods described herein may be coded as software executable on one or more processors using any one of a variety of operating systems or platforms. In addition, such software may be written using any of a number of suitable programming languages and / or conventional programming or scripting tools, and may also be compiled as executable machine code. In this regard, one embodiment of the present invention, when executed on one or more computers or other processes, is a computer readable medium or a plurality of computers encoded with one or more programs for carrying out the method for implementing the various embodiments of the present invention described above. It will be appreciated that the invention relates to readable media (eg, computer memory, one or more floppy disks, compact disks, optical disks, magnetic tape, etc.). These computer readable media or media may be transportable, and thus the program or programs stored thereon may be loaded onto one or more different computers or other processors to implement the various aspects of the invention described above.

It is well understood that the term "program" is used herein in its general sense to refer to any type of computer code or instruction set that can be used to program a computer or other processor to implement the various aspects of the invention described above. Will know. Furthermore, according to one aspect of this embodiment, one or more computer programs that, when executed, do not have to reside on a single computer or processor to perform the methods of the present invention and multiple different computers or to implement various aspects of the present invention. It will be appreciated that it may be distributed in a modular fashion among processors.

Various aspects of the invention may be used alone, in combination, or in various configurations not specifically described in the embodiments described above, and the aspects of the invention described herein may be described in the foregoing description in their application. It is not limited to the details and configurations of components described or illustrated in the drawings. Aspects of the invention enable other embodiments and may be practiced or carried out in various ways. Various aspects of the invention may be implemented in connection with any type of network, cluster, or configuration. There is no limit to the network implementation. Accordingly, the foregoing description and drawings are merely examples.

The use of ordinal terms such as "first", "second", "third", and so forth, to modify a claim element in a claim is, by itself, any priority, priority to another claim element of a claim element. It is merely used as a label to distinguish one claim element from another claim element with the same name to distinguish claim elements without implying the order, or order, or temporal order in which the steps of the method are performed. .

Also, the phraseology and terminology used herein is for the purpose of description and should not be regarded as limiting. The use of “comprising”, “comprising”, or “having”, “containing”, “comprising” and variations thereof herein is intended to refer to the items listed thereafter and their equivalents as well as additional items. It is to encompass.

Claims (190)

To authorize online transactions between buyers and merchants, Providing an identification of the buyer's identity through an identity provider, and Via a payment provider, providing confirmation that the buyer is capable of paying for the transaction, Wherein said ID provider and said payment provider are different network entities. 2. The method of claim 1, further comprising providing identification information through the buyer to facilitate the identity provider to verify the identity of the buyer. 3. The method of claim 2, wherein providing the identity information comprises providing a subscriber identity module (SIM) number, a network address, or a unique hardware identification. . 3. The method of claim 2, wherein providing the ID information includes providing the ID information programmatically through an end user computer associated with the buyer, And the ID information is provided when at least one application running on the end user computer indicates that the buyer intends to make a purchase. The method of claim 1, wherein the step of providing confirmation that the buyer is capable of payment is performed by the payment provider only after the identification of the buyer is confirmed. 6. The method of claim 5, wherein the payment provider uses the ID verification to perform the payment verification. The method of claim 1, wherein the ID provider is a bank or a government agency. The method of claim 1, wherein the identity provider provides identity verification via an identity token to be received by the payment provider, Wherein the payment provider provides payment confirmation via a payment token to be received by the merchant. The method of claim 8, wherein the ID token comprises a predetermined time period during which the ID token can be processed, When the predetermined time period expires, the ID token is considered invalid. The method of claim 8, wherein the payment token comprises a predetermined time period during which the payment token can be processed, When the predetermined time period expires, the payment token is considered invalid. A computer system having a plurality of nodes interconnected through a network, The computer system is configured to conduct an online transaction between a buyer and a merchant, The computer system, A first node configured to provide confirmation of said buyer's ID, and A second node configured to provide confirmation that the buyer is capable of paying for the transaction, And the first node and the second node are associated with different network entities. The method of claim 11, further comprising a buyer node associated with the buyer, And said buyer node is configured to provide ID information to facilitate said first node verifying said buyer's ID. 13. The computer system of claim 12 wherein the buyer node provides a subscriber identity module (SIM) number, a network address, or a unique hardware identification as the identity information. The terminal of claim 12, wherein the buyer node programmatically provides the identification information when the signal for initiating the transaction is issued by at least one application running on an end user computer. A computer system comprising a user computer. 12. The computer system of claim 11 wherein the second node provides confirmation that the buyer is capable of paying only after the first node has verified the buyer's ID. 16. The computer system of claim 15 wherein the second node uses the ID verification to perform the payment verification. 12. 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 method of claim 11, wherein the first node provides ID verification via an identity token to be received by the second node, And the second node provides a payment confirmation via a payment token to be received by the merchant. 19. The method of claim 18, wherein the ID token comprises a predetermined time period during which the ID token can be processed, And when the predetermined time period expires, the ID token is considered invalid. 19. The method of claim 18, wherein the payment token comprises a predetermined time period during which the payment token can be processed, And when the predetermined time period expires, the payment token is considered invalid. As a distributed program that conducts online transactions, The program has a plurality of software components distributed through 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 component of the plurality of software components via the network; The distributed program, A first component installed on a first node, where an end user accesses the network from the first node, and the first component accesses the network in response to an indication for conducting a transaction between the end user and the merchant. Provide an identifier via the identifier associated with the end user and / or the first node; At least one second component of the distributed program installed on at least one second node, the at least one second component configured to receive the identifier and provide confirmation that the end user is capable of paying for the transaction Yes-, and A third component of the distributed program installed on a third node associated with the merchant, the third component configured to receive a confirmation that the end user is capable of payment before continuing the online transaction; Distributed program. The method of claim 21, wherein the at least one second component, An ID component of the distributed program installed on an identifier node associated with at least one ID provider, the ID component providing an ID token that receives the identifier and verifies the end user's ID based on the identifier Configured to-, and A payment component of the distributed program installed on a payment node associated with at least one payment provider, the payment component configured to receive the ID token and provide a payment token based on the ID token, the payment token being the final Including said confirmation that the user is capable of paying. A computer system having a plurality of nodes interconnected through a network, The computer system is configured to facilitate online transactions between a buyer and a merchant providing one or more goods, services, or both, The computer system, A first network device associated with the buyer, the first network device being configured to programmatically issue ID information indicating the buyer when the buyer makes an indication to initiate the transaction, the ID information being the buyer setting Not a password (purchaser established password) -and And a second network device associated with an ID provider, the second network device configured to receive the ID information and issue an ID token to verify the purchaser's ID for the transaction. To authorize online transactions between buyers and merchants, Generating an ID token based on ID information other than a buyer setup password, the identification token providing confirmation of the buyer's ID, and Generating a payment token providing confirmation that the buyer is capable of paying for the transaction. In computing devices in a distributed network environment, validating a mobile module of a portable device over a network independent of the mobile infrastructure's wireless network, thereby allowing a user access to services, goods, or both. In order to authenticate the mobile module (mobile module) to be associated with the billing account (billing account) of the mobile infrastructure, Receiving a request to authenticate a mobile module when attempting to access a service, product, or both, Receiving from the mobile module one or more credentials used by the mobile infrastructure in verifying billing account information of the mobile infrastructure, Transmitting the one or more credentials to the mobile infrastructure via an independent network separate from the wireless network of the mobile infrastructure, and A portable digital ID for controlling access to the service, product, or both by receiving authentication information corresponding to an activation status of the charging account of the mobile module on the mobile infrastructure via the independent network mobile module authentication method comprising the step of enabling a portable digital identity. 27. The method of claim 25, wherein the mobile module is a subscriber identity module (SIM) for the mobile infrastructure, Wherein the one or more credentials include information based on a challenge from the mobile infrastructure and a shared key between the SIM and the mobile infrastructure. 27. The method of claim 26, wherein the SIM is included in hardware other than a wireless transmission device and attached to the computing device via one or more hardwired or wireless ports. 27. The method of claim 26, wherein the SIM is attached directly to the computing device via a special hardware connection specifically designed for the SIM. 27. The method of claim 25, wherein the service, product, or both are requested from a remote service connected to the independent network. 30. The method of claim 29, wherein said independent network comprises the Internet. 31. The computer-readable medium of claim 30, wherein the service, product, or both are freely distributed over the Internet and present on a local computing device, And wherein said authentication of said mobile module enables content of said service, product, or both to be unlocked on said local computing device. The device of claim 25, wherein the service, product, or both are one or more of a software program on the computing device, hardware attached to the computing device, multimedia content for consumption on the computing device, or access to the computing device itself. Mobile module authentication method. 33. The system of claim 32, wherein the service, product or both have multiple levels of available access, Based on the authentication of the mobile device, one or more of the available levels are activated. The contract of claim 25, wherein a contract agreement with a merchant is created for the service, product or both based on the activation state of the mobile module and the mobile infrastructure authenticates the user to the user. Determining whether to require input of one or more user input credentials to If 'yes' in the determining step, the method, Sending a request to the user to enter the one or more user input credentials, and Based on the user input, determining whether the user is authorized to access a protected service. 35. The method of claim 34, wherein the user input credentials are stored in one or more of the server corresponding to the mobile module, the mobile infrastructure, or the merchant. The method of claim 25, wherein if the mobile module is not authenticated by the mobile infrastructure, the method further comprises: Receiving via the independent network a deactivation message to deactivate the mobile module. In a mobile infrastructure in a distributed network environment, the mobile module of the portable device is validated via a network independent of the wireless network of the mobile infrastructure, thereby giving the user access to services, goods, or both. A method of authenticating a mobile module as being associated with a billing account of the mobile infrastructure to permit, Receiving a request to authenticate a mobile module when a user attempts to access a service, product, or both, the mobile module corresponding to a charging account of the mobile infrastructure, the request being distinct from the wireless network of the mobile infrastructure; Received via private, independent network-, Receiving one or more credentials from the mobile module via the independent network, and Based on the verification of the one or more credentials, access to the service, product, or both via two independent networks by sending authentication information corresponding to the activation status for the charging account of the mobile module over the independent networks. Mobile module authentication method comprising the step of enabling a portable digital ID for controlling. 38. The system of claim 37, wherein the mobile module is a subscriber identity module (SIM) for the mobile infrastructure, The method, Transmitting a challenge to the SIM device through the independent network, Receiving a response comprising the challenge and the one or more credentials corresponding to information in a shared key between the SIM and the mobile infrastructure, and Based on the response to the challenge, authenticating an activation state of the SIM according to the information about the charging account. 39. The device of claim 38, wherein the request, the one or more credentials and authentication information are routed to the mobile infrastructure through a trusted server, And the authentication establishes a trusted communication between the SIM and the trusted server. The method of claim 38, wherein the SIM is part of a device that is unable to communicate over a wireless network of the mobile infrastructure. 38. The method of claim 37, wherein the service, product or both are requested from a remote service connected to the independent network. 38. The method of claim 37, wherein said independent network comprises the Internet. 43. The computer-readable medium of claim 42, wherein the service, product, or both are freely distributed over the internet and reside on a local computing device, And wherein said authentication of said mobile module enables content of said service, product, or both to be unlocked on said local computing device. 38. The system of claim 37, wherein the service, product, or both are one or more of a software program on the computing device, hardware attached to the computing device, multimedia content for consumption on the computing device, or access to the computing system itself. Mobile module authentication method. 38. The method of claim 37, wherein based on the activation state of the mobile module, a contract agreement is created with a merchant for the service, product, or both, and the mobile infrastructure allows the user to authenticate the user. Determining whether to require input of one or more user input credentials for If 'yes' in the determining step, the method, Sending a request to the mobile module to prompt the user to enter the one or more user input credentials, and Based on the user input, determining whether the user is authorized to access a protected service. 35. The method of claim 34, wherein the user input credentials are stored in one or more of the server corresponding to the mobile module, the mobile infrastructure, or the merchant. 38. The method of claim 37, wherein if the mobile module is not authenticated by the mobile infrastructure, And sending a deactivation message to deactivate the mobile module over a wireless network of the mobile infrastructure, the independent network, or both. Portable used to interface the mobile module to a local computing machine used to authenticate the mobile module as having a valid billing account for the mobile infrastructure to allow a user access to a service, product, or both. As a device, A case holder that securely holds a mobile module with a billing account in the mobile infrastructure used to verify the mobile module when attempting to access a service, product, or both on a local computing machine, and The portable device, Transmit one or more credentials from the mobile module to the local computing device to authenticate the mobile module to the mobile infrastructure, An interface for receiving authentication information from the local computing device that verifies the status of the accounting account, The interface enables the transmission and reception of information through an independent network separate from the wireless network of the mobile infrastructure, thereby controlling access to the service, goods or both via two independent networks. A portable device that enables portable digital ID. 49. The method of claim 48 wherein the mobile module is a subscriber identity module (SIM) for the mobile infrastructure, And the one or more credentials include information based on a challenge from the mobile infrastructure and a shared key between the SIM and the mobile infrastructure. The apparatus of claim 49, wherein the case holder is hardware other than a wireless transmission device, And the interface allows the portable device to be attached to the local computing device via one or more hardwired or wireless ports. 50. The portable device of claim 49, wherein the independent network comprises the Internet. 50. The device of claim 49, wherein the service, product or both are freely distributed over the internet and present on a local computing device, And wherein said authentication of said mobile module enables the content of said service, product, or both to be unlocked on said local computing device. 50. The system of claim 49, wherein the service, product, or both, are a software program on the local computing device, hardware attached to the local computing device, multimedia content for consumption on the local computing device, or the local computing device itself. A portable device that is one or more of access. 54. The method of claim 53 wherein the service, product or both have multiple levels of available access, Based on the authentication of the mobile device, one or more of the available levels are activated. 50. The portable device of claim 49, wherein the interface is also used to receive user credentials for verifying the user. 56. The portable device of claim 55, wherein the user input credentials are stored in one or more of the server corresponding to the mobile module, the mobile infrastructure, or the merchant. In computing devices in a distributed network environment, free deployment on a computing device configured to authenticate the portable device as being associated with the mobile account's billing account via a network independent of the mobile infrastructure's wireless network. A method of enabling access to a service, product, or both, Receiving at the local computing device one or more freely distributed services, products or both including protected content that only authorized computing devices can access; Receiving from the mobile module one or more credentials used by the mobile infrastructure in verifying billing account information of the mobile infrastructure, Transmitting the one or more credentials to the mobile infrastructure via an independent network separate from the wireless network of the mobile infrastructure, Receiving, via the independent network, authentication information corresponding to an activation state of a charging account of the mobile module on the mobile infrastructure, and Based on the authentication information, receiving a license to allow the local computing device to access at least a portion of the protected content, thereby allowing a portable digital ID to access the protected content. Allowing access to the services, goods, or both on a plurality of different computing devices without limiting the number. 59. The method of claim 57, wherein the freely distributed service, product, or both are received through the independent network or purchased at a store and installed directly on the local computing device. 59. The method of claim 57, wherein the license has a limited lifetime, regardless of whether the mobile module is connected to the local computing machine or both. 58. The method of claim 57, wherein the mobile module is a subscriber identity module (SIM) for the mobile infrastructure, Wherein the one or more credentials include information based on a challenge from the mobile infrastructure and a shared key between the SIM and the mobile infrastructure. 59. The method of claim 57, wherein the SIM is included in hardware other than a wireless transmission device and attached to the computing device via one or more hardwired or wireless ports. 59. The method of claim 57, wherein the SIM is attached directly to the local computing device via a special hardware connection specifically designed for the SIM. 59. The method of claim 57, wherein the service, product, or both are requested to a remote service connected to the independent network. 59. The method of claim 57, wherein said independent network comprises the Internet. 59. The method of claim 57, wherein the service, product, or both are one or more of a software program on the local computing device, hardware attached to the local computing device, or multimedia content for consumption on the local computing device. . 58. The method of claim 57, wherein the service, product, or both have multiple available levels of access, Based on the license, one or more of the available levels are activated. In a computing system connected to a distributed network, using a single portable hardware device to allow access to protected services, products, or both that require single-factor or multifactor authentication As The mobile module is configured to allow a local computing device access to a protected service, product, or both if the mobile module has an active billing account in the mobile infrastructure, which is also configured to authenticate the user in a multifactor process. Transmitting at least one credential to the local computing device requesting access to a protected service, product or both from the at least one credential, wherein the at least one credential for the mobile module is independent of the wireless network of the mobile infrastructure. Sent via-, Receiving, from the local computing device, authentication information corresponding to an activation state for the charging account of the mobile module, and Based on the authentication information, determining whether the protected service, product, or both require additional user authentication, If yes in the determining step, the method, Sending a request for one or more user input credentials to compare with the securely stored version of the user input credentials, and Based on the information about the comparison, determining whether the user is authorized to access the protected service, product, or both to allow. 68. The system of claim 67, wherein the one or more user input credentials are encrypted using a shared key between the mobile module and the mobile infrastructure, The method, Transmitting the encrypted one or more user input credentials to the local computing device for transmission to the mobile infrastructure via the independent network for comparison of the encrypted one or more user input credentials; Receiving information regarding the comparison indicating that the user is properly authenticated to the mobile infrastructure, and Transmitting a license to the local computing device to allow the user access to the protected service, product, or both. 69. The method of claim 68, wherein the license is limited based on lifetime, proximity of the mobile module to the local computing device, or both, Upon expiration of the license, the user and the mobile module need to be reauthenticated to the mobile infrastructure to further access the protected service, product or both. 69. The method of claim 68, wherein the one or more user input credentials relate to a merchant of the product, service, or both, The merchant has a trusted contractual relationship with the mobile infrastructure indicating that the one or more user credentials are required for authentication. 69. The method of claim 68, wherein the protected service, product, or both correspond to an application running on the local computing device connected to the mobile module. 68. The system of claim 67, wherein the protected service, product, or both correspond to an application running on the local computing device connected to the mobile module, Wherein the one or more user input credentials are stored on the local computing device. 68. The system of claim 67, wherein the protected service, product, or both are remotely controlled by a service in the distributed system, Wherein the one or more user input credentials are stored on a remote server. 67. The method of claim 67 wherein the mobile module is a subscriber identity module (SIM), Wherein the one or more credentials are determined based on a challenge from the mobile infrastructure and a shared key between the SIM device and the mobile infrastructure. 75. The method of claim 74, wherein the SIM is included in hardware other than a wireless transmission device and attached to the computing device via one or more hardwired or wireless ports. 75. The method of claim 74, wherein the SIM is attached directly to the local computing device via a special hardware connection specifically designed for the SIM. 68. The method of claim 67, wherein the service, product, or both are one or more of a software program on the local computing device, hardware attached to the local computing device, or multimedia content for consumption on the local computing device. . In a mobile infrastructure connected to a distributed network, a single portable hardware device can be used to allow access to protected services, products, or both that require single-factor or multifactor authentication. As a method, Receiving one or more credentials from a mobile module indicative of a request for access to the protected service, product, or both to allow a local computing device to access the protected service, product, or both, to the mobile module At least one credential is received over an independent network separate from the wireless network of the mobile infrastructure-, Authenticating the mobile module with the one or more credentials to have an active billing account in the mobile infrastructure, which is also configured to authenticate the user in a multifactor process; and Determining whether the protected service, product or both additionally requires user authentication, If yes in the determining step, the method, Sending over the independent network a request for one or more user input credentials for comparison with a securely stored version of the user input credentials, Receiving the at least one user input credential via the independent network, the received at least one user input credential is encrypted using a shared key between the mobile module and the mobile infrastructure; and Based on the comparison of the encrypted one or more user input credentials with the securely stored version of the user input credentials, information indicating the user's authentication is transmitted to the mobile infrastructure to provide the protected service, product or Allowing issuance of a license that provides access to both. 79. The system of claim 78, wherein the license is limited based on lifetime, proximity of the mobile module to the local computing device, or both, Upon expiration of the license, the user and the mobile module need to be reauthenticated to the mobile infrastructure to further access the protected service, product or both. 79. The apparatus of claim 78, wherein the one or more user input credentials relate to a merchant of the product, service, or both, The merchant has a trusted contractual relationship with the mobile infrastructure indicating that the one or more user credentials are required for authentication. 79. The method of claim 78, wherein the protected service, product, or both correspond to an application running on the local computing device connected to the mobile module. 79. The method of claim 78, wherein the mobile module is a subscriber identity module (SIM), Wherein the one or more credentials are determined based on a challenge from the mobile infrastructure and a shared key between the SIM device and the mobile infrastructure. 83. The method of claim 82, wherein the shared key for encrypting the one or more user credentials is different from the shared key used for the one or more credentials from the mobile module. In a distributed system, when connecting the mobile module to the host computer to display the host computer as a peripheral device rather than a mobile terminal subject to the stringent requirements of the mobile operator system, the host computer is disconnected from the mobile operator system. A computing framework used to abstract, Subscriber identity module (SIM) containing information associated with billing accounts for mobile carrier systems, A host computer for connecting the SIM to the mobile carrier system via a network independent of the wireless network of the mobile carrier system to authenticate the charging account information for the SIM; A SIM driver coupled to the host computer for reading information from the SIM for use in authenticating at least the SIM to the mobile carrier system via the independent network, and The SIM and the SIM defining a protocol used to protect the SIM from attack by limiting one or more of a number, sequence, or length of instructions transmitted between the SIM driver and the SIM A computing framework that includes an interface that acts as a firewall between drivers. 85. The computing framework of claim 84, wherein the SIM is connected to the host computer through a wired port, a wireless port, or both. 85. The computing framework of claim 84, wherein said interface is part of a portable device used to connect said SIM to said host computer. 87. The computing framework of claim 86, wherein said portable device is not configured for wireless communication over a network of said mobile operator system. 85. The computing framework of claim 84, wherein said authentication of said SIM over said independent network is used to access said host computing device. 85. The computing framework of claim 84, wherein said authentication of said SIM is used to access a service, a product, or both, provided through said independent network. 85. The system of claim 84, wherein the authentication of the SIM device is for a service, a product, or both associated with a software application provided on the independent network and running on the host computer that is separate from the web browsing application. Computing framework. 85. The computing framework of claim 84, wherein the protocol comprises a formal state machine used to track one or more of the number, order, or length of the communication between the SIM driver and the SIM. . In a computing system associated with a distributed network, the client may be configured to deliver a session key to at least a software stack on the client for one or more of encryption or signing. By establishing secure tunneling between the connected mobile module and the mobile infrastructure associated with the mobile module, thereby establishing transport level secure communications between the client and server over an otherwise unsecured network. , Identifying one or more credentials of the mobile module connected to the host computer, Sending the one or more credentials to a mobile infrastructure for authentication of a valid billing account for the mobile module, wherein the request is sent over an independent network separate from the wireless network corresponding to the mobile infrastructure; and Based on the authentication, receiving a session key from the mobile module for use in transport level secure communication over the independent network between the host computer and a server. 93. The method of claim 92, wherein the mobile module is a subscriber identity module (SIM) for the mobile infrastructure, And wherein the one or more credentials include information based on a challenge from the mobile infrastructure and a shared key between the SIM and the mobile infrastructure. 94. The method of claim 93, wherein the SIM is included in hardware other than a wireless transmission device and attached to the computing device via one or more hardwired or wireless ports. 94. The method of claim 93, wherein said independent network comprises the Internet. 94. The system of claim 93, wherein the server is further configured to: establish a trust relationship with the mobile infrastructure such that the session key is also passed from the mobile infrastructure to the server for the transport level secure communication with the host computer. How to set up transport level secure communications that are part of 97. The method of claim 96, further comprising: 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 Using the another session key for transport level secure communication with the third party server. 98. The method of claim 97, wherein prior to using the another session key to communicate with the third party, Transmitting the another session key and token to the third party server, wherein the third party server verifies the another session key by authenticating the token with the trust server that is part of the framework. , And Based on the authentication of the token, further comprising using the another session key for secure communication with the third party server. 99. The system of claim 98, wherein the third party server is a merchant of services, goods, or both, The user must also be authenticated to the third party server by providing a user input credential. 107. The method of claim 99, wherein authenticating the SIM against the mobile infrastructure by verifying the billing account of the mobile infrastructure is such that a payment fund for the service, product, or both when making a purchase from the merchant. A method for establishing transport level secure communication, which is used as confirmation of a message. 95. The system of claim 93, wherein the session key expires based on one or more of the lifetime of the session key or the number of messages that have been encrypted, signed, or both with the session key, upon expiration of the SIM with the host computer. And to re-authenticate to the mobile infrastructure for further secure communication between the servers. 94. The method of claim 93, wherein said SIM is externally connected to said host computer but remains physically in close proximity to said host computer. 103. The method of claim 102, wherein said physically close is within 10 yards. 107. The method of claim 103, wherein said 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 shared secret between the SIM and the mobile infrastructure. 95. The apparatus of claim 93, wherein the session key is received from the mobile infrastructure while being encrypted by a shared key between the SIM and the mobile infrastructure, Prior to receiving the session key from the SIM, the method includes: Sending the encrypted key to the SIM for decryption using the shared key to provide the session key to the host computer without compromising the shared key. Way. In a mobile infrastructure that is independent of the mobile infrastructure's wireless network or otherwise connected to a distributed network through an insecure network, session keys are sent to a trusted server for one or more of encryption or signing. transport level secure communications between the client and server over an insecure network by establishing secure tunneling between the mobile module connected to the client and the mobile infrastructure to deliver a session key. As a method of setting Receiving at least one credential of a mobile module connected to a host computer, wherein the at least one credential is received via an independent network separate from the 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, sending a session key to a server for use in transport level secure communication over the independent network between the host computer and the server. 107. The method of claim 107, wherein the mobile module is a subscriber identity module (SIM) for the mobile infrastructure, And wherein the one or more credentials include information based on a challenge from the mobile infrastructure and a shared key between the SIM and the mobile infrastructure. 109. The method of claim 108, wherein said independent network comprises the Internet. 109. The system of claim 108, wherein the server is further configured to: establish a trust relationship with the mobile infrastructure such that the session key is also passed from the mobile infrastructure to the server for the transport level secure communication with the host computer. A method of establishing transport level secure communication that is part of it. 109. The method of claim 108, wherein authenticating the SIM against the mobile infrastructure by verifying the billing account of the mobile infrastructure is such that payment payment for the service, product, or both is made when making a purchase from the merchant. A method for establishing transport level secure communication that is used as a confirmation of a fund. 109. The system of claim 108, wherein the session key expires based on one or more of the lifetime of the session key or the number of messages that have been encrypted, signed, or both with the session key, wherein upon expiration the SIM is associated with the host computer. And re-authenticating the mobile infrastructure for further secure communication between the servers. 109. The method of claim 108, wherein the session key is derived from the SIM and the mobile infrastructure based on a shared secret between the SIM and the mobile infrastructure. In a host computer in a distributed computing system, the host computer and the host computer by using a protocol for authenticating a subscriber identity module (SIM) to the mobile infrastructure through a network connection independent of the wireless network associated with the mobile infrastructure. A method of establishing secure communication between servers, Generating a request for a session key comprising a challenged response calculated from a subscription identity module (SIM) attached to a host computer attempting to establish secure communication with the server-the challenge A response is used to authenticate the SIM to the mobile infrastructure that holds the charging status information of the mobile infrastructure-, Sending the request of a session key to the server having a trust relationship with the mobile infrastructure, wherein the request of the session key is sent over a network independent of the wireless network associated with the mobile infrastructure; Receiving a response to the request of a session key, wherein the response includes the session key and is signed, encrypted or both by a mobile infrastructure using a shared key, wherein the SIM responds to the challenge response Indicates that you are properly authorized for the mobile infrastructure using-, Sending the session key to the SIM for verifying using the shared key, which establishes tunneled communication between the SIM and the mobile infrastructure; and Upon verification of the session key, enabling the host computer to use the decrypted session key for secure communication with the server. 117. The method of claim 114 wherein the response to the request of the session key is signed by the server, the mobile infrastructure, or both. 118. The method of claim 114, wherein the challenge response comprises a nonce signed by the SIM using the shared key such that the challenge response is generated by the SIM itself. 118. The method of claim 114, wherein the shared key is associated with a SIM. 117. The method of claim 114, wherein said request of said session key is signed, encrypted, or both, using a token specified by said server. 117. The method of claim 114, wherein said request of said session key is signed, encrypted, or both, using a token associated with said host computer. 118. The method of claim 114, wherein a challenge used by the SIM to generate the challenge response is received prior to sending the challenge response. 119. The method of claim 114, wherein upon authenticating the SIM to the mobile infrastructure, the method further comprises: to authenticate a user to the mobile infrastructure via the independent network, Generating a request of a user token used to authenticate a user to one or more of the mobile infrastructure, the server, or other third party service, Sending the request of the user token to the server over the network independent of the wireless network associated with the mobile infrastructure, Receiving a response to the request of a user token, the challenge comprising a challenge generated from the mobile infrastructure, Indicating that the challenge corresponds to user authentication to send the challenge to the SIM to urge the SIM to request one or more user credentials, Receiving user input specifying the one or more user credentials, which are then passed to the SIM to determine an appropriate challenge response; Sending the challenge response including the one or more user credentials to the server, Receiving the user token signed, encrypted or both using the shared key by the mobile infrastructure indicating that the user has been properly authenticated, Sending the user token to the SIM for verification using the shared key, and Upon verifying the session key, enabling the host computer to use the user token for secure communication with them in subsequent communications to the server or third party service. Way. 126. The method of claim 121, wherein the user token is used to request a service session key sent to a third party service, And the third party service verifies the service session key through the server. 123. The method of claim 122, wherein the service session key is provided by the server in a token separate from the user token when a request from the host computer is made and the user is authenticated with the server. In a mobile operator system in a distributed computing environment, a host computer by using a protocol for authenticating a subscriber identity module (SIM) to the mobile operator system through a network connection independent of the wireless network associated with the mobile operator system. A method of establishing secure communication between a server and A challenge challenge calculated from a subscription identity module (SIM) attached to a host computer attempting to establish secure communication with a server having a trust relationship with the mobile infrastructure corresponding to the SIM. Receiving a request for a session key comprising: the request of the session key is sent over a network independent of a wireless network associated with the mobile infrastructure; Using the challenge response to authenticate the SIM as having a valid billing account in the mobile infrastructure, Secure the session key 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; Sending a response to the host computer that includes the session key to the host computer to enable the attached SIM to verify the session key using the shared key, which is between the SIM and the mobile infrastructure. Establish tunneling communication-, and Transmitting the session key to the server to establish network level secure communication between the server and the host computer. 124. The method of claim 124, wherein said response to said request of said session key is signed by said server, said mobile infrastructure, or both. 124. The method of claim 124, wherein the challenge response comprises a nonce signed by the SIM using the shared key such that the challenge response is generated by the SIM itself. 124. The method of claim 124, wherein the shared key is associated with a SIM. 124. The method of claim 124, wherein said request of said session key is signed, encrypted, or both, using a token specified by said server. 124. The method of claim 124, wherein said request of said session key is signed, encrypted, or both, using a token associated with said host computer. 124. The method of claim 124, wherein a challenge used by the SIM to generate the challenge response is received prior to sending the challenge response. 126. The method of claim 124, wherein upon authenticating the SIM to the mobile infrastructure, the method further comprises: to authenticate a user to the mobile infrastructure via the independent network, Receiving a request of a user token used to authenticate a user to the mobile infrastructure, wherein the request of the user token is received via the network independent of the wireless network; Sending a challenge generated from the mobile infrastructure to request to obtain one or more user credentials for the SIM, Receiving a challenge response including the one or more user credentials, Based on the verification of the one or more user credentials, securing the user token by signing, encrypting, or both using the shared key, indicating that the user has been properly authenticated to the mobile infrastructure. , And Send the user token to the SIM for verification using the shared key to enable the host computer to use the user token for secure communication with them in subsequent communications to the server or third party service. Further comprising the step of setting up a secure communication. In consumer computing devices in distributed systems, establishing a three-way exchange of data between computing devices for consumers, merchants, and payment providers to provide secure commerce for online purchase of services, goods, or both. As a way to, Sending an online request to purchase one or more services, goods or both provided by the merchant, Receiving charging information from the merchant including charges associated with the purchase of the one or more services, goods or both, Sending a request for payment authorization for the cost from a consumer computing device to at least one payment provider, wherein the consumer has a charging account with the at least one payment provider; Receiving a payment token from the at least one payment provider as evidence that the consumer is capable of paying for at least a portion of the one or more services, goods or both, the payment token being the billing of the consumer Uniquely identify a grant of payment for at least a portion of the cost without providing sensitive information about the account- Transmitting the payment token from the consumer computing device to the merchant, wherein the merchant uses the payment token to verify the payment at the payment provider, which makes the merchant difficult to know sensitive information about the accounting account. Still provides secure payment validation-, and Receiving an acknowledgment of the validity of the payment token, which indicates an appropriate transfer of the one or more services, goods or both from the merchant to the consumer. 134. The method of claim 132, wherein the billing information further comprises one or more of a description of the service, a product, or both, an available payment option from the merchant, or merchant related information. . 134. The method of claim 133, wherein the charging information is provided to the at least one payment provider when requesting a payment authorization for the service, product, or both. 134. The payment token of claim 134, wherein the payment token comprises the charging information, the charging information to verify the payment token and match the payment token to a payment authorization request from the consumer. A method of providing secure commerce, in which the provider is signed, encrypted, or both. 138. The security of claim 135, wherein the payment authorization request, the provision of the charging information to the at least one payment provider, and the transfer of the payment token to the merchant is automatically made without interaction from the consumer. How to provide commerce. 134. The method of claim 133, based on the available payment methods provided by the merchant. Providing the consumer with a user interface showing one or more of the available payment methods, Receiving a user input from the consumer to select the at least one payment provider, and Based on the user input, establishing a communication channel between the consumer computing device and the at least one payment provider to request the payment authorization. 134. The method of claim 132, wherein the at least one payment provider is selected based on a default payment provider preset by the consumer. 134. The mobile device of claim 132, wherein the at least one payment provider comprises: a mobile infrastructure having billing account information for a SIM device owned by the consumer, the consumer's credit card company, the consumer's prepay service, or And one of the consumer's bank accounts. 134. The seamless in-band experience of claim 132, wherein the commerce is integrated into a single application that the payment and selection of the service, product, or both are not part of a web browser. Secure commerce provision method. 134. The method of claim 132, wherein the payment token expires after some predetermined period of time, number of uses, or both, set by the at least one payment provider. 134. The method of claim 132, wherein the cost is variable and provided as a range of values in the charging information. 134. The method of claim 132, wherein the payment token is cancelable by the consumer, the at least one payment provider, or both. 134. The system of claim 132, wherein the cost exceeds a predetermined amount allowed by the at least one payment provider, And wherein additional user interaction is required to grant the payment token. 134. The method of claim 132, wherein the payment token is signed or encrypted by the at least one payment provider, or both, Verifying the payment token for the at least one payment provider comprises verifying the signature, the encryption, or both. 134. The system of claim 132, wherein the one or more services, goods, or both, require subscription or multiple payments, Wherein the payment token can be used multiple times for such a payment. 134. The system of claim 132, wherein the one or more services, goods, or both, require subscription or multiple payments, The payment token is valid only for one payment of the subscription or for multiple payments, A method of providing secure commerce in which additional tokens are needed for future payments. In merchant computing devices in distributed systems, secure commerce when enabling the purchase of a service, product, or both by establishing a three-way exchange of data between computing devices for consumers, merchants, and payment providers. As a method of performing Receiving an online request to purchase one or more services, goods or both provided by a merchant, Transmitting to the consumer billing information comprising a cost associated with the purchase of the one or more services, goods or both, Receiving a payment token from the consumer as a proof that the consumer is capable of paying for at least a portion of the one or more services, goods or both, the payment token being added to the billing account of the consumer Uniquely identify an authorization of payment by a payment provider for at least a portion of the cost without providing sensitive information regarding the payment provider; Sending the verification request of the payment token to the payment provider, thereby enabling the merchant to securely verify the payment of at least a portion of the cost while making the merchant obscure the sensitive information about the billing account, and Based on the verification of the payment token, sending an acknowledgment of the validity of the payment token, which indicates a proper transfer of the one or more services, goods or both from the merchant to the consumer. How to perform secure commerce, including. 148. The method of claim 148, wherein the charging information further comprises one or more of a description of the service, a product, or both, an available payment option from the merchant, or merchant related information. . 149. The payment token of claim 149, wherein the payment token comprises the charging information, the charging information to verify the payment token and match the payment token to a payment authorization request from the consumer. A method of performing secured commerce, in which a provider is signed, encrypted, or both. 148. The method of claim 148, wherein the payment token expires after some predetermined period of time, number of uses, or both, set by the payment provider. 148. The method of claim 148, wherein at least a portion of the cost is variable and provided as a range of values in the charging information. 148. The method of claim 148, wherein the payment token is cancelable by the consumer, the payment provider, or both. 148. The system of claim 148, wherein the cost exceeds a predetermined amount allowed by the payment provider, And wherein additional user interaction is required to grant the payment token. 148. The method of claim 148, wherein the one or more services, goods, or both, require subscription or multiple payments, Wherein the payment token can be used multiple times for such a payment. In a payment provider computing device in a distributed system, a payment is made in a commerce for the purchase of a service, product, or both by establishing a three-way exchange of data between the computing devices for the consumer, merchant and payment provider. As a way of permitting, Receiving a request for payment authorization from a consumer who purchases one or more services, goods, or both from a merchant, wherein the request for payment authorization includes billing information for the cost associated with the purchase; Sending a payment token to the consumer as proof that the consumer is capable of paying for the one or more services, goods or both based on the charging account status for the consumer, the payment token being the billing account of the consumer Uniquely identify an authorization to pay for one or more of the services, goods, or both, without providing sensitive information about Receiving a request from the merchant to verify the payment token, and Sending an acknowledgment of the validity of the payment token based on the comparison of the payment token with the charging information from the request for payment authorization, which is for the one or more services, goods or both to the consumer. Indicating that payment is to be provided to the merchant at an appropriate transfer. 158. The method of claim 156, wherein the charging information further comprises one or more of a description of the service, a product, or both, an available payment option from the merchant, or merchant related information. 158. The mobile device of claim 156, wherein the at least one payment provider comprises: a mobile infrastructure having billing account information for a SIM device owned by the consumer, the consumer's credit card company, the consumer's prepay service, or One of the consumer's bank accounts. 162. The method of claim 156, wherein the payment token expires after some predetermined period of time, number of uses, or both, set by the payment provider. 168. The method of claim 156, wherein the cost is variable and provided as a range of values in the charging information. 162. The method of claim 156, wherein the payment token is cancelable by the consumer, the payment provider, or both. 168. The system of claim 156, wherein the cost is above a predetermined amount allowed by the payment provider, The payment authorization method requires additional user interaction to authorize the payment token. 158. The method of claim 156, wherein the payment token is signed or encrypted by the payment provider, or both, Verifying the payment token for the payment provider comprises verifying the signature, the encryption, or both. 162. The system of claim 156, wherein the one or more services, goods, or both require subscription or multiple payments, Wherein the payment token can be used multiple times for such payment. 162. The system of claim 156, wherein the one or more services, goods, or both require subscription or multiple payments, The payment token is valid only for one payment of the subscription or for multiple payments, The payment authorization method in which additional tokens are required for future payments. In a distributed computing system executing online commerce, a method of granting payment based on an electronic bill presentation that maintains a record of the online transaction for auditing, fraud protection and other purposes. As Receiving, at a consumer computing device, an electronic bill containing a description and cost of a purchase of the one or more services, goods or both from a merchant during the online commerce of one or more services, goods or both, and Sending a copy of the electronic invoice to a payment provider to authorize payment of the one or more services, goods or both. 167. The method of claim 166, wherein the one or more portions of the electronic bill are encrypted by the merchant such that the one or more portions are difficult for the consumer, payment provider, or both. 167. The method of claim 167, wherein the one or more portions of the encrypted electronic bill are used for automatic payment federation to one or more business associates of the merchant. 167. The method of claim 166, further comprising: storing a copy of the electronic bill on the consumer computing device, Receiving a payment request from the payment provider corresponding to a payment to the merchant, the payment request comprising a copy of the electronic bill from the merchant; and And comparing the stored copy of the electronic bill with the copy received from the payment provider to audit appropriate payments made to the merchant. 166. The system of claim 166, wherein a copy of the electronic invoice is signed by the merchant, The method, Receiving a payment token from the payment provider to authorize payment of the one or more services, goods or both, the token comprising the signed copy of the electronic invoice; and Sending the payment token to the merchant for authorization of payment, the merchant being able to verify the payment token as coming from the consumer based on the signed copy of the electronic invoice. Payment authorization method. In a distributed computing system implementing online commerce, services from merchants based on electronic bill presentations that maintain records of the online transactions for auditing, fraud protection and other purposes; A method of authorizing payment for goods or both, Receiving, at a payment provider, an electronic bill comprising a description and a cost for the purchase of one or more services, goods or both by the consumer computing device during the online commerce, and And sending a payment token to a consumer that includes a copy of at least a portion of the electronic bill to authorize payment of the one or more services, goods, or both from a merchant. 172. The method of claim 171, wherein the one or more portions of the electronic bill are encrypted by the merchant such that the one or more portions are difficult for the consumer, payment provider, or both. 172. The method of claim 172, wherein the one or more portions of the encrypted electronic bill are used for automatic payment federation to one or more business associates of the merchant. 171. The method of claim 171, further comprising: storing a copy of the electronic bill on the payment provider computing device, Receiving from the merchant a request for payment of a charge corresponding to the one or more services, goods or both, the payment request comprising a copy of at least a portion of the electronic bill from the merchant; 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 proper payment to the merchant. 171. The method of claim 171, wherein a copy of the electronic invoice is signed by the merchant, The method, Sending a payment token to the consumer that includes the signed copy of the electronic invoice, wherein the merchant can use the signed copy to verify that the payment token is part of a commerce initiated between the merchant and the consumer. has exist -, Receiving a request from the merchant to authorize the payment token for the one or more services, goods or both, and Sending the authorization of the validity of the payment token to the merchant to enable the merchant to transfer the one or more services, goods or both to the consumer. In a distributed computing system executing online commerce, a payment authorization is verified based on an electronic bill presentation that maintains a record of the online transaction for auditing, fraud protection and other purposes. As a method, Transmitting an electronic bill to the consumer computing device, the electronic bill including a description and cost of the purchase of the one or more services, goods or both from the merchant during one or more services, goods or both online commerce, and Receiving a payment token comprising at least a portion of the electronic bill to verify that the payment token is part of a commerce initiated between the merchant and the consumer. 176. The method of claim 176, wherein one or more portions of the electronic bill are encrypted by the merchant to make the one or more portions difficult for the consumer, payment provider, or both. 178. The method of claim 177, wherein the one or more portions of the encrypted electronic bill are used for automatic payment federation to one or more business associates of the merchant. . 176. The method of claim 176, further comprising: transmitting the payment token to a payment provider to authorize payment of the one or more services, goods, or both, the token comprising the signed copy of the electronic bill; Receiving a verification of the payment token from the service provider, indicating that the consumer is capable of paying for the one or more services, goods, or both; and Based on the permission, sending the one or more services, goods, or both to the consumer to complete the commerce. In a distributed system, a method of automatically distributing payments to a series of business partners with predefined business relationships based on one payment from a consumer for online commerce, Receive one online payment for the service, product or both provided by a merchant having a contractual business relationship with at least one other business partner who assists in providing at least a portion of the service, product or both. step, Based on the defined contractual relationship, identifying a portion of the one-time online payment as belonging to the at least one business affiliate, and Automatically transferring the portion of the payment to the account of the at least one business affiliate to consolidate payments to them based on trust relationships and policies associated with the merchant and at least one business affiliate. Payment Allocation Method. 181. The method of claim 180, wherein the portion is also identified based on the portion specified in the charging information generated by the merchant presented to the consumer who authorized the one time payment. 181. The method of claim 181, wherein the portion is signed by the merchant to inform the consumer of the payment federation. In a distributed online system that conducts commerce, a method of presenting a payment method to a consumer based on analysis of electronic bills and policies or rules defined by a merchant, consumer, or both, At the consumer device, receiving an electronic invoice comprising information relating to a purchase request for goods, services or both for the merchant, Comparing the information in the electronic bill with one or more predefined rules from the consumer, merchant or both, and Based on the comparison, determining an appropriate action that satisfies the requirements of the one or more predefined rules. 185. The method of claim 183, wherein the one or more predefined rules is a list of available types of payment methods for the merchant, consumer or both, The act of selecting one or more payment methods from the list for presentation to a user. 184. The method of claim 184, wherein the one or more predefined rules limit the type of payment based on a trust relationship with the merchant, Wherein the information in the electronic bill identifies the trust relationship based on a signature, encryption, or both from the merchant. 184. The method of claim 184 wherein the one or more predefined rules limit the type of payment based on the type of payment available to the consumer compared to the type of payment accepted by the merchant. 184. The method of claim 184 wherein the one or more predetermined rules limit the type of payment based on the total cost of the one or more services, goods, or both. 184. The method of claim 184 wherein the information in the electronic bill further includes a rule for the merchant such that the rule for the merchant is compared to a rule for the consumer. 185. The method of claim 188, wherein any conflict between a rule for the merchant and a rule for the consumer is resolved in favor of the merchant or the commerce is canceled. 184. The system of claim 184, wherein the commerce is a pay as you go subscription, Wherein the one or more rules limit the duration of the subscription based on a payment amount, duration, or both.

Images