WO2014031032A1 - Способ создания платежной системы - Google Patents

Способ создания платежной системы Download PDF

Info

Publication number
WO2014031032A1
WO2014031032A1 PCT/RU2013/000620 RU2013000620W WO2014031032A1 WO 2014031032 A1 WO2014031032 A1 WO 2014031032A1 RU 2013000620 W RU2013000620 W RU 2013000620W WO 2014031032 A1 WO2014031032 A1 WO 2014031032A1
Authority
WO
WIPO (PCT)
Prior art keywords
network
transaction
payment
siss
identifier
Prior art date
Application number
PCT/RU2013/000620
Other languages
English (en)
French (fr)
Inventor
Олег Александрович СЕРЕБРЕННИКОВ
Original Assignee
Serebrennikov Oleg Alexandrovich
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Serebrennikov Oleg Alexandrovich filed Critical Serebrennikov Oleg Alexandrovich
Priority to US14/415,769 priority Critical patent/US20150178711A1/en
Publication of WO2014031032A1 publication Critical patent/WO2014031032A1/ru

Links

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00—Payment architectures, schemes or protocols
    • G06Q20/30—Payment architectures, schemes or protocols characterised by the use of specific devices or networks
    • G06Q20/305—Payment architectures, schemes or protocols characterised by the use of specific devices or networks using wired telephone networks
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00—Payment architectures, schemes or protocols
    • G06Q20/38—Payment protocols; Details thereof
    • G06Q20/384—Payment protocols; Details thereof using social networks
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00—Payment architectures, schemes or protocols
    • G06Q20/02—Payment architectures, schemes or protocols involving a neutral party, e.g. certification authority, notary or trusted third party [TTP]
    • G06Q20/027—Payment architectures, schemes or protocols involving a neutral party, e.g. certification authority, notary or trusted third party [TTP] involving a payment switch or gateway
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00—Payment architectures, schemes or protocols
    • G06Q20/08—Payment architectures
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00—Payment architectures, schemes or protocols
    • G06Q20/08—Payment architectures
    • G06Q20/10—Payment architectures specially adapted for electronic funds transfer [EFT] systems; specially adapted for home banking systems
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00—Payment architectures, schemes or protocols
    • G06Q20/22—Payment schemes or models
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00—Payment architectures, schemes or protocols
    • G06Q20/22—Payment schemes or models
    • G06Q20/227—Payment schemes or models characterised in that multiple accounts are available, e.g. to the payer
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00—Payment architectures, schemes or protocols
    • G06Q20/38—Payment protocols; Details thereof
    • G06Q20/382—Payment protocols; Details thereof insuring higher security of transaction
    • G06Q20/3829—Payment protocols; Details thereof insuring higher security of transaction involving key management
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00—Payment architectures, schemes or protocols
    • G06Q20/38—Payment protocols; Details thereof
    • G06Q20/386—Payment protocols; Details thereof using messaging services or messaging apps
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q30/00—Commerce
    • G06Q30/06—Buying, selling or leasing transactions

