BR102019017007A2 - payment method that dispenses with the use of debit and credit models, cards and other physical tokens. - Google Patents

Abstract

The present invention is a Computational System (not merely a program) that makes use of QRCode or related identifiers to identify its users, thus dispensing with debit and credit cards and, consequently, their dummies. Upon registration, each pole of the commercial relationship is identified. For each, a unique identifier code is generated in the form of QRCode and associated with the CPF / CNPJ and usage password. The credits themselves are inserted pre or post paid. The passive pole of the financial transaction (the one that receives the funds) through an application - which automatically generates encrypted keys for each financial transaction carried out - reads this identifier and thus makes the sale. The data is transmitted via end-to-end encryption to the central which does not decode it, only approves and retains a certain amount as a commission. Thus, there is an inversion in the way payments are made. In this method, which basically functions as an electronic command, it is the passive pole that, also, retains the burden of counterproofing financial transactions, not only limiting the existence of balances. Therefore, with application in the banking sector, various payments area, as well as electronic command systems in several commercial and service sectors, aiming at effective facilitation, red tape, cost reduction, implementation facilities and improvements, this system makes it possible to small suppliers of products and services receive payments by electronic means and due to the particularity of not having to take even a card, it makes the lives of these consumers easier and safer.

Description

PAYMENT METHOD THAT DISPENSES THE USE OF DEBIT AND CREDIT MACHINES, CARDS AND OTHER PHYSICAL TOKENS.

[001] The so-called program is an integral part of the payment method (henceforth so-called) includes a set of software and related algorithms in a multi-platform environment, that is, developed for WEB environments and APPLICATIONS FOR SMATPHONES AND TABLETS, contemplating any and all operating systems contained therein, browsers and intrinsic or extrinsic tools of now, past and future. It also contemplates any and all media, alterations or alternatives, printed, digital and of any other nature, characteristics, intellectual or not, tangible or intangible to which they refer to this similar, analogous, similar tool or that promotes any other ambiguity or discussion since now and forever.

[002] The source code of this program was basically developed using programming languages JAVA, HTML, C, JPS, JSON and JavaScript on different occasions and situations. Often used together. Tools were also used for programming, compiling (CodeBlocks), design, construction, formatting and database storage (MySQL), GlassFish, etc. The codes referring to the generation of iTokkens and related encryptions and keys (of public nature - type 'A' and private - type 'B'), as well as the miscegenation of information, data processing and other events related to the protective face of the methodology are elaborated in different encodings and of course here they were omitted due to security factors. It is worth noting that the omission, even if intentional, of these encodings and contents does not hinder the functioning and, therefore, analysis for obtaining a patent, of this software in question.

[003] The basic idea is to simulate an electronic command through a bracelet or any other media capable of carrying an iTokken of the type QR-Code, analogous or similar, for later identification. The program makes use of iTokkens at three different times: at the time of user registration, for the recipient of funds and for the financial transaction itself. Therefore, there will be three iTokkens to be generated by the program. The first belongs to the service operator (point of sale and payments), the second to the user (paying, consumer of products and services) and the third to the merchant receiving credits. Each iTokken identifier is unique, non-transferable and valid for a certain period of time.

[004] In due course, the program is subdivided into two sides: the credit operator - who is intended to withhold payments and the recipient of credits - the one to whom the funds are destined. Naturally, each will have its own control application. At the time of registration, the user and the recipient of resources obtain iTokken codes and, by means of a password, public cryptographic keys (type key 'A'). At the time of the financial transaction, a new encrypted iTokken code is generated by these public keys, containing the pertinent information that is sent to the remote server - cloud. Later, the operator, who holds a private and unique decrypting key (type ‘B’ decrypting key) accesses this data and makes payments and receipts are actually made. At the end of the financial transaction, new type A keys are generated and properly installed. It should also be noted that the server will not keep any information for longer than the strictly necessary, even if it is protected and, at no time, will it know the content of the individual keys of each entity mentioned here. It will only act as a temporary data storage platform for the purpose of validating financial transactions between consumers and service providers.

[005] For illustrative purposes, imagine the following example: A person stays at an inn and goes out to have fun at a kiosk by the sea. Basically, the user of the service (paying, consumer of products or services, here the person of the guest) goes to a point of sale or, in this first example, to the lodging counter (operator) where he is staying. It does, right there, a registration in the system of our company. With this, he receives from the hosting a unique and non-transferable identifier code - iTokken contained or printed on a bracelet or any other medium. This identifier code can be transcribed as QR-Code or any other encoding, it also registers a password of your choice. With this (code and password), he goes to any establishment where he wants to consume products or services, in this example, a kiosk. When it is time to pay the bill, the credit receiver (merchant, kiosk owner) who also has an identifier code previously obtained upon registration, makes use of his smartphone or any other device connected to the internet to read this consumer's iTokken. Immediately, the third identifier code, that of the sale itself, is generated, which will contain the details of the sale or consumption, as well as the amount, date, time and other pertinent information. This information is immediately sent to the database for subsequent payment, that is, when the consumer, for example, leaves the place where he is staying. On this occasion, the values of your bank account are debited in the usual way, read money, debit or credit, or, if you choose, credits previously purchased on the system platform. In possession of the resources, the operator, in this example, the hosting, remits via bank transfer the correct amounts to the service provider (kiosk), to this company and himself withholds a certain commission. However, if you wish, this same guest can purchase the bracelet and credits directly from the company's platform, just like prepaid cards.

[006] The main feature of this payment method is the use of a responsive identifier code and encrypted systemic transfer of information without the need for specific HARDWARE for reading and validation, as is usual with the dummies.

[007] The central idea is to make it unnecessary to carry bank cards or any other valuable or useful objects that could be the object of absence or loss for any reason. It also brings, in the background, more comfort and convenience to the user and the merchant, service provider, as it makes it more accessible to carry out financial transactions without the need for debit and credit schemes, which are often expensive and impractical. It also differs from current payment apps like AndroidPAY, GooglePay, etc. as it is unnecessary for consumers to take their cell phone or cards with them.

[008] The remuneration of the company that owns this technology will be mainly due to the retention of percentages measured in the purchases of its users. Thus, a certain commission will be deducted from each financial transaction carried out. BLOCKCHAINS technology may be used on this occasion.

Claims (4)

“PAYMENT METHOD THAT DISPENSES THE USE OF DEBIT AND CREDIT MACHINES, cards AND other PHYSICAL tokens” characterized by being a computer system to provide different payments and receipts through the use of QRCode identifiers, or correlated ones, encrypted and use of end-to-end encryption for data transmission. It presents a certain inversion in the validation considerations, not only limiting the existence of bank balance, but also the effective existence of a financial transaction. “PAYMENT METHOD THAT DISPENSES USE OF DEBIT AND CREDIT MACHINES, cards and other physical tokens” ---- is characterized by presenting the computational system described in claim 1 and by being prepared as follows: use of programming languages, in due course , with different orientations, packages and libraries, servers and other computational resources. “PAYMENT METHOD THAT DISPENSES USE OF DEBIT AND CREDIT MACHINES, cards and other physical tokens” is characterized by presenting the components described in claim 1, being prepared according to claim 2 and the unnecessary of any token or electronic (for the consumer) during financial transaction. “PAYMENT METHOD THAT DISPENSES THE USE OF DEBIT AND CREDIT MACHINES, cards and other PHYSICAL TOKENS” is characterized by presenting the components described in claim 1, being prepared according to claim 2, presenting use according to claim 3 and the effect of "electronic commands" In this way, the use is extended to small service providers that may come together around a "centralizing" unit responsible for the effective delivery of values.

Images