Method for payment authorization on offline mobile devices with irreversibility assurance

Abstract

A methods for payment authorization (10) on mobile devices (DM) such as smartphones, tablets or any others available, which may be offline; the method for payment authorization (10) comprises the compilation of sequential steps of method (M1) of the payer (20) with method (M2) of the operational system (50) or application that constitutes a logical structure for alignment with the method (M3) of the payee (30), resulting in authenticated payment (PG) of financial transactions (TF) with assurance of “non-repudiation” through generation of a private key (51) and public key (52), as well as association of positive identification (21a) and personal identification (21b) of the payer (PG) with the mobile device (DM); said methods (M1), (M2) and (M3) are executed on mobile devices (DM) with enough processing capacity for execution of encryption algorithms and which may be used for issuing payment orders (PG), on-site or otherwise, carried out with financial resources (RF) or credit limits (LC) such as bonuses, points, products, tickets, etc. of the payer (20) of the device (DM).

Claims

1. A method for using a mobile device to implement offline payment authorization for financial transactions with non-repudiation assurance, said method comprising: receiving, at a payer mobile device, an indication of a positive identification of the payer mobile device for a user of the payer mobile device and a personal identifier for the user of the payer mobile device; generating, at the payer mobile device, a first association between the indication of the positive identification of the payer mobile device and the personal identifier for the user that indicates the payer mobile device is authorized to generate payment orders for the user; receiving, at the payer mobile device, an authentication credential from the user to be used for payment authorization; generating, at the payer mobile device, an asymmetric key pair having a private key and a public key for use in signing and verifying payment orders generated for the user; storing the private key in a data store of the payer mobile device and restricting access to the private key with the authentication credential; transmitting the public key and the first association from the payer mobile device to a payment authorization server system; and recording a second association between the public key and the first association at the payment authorization server system; wherein in response to receiving, at a payee data transfer device, a payment order for a transaction for the user that is signed with a digital signature using the private key, transmitting the payment order from the payee data transfer device to the payment authorization server system; verifying authenticity and integrity of the payment order by using the public key to validate the digital signature at the payment authorization server system; and upon verification of the payment order, processing the transaction for the user at the payment authorization server system, wherein the payment order is generated at the payer mobile device, being offline and disconnected from a payment authorization network, and transferred to the payee data transfer device from the payer mobile device without utilizing an online connection between the payee data transfer device and the payer mobile device wherein upon verifying the second association, the payment authorization server system registers an indication that the payer mobile device is authorized to generate payment orders for the user; wherein the payment authorization server system is operable to associate use restrictions for payment orders defined by the user with the indication that the payer mobile device is authorized to generate payment orders for the user; wherein the payment authorization server system is operable to, in response to a deactivation request from the user, delete the recording of the public key to prevent processing of payment orders generated for the user by the payer mobile device; wherein generating the payment order for the transaction at the payer mobile device comprises: receiving information input by the user for the transaction indicating a payable amount for the transaction, the payment authorization server system; and providing: a currency or type for the payable amount; a payment source for the user from which the payable amount is to be drawn; an identification of a purchase for which the payment order is being made; an identification of a payee for the transaction, any use restrictions specific to the payment order, validity of the payment order, one or more codes for each item or service being purchased, and/or other access credentials; and wherein generating the payment order for the transaction at the payer mobile device further comprises: preparing a grouping of data that includes the first association, unique identification information for the payment order, and an appropriate set of the information input by the user for the transaction to the payer mobile device; utilizing the authentication credential included in the information input by the user for the transaction to access the private key; and using the private key to create a digital signature for the grouping of data; wherein the payment order is transferred to the payee data transfer device from the payer mobile device as the grouping of data signed with the digital signature in an offline manner; and wherein the unique identification information for the payment order includes at least one of an identification of an account for the payee, a universal identifier for the payment, a mobile device identifier, and a timestamp for generation of the payment order.

2. The method of claim 1, wherein generating the asymmetric key pair, storing the private key in the data store of the payer mobile device, restricting access to the private key with the authentication credential, and transmitting the public key and the first association to the payment authorization server system are performed by the payer mobile device in response to generation of the first association.

3. The method of claim 1, wherein verifying the payment order at the payment authorization server system further comprises the payment authorization server system, upon receiving the payment order from the payee data transfer device, validating the transaction first by verifying the integrity of the payment order digital signature using the associated public key and then by confirming that each use restriction associated with the indication that the payer mobile device is authorized to generate payment orders for the user and each use restriction specific to the payment order that is indicated within the grouping of data is satisfied and confirming that the payment source indicated within the grouping of data has a sufficient available balance to cover the payable amount for the transaction indicated within the grouping of data; wherein the currency or type for the payable amount indicated within the grouping of data specifies that the payable amount for the transaction is selected from the group consisting of a monetary value, reward program points, a voucher, a bonus, a product, and a ticket; wherein if the currency or type for the payable amount specifies that the payable amount for the transaction is a monetary value, processing the transaction for the user comprises transferring the payable amount from the payment source to an account for the payee.

4. The method of claim 3, wherein each of one or more of the use restrictions specifies one of a location from which the payment order is received, a type of product for the purchase for which the payment order is being made, a type of service for the purchase for which the payment order is being made, and a time period during which the payment order is received that must be satisfied for the payment authorization server system to process the transaction for the user.

5. The method of claim 4, wherein the payment order is transferred to the payee data transfer device from the payer mobile device using a medium selected from the group consisting of a 1D or 2D bar code, visual signals, near-field communication, and sound waves.

Description

DESCRIPTION OF THE DRAWINGS

(1) FIG. 1 shows a diagram of the method assembly of the payer, system and payee that constitutes offline payment.

(2) FIG. 1A shows a flowchart providing a general overview of exemplary methods M1 and M2 described herein.

(3) FIG. 1B shows the optimized flowchart of the authorization phase of the payment order.

(4) FIG. 1C shows the payment order generation flowchart.

(5) FIG. 2 represents a block diagram of the logical sequence of the exemplary payer method M1.

(6) FIGS. 3 and 4 show block diagrams of the logical sequence of the exemplary payer method M2.

(7) FIG. 4A shows a flowchart for generation of the pair of keys (public and private) associated to the payer and its mobile device.

(8) FIG. 5 illustrates a block diagram of the logical sequence of the exemplary offline payment authorization method of the payee M3 and the Authorization Entity (ET).

(9) FIG. 5A shows the payment order generation flowchart.

(10) FIG. 5B shows a flowchart of an example of payment authorization.

DESCRIPTION OF THE INVENTION

(11) According to the figures, this invention relates to a “METHOD FOR PAYMENT AUTHORIZATION ON OFFLINE MOBILE DEVICES WITH IRREVERSIBILITY ASSURANCE”, more precisely relating to a method for payment authorization (10) on mobile payment devices (DM) such as smartphones, tablets or other devices available which may be offline.

(12) According to this invention, said method for payment authorization (10) is executed, especially, on mobile devices (DM) with enough processing capacity for executing encryption algorithms and which may be used for generating payment orders (PG), on-site or otherwise, using financial resources (RF) or credit limits (LC) such as bonuses, points, products, tickets, etc. of the payer (20) of the device (DM).

(13) Said method for payment authorization (10) comprises the compilation of sequential steps of the method (M1) of the payer (20) with the method (M2) of the operational system (50) or application that form a logical structure for alignment with the method (M3) of the payee (30), resulting in authenticated offline payment (PG) of financial transactions (TF) with “non-repudiation” assurance through generation of a private key (51) and a public key (52), as well as association of positive identification (21a) and personal identification (21b) of the payer (PG) with the mobile device (DM).

(14) In a preferred operational version, the method (M1) of the payer (20) starts with the steps for authorization request (21) for performance of the financial transaction (TF) through identification means (21a) and (21b) and association of the mobile device (DM) with the holder/payer (20) for execution of the financial transaction (TF). The steps (P1) for identification (21a) and (21b) are:

(15) a) Positive identification (21a) and preview of the holder/payer (20) of the device(s) (DM) used to perform the payments (PG). Said positive identification may be executed in many ways, such as digital certificate, on-site validation, notary office, credit bureaus, etc.;

(16) b) Personal identification (21b) of the payer 920) through the respective e-mail, tax identifier as the personal identification number, device (DM) identification, but in case the device is a smartphone, identification is made from the phone number through installation of the application (50) and other devices may have other forms of identification, as well as identification of other complementary information such as payer address;

(17) c) Request for association (21c) of the mobile device (DM) to its identity (21a) and (21b). The payer (20) may prove, optionally, that the holds the device (DM), but in case the device is a smartphone, said proof may be provided, for example, by sending a text message with a random number—code—to the device (DM) and requesting that the payer (20) inputs the code received to the application (50). Other devices may have unique serial numbers and the payer (20) must provide it during this action;

(18) d) Request the payer (20) to provide some sort of payment authorization key (PG), which may be represented by a security code (23)—PIN—, a biometric feature such as fingerprint, iris recognition, face, voice, etc. or any other means.

(19) After identification of the payer (20) the method (M2) of the operational system (50) follows with logical steps for association of the mobile device (DM) with the holder/payer (20) through the following steps (P2):

(20) a1) Generation of a pair of keys (51) and (52) through the application (50), one being a private key (51) and the other a public key (52) by means, for example, an RSA algorithm, or another with n-bits, in which n may be any proper number, such as 1024 or 2048, in order to ensure the security level of the keys (51)/(52), which may vary due to the typical amounts of financial transactions, for example;

(21) b1) The private key (51) is stored in the device (DM) while encrypted through some symmetric encryption mechanism (with the PIN as the key) which only allows recovery with the key defined on step (d);

(22) c1) The public key (52) with identifications (21a) and (21b) of the payer (PG) and device (DM) is sent to a payment authorization server (53) which, in turn, records the association between this device (DM) and the public key (52) of the holder (20) of the mobile device (DM). To perform this step, the payer's device (DM) must be online;

(23) d1) The holder (20) confirms the public key (52), confirming the device (DM) through respective identifications (51) and (52) or any other entity that may truthfully attest the person who can authorize the payments (PG), in the device (DM). Optionally the holder/payer (20) of the mobile device (DM) can establish use restrictions, such as location, product type and services to be paid, specific times for use, etc.;

(24) e1) After confirmation of the association of the holder/payer (20) and mobile device (DM), it is now registered and authorized to generate payment orders, transfer of financial resources or other similar activities;

(25) f1) For disqualification of the mobile device (DM) as means of payment, the holder/payer (20) can, for example, contact the customer service of the company that authorizes payments and request deactivation of the mobile device (DM). The simple removal of the corresponding public key (52) prevents that payment (PG) orders (O1) signed by the device (DM) are accepted thereafter.

(26) After the identification steps (21a) and (21b) and association of the possession of the mobile device (DM), the authorized holder/payer (20) to use the device (DM) for payments (PG) of various financial transactions (TF) proceeds with the following steps (P3):

(27) i. Communication of the amount (V1) of the transaction (TF);

(28) ii. Optionally, any additional information such as identification of the entity that will validate the payment (PG) order (O1), currency of the payable amount (V1), identification of the financial source in case the payer (20) has more than one current account, credit card, etc.;

(29) iii. Identification of the purchase such as order number, invoice, description, etc.;

(30) iv. Identification of the recipient/payee(s) (30) that are authorized to receive such payment (PG);

(31) v. Information of any other use restriction of the payment (PG) order (O1) such as determination of geographic region, specific purpose or any other restriction;

(32) vi. Validity of the payment (PG) order (O1);

(33) vii. Code(s) of the goods being traded;

(34) viii. Necessary information for access to the private key (51), in other words, PIN, biometry, etc.

(35) After obtaining information of the steps (P3) the method (M2) of the operational system (50) proceeds with the second sequence of logic steps, which are:

(36) a2) Grouping (P4), necessarily, with the identifications (21a)/(21b) of the payer (20) which issues the authorization, in other words, account number, fiscal identifier or any other identification form of the payer (20) to the system (50);

(37) b2) Grouping (P5) with information provided by the payer (20) and some information that ensure uniqueness of this payment (PG) order (O1), for example: i) identification of the payee's account; ii) universal identifier—UUID—of the payment; iii) mobile device identifier (DM); iv) timestamp such as date/time at the moment of generation of the authorization; v) a combination of this information; vi) other that may be applicable;

(38) c2) From the information of the step (P3) and grouping (P4) and (P5), the device (DM) generates a payment (PG) authorization (P6), such as a byte sequence that provides the payment data (PG), additionally with a digital signature using the private key (51) of the holder/payer (20) of the mobile device (DM), through any common algorithm for this purpose such as SHA+RSA, MD5+RSA, etc.;

(39) d2) All data mentioned in steps (P3), (P4) and (P5), with the digital signature generated in step (P6) constitute the authorization (AT) of the payment (PG) order (O1);

(40) e2) The authorization (AT) generated in the previous step (d) is then transferred to the payee (30) of the payment (PG), either through a bar code, visual signals, electromagnetic waves, sound waves, etc.

(41) The Method (M3) of the payee (30), after receiving the payment (PG) order (O1), proceeds with the following steps:

(42) a3) Sending of the payment (PG) order (O1) to the entity (ET) that authorizes and settles the payment (PG), with said entity (ET) typically being a bank, payment institution, credit company or similar;

(43) b3) Said entity (ET) verifies if the authorization is valid, analyzing all pertaining restrictions, such as location, spending limits, balance available, existing account, etc. For such, the payee's device (30) needs an online mechanism for communication between the payee's device (30) and the entity (ET) that authorizes it, or any kind of trust bond between the payer (20) and the payee (30), so that the recipient may act on behalf of the entity (ET), even when offline. In this last case, the payee takes the risk that the payment order may not be authorized afterwards by the (ET);

(44) c3) After the information of the financial transaction (TF) is validated, the authorizing entity (ET) checks the authenticity of the digital signature, comparing the payment (PG) information with the public key (52) previously registered for the device during step (e) of the method (M2) of the operational system (50). The validation of the signature ensures that such order (O1) is indeed generated by the device (DM) authorized and signed with the private key (51) of the holder/payer (20) and, therefore, free of tampering prior to reaching the ET;

(45) d3) After validation of the steps (b) and (c), the payment (PG) order (O1) is processed, transferring funds from the payer's (20) account to the payee's (30) account or generating any effect needed for such payment order (PG) to be processed, which may not necessarily involve money, but also credit from reward programs, shopping vouchers, etc.;

(46) e3) Afterwards the payee's device (30) is notified about the transaction taking place, which is then concluded and recorded.

(47) It should be noted, then, that the technical evolution of this invention lies in the methods (M1), (M2) and (M3) herein featuring the ability of the authorization server in authorizing a payment (PG) order (O1) generated by the mobile device (DM) of the payer (20) without any connection between the payer (20) and the authorization server, enabling the payer (20) to be completely offline, with only a screen to show a bar code, a speaker for producing sounds, an NFC or any other means for sending a small amount of data to the sales device (DM) of the vendor (30) in an unidirectional manner.

(48) Another relevant aspect of this invention is the combination of various encryption techniques and digital signature for generating a digital representation capable of ensuring authenticity of its information (payer, amount and other additional information).

(49) Another relevant aspect refers to the optimization of the implementation of encryption algorithms, digital signature and generation of the digital code so that the processing requisites are compatible with the capacity of most current mobile devices (CPU, memory, screen resolution).

(50) Aside from the optimization related to the implementation of the aforementioned algorithms, optimization of the digital representation may also be mentioned, regarding the amount of bits needed to store all information of the payment order.

(51) It is certain that when this invention is put into practice, modifications may be introduced concerning certain construction and shaping details, without departing from the base principles that are clearly substantiated in the set of claims, therefore considering that the terminology used is not limiting in any sense.