Definitions

  • the present invention relates to the field of computer technology, methods for searching, retrieving and processing information and identifying network resources, electronic commerce and distribution of physical and virtual goods and services, in particular distribution of the Internet domain name system (DNS), as well as the creation of payment tools, payment systems , addressing and making payments.
  • DNS Internet domain name system
  • a retailer such as Wal-Mart may be a payment system in which each product is assigned a DNS account identifier to receive payment from users / buyers.
  • Another example of the need for a payment system is the sale of virtual goods, such as DNS names or virtual goods in the gaming environment, which allows top-level domains or game manufacturers to earn income using the business model of the payment system.
  • the objective of the present invention is to eliminate the above limitations by improving the functional and operational characteristics of the payment system and improving the usability of it.
  • the method of creating a system for conducting transactions and exchanging messages for transactions in a communication network is characterized in that for a communication network, connections are established between the calling and called network resource using the network connection addressing system of said communication network;
  • the system for addressing network connections of a communication network is equipped with a database in which network identifiers and network addresses are recorded, with at least one network address corresponding to each network identifier in said database;
  • the network addressing system provides the calling network resources with a permission service, consisting in the fact that the addressing system receives the network identifier of the called resource from the calling resource, searches the network addressing database for the network address that matches the network identifier of the called resource and returns the found network address of the called resource the calling resource, and the calling resource uses the received network address of the called resource to establish a network connection from the call aemym resource network;
  • transaction system has a database of transaction accounts and is a network resource, and each transaction account in the database of the transaction system is assigned a Network Transaction Account Identifier (
  • said transaction system is a payment system
  • transaction accounts are financial accounts
  • the transaction instruction is a payment instruction and contains at least the payer's SISS and the payment amount
  • the SISS identifier contained in the payment instruction identifies the payer's financial account in corresponding Base Segment.
  • said network identifiers are DNS names or Uniform Resource Identifiers (URIs), and network addresses are IP addresses.
  • URIs Uniform Resource Identifiers
  • the N-level DNS registrar is provided with a Payment System Segment, and the N-level DNS registered by the registrar is used as the SISS to identify financial accounts in the said Base Segment, each SISS is assigned at least one network address of the corresponding Segment Addresses, and SISS and at least one of the mentioned addresses of the Address Segment assigned to it are recorded in the database of the network connection addressing system.
  • the Internet creates the Payment System
  • a second-level DNS identifiers registered in the selected top-level domain of the Internet are used as the SISS
  • the registrar is a different top-level domain
  • the said Payment system segment is used as distributor payment system.
  • said selected top-level domain is a .PAY domain.
  • asymmetric encryption private and public cryptographic keys are created for said registrar, and said users are asked to enter credit card information when registering the said SISS, which are encrypted using the distributor’s public cryptographic key and receive a ZZKK (encrypted credit card record), then the connection of the said ZZKK is established with the aforementioned SISS and record the ZZKK with the associated SISS in the Database Segment of the said registrar, and if paid, the corresponding by the user of a product or service on the Internet or in the retail network of the physical world, they enter the said SISS and use the SISS to create and transfer the said payment instructions to the Registrar Database Segment, and to carry out the payment in the Database Segment, the account is searched for with an identifier that matches the mentioned SISS and they extract the ZZKK which is aligned with the mentioned SISS in the Base Segment, the ZZKK are decrypted using the registrar’s private key and use the decrypted data to eniya payment.
  • connection between the ZZKK and SISS is not established and the ZZKK is not recorded in the database of the Segment database, and for making a payment the ZZKK is placed in the payment instructions.
  • said one or more addresses of the Address Segment are randomly selected from a plurality of transaction system addresses.
  • the value of the encrypted account record is placed in the transaction instructions.
  • the SISS identifier is not placed in the transaction instruction, and the transaction is conducted with respect to the decrypted identifier of the transaction account.
  • the account record is a payment card account record.
  • said account record is encrypted using the Segment public key.
  • asymmetric encryption public and private cryptographic keys are created for the Database Segment, and data is encrypted and decrypted using the said public and private keys.
  • multiple SISCs are created, each of which is a DNS identifier, and to create the corresponding DNS identifier as the right part of the identifier, or at least as a variable part of the right part of the identifier, use the DNS name of the server of the service provider, and as the left part
  • the DNS identifier uses the user's login to access the server of the service provider or the user's phone number, and the left part is attached to the right part, separating the mentioned parts with a dot ⁇ . >.
  • said telephone number is used for the purpose of establishing feedback with a client or for verification purposes or for authentication purposes during a transaction.
  • a plurality of SISCs are created, each of which is a DNS identifier, and to create a SISS, an email address is used in which at least the ⁇ @> sign is replaced by a dot ⁇ . >
  • a plurality of SISCs are created, each of which is a DNS identifier, moreover, to create a SISS, the telephone number of the user and the DNS name of the telephone operator are used, for which at least the telephone number is attached to the DNS name of the telephone operator on the left, dividing the For example, the phone number and DNS name mentioned are dotted ⁇ . >. Examples of carrying out the invention
  • the present invention provides a method for creating payment systems by renting through the Internet cloud services of an anonymous payment system, the software and hardware complex of which (the payment system cloud) is also located on the Internet and involves the use of network identifiers as identifiers of financial accounts, as disclosed in Serebrennikov's application.
  • Serebrennikov’s application relates to the field of conducting transactions of any kind, having illustrated the essence of the invention with the example of a payment system, we will bear in mind that using the present invention, a system of conducting transactions of a different kind can be constructed. We will also continue to reason for the Internet, bearing in mind that using the present invention a transaction system can be created in a telephone network or in another public communication network.
  • Serebrennikov’s method discloses a method for making a payment on the Internet, for example, the identifier of the payer and payee in the payment system are valid DNS names such as pay.rau and payee. pay, in this case registered in the alleged .PAY top-level domain.
  • Each of the DNS names has an IP address assigned to the server of the payment system serving the account of the payer or payee, respectively, thus after resolving the specified DNS names into IP addresses, for example, in the case of:
  • Payer rau? raueg. rau & rauee. rau & $ 100 a connection will be established, respectively, with the server of the payer payment system, where payment initiation will be transmitted (HTTP request): raueg.rau & rauee.rau & $ 100
  • the payer’s payment server will extract from the request the value of the payer’s name payee.rau, as well as the payment amount of $ 100.
  • the payment server After extracting the name of the payer, the payment server will check whether there is an account with the payer ID in the payment system and, if the account exists, then the server of the payer payment system will accept the payment for processing. Any known method can be used for authentication of the payer, verification of data and authorization of payment.
  • Payer pay? payer. pay & etickets.pay & $ 100 uses the string to create an Internet connection in the HUPS protocol, and the name raueg.rau will be resolved through the DNS system to the IP address of the payer payment server, with which etickets.pay will establish an Internet connection and transfer it to the payer payment server payment instruction payer.pay & etickets.pay & $ 100.
  • the server of the payer payment system will check the presence of a client account with the identifier raue.rau and if such an account exists, then, for example, for the authentication of the payer and authorization of the payment, the server etickets.pay will transfer control to the server of the payer system, and the payment system server will prompt the payer to enter the password known to the payer in a special authentication field of the payer on the payer's payment system page, then the password entered by the payer will be verified on the server of the payment system and, if the password is correct, the payment will be authorized by the payment system and control will be transferred again to etickets.pay website to complete the issuance of the electronic ticket.
  • VISA TM 3DSecure TM technology uses VISA TM 3DSecure TM technology, with the only difference being that instead of the payer account identifier rage.rau, the customer enters the data of a plastic payment card, therefore one of the existing technologies can be used to authenticate the payment using the claimed method, which makes the implementation of the claimed method inexpensive.
  • Each network DNS identifier used to identify the transaction account must resolve to the cloud's IP address. This imposes restrictions on the policy of delegating DNS names (or URLs or URIs) used for payment purposes, as it does not allow free selection of IP addresses for the mentioned DNS names, and each of the IP addresses must belong to the cloud. This simultaneously creates the prerequisites for the use of new top-level domains, the domain names in which are intended solely for addressing connections for the purpose of conducting various transactions, including addressing payments. For example, in the .book domain you can register the DNS names of books that will simultaneously serve as account identifiers for receiving payments from the sale of the corresponding book.
  • the .arr domain for the distribution of applications (applications) and any other top-level domain for the distribution of the names of the second level as goods for which the user pays (registrant). Therefore, it seems appropriate and preferable to use the .pay domain for payments of any kind.
  • the first and second stage of registering second-level names in new top-level domains is the Sunrise and Landrush period, during which the second-level domain names are registered for owners of well-known registered trademarks.
  • trademark and service companies are owners of trademarks, which allows you to register DNS identifiers for all TSPs who wish to have transactional accounts in the cloud, such as TSPs.
  • TLDs where TLDs are any Internet Top-Level Domain.
  • Each DNS name of the second level of TSP. TLD can also serve as an identifier of the payment system account in the cloud of payment systems.
  • Each TSP can create accounts for goods and services by registering third-level DNS names such as TO V AR S P. TLD, the only restriction, as noted earlier, will be the use of IP addresses belonging to the cloud of payment systems.
  • a TSP whose DNS second-level account identifier (e.g. amazon.pay) was registered during the Sunrise and Landrush periods can be an owner account identifier or even become an identifier for a separate payment system that can assign third-level DNS names to product accounts or services that the TSP sells (for example, kindle.amazon.pay) or can assign third-level DNS names to the accounts of the users that the TSP serves (for example, Smith. amazon.pay).
  • accounts can mainly serve to receive payments when selling goods (services).
  • accounts can serve both for incoming and outgoing payments.
  • payment systems created in the cloud may also have DNS identifiers transaction account of a specific payment system, including customer accounts or goods (services).
  • the identifiers of the cloud payment systems can be second-level DNS identifiers delegated to them, but the Segments of the Payment system can have other identifiers.
  • top-level domains themselves are e-commerce enterprises selling DNS names, which are virtual goods. This allows you to make top-level domains identifiers of the corresponding cloud payment systems, and second-level domain names registered in at least one of them (for example .PAY), identifiers of user accounts of the payment system.
  • a payment system cloud may not have its own DNS identifier or may have a top-level domain name, such as .PAY or may have any other DNS name and corresponding name.
  • An example of a payment system containing an account for goods (services) is a Wal-Mart TM or Sportmaster TM payment system or a payment system of a Samsung TM or Apple TM product manufacturer, where each product can be assigned a URI containing a domain name of a level N product in the hierarchical part of the URI, being the identifier of the goods account and receiving payments from the buyers of this product.
  • the same URI can be used, the [? Request] component of which, instead of a payment instruction, may contain a request for data on a product or service.
  • An example of a payment system containing user accounts is the payment system of a free email company Gmail or Hotmail, or the payment system of Citibank, or the payment system of the online game World of War Craft or Angry Birds, and so on.
  • Another example of payment systems can be any top-level domains (for example .amazon), goods or user accounts in which there may be second-level domains registered in these top-level domains (for example kindle. Amazon).
  • top-level domains for example .amazon
  • goods or user accounts in which there may be second-level domains registered in these top-level domains (for example kindle. Amazon).
  • DNS identifiers are created to identify transaction accounts of payment systems, however, users of the payment system may not have their own DNS names to use this method. Users of online services that use a username and password to identify customers may not have their own DNS names, telephone service customers or free email clients may not have DNS identifiers, and so on. In such cases, creating multiple DNS identifiers for clients can be difficult because:
  • the number of provider’s clients can reach millions and the selection of DNS identifiers for a large number of open accounts without the use of automation can be very time-consuming;
  • DNS identifiers are usually mnemonic (meaningful) for easier memorization by people and at the same time unique
  • the creation of mnemonic and at the same time unique identifiers requires the use of special methods for their creation.
  • the requirements for network identifiers may be at least the following:
  • Automation The ability to automate the selection of network identifiers for existing transaction accounts
  • the network account identifier must be mnemonic (meaningful) for the owner of this account.
  • the network account identifier must be unique in the whole set of transaction accounts served by the transaction server.
  • the present invention provides a procedure for automatically generating invoice names for all clients where either the unique name (login) of the account holder used by him to enter the server of the online services of the service provider is used as the CLIENTJD, or the unique phone number of the account holder and so on.
  • the online service provider is Citibank
  • the customer’s login on the bank’s server is SAM1 CITI
  • the customer’s phone number is +1 (212) 1234567 stored in the Citibank database
  • transaction account identifiers can be created by adding a subscriber's phone number as a third-level label to the DNS name of the carrier, for example:
  • Using a phone number in the DNS identifier of the transaction account is also useful because it allows you to create an online feedback channel with the account user for user authentication, data verification and payment authorization.
  • each of the created transaction identifiers is a network DNS identifier and each corresponds to the mentioned requirements of automation, fame, meaningfulness and uniqueness. If these transactional identifiers are matched with cloud IP addresses, then using them it will be possible to conduct transactions in the cloud, as disclosed in Serebrennikov’s application and in the present invention.
  • ⁇ cloud index a network of transaction processing (payments) processing company ABC
  • ⁇ cloud index a network server or grouping of ABC network servers
  • DNS identifiers for clients can be assigned using any known method of creating and assigning DNS names, and DNS names assigned to clients can be created in any top-level domain and can be DNS names of any level, and the only requirement for them is their uniqueness and mapping them to IP addresses of relevant payment systems.
  • the email addresses client_ID@facebook.com and client_ID@gmail.com can be converted into DNS identifiers by replacing the @ sign with a dot sign, thus the identifiers of transaction accounts will be respectively client_ID.facebook.com and client_ID.gmail.com.
  • the DNS account ID of the client who owns the phone number + 1-212- 1234567 and the samlciti login in AT&T can be, for example, identifier 12121234567. att.com or sam1citi.att.com identifier.
  • IP index Facebook Each of the newly created payment systems Facebook, gmail.com and AT&T is leased / used with one or more IP addresses from the "IP index of the cloud", then these one or more IP addresses of the payment system will be called, respectively, “IP index Facebook”, “IP gmail and ip index AT&T index for the respective payment systems. Moreover, all IP addresses belong to the “ ⁇ cloud index” and provide connection to the cloud.
  • Cloud segments that are addressed using the “Facebook IP Index”, “gmail IP Index” and “AT&T IP Index” are logically or physically separated for the purpose of processing the processing of facebook, gmail and AT&T payment systems, respectively.
  • Differentiating “ Why ⁇ esque cloud index” into indices and processing areas belonging to different payment systems makes it possible to differentiate accounting and apply different accounting policies for transactions conducted by customers of each of the payment systems, as well as increase system security and system resilience to failures.
  • Facebook, Google and AT&T companies can independently establish various payment commissions for their customers, independently manage the processes of customer authentication, verification and authorization of payments, limit or expand the powers of customers, and offer certain additional conditions for using accounts.
  • Step 5 Transaction between customer accounts in the created payment systems.
  • connection address (DNS name) 12121234567.att.com will be resolved to the IP address from the “AT&T IP Index”; 2) an Internet connection will be established (for example, HTTPS) with the AT&T payment system in the cloud; 3) payment instruction 12121234567.att.com & client_ID.gmail.com & $ 100 will be transferred to the AT&T payment system.
  • the payment system will have to process the payment instruction (HTTPS request) and respond to it to the calling resource (HTTPS response), which will allow you to establish an exchange between the calling resource and the payment system server and make a payment using, for example, the scenario for purchasing an electronic ticket described above.
  • the calling resource in this example can be any person, including the parties to the payment and the server of the respective payment systems, and the Internet connection established between the calling resource and the AT&T payment system can be used to organize the exchange processes between the calling resource and the payment system server for the purposes of authentication of the payer and / or payee, data verification and payment authorization by known methods. Distribution of DNS cloud financial account identifiers registered in the selected top-level domain
  • Serebrennikov’s application discloses a method of encrypting user’s credit card data (buyer’s DNS identifier) using the asymmetric encryption method using the public key of a transaction service provider’s service, and using DNS identifiers as transaction identifiers, including financial accounts.
  • the present invention provides a method for distributing DNS identifiers by any third parties (hereinafter, for example, we will talk about second-level domains registered in the .PAY top-level domain), which are used as identifiers for financial accounts.
  • a third party hereinafter, for example, we will talk about second-level domains registered in the .PAY top-level domain
  • the said distributor offers the user to register the name in the top-level domain .PAY and use the latter as the identifier of the financial account to pay for purchases on the Internet and in the physical retail network.
  • a Transaction System Segment is created for the distributor, and all DNS names distributed by it in the .PAY domain are used as identifiers of the financial accounts of the corresponding users of an arbitrary top-level domain in its Transaction System Segment, which allows the said distributor to receive a commission from transactions by its users with using as identifiers of the financial account DNS identifiers registered by them in the top-level domain .PAY registered with the said distributor.
  • the owner may be delegated their own second-level DNS identifier in the .PAY domain, an identifier that is used as the identifier of the distributor’s financial account in the Transaction System and the commission from operations performed by the distributor’s users can be credited to this account.
  • This method allows you to interest other top-level domains in the distribution of domain names of selected TLDs (for example .PAY), as this allows top-level domains to create their own payment system (Transaction System Segment) and receive a commission from users making top-level domains of payments on the Internet and in retail networks of the physical world.
  • TLDs for example .PAY
  • Transaction System Segment Transaction System Segment
  • a DNS identifier in the .PAY domain can be offered to the user on preferential terms, which may consist in the fact that the user benefits from registering a DNS name in a .PAY domain or registering a DNS name in a .PAY domain is for a user free or reduced fee.
  • preferential terms which may consist in the fact that the user benefits from registering a DNS name in a .PAY domain or registering a DNS name in a .PAY domain is for a user free or reduced fee.
  • Another advantage of using a DNS name as an identifier for a financial account is the intuitiveness of the DNS name and the fact that such names are mnemonic, that is convenient for remembering, which allows you to place them on a business card and quickly remember them.
  • Serebrennikov's application discloses a method for creating and using an Encrypted Account Record (ZZS).
  • ZZS Encrypted Account Record
  • an RFP is created by encrypting account data using the public key of the transaction server, so only the transaction server can decrypt such a record.
  • Serebrennikov’s application also discloses the method of using the ZZS in which the ZZS is placed and used together with the network address of the transaction server ( ⁇ ), whose public key was used to encrypt the ZZS.
  • Serebrennikov's application method allows you to encrypt plastic card data using the public key of the card payment processing center server and store the received ZZS of the plastic card in memory together with the CAS of the card payment processing center. And when making a payment, extract from the memory of the ⁇ and ⁇ center, establish a network connection with the processing center and transfer the ⁇ to it, where the ⁇ is decrypted using the Private key of the processing center and then the operation of payment is applied to the decrypted card data.
  • the present invention extends the use of Serebrennikov's application method for cloud payment systems.
  • the card data is encrypted with the public key of one of the cloud payment systems and is recorded together with the IP address from the “ ⁇ index” of this payment system or recorded with SISS. Data can be written into the memory accessible to the cardholder and thus remain at the disposal of the cardholder himself and not be known to the payment system, and presented to the payment system only at the time of payment.
  • the ZZS can be created by any third party with the appropriate cryptographic means, since the public key of the payment system is available to the public as part of the digital certificate of the payment system.
  • the CAS can be placed in the transaction instructions of the calling resource and transferred to the cloud after the connection between the calling resource and the cloud is established.
  • sellers can be pre-certified or approved to connect to the payment system and they can use special certified or certified tools, such as dedicated IP addresses from which they can connect to the cloud of payment systems, as well as the use of secure protocols (such as HTTPS), special equipment, certain methods, and so on. Online access to payment services
  • An important feature of the invention is that the process of resolving DNS account identifiers to the IP addresses of servers with the subsequent establishment of an Internet connection is separated from the transaction process in the same way as today the process of resolving a DNS name for example Citibank (Citibank.com) is separated from the services provided by Citibank online payments using Citibank online banking. Therefore, the use of the invention does not carry additional risks for the Internet DNS addressing system.
  • the invention Since the invention is applicable to DNS names of any level and registered in any domain of the upper or lower level, the invention does not pose any threats to the stability of the DNS system as a whole, it is also safe for the roots of any specific top-level domains.
  • the invention does not pose additional risks to networks and addressing mechanisms for network connections when using the invention in other public networks.
  • the creation of the “Facebook IP Index”, “gmail IP Index” and “AT&T IP Index” can be organized in a random way, in which the set of IP addresses of each index is a random sequence of addresses. This can be achieved by random selection of IP addresses from the index of consecutive IP addresses for inclusion in the index of IP addresses of a particular payment system. This method of assigning IP addresses will not allow you to determine whether a particular IP address belongs to the IP address index of a particular payment system. A random sequence of index IP addresses will also not allow determining the number of clients of a particular payment system using public DNS services. When using cryptographic keys of the payment system, a random set of IP addresses of the index of IP addresses of the payment system will not allow attackers to determine the cryptographic keys of which payment system are used when connecting to a specific IP address of the cloud of payment systems.
  • the claimed method allows you to create new transaction systems and in particular payment systems in a short time, and promote newly created payment systems under the names of their respective tenants / users, and also allows you to automate the creation of DNS account identifiers protect data of transaction accounts for their safe storage and distribution in the communication network.
  • the invention provides a process for distributing network identifiers to identify transaction accounts.
  • the creation of transaction systems, the generation of network account identifiers and the protection and distribution of identifiers and transaction account data using the presented invention can be organized in real time, and the duration and cost of creating payment systems, the generation of network account identifiers, protection, secure storage and data exchange transaction accounts may have a short duration in time and be affordable at the cost of creation and ownership as for the enterprise th small business and for large companies.

Landscapes

  • Business, Economics & Management (AREA)
  • Accounting & Taxation (AREA)
  • Engineering & Computer Science (AREA)
  • Physics & Mathematics (AREA)
  • General Business, Economics & Management (AREA)
  • General Physics & Mathematics (AREA)
  • Strategic Management (AREA)
  • Theoretical Computer Science (AREA)
  • Finance (AREA)
  • Development Economics (AREA)
  • Economics (AREA)
  • Computer Security & Cryptography (AREA)
  • Marketing (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Financial Or Insurance-Related Operations Such As Payment And Settlement (AREA)

Abstract

Изобретение относится к способам обработки информации и идентификации сетевых ресурсов и электронной коммерции. Технический результат - повышение надежности при проведении транзакции. Способ осуществляют с помощью системы адресации сетевых соединений сети коммуникаций и систем проведения транзакций. Система адресации содержит базу данных с сетевыми идентификаторами, каждому из которых поставлен в соответствие сетевой адрес. Каждая система проведения транзакции является сетевым ресурсом, имеющим сетевой адрес, и имеет базу данных транзакционных счетов, каждому из которых присвоен сетевой идентификатор транзакционного счета. Система проведения транзакций разделена на сегменты, с соответствующим, по меньшей мере, одним транзакционным счетом сегмента, имеющим идентификатор счета сегмента, которому в базе данных системы адресации соответствует, по меньшей мере, один адрес соответствующего сегмента. Создают платежную инструкцию, содержащую, по крайней мере, один сетевой идентификатор транзакционного счета. Указанную инструкцию передают в систему адресации для установления сетевого соединения, с использованием сетевого адреса соответствующего сегмента, и проведения платежной транзакции.

Description

СПОСОБ СОЗДАНИЯ ПЛАТЕЖНОЙ СИСТЕМЫ
Область техники
Настоящее изобретение относится к области компьютерной техники, способов поиска, извлечения и обработки информации и идентификации сетевых ресурсов, электронной коммерции и дистрибуции физических и виртуальных товаров и услуг, в частности дистрибуции системы доменных имен (DNS) Интернет, а также создания платежных инструментов, платежных систем, адресации и проведения платежей.
Уровень техники
Известны способы проведения платежей с использованием пластиковых карт VISA™ и других карт, но идентификаторы карт трудно запомнить и эти идентификаторы не являются сетевыми, что не позволяет их использовать непосредственно в слое сетевых протоколов сетей связи и Интернет. Известные системы проведения платежей PayPal, Яндекс.Деньги и другие платежные системы, использующие идентификаторы электронной почты, однако эти идентификаторы не позволяют проводить платежи в режиме реального времени, так как предполагают использование сетевого протокола SMTP, который не обеспечивает доставку сообщений в режиме реального времени. Все упомянутые системы не предоставляют облачных услуг (cloud service) быстрого и недорогого создания платежных систем с использованием оборудования и программного обеспечения упомянутых платежных систем, они также не предоставляют безымянных (White Label) решений, что позволило бы их клиентам продвигать собственные бренды в качестве наименований платежной системы, построенной с использованием упомянутых облачных услуг. Известен способ идентификации транзакционных счетов и обмена транзакционными сообщениями между сторонами проведения транзакции (патентная заявка США Ne 20050114367, А1, серийный Ne 927460/10, опубл. 26.05.2005, автор ОАСеребренников), далее названный способ именуется Заявка Серебренникова или Способ Серебренникова. Однако способ Серебренникова не предлагает способа создания платежных систем путем предоставления облачных услуг безымянной системы.
Таким образом, разработка собственной платежной системы является в настоящее время длительным и затратным производством, кроме того имеющим немалую стоимость владения, что делает затруднительным создание собственной платежной системы особенно для небольших компаний. Еще одним естественным ограничением является сложность расширения платежной системы за рамки собственной клиентской базы, так как это приводит к смещению фокуса деятельности компании в область платежных систем, в то время как обслуживание одной только собственной клиентской базы может иметь слишком высокую усредненную стоимость обслуживания одного клиента. Другим ограничением в настоящее время является то, что расходы на проведение платежей через платежные системы третьих сторон могут достигать 30% от суммы платежа, как в случае с платежной системой компании Apple (https://developer.apple.com/appstore/in- app-purchase/ln-App-Purchase-Guidelines.pdf), которой для проведении платежей внутри приложений (in-app платежи) обязаны пользоваться все разработчики приложений для операционной системы iOS.
В настоящее время миллионы людей являются пользователями различных социальных сетей Интернет и приложений для различных устройств, операторы связи имеют миллионы абонентов, а пользователями провайдеров услуг бесплатной электронной почты являются миллионы пользователей и так далее. В то время, как одним из основных способов монетизации клиентской базы указанных бизнесов является модель показа платной рекламы или взимание платы за обслуживание, каждый бизнес ищет новые способы монетизации клиентской базы. Одним из путей монетизации является взимание платы за предоставление услуг проведения платежей, что может требовать создания собственной платежной системы.
Другим примером потребности в собственной платежной системе является онлайновая продажа товаров (в том числе виртуальных) и услуг. Например такой ритейлер как Wal-Mart может быть платежной системой в которой каждому товару присвоен DNS идентификатор счета для получения оплаты от пользователей/покупателей.
Еще одним примером потребности в платежной системе является продажа виртуальных товаров, таких как DNS имена или виртуальные товары в игровой среде, что позволяет доменам верхнего уровня или производителям игр получать доход, используя бизнес модель платежной системы.
Задачей настоящего изобретения является устранение упомянутых выше ограничений путем улучшения функционально - эксплуатационных характеристик платежной системы и улучшения удобства пользования ею.
Раскрытие изобретения
Поставленная задача решается тем, что способ создания системы проведения транзакций и обмена сообщениями проведения транзакций в сети коммуникаций, характеризуется тем, что для сети коммуникаций устанавливают соединения между вызывающим и вызываемым ресурсом сети с использованием системы адресации сетевых соединений упомянутой сети коммуникаций; система адресации сетевых соединений сети коммуникаций оснащена базой данных, в которую записаны сетевые идентификаторы и адреса сети, причем каждому сетевому идентификатору в упомянутой базе данных поставлен в соответствие, по меньшей мере, один сетевой адрес; система адресации сети предоставляет вызывающим ресурсам сети услугу разрешения, состоящую в том, что система адресации получает от вызывающего ресурса сетевой идентификатор вызываемого ресурса, осуществляет в базе данных системы адресации поиск сетевого адреса, поставленного в соответствие сетевому идентификатору вызываемого ресурса и возвращает найденный сетевой адрес вызываемого ресурса вызывающему ресурсу, а вызывающий ресурс использует полученный сетевой адрес вызываемого ресурса для установления сетевого соединения с вызываемым ресурсом сети; система проведения транзакций имеет базу данных транзакционных счетов и является сетевым ресурсом, а каждому транзакционному счету в базе данных системы проведения транзакций присвоен Сетевой Идентификатор транзакционного Счета (СИС); системе проведения транзакций присвоены один или более адресов системы проведения транзакций (АСПТ), и упомянутые АСПТ используются для установления сетевых соединений между вызывающими ресурсами сети и системой проведения транзакций, которая является сетевым ресурсом; причем упомянутым СИС в базе данных системы сетевой адресации ставят в соответствие, по меньшей мере, один АСПТ; а для проведения транзакции создают инструкцию проведения транзакции, содержащую, по меньшей мере, один СИС, обращаются в систему адресации соединений сети за услугой разрешения и передают в упомянутую систему адресации упомянутый СИС, осуществляют услугу разрешения в отношении СИС, получают упомянутый, по меньшей мере, один АСПТ, поставленный в базе данных системы адресации сетевых соединений в соответствие упомянутому СИС, с помощью упомянутого АСПТ устанавливают сетевое соединение с базой данных проведения транзакций и передают в базу данных проведения транзакций упомянутую инструкцию проведения транзакции содержащую упомянутый, по меньшей мере, один СИС, при этом систему проведения транзакций разделяют, по меньшей мере, на два Сегмента, каждому Сегменту выделяют индивидуальный Сегмент базы данных системы проведения транзакций (Сегмент Базы), множество АСПТ делят по числу Сегментов на непересекающиеся подмножества адресов (Сегменты Адресов), упомянутые Сегменты Адресов используют для адресации соединений исключительно с соответствующим Сегментом Базы; в избранном Сегменте Базы создают, по меньшей мере, один транзакционный счет для которого создают, по меньшей мере, один Сетевой Идентификатор Счета Сегмента (СИСС) и упомянутому СИСС в базе данных системы адресации сетевых соединений ставят в соответствие, по меньшей мере, один адрес из числа адресов соответствующего Сегмента Адресов; используют упомянутый СИСС для создания упомянутой платежной инструкции, установления сетевого соединения с упомянутым Сегментом Базы и передачи инструкции в упомянутый Сегмент Базы. Предпочтительно, из полученной инструкции извлекают СИСС и применяют известное правило проведения транзакции в счету, идентификатор которого совпадает с СИСС, излеченным из упомянутой инструкции проведения транзакции.
Предпочтительно, упомянутая система проведения транзакций является системой проведения платежей, счета проведения транзакций являются финансовыми счетами, а инструкция проведения транзакции является платежной инструкцией и содержит, по меньшей мере, СИСС плательщика и сумму платежа, а идентификатор СИСС содержащийся в платежной инструкции идентифицирует финансовый счет плательщика в соответствующем Сегменте Базы.
Предпочтительно, упомянутые сетевые идентификаторы являются DNS именами или идентификаторами Uniform Resource Identifier (URI), a сетевые адреса являются IP адресами.
Предпочтительно, регистратору DNS имен уровня N предоставляют Сегмент системы проведения платежей, а зарегистрированные регистратором упомянутые DNS имена уровня N используют в качестве упомянутых СИСС для идентификации финансовых счетов в упомянутом Сегменте Базы, каждому СИСС ставят в соответствие, по меньшей мере, один сетевой адрес соответствующего Сегмента Адресов, а СИСС и поставленный ему в соответствие хотя бы один упомянутый адрес Сегмента Адресов записывают в базу данных системы адресации сетевых соединений.
Предпочтительно, в избранном домене верхнего уровня Интернет создают упомянутую Систему проведения платежей, a DNS идентификаторы второго уровня зарегистрированные в упомянутом избранном домене верхнего уровня Интернет используют в качестве упомянутых СИСС, упомянутым регистратором является другой домен верхнего уровня, а упомянутый Сегмент системы проведения платежей используют в качестве платежной системы дистрибутора. Предпочтительно, упомянутым избранным доменом верхнего уровня является домен .PAY.
Предпочтительно, для упомянутого регистратора создают закрытый и открытый криптографические ключи асимметричного шифрования, а упомянутым пользователям при регистрации упомянутых СИСС предлагают ввести данные кредитной карты, которые шифруют с использованием открытого криптографического ключа дистрибутора и получают ЗЗКК (зашифрованную запись кредитной карты), затем устанавливают связь упомянутой ЗЗКК с упомянутым СИСС и записывают ЗЗКК с сопоставленным ему СИСС в Сегмент базы упомянутого регистратора, а при оплате соответствующим пользователем товара или услуги в сети Интернет или в розничной сети физического мира, вводят упомянутый СИСС и используют СИСС для создания и передачи упомянутой платежной инструкции в Сегмент Базы регистратора, а для проведения упомянутого платежа в Сегменте базы осуществляют поиск счета идентификатор которого совпадает с упомянутым СИСС и извлекают ЗЗКК поставленный в соответствие упомянутому СИСС в Сегменте Базы, ЗЗКК расшифровывают с использованием закрытого ключа регистратора и используют расшифрованные данные для осуществления платежа.
Предпочтительно, связь между ЗЗКК и СИСС не устанавливают и ЗЗКК в базу данных Сегмента базы не записывают, а для проведения платежа ЗЗКК размещают в инструкции проведения платежа.
Предпочтительно, упомянутые один или более адресов Сегмента Адресов выбирают случайным образом из множества адресов системы проведения транзакций.
Предпочтительно, в инструкции проведения транзакции размещают значение зашифрованной записи счета.
Предпочтительно, в инструкции проведения транзакции не размещают идентификатор СИСС, а транзакцию проводят в отношении расшифрованного идентификатора транзакционного счета. Предпочтительно, записью счета является запись счета платежной карты.
Предпочтительно, упомянутую запись счета шифруют с использованием открытого ключа Сегмента.
Предпочтительно, для Сегмента Базы создают открытый и закрытый криптографические ключи асимметричного шифрования, а данные шифруют и дешифруют с использованием упомянутых открытого и закрытого ключей.
Предпочтительно, создают множество СИСС, каждый из которых является DNS идентификатором, причем для создания соответствующего DNS идентификатора в качестве правой части идентификатора или, по меньшей мере, в качестве изменяющейся части правой части идентификатора, используют DNS имя сервера сервис провайдера, а в качестве левой части DNS идентификатора используют логин пользователя для доступа к серверу сервис провайдера или номер телефона пользователя, а упомянутую левую часть присоединяют к правой разделяя упомянутые части знаком точка < . >.
Предпочтительно, упомянутый номер телефона, используют для целей установления обратной связи с клиентом или для целей верификации или для целей аутентификации при проведении транзакции.
Предпочтительно, создают множество СИСС, каждый из которых является DNS идентификатором, причем для создания СИСС используют адрес электронной почты в котором, по меньшей мере, знак < @ > заменяют знаком точка < . >
Предпочтительно, создают множество СИСС, каждый из которых является DNS идентификатором, причем для создания СИСС используют номер телефона пользователя и DNS имя оператора телефонной связи, для чего, по меньшей мере, номер телефона присоединяют слева к DNS имени оператора телефонной связи разделяя упомянутый, по меньшей мере, номер телефона и упомянутое DNS имя знаком точка < . >. Примеры осуществления изобретения
Настоящее изобретение предлагает способ создания платежных систем путем аренды через Интернет облачных услуг безымянной платежной системы, программно-аппаратный комплекс которой (облако платежной системы) расположен также в Интернет и предполагает использование сетевых идентификаторов в качестве идентификаторов финансовых счетов, как раскрыто в заявке Серебренникова.
Поскольку заявка Серебренникова относится к области проведения транзакций любого рода, то проиллюстрировав суть изобретения на примере платежной системы, мы будем имеем в виду, что с использованием настоящего изобретения может быть построена система проведения транзакций иного рода. Мы также будем далее вести рассуждения для сети Интернет, имея в виду, что с использованием настоящего изобретения может быть создана система проведения транзакций в сети телефонной связи или в другой публичной сети связи.
Вкратце способ Серебренникова раскрывает способ проведения например платежа в Интернет, причем идентификатором счета плательщика и получателя платежа в платежной системе являются действительные DNS имена например рауег.рау и payee. pay, в данном случае зарегистрированные в предполагаемом домене верхнего уровня .PAY. Каждому из DNS имен сопоставлен IP адрес сервера платежной системы, обслуживающей соответственно счет плательщика или получателя платежа, таким образом после разрешения указанных DNS имен в IP адреса, например в случае:
Payer. рау?рауег. рау&рауее. рау&$100 будет установлено соединение соответственно с сервером платежной системы плательщика, куда будет передана инициация платежа (HTTP запрос): рауег.рау&рауее.рау&$100 Платежный сервер плательщика извлечет из запроса значения имени плательщика рауег.рау, а также сумму платежа $100. После извлечения имени плательщика платежный сервер проверит, есть ли в платежной системе счет с идентификатором плательщика и, если счет существует, то сервер платежной системы плательщика примет платеж в обработку. Для аутентификации плательщика, верификации данных и авторизации платежа может быть использован любой известный способ.
Сценарий покупки электронного билета
Проиллюстрируем использование заявки Серебренникова на примере покупки билета на предполагаемом сайте etickets.pay, причем покупателю принадлежит идентификатор рауег.рау которому поставлен в соответствие IP адрес платежной системы. Покупатель билета посещает страницу сайта etickets.pay, выбирает билет и выбирает способ оплаты с использованием способа заявки Серебренникова. Покупателю предлагается согласиться с суммой и условиями оплаты, а также указать DNS идентификатор счета плательщика в платежной системе. Плательщик вводит свой идентификатор счета рауег.рау в специальное поле страницы оплаты сайта etickets.pay. После этого сайт etickets.pay создает строку
Payer. pay?payer. pay&etickets.pay&$ 100 и использует строку для создания Интернет соединения в протоколе HUPS, при этом имя рауег.рау будет разрешено через систему DNS в IP адрес сервера платежной системы плательщика, с которым etickets.pay установит Интернет соединение и передаст на сервер платежной системы плательщика платежную инструкцию payer.pay&etickets.pay&$100.
Сервер платежной системы плательщика проверит наличие клиентского счета с идентификатором рауег.рау и если такой счет существует, то, например, для аутентификации плательщика и авторизации платежа сервер etickets.pay передаст управление серверу платежной системы плательщика, а сервер платежной системы предложит плательщику ввести известный плательщику пароль в специальное поле аутентификации плательщика на странице платежной системы плательщика, затем введенный плательщиком пароль будет верифицирован на сервере платежной системе и, если пароль верный, то платеж будет авторизован платежной системой, а управление будет вновь передано сайту etickets.pay для завершения оформления электронного билета. Похожий сценарий, в частности, использует технология 3DSecure™ компании VISA™, с той только разницей, что вместо идентификатора счета плательщика рауег.рау, покупатель вводит данные пластиковой платежной карты, поэтому для аутентификации платежа заявленным способом может быть использована одна из существующих технологий, что делает внедрение заявленного способа недорогим.
Идентификаторы счетов Торгово-Сервисных Предприятий (ТСП или мерчентов)
Каждый сетевой DNS идентификатор используемый для идентификации транзакционного счета должен разрешаться в IP адрес облака. Это накладывает ограничения на политику делегирования имен DNS (или URL или URI ), используемых для целей проведения платежей, так как не допускает свободного выбора IP адресов для упомянутых DNS имен, и каждый из IP адресов должен принадлежать облаку. Это одновременно создает предпосылки для использования новых доменов верхнего уровня, доменные имена в которых предназначены исключительно для адресации соединений с целью проведения различных транзакций, включая адресацию платежей. Например в домене .book можно регистрировать DNS наименования книг, которые одновременно будут служить идентификаторами счета для получения платежей от продажи соответствующей книги. Так же можно использовать домен .арр для целей дистрибуции приложений (applications) и любой другой домен верхнего уровня для целей дистрибуции в нем имен второго уровня как товара за который платит пользователь (registrant). Поэтому, представляется целесообразным и предпочтительным использовать домен .pay для платежей любого рода. Как известно, первым и вторым этапом регистрации имен второго уровня в новых доменах верхнего уровня является период Sunrise и Landrush, в течении которого происходит регистрация доменных имен второго уровня для владельцев известных зарегистрированных торговых марок. Как правило владельцами торговых марок являются Торгово- Сервисные Предприятия (ТСП), что позволяет зарегистрировать DNS идентификаторы всем ТСП, желающим иметь транзакционные счета в облаке, такие как ТСП.ДВУ где ДВУ является любым Доменом Верхнего Уровня Интернет. Каждое DNS имя второго уровня ТСП.ДВУ может также служить идентификатором счета платежной системы в облаке платежных систем. Каждое ТСП может создавать счета товаров и услуг путем регистрации DNS имен третьего уровня таких как ТО В АР С П. ДВУ, единственным ограничением, как отмечалось ранее, будет использование IP адресов, принадлежащих облаку платежных систем.
Идентификаторы счетов в платежных системах облака
В соответствии с настоящим изобретением, ТСП, чей DNS идентификатор счета второго уровня (например amazon.pay) был зарегистрирован в период Sunrise и Landrush, может быть идентификатором счета владельца или даже стать идентификатором отдельной платежной системой, которая может присвоить DNS имена третьего уровня счетам товаров или услуг которые ТСП продает (например kindle.amazon.pay) или может присвоить DNS имена третьего уровня счетам пользователей, которых ТСП обслуживает (например Smith. amazon.pay). В случае идентификации счетов товаров (услуг) счета могут преимущественно служить для получения платежей при продаже товара (услуги). В случае идентификации счетов пользователя, счета могут служить как для входящих так и для исходящих платежей.
Идентификаторы платежных систем облака
Для целей клиринга и проведения взаимных расчетов платежные системы созданные в облаке также могут иметь DNS идентификаторы транзакционного счета конкретной платежной системы, включающей счета клиентов или товаров (услуг).
Как показано выше, идентификаторами платежных систем облака (Сегменты Системы проведения платежей) могут быть делегированные им DNS идентификаторы второго уровня, но Сегменты Системы проведения платежей могут иметь и другие идентификаторы. Вместе с тем, домены верхнего уровня сами по себе являются предприятиями электронной коммерции продавая DNS имена, которые являются виртуальным товаром. Это позволяет сделать домены верхнего уровня идентификаторами соответствующих платежных систем облака, а доменные имена второго уровня, зарегистрированные, по меньшей мере, в одном из них (например .PAY), идентификаторами счетов пользователей платежной системы.
Облако платежных систем может не иметь собственного DNS идентификатора или может иметь имя домена верхнего уровня, например .PAY или может иметь любое другое DNS имя и соответствующее название.
Примеры платежных систем ТСП
Примером платежной системы содержащей счета товаров (услуг) может служить платежная система компании Wal-Mart™ или Спортмастер™ или платежная система производителя товаров Samsung™ или Apple™, где каждому товару может быть присвоен URI содержащий доменное имя товара уровня N в иерархической части URI, являясь идентификатором счета товара и получения платежей от покупателей этого товара. Для поиска информации о товаре может быт использован тот же URI, компонент [?запрос] которого, вместо платежной инструкции может содержать запрос данных о товаре или услуге.
Примеры платежных систем
Примером платежных систем содержащих счета пользователей могут служить платежные системы компаний бесплатной электронной почты Gmail или Hotmail, или платежная система банка Citibank или платежная система онлайновой игры World of War Craft или Angry Birds и так далее.
Другим примером платежных систем могут служить любые домены верхнего уровня (например .amazon), счетами товаров или пользователей в которых могут быть домены второго уровня, зарегистрированные в этих доменах верхнего уровня (например kindle. amazon).
Создание DNS идентификаторов счетов для клиентов и товаров платежных систем
На первом этапе создания облака платежных систем (как раскрыто выше) производится создание DNS идентификаторов для идентификации транзакционных счетов платежных систем, однако пользователи платежной системы могут не иметь собственных DNS имен для использования указанного способа. Собственных DNS имен могут не иметь пользователи онлайновых услуг, которые используют для идентификации клиентов логин и пароль, DNS идентификаторов могут не иметь также клиенты операторов телефонной связи или клиенты бесплатной электронной почты и так далее. В таких случаях создание множества DNS идентификаторов для клиентов может быть затруднено тем, что:
1. Число клиентов провайдера может достигать миллионов и подбор DNS идентификаторов для большого числа открытых счетов без использования автоматизации может оказаться очень трудоемким;
2. Поскольку трудность запоминания DNS идентификатора счета может служить препятствием к внедрению сетевых идентификаторов для существующих клиентов, то в качестве сетевых идентификаторов счета желательно использовать данные, ранее известные клиенту сервиса.
3. Поскольку одним из преимуществ использования DNS идентификаторов для идентификации счетов является то, что DNS идентификаторы, как правило, являются мнемоническими (осмысленными) для более простого их запоминания людьми и одновременно уникальными, то создание мнемонических и одновременно уникальных идентификаторов требует использования специальных способов их создания.
В связи с вышеизложенными соображениями, требованиями к сетевым идентификаторам могут быть, по меньшей мере, следующие:
1. Автоматизация. Возможность автоматизации выбора сетевых идентификаторов для существующих транзакционных счетов;
2. Известность. Сетевые идентификаторы должны содержать информацию ранее известную владельцу счета и транзакционному серверу;
3. Осмысленность. Сетевой идентификатор счета должен быть мнемоническим (осмысленным) для владельца этого счета.
4. Уникальность. Сетевой идентификатор счета должен быть уникальным во всем множестве транзакционных счетов обслуживаемых транзакционным сервером.
Настоящее изобретение предлагает процедуру автоматической генерации имен счетов для всех клиентов где в качестве CLIENTJD используется или уникальное имя (логин) владельца счета используемое им для входа на сервер онлайновых услуг провайдера услуг, или уникальный номер телефона владельца счета и так далее.
Если например провайдером онлайновых услуг является Citibank, логином клиента на сервере банка является имя SAM1 CITI, а телефоном клиента является номер +1 (212) 1234567 записанный в базе данных Ситибанка, то в соответствии с настоящим изобретением автоматически могут быть созданы следующие сетевые идентификаторы счета указанного клиента:
12121234567.citibank.com и / или sam1citi.citibank.com Другим примером может служить создание DNS идентификаторов транзакционных счетов для провайдеров услуг бесплатной почты hotmail.com, gmail.com, mail.ru или любого другого публичного или корпоративного почтового сервера. Как известно все почтовые адреса пользователей одного провайдера отличаются лишь логином, расположенным слева от знака @ и логин является уникальным идентификатором пользователя. Заменяя знак @ знаком точка < . > можно конвертировать e-mail адреса в DNS адреса второго уровня в домене сервис провайдера, так что почтовому адресу sam1citi@gmail.com будет соответствовать уникальный DNS идентификатор транзакционного счета sam1citi.gmail.com.
Для операторов телефонной связи как фиксированной так и сотовой DNS идентификаторами транзакционных счетов можно создавать прибавляя номер телефона абонента в качестве метки третьего уровня к DNS имени оператора связи, например:
12121234567.att.com
Использование номера телефона в DNS идентификаторе транзакционного счета полезно еще и тем, что позволяет создать канал онлайновой обратной связи с пользователем счета для целей аутентификации пользователя, верификации данных и авторизации платежа.
Приведенные примеры в равной степени относятся к созданию DNS идентификаторов счетов для товаров (услуг) или пользователей в доменах верхнего уровня:
12121234567.att kindle.amazon samlciti. google samlciti. citibank angrybirds. apple ipad-3-16gb.walmart и так далее...
Как видно из приведенных примеров каждый из созданных транзакционных идентификаторов является сетевым DNS идентификатором и каждый соответствует упомянутым требованиям автоматизации, известности, осмысленности и уникальности. Если этим транзакционным идентификаторам поставить в соответствие IP адреса облака, то с их использованием можно будет проводить транзакции в облаке, как раскрыто в заявке Серебренникова и в настоящем изобретении.
Несмотря на то, что в приведенных выше примерах в качестве метки соответствующего уровня для образования действительного DNS имени использовался только номер телефона или логин, такой номер телефона или логин может являться лишь частью строки названной метки или являться только переменной частью названной строки метки для образования действительного DNS имени соответствующего уровня, используемого далее в качестве идентификатора счета товара, услуги или пользователя.
Создание облака платежных систем
Предположим, что в сети создана и предлагается сетевая услуга процессинга транзакций (платежей) компании ABC и, что программное обеспечение обеспечивающее процессинг транзакций размещено на сетевом сервере или группировке сетевых серверов компании ABC (далее сервер или группировку серверов ABC будем называть «облаком»), которые доступны потенциальным клиентам и пользователям сети Интернет (или другой сети) с использованием одного или более IP адресов (или сетевых адресов другой сети), далее именуемых «ΙΡ индекс облака».
Проиллюстрируем сценарий использования облака для создания платежных систем например для социальной сети Facebook, для оператора сотовой связи AT&T и для сервера бесплатной электронной почты gmail.com, а также проиллюстрируем проведение платежной операции между счетами созданных в облаке платежных систем.
Этап 1. Создание DNS идентификаторов транзакционных клиентских счетов.
DNS идентификаторы клиентам могут быть присвоены с использованием любого известного способа создания и присвоения DNS имен, причем присвоенные клиентам DNS имена могут быть созданы в любом домене верхнего уровня и могут быть DNS именами любого уровня, а единственным требованием к ним является их уникальность и сопоставление им IP адресов соответствующих платежных систем.
Для создания DNS идентификаторов транзакционных счетов клиентов Facebook.com и gmail.com, адреса электронной почты client_ID@facebook.com и client_ID@gmail.com могут быть преобразованы в DNS идентификаторы путем замены знака @ на знак точка, таким образом идентификаторами транзакционных счетов будут соответственно client_ID.facebook.com и client_ID.gmail.com.
Для создания идентификаторов транзакционного счета для клиентов AT&T может быть использованы или логины входа пользователей на сервер AT&T или номера телефонов клиентов, соответственно DNS идентификатором счета клиента владеющего номером телефона +1-212- 1234567 и логином samlciti в AT&T может быть, например, идентификатор 12121234567.att.com или идентификатор sam1citi.att.com.
Этап 2. Присвоение IP адресов платежным системам Facebook, Gmail и AT&T.
Каждой из вновь создаваемых платежных систем Facebook, gmail.com и AT&T передается в аренду/использование один или более IP адресов из "IP индекса облака", далее эти один или более IP адресов платежной системы будем называть соответственно "IP индекс Facebook", "IP индекс gmail" и "IP индекс AT&T" для соответствующих платежных систем. При этом все IP адреса принадлежат «ΙΡ индексу облака» и обеспечивают соединение с облаком.
Этап 3. Разграничение процессинга различных платежных систем.
Сегменты облака, адресуемые с помощью "IP индекса Facebook", "IP индекса gmail" и "IP индекса AT&T" логически или физически разделяются для целей разделения процессинга платежных систем facebook, gmail и AT&T соответственно. Разграничение «ΙΡ индекса облака» на индексы и области процессинга, принадлежащие разным платежным системам позволяет разграничить учет и применять различную политику учета в отношении транзакций проводимых клиентами каждой из платежных систем, а также увеличить безопасность работы и устойчивость систем к сбоям. В частности компании Facebook, Google и AT&T могут независимо друг от друга устанавливать для своих клиентов различные комиссии по платежам, самостоятельно управлять процессами аутентификации клиентов, верификации и авторизации платежей, ограничивать или расширять полномочия клиентов, предлагать те или иные дополнительные условия использования счетов.
Этап 4. Присвоение IP адресов DNS идентификаторам транзакционных счетов.
Для того чтобы DNS идентификатор счета каждого пользователя платежных систем стал действительным DNS адресом сети Интернет, ему в соответствие должен быть поставлен IP адрес. Поэтому каждому DNS идентификатору счета пользователя Facebook ставим в соответствие IP адрес из "IP индекса Facebook", а соответственно DNS идентификатору счета каждого пользователя gmail ставим в соответствие IP адрес из "IP индекса gmail", а для каждого пользователя AT&T ставим IP адрес из "IP индекса AT&T". Благодаря этому, разрешение сетевых идентификаторов счетов пользователей Facebook через систему DNS Интернет будет возвращать IP адреса из "IP индекса Facebook", аналогично для Gmail и для AT&T будет возвращать соответственно адреса из "IP индекса gmail" и из "IP индекса AT&T", что позволит устанавливать соединения соответственно с сегментом платежной системы Facebook или Gmail или AT&T соответственно.
Этап 5. Проведение транзакции между счетами клиентов в созданных платежных системах.
Для проведения платежа на сумму $100 со счета 12121234567.att.com на счет cliant_ID.gmail.com, например, может быть использована, например, строка с адресом соединения и платежной инструкцией, расположенной после адреса соединения и знака «?»:
12121234567.att.com?12121234567.att.com&client_ID.gmail.com&$100
В данном примере 1) адрес соединения (DNS имя) 12121234567.att.com будет разрешен в IP адрес из "IP индекса AT&T"; 2) будет установлено Интернет соединение (например HTTPS) с платежной системой AT&T в облаке; 3) в платежную систему AT&T будет передана платежная инструкция 12121234567.att.com&client_ID.gmail.com&$100.
После шага 3) платежная система должна будет обработать платежную инструкцию (HTTPS запрос) и ответить на него вызывающему ресурсу (HTTPS ответ), что позволит установить обмен между вызывающим ресурсом и сервером платежной системы и провести платеж используя, например, Сценарий покупки электронного билета, описанный выше. Вызывающим ресурсом в приведенном примере может быть любое лицо, включая стороны проведения платежа и сервера соответствующих платежных систем, а соединение Интернет, установленное между вызывающим ресурсом и платежной системой AT&T может быть использовано для организации процессов обмена между вызывающим ресурсом и сервером платежной системы для целей аутентификации плательщика и/или получателя платежа, верификации данных и авторизации платежа известными способами. Дистрибуция DNS идентификаторов финансовых счетов облака, зарегистрированных в избранном домене верхнего уровня
Заявка Серебренникова раскрывает способ шифрования данных кредитной карты пользователя (покупатель DNS идентификатора) с помощью метода ассиметричного шифрования с использованием открытого ключа сервис провайдера услуг проведения транзакций, а также использования DNS идентификаторов в качестве идентификаторов транзакционных, в том числе финансовых счетов.
Предположим, что домен верхнего уровня .PAY используется для создания DNS идентификаторов, предназначенных для использования в качестве идентификаторов транзакционных (финансовых) счетов.
Настоящее изобретение предлагает способ дистрибуции любыми третьими сторонами DNS идентификаторов (далее для примера будем говорить о доменах второго уровня зарегистрированных в домене верхнего уровня .PAY), которые используются в качестве идентификаторов финансовых счетов. Предположим пользователь Интернет посетил web сайт дистрибутора доменов второго уровня в РДВУ .PAY. Упомянутый дистрибутор предлагает пользователю зарегистрировать имя в домене верхнего уровня .PAY и использовать последнее в качестве идентификатора финансового счета для оплаты покупок в Интернет и в физической розничной сети. Для дистрибутора создается Сегмент Системы проведения транзакций, а все распространенные им DNS имена в домене .PAY используются в качестве идентификаторов финансовых счетов соответствующих пользователей произвольного домена верхнего уровня в его Сегменте Системы проведения транзакций, что позволяет упомянутому дистрибутору получать комиссионное вознаграждение от проведения его пользователями транзакций с использованием в качестве идентификаторов финансового счета DNS идентификаторов зарегистрированных ими в домене верхнего уровня .PAY, зарегистрированных с помощью упомянутого дистрибутора. Для идентификации финансового счета дистрибутора в Систем проведения транзакций владельцу возможно делегируют собственный DNS идентификатор второго уровня в домене .PAY, идентификатор который используется в качестве идентификатора финансового счета дистрибутора в Системе проведения транзакций и на этот счет может зачисляться комиссия от операций проведенных пользователями дистрибутора.
Настоящий способ позволяет заинтересовать другие домены верхнего уровня в дистрибуции доменных имен избранного ДВУ (например .PAY), так как это позволяет доменам верхнего уровня создать собственную платежную систему (Сегмент Системы проведения транзакций) и получать комиссию от проведения пользователями доменов верхнего уровня платежей в Интернет и в розничных сетях физического мира.
Для мотивации пользователя в регистрации DNS идентификатора в домене .PAY, такая регистрация может предлагаться пользователю на льготных условиях, которые могут состоять в том, что пользователь получает выгоду от регистрации DNS имени в домене .PAY или регистрация DNS имени в домене .PAY является для пользователя бесплатной или плата взимается в уменьшенном размере. Другим преимуществом использования DNS имени в качестве идентификатора финансового счета является интуитивная понятность DNS имени и то, что такие имена являются мнемоническими, то есть удобными для запоминания, что позволяет размещать их на визитной карточке и быстро запоминать их.
Защита данных, безопасность адресации и использования сетевых соединений
Вопросы безопасности при использовании изобретения могут решаться различными известными способами и способами раскрытыми в настоящем изобретении. Криптографическая защита данных счета в облаке
Заявка Серебренникова раскрывает способ создания и использования Зашифрованной Записи Счета (ЗЗС). Согласно заявке Серебренникова ЗЗС создается путем шифрования данных счета с использованием открытого ключа сервера проведения транзакций, таким образом только сервер проведения транзакций может расшифровать такую запись. Заявка Серебренникова также раскрывает способ использования ЗЗС при котором ЗЗС размещается и используется вместе с сетевым адресом сервера (САС) проведения транзакций, чей открытый ключ был использован для шифрования ЗЗС. Это позволяет извлекать данные ЗЗС и САС, адресовать соединение с сервером проведения транзакций с помощью САС и передавать серверу проведения транзакций ЗЗС, которую сервер транзакций расшифровывает с использованием собственного закрытого ключа асимметричной криптографии и использует расшифрованные данные Записи Счета (ЗС) для проведения транзакции по счету.
Для счета кредитной карты способ заявки Серебренникова позволяет шифровать данные пластиковой карты с помощью открытого ключа сервера центра процессинга карточных платежей и размещать полученную ЗЗС пластиковой карты в памяти вместе с САС центра процессинга карточных платежей. А при проведении платежа извлекать из памяти ЗЗС и САС центра, устанавливать сетевое соединение с центром процессинга и передавать на него ЗЗС, где ЗЗС расшифровывается с помощью Закрытого ключа центра процессинга и далее к расшифрованным данным карты применяется операция проведения платежа.
Настоящее изобретение расширяет использование способа заявки Серебренникова для платежных систем облака. Для этого данные карты шифруются открытым ключом одной из платежных систем облака и записываются вместе с IP адресом из «ΙΡ индекса» этой платежной системы или записываются вместе с СИСС. Данные могут записываться в память доступную владельцу карты и оставаться, таким образом, в распоряжении самого владельца карты и быть неизвестны платежной системе, а предъявляться платежной системе только в момент проведения платежа. Таким образом, ЗЗС может создаваться любым третьим лицом имеющим соответствующие криптографические средства, поскольку открытый ключ платежной системы доступен публике как часть цифрового сертификата платежной системы. Это позволяет избежать хранения данных клиента в единой базе данных, что позволяет избежать рисков неавторизованного доступа к данным ЗЗС всех клиентов одновременно в случае, если проникновения мошенников в базу данных и одновременно не создает помех и дополнительных барьеров при проведении транзакции. При хранении ЗЗС различных клиентов различных платежных систем облака, для расшифровывания конкретной ЗЗС необходимо знать открытым ключом какой конкретно платежной системе облака была зашифрована ЗЗС, что также трудно сделать если использовать случайные последовательности IP адресов для формирования «ΙΡ индекса» конкретной платежной системы как это описано ниже в разделе «Использование случайных последовательностей».
При отказе от хранения ЗЗС в памяти или базе данных системы проведения транзакций, ЗЗС может быть размещена в инструкции проведения транзакции вызывающего ресурса и передаваться в облако после установления соединения между вызывающим ресурсом и облаком.
Аутентификация, верификация и авторизация
В случае выставления счетов продавцами для оплаты покупателем, как и в случае с мерчентами (ТСП) в системах кредитных карт, продавцы могут быть предварительно аттестованы или одобрены для подключения к системе проведения платежей и ими могут использоваться специальные сертифицированные или аттестованные средства, например выделенные IP адреса с которых они могут устанавливать соединение с облаком платежных систем, а также использование защищенных протоколов (например HTTPS), специального оборудования, определенных способов и так далее. Онлайновый доступ к услугам проведения платежей
Для онлайнового доступа к платежной системе с целью проведения операций самими владельцами счетов могут быть использованы технологии доступа к услугам интернет банкинга. Поскольку настоящее изобретение в равной степени относится к сетевым именам любых сетей.
Устойчивость систем адресации
В случае Интернет особой заботой таких организаций как ICANN является избегание рисков потери стабильности и целостности системы DNS. Важной особенностью изобретения является то, что процесс разрешения DNS идентификаторов счетов в IP адреса серверов с последующим установлением Интернет соединения, отделен от процесса проведения транзакций таким же образом, как сегодня процесс разрешения DNS имени например Ситибанка (Citibank.com) отделен от предоставляемых Ситибанком услуг проведения платежей в режиме онлайн с использованием онлайн банкинга Ситибанка. Поэтому использование изобретения не несет дополнительных рисков для системы DNS адресации Интернет.
Поскольку изобретение применимо к именам DNS любого уровня и зарегистрированных в любом домене верхнего или более низкого уровня, то изобретение не несет как угроз стабильности системы DNS в целом, так безопасно и для корней любых конкретных доменов верхнего уровня.
Аналогичным образом изобретение не несет дополнительных рисков для сетей и механизмов адресации сетевых соединений при использовании изобретения в других публичных сетях.
Использование случайных последовательностей
Создание "IP индекса Facebook", "IP индекса gmail" и "IP индекса AT&T" может быть организовано случайным способом, при котором множество IP адресов каждого из индексов представляют собой случайную последовательность адресов. Этого можно достигнуть путем случайного выбора IP адреса из индекса последовательных IP адресов для его включения в индекс IP адресов конкретной платежной системы. Такой способ назначения IP адресов не позволит определить принадлежность конкретного IP адреса индексу IP адресов конкретной платежной системы. Случайная последовательность IP адресов индекса, также не позволит определить число клиентов конкретной платежной системы с использованием публичных DNS сервисов. При использовании криптографических ключей платежной системы, случайное множество IP адресов индекса IP адресов платежной системы не позволит определить злоумышленникам криптографические ключи какой платежной системы используются при соединении с определенным IP адресом облака платежных систем.
Как видно из описания изобретения и как показано на примерах, заявленный способ позволяет создавать новые системы проведения транзакций и в частности платежные системы в короткие сроки, и продвигать вновь созданные платежные системы под именами их соответствующих арендаторов/пользователей, а также позволяет автоматизировать создание DNS идентификаторов счетов, защищать данные транзакционных счетов для их безопасного хранения и распространения в сети коммуникаций. Кроме того изобретение предлагает процедуру дистрибуции сетевых идентификаторов для идентификации транзакционных счетов. Создание систем проведения транзакций, генерация сетевых идентификаторов счетов и защита и дистрибуция идентификаторов и данных транзакционных счетов с использованием представленного изобретения могут быть организованы в режиме реального времени, а продолжительность и стоимость создания платежных систем, генерации сетевых идентификаторов счетов, защита, безопасное хранение и обмен данными транзакционных счетов могут иметь небольшую продолжительность во времени и быть доступными по стоимости создания и владения как для предприятий малого бизнеса так и для крупных компаний.
Специалисту в данной области техники должно быть очевидно, что в настоящем изобретении возможны разнообразные модификации и изменения. Соответственно, предполагается, что настоящее изобретение включает указанные модификации и изменения, а также их эквиваленты, без отступления от сущности и объема изобретения, раскрытого в прилагаемой формуле изобретения.

Claims

ФОРМУЛА ИЗОБРЕТЕНИЯ
1. Способ создания платежной системы в сети коммуникаций, характеризующийся тем, что для сети коммуникаций устанавливают соединения между вызывающим и вызываемым ресурсом сети с использованием системы адресации сетевых соединений упомянутой сети коммуникаций; система адресации сетевых соединений сети коммуникаций оснащена базой данных, в которую записаны сетевые идентификаторы и адреса сети, причем каждому сетевому идентификатору в упомянутой базе данных поставлен в соответствие, по меньшей мере, один сетевой адрес; система адресации сети предоставляет вызывающим ресурсам сети услугу разрешения, состоящую в том, что система адресации получает от вызывающего ресурса сетевой идентификатор вызываемого ресурса, осуществляет в базе данных системы адресации поиск сетевого адреса, поставленного в соответствие сетевому идентификатору вызываемого ресурса и возвращает найденный сетевой адрес вызываемого ресурса вызывающему ресурсу, а вызывающий ресурс использует полученный сетевой адрес вызываемого ресурса для установления сетевого соединения с вызываемым ресурсом сети; система проведения транзакций имеет базу данных транзакционных счетов и является сетевым ресурсом, а каждому транзакционному счету в базе данных системы проведения транзакций присвоен Сетевой Идентификатор транзакционного Счета (СИС); системе проведения транзакций присвоены один или более адресов системы проведения транзакций (АСПТ), и упомянутые АСПТ используются для установления сетевых соединений между вызывающими ресурсами сети и системой проведения транзакций, которая является сетевым ресурсом; причем упомянутым СИС в базе данных системы сетевой адресации ставят в соответствие, по меньшей мере, один АСПТ; а для проведения транзакции создают инструкцию проведения транзакции, содержащую, по меньшей мере, один СИС, обращаются в систему адресации соединений сети за услугой разрешения и передают в упомянутую систему адресации упомянутый СИС, осуществляют услугу разрешения в отношении СИС, получают упомянутый, по меньшей мере, один АСПТ, поставленный в базе
ISA/RU
ИСПРАВЛЕННЫЙ ЛИСТ (ПРАВИЛО 91.1) данных системы адресации сетевых соединений в соответствие упомянутому СИС, с помощью упомянутого АСПТ устанавливают сетевое соединение с базой данных проведения транзакций и передают в базу данных проведения транзакций упомянутую инструкцию проведения транзакции содержащую упомянутый, по меньшей мере, один СИС, отличающийся тем, что систему проведения транзакций разделяют, по меньшей мере, на два Сегмента, каждому Сегменту выделяют индивидуальный Сегмент базы данных системы проведения транзакций (Сегмент Базы), множество АСПТ делят по числу Сегментов на непересекающиеся подмножества адресов (Сегменты Адресов), упомянутые Сегменты Адресов используют для адресации соединений исключительно с соответствующим Сегментом Базы; в избранном Сегменте Базы создают, по меньшей мере, один транзакционный счет для которого создают, по меньшей мере, один Сетевой Идентификатор Счета Сегмента (СИСС) и упомянутому СИСС в базе данных системы адресации сетевых соединений ставят в соответствие, по меньшей мере, один адрес из числа адресов соответствующего Сегмента Адресов; используют упомянутый СИСС для создания упомянутой платежной инструкции, установления сетевого соединения с упомянутым Сегментом Базы и передачи инструкции в упомянутый Сегмент Базы.
2. Способ по п. 1 , отличающийся тем, что из полученной инструкции извлекают СИСС и применяют известное правило проведения транзакции в счету, идентификатор которого совпадает с СИСС, излеченным из упомянутой инструкции проведения транзакции.
3. Способ по п. 1 , отличающийся тем, что упомянутая система проведения транзакций является системой проведения платежей, счета проведения транзакций являются финансовыми счетами, а инструкция проведения транзакции является платежной инструкцией и содержит, по меньшей мере, СИСС плательщика и сумму платежа, а идентификатор СИСС содержащийся в платежной инструкции идентифицирует финансовый счет плательщика в соответствующем Сегменте Базы.
ISA RU
ИСПРАВЛЕННЫЙ ЛИСТ (ПРАВИЛО 91.1)
4. Способ по п. 1, отличающийся тем, что упомянутые сетевые идентификаторы являются DNS именами или идентификаторами Uniform Resource Identifier (URI), а сетевые адреса являются IP адресами.
5. Способ по п. 4, отличающийся тем, что регистратору DNS имен уровня N предоставляют Сегмент системы проведения платежей, а зарегистрированные регистратором упомянутые DNS имена уровня N используют в качестве упомянутых СИСС для идентификации финансовых счетов в упомянутом Сегменте Базы, каждому СИСС ставят в соответствие, по меньшей мере, один сетевой адрес соответствующего Сегмента Адресов, а СИСС и поставленный ему в соответствие хотя бы один упомянутый адрес Сегмента Адресов записывают в базу данных системы адресации сетевых соединений.
6. Способ по п. 5, отличающийся тем, что в избранном домене верхнего уровня Интернет создают упомянутую Систему проведения платежей, a DNS идентификаторы второго уровня зарегистрированные в упомянутом избранном домене верхнего уровня Интернет используют в качестве упомянутых СИСС, упомянутым регистратором является другой домен верхнего уровня, а упомянутый Сегмент системы проведения платежей используют в качестве платежной системы дистрибутора.
7. Способ по п. 6, отличающийся тем, что упомянутым избранным доменом верхнего уровня является домен AY.
8. Способ по п. 5, отличающийся тем, что для упомянутого регистратора создают закрытый и открытый криптографические ключи асимметричного шифрования, а упомянутым пользователям при регистрации упомянутых СИСС предлагают ввести данные кредитной карты, которые шифруют с использованием открытого криптографического ключа дистрибутора и получают ЗЗКК, затем устанавливают связь упомянутой ЗЗКК с упомянутым СИСС и записывают ЗЗКК с сопоставленным ему СИСС в Сегмент базы упомянутого регистратора, а при оплате соответствующим пользователем товара или услуги в сети Интернет или в розничной сети
ISA/RU
ИСПРАВЛЕННЫЙ ЛИСТ (ПРАВИЛО 91.1) физического мира, вводят упомянутый СИСС и используют СИСС для создания и передачи упомянутой платежной инструкции в Сегмент Базы регистратора, а для проведения упомянутого платежа в Сегменте базы осуществляют поиск счета идентификатор которого совпадает с упомянутым СИСС и извлекают ЗЗКК поставленный в соответствие упомянутому СИСС в Сегменте Базы, ЗЗКК расшифровывают с использованием закрытого ключа регистратора и используют расшифрованные данные для осуществления платежа.
9. Способ по п. 6, отличающийся тем, что связь между ЗЗКК и СИСС не устанавливают и ЗЗКК в базу данных Сегмента базы не записывают, а для проведения платежа ЗЗКК размещают в инструкции проведения платежа.
10. Способ по п. 1 , отличающийся тем, что упомянутые один или более адресов Сегмента Адресов выбирают случайным образом из множества адресов системы проведения транзакций.
11. Способ по п. 1 , отличающийся тем, что в инструкции проведения транзакции размещают значение зашифрованной записи счета.
12. Способ по п. 11 , отличающийся тем, что в инструкции проведения транзакции не размещают идентификатор СИСС, а транзакцию проводят в отношении расшифрованного идентификатора транзакционного счета.
13. Способ по п. 11 , отличающийся тем, что записью счета является запись счета платежной карты.
14. Способ по п. 11 , отличающийся тем, что упомянутую запись счета шифруют с использованием открытого ключа Сегмента.
15. Способ по п. 1 , отличающийся тем, что для Сегмента Базы создают открытый и закрытый криптографические ключи асимметричного шифрования, а данные шифруют и дешифруют с использованием упомянутых открытого и закрытого ключей.
ISA/RU
ИСПРАВЛЕННЫЙ ЛИСТ (ПРАВИЛО 91.1)
16. Способ по п. 1 , отличающийся тем, что создают множество СИСС, каждый из которых является DNS идентификатором, причем для создания соответствующего DNS идентификатора в качестве правой части идентификатора или, по меньшей мере, в качестве изменяющейся части правой части идентификатора, используют DNS имя сервера сервис провайдера, а в качестве левой части DNS идентификатора используют логин пользователя для доступа к серверу сервис провайдера или номер телефона пользователя, а упомянутую левую часть присоединяют к правой разделяя упомянутые части знаком точка < >.
17. Способ по п. 16, отличающийся тем, что упомянутый номер телефона, используют для целей установления обратной связи с клиентом или для целей верификации или для целей аутентификации при проведении транзакции.
18. Способ по п. 1 , отличающийся тем, что создают множество СИСС, каждый из которых является DNS идентификатором, причем для создания СИСС используют адрес электронной почты в котором, по меньшей мере, знак < @ > заменяют знаком точка < . >
19. Способ по п. 1 , отличающийся тем, что создают множество СИСС, каждый из которых является DNS идентификатором, причем для создания СИСС используют номер телефона пользователя и DNS имя оператора телефонной связи, для чего, по меньшей мере, номер телефона присоединяют слева к DNS имени оператора телефонной связи разделяя упомянутый, по меньшей мере, номер телефона и упомянутое DNS имя знаком точка < . >.
ISA/RU
ИСПРАВЛЕННЫЙ ЛИСТ (ПРАВИЛО 91.1)
PCT/RU2013/000620 2012-08-24 2013-07-19 Способ создания платежной системы WO2014031032A1 (ru)

Priority Applications (1)

Application Number Priority Date Filing Date Title
US14/415,769 US20150178711A1 (en) 2012-08-24 2013-07-19 Method for creating a payment system

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
RU2012136238/08A RU2509360C1 (ru) 2012-08-24 2012-08-24 Способ создания платежной системы
RU2012136238 2012-08-24

Publications (1)

Publication Number Publication Date
WO2014031032A1 true WO2014031032A1 (ru) 2014-02-27

Family

ID=50150216

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/RU2013/000620 WO2014031032A1 (ru) 2012-08-24 2013-07-19 Способ создания платежной системы

Country Status (3)

Country Link
US (1) US20150178711A1 (ru)
RU (1) RU2509360C1 (ru)
WO (1) WO2014031032A1 (ru)

Cited By (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN106485487A (zh) * 2016-10-13 2017-03-08 中国互联网络信息中心 一种网上支付方法、域名系统及网上支付装置
US20210357900A1 (en) * 2014-03-07 2021-11-18 First Data Corporation Systems and methods for mobile device purchase flows

Families Citing this family (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
FR3019356B1 (fr) * 2014-03-25 2016-04-15 David Haddad Procede et systeme de paiement divise d'un produit ou service
EP3073670B1 (en) * 2015-03-27 2020-09-02 Black Gold Coin, Inc. A system and a method for personal identification and verification
RU2673398C1 (ru) * 2018-01-22 2018-11-26 Олег Александрович Серебренников Способ проведения платежных транзакций
CN109981816B (zh) * 2019-03-21 2023-04-18 上海风汇网络科技有限公司 基于dns域名系统的价值传输系统、方法及dns服务器
CN111756619B (zh) * 2020-06-24 2022-12-27 上海风汇网络科技有限公司 一种基于电子邮件的价值传输方法及价值传输集群系统
CN111738723B (zh) * 2020-07-04 2021-01-29 和宇健康科技股份有限公司 一种在线安全交易方法、装置及可读存储介质

Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20050114367A1 (en) * 2002-10-23 2005-05-26 Medialingua Group Method and system for getting on-line status, authentication, verification, authorization, communication and transaction services for Web-enabled hardware and software, based on uniform telephone address, as well as method of digital certificate (DC) composition, issuance and management providing multitier DC distribution model and multiple accounts access based on the use of DC and public key infrastructure (PKI)
RU2273107C2 (ru) * 2001-10-24 2006-03-27 Закрытое акционерное общество "ПлатоФон" Способ, система и компьютерное устройство для предоставления услуг связи между ресурсами в сетях связи и интернет с целью проведения транзакций
RU2376635C2 (ru) * 2002-10-23 2009-12-20 Закрытое акционерное общество "МедиаЛингва" Способ и система проведения транзакций в сети с использованием сетевых идентификаторов

Family Cites Families (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US6539077B1 (en) * 1998-06-05 2003-03-25 Netnumber.Com, Inc. Method and apparatus for correlating a unique identifier, such as a PSTN telephone number, to an internet address to enable communications over the internet
GB0426736D0 (en) * 2004-12-06 2005-01-12 Omnifone Ltd MyFone
US7653302B2 (en) * 2005-03-24 2010-01-26 Syabas Technology Inc. Techniques for transmitting personal data and metadata among computing devices
JP5342238B2 (ja) * 2005-09-28 2013-11-13 ワン スマート スター リミテッド ビジネス顧客との通信

Patent Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
RU2273107C2 (ru) * 2001-10-24 2006-03-27 Закрытое акционерное общество "ПлатоФон" Способ, система и компьютерное устройство для предоставления услуг связи между ресурсами в сетях связи и интернет с целью проведения транзакций
US20050114367A1 (en) * 2002-10-23 2005-05-26 Medialingua Group Method and system for getting on-line status, authentication, verification, authorization, communication and transaction services for Web-enabled hardware and software, based on uniform telephone address, as well as method of digital certificate (DC) composition, issuance and management providing multitier DC distribution model and multiple accounts access based on the use of DC and public key infrastructure (PKI)
RU2376635C2 (ru) * 2002-10-23 2009-12-20 Закрытое акционерное общество "МедиаЛингва" Способ и система проведения транзакций в сети с использованием сетевых идентификаторов

Cited By (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20210357900A1 (en) * 2014-03-07 2021-11-18 First Data Corporation Systems and methods for mobile device purchase flows
US11928663B2 (en) * 2014-03-07 2024-03-12 First Data Corporation Systems and methods for mobile device purchase flows
CN106485487A (zh) * 2016-10-13 2017-03-08 中国互联网络信息中心 一种网上支付方法、域名系统及网上支付装置

Also Published As

Publication number Publication date
RU2509360C1 (ru) 2014-03-10
RU2012136238A (ru) 2014-02-27
US20150178711A1 (en) 2015-06-25

Similar Documents

Publication Publication Date Title
RU2509360C1 (ru) Способ создания платежной системы
US10649984B2 (en) Online transaction validation using a location object
CN109658103B (zh) 身份认证、号码保存和发送、绑定号码方法、装置及设备
CN109409876A (zh) 基于区块链的电子合同签署方法、装置、设备及存储介质
US20170308896A1 (en) Methods and apparatus for brokering a transaction
US8239325B2 (en) Method and system to verify the identity of a user
RU2292589C2 (ru) Аутентифицированный платеж
US20020023054A1 (en) Method and system for protecting credit card transactions
US20040059952A1 (en) Authentication system
CN101218559A (zh) 令牌共享系统和方法
RU2735614C1 (ru) Способ и устройство выделения ресурсов и способ электронного платежа
JP2000194770A (ja) 電子商取引方法及びシステム、並びにコンピュ―タ・プログラム製品
US20120072346A1 (en) System and method for securing and authenticating purchase transactions
CN101291217A (zh) 网络身份认证方法
CN105283890A (zh) 用于激活凭证的方法和系统
US20100036946A1 (en) System and process for providing online services
US10158643B2 (en) Token-based routing for in-network authorization
WO2013140196A1 (en) A system for electronic payments with privacy enhancement via trusted third parties
KR20110107311A (ko) 모바일 네트워크를 이용한 결제 서비스 시스템 및 그 방법, 그리고 이를 위한 컴퓨터 프로그램
US20080040784A1 (en) Procedure and Multi-Key Card to Avoid Internet Fraud
EP3400695A1 (en) System, method and apparatus for data transmission
US20240121230A1 (en) Systems and methods for generating and using secure sharded onboarding user interfaces
EP3690782A1 (en) Secure and confidential payment
Ito et al. Investigations of Top-Level Domain Name Collisions in Blockchain Naming Services
TV et al. MPVIDS-SVB: Mobile Phone Virtual ID system based on smartphone volunteers’ Blockchain

Legal Events

Date Code Title Description
121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 13830832

Country of ref document: EP

Kind code of ref document: A1

WWE Wipo information: entry into national phase

Ref document number: 14415769

Country of ref document: US

NENP Non-entry into the national phase

Ref country code: DE

122 Ep: pct application non-entry in european phase

Ref document number: 13830832

Country of ref document: EP

Kind code of ref document: A1