RU2402814C2 - On-line commercial transactions - Google Patents

Abstract

FIELD: information technology.

SUBSTANCE: three-way data exchange is set up between a seller, a customer and payment provider in a distributed system of secure commercial transactions. The customer sends the seller an online request for purchasing goods and/or services and receives an electronic bill from the seller. The customer sends a copy of the electronic bill to the payment provider for authorisation of payment and receives a payment marker from the payment provider as proof of paying capacity of the customer. The payment marker is encrypted or signed (digital signature). The payment marker is sent from the customer to the seller. The seller authenticates it by sending the payment provider a request. The seller sends confirmation of authenticity of the payment marker to the customer.

EFFECT: safer transaction owing to verification of identification information of a customer and verification of paying capacity of the customer.

39 cl, 13 dwg

Description

FIELD OF THE INVENTION

The present invention relates to network-connected transaction systems and methods for conducting online transactions.

BACKGROUND OF THE INVENTION

The increase in the number of computer systems connected to the network has opened up new possibilities in relation to how corporations and individuals conduct business activities. For example, end users connected to a network (such as the Internet) through a network device such as a computer, personal digital assistant (PDA), cellular telephone, etc., can conduct commercial transactions over the network to purchase services and / or goods, conduct financial transactions, or otherwise conduct commercial and industrial activities or carry out personal transactions over the network. A problem inherent in online transactions is security, especially when the transaction includes the transfer of amounts of money, funds and / or the transfer of financial, personal or other confidential information.

Many traditional online transactions are conducted in accordance with one of two different but interconnected models. Both models use a browser (Web viewer) as an interface for processing information transfer between parties involved in a transaction. In the first model, the seller offers goods or services online (interactively) using a browser. The term "seller" refers here generically to any object offering goods and / or services for purchase. The term “seller” is not used to describe any particular commercial status or to describe a licensed seller, unless specifically indicated. Preferably, the term generically describes a seller or an entity offering goods and / or services for purchase or sale. The term “service provider” is used interchangeably with the term “seller” and, unless otherwise indicated, has the same meaning.

In a traditional online transaction, a seller may have a website that describes, displays or otherwise offers goods and / or services for sale. The end user indicates the desire to buy one or more units of goods or services, usually by selecting the item corresponding to the product using the browser interface. The browser then displays the transaction page, which allows the end user to select one or more payment types and enter the information required to complete the transaction. For example, a transaction-related page displayed through a browser may allow the end user to select a payment type, such as a credit card (for example, VISA, MasterCard, American Express, etc.), and enter transaction-related information, such as a number credit card, card expiration date, etc. The transaction-related page may also request the end user about personal information such as name, billing address, shipping address, etc. The end user then submits the information, and the seller processes the submitted information.

In this first model, the seller usually “owns” the website. That is, the seller maintains the website, is responsible for the content, and accepts and processes the information related to the transaction provided by the end user. The seller can set up an account for the end user before conducting the first transaction, and the end user can then access this account using the user name and password set by the user each time the end user conducts a transaction with the seller. That is, the end user usually selects the login name and password to be used in subsequent sessions or transactions. After the end user has submitted the information requested using the transaction-related page (s), the seller processes the information to make sure that the information is sufficient to complete the transaction. For example, the seller can verify that the credit card number is valid and has sufficient funds to cover the cost of goods and / or services.

The second model usually includes a third-party transaction provider (“third party”), which processes the payment portion of the transaction. A third party forms a relationship with both the end user and the seller. In particular, the end user can set up an account for a third party, which can be accessed using a login name and password, as discussed above. To establish an account, the end user may provide personal and billing information to a third party (i.e., the end user may provide personal information and billing information that identifies the user, such as one or more credit card numbers, one or more expiration dates, etc. .). The end user can also set up an account of the electronic payment transfer system by providing funds to a third-party transaction provider, the balance of which can be used to purchase goods and / or services online. A third party archives the account information provided by the end user and / or maintains the balance of payments of the end user.

A third party also establishes a relationship with the seller, with the third party processing the payment regarding the transaction. In particular, a third party agrees to make payments to the seller when the end user, with an account (s), requests a transfer of funds to complete the purchase. The seller can provide the possibility of using a third party by signaling the availability of such a possible option on his website, where goods and services are sold. For example, when a user visits the seller’s website and decides to make a purchase, the user may then be presented with a possible payment option using a third-party transaction provider.

When the end user chooses the option to pay for the purchase using a third-party transaction provider, the end-user’s browser is redirected to a website owned by a third-party transaction provider. The end user then logs into his account using a combination of registration name / password and selects the type of payment (for example, credit card) to use in the transaction, or requests a transfer of funds from the user's financial account to the seller’s account. Once the seller determines that the payment has been properly transferred by the transaction provider, the seller can proceed to send the purchased goods or provide the purchased service to the end user. In the second model, the third party is responsible for maintaining the personal and financial information of the end user and for processing the transaction.

BRIEF DESCRIPTION OF THE DRAWINGS

In the drawings, each same or substantially the same component, which is illustrated in various drawings, is represented by the same reference position. For clarity, not all components may be indicated on each drawing. The drawings show the following:

FIG. 1 is an illustration, in accordance with one embodiment of the invention, of a block diagram of a network-connected computing system for performing online transactions;

FIG. 2 is an illustration of a system diagram and method for initiating and performing verification of identification information (a set of personal attributes of an object on a network) in an online transaction, in accordance with one embodiment of the invention;

FIG. 3 is an illustration of a diagram of a system and method for negotiating payment, verification, and / or certification conditions in an online transaction, in accordance with one embodiment of the invention;

FIG. 4 is an illustration, in accordance with one embodiment of the present invention, of a network computer system for conducting online transactions, the transactions being processed at least in part by transaction software installed on networked computers;

FIG. 5 is, in accordance with another embodiment of the present invention, an illustration of a network-connected computing system for conducting online transactions, the transactions being processed, at least in part, by transaction software installed on network-connected computers;

FIG. 6 is, in accordance with one embodiment of the present invention, an illustration of a network-connected computing system for licensing applications installed on an end-user computer, the license being obtained through a network transaction;

FIG. 7A is an illustration of a system used to authenticate a mobile communication module with a network to establish secure communication with it, in accordance with exemplary embodiments;

FIG. 7B is an illustration of a system used to authenticate a user to a network using a mobile communication module when establishing a secure communication channel in accordance with exemplary embodiments;

FIG. 7C is an illustration of a system configured to single or multi-tier verification of many different services using a mobile communication module, in accordance with exemplary embodiments;

FIG. 8 is an illustration of a tripartite secure payment information exchange and federation (or integration if there are loosely coupled entities) of payments in accordance with exemplary embodiments;

FIG. 9 is an illustration of various applications of the commercial transaction subsystem and invoice presentation in accordance with exemplary embodiments;

FIG. 10 is an illustration of the use of payment options and rules to determine which payment provider should be used for a commercial transaction, in accordance with exemplary embodiments; and

FIG. 11 is an illustration of a subscriber identity module (SIM) device configured with a security system (firewall) to conform to established radio network protocols if used for commercial transactions in accordance with exemplary embodiments.

SUMMARY OF THE INVENTION

Traditional online transactions, such as purchasing goods and / or services online, are vulnerable to security breaches, resulting in the loss of personal, financial, and / or other confidential information. In addition, in an untrusted network (for example, the Internet), both sellers and buyers risk entering into a transaction with a bad agent, so that one side of the purchase agreement is not satisfied. Traditional online transaction models may also require that the seller create archives of customer confidential information, and may require that they process the payment aspects of the transaction. In addition, traditional online transaction models are inconvenient for the buyer and represent a generally unintuitive transaction practice. For example, traditional online transactions are conducted using a browser using a login / password paradigm, which is misleading and difficult to manage.

The Applicant has determined that transferring at least a number of transaction-related obligations processed in traditional models by the buyer and the browser to lower-level systems (and other than the browser and the end user) may contribute to a simpler and more secure structure of an online commercial transaction . For example, one or more transactions-related tasks can be processed through the operating system on the side of either the end user or the seller, or both, where the information can be more reliably protected. By embedding one or more tasks in the operating system, users can be freed from some obligation to transfer transactional information, which makes the work practice more intuitive and increases security. In addition, the seller may be exempted from maintaining the buyer's information, processing payment information and / or processing the transaction.

The applicant also found that the difficulties associated with verifying the authenticity of the buyer's identification information can be reduced by using technologies that are more secure and convenient than the registration name / password model. In one embodiment, customer identification information is provided through a subscriber identity module (SIM) card that stores end-user identification information that can be issued programmatically, creating a less confusing and more direct purchase practice. In addition, embodiments of the document include protocols, methods, computing systems, and other mechanisms capable of single or multi-level authentication using a SIM device or otherwise untrusted or insecure network (e.g., the Internet).

The applicant has also found that providing various transaction-related elements of online commercial transactions using generally uninterested third parties reduces the risks for both the buyer and seller. In one aspect of the invention, a commercial transaction system is provided in which the first object in the network verifies the identity of the buyer, and the other object in the network verifies the user's ability to pay for the purchase, so that both the seller and the buyer who are external to each other can transaction in relative safety.

In addition, other embodiments allow for a tripartite secure commercial transaction between the seller, consumer and (supplier) payment in such a way that confidential payment account information is opaque to the seller or third parties. In such an embodiment, the payment tokens are transmitted through the consumer between the payment provider and the seller. Such payment tokens are encrypted or signed (digitally signed) in such a way that the seller and the rest do not control or receive any confidential consumer account information. Nevertheless, the seller can still confidentially verify the validity of the payment token indicating the solvency of the consumer to pay for the services and / or goods provided.

In another embodiment, electronic billing information is used to authorize payment, auditing, and other purposes. In this embodiment, various objects in the network (e.g., consumer, seller, payment provider, etc.) are provided with a machine-readable electronic representation of the invoice, which is used to automatically request and verify the validity of a payment in an online commercial transaction, create a transaction history, present more accurate description of paid for services / goods and for other purposes. This invoice information can also be used to federate lump-sum payments from a consumer to various seller business partners. For example, a seller may have contractual relationships with various business partners that provide services and / or goods in a commercial transaction. Information on electronic submission of an invoice may include such portions of payments that should be distributed between different partners so that payment federation can occur automatically without any need for interaction with the user or separate control and payment mechanisms.

At the same time, mechanisms are also provided for automated decision-making of a commercial transaction using the rules or restrictions set by any number of objects in the network, including the consumer, seller, payment provider, etc. For example, the payment options accepted by the seller can be compared with the payment options available to the consumer. Based on such a comparison, only those possible options that coincide can be presented to the consumer. Alternatively, a payment option may be automatically selected based on such a comparison and / or based on additional rules or restrictions. For example, a consumer may limit the type of payment based on established trust with the seller. Of course, there can be many other types of rules and / or restrictions that define the various actions that can occur in a commercial transaction.

DETAILED DESCRIPTION OF THE INVENTION

Traditional models for online commercial transactions are based on a browser as an interface for requesting and submitting personal and financial information between the end user-buyer and the seller or service provider, whether this happens directly through the seller or through a third-party transaction provider. In the first case, the seller is obligated to create and maintain an infrastructure capable of requesting, receiving, maintaining and processing personal and financial information, usually with a certain minimum level of protection. In addition, the seller may be responsible for maintaining the account and account information for each of its customers (which usually includes both confidential personal and financial information).

The buyer must provide personal information (for example, name, address, phone number, etc.) and financial information (for example, debit (payment) and credit card numbers and expiration dates, bank account numbers, etc.), to complete a transaction. At some level, the buyer must trust that the seller is an honest broker and will act with good intentions, using information only in an authorized manner. Similarly, the seller must trust that the buyer is who he represents and that the payment information provided is truly related to the end user making the purchase. There can be no reliable way for the seller to verify the accuracy of the buyer's identification information and / or the accuracy of the payment information. In a distributed network environment, buyers may be forced to rely on the seller’s reputation, which may limit the sources from which the buyer wishes to conduct transactions. The seller may be forced to act even with less conviction that the buyer is a bona fide, guaranteed against dishonesty buyer. In an untrusted network, this model may present inappropriate risks on one or both sides.

Even when an established and well-deserved trust has been created between the buyer and the seller, seller-maintained databases storing information about the buyer can be sensitive to hacking, theft of information and even bad agents in an otherwise honest and trustworthy business. Third-party transaction providers are also vulnerable to electronic theft, security breaches, etc. More sophisticated spyware programs allow attackers to record keystrokes and take snapshots of computer screens that have been unauthorizedly opened, making browser-based transactions particularly vulnerable to electronic theft. Accordingly, customers conducting online business transactions in accordance with traditional methods and models may be vulnerable to the distribution and misuse of their confidential personal and financial information.

Traditional commercial transaction models typically require the buyer to set up an account with each seller with whom the buyer wishes to conduct a commercial transaction. In general, the account is secure and is accessed using a login name and password, requiring the buyer to manage many login names and passwords and support which account name / password combination matches which account. Some customers may resort to storing their login / password combinations locally on their computer, or using the same login / password combination for all accounts. Both attempts to manage many accounts are vulnerable to theft, hacking and / or other security breaches.

For example, the buyer risks violating all of his accounts if the only combination of registration name / password is obtained by electronic theft. In addition to their own security risks associated with traditional login / password paradigms, customers may find the account login name procedure an inconvenient transaction practice. In particular, the need to register with an account when a purchase is desired makes the transaction less convenient, because the buyer must somehow generate this information before the transaction can be completed. In addition, with the help of third-party transaction providers, the buyer is redirected from the seller’s website to the website of the third-party transaction provider. This step is not intuitive and at best for the buyer is cumbersome and confusing.

The Applicant has determined that transferring at least a number of transaction-related duties handled by the buyer and the browser in traditional models to lower-level systems (and other than the browser and the end user) may contribute to a simpler and more secure structure of an online commercial transaction . In one embodiment, one or more transaction related tasks are processed by the operating system on the side of either the end user, the seller, or both, where the information can be more reliably protected. By embedding one or more tasks in the operating system, users can be freed from some responsibility to transfer transactional information, making work practices more intuitive and increasing security. In addition, the seller may be exempted from maintaining the buyer's information, maintaining payment information and / or processing the transaction.

The applicant further assessed that the difficulties associated with verifying the authenticity of user identification information can be reduced by using technologies that are more secure and convenient than the registration name / password model. In one embodiment, customer identification information is provided through a subscriber identity module card (SIM) storing end-user identification information that can be issued programmatically. In another embodiment, the identification information is provided by means of a microprocessor card (smart card) integrated or otherwise connected to a network device from which a customer conducts an online business transaction. The use of any identification tool based on various microcircuits or cards allows the buyer to associate their identification information with a specific device, such as a cellular telephone or network computer.

The term "programmable" and / or "automatically" refers to actions performed essentially without involving a manual action or operator action. In particular, “programmable” or “automatic” refers to actions initiated and / or performed by one or more computer programs. For example, providing identification information by requesting a user (eg, a customer) to provide registration name and / or password information will not be considered programmable, since the substance of the action is performed by the user. However, an action in which identification information (for example, SIM number, network address, hardware identifier (ID), etc.) the program issues without asking the user to enter information will be considered programmable. It should be noted that such automatic operations can be carried out using either software or hardware components.

The applicant further appreciated that the distribution across various network devices of various transaction-related elements of online commercial transactions contributes to more secure commercial transactions over an untrusted network. In one embodiment, the identity provider and the payment provider, both separate from the network and separate from the end user, seller, and each other, provide verification support during the commercial transaction. The term "object in the network" refers to the presence in the network and can be a single or a combination of "end user / buyer", "provider of identification information", "payment provider", "seller", etc. An object on the network can be present on the network using one or more network nodes. For example, several network devices can operate under the auspices of a single object on a network, such as an identity provider using many servers for online business or an end user connected to the network via a cell phone and personal computer. An object in a network can be an enterprise, such as a bank or retailer, or an individual, such as an end user.

In one embodiment, various elements of an online transaction are distributed to separate and independent entities in a network. For example, the identity provider may provide verification of the identity in the form of an identification token (sign) that the seller may use to verify the identity of the customer. The identity token may include one or more identity credentials (proof of access) of the end user. An identification token can be issued based on the identification information provided by the end user / buyer, for example, the subscriber number from the SIM card, the network address (for example, identification of the network interface board (NIC), global name (WWN), etc.), registration name information, etc. Similarly, a payment provider can provide end-user solvency verification in the form of a payment token. In addition, the payment provider may conduct payment transactions on behalf of the buyer to pay for the purchase of goods and / or services from the seller. The above structure allows, among other things, the buyer and seller, who are third parties, to conduct online commercial transaction in an untrusted network environment in relative secrecy, as discussed in further detail in various exemplary embodiments of the implementation below.

For example, one embodiment provides a three-way, secure connection between a seller, a consumer, and a payment provider during a commercial transaction to purchase services and / or goods, either in an online or retail environment. As will be discussed in more detail below, payment tokens are transmitted from the payment provider to the seller through the consumer. Such payment tokens provide evidence of consumer solvency for services and / or goods, allowing the seller to verify the accuracy of the token directly with the payment provider. Although such payment tokens uniquely identify authorization of payment for services and / or goods, confidential consumer account information is either not included in the token or otherwise encrypted to be invisible to the seller. Accordingly, the consumer’s confidential information is opaque to the seller, thus allowing the consumer to trustfully buy products from the seller, even when there is no trusted relationship between them.

Additionally, since the seller can verify the validity of the payment token directly with the payment provider, the seller can deliver products with confidence in the consumer's ability to pay for such services and / or goods without supporting financial information about the consumer (for example, information about credit card numbers, account, etc. .). In addition, since the payment provider can verify the authenticity of the payment token on receipt from the consumer, the payment provider can trust the funds to the seller; thus completing a three-way secure business transaction.

As previously mentioned, other embodiments of the disclosed structure move parts of a transaction to more secure subsystems of a computing device (eg, an operating system). This effectively allows for numerous possibilities, including in them: an abstraction model to enable existing applications to provide internal practice of working with a network commercial transaction; additional types of fraud protection; recording and submission of a payment document for control, federation of payments and other purposes of payment or authentication; execution of the (software) code of the service provider for additional protection and seller-specific functional means; multi-level authentication and other features. For example, such an abstraction model allows existing and other applications to provide the user with online purchase and payment capabilities, as if such a transaction occurred directly within the application, although parts of the commercial transaction are performed externally. Examples include catalog purchases (e.g. Amazon, Sears, etc.), direct purchase of multimedia content from a multimedia application, downloading software / games over the network in trial mode and automatically unlocking them using the internal payment model, providing the possibility of payment for subscription-based services such as a simple messaging service via email, etc.

Additionally, in another embodiment, a structure that records and presents electronic payment documents in the above trilateral secure (and other) commercial transactions will be described in more detail below, as a mechanism for additional authentication, control, federated payments and other purposes. In addition, according to the transfer of a commercial transaction to more secure parts of the subsystem, other embodiments enable the seller to execute a specific code on the computer (for example, additional user authentication, payment rules / mechanisms, user practices, etc.) with confidence that such code will not be hacked or otherwise broken. Of course, as described in more detail below, the Applicant has additionally realized other advantageous features by using the abstraction model presented in the document.

In another embodiment, the Applicant also provides a common system and protocol that uses a mobile communication module for secure communication and authentication of identification and payment capabilities for a variety of different services. For example, a subscriber identity module (SIM) (or other similar mobile communication module) can be used to authenticate a user and / or device with a service or server in a multi-level validation environment. In such an embodiment, the mobile communication module (and possibly even the user) are authenticated over a network independent of the infrastructure of the mobile communication network for the mobile communication module. Thus, the system checks the validity of the ownership of the mobile communication module by authenticating the active payment account with the mobile communication infrastructure. This establishes a secure connection with a computing device connected to the mobile communication module and a service (e.g., a web service (WS)) using existing secure communication protocols (e.g., WS-Authentication (WS-authentication), WS-Security (WS-security ) and other similar protocols). Such secure communication can also be used to authenticate the user through other protocols and data exchanges between the mobile communication module and the mobile communication infrastructure, as described in more detail below. Additionally, other embodiments provide a protocol and a state machine that abstract the computing device (used in communications over an independent network) from the mobile communications infrastructure. Accordingly, the mobile communication module itself becomes a mobile communication terminal, and the computing device becomes a peripheral device, thus acting in accordance with the rules of current wireless communication standards such as 3GPP (3rd Generation Communication Systems Partnership Project).

In FIG. 1 illustrates a block diagram of a commercial transaction system 100 comprising a plurality of network nodes, including an end-user (customer) computer 110, a seller computer 140, an identity provider provider computer 120, and a payment provider computer 130. Each of the above nodes may include one or more computing devices interconnected via a network 105. It is understood that the computer of the end user, seller 140, identity provider 120 and payment provider 130 may be associated with an object in the network, such as an individual , company or enterprise. For example, end-user computer 110 is typically associated with an individual using a computer to access resources on a network, and seller computer 140 may be associated with a corporation or enterprise offering goods and / or services for sale. One or more computing devices that form each of the mentioned components in the commercial transaction system 100 may act as an entry point, computing platform and / or transmission medium through which connected objects in a network communicate over the network.

It should be noted that although the embodiments presented herein may be described in an online shopping environment, the embodiments may also be used in a direct retail transaction. For example, the above and the following descriptions of a commercial transaction may apply to a consumer for purchasing goods at a retail store, using payment, identification information, authorization, and other embodiments. Accordingly, the use of online work practices to describe embodiments is intended for illustrative purposes only and is not intended to limit or otherwise narrow the scope of embodiments unless explicitly stated otherwise.

It should also be noted that network 105 can be any type of network in any type of configuration that links nodes and allows nodes connected to the network to communicate. The nodes or devices can be connected to the network via a copper (for example, category 5 cable system) cable, optical connections, radio communications, 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. Network 105 can have any number of devices connected to it and can be a trust (e.g., corporate network) or a non-trusted network (e.g., a local area network / wide area network (LAN / WAN, LAN / WAN), the Internet, etc. ), or a combination of both. Computers connected to the network can be any type of device, including, but not limited to, one device or any combination of devices from a mobile phone, desktop computer, tablet personal computer, server, workstation, etc.

In FIG. 2, in accordance with one embodiment of the invention, a diagram of a system and method for initiating and performing verification of identity information in an online transaction is illustrated, and FIG. 3, in accordance with one embodiment of the invention, a diagram of a system and method for negotiating payment terms, verification, and / or certification in an online transaction is illustrated. The methods may be used singly or in combination to carry out an online transaction between the end user / buyer and seller. In the following description, unless specifically indicated, no distinction is made between an entity in a network and associated network devices. For example, the “identity provider” is used generically to describe the identity provider in the form of an entity (eg, a bank, government agency, agency, etc.) and as a computing device that the entity uses to perform various network functions, such as providing verification of identification information to the end user, or otherwise acting on behalf of the entity. End user computer 110 may place an order 242 to seller 140. Order 242 may be any indication that the end user would like to purchase one or more units of goods and / or services from seller 140. For example, order 242 may be the result of an end user selecting a product or service using a web browser that displays pages that are constantly located on the seller’s website, or may be the result of selecting a possible option from a locally executing application, as described with further details below. As an example of the first case, the seller 140 may provide a website to display or otherwise offer for sale the goods and / or services that it provides, or may provide an online catalog of goods. Order 242 may be of any type indicating that the end user would like to buy one or more units of goods and / or services from seller 140.

As an example of the second case and as an alternative to selecting one or more units of goods and services from the seller’s website, order 242 may come from an application or other program local to end-user computer 110. For example, an end user can create, shape, or edit a document through a word processing application, design a slide show using a presentation application, and / or manage images or graphics for a poster or brochure using an image application. An application may include a possible option under a paragraph of a set of instructions for printing, which allows a document to be printed by a third party, for example, to take advantage of print media that cannot be accessed locally, or otherwise use professional printing services. When a possible option is selected, the application can send order 242 to the seller 140 via the network. It is understood that order 242 can be any indication for the purchase of any product and / or service, since aspects of the invention are not limited in this regard.

In response to order 242, seller 140 may request that end user 110 provide an indication of end-user identification information and / or verification that the end-user is indeed what he should mean (step 205). For example, the seller 140 may not know anything about the source of the order 242 and may be interested in the identification information of the end user and / or the guarantee that the end user does not fraudulently simulate his identification information. Alternatively, seller 140 may send a notification or an indication that a payment for the service is required and require that a payment token be provided. In order to obtain a payment token, it may first be necessary to establish the identification information using the identification token, as described with further details below. In any case, the end user 110 may respond to the request of the seller 140 by engaging the services of the identity provider 120 (step 215).

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

The identity provider 120 uses the identity to locate the identity credentials associated with the end user. For example, identity provider 120 may include a database that stores identity and credentials for a number of end users. Identity information can be used to (organize) the index into a database to obtain the correct identity credentials. Identity provider 120 may be of any type. For example, the identity provider 120 may be a cellular telephone service company that uses the subscriber number provided by the end user SIM card to determine the location of the corresponding identity. In one embodiment, the subscriber number is used to determine the location and receive information provided by the end user while subscribing to a cellular telephone or other device using SIM technology. The identity provider 120 may be a bank, a government agency (such as a vehicle registry (RMV)), or any other means that supports identity or mandates associated with end users.

In response to the identification information provided by the end user, the identification information provider 120 supplies an identification marker to the end user computer 110, which provides authentication of the identification information and / or identification credentials with respect to the end user (step 225). The identification token may be any type of electronic message that another network device can use to authenticate, verify, and / or determine the identity of the end user. For example, an identity token may include end-user identity credentials. Identification credentials may include, but are not limited to, any one or a combination of attributes from a name, date of birth, address, phone number, email address, etc.

The identification token may include an electronic signature from the identity provider 120, verifying that the credentials are valid. Thus, the seller and / or payment provider may trust an uninterested third party (i.e., an identity provider) rather than statements by an arbitrary end user. The identification token can be encrypted before being transmitted over the network and decrypted when received by the desired network device (e.g., merchant, payment provider, etc., as discussed with further details below), to protect against message interceptors on the network. In other embodiments, the payment token is simply an authentication of the end user identification information without accompanying identification information.

The identity provider 120 may transmit the identity token to the end user computer 110 for delivery to the seller 140 (step 235), and / or the identity provider 120 may transmit the identity token directly to the seller 140. The seller 140 may then process the identity token to identify the end user and / or verify that the end user is what he should mean. An identification token can be used to authenticate some end-user information that may affect the transaction. For example, seller 140 may provide a service that requires the end user to be of a certain age. Identity credentials transmitted using an identification token can be used to ensure that the end user is of the appropriate age and satisfies this requirement. Seller 140 may have discounts for specific end users who are frequent buyers, or have accepted a coupon, promotional offer, etc. Vendor 140 may index the end-user database to determine whether the end-user meets the requirements or should otherwise be specifically processed based on the credentials provided.

Optionally, seller 140 may request verification of the identity token by sending a request to identity provider 120 (step 245). The authentication token verification request may include forwarding the identification token from seller 140 to identity information provider 120. Having accepted the request for validation of the identification token, the identity provider 120 can verify the authenticity of the identification token and thus determine whether the identification token is genuine. The identity provider 120 may then forward an identity token to the seller 140 (step 255). Alternatively, the merchant 140 may simply directly confirm the validity of the identification marker (step 265) (for example, assuming the identification marker is valid, or otherwise processing the marker). The response may be returned from the seller 140 to the end-user computer 110, the response may include a message indicating whether the identification token is valid, any applicable discount or promotional offers, and / or any other type of message, since the invention is not is limited in this regard (step 265).

After the seller 140 has processed the identification token and / or received the verification of the identity of the identification token from the identity provider 120, the seller 140 may request that the end user verify or verify the solvency and / or provide an indication of how the end user would like to pay for the goods or services. The merchant 140 may fulfill the request by requesting a payment token (step 305 in FIG. 3). In response to a request for a payment token, the end-user computer 110 may engage the services of a 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 a financial institution, or a third-party intermediary that conducts financial transactions and payment procedures.

End user computer 110 may request a payment token from payment provider 130 (step 315) by transmitting an identification token to payment provider 130. Alternatively, the end user may request a payment token by registering with the payment provider 130 in a manner similar to that discussed in connection with the identity provider 120 (i.e. providing an identifier such as a SIM subscriber number, NIC address, and / or using a combination of registration name / password ) It is understood that the end user may request a payment token in other ways, since the invention is not limited in this regard. In addition, the end user can send purchase information, such as price and purchase details, so that the payment provider can verify that the end user is solvent. However, providing purchase information is not required, as it may not be necessary, or it may be processed in subsequent steps of the transaction.

Payment provider 130 processes an identification token (or other provided identifier) to locate end-user information. For example, a payment provider 130 may access a payment information database based on identification credentials transmitted with an identification token. Payment provider 130 may determine which payment options and options the identified end user has available. The payment provider 130 can then verify that the end user is solvent, and in response generates and transmits the payment token to the end user computer 110 (step 325). The payment token may indicate the solvency of the end user and / or confirmation that the payment provider 130 wishes to process the transaction on behalf of the end user. The end user computer 110 may then forward the payment token to the merchant 140 (step 335).

Seller 140 processes the payment token so that seller 140 is satisfied that the end user is able to pay for goods or services (step 365). For example, merchant 140 may request payment provider 130 to verify the validity of the payment token (steps 345, 355) or may simply verify (verify) its validity itself (step 365) (for example, assuming that the payment token is valid or otherwise processing the token). Seller 140 may then begin the process of delivering goods and / or services to the end user. Since the payment provider 130 may be an uninterested third party, the seller 140 may consider the payment token essentially as a payment and is not required to wait until the transaction has been fully processed.

When the seller deals directly with the end user in traditional transaction models, the seller must ensure that the payment information provided by the end user is correct and sufficient. For example, the merchant may need to pass the provided credit card number through the credit card system to request whether the number is valid, the card is valid, if there are sufficient funds, and / or the card is correctly associated with the identification information provided by the end user. If something is not confirmed, the transaction must be canceled, completed or liquidated. In addition, the completion of the transaction can occur after the end user perceives the completion of the transaction and no longer accesses the network and / or no longer accesses the seller’s website, etc.

The seller may then need to notify the end user that there is a problem with the transaction, and the end user will have to go through the transaction again to fix the problem (for example, by entering the payment information correctly, indicating another card with sufficient funds, etc.). In some cases, the end user may not be notified and the commercial transaction will never be completed.

In the various embodiments discussed in the document, since the payment token will not be issued until the payment information of the end user is correct, sufficient funds will be available, and / or the payment provider will otherwise certify that it will make the payment on behalf of the end user, the seller can continue the transaction immediately. Any inaccuracies in the transaction can be identified in real time and resolved so that all parties can be relatively confident that their expectations are met in relation to the transaction.

In addition, since the payment provider can process a financial transaction (for example, by processing a credit card, transferring funds, etc.), the seller can be exempted from establishing and maintaining the infrastructure necessary, for example, to process credit card numbers, or otherwise process the procedure making payments and transferring funds. In some cases, the payment token acts as a guarantee that the payment provider will transfer the indicated funds, for example by wire transfer or ordering the electronic transfer of funds to the seller. A payment token can also be an assurance that the payment will be made using a non-electronic means, such as a promise to give the seller a check or other negotiable credit document.

From the point of view of the seller, a commercial transaction is essentially risk-free if the end-user identification information and payment verification are processed by third parties and therefore is less susceptible to fraud, fraudulent imitation and even simple errors in the provision of personal and financial information. Consequently, sellers will be more likely to conduct online commercial transactions with unknown end users over an untrusted network. From the point of view of the end user, personal and financial information is constantly located with objects that already support information and / or with end users with whom relations have already been established. End-user confidential personal and financial information does not require disclosure to the seller, reducing the vulnerability of incorrectly used or misappropriated confidential information. As a result, end users will be more likely to conduct commercial transactions with unknown sellers, without worrying about whether the seller is trustworthy or not.

In some traditional commercial transaction models, the identity and payment information is entered by the user and processed by either a third party or a seller. As discussed above, for the user, these models are inconvenient, inefficient and time-consuming. In addition, traditional models pose numerous questions regarding the protection of confidential information of the end user, and also make the seller vulnerable to fraud and / or sensitive to failure of payment by the end user. The Applicant has determined that commercial transaction software installed on each of the computers used in various commercial transactions can reduce or eliminate the risks associated with security and fraud. In addition, many of the actions handled by the end user and seller in traditional models can be performed using commercial transaction software, making the transaction simpler and more intuitive for the end user.

In FIG. 8 illustrates an example of the use of some of the features described above for three-way secure communications and various trust boundaries that can be set during a commercial transaction. As will be described in more detail below, this model takes into account one-time or monthly payments, as well as the federation of payments, so that the service or seller can combine payments intended for smaller companies; thus, providing the customer with the opportunity to pay a one-time payment document. As shown, the distributed system 800 is configured to facilitate a commercial transaction between a consumer 810, a seller 830, and a payment provider 805. A trust boundary 815 separates the seller 830 from the consumer 810 / payment provider 805, so that a trust relationship exists between the payment provider 805 and the consumer 810 or the buyer's computing device (i.e., the consumer has properly identified or authenticated itself for the payment provider using any of mechanisms as described in the document). Accordingly, consumer 810 can use this trust to authorize payment to seller 830 for various types of payments and various types of services.

For example, suppose a seller 830 requires a back up payment for a product (for example, a specialized product that requires a down payment, like a car, computer, etc.) that a consumer 810 wants to buy. However, before requesting payment authorization, the user of the consumer computing device 810 may require proper authentication, as described in the document. Once the user authenticates, the consumer computing device 810 may accordingly request payment from the payment provider 805 through any of various mechanisms, as also described in the document. For example, consumer 810 may provide payment provider with payment and settlement or other request information that is signed or otherwise encrypted using consumer computer system 810. This authenticates the validation request of the proper solvency of the account holder (that is, consumer) (that is, the user has a prepaid account , a credit account, or other payment account, such as a mobile subscription, as described below). If the verification is successful, a payment token is issued and then funds are reserved to guarantee payment. Such a payment token is usually then signed and / or otherwise encrypted by the payment provider (for example, a mobile web server, as described in the document) and transmitted to the client part of the consumer 810. The consumer 810 passes the payment token back to the seller 830, which verifies the validity of the token by relation to the payment provider, and if successful, completes the order.

Once the product is ready for delivery (e.g., a custom product has been created), seller 830 can use the backup payment token to request payment from a payment provider 805. It should be noted that the amount of the request for payment may be different from the reserved amount. However, payment provider 805 verifies the accuracy and returns a response to the payment request to seller 830 and / or consumer 810. If approved, seller 830 may send (or otherwise provide delivery) the order to consumer 810 and receive payment for it. On the other hand, if the payment is declined, or additional interaction with the user is required, the seller 830, the payment provider 805, and / or the consumer 810 can choose which action procedure to take. For example, if the amount requested by seller 830 does not match the reserved funds, payment provider 805 and / or seller 830 may request authorization from consumer 810 for the new amount. Alternatively, the payment provider 805 may require a user input authorizing the transfer of funds regardless of any change in the reserved and requested payment amounts. Of course, other actions and procedures for making a commercial transaction are also considered.

It should be noted that although the above trilateral secure payment mechanism was used to purchase a backup product, a one-time payment can also be applied to other services and / or goods. For example, a one-time payment mechanism can be applied to a program that is ready for immediate download over the network. Alternatively or together, a one-time payment can unlock the various levels of the program that has been downloaded (for example, the student version, the professional version, or other separate functionality). In fact, it is understood that the above one-time payment can be used for various types of purchases, some in a slightly modified form of payment.

For example, let it be understood that consumer 810 wants to establish a subscription for a long-term service with seller 830 (for example, a subscription to a newspaper or magazine, a subscription to a movie, game application, or other goods and / or services provided under the pay-as-you scheme -go ("paying bills on time")). Accordingly, the seller 830 will request the consumer 810 about the payment token, and thus the customer of the consumer 810 can interact with the user, requesting authorization to continue the action, as described in the document. Similar to the above, the consumer 810 digitally signs or otherwise encrypts the payment request (for example, using electronic billing information as described in the document below) and sends such a request to the payment provider 805 (for example, a mobile operator, a company selling credit card goods , third-party service with a prepayment or other type, etc.). He authenticates the request and verifies that the account holder (that is, the consumer or buyer) has sufficient initial funds. If successful, a payment token is issued, signed, and / or otherwise encrypted, and returned to customer 810, which transmits the payment token back to the subscription seller 830. Merchant 830 then verifies the authentication of the token and completes the subscription setup.

It should be noted that usually the payment token is stored at the seller 830 and is periodically used when requesting a subscription payment from the payment provider 805. Accordingly, when processing a monthly payment, the seller 830 retrieves the payment token and sends it to the payment provider 805 to calculate the payment. Payment provider 805 verifies and returns a response to the payment request to seller 830 and / or consumer 810. If an approved response is returned, subscription seller 830 will accept the payment during the next payment cycle on the account of payment provider 805. If the payment request is rejected, despite this, the payment provider 805 and / or seller 830 may respond appropriately. For example, seller 830 (or payment provider 805) may contact (eg, via email) a user or consumer 810 informing them of an unpaid payment. Consumer 810 can then make a one-time payment, as described above, or establish a different monthly payment through the same or different payment provider 805. Of course, seller 830, payment provider 805, and / or consumer 810 may have other rules or requirements for processing these and other payment authorizations, as will be described in more detail below.

As indicated above, other embodiments provide for a consumer lump sum federation 810 for a number of business partners or affiliates with a contractual arrangement. Often, business relationships are complex and require distribution of payments for various services and / or goods provided within a specific business model. For example, when buying a trip from a travel agent 830, a consumer 810 may be provided with a package agreement that includes flight plans, hotel accommodations, transportation services, etc. Seller 830, who typically contracts with many of the (providers) of such services and / or goods, must then keep detailed records of such a commercial transaction in order to make proper payments to its business partners. To reduce the complexity of such accounting and other tasks, the implementation options in the document provide for automatic federation of payments for business partners within a specific type of relationship on a per-transaction basis.

For example, a car rental service (eg, business partner “A” 820) may require payment from seller 830 as part of a holiday package sale. An insurance company (for example, business partner "B" 825) may charge a seller 830 a fee for each current account transaction. Based on the trust boundary of 835 business partners, payments are automatically integrated for each business partner (for example, “A” 820 and “B” 825) when a one-time payment is made to the seller 830. In other words, the consumer 810 or the payment provider 805 makes a one-time payment to the seller 830 ; however, all affiliates with a business relationship may be duly paid according to the confidence border for business model 835. It should be noted that such a payment will usually be linked to an electronic invoice status report, as described in more detail below. More specifically, a different part of the electronic account for input and recording, presentation and other purposes may correspond to which part of the payment should be integrated for each business partner. Additionally, each of these parts can be signed and / or encrypted so that specific payment information is opaque to the consumer 810, payment provider 805, or between various business partners 820, 825, as determined by various trust boundaries 815, 825.

It should be noted that although the aforementioned payment federation model has been described with respect to the practice of a travel agent, there are also other business relationships that may use this embodiment. For example, companies that create products with many components supplied from various sellers, suppliers of products that buy materials for this product and make payments on a per-product basis, payments for multimedia products for which royalties are paid on the basis of each sales, or any other type of business model that provides bundled or otherwise can calculate and make payments to business partners based on "for each product", can also use the option Embodiments disclosed herein. As such, the above use of a travel agent to describe various embodiments is for illustrative purposes only and is not intended to limit or otherwise narrow the embodiments described herein.

In FIG. 4 illustrates a network computing system for processing commercial transactions in accordance with one embodiment of the present invention. The network computing system 400 may be similar to the computing system 100 illustrated in FIG. 1. However, in FIG. 4, each of the computers in system 400 includes 485 commercial transactions on-premises software installations. In particular, the end user or consumer computer 410, identity provider 420, payment provider 430, and seller 440 includes commercial transaction software 485a-485d, respectively. The commercial transaction software locally installed in each of the computers in the system can be the same, or it can be configured for a specific computer, taking into account what role (s) the computer plays in the transaction (that is, whether the computer acts as an end-user node, seller’s node, identity provider node, payment provider node, etc., or some combination of the above). In any case, each installation is configured to communicate with installations on other network computers in order to perform online transactions. For example, each installation may be configured to communicate with installations on networked computers to perform the methods illustrated in FIG. 2 and / or FIG. 3.

In one embodiment, locally installing commercial transaction software 485a on the computer of the identity provider 420 may create an identification token identifying the end user using the end user computer 410. In addition, the commercial transaction software 485a on the computer of the identity provider 420 may send the identification token to the end user, payment provider 430, seller 440, and / or any other computer, because the invention is not limited in this regard. A local installation of commercial transaction software 485b on an end user computer 410 may provide identification information (in order to identify the end user) in response to an instruction to conduct an online transaction between the end user and the seller. A local installation of commercial transaction software 485c installed on the computer of the payment provider 430 can receive an identification token and generate a payment token, verifying end-user solvency (e.g., payment token) for an online transaction. A local installation of commercial transaction software 485d installed on a seller’s computer 440 may receive an end-user solvency verification result before continuing with an online transaction.

In one embodiment, each of the computers in system 400 operates using a local installation of the same or similar operating system 495. For example, each of the computers in system 400 can operate using a Microsoft Windows® operating system from Microsoft. The 485 commercial transaction software may be an operating system subsystem. Thus, various computers used in a commercial transaction communicate in a consistent and well-known manner. Because commercial transaction software communicates directly over the network and processes validation, verification and security, the end user and seller need to know something about each other, and more importantly, they do not need to establish any kind of trust. In addition, since some parts of the transactions are processed by the operating system, almost the entire transaction can be performed essentially invisible to the user, without requiring confused and inconvenient end-user participation.

If commercial computer software is available on each computer, various encryption methods can be used during the transfer of information from one computer to another. In addition, additional security features, such as identification tokens and / or payment tokens, that are valid for a limited period of time, may be included. For example, an identification marker may include a time component that defines the time after which any component receiving and processing the marker should consider it invalid and not consider the marker as confirmation of identification information and / or payment. Commercial transaction software components can programmatically handle any token time constraints. This can prevent later markers obtained by "fishing" from being misused later.

It is understood that commercial transaction software does not have to be part of the operating system, but can be any program or group of programs local to computers participating in a commercial transaction that can communicate with each other over the network. For example, commercial transaction software may be an application developed by a third party that can be installed on computers to operate on or independently of the operating system installed on the computer. The application can be configured to work with any one operating system or with a combination of them so as to be available for computers or devices with a wide range of capabilities and configurations, and is not limited to any specific operating system, processor, command system, etc. .

In FIG. 5 illustrates a commercial transaction initiated by an end user selecting one or more desired goods and / or services, the transaction related purchase components being processed, at least in part, by the transaction software subsystem distributed as part of the operating system of the various computers involved in one or more transactions. An end user connected to the network 505 via an end user computer 510 may execute an application 555. The application 555 may be a browser displaying an enterprise website that offers goods or services for sale. Application 555 may be an application providing an optional opportunity to participate in an online transaction, such as an image editing program that allows users to manage images.

The end user using the application 555 can select one or more products or services to purchase. For example, an end user may wish to have an edited image professionally printed on photographic quality paper. Application 555 may include such an option under a set of instructions for printing. As a result of the selection, the print command can form a rectangular area or a dialog box displaying a list of all available possible print options, including network-accessible services. For example, a print team may display a list of service providers 540a, 540b, and 540c as options for providing a print service. When the user selects one of the service providers, an online business transaction can be initiated, as described above. In particular, the service provider may request that the end user provide an identification token. In response, application 555 (or an application embedded in commercial transaction software 585) may generate a dialog box or interface displaying a list of available identity providers. For example, as described in more detail below, the dialog box may display a list of identity providers 520a, 520b and 520c, respectively, as possible identity providers that the user can select to conduct authentication verification.

In FIG. 9 illustrates the use of a trusted commercial subsystem and other capabilities in a distributed system and in accordance with exemplary embodiments. As shown, the local computing device 920 in the distributed system 900 is configured to provide an online or local retail transaction in accordance with the embodiments described herein. It should be noted that although the trusted subsystem 965 commercial transactions is shown only as part of the local computing device 920, such subsystems can also reside on other objects in the network. Additionally, it should be noted that although various components or modules can be described as residing on any particular object in the network, such components or modules can be distributed throughout the computing system and can reside on any number of objects in the network (i.e., parts can be present at one or more objects on the network). Accordingly, the specific “aesthetic” layout and use of a particular module by means of a network device or object is used in the document for illustrative purposes only and is not intended to limit or otherwise narrow the scope of the embodiments.

Regardless of the distribution and “aesthetic” layout of the computing system 900, as previously described, there is a confidence boundary 906 that separates the trust relationships between the various components. Although the relationships can be divided in various ways, in the present example, trust relationships exist between the payment provider 990 and the trusted commercial transaction subsystem 965. This predominantly allows for many features that existing commercial systems cannot provide. For example, trust boundary 906 abstracts applications 925 from a commercial transaction with a seller. Accordingly, existing and other applications 925 can provide end user 940 with internal work practices, although almost all of the functionality looks external. For example, in the above example, to enable professional printing of images on photographic quality paper, selecting in the “drop-down” set of commands, verifying the authenticity of identification information, possible payment options and other components to help the user purchase such a service look like part of application 925. Accordingly, the application 925 upon receipt of the input data for the purchase of services and / or goods may create a call 930 purchases in the trusted subsystem 965 commercial transactions and which is then used to form dialog boxes, accept input 935 from user 940, and otherwise automatically interact with seller 905 and / or payment provider 990, as described in the document.

In other words, user 940 need not necessarily trust application 925 or seller 905 in a commercial transaction. Instead, trust is limited to subsystem 965 of the present structure, which reduces the degree or levels of trust necessary for a trusted and secure execution of a commercial transaction. That is, to the details 950 of the user account 940, including the confidential information 955, which the user 950 does not want or considers inconvenient to publicly share (for example, credit card information, personal information, user names / passwords, etc.), access either through direct user input 935 of data into the subsystem 965, or from a secure 960 account information storage 945. As such, applications 925, seller 905, and other components abstract from the financial and other payment and account details 955 of the account, managed by subsystem 965, as described in the document. This is quite different from the modern business transaction models described above, where applications 925 or merchants 905 maintain and manage account information. Accordingly, this and other embodiments described herein advantageously provide additional levels of protection during such commercial transactions. This represents a significantly more manageable trust relationship in order to minimize the number of components or organizations that have access to or affect highly sensitive financial data.

Also shown in FIG. 9 and similar to the tripartite secure commercial transaction described above, the trust boundary 906 also indicates a secure connection between the payment provider and the trusted commercial transaction subsystem 965. Accordingly, the subsystem 965 authenticates with the payment provider 990 in any of the many ways described in the document, allowing secure communication with it. Similar to the above, a local computing device (which can be, as described below, a portable portable device in a local retail transaction, a personal computer in an online transaction, or another similar device, as described in the document) requires various services and / or goods offered by the seller (s) ) 905. In this example, invoice information 910 is supplied to local computing device 920 for authentication, monitoring, and other purposes, as used in the exemplary embodiments. x implementation described in the document. Such invoice information may include, but is not limited to, the cost of goods and / or services, a detailed description of the commercial transaction, seller-specific information 905, payment federation information, type of transaction (e.g., one-time payment, subscription, etc. .) or other types of billing information. The invoice information 910 may also include other information, such as seller restrictions and payment options, as described in more detail below. In one embodiment, the invoice information 910 is an electronic payment document (bill) executed in a machine readable manner, which provides many advantageous features of a given commercial transaction system. For example, one embodiment provides that invoice information 910 may be part of a payment token request 980 (or otherwise delivered in another transfer of information to a payment provider computer 990), as previously described. As such, the invoice information may be used by the payment provider 990 to verify the validity of the payment token 940. More specifically, billing information 910 provided from a consumer or local computing device 920 may be compared with payment token 985 provided from seller 905 in a payment token verification 904. Accordingly, if the invoice information 910 for checking 904 the validity of the payment token is the same as the invoice information 910 from the payment token request 980, the payment provider 990 can be further authenticated with the authenticity of the payment token 985 and the seller’s validity.

It should be noted that the way in which the information 910 submission of the invoice from the seller is transmitted to the payment provider 990 (as well as other components in it) may vary. For example, invoice information 910 sent from seller 905 to payment provider 990 may be a copy of invoice information 910 sent to trusted commercial transaction subsystem 965 or client 920. Alternatively, or together, invoice information 910 may be signed and / or an encrypted version from a payment provider 990 routed through a consumer or local computing device 920. In any case, the payment provider may perform the comparison described above for authentication token 985 payment.

Additionally, it should be noted that such invoice information 910, as used by the payment provider 990, can also be used to provide a more detailed description of the account-related charges, which will subsequently be presented to the user 940 for charging the user's account. Since this may also be a computer readable invoice 910, the local computing device 920 may correlate the invoice information 910 with a pre-accepted seller 905 to further authorize the payment with respect to the seller 905. In other words, if the invoice information 910 from the payment provider 990 does not match any accepted from the seller 905, then accruals for salary may be considered fraudulent.

In another embodiment, the merchant 905 may use invoice information 910 for control purposes, user authentication and others, payment federation, etc. For example, the seller may sign or otherwise encrypt portions of the invoice information 910. This allows for many advantageous features in the embodiments described herein. For example, invoice information 910 may be part of a payment token 985 received by the payment provider through local computing device 920. The seller 905 may check the accuracy of the invoice information 910 for authentication that the payment token 985 came from a client 920 or a trusted commercial transaction subsystem 965. Similarly, during validation 904 of the payment token, the seller 905 can use the invoice information 910 received from the payment provider 990 to validate or authenticate the payment provider 990 and / or the local computing device 920. In other words, since the invoice information 910 is routed to the provider payment through a subsystem 965 or a consumer 920, billing information received from a payment provider that corresponds to that sent to a client 920 may Confirm the reliability of customer 920 and payment token 985 by the payment provider 990.

It should be noted that in another embodiment, as briefly described above, invoice information 910 can also be used by the seller to federate payments. In this embodiment, the various pieces of invoice information 910 may be machine-readable to determine which parts of the funds from the payment provider 990 (upon successful payment authentication) should be distributed to business partners, as previously described. It should be noted that in this embodiment, portions of invoice information 910 will usually be encrypted or otherwise opaque to user 940 (or customer customer 920), payment provider 990, or other components that are not part of the business relationship with seller 905. This is also unique identifies a business partner in an invoice federation, and thereby can be used for authentication purposes. More specifically, various pieces of invoice information 910 specific to a business partner can be encrypted using a key specifically defined for such a business partner, so invoice information can only be visible to seller 905 and a particular business partner. In other embodiments, however, parts of the account for distribution or federation of payments are signed only by the seller 905 to be opaque to other components in the system 900.

It is understood that other uses of invoice information 910 may be used for various purposes. For example, invoice information 910 may also be used for control purposes, to coordinate distribution of goods, or any other well-known business and other purposes. Accordingly, the above use of invoice information 910 for authorization, identification, payment federation, or any other purpose is used for illustrative purposes only and is not intended to limit or otherwise narrow the scope of the embodiments, unless expressly indicated otherwise.

It should be noted that the confidence boundary 906 and subsystem 965 also have other beneficial features in other embodiments described herein. For example, as shown in FIG. 9, the (software) code 970 of the payment provider within the subsystem 965 allows a secure executable code specifically defined for one or more payment providers 990. Such a code can be used for additional authorization specific to the payment provider, for example, biometric, radio frequency identification (RFID), user name / password, or any numerous additional authentication methods. In other words, due to the trust relationship that payment provider 990 has with subsystem 965, the payment provider may execute a trusted code for its specific business purpose.

The use of such code 970 also allows a more integrated internal user experience that can be managed by a payment provider 990 or any other component that has a trust relationship with subsystem 970. For example, although not shown, trust relationships may exist between some sellers 905 and subsystem 965 so that allow the execution of their trust code by means of subsystem 965. As such, seller 905, payment provider 990, or any other component involved in a commercial transit tion may provide an integrated user experience inner practice that looks inside executable application 925 (an existing or otherwise); however, many events take place externally. For example, in the example of printing images with photographic quality through the professional service mentioned above, dialog boxes, payment options, or any other set of possibilities presented to the user, or application functionality (for example, in response to user data input) can be controlled by code 970, specially provided by various trusted entities on the network (for example, payment provider 990, seller 905, etc.). Accordingly, as will be described in more detail below, this code can also be used when evaluating payment options and other restrictions from the seller 905 and / or the payment provider 990.

As mentioned above, in one embodiment, the selected service provider or seller transfers any requirements to the identity provider together with a request for verification of the identity information. For example, a service provider may be selling goods or services that require a minimum age, or are limited to a specific geographic location. Accordingly, the list of identity providers may be limited to those that can provide identity credentials that meet the requirements of the service provider. For example, the list of identity providers may be limited to those that can provide age verification or current address information, such as RMV.

Similarly, a dialog box may be formed showing a list of options for payment providers. For example, a dialog box may display a list of payment providers 530a, 530b and 530c, which may include, respectively, a credit card trading company offering an electronic debit service bank, or a private third party offering financial transactions. As with the request for identification information, the selected service provider may include any payment requirements associated with the purchase. For example, a service provider can only accept a certain type of credit card. Payment requirements can then be reflected in the list of available payment providers or involved in the payment provider selection dialog box. Once a payment provider has been selected, payment certification may occur and the transaction may be completed.

It should be noted that other embodiments also include comparing seller restrictions (e.g., available payment options, age restrictions, etc.) with consumer rules to determine the various actions that can be taken. In FIG. 10 illustrates an embodiment in which a distributed system 1000 is configured to programmatically determine actions based on circumstances such as seller restrictions 1010 and / or consumer rules 1035. For example, the seller 1020, within the limits of the seller’s restrictions 1010, may specify payment providers 1005 or payment types acceptable for purchasing their services and / or goods. The decision module may then present such restrictions to the user, for example, in a user interface requesting user input 1040 to select one or more available payment options. Based on user input 1040, you can contact the appropriate payment provider 1005 to properly finance services and / or goods. In another embodiment, consumer rules 1035 may also be used in addition to or instead of seller restrictions 1010. For example, consumer rules 1035 may indicate that only certain types of payments can be made for certain types of sellers 1020. More specifically, consumer rules 1035 may indicate that if seller 1020 is unregistered or otherwise insecure, only purchases from seller 1020 may be used. payments that may be reversible.

Of course, as described above, other seller rules 1010 and consumer restrictions 1035 can be used by decision module 1030 to determine the actions that are taken in a commercial transaction. In fact, seller restrictions 1010 and consumer rules 1035 can be compared for compatibility and other purposes. For example, payment options available from seller 1020 may be compared with payment providers 1005, available or accepted by the consumer, when presenting a selection of payment providers 1005 to the user. Of course, a payment can also be selected automatically based on circumstances such as the default setting, ratings or preferences of the supplier, or any other number of settings for possible options. In fact, any number of actions can take place based on the implementation of various rules of seller 1010 and / or consumer 1035. For example, if the rules (seller 1010 or consumer 1035) are unsuccessfully or otherwise violated, additional input from seller 1020 or user 1040 may be necessary (or automatically based on additional rules or settings) to resolve inconsistencies or other inconsistencies. Accordingly, any specific action taken in the implementation of specified restrictions and / or rules is used in the document for illustrative purposes only and is not intended to limit or otherwise narrow the options for implementation presented in the document.

Additionally, it should be noted that, as described above, seller restrictions 1010 may be included in invoice information or delivered separately to the consumer. It should also be noted that a comparison of various rules and actions taken in connection with this can all occur under “shells,” that is, without knowledge of user and / or other system components. In addition, it should be noted that this system is not limited only by the restrictions or rules set by either the consumer or the seller. For example, the payment provider may also set various restrictions, which can also be considered in conjunction with or instead of the rules of the consumer and / or seller. Accordingly, the above use of seller and consumer restrictions to determine various actions (such as possible payment provider options) is used in the document for illustrative purposes only and is not intended to limit or otherwise narrow the options for implementation described in the document, unless explicitly stated otherwise.

In traditional online transactions, it can be difficult for both the end user and / or the service provider to know specifically when the transaction was completed and whether the goods or services were successfully delivered. For example, an end user can choose a software package for download over the network, or an end user can buy songs, movies, or other electronic multimedia works. Sometimes the network connection may be broken before the download over the network can be completed. Under such conditions, the end user may be inclined to choose the goods again, but may doubt, because the end user does not know whether a double purchase fee will be charged from him or her. Similarly, the service provider may not know if the network download was completed successfully, and may double the fee when the user attempts to correct the destruction by selecting the goods again.

The applicant appreciated that providing logging or control capabilities in commercial transaction software could eliminate some uncertainties regarding electronic downloads over the network. For example, the final execution of a possible payment option may depend on the signal or on the means of control that the download is complete. In this case, if the download over the network is interrupted, the end user can verify that the selected payment option failed. For example, the commercial transaction software 585 of FIG. 5 (or other subsystems or components of an object in the network, as described in the document) may include a registration tool that logs in the journal all the various stages of commercial transactions conducted by a computer. Registration information may be used as proof of purchase or otherwise store transaction information. In addition, commercial transaction software 585 may include a network download monitoring tool that sends confirmation of verification of a successful download over the network only after the final payment has been completed. By making the payment dependent on the signal that the transfer of goods or services was successful, the problems of double billing can be resolved and essentially eliminated.

The software was developed by companies to handle a wide variety of tasks, including from well-known tasks of word processing and document processing, spreadsheets, image editing to more specialized tasks such as video editing, computer graphics software, web content development applications ( content), portfolio management software (organizations), etc. However, it can be prohibitively expensive to own software that handles every task that the end user may wish to perform. Software packages can cost from hundreds to thousands, to tens and even hundreds of thousands of dollars to get one license. In addition, the end user may need the services of a particular application only occasionally or from time to time, so the cost of buying an application may not be justified.

The applicant appreciated the benefits of allowing the end user to use the software in a pay-as-you-go environment. In particular, the end user can only be charged for the total time spent on using the application, preferably paying the retail price for the software (in which many features and / or applications would be largely unused). In FIG. 6 illustrates a network computing system with a commercial transaction structure that allows an end user to pay for the time spent using the application. Network computing system 600 comprises a network 605 connecting an end-user node 610 with a plurality of identity providers 620, a plurality of payment providers 630, and a plurality of service providers 640.

The end-user node 610 may be a computer executing the operating system 695. Several software applications 655 may be installed on the end-user computer. Software applications may be supplied with the computer upon purchase, freely downloaded via the network, or otherwise distributed (often free or for nominal fee, or to register with the supplier) seller of the application. Application 655 can be any type of application, and any number of applications can be installed on a computer. Service providers 640 may be associated with one or more applications installed on end-user computer 610. For example, a 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 providers is a license to use the appropriate applications installed on the computer. For example, when software (for example, applications 655) is freely distributed, it can be initially blocked (protected) so that users cannot run the application without first obtaining a license from the seller of the application. A license can be obtained by initiating a commercial transaction with one or more 640 service providers. For example, application 655a may be a desktop publishing application that an end user would like to use for a couple of hours to create a map or brochure. When the end user opens the application 655a, the end user is notified that he must buy a license in order to use the application. For example, a dialog box may appear displaying a list of features and prices for various “for use” licensing options.

A license may be for a specified amount of time, such as an hour or a day. The license may expire as soon as the application has been closed, or the license may remain active until the expiration date. A license may be based on operations or tasks that allow the end user to perform one or more work or apply one or more of the required capabilities. Additional features to be used may increase the cost of the license. It is understood that a license may be contractual with any of the required conditions, since aspects of the invention are not limited in this regard.

Once the end user has selected a possible 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. A transaction may be processed by means of commercial transaction software 685, essentially as described in any embodiment of the preceding or subsequent embodiments. When the service provider receives the payment token from one of the payment providers 620, the service provider may transfer the license in accordance with the conditions agreed upon at the initiation of the transaction.

The accepted license can be processed through the general service of 690 licenses, so that the corresponding accessibility to the application can be activated. The General Licensing Service can then issue an authorization key for application 655 so that the user can run the software and use its functionality in accordance with the license. The authorization key may include any information necessary for the application to provide the necessary services for the period indicated in the license. The enabling key may include a password provided by the service provider, so that the application is notified that the license is valid and / or can simply trust the submission from the general service of 690 licenses that a valid license has been obtained. Once the application is operational, the measurement processor 694 may be notified to track the time and indicate to the application when the license has expired. Alternatively, the application can be programmed to periodically request the measurement processor and then shut down when the license has expired. In addition, by requesting the measuring processor, the application can send the user periodic warnings or updates about the time remaining in the purchased license if the license includes an expiration date.

When the end user has completed the operation, he can choose to receive a professionally printed finished product and selects a print command that initiates another online transaction, such as the transaction described in connection with FIG. 5. A pay-as-you-go license can provide users with much greater adaptability and, with the help of a validity period license, give them access to software that they did not have access to earlier due to the cost of purchasing a software package. In addition, software providers can benefit from revenue from users who do not want to pay the full retail price, but who want to pay for limited use and / or limited functionality.

Software piracy affects profits across the software industry. Unlicensed user software costs businesses a relatively substantial amount each year. Once a software product has been purchased, the seller has little control over where and on how many computers the software is installed. The illegal provision of software for downloading over the Internet provides an even larger way to distribute and receive software for which the end user has not paid. Applicant has found that providing a relatively secure and simple structure of commercial transactions with a pay-as-you-go license, for example, the structure described in the embodiment illustrated in FIG. 6, can reduce or eliminate piracy problems. Since the software is freely distributed by the seller, end-users may (illegally) adapt the software in a way that they consider appropriate. Since the software is provided only by paying a license for a term or a license for a task, end users are significantly limited in their ability to use the software incorrectly.

As previously described, embodiments in the document allow authentication for identification and / or payment purposes using a mobile communication module (eg, a subscriber identity module (SIM)) associated with a particular payment account of a mobile communication infrastructure or operating system. Unlike conventional standards for mobile communications (for example, global mobile communications systems (GSM, GSM), a partnership project of 3rd generation communications systems and other similar protocols), which takes place via a trusted radio network, authentication in accordance with the described embodiments takes place through an independent untrusted data network (for example, the Internet). As a result, the described embodiments solve many of the additional security difficulties imposed by the use of such mobile communication modules (SIM) in the Web service and other independent network protocol environments. Such security challenges include, but are not limited to: determining the endpoint of a trusted network for server authentication; client authentication for a mobile communication module or SIM device; user authentication for the SIM device; SIM authentication and authentication server; establishing a secure network connection between the mobile communication module and the network authentication server; and user authentication for the network authentication server.

In addition, in order to comply with GSM, 3GPP and other standards, additional requirements are imposed on terminal equipment that interacts with a mobile communication module or SIM device. More specifically, GSM, 3GPP and other similar standards require the SIM to restrict access to certain types of information, including encryption keys, for a mobile communication terminal. In order to satisfy these requirements, the described embodiments provide an abstraction of a security profile that transfers the processing and decoding of some messages and security to the SIM device directly. For example, as shown in FIG. 11, the firewall 1090 defines the state machine and protocol messages for abstracting the SIM 1085 from the host device 1075 when communicating over an independent network 1060. More specifically, the firewall 1090 uses a formal state machine that sets a limit or limits the number and / or a sequence of commands sent from the reader driver inside the host 1075 to the SIM 1085 directly. Accordingly, the SIM device 1080 (for example, a cellular telephone, SIM interface, etc. - it should be noted that the "mobile communication module" represents the general term for "SIM", but is used interchangeably in the document, unless specifically stated otherwise ) becomes a mobile communication terminal, and the host device 1075 becomes an external device that complies with the communication protocol 1055 for the mobile communication network 1050. The following describes in more detail some state machines and protocols used to address some of the additional security requirements and factors described above.

The described embodiments define a security profile for authentication over an untrusted independent network (i.e., a network independent of a radio network, corresponding infrastructure of a mobile communication module or an operator system) in terms of various levels of protection that this security token can represent. These include, but are not limited to, the device security level, network security level, user security level and service security level. At each level, there are different requirements and procedures for obtaining a security token. Accordingly, as described in more detail below, each security level represents a different authentication level in the security model, and each has some requirements and / or guarantees. Additionally, it should be noted that each level of protection may or may not be independent of the others. For example, it may not be necessary to set the security level of the device before the security level of the network or user is reached; however, for proper safeguards, such a hierarchical procedure may be desirable.

The device security level indicates the physical ownership of a mobile communication module, such as a SIM device, such as a cellular telephone. A device token (that is, a SIM security token with a device security level) is usually issued locally through a mobile communication module or SIM device with proper user authentication for it. Such user authentication requirements for a mobile communication module are typically established by a mobile communications infrastructure or mobile operator. Additionally, device authentication is typically enforced by the SIM device, however other embodiments may involve the use of other components in the authentication process. For example, a SIM or other device may require a password before a mobile module or other device issues a device token. Of course, the document also addresses other forms of credentials for device-level authentication.

In one embodiment, the SIM device requires the client or host computer to authenticate or identify with the mobile communication module before the device security token is issued. Additionally, the validity period of a device token is typically controlled by a mobile communication module or SIM device using the policy defined by the mobile communications infrastructure. In one embodiment, the validity period or other requirements set by the mobile operator may be dynamically configured through an independent network and / or radio network. If the device token does not have a validity period or other restrictions, usually the SIM does not require the user to re-authenticate for the mobile communication module more than once.

The network security level indicates the authenticated connection between the mobile communications module or SIM and the mobile communications infrastructure or network over an untrusted independent network. The network protection level can be set without the presence of the user or interaction with the user if the unlocked SIM device is accessible to the client or host computer. Usually, the network security level is a one-factor authentication, which confirms the proof of the SIM device’s ownership to the mobile communications infrastructure or operator. Typically, the mobile communications infrastructure will issue a network security token through an authentication server and through a “call answering” mechanism before issuing a network security token to a client computing device or master. This network security level token can then be used in subsequent authentication stages and provides security appropriate to the transport layer to encrypt and / or sign further interactions between the client and the authentication server and / or mobile communications infrastructure.

In FIG. 7A illustrates an independent network 700 configured to provide a network security layer token to establish secure transport layer communications between a client and an authentication server. Typically, a client or master computing device 710 (which may be a personal computer, mobile phone, or other portable or non-mobile computing device) initiates an authentication request by sending a request 725 token network security to the infrastructure 720 mobile communication server 715 authentication / trusted server (it should be noted, however, that the request can also be initiated by another device, such as directly SIM 705). Typically, the request 725 will be unsigned when received by the authentication server 715, which can then sign and / or encrypt the request before sending it to the mobile communications infrastructure 720 to verify that the request has arrived from the authentication server 715. The trusted server 715 can then request the infrastructure 720 of the mobile communication or mobile operator to call 730, which will then be sent to the mobile communication module 705. The mobile communication module 705 uses the secret (secret key) 740 with the mobile communication infrastructure 720 to generate a call response 735, which is then forwarded to the client 710. Typically, the secret will be specific to the SIM 705 and set by the mobile operator 720.

Client 710 will use the call response 735 to generate a response to the security token request, which may also include SIM identification information and call 730 for authentication purposes. Typically, the client will request that the mobile communication module 705 sign and / or encrypt the response to requesting a security token using the corresponding shared secret device 715 740 or another key, such as a SIM device token - although this may or may not be necessary. The response to the request for the security token and the answer 735 to the call can be checked for authenticity using, for example, the shared secret 740. It should be noted, as previously mentioned, that the response to the request for the security token may or may not be signed and / or encrypted using the same key used to generate a response 735 to the call. In any case, if the mobile communication infrastructure 720 confirms the authenticity of the answer 735 to the call (that is, the answer to the call is valid and the mobile communication module has an active billing account), the mobile communication infrastructure 720 and / or the authentication server 715 can respond by generating a message, which contains a network security token 745 with encrypted session key (s) that are signed and / or encrypted using shared secret 740. The message can be additionally signed using zovaniem own protection or authentication server 715 the marker (e.g., certification standard X.509, for Kerberos technology certification, etc.) or using the mobile infrastructure protection token 720. Client 710 may then check the signed message and transmit the encrypted network session key (s) to SIM 705 for decryption. Using the shared secret 740, the mobile communication module 705 can then return the unencrypted session key (s) 750 to the client 710.

It should be noted that in the above issue of the network security token 745 to the mobile communication module 705, an active payment account is usually required in good (financial) condition on the mobile communication infrastructure 720. Accordingly, after verifying the answer 735 to the call and the information of such an active payment account, trust can be established between SIM 705 and mobile communication infrastructure 720, creating a virtual secure channel. The session key (s) 750 are then delegated or transmitted from the mobile communication module 705 to the underlying software or the stack of the host computing device 710 and from the mobile operator 720 to the authentication server 715 (if necessary). It should be noted the physically close proximity of the mobile communication module 705 to the host computing device 710 (which can be connected to it via a universal serial bus (USB, USB) port, Bluetooth, or other wireless or wired connection) and the trust relationship between the mobile communication infrastructure 720 and the server 715 authentication. This session key (s) 750 is then used by client 710 and trusted server 715 to establish secure communication 755.

It should be noted that there may be a second mode of operation for authenticating the mobile communication module 705, which can be used by the mobile communication infrastructure 720. In this case, the client master 710 may request that the SIM 705 form and sign its own call (usually in the form of a Nonce parameter). Client 710 can then attach information as part of a device token when it requests a network security token 725 from a trusted server 715 or mobile infrastructure 720. If the mobile operator 720 can verify that the device token contains a valid call response 735, it can directly issue the network token 745 back to the client 710 to decrypt the session key (s) as described above.

As will be described in more detail below, typically this network layer security token 745 is required to provide a client with access to an authenticated service token, which can be used to request services and / or goods from a third-party service. It should also be noted that in order to obtain a network token, it is assumed above that the client or master device 710 has successfully determined the network endpoint for the authentication server 715 and / or mobile communications infrastructure 720. Additionally, it is assumed that the client 710 and the user (not shown) are already authenticated for the SIM device 705. As described above, the network layer security token 745 is used in subsequent authentication steps and provides appropriate transport layer security to encrypt and sign further interactions between client 710 and trusted server 715. The validity of the network token 745 (and other tokens) is controlled by the authentication server 715 or mobile operator 720. Since the network token 745 is used as a session context between the SIM device 705 and the mobile communication infrastructure 720, the validity period may be limited to hours or days, the number of bytes transferred and / or may be valid only if the mobile communication module 705 is properly connected to the client 710.

As previously mentioned, the user protection level indicates that the user is authenticated for the network (trusted server 715, mobile communications infrastructure 720 or other service), usually according to the provision of information stored outside the SIM 705 or host computing device 710. Accordingly, the user protection level along with the network level of protection establishes multi-factor authentication based on evidence of SIM 705 ownership and some external information (for example, user name / password I). Typically, a trusted server 715 or a mobile communications infrastructure 720 are the only components to provide user level security, however, in some cases, a third-party service may also issue such user tokens. Accordingly, the mobile communications infrastructure 720 (or another service, as the case may be) will check the user through a call answering mechanism before issuing the user level security token back to the client 710. It should be noted that the user security token is used by the client to sign and / or encrypt service token requests as described below. It may not be recommended for a client to send a custom security token to any service other than a trusted server (since usually no other service can verify / use it). As with the aforementioned network token 745, the user token may have a limited validity period controlled by the mobile operator 720 and may be limited by the length of time, the number of bytes transmitted, and / or by means of a connection between the mobile communication unit 705 and the client 710.

In FIG. 7B illustrates an independent network 700 configured to issue a user level security token to establish multi-level secure communication between client 710 and authentication server 715. The user authentication step in the network allows the mobile operator 720 (or another server) to verify that the known person owns the known device 705. Effectively, the user authentication step for the network is a two-factor authentication step and prevents the network from distributed service denial of service attacks. In addition, this protects the user by preventing the improperly stolen SIM device 705 from being used.

The host computing device 710 may issue a request for a user token 765, which is sent to the mobile infrastructure 720 via a trusted server 715. Typically, the request 765 will be unsigned when received by the authentication server 715 / trusted server, which then signs and / or encrypts the request before sending it to a mobile communications infrastructure 720 for verifying that a request has arrived from the authentication server 715. The trusted server 715 may then request the infrastructure 720 of the mobile phone or mobile operator to call 770, which will then be sent to the mobile communication module 705. It should be noted that the call 770 may be generated using an algorithm different from the call 730 used to authenticate the device 705 for the network. Client 710 will extract the call 770 from the token message and transmit it to the mobile communication module 705, indicating that it is user authentication. Accordingly, the SIM 705 will request the user credential (s) 775 from the client 710. The host computer 710 will then request the user 760 to user input 780 and return them to the mobile communication module 705. The SIM 705 or client 710 may optionally decide that user data input 780 or credential (s) should be encrypted using a key (i.e., a pre-received session key (s)) 750 for network security.

Using user input 780, the mobile communication module 705 will generate a response 785 to the call and return it to the client 710, which will generate and send a response to the request for the security token, which includes, for example, a SIM identifier, a call 770 and a call response 785. Typically, the client 710 will request that the mobile communication module 705 sign / or encrypt the response to the security token request together with the network security token 745 using the shared secret key 740, or a key specific to SIM 705. Similar to the above, the response to the request for the security token and the response 785 to the call can be verified using, for example, a shared secret 740 or another key specific to the mobile communication module 705. It should be noted, as previously mentioned, that the response to the request for the security token may or may not be signed and / or encrypted with the same key used to generate the call response 785. In any case, if the mobile communications infrastructure 720 verifies the authenticity of the answer 785 to the call (that is, the provided user credentials are appropriate), the mobile infrastructure 720 and / or the authentication server 715 can respond by generating a message that contains the user security token 795 along with the encrypted ones user keys (s) that are signed and / or encrypted using a shared secret 740 or other device-specific key 705 . The message may be additionally signed using either the native security token of the authentication server 715 (e.g., X.509 certification, Kerberos certification, etc.), or using the security token of the mobile infrastructure 720. Client 710 can then verify the signed message and transmit the encrypted user session key (s) to SIM 705 for decryption. Using a shared secret 740 or other key (as the case may be), the mobile communication module 705 may then return the unencrypted user key (s) 790 to the client 710; thus authenticating the user to network 792.

The user authentication step with respect to the service provides a mechanism for the network operator 720 of the mobile communication network to provide authentication on behalf of a third-party service. Similar to the user protection level for the network, the “user with respect to service” stage is multi-factor authentication and prevents the network from issuing service tokens without the user 760 being present during at least one authentication stage. Typically, there are two modes of operation of the authentication server 715 regarding how service tokens are issued. First, if the user 760 previously received the user token, the trusted server 715 can consider the user 760 as authenticated and automatically issue a service token (provided that the request for the service token is respectively signed with the user token 790, 795). On the other hand, if the mobile communications infrastructure 720 did not issue a user token 790, 795, then the user 760 will be required to authenticate in a manner similar to that described above in order to query the user token 795, 790.

In FIG. 7C illustrates how various objects in a network communicate over an independent network 700 to establish secure communication between a client 710 and a third-party server 728. As mentioned above, the mobile communication device 705 and user 760 can authenticate to the mobile operator system 720, as previously described. Accordingly, there is a secure connection between the authentication server 715 and the client 710 after properly verifying the validity of the payment account for the mobile communication device 705 and authenticating its ownership to the user 760. The trusted server 715 (or mobile communications infrastructure 720, as appropriate) may then issue service tokens 724 for various services, when, for example, client 710 wishes to buy services and / or goods from a third-party service 728. Accordingly, client 710 may issue a service token 726 to a third-party server p, which then validates the token 722 through the authentication server 715. It should be noted that the third-party server 728 may or may not require additional authentication, and as previously described, it can use various mechanisms to perform such validation. It should also be noted that the use of the service token 726 not only establishes a secure connection between the client 710 and the third-party server 728, but also may indicate the ability of the user 760 to pay for one or more units of services and / or goods in a manner similar to that previously described. It should be noted that usually until the service token is issued to the client 710, security tokens are issued that are not relevant to any other service other than the authentication server 715. The reason is that the security hierarchy may prevent any outside party from deciphering the device token, network token, or even the user token properly, since they all derive from the root or shared key 740, known only on the SIM device 705 and 720 mobile communications infrastructure. This usually happens after the authentication server 715 issues a service token 724, which an arbitrary third-party web service 728 can use for the security token 724. It should also be noted that the aforementioned security tokens and messages (for example, calls, answering calls, etc.) can accept various formats or patterns. For example, tokens and / or messages may be in Extensible Markup Language (XML) format, binary, or other similar encryption format that may be issued by mobile operator 720, which may or may not want some network elements to be visible for interaction SIM with intermediate parties.

The above-described use of portable hardware device 705 to verify the authenticity of authentication, identification information and / or payment can be used for online or local retail purchase of a service and / or goods (for example, an online newspaper, music piece, software application or other goods and services) or for providing access to an application running on a local personal computer (PC, PC) or client 710 (for example, Word®, Adobe Photoshop, Print, pay-as-you-go software ") etc.). Accordingly, the above embodiments are particularly advantageous for unlocking freely distributed secure software or content (eg, music, video, games, etc.) on many of the leading devices 710. In other words, the license now becomes associated with the portable mobile communication device 705, which can be authenticated as described above, providing that the portable digital identification information will not be associated with a limited set of computing devices. As such, user 760 goes to a friend’s house and does not have to bring all of his programs or other protected content; it is all accessible and authenticated through the portable device 705.

From the foregoing, it is understood that there are numerous aspects of the present invention that can be used independently of each other, including aspects that relate to identity tokens, payment tokens, selecting one provider from a plurality of identity providers, selecting a single provider from a plurality of payment providers, and presence commercial transaction software on an end-user system, a service provider system, an identity provider system th information and payment system provider. It is also understood that in some embodiments, all of the features described above can be used together, or any combination or subset of the features described above can be used together in a particular implementation, since aspects of the present invention are not limited in this regard.

The above embodiments of the present invention can be implemented in any of numerous ways. For example, embodiments may be implemented using hardware, software, or a combination thereof. If implemented as software, the program code can be executed on any suitable processor or set of processors, whether it is provided on a single computer or distributed among many computers. It is understood that any component or set of components that perform the functions described above can be generically considered as one or more controllers that control the functions discussed above. One or more controllers can be implemented in many ways, such as using specialized hardware, or using universal hardware (for example, one or more processors) that are programmed using microcode or software to perform the functions described above.

It is understood that the various methods described in general terms can be encoded as software running on one or more processors that use any of the many operating systems or platforms. Additionally, such software may be written using any of a variety of suitable programming languages and / or traditional programming tools or scripts, and may also be compiled as executable machine language code. In this regard, it should be obvious that one embodiment of the invention is focused on a computer-readable medium or a plurality of computer-readable media (for example, a computer storage device, one or more media on floppy disks, compact discs, optical disks, magnetic tapes, etc.) encoded with one or more programs that, when executed on one or more computers or other processors, perform methods that implement various embodiments of the invention discussed above. A computer-readable medium or medium may be portable so that the program or programs stored thereon can be downloaded over the network to one or more different computers or other processors in order to implement various aspects of the present invention, as discussed above.

It is understood that the term “program” is used in a document in a general sense to mean any type of computer code or a set of instructions that can be used to program a computer or other processor to implement various aspects of the present invention, as discussed above. It is also understood that, in accordance with one aspect of this embodiment, one or more computer programs that, when executed, implement the methods of the present invention, do not need to reside on a single computer or processor, but can be distributed modularly on many different computers or processors so that implement various aspects of the present invention.

Various aspects of the present invention can be used singly, in combination or in a variety of schemes not specifically discussed in the embodiments described above, and aspects of the described invention in their application are not limited to the details and schemes set forth in the foregoing description or illustrated in the drawings. Aspects of the invention allow for other embodiments and practice or implementation in various ways. Various aspects of the present invention can be implemented in conjunction with any type of network, multi-machine computing system, or configuration (equipment). No restrictions are imposed on the implementation of the network. Accordingly, the foregoing description and drawings are given by way of example only.

The use of ordinal terms in the claims, such as “first”, “second”, “third”, etc. to modify the claimed element does not mean any priority, precedence or precedence of one claimed element over another, or the temporal order in which the actions of the method are performed, but are used simply as marks to distinguish one claimed element with some name from another claimed element with the same name (but using an ordinal term) to distinguish between the claimed elements.

Also, the wording and terminology used in the document are intended for description purposes and should not be construed as limiting. The use of the terms “including”, “comprising”, or “having”, “comprising”, “including”, and their variations in the document is intended to encompass the elements and their equivalents after them, as well as additional elements.

Claims (39)

1. A method of providing a secure commercial transaction for an online purchase of services and / or goods in a consumer’s computing device in a distributed system by establishing a three-way data exchange between computing devices intended for the consumer, seller, and payment provider, the method comprising the steps of:
send an online request to purchase one or more of the services and / or goods offered by the seller;
receive invoice submission information from the seller, which includes the cost associated with the purchase of one or more of the services and / or goods;
sending a payment authorization request for payment to at least one payment provider from a consumer computing device, wherein the consumer has a payment account with at least one payment provider;
receive, from at least one payment provider, a payment token as evidence of a consumer’s ability to pay for at least part of one or more of the services and / or goods, and the payment token uniquely identifies payment authorization for at least a portion payment without providing confidential information about the consumer's payment account; send a payment token from the consumer’s computing device to the seller, in order to verify the validity of the payment with the payment provider, the seller uses the payment token, which makes the confidential information about the payment account opaque to the seller, but provides a secure verification of the validity of the payment; and
accepting the validity of the payment token indicating the proper transfer of one or more of the services and / or goods from the seller to the consumer. 2. The method according to claim 1, in which the information of the invoice additionally includes one or more of the description of services and / or goods, possible payment options from the seller or information specific to the seller. 3. The method of claim 2, wherein the invoice information is provided to at least one payment provider when requesting payment authorization for services and / or goods. 4. The method according to claim 3, in which the payment token includes invoice information, which is then signed and / or encrypted by at least one payment provider to verify the validity of the payment token and to match the payment token with the payment authorization request from the consumer . 5. The method according to claim 4, in which the request for authorization of payment, submission of payment information to at least one payment provider and sending a payment token to the seller are executed automatically without interaction from the consumer. 6. The method according to claim 2, in which, based on the available payment options provided by the seller, the method further comprises the steps of:
present to the consumer a user interface that shows one or more available payment options; receive user input from a consumer selecting at least one payment provider; and based on user input, a communication channel is established between the consumer computing device and at least one payment provider to implement a payment authorization request. 7. The method of claim 1, wherein the at least one payment provider is selected based on a default payment provider predetermined by the consumer. 8. The method according to claim 1, in which at least one payment provider is one of: a mobile communications infrastructure that has payment account information for a consumer-owned SIM device, a credit card sales company for a consumer, a prepaid service for a consumer , or consumer bank account. 9. The method according to claim 1, in which the commercial transaction is a direct internal practice in that the payment and selection of services and / or goods are integrated in a separate application that is not part of a web browser. 10. The method according to claim 1, wherein the payment token expires after at least one payment provider has set a predetermined period of time and / or frequency of use. 11. The method according to claim 1, in which the cost is a variable and is presented in the payment information as a range of values. 12. The method according to claim 1, in which the payment token is canceled by the consumer and / or at least one payment provider. 13. The method according to claim 1, in which the payment occurs at a predetermined amount provided by at least one payment provider, and it is necessary additional interaction with the user to authorize the payment token. 14. The method according to claim 1, in which the payment token is signed and / or encrypted by at least one payment provider, and the verification of the validity of the payment token for at least one payment provider includes verification of the signature and / or encryption. 15. The method according to claim 1, in which one or more of the services and / or goods require subscription or multiple payments, and the payment token can be used repeatedly for such a payment. 16. The method according to claim 1, in which one or more of the services and / or goods require subscription or multiple payments, and the payment token is only valid for a one-time payment of subscription or multiple payments, and for subsequent payments are necessary additional markers. 17. A method in a seller’s computing device in a distributed system for performing a secure commercial transaction while enabling the purchase of services and / or goods through the establishment of a three-way data exchange between computing devices intended for the consumer, seller, and payment provider, the method comprising the steps of :
accept an online request to purchase one or more of the services and / or goods offered by the seller;
send consumer invoice information, which includes the cost associated with the purchase of one or more of the services and / or goods;
receive from the consumer a payment token as an offer of evidence of the consumer’s solvency to pay for at least a portion of one or more services and / or goods, and the payment token uniquely identifies authorization of payment by the payment provider for at least a portion of the payment without confidential consumer billing information with the payment provider;
send a request to the payment provider to verify the validity of the payment token, thus allowing the seller to securely verify the accuracy of the payment for at least part of the payment, while making the confidential information about the payment account opaque to the seller; and
based on the validation of the payment token, a confirmation of the validity of the payment token is sent, indicating the proper transfer of one or more of the services and / or goods from the seller to the consumer. 18. The method of claim 17, wherein the invoice submission information further includes one or more of a description of the services and / or goods, available payment options from the seller, or information specific to the seller. 19. The method of claim 18, wherein the payment token includes billing information that is signed and / or encrypted by at least one payment provider to validate the payment token and to match the payment token with a payment authorization request from a consumer. 20. The method according to 17, in which the payment token expires after the payment provider has established a predetermined period of time and / or frequency of use. 21. The method of claim 17, wherein at least a portion of the cost is variable and is presented in the invoice presentation information as a range of values. 22. The method according to 17, in which the payment token is canceled by the consumer and / or payment provider. 23. The method according to 17, in which the payment is carried out at a predetermined amount provided by the payment provider, and for this authorization of the payment token requires additional interaction with the user. 24. The method according to 17, in which one or more of the services and / or goods requires subscription or multiple payments, and the payment token can be used repeatedly for such a payment. 25. A method of authorization of a payment in a computing device of a payment provider in a distributed system in a commercial transaction for the purchase of services and / or goods by establishing a three-way data exchange between computing devices intended for the consumer, seller and payment provider, the method comprising the steps of:
accept a payment authorization request from a consumer buying one or more of the services and / or goods from the seller, and the payment authorization request includes invoice information for the costs associated with the purchase; based on the state of the consumer’s payment account, a payment token is sent to the consumer as proof of the consumer’s ability to pay for one or more of the services and / or goods, and the payment token uniquely identifies the authorization of payment for one or more of the services and / or goods without providing confidential information about the payment consumer account;
receive from the seller a request to verify the validity of the payment token and
based on the comparison of the payment token with the invoice information from the payment authorization request, a confirmation of the validity of the payment token is sent indicating that the payment will be provided to the seller after the corresponding transfer of one or more of the services and / or goods to the consumer. 26. The method according A.25, in which the information of the invoice additionally includes one or more of the description of services and / or goods, available payment options from the seller or seller-specific information. 27. The method according to claim 25, wherein the at least one payment provider is either a mobile communications infrastructure comprising invoice information for a consumer SIM device or a credit card company for a consumer or a prepaid service for a consumer, or consumer bank account. 28. The method according A.25, in which the payment token expires after the payment provider has established a predetermined period of time and / or frequency of use. 29. The method of claim 25, wherein the cost is a variable and is presented in the invoice presentation information as a range of values. 30. The method of claim 25, wherein the payment token is a cancellable consumer and / or payment provider. 31. The method according to claim 25, wherein the payment is made according to a predetermined amount provided by the payment provider, and additional authorization with the user is required to authorize the payment token. 32. The method according A.25, in which the payment token is signed and / or encrypted by the payment provider, and the verification of the validity of the payment token for the payment provider includes verifying the authenticity of the signature and / or encryption. 33. The method according A.25, in which one or more of the services and / or goods requires subscription or multiple payments, and the payment token can be used repeatedly for such a payment. 34. The method according A.25, in which one or more of the services and / or goods requires a subscription or multiple payments, and the payment token is only valid for a one-time payment of subscription or multiple payments, and additional payments require additional markers. 35. A method of performing authorization of a payment in a distributed computing system for executing an online commercial transaction based on electronic submission of an account to maintain registration of an online transaction for purposes of monitoring, anti-fraud, and others, the method comprising the steps of: receiving in a computing device consumer’s electronic account, which includes a description and the cost of the purchase of one or more of the services and / or goods from the seller during online howling commercial transaction for that; and
send a copy of the electronic invoice to the payment provider to authorize the payment for one or more of the services and / or goods. 36. The method according to clause 35, in which one or more parts of the electronic account is encrypted by the seller so that one or more parts are opaque to the consumer and / or payment provider. 37. The method according to clause 36, in which one or more encrypted parts of the electronic account is used to automatically federate payments in relation to one or more business partners of the seller. 38. The method according to clause 35, further comprising stages in which:
save a copy of the electronic invoice on the consumer’s computing device;
accept a payment request from the payment provider for payment corresponding to the payment to the seller, wherein the payment request includes a copy of the electronic invoice from the seller; and comparing the stored copy of the electronic invoice with the copy received from the payment provider in order to verify the corresponding payment made in relation to the seller. 39. The method according to clause 35, in which the copy of the electronic invoice is provided with the signature of the seller, the method further comprises the steps of:
receive a payment token from the payment provider to authorize the payment of one or more of the services and / or goods, the token including a signed copy of the electronic invoice; and send the payment token to the seller to authorize the payment, while the seller can verify the accuracy of the payment token upon receipt from the consumer based on the signed copy of the electronic invoice.

Images