AU2020101863A4 - IoT-Based Micropayment Protocol for Wearable Devices with Unique Verification - Google Patents

Abstract

Patent Title: loT-Based Micropayment Protocol for Wearable Devices with Unique Verification ABSTRACT My Invention "loT-Based Micropayment Protocol for Wearable Devices with Unique Verification" is a micropayment system and method is presented for a Payor U to establish payment to Payee-M for a Transaction-T, which typically has a very low value Tv. The invented micropayment scheme minimizes the bank's processing costs, while at the same time eliminating the need for users and merchants to interact in order to determine whether a given micropayment should be selected for payment. the micropayment scheme includes time constraints, which require that an electronic Check-C for the Transaction-T be presented to a Bank-B for payment within a predetermined location, time, date, interval. The invented micropayment scheme includes a deferred selection protocol, which provides the bank with control and flexibility over the payment selection process. The invented wearable device is one of the parts of the essential (COGS) Cost of Goods Sold in the wheel of the Internet of things (loT) contributing towards a potential impact in finance and banking sectors. The invention also lightweight cryptography mechanisms for loT devices because these are resource constraints a novel approach of an loT-based micropayment protocol in wearable devices environment is introduced. The invention can use the payment model "(ECIES) elliptic curve integrated encryption scheme "for encryption and decryption of the communicating messages between various entities. The invention provides the customer to buy the goods using a wearable device and sent the confidential payment information to the mobile application and creates a secure session between the customer, banks and merchant. The static security analysis and informal security methods indicate that the invented protocol is withstanding the various security vulnerabilities involved in mobile payments. For logical verification of the correctness of security properties using the formal way of "(BAN) Burrows-Abadi Needham " logic confirms the accuracy of the invented protocol. The practical simulation and validation using Scyther and Tamarin tool ensure the absence of security attacks in our scheme. Finally, the performance analysis based on cryptography features and computational overhead of related approaches specify that the proposed micropayment protocol for wearable devices is secure and efficient. Dr. B. Madhuravani (Professor) Mrs. Sameera Divanu (Assistant Professor) Mrs. M. Trupthi (Assistant Professor) Mrs. Gnyanadeepa Yaganti (Assistant Professor) Mrs. K Swathi (Assistant Professor) Mrs. Sneha Bushetty (Assistant Professor) Kuntimalla Sudheer Babu (Assistant Professor) Dr. Yugandhar Garapati (Assistant Professor) Sri Sowmya Gudipati (Assistant Professor) Ponnuru Sowjanya (Assistant Professor) TOTAL NO OF SHEET: 12 NO OF FIG: 12 TOERVEWAMC STUDMCRET TASC NONSc m <*YES M CAUSES BANkK B YO> DIB CAUDBS CORH AT To&AMmaI s01waAkD TRANACTONS

Description

Dr. B. Madhuravani (Professor) Mrs. Sameera Divanu (Assistant Professor) Mrs. M. Trupthi (Assistant Professor) Mrs. Gnyanadeepa Yaganti (Assistant Professor) Mrs. K Swathi (Assistant Professor) Mrs. Sneha Bushetty (Assistant Professor) Kuntimalla Sudheer Babu (Assistant Professor) Dr. Yugandhar Garapati (Assistant Professor) Sri Sowmya Gudipati (Assistant Professor) Ponnuru Sowjanya (Assistant Professor) TOTAL NO OF SHEET: 12 NO OF FIG: 12

TOERVEWAMC STUDMCRET TASC NONSc

m

<*YES M CAUSES BANkK B YO>

DIB CAUDBS CORH AT To&AMmaI s01waAkD

TRANACTONS

Australian Government IP Australia Innovation Patent Australia Patent Title: IoT-Based Micropayment Protocol for Wearable Devices with Unique Verification Name and address of patentees(s): Dr. B. Madhuravani (Professor) Address: Department of CSE, MLR Institute of Technology, Dundigal, Hyderabad, Telangana 500043, India. E-mail: madhuravani.peddi@gmail.com Mrs. Sameera Divanu (Assistant Professor) Address: Department of Information Technology, B V Raju Institute of Technology, Narsapur, Medak District - 502313, Telangana, India. E-mail:sameerach@gmail.com Mrs. M. Trupthi (Assistant Professor) Assistant Professor, Department of Information Technology, Chaitanya Bharathi Institute of Technology(A), Gandipet, Hyderabad, Telangana-500075, India. E-mail: trupthijan@gmail.com Mrs. Gnyanadeepa Yaganti (Assistant Professor) Address: Department of Information Technology, Chaitanya Bharathi Institute of Technology(A), Gandipet, Hyderabad, Telangana-500075, India. E-mail: deepayg@gmail.com Mrs. K Swathi (Assistant Professor) Address: Department of Information Technology, Chaitanya Bharathi Institute of Technology(A), Gandipet, Hyderabad, Telangana-500075, India. E-mail: kswathi2710@gmail.com Mrs. Sneha Bushetty (Assistant Professor) Address: Department of Computer Science & Engineering, BVRIT Hyderabad College of Engineering for Women, Rajiv Gandhi Nagar Colony, Nizampet Rd, Hyderabad - 500090, Telangana, India. E-mail:sneha1779@gmail.com Kuntimalla Sudheer Babu (Assistant Professor) Address: Department of Computer Science and Engineering, Gokaraju Rangaraju Institute of Engineering and Technology, Nizampet Road, Bachupally, Hyderabad, Telangana-500090, India. E-mail: sudheerkuntumalla@gmail.com Dr. Yugandhar Garapati (Assistant Professor) Address: Department of Computer Science & Engineering, GITAM (Deemed to be University), Hyderabad, Telangana - 502329, India. E-mail: yugandhar.garapati@gmail.com Sri Sowmya Gudipati (Assistant Professor) Address: Department of Computer Science & Engineering, GITAM (Deemed to be University), Hyderabad, Telangana-502329, India. E-mail: sowmya.aries@gmail.com Ponnuru Sowjanya (Assistant Professor) Address: Department of Computer Science & Engineering, GITAM (Deemed to be University), Hyderabad, Telangana- 502329, India. E-mail: sowjanya.ponnuru@gmail.com Complete Specification: Australian Government

FIELD OF THE INVENTION

My Invention "loT-Based Micropayment Protocol for Wearable Devices with Unique Verification "is related (Computer Engineering) to cryptographic mechanisms for secure (e.g., secret) communication, and use of intermediary entities to perform cryptographic operations.

BACKGROUND OF THE INVENTION

The growth in electronic commerce systems has led to a rapid growth in the number of financial transactions taking place across electronic networks. Micropayments enable new forms of electronic commerce transactions, by providing a convenient method for financing on-line low-value services such as information retrieval services. Micropayments may have very low value-in some cases fractions of a penny-but may be executed in very high volumes. By way of example, information service providers may wish to charge for their services in small increments. Micropayments may be used to pay for each web page visited or for each minute of music or video streamed to the user.

In a public key cryptosystem, a sender who wishes to secretly send a message obtains the receiver's public key and uses it to encrypt the message. Upon receiving the encrypted message, the receiver uses his matching private key to decrypt it and read the original message. Without access to the matching private key, it is computationally infeasible to decrypt the encrypted message. In a public key digital signature scheme, a signer of a message creates his digital signature by applying his private key to the message. The resulting digital signature is thus unique to both the message and to the particular private key used to create the digital signature. Anyone in possession of the message and the digital signature can verify the authenticity of the digital signature using the signer's public key.

A hash function is also used in many public key digital signature schemes. A hash function is an algorithm which, when applied to a message, creates a digital "fingerprint" of the message, in the form of a "hash value" that typically has a fixed length. A "one-way collision-resistant" (or secure) hash function is a hash function for which it is computationally infeasible to derive the original message from its hash value, or even to find two messages having the same hash value. The hash of a message thus works well as an identifying "fingerprint" for the message, since if one makes any change, even the slightest change, to a message, one invariably obtains a message with a different hash value. It is common to use hash functions in digital signature schemes in a "hash and sign" manner. To create a digital signature in this way, the sender of a message applies a hash function to the message, thus computing a message digest or hash value for the message. The sender then applies his private key to the hash value to obtain his digital signature for that message.

The authenticity of the digital signature, as well as the integrity of the contents of the message, can be verified using the sender's public key and the hash function that was used to create the signature. The receiver can verify that the message was indeed signed by the sender by recomputing the hash value for the message, and then applying a verification procedure that takes as inputs this hash value and the sender's public key. The verification procedure might say, for example, to use the sender's public key as a decryption key and to accept the signature as valid if the decryption yields the recomputed hash value of the message. If verification succeeds, the receiver may be confident that the sender actually signed the message and that the message was not altered since it was signed.

In a typical electronic check payment scheme, a user pays a merchant for a transaction by providing a digital signature to a piece of data that identifies the transaction. The data may identify, among other things, the user, the user's bank account number, the merchant, the amount to be paid, the time of the transaction, and/or the information, services, or merchandise that has been purchased. Typically, the merchant deposits the electronic check that he receives from the user by sending the check to the bank. The digital signature capabilities in an electronic check scheme may be supported by digital certificates. A digital certificate is most commonly an electronic document that asserts that a particular individual holds the private key corresponding to the public key given in the certificate. In other words, the certificate correlates a key pair with a particular party. Since the certificate is itself digitally signed by a trusted authority, a digital certificate is normally trusted as proof that the named party indeed owns the public key listed in the certificate and that the named party exclusively controls the corresponding private key. Digital certificates may also assert that the party is authorized to sign electronic payments or perform other specified actions.

After verifying the digital signature on an electronic check, the bank may credit the merchant with an appropriate amount, and may debit the user with an appropriate amount. The bank may also charge discretionary transaction fees or other fees. Electronic payment systems, and in particular micropayment systems, face many challenges. A fundamental problem with micropayments lies in a bank's processing costs for the micropayments. Frequently, the cost to the bank of handling a micropayment transaction will be many times larger than the value of the micropayment itself. For example, processing a credit card transaction usually costs about 25 cents, while a typical micropayment may be worth about 1 cent or less. Exceptional efficiency is therefore required in order to support micropayments; otherwise the cost of the payment mechanism will much exceed the value of the payments.

Micropayment schemes therefore attempt to reduce the bank's processing costs by aggregating many small payments into fewer, larger payments. A variety of aggregation strategies are available. Some micropayment schemes have session-level aggregation: all payments between a user and a merchant during a given "session" are aggregated into a single larger payment. Another strategy is global aggregation: payments are aggregated across all user/merchant pairs. Global aggregation can provide. The electronic lottery scheme by Rivest provides another method for aggregating micropayments, so as to reduce transaction costs. This scheme is based on a selection rate or selection probability s (<s<1) for each micropayment: on average, only one out of every 1/s micropayments is selected for actual payment. The selection rate s is known, predictable, and fixed. For each micropayment presented to the merchant, the merchant first verifies the user's signature on the root wo of the Pay Word chain and verifies that the provided hash valuewkindeed yields wowhen iteratively hashed k times. If so, the merchant accepts the micropayment from the user. The merchant then goes through a predetermined interaction protocol with the user, in order to determine whether or not the micropayment should be selected for deposit at the bank.

A non-selected check cannot be deposited and is thus worthless to the merchant; it is thus discarded by the merchant. Only a micropayment that is selected (through the interaction protocol) is actually presented to the bank by the merchant, in order to receive payment. In this way, the bank does not have to process each and every micropayment, but only processes, on average, one out of 1/s micropayments. The bank's processing costs are thereby greatly reduced. To make this process fair to the merchant, for each selected micropayment, the merchant gets paid an amount 1/s times greater than the originally specified micropayment amount. In other words, the bank pays to the merchant an amount that is "scaled" to a value 1/s times the face value of the micropayment.

Despite its advantages, the electronic lottery scheme suffers from the drawback that the user and the merchant must interact for each micropayment, in order to determine whether a particular micropayment should be selected for deposit. This requirement considerably slows down the electronic payment system, and in some cases renders the scheme impracticable. For the foregoing reasons, there is a need for a non interactive micropayment method and system, which allow global aggregation of micropayments to minimize bank processing costs, but which at the same time do not require user-merchant interaction in the micropayment selection process.

The incorporate time constraints into a micropayment system. For example, it would be advantageous to include in a micropayment system time constraint that require the merchant to deposit any payable check (i.e. a micropayment that is properly selected for deposit) in the bank within a reasonable time period, in order to receive payment from the bank. In this way, the user would not be charged too late, i.e. when a possible expenditure for the transaction is no longer in his budget. This type of constraint would also give an extra incentive to the merchant to verify that the time information on a check C is accurate, thereby enhancing the security of the system.

The probabilistic micropayment schemes, besides the inefficiency caused by user merchant interaction in the selection process, is the risk to the user of being charged in excess of what he actually spends. A user in a probabilistic micropayment scheme must deal with the probability (albeit small) that in some cases, by bad luck, he may have to pay more than what he actually spent. Such occurrences may be rare, and the relative impact of such a rare occurrence may decrease dramatically with the number of micropayments made. Nonetheless, the possibility, however slim, of being excessively charged may constitute a strong obstacle to a widespread acceptance of the scheme. This is because ordinary users are generally not accustomed to managing risk.

For the foregoing reasons, there is a need for a micropayment method and system, which not only minimizes bank processing costs, but also guarantee that the user is never charged in excess of what he actually spends. Finally, micropayment systems which attempt to increase their efficiency generally call the bank into action only with respect to those payments that have been selected for payment by the merchant, and that generally constitute only a small fraction of the total number of payments. Such micropayment systems, however, do not provide the bank with any flexibility or control over the payment selection process. Such control may be advantageous to the bank in managing its risk.

It is therefore desirable that a micropayment scheme be available which not only eliminates the need for user-merchant interaction in the selection process, and shifts the risk of excessive payment away from the user to the bank or the merchant, but also provides the bank with some flexibility and control over the payment selection process. Multiple activities are involved in processing a transaction between a consumer and a merchant for a product or service that is payable upon an account issued to the consumer by an issuer within a payment processing system. Typically, processing of the transaction involves an authorization activity followed by a clearing and settlement activity (collectively "remittance"). Clearing includes the exchange of financial information between the issuer and an acquirer of the merchant and settlement includes the transfer of funds.

Referring to FIG. 1, a cross-functional flow chart depicts an exemplary method of authorizing and remitting a transaction using an account identifier of the account. When the merchant and the consumer engage in the transaction, the consumer may give the merchant the account identifier (e.g., the account number) of a corresponding account of the consumer upon which the transaction is to be made payable. The account identifier is then used throughout both the authorization and the remittance of the transaction to distinguish the transaction from among many of the transactions.

PRIOR ART SEARCH S4868877A *1988-02-121989-09-19Fischer Addison M Public key/signature cryptosystem with enhanced digital signature certification. US4995082A *1989-02-241991-02-19Schnorr Claus P Method for identifying subscribers and for generating and verifying electronic signatures in a data exchange system. US5218637A *1987-09-071993-06-08L'etat Francaise Represente Par Le Ministre Des Postes, Des Telecommunications Et De L'espace Method of transferring a secret, by the exchange of two certificates between two microcomputers which establish reciprocal authorization. US5231668A *1991-07-261993-07-27The United States Of America, As Represented By The Secretary Of Commerce Digital signature algorithm. US5420926A1994-01-051995-05-30At&T Corp. Anonymous credit card transactions. US5530232A1993-12-221996-06-25Datamark Services, Inc. Multi-application data card. US5557516A1994-02-041996-09-17Mastercard International System and method for conducting cashless transactions. W01996029668A11995-03-211996-09-26Maritz Inc. Debit card system and method for implementing incentive award program. US5578808A1993-12-221996-11-26Datamark Services, Inc. Data card that can be used for transactions involving separate card issuers. US5606617A *1994-10-141997-02-25Brands; Stefanus A. Secret-key certificates. S20020087344A1 *2000-10-242002-07-04Billings Sarah T. System and method for collecting information to facilitate enrolment in an electronic funds transfer program. US20020120582A1 *2001-02-262002-08-29Stephen Elston Method for establishing an electronic commerce account. US20030200184A1 *2002-04-172003-10-23Visa International Service Association Mobile account authentication service. US20050119972A1 *2000-03-302005-06-02Inglis Frank S. System, method, and article of manufacture for secure payment utilizing a computer network. US20080052182A1 *2006-08-282008-02-28Choicepay, Inc. Method and system to accept and settle transaction payments for an unbanked consumer.

US20080059306A1 *2006-08-312008-03-06Fordyce Edward W-Loyalty program incentive determination. FR2536928A1 *1982-11-301984-06-01France Etta System for enciphering and deciphering information, of the type using a public key deciphering system. US4745568A *1986-12-161988-05-17Onyszchuk Ivan M Computational method and apparatus for finite field multiplication. US4748668A*1986-07-091988-05-3lYeda Research And Development Company Limited Method, apparatus and article for identification and signature. US4890323A *1986-05-221989-12-26Racal-Guardata Limited Data communication systems and methods. US4989171A*1988-10-181991-01-29U.S. Philips Corporation Data processing method and apparatus for calculating a multiplicatively inverted element of a finite field. WO1991016691A1 *1990-04-121991-10-31Jonhig Limited Value transfer system. US5146500A *1991-03-141992-09-080mnisec A.G. Public key cryptographic system using elliptic curves over rings. US5150411A *1990-10-241992-09-22OmnisecCryptographic system allowing encrypted communication between users with a secure mutual cipher key determined without user interaction.

Conventional public-key encryption schemes allow an entity holding a private key related to some public key to decrypt cipher texts encrypted under said public key. The encryption scheme proposed by Megamall is one example of public-key encryption scheme (see Megamall, T. (1984, August). A public key cryptosystem and a signature scheme based on discrete logarithms. In Workshop on the Theory and Application of Cryptographic Techniques (pp. 10-18). Springer Berlin Heidelberg.) Public-key encryption is one of the basic tools of public-key infrastructures. Among other uses, public key encryption provides an algorithm by which one party (e.g., Alice) can communicate with another (e.g., Bob) over an untrusted channel without a shared secret key being known to both sender and receiver. For example, Alice, upon determining to send a plaintext message to Bob, might obtain Bob's public key. This public key algorithmically corresponds to a private (and secret) key held by Bob, but unknown to Alice and others. The nature of this correspondence is such that, once Alice encrypts the message into a cypher text with Bob's public key, only the party with the corresponding private key (i.e., Bob) can decrypt the message. Similar use cases exist for cryptographic signatures, where a party's public key is used to verify that an entity with access to the corresponding private key signed a document. In some cases, public-key encryption is used to exchange a symmetric encryption key (e.g., a shared secret, high entropy value) that is then used to encrypt and decrypt subsequent messages more efficiently than with public-key encryption.

In recent years, research on more advanced functionalities has been conducted in relation with public-key encryption, leading to schemes where decryption of cipher texts originally encrypted by some public key can be performed with a private key not associated with said public key. This is what is known as "Proxy re-encryption" by the scientific community. There are several proxy re-encryption schemes in the literature, being the most prominent those based on Megamall public-key encryption scheme, such as the ones proposed by Blaze et al. (see Blaze, M., Bleumer, G., & Strauss, M. (1998, May). Divertible protocols and atomic proxy cryptography. In International Conference on the Theory and Applications of Cryptographic Techniques (pp. 127 144). Springer Berlin Heidelberg) and Ateniese et al. (see Ateniese, G., Fu, K., Green, M., & Rosenberger, S. (2006). Improved proxy re-encryption schemes with applications to secure distributed storage. ACM Transactions on Information and System Security (TISSEC), 9(1), 1-30.)). However, none of the proxy re-encryption schemes to date is compatible with any encryption standard due to a variety of technical problems that remain to be solved to achieve compatibility.

One standard expected to see even broader use in the future is the Elliptic Curve Integrated Encryption Scheme (ECIES) standard, which is a hybrid encryption algorithm based on elliptic curves, defined by the ANSI X9.63 standard (see American National Standard for Financial Services. (2011). X9.63-2011. Public Key Cryptography for the Financial Services Industry: Key Agreement and Key Transport using Elliptic Curve Cryptography), where it is simply called Asymmetric Encryption Scheme. This algorithm is of public knowledge, and variants have been standardized also by ISO/IEC and IEEE. When producing a cipher text with ECIES, the sender first creates an ephemeral public key and uses it in a Diffie-Hellman key agreement together with the public key of the intended recipient. The resulting shared secret is used to create the keys for the symmetric encryption and message authentication code algorithms used internally. The final cipher text contains the ephemeral public key, which is used for decryption, and the outputs of the symmetric encryption and message authentication code algorithms.

Conditional access systems are well known and widely used in conjunction with currently available pay television systems. At present, such systems are based on the transmission of services encrypted with control words (also referred to as service encryption keys) that are received by subscribers having a set-top box and a smartcard for each subscription package.

Typically, these services are transmitted by a head-end system in a broadcast stream. Implementations are known wherein set-top box functionality is integrated into a device like a television, a personal video recorder, a mobile phone, a smart phone or a computer appliance. Smartcard implementations are known wherein the smartcard is a separate card that is manually inserted into the set-top box before operation or a surface mounted device integrated into the set-top box. Software implemented smartcards are known that run as a software module in the set-top box. The smartcard for a subscription package from a particular service provider allows the encrypted services within the package to be decrypted and viewed. The broadcast stream further contains entitlement management messages (EMMs), also referred to as key management messages (KMMs), and entitlement control messages (ECMs), which are necessary for the smartcard to decrypt the service. The control word is the primary security mechanism for protecting the service data and changes relatively frequently.

ECMs are used to carry the control word in encrypted form, and are therefore sent relatively frequently. EMMs are used to convey the secret keys used to decrypt the ECMs to extract the control word, to decrypt other data related to the addition or removal of viewing/usage rights, and/or to decrypt other user-specific data. As such there are different kinds of EMMs, which 2 are sent with varying degrees of frequency, but invariably somewhat slower or much slower than the frequency at which ECMs are sent. Elliptic curve cryptography is a known technique for encrypting and digitally signing messages such as EMMs and ECMs.

An elliptic curve cryptosystem implementing an elliptic curve cryptographic technique performs arithmetic operations on an elliptic curve over a finite field determined by predefined elliptic curve domain parameters. The elliptic curve domain parameters are stored in the head-end system for encryption and signing purposes and stored on the smartcard for decryption and signature verification purposes.

Elliptic curve cryptography typically uses one of the following elliptic curve domain parameters: elliptic curve domain parameters over finite field IFp and elliptic curve domain parameters over IF2-m.

The elliptic curve domain parameters over 1FP are p, a, b, G, n and h. Parameter p is a prime specifying the finite field IFP. Parameters aEIFp and belFP specify the elliptic curve E(IEP) defined by the equation y2=x3+a*x+b. Parameter G is a base point (GX, Gy) of a cyclic subgroup of points on the elliptic curve. Parameter n is the order of G, i.e. the smallest non-negative prime number n such that n=G = 0 (0 being a point at infinity).

Parameter h is the cofactor IE(]Fp)I/n.

The elliptic curve domain parameters over IF2-m are m, f(x), a, b, G, n and h. Parameter m is an integer specifying the finite field IF2Am. Parameter f(x) is an irreducible binary polynomial of degree m specifying the representation of ZF2-,

Parameters aE1E'2-m and bEIFZAm specify the elliptic curve E(IF2Am) defined by the equation y2+x*y=x3+a*x2+b in 7F2m. Parameter G is a base point (GX,Gy) of a cyclic subgroup of points on the elliptic curve. Parameter n is the order of G, i.e. the smallest non-negative prime number n such that n=G = 0 (0 being a point at infinity)

. Parameter h is the cofactor E(IF2Am) I /n.

Encryption is the process of transforming information (also known as plaintext) using an algorithm (also known as a cipher) to make it unreadable to anyone except those possessing a decryption key. A known public-key encryption sdheme based on elliptic curve cryptography is the Elliptic Curve Integrated

Encryption Scheme (ECIES). ECIES is described in e.g. M.

Abdalla, M. Bellare, P. Rogaway, "DHAES: An encryption scheme based on the Diffie Hellman problem", http://www-cse.ucsd.edu

/ users / mihir / papers / dhies.html, 18 September 2001' and is standardized in e.g. ANSI X9.63 and IEEE P1363A, which are incorporated by reference in its entirely in the present application. ECIES uses the receiver's private key (denoted as parameter dreceiver) and public key (denoted as parameter Qreceiver) in the encryption/decryption process. Herein, parameter dreceiver is typically a randomly selected integer in the interval [1,n-1] . Parameter Qreceiver typically equals dreceiver'G-To encrypt a plaintext message using ECIES, the head-end system performs the following steps. Firstly, a random number r is generated and a random point R=r=G is calculated resulting in R= (R,., Ry) . Secondly, a shared secret S=Px is derived, where P= ( PX, Py) =r = Qreceiver (and P is not a point at infinity).

Thirdly, a key derivation function (KDF), such as KDF1 or KDF2 as defined in ISO/IEC 18033-2, is used to derive a symmetric encryption key by calculating kE=KDF(S). Fourthly, the message is encrypted using the encryption key kE by calculating E(kE;message). Fifthly the result of the encryption is output as Rllencryptedmessage, i.e. random point R concatenated with the encrypted message. To decrypt the message using ECIES, the smartcard performs the following steps. Firstly, the shared secret S=PX is derived, where P= ( PX, Py) =dreceiver *R. Secondly, the KDF is used to derive the symmetric encryption key by calculating kE=KDF(S). Thirdly, the message is decrypted using the encryption key KE by calculating E 1(kE;encryptedmessage).

A digital signature is a type of asymmetric cryptography used to simulate the security properties of a handwritten signature on paper. A digital signature provides authentication of a message. A known public-key signature algorithm based on elliptic curve cryptography is the Elliptic Curve Digital Signature Algorithm (ECDSA). ECDSA is standardized in e.g. ANSI X9.62, FIPS 186-2, IEEE P1363 and ISO 15946-2, which are incorporated by reference in its entirely in the present application. ECDSA uses the sender's private key (denoted as parameter dsenaer) and public key (denoted as parameter Qsender) in the signing/verification process. Herein, parameter dsender is typically a randomly selected integer in the interval [1,n-1] . Parameter Qsender typically equals dsender'G.

To digitally sign a message using ECDSA, the head-end system performs the following steps. Firstly, a hash e of the message is calculate as e=H(message), where H is a cryptographic hash function such as SHA-1 as defined in FIPS PUB 180-1. Secondly, a random integer k is selected from [1,n-1]. Thirdly, signature component signature=Xi (mod n) is calculated, where (xi, yl) =k= G. If signature equals 0, the second step is repeated.

Fourthly, signature component Signature=kl* (e+rsignature*dsender) (mod n) is calculated. If Ssignature equals 0, the second step is repeated. Fifthly, the resulting signature is output as rsignature I I Ssignaturer i.e. signature component rsignature concatenated with signature component Ssignature =

To verify the digital signature of the message using ECDSA, the smartcard performs the following steps. Firstly, it is verified that signature component rsignature and signature component Ssignature are integers in [ I, n-I ] . I f not, the signature is invalid. Secondly, the hash e of the message is calculated as e=H(message), where H is the same function used in the signature generation. Thirdly, w=ssignature-' (mod n) is calculated. Fourthly, ul=e*w (mod n) and u2=rsignature*w (mod n) are calculated. Fifthly, (xi, yl) =ul = G+u2 = Qsender is calculated. Sixthly it is concluded that the signature is valid if X1=rsignature (mod n) or invalid otherwise.

The process of both encrypting and digitally signing data is also known as signcryption. In Fig.1A a prior art example of an EMM or ECM before and after applying ECIES encryption is shown. The unencrypted ECM/EMM 10 in this example has a 6-byte header 11 and a 50-byte payload 12. The payload 12 is encrypted using ECIES and a 192-byte public key. This is also known as encrypting using ECC-192. The resulting encrypted EMM/ECM 20 contains the header 11, a 48-byte random point R=(RX, Ry) 21 and a 50-byte encrypted payload 22. Thus, the encrypted EMM/ECM packet 20 in this example is 48 bytes longer after encryption due to a 48-byte overhead of random point R 21. It is possible to use a public key of a different size, resulting in a random point R= (R,s, Ry) of a different size.

Fig.1B a prior art example of an encrypted EMM or ECM before and after applying ECDSA digitally signing is shown.

The encrypted EMM/ECM 20 in this example has a 6-byte header 11, a 48-byte random point R(RX,Ry) 21 and a 50-byte encrypted 5 payload 22. The encrypted EMM/ECM is digitally signed using ECDSA and a 192-byte public key. This is also known as digitally signing using ECC-192. The resulting signed and encrypted EMM/ECM 30 contains the encrypted ECM 20, a 24-byte signature component rsignature 31 and a 24-byte signature component Ssignature 32. Thus, the digitally signed and encrypted ECM packet 30 in this example is 48 bytes longer after digitally signing due to a 24-byte overhead of signature components rsignature 31 and a 24 byte overhead of signature component Ssignature 32. It is possible to use a public key of a different size, resulting in signature components of a different size.

ECIES and ECDSA increase the size of messages. In the example of ECC-192 a total of 96 bytes are added to the message after applying ECIES and ECDSA. For EMMs and ECMs with a typical data packet size of 184 bytes, this overhead is significant. In EP0874307A1 a method is disclosed for multiplication of a point P on elliptic curve E by a value k in order to derive a point kP. The method is disclosed for elliptic curves in a binary field IF2^m only. The method comprises the steps of representing the number k as vector of binary digits stored in a register and forming a sequence of point pairs (P1, P2) wherein the point pairs differed most by P and wherein the successive series of point pairs are selected either by computing (2mP, (2m+) P) from (mP, (m+l) P) or ((2m+1) P, (2m+2) P) from (mP, (m+) P). The computations may be performed without using the y-coordinate of the points during the computation while allowing the y-coordinate to be extracted at the end of the computations, thus, avoiding the use of inversion operations during the computation and therefore, speeding up the cryptographic processor functions. EP0874307A1 also discloses a method for accelerating signature verification between two parties. In EP0874307A1 signcrypted messages disadvantageously have an increased size due to overhead added to the messages by encrypting and digitally signing the messages.

OBJECTIVES OF THE INVENTION 1. The objective of the invention is to a micropayment system and method is presented for a Payor-U to establish payment to Payee-M for a Transaction-T, which typically has a very low value Tv. The invented micropayment scheme minimizes the bank's processing costs, while at the same time eliminating the need for users and merchants to interact in order to determine whether a given micropayment should be selected for payment. 2. The other objective of the invention is to the micropayment scheme includes time constraints, which require that an electronic Check-C for the Transaction-T be presented to a Bank-B for payment within a predetermined location, time, date, interval. The invented micropayment scheme includes a deferred selection protocol, which provides the bank with control and flexibility over the payment selection process. 3. The other objective of the invention is to the invented wearable device is one of the parts of the essential (COGS) Cost of Goods Sold in the wheel of the Internet of things (loT) contributing towards a potential impact in finance and banking sectors. 4. The other objective of the invention is to the invention also lightweight cryptography mechanisms for loT devices because these are resource constraints a novel approach of an loT-based micropayment protocol in wearable devices environment is introduced. 5. The other objective of the invention is to the invention can use the payment model "(ECIES) elliptic curve integrated encryption scheme "for encryption and decryption of the communicating messages between various entities. 6. The other objective of the invention is to the invention provides the customer to buy the goods using a wearable device and sent the confidential payment information to the mobile application and creates a secure session between the customer, banks and merchant. 7. The other objective of the invention is to the static security analysis and informal security methods indicate that the invented protocol is withstanding the various security vulnerabilities involved in mobile payments. For logical verification of the correctness of security properties using the formal way of "(BAN) Burrows Abadi-Needham " logic confirms the accuracy of the invented protocol. 8. The other objective of the invention is to the practical simulation and validation using Scyther and Tamarin tool ensure the absence of security attacks in our scheme. Finally, the performance analysis based on cryptography features and computational overhead of related approaches specify that the proposed micropayment protocol for wearable devices is secure and efficient.

SUMMARY OF THE INVENTION

The present invention relates to probabilistic micropayment schemes, which allow a user U (or other payor, henceforth referred to as "U" or "user") to establish payment to a merchant (or other payee, henceforth referred to as "M" or "merchant") for at least one transaction T. Typically, T has a very low value Tv, although the scheme featured in the present invention is applicable to any value of Tv. The micropayment schemes featured in the present invention minimizes the costs necessary for processing such micropayments, thereby significantly increasing the efficiency of the system. A number of additional advantages are also offered, as described below.

The invention, a micropayment protocol is presented which allows the merchant to determine, immediately upon receipt of a check and without interacting with the user, whether or not the check should be selected for payment. Unlike prior art probabilistic micropayment schemes, the micropayment protocol in this embodiment does not require that the playability determination be deferred until an interactive selection protocol takes place between the merchant and the user. In a second embodiment of the invention, the micropayment scheme of the present invention incorporates time constraints into the system and uses them in a special way. These time constraints require that information regarding the time and/or date of the transaction be provided on a check, and that the time information on the check satisfy predetermined criteria, in order for the check to be selected for payment.

In a third embodiment of the invention, a selective deposit protocol is presented, which eliminates any risk to the user of being charged in excess of what he actually spends. Finally, a fourth embodiment of the invention features a deferred selection protocol, which provides the bank (or other third party or broker, henceforth referred to as "bank") control and flexibility over the payment process.

In a micropayment scheme in accordance with the first embodiment of the present invention, a user U uses the records relating to the transaction T, in order to create a data string C related to T. C may be an electronic check signed by creating a digital signature for T, using a secret key of the user. The user causes the merchant to receive the check C. Upon receipt of C, the merchant associates with C an item V that is substantially unpredictable by the user. The merchant may use secret information SI, known only to the merchant, in order to associate V with C. By way of example, V may be the merchant's digital signature for C, denoted by SIGM(C), and created by the merchant using the merchant's secret signing key in a public key digital signature scheme.

The merchant then determines whether V satisfies a property P. In a preferred form, the property P may be related to the probability s that a given check C be selected for payment (O<s<1). If the merchant determines that the item V derived from the electronic check C does not satisfy the property P, the merchant simply discards the check C, and the bank never sees the check C. If the merchant determines that the item V (for example, SIGM(C)) does satisfy the property P, the merchant causes the bank to receive information I that enables the bank to also verify whether V satisfies P. For example, I may be (or may include) the merchant's public key for the merchant's digital signature scheme, corresponding to the merchant's secret key used to create V.

Upon receipt of 1, the bank undertakes to independently verify whether V satisfies the property P. If the bank verifies that V does indeed satisfy the property P, the bank causes the merchant, or a fourth party other than the merchant, the user, or the bank, to receive an amount of money A. The amount A is typically greater than Tv, and in one form, may be related to the product of Tvand the multiplicative inverse of the probability s. The amount A may be given by A=[Tv*1/s].

A system for establishing payment for a transaction T, in accordance with the first embodiment of the present invention, includes a communications channel for transmitting electronic data between a first party (user or other party), a second party (merchant or other party), a third party (bank or other party), and a fourth party. The system includes means operative by the first party for inputting and storing a data string C derived from T. The system further includes means operative by the second party and responsive to C, for inputting and storing an item V associated with at least a portion of C and substantially unpredictable by the first party. The system includes means operative by the second party, for determining whether V satisfies a property P. The system further includes means, selectively operative by the second party when V satisfies P, for causing a third party to receive information I enabling the third party to verify that V satisfies P. The system further includes means, selectively operative by the third party when V satisfies P, for causing a fourth party to receive an amount A.

The invention, time constraints are incorporated into the non-interactive micropayment protocol described above. In this embodiment, a user can establish payment to a merchant for a transaction T that is characterized in part by a time t. Typically, the time t indicates the time and/or date at which the transaction T takes place. The user creates a data string C that is related to T. In this embodiment, C must contain information regarding the time t of T. The user causes the merchant to receive C, or at least a portion of C that includes information on t. The merchant associates with C (or with the portion of C that he received) an item V that is substantially unpredictable by the user. The item V is a function of the time information on C, for example the merchant's digital signature (created using the merchant's secret key) of at least a portion of C that includes the time information. V may also be a digital signature of G(C), where G(C) denotes a function of C, or an algorithm using C. For example, G(C) may be a function that returns time/date information of C (e.g, the exactly same time/date information of C, or that time/date information "rounded up"), or time/date information of the transaction T to which C refers. The merchant then determines whether V satisfies a property P. If V does satisfy P, the merchant at time t' causes the bank to receive information I (which may include for example the merchant's public key corresponding to the merchant's secret key used to create V) enabling the bank to verify whether V satisfies P.

The invention, in order for the bank to cause a fourth party to receive an amount A, t'-t must be less than a predetermined time interval. This is another requirement, in addition to the requirement that V satisfy P. In other words, the bank will credit the merchant's account only if the merchant presents a payable check that contains information regarding a time t (at which the transaction T occurred), which is within prescribed time limits. For example, if the transaction T occurred on a day i, then the merchant may be required to deposit the corresponding check C within the end of the day i, or by day i+1, or by day i+n, where n is a predetermined integer. The time constraints in the protocol thus requires a timely deposit. Requiring timely deposits provides benefits by ensuring that the user is not charged too late; it also allows the bank to control other forms of risk, such as those arising from back-dated checks.

The present invention, a selective deposit protocol is presented which guarantees that a user is never charged more than what he actually spends. For each of one or more transactions Ti (i=1, . . . , n), the user derives a check/micropayment Ci having a face value TV (possibly worth only a fraction of the costs necessary for the bank to process a transaction such as Ti), according to an underlying probabilistic payment scheme.

The invention, each check Cincludes a progressive serial number Si, preferably starting from 1. The serial number Siis preferably representative of the position of the check Ci relative to other checks, in a time-ordered succession of checks derived by the user. In the third embodiment, the aggregate debit amount for a user is guaranteed to never be greater than the aggregate amount actually spent by the user, denoted by TVaggfor convenience. Typically, when the user writes his i-th check, the aggregate amount TVagg is given by the aggregate amount of his checks, namely:

TVagg=TV1+TV2+. .. +TVi.

For instance, the micropayment scheme featured in the third embodiment of the present invention forces Di to be no greater than TVagg=TV1+TV2+ . . . +TVi, if Ci is the first check that is found to be payable, and Di is the corresponding debit amount. This guarantee is accomplished through a protocol in which the bank keeps track of the serial numbers of the checks it receives from the merchant. Before debiting the user, the bank must determine the serial number Smax on the last check, among the ordered succession of checks, upon which payment was made. In an illustrative case, all of the transactions are worth an equal value TV. In this case, if Clis the next payable check, then the bank causes the user to be debited by an amount Di=(Si-Smax) *TV. The amount Dithus only depends only on the number of checks the user has written since the last payment was made, and the aggregate debit amount is guaranteed to be no greater than Si*TV.

Finally, in a fourth embodiment of the present invention, a deferred selection protocol is presented, which provides the bank with greater control and flexibility over the payment process. As in previous embodiments of the invention, the user derives a data string or "check" Cifor each of one or more transactions Ti (i=1,. . . , n), each having a value TV, and causes the merchant to receive C.

In the fourth embodiment of the invention, the merchant uniquely associates groups of the checks Cithat he has received into m lists Lk, where k=1, . . . , m. Each list Lkincludes data strings Ck 1, . . . , Ck 1k, where Ikrepresents the total number of checks in a given list Lk. Thus, if n is the total number of checks in all m lists, Em k=llk=n.

The merchant commits to the m lists Lk (k=1, . . . , m), by computing a commitment CMk for each Lk. The commitment CMk is preferably a hash value H(Lk), where H is a one-way hash function. The merchant causes the bank to receive the commitments CMk (k=1, . . . , m).

Upon receipt of CMk (k=1,. . . , m), the bank implements the deferred selection protocol featured in the fourth embodiment of the present invention, by selecting one or more integer indices ii, i 2 ,. . . ir. The value of r is arbitrary, and up to the bank. The bank causes the merchant to receive the selected indices ii, i 2 , . .. ir.

In response to receipt of the selected indices ii, i2 , . . . ir, the merchant de-commits CMi, CMi2. .. . CMir, thereby revealing L 1 , ... Lir to the third party (e.g., a bank). A fifth party (which may be the bank, or an entity other than the bank) causes a fourth party (which may be the merchant, or an entity other than the merchant) to receive a credit amount CR. The fifth party causes the user to be debited by a debit amount D.

Preferably, the credit amount CR is related to Vk, where Vk represents the aggregate value of all the checks contained in a given list Lk, i.e.

Vk=TVk 1+ .. .TVk /k.

The credit amount CR may be given by the aggregate value of all the checks contained in all of the m lists, i.e.

CR=V1+... Vk +. .. Vm=mk=1 Vk.

In this case, commitments to the values Vi may have been provided to the bank when the commitments CMi to the lists were provided; then all the values Vi are decommitted after the bank selects some of the lists by specifying their indices. Alternatively, the credit amount CR may be related to the aggregate value of all the checks contained in just those lists whose indices were selected by the bank. This credit amount CR may be related to the just-mentioned aggregate value by a scale factor such as m/r (where the integers m and r are referenced above), in order to reflect the fact that the bank is only seeing a fraction r/m of the checks.

The corresponding debit amount D may be derived in one of several ways; the choice of method for deriving D may or may not be related to the method for computing CR. For example, the value D may be related to the aggregate value Vi +V i2+... +V i,

of all the checks contained in those lists whose indices match the indices selected by the bank and forwarded to the merchant; for example it might be the value of this sum scaled by a factor such as m/r. Or, the value D might be derived from the credit amount CR; for example, it could be equal to the credit amount CR. Or, the value D could be derived from the serial numbers on the checks contained in the selected lists, in the manner previously described. In most applications there will be a number of distinct users, and the amount each user is charged will depend in one way or another on just those checks written by that user in the selected lists. A preferred method of computing the debit amount Dufor each user U would be to use a method based on the serial numbers of the checks written by user U.

In one implementation, a computer implemented method is disclosed wherein a transaction between a merchant and a consumer upon an account issued to the consumer by an issuer within a payment processing system is processed using a Globally Unique IDentifier ("GUID") that is associated with the transaction. The GUID is unique within the payment processing system such that the GUID is unique among multiple of the GUIDs each associated with a corresponding transaction. An authorization request for the transaction is received having: a preliminary quantity of funds to be authorized for the transaction by the issuer; a code for the transaction that is unique among a plurality of said transactions of the merchant; and an account identifier of a corresponding account. The GUID is associated with the transaction. A first transmission is formed having information for delivery to the issuer and usable to form an authorization response responding to the authorization request for the transaction, wherein the information includes the GUID. The authorization response of the issuer is received, including the GUID but not the account identifier of the account. The authorization response is associated with the authorization request by, at least, matching the GUID associated the transaction, with the GUID received in the authorization response.

A second transmission containing information for delivery to the merchant is formed, wherein the information does not include the account identifier but includes: the authorization response; the GUID; and the code for the transaction. A third transmission is received including: the GUID; and a final quantity of funds for the transaction. A fourth transmission is received having information for delivery to the issuer and usable to forward the final quantity of funds for the transaction from the account to pay the merchant for the transaction.

The payment processing system comprises a merchant and a consumer engaging in a transaction that has been authorized with an authorization by an issuer as being payable upon an account issued to the consumer by the issuer within the payment processing system. The account is associated with an account identifier. A payment amount of the transaction is unknown until after the merchant receives the authorization from the issuer. After receiving the authorization, the merchant submits to the payment processing system at least: the payment amount, and an associated Globally Unique IDentifier (GUID) that is unique within the payment processing system and is independent of the account identifier, whereby the transaction is distinguished by the GUID from a plurality of the transactions within the payment processing system. Subsequent to receiving the authorization from the issuer, the merchant does not submit the account identifier to the acquirer or the transaction handler.

The authorization request for the transaction is formed having: a preliminary quantity of funds to be authorized for the transaction by the issuer; a code for the transaction that is unique among a plurality of the transactions of the merchant; and an account identifier of the account. An authorization response of the issuer is received responding to the authorization request and not including the account identifier, but including the code for the transaction and the GUID. The GUID received in the response is associated with the transaction by, at least, matching the code for the transaction in the authorization request with the code for the transaction received in the authorization response. When the response includes an indication that the transaction has been authorized: the good or the service is released to the consumer; and a transmission is formed including: the GUID, and a final quantity of funds for the transaction that is to be the payment for the transaction from the account, wherein the transmission does not include the account identifier. A notification is received indicating that the payment amount from the account has been forwarded to the acquirer.

Some aspects include cryptographic process for secret or secure communication, and in particular to the use of intermediary entities to perform cryptographic operations, the process including: obtaining, with one or more processors, a first ciphertext, wherein: the first ciphertext is formed by encrypting a plaintext message with elliptic curve encryption; the elliptic curve encryption has a field size as a domain parameter; the field size is a prime number; the first ciphertext is encrypted based on a first public encryption key of a first recipient; the first public encryption key is part of a first encryption key pair; the first encryption key pair includes a first private encryption key corresponding to the first public encryption key; and the first ciphertext requires access to the first private encryption key to access the plaintext from the first ciphertext; obtaining, with one or more processors, the field size with which the first ciphertext was encrypted; obtaining, with one or more processors, the first private encryption key of the first encryption key pair; receiving, with one or more processors, a request to delegate access to the first ciphertext to a second recipient different from the first recipient, wherein:

The second recipient corresponds to a second encryption key pair different from the first encryption key pair; and the second encryption key pair includes a second public encryption key and a second private encryption key; obtaining, with one or more processors, the second private encryption key; determining, with one or more processors, a key-switching key based on the field size, the first private encryption key, and the second private encryption key; in response to the request, delegating access by forming a second ciphertext from which the plaintext is accessible with the second private encryption key, wherein: forming the second ciphertext is performed without decrypting the first ciphertext or accessing the plaintext; forming the second ciphertext is performed without the second private encryption key; the second ciphertext requires access to the second private encryption key to access the plaintext from the second ciphertext; and the second ciphertext is formed based on the first ciphertext and the key-switching key; and storing, with one or more processors, the second ciphertext in memory.

Some aspects include a tangible, non-transitory, machine-readable medium storing instructions that when executed by a data processing apparatus cause the data processing apparatus to perform operations including the above-mentioned process. Some aspects include a system, including: one or more processors; and memory storing instructions that when executed by the processors cause the processors to effectuate operations of the above-mentioned process.

BRIEF DESCRIPTION OF THE DIAGRAM

FIG. 1: is a flow-chart form, an overview of a method for micropayment transactions.

FIG. 2: is a block diagram illustrating the components of a micropayment system for establishing payment for a transaction.

FIG. 3: is a flow-chart form, an overview of a method for micropayment transactions.

FIG. 4: is a flow-chart form, an overview of a method for micropayment transactions In which includes a selective deposit protocol that eliminates the risk to the user of being charged in excess of what he actually spent.

FIG. 5: is a block diagram illustrating the components of a micropayment system for establishing payment for a transaction.

FIG. 6: is a flow-chart form, an overview of a method for micropayment transactions.

FIG. 7:is a schematic block diagram illustrating the components of a micropayment system for establishing payment for a transaction.

FIG. 8: is a diagram of the transmission of an encrypted message from one location to another.

FIG. 9: is a diagram of an encryption module used with the communication system of FIG. 8.

FIG. 10: is a diagram of a finite field processor used in the encryption and decryption module of FIG. 9.

FIG. 11: is a flow chart showing movement of the elements through the processor of FIG.10 in computing an inverse function.

FIG. 12: is a flow chart showing movement of elements through the processor of FIG. to compute the addition of two points.

DESCRIPTION OF THE INVENTION

FIG. 1: provides, in schematic flow-chart form, an overview of a method for micropayment transactions, in accordance with the first embodiment of the present invention. When a user wishes to make a payment in a micropayment scheme in accordance with the present invention, the user creates a data string or "electronic check" C, and sends C to the merchant, or otherwise causes the merchant to receive C. The check C is typically derived from a record T of the transaction. For example, the check C may be generated by creating a digital signature for the transaction, SIGu(T), using a secret key of the user; this signature by the user is verified by the merchant. The user's signature SIGu(T) may include, or may be accompanied by, sufficient information about T to enable this verification to proceed. The user may also cause the merchant to receive, or may incorporate in C, the digital certificate enabling verification of his digital signature-e.g., the digital certificate specifying the public key of U to be used to verify U's digital signature. Each check C may have a probability or selection rate s (0<s<1) of being selected for payment.

The merchant associates with the check C an item V that is substantially unpredictable by the user, for example a digital signature for C, created using a secret key of the merchant. The merchant then determines whether V satisfies a certain property P. In a preferred embodiment of the invention, the probability that V satisfies P is equal to the selection rate s. If merchant finds that V does indeed satisfy P, the merchant causes the bank to receive the information I that enables the bank to also verify whether V satisfy P. Otherwise, the merchant discards the check C. Upon receipt of 1, the bank may verify the user's signature on the check C, if present, and discard the check if the signature does not verify. The bank may perform other tests, for example those relating to the status of the user's account at the bank, such as determining if the account is still in good standing (e.g., whether the relevant user's digital certificate has been revoked); the bank may choose not to honor a check if such tests are not passed. The bank then verifies that V does indeed satisfy P, and causes the merchant to receive a sum of money only if V satisfies P.

FIG. 2: provides a schematic block diagram illustrating the components of a micropayment system 100 for establishing payment for a transaction T, in accordance with one embodiment of the present invention. The system 100 includes communications means 110 that permit the user, the merchant, and the bank to transmit electronic data, and even payments, among themselves. The electronic data may include data strings that represent electronic checks, or strings that represent messages. In one embodiment, the communications mean 110 may permit access to remote servers. The communications mean 110 may include a modem, and one or more network interface devices known in the art, including but not limited to network interface cards. The communication means 110 may include buses, for example address buses 114 and data buses 115, that permit transfer of data between different network nodes.

The system 100 also includes a first processing means 105, and a second processing means 106. The first and second processing means may be computer systems, for example digital computers running a DOS or Windows operating systems, and are connected to the address buses 114 and the data buses 115. Each of the processing means 105 and 106 typically include storage means 121 for storing data, input means 122 for inputting data, and a Central Processing Unit ("CPU") 123 that implements the system commands. The storage means 121 may include a computer memory, and a data storage device such as hard disks, CD-ROMs, and the like. The input means 122 may be any input device known in the art, for example a conventional keyboard.

The first processing means 105 is operative by a first party for deriving, inputting and storing a data string C related to the transaction T. The second processing means 106 is operative by a second party and responsive to C, for associating an item V with at least a portion of C. The second processing means 106 is also operative to determine whether V satisfies a property P. For example, a set of instructions can be inputted into the CPU 123 of the second processing means 106, to cause the CPU to derive the item V associated with C (or a portion of C), and to cause the CPU 123 to determine whether V satisfies a property P. This is a necessary condition that must be satisfied, in order for the next step to be executed by the CPU 123, namely the ordering of the transfer to a third party (the bank) of information I enabling the third party to verify whether V satisfies P. The CPU 123 can be programmed to be selectively operative when V satisfies P, to transmit the information I to the third party.

The system 100 also includes means 140, selectively operative by the third party when V satisfies P, for causing a fourth party to receive a sum of money. The means 140 may also be a computer system, having a CPU that can be programmed to be selectively operative when V satisfies P, to order the transfer of a payment to a fourth party. Different variants are possible within the non-interactive framework that is presented in the first embodiment described above. In particular, in a second embodiment of the invention, time constraints can be incorporated. The micropayment scheme, as described in the previous section, may allow a merchant to deposit a payable check at any time. In many cases, however, it is advantageous for the bank to have the capability to refuse to credit the merchant's account unless the merchant presents a payable (i.e. properly selected) check whose time information indicates that the check is being presented within a predetermined time interval from the time at which the relevant transaction occurred.

The invention, a micropayment scheme is presented which allows the user to establish payment for a transaction T that is characterized in part by a time t. Typically, the time t represents the time and/or date on which the transaction T occurred. FIG. 3 provides, in flow-chart form, an overview of a method for micropayment transactions in accordance with a second embodiment of the present invention. The user derives from T a data string or electronic check C from the transaction T. In the second embodiment, the check C, or the transaction T to which C refers, must contain information IN regarding the time t of the transaction T.

The user causes the merchant to receive at least a portion of C that contains IN. The merchant, upon receipt of the portion of C, associates with C an item V that is substantially unpredictable by the user. In this embodiment of the invention, the substantially unpredictable item V is defined in terms of the time t of T. For example, V may be created using the merchant's secret key in a public digital signature scheme and may be given by SIGM(C), i.e. the merchant's digital signature for C or for the portion of C that includes information on t. In the latter case, more precisely V=SIGM(G(C)), where G is a function of C that returns time information about C.

FIG. 4: provides, in flow-chart form, an overview of the method for micropayment transactions in accordance with the present invention, which includes a selective deposit protocol that eliminates the risk to the user of excessive payment. In this embodiment, a method and system is featured, which enables a user to establish payment for a series T; (i=1, . . . , n) of transactions. Each transaction T; is typically characterized by a transaction value TV that is very low, for example one cent or a fraction of a cent. The bank would therefore incur processing costs much higher than the transaction value TV itself, if the bank were to process every single transaction Ti.

A probabilistic micropayment scheme (e.g., Rivest's lottery scheme, or one of the schemes set forth in the previous sections) can therefore be used by the user to generate for each Tia check/micropayment Ci, which is sent to the merchant as payment for the transaction Ti. Then, with probability greater than 0 and less than 1, it may be determined whether Ci is selected for payment, either by an interaction of the user and the merchant, as in Rivest's lottery scheme, or non-interactively by the merchant alone, as in the schemes described in the previous section.

As seen from FIG. 4, for each Ci (i=1, . . . , n), the user causes the merchant to receive C. For each Cithat the merchant receives, the merchant determines, in accordance with the underlying probabilistic scheme and in a manner that prevents the user from predicting in advance which checks will be selected for payment, whether Clis selected (i.e. payable). For example, the underlying probabilistic scheme may be the scheme described in section I above, in which case the merchant will determine payability by associating an item Vi with Ci, and determining whether Vi satisfies a property Pi. The merchant may possibly check other conditions, such as whether the user's signature on Cl is valid, whether the amount of the check is not too large, and so forth; some of these conditions may be specified in the user's certificate. If the merchant determines that Clis not payable, the merchant discards C. If the merchant) determines that Cl is payable, the merchant causes the bank to receive information li, which enables the bank to verify that the selected check Clis payable. The bank uses li to verify that Ci is payable. If and only if Ci is payable, the bank causes the merchant to receive a credit amount CR, and the user to be debited by an amount Di.

The invention, the bank must ensure that Diis such that the total amount D=D1+D2. .

. Di debited to the user is no greater than the total aggregate value Tagg=TV1+TV2+ ..

. TVof the checks the user has written. In other words, the total amount that a user is debited after he has participated in i transactions, for any integer i such that iin must never exceed the aggregate value of the transactions Ti, . . . Ti that he has purchased from merchant.

In a preferred form, the bank determines Di, in a manner that guarantees DD1+D2+ . +Di to be no greater that Tagg, by using serial numbers from the checks. In this form, each of the plurality of checks Ci (i=1, . . . , n) generated by the user in the underlying probabilistic payment scheme includes a serial number Si. These serial numbers Si are preferably consecutive integers starting from 1. Also, the i-th serial number is preferably representative of the order in time of the transaction Tiand the check Ci, relative to the other transactions (Ti, . . . , Ti-1, and Ti,. . . Tn) and the other checks (C1, . . . , C-1, and Ci , . . . Cn).

The serial number Si provides an indication of the index i associated with the transaction Ti and/or the check C. Ordered but non-consecutive serial numbers can also be used, however. For example, one may associate with the i-th check the i-th prime number, after a given number P. For simplicity, the case in which each transaction Ti has the same transaction value TV=TVi will be described first. The third embodiment also encompasses cases in which the transactions Timay have different values TV, as discussed in more detail later.

The bank (or another fifth party) keeps track of the serial numbers of the checks that have been selected for payment. In order to determine the debit amount Di of a payable check Ci, the third/fifth party uses the value Smax, where Smaxdenotes the serial number appearing on the most recent check that has been presented, so far, for payment. The value Smaxis initialized to zero in the case that the serial numbers are used sequentially starting with 1. Because the serial numbers on the checks are sequentially ordered, Smax is the largest of the serial numbers appearing on any check that has previously been presented for payment. Also, Smax is less than the serial number Siof the current payable check Ci, because of the sequential ordering of the serial numbers. As shown in FIG. 4, the user is debited (e.g., by the fifth party) for this check by an amount D i=(S i -S max)*TV. (1) It follows that the total amount D the user has been debited for all of the checks he has written is Si*TV. If non-consecutive serial numbers are used, one may define Di=#(Si-Smax)*TV, where #(Si-Smax) denotes the number of serial numbers between Si and Smax (inclusive of Si but exclusiveof Smax).

The amount DD1+D2+ .. . Dmax represents the aggregate value of all the checks that user has issued. Since D is never more than i*TV after i checks have been written, the risk to the user of making an excessive payment is thus eliminated. In order to process future micropayments, the bank then resets the valueof SmaxtO Si, which as explained above is the most recent check found by the bank so far to be payable. Equation (1) also shows that the amount ultimately charged to the user does not depend on which checks ultimately turn out to be payable, but only on the number of checks that the user has written; the user is eventually charged the proper amount for each check he has written.

The fifth party may cause a fourth party (which may be the merchant, or may be an entity other than the merchant) to receive a credit amount CRi, which typically is given by: CRi=TV*(1/s). (2) If there is a selection rate s in the underlying probabilistic payment scheme, then also in the method and system of the present invention, approximately only 1 out of every 1/s checks becomes selected for payment, when averaged over a large number of micropayments. Accordingly, the credit amount is fair to the merchant, too, since it is the full aggregated value of the 1/s checks, and the merchant ends up receiving the correct amount, when an average is made over a large number of micropayments. But the resulting scheme is much fairer to the user, because the risk of making an excessive payment is shifted from the user to the bank. For example, if the selection rate is s= 1/1000, and the merchant deals with 1,000 micropayments, each worth one cent, then it is expected that only one of these 1,000 payments will be selected, but the selected one will cause the merchant to receive 1/s=1000 cents, or $10. If more than one micropayment (out of 1,000 micropayments) is selected, the bank will, by bad luck, have to pay $10 more than once. The bank may choose to shift some risk to the merchants by deferring payment on a check to a merchant until the user has paid enough in aggregate, according to the serial-number debiting scheme described above, to cover the payment of this check and of all previous checks also selected for payment.

FIG. 5: provides a schematic block diagram illustrating the components of a) micropayment system 200 for establishing payment for a transaction Ti, in accordance with the third embodiment of the present invention. The system 200 includes communications means 210 that permit the user, the merchant, and the bank to transmit electronic data, and even payments, among themselves. The electronic data may include data strings that represent electronic checks, or strings that represent messages. In one embodiment, the communications mean 210 may permit access to remote servers. The communications mean 210 may include a modem, and one or more network interface devices known in the art, including but not limited to network interface cards. One or more buses, for example address bus 214 and data bus 215, may be provided so as to permit transfer of data between different network nodes.

The system 200 also includes a first processing means 205, and a second processing means 206. The first and second processing means may be computer systems, for example digital computers running a DOS or Windows operating systems, and are connected to the address buses 214 and the data buses 215. Each of the processing means 205 and 206 typically includes storage means 221 for storing data, input means 222 for inputting data, and a Central Processing Unit ("CPU") 223 that implements the system commands. The storage means 221 may include a computer memory, and a data storage device such as a hard disk, a CD-ROM, and the like. The input means 222 may be any input device known in the art, for example a conventional keyboard.

The first processing means 205 is operative by the user for deriving, inputting and storing a data string Ci related to a transaction Ti (i=1, . . . , n), including in the data string Ci a progressive serial number Si that is representative of the position of the check Ci relative to other checks in an ordered succession of checks Cj (j=1,. . . , n).

The second processing means 106 is operative by the merchant and responsive to Ci, for associating an item Vi with C1. The second processing means 106 is also operative to determine whether Vi satisfies a property Pi. For example, a set of instructions can be inputted into the CPU 223 of the second processing means 206, to cause the CPU to derive the item Vi associated with Ci (or a portion of Ci), and to cause the CPU 223 to determine whether Vi satisfies a property Pi. This is a necessary condition that must be satisfied, in order for the next step to be executed by the CPU 223 in 206, namely the ordering of the transfer to the bank of information lienabling the bank to verify whether Vi satisfies Pi. The CPU 223 in the processing means 206 can be programmed to be selectively operative when Vi satisfies Pi, to transmit the information li to the bank.

The system 200 also includes means 240, selectively operative by the bank (or another fifth party) when Vi satisfies Pi, for causing a fourth party (which may be the merchant, or another entity) to receive a sum of money. The means 240 may also be a computer system, having a CPU that can be programmed to be selectively operative when Vi satisfies Pi, to: 1) determine the valueof Smax, where Smax is the serial number of the last check upon which payment was made (and thus the largest of the serial numbers on any check presented to the bank so far for payment); 2) order the transfer of a payment of amount CR to a fourth party; and 3) cause the user to be debited by an amount D.

FIG. 6: provides, in flow-chart form, a schematic overview of a method for micropayment transactions, in accordance with the fourth embodiment of the present invention. A user creates a data string or "electronic check" C, derived from a micropayment transaction T, and sends C to the merchant, when a user wishes to make a payment. In the illustrated embodiment of the invention, a plurality of transactions Ti(i=1, ... n) are involved. The user or users derive a check Cifor each transaction Ti, and causes the merchant to receive the checks Ci (i=1, . . . , n).

The merchant groups the checks Ci (i=1, . . . , n), which he has received from the users, into m lists Lk, where k=1, . . . , m. Each list Lk(k=1, . . . , m) includes Ikdata strings Ck 1, . . . Cklkwhere Ik represents the number of data strings in a given list Lk. When summed over the m lists, Ik naturally adds up to the total number n of received checks, i.e. /1+...+/k+... m =n.

The merchant then commits to each list Lk, by computing a commitment CMkfor Lk, and causes the bank to receive CMk for each k (i.e. for k=1, . . . , m).

The grouping of checks into lists may be done according to a specific rule, agreed upon by the merchant and the bank. For example, the check C may be placed in a list

L1, where i was computed as a function of C, e.g. by using the serial number of C, or extracting some bits from C, or extracting some bits from the hash of C.

Each transaction Ti is preferably characterized by a transaction value TV. Also, each data string Ci preferably includes data that represents the transaction value TV of the transaction Tifrom which Ciis derived. The merchant can thus determine an aggregate value Vk for each list Lk, where Vk is given by:

V k=TVk 1+ .. . +TVk / k.

In other words, Vk represents the aggregate value of all the data strings C 1, Cklk in the list Lk. In this case, the merchant may also optionally commit to the values Vk in addition to committing to the values Lk. That is, the merchant may provide an additional commitment CV=H(V 1, V 2 , . . . Vm) to the list of values (V 1 , V 2 , . . . Vm), where H is a one-way hash function. By de-committing CV, the merchant thus reveals the list (V 1 , V 2 , . . . , Vm).

In the deferred selection protocol featured in the fourth embodiment, the payment selection process, for determining whether or not a particular check Cishould be selected for payment, is deferred until the bank receives the merchant's commitments CMk (k=1, . . . , m) to the lists Lk, and until the bank receives the commitment CV to the values Vk, if this option is chosen. This deferral is a distinguishing feature of the micropayment scheme described in the fourth embodiment. Upon receipt of CMk (k=1, m) (and the optional commitment CV), the bank selects one or more integer indices ii, i2 ,. . . , ir, and causes the merchant to receive the selected indices ii, i2 ,. . .

, ir. In the fourth embodiment of the present invention, the selection by the bank of the integer indices ii,. . . , ir represents the selection process that determines whether or not a check is selected for payment.

It should be noted that the value of r is arbitrary, and up to the bank. When there are more incidences of attempted fraud, or when there is suspicion upon a particular merchant, a larger value of r may be used. In some cases, the bank may even ask the merchant to de-commit all of his commitments (that is, choose r=m). Choosing r>1 is recommended, in order to have a chance to catch two checks from the same user with the same serial number, rather than throwing out such a user later on statistical evidence.

Upon receipt of the indices ii, i 2 ,. . . , ir, the merchant de-commits those commitments CMk whose indices correspond to the indices ii, i2 ,. . . , irthat he received. In other words, the merchant de-commits CM 1 , CMi 2 , . . . , CMir, i.e. the merchant causes the bank to receive a de-commit string for each of the CM' 1 , CMi 2 , . . . , CMir. The merchant thereby reveals to the bank L',L 2 , . . . Lir, if each CMk=H(Lk). If the commitment CV was previously given to the bank, the merchant reveals to the bank the list (V 1, . . .

, Vr). For those lists whose indices match the particular indices that the bank has selected, the bank is able to see the data strings that are contained in the lists, and therefore the corresponding aggregate transaction values as well. If CV was decommitted as well, then the bank sees the merchant's claimed aggregate transaction value for all lists, and not just the selected lists. The bank can re-compute the aggregate transaction value for the decommitted lists, and compare these values to the recommitment of CV, in order to check for cheating on the part of the merchant. Such checking may also involve checking that each list only contains checks that are appropriate for inclusion in that list, and checking for checks appearing in more than one list.

FIG. 7: illustrates a system 300 for establishing payment for a plurality of n transactions T1, T2, . . . , Ti, . . . , Tn, each Ti having a value TV. The system 300 includes communications means for transmitting data between a user, a merchant, a bank, and a fourth party. The system 300 also includes a first processing means 310, a second processing means 320, a third processing means 330, and a fourth processing means 340. All four processing means typically include storage means 351 for storing data, input means 352 for inputting data, and a CPU 353 that implements the system commands.

The first processing means 310 is operative by a user for deriving, inputting, and storing a data string Ci (1 i n) for each Ti. The second processing means 320 is operative by merchant, and responsive to receipt of Ci (i=1, . . . n), for uniquely associating groups of said data strings Ci (i=1, . . . , n) into m lists Lk (k=1, . . . , m), and for inputting and storing said lists Lk(k=1, . . . , m). Each list Lk includes data strings Ck 1, . . . , Cklk, and Y k=llk=n. The second processing means is further operative by the merchant for computing a commitment CMk for each Lk, and for inputting and storing the commitments CMk (k=1, . . . , m).

The third processing means 330 is operative by the bank, upon receipt of the commitments CMk, for selecting one or more integer indices ii, i2 ,. . . , ir, and for causing the second party to receive the indices ii, i2 ,. . . , ir, where 1irimfor all r. The fourth processing means 340 is operative by the merchant, upon receipt of the indices ii, i 2 ,. . . , ir, for de-committing CM, thereby revealing L'1 , . . . , Lir to the bank.

The system 300 includes means 370, operative by the third party upon revelation of L1,., Lir, for causing the user to be debited by a debit amount D and for causing a fourth party to receive a credit amount CR.

FIG. 8: a message M is to be transferred from a transmitter 10 to a receiver 12 through a communication channel 14. Each of the transmitters 10 and receiver 12 has an encryption/decryption module 16 associated therewith to implement a key exchange protocol and an encryption/decryption algorithm. The module 16 is shown schematically in FIG. 2 and includes an arithmetic unit 20 to perform the computations in the key exchange and generation. A private key register 22 contains a private key, d, generated as a 155-bit data string from a random number generator 24, and used to generate a public key stored in a public key register 26. A base point register 28 contains the coordinates of a base point P that lies in the elliptic curve selected with each coordinate (x, y), represented as a 155-bit data string. Each of the data strings is a vector of binary digits with each digit being the coefficient of an element of the finite field in the normal basis representation of the coordinate.

The elliptic curve selected will have the general form y 2 +xy=x3 +ax2 +b and the parameters of that curve, namely the coefficients a and b are stored in a parameter register 30. The contents of registers 22, 24, 26, 28, 30 may be transferred to the arithmetic unit 20 under control of a C.P.U. 32 as required. The contents of the public key register 26 are also available to the communication channel 14 upon a suitable request being received. In the simplest implementation, each encryption module 16 in a common security zone will operate with the same curve and base point so that the contents of registers 28 and 30 need not be accessible. If further sophistication is required, however, each module 16 may select its own curve and base point in which case the contents of registers 28, 30 have to be accessible to the channel 14.

The module 16 also contains an integer register 34 that receives an integer k, the session seed, from the generator 24 for use in encryption and key exchange. The module 16 has a random access memory (RAM) 36 that is used as a temporary store as required during computations. The encryption of the message M with an encryption key kdP derived from the public key dP and session seed integer k is performed in an encryption unit 40 which implements a selected encryption algorithm. A simple yet effective algorithm is provided by an XOR function which XOR's the message m with the 310 bits of the encryption key kdP. Alternative implementations such as the DES encryption algorithm could of course be used.

FIG. 10. The unit 20 includes a multiplier 48 having a pair of cyclic shift registers 42, 44 and an accumulating register 46. Each of the registers 42, 44, 46 contain M cells a, 50b . . . 50m, in this example 155, to receive the m elements of a normal basis representation of one of the coordinates of e.g. x, of P. As fully explained in U.S. Pat. No. 4,745,568, the cells 50 of registers 42, 44 are connected to the corresponding cells 50 of accumulating register 46 such a way that a respective grouped term is generated in each cell of register 46. The registers 42,44,46 are also directly interconnected in a bit wise fashion to allow fast transfers of data between the registers.

WE CLAIMS

1. My Invention "loT-Based Micropayment Protocol for Wearable Devices with Unique Verification" is a micropayment system and method is presented for a Payor-U to establish payment to Payee-M for a Transaction-T, which typically has a very low value Tv. The invented micropayment scheme minimizes the bank's processing costs, while at the same time eliminating the need for users and merchants to interact in order to determine whether a given micropayment should be selected for payment. the micropayment scheme includes time constraints, which require that an electronic Check-C for the Transaction-T be presented to a Bank-B for payment within a predetermined location, time, date, interval. The invented micropayment scheme includes a deferred selection protocol, which provides the bank with control and flexibility over the payment selection process. The invented wearable device is one of the parts of the essential (COGS) Cost of Goods Sold in the wheel of the Internet of things (loT) contributing towards a potential impact in finance and banking sectors. The invention also lightweight cryptography mechanisms for loT devices because these are resource constraints a novel approach of anloT-based micropayment protocol in wearable devices environment is introduced. The invention can use the payment model "(ECIES) elliptic curve integrated encryption scheme "for encryption and decryption of the communicating messages between various entities. The invention provides the customer to buy the goods using a wearable device and sent the confidential payment information to the mobile application and creates a secure session between the customer, banks and merchant. The static security analysis and informal security methods indicate that the invented protocol is withstanding the various security vulnerabilities involved in mobile payments. For logical verification of the correctness of security properties using the formal way of "(BAN) Burrows-Abadi-Needham " logic confirms the accuracy of the invented protocol. The practical simulation and validation using Scyther and Tamarin tool ensure the absence of security attacks in our scheme. Finally, the performance analysis based on cryptography features and computational overhead of related approaches specify that the proposed micropayment protocol for wearable devices is secure and efficient. 2. According to claims# the invention is to a micropayment system and method is presented for a Payor-U to establish payment to Payee-M for a Transaction-T, which typically has a very low value Tv. The invented micropayment scheme minimizes the bank's processing costs, while at the same time eliminating the need for users and merchants to interact in order to determine whether a given micropayment should be selected for payment.

3. According to claiml,2# the invention is to the micropayment scheme includes time constraints, which require that an electronic Check-C for the Transaction-T be presented to a Bank-B for payment within a predetermined location, time, date, interval. The invented micropayment scheme includes a deferred selection protocol, which provides the bank with control and flexibility over the payment selection process. 4. According to claiml,2# the invention is to the invented wearable device is one of the parts of the essential (COGS) Cost of Goods Sold in the wheel of the Internet of things (loT) contributing towards a potential impact in finance and banking sectors. 5. According to claiml,2,4# the invention is to the invention also lightweight cryptography mechanisms for loT devices because these are resource constraints a novel approach of an loT-based micropayment protocol in wearable devices environment is introduced. 6. According to claiml,2,5# the invention is to the invention can use the payment model "(ECIES) elliptic curve integrated encryption scheme "for encryption and decryption of the communicating messages between various entities. 7. According to claiml,2,3,6# the invention is to the invention provides the customer to buy the goods using a wearable device and sent the confidential payment information to the mobile application and creates a secure session between the customer, banks and merchant. 8. According to claiml,2,6# the invention is to a the static security analysis and informal security methods indicate that the invented protocol is withstanding the various security vulnerabilities involved in mobile payments. For logical verification of the correctness of security properties using the formal way of "(BAN) Burrows-Abadi-Needham " logic confirms the accuracy of the invented protocol. 9. According to claiml,2,5,8# the invention is to the practical simulation and validation using Scyther and Tamarin tool ensure the absence of security attacks in our scheme. Finally, the performance analysis based on cryptography features and computational overhead of related approaches specify that the proposed micropayment protocol for wearable devices is secure and efficient.

Date: 16/8/2020 Dr. B. Madhuravani (Professor) Mrs. Sameera Divanu (Assistant Professor) Mrs. M. Trupthi (Assistant Professor) Mrs. Gnyanadeepa Yaganti (Assistant Professor) Mrs. K Swathi (Assistant Professor) Mrs. Sneha Bushetty (Assistant Professor) Kuntimalla Sudheer Babu (Assistant Professor) Dr. Yugandhar Garapati (Assistant Professor) Sri Sowmya Gudipati (Assistant Professor) Ponnuru Sowjanya (Assistant Professor)

FOR Dr. B. Madhuravani (Professor) Mrs. Sameera Divanu (Assistant Professor) Mrs. M. Trupthi (Assistant Professor) Mrs. Gnyanadeepa Yaganti (Assistant Professor) Mrs. K Swathi (Assistant Professor) Mrs. Sneha Bushetty (Assistant Professor) 17 Aug 2020

Kuntimalla Sudheer Babu (Assistant Professor) Dr. Yugandhar Garapati (Assistant Professor) Sri Sowmya Gudipati (Assistant Professor) Ponnuru Sowjanya (Assistant Professor) TOTAL NO OF SHEET: 12 NO OF FIG: 12 2020101863

FIG. 1: IS A FLOW-CHART FORM, AN OVERVIEW OF A METHOD FOR MICROPAYMENT TRANSACTIONS.

FOR Dr. B. Madhuravani (Professor) Mrs. Sameera Divanu (Assistant Professor) Mrs. M. Trupthi (Assistant Professor) Mrs. Gnyanadeepa Yaganti (Assistant Professor) Mrs. K Swathi (Assistant Professor) Mrs. Sneha Bushetty (Assistant Professor) 17 Aug 2020

Kuntimalla Sudheer Babu (Assistant Professor) Dr. Yugandhar Garapati (Assistant Professor) Sri Sowmya Gudipati (Assistant Professor) Ponnuru Sowjanya (Assistant Professor) TOTAL NO OF SHEET: 12 NO OF FIG: 12 2020101863

FIG. 2: IS A BLOCK DIAGRAM ILLUSTRATING THE COMPONENTS OF A MICROPAYMENT SYSTEM FOR ESTABLISHING PAYMENT FOR A TRANSACTION.

FOR Dr. B. Madhuravani (Professor) Mrs. Sameera Divanu (Assistant Professor) Mrs. M. Trupthi (Assistant Professor) Mrs. Gnyanadeepa Yaganti (Assistant Professor) Mrs. K Swathi (Assistant Professor) Mrs. Sneha Bushetty (Assistant Professor) 17 Aug 2020

Kuntimalla Sudheer Babu (Assistant Professor) Dr. Yugandhar Garapati (Assistant Professor) Sri Sowmya Gudipati (Assistant Professor) Ponnuru Sowjanya (Assistant Professor) TOTAL NO OF SHEET: 12 NO OF FIG: 12 2020101863

FIG. 3: IS A FLOW-CHART FORM, AN OVERVIEW OF A METHOD FOR MICROPAYMENT TRANSACTIONS.

FOR Dr. B. Madhuravani (Professor) Mrs. Sameera Divanu (Assistant Professor) Mrs. M. Trupthi (Assistant Professor) Mrs. Gnyanadeepa Yaganti (Assistant Professor) Mrs. K Swathi (Assistant Professor) Mrs. Sneha Bushetty (Assistant Professor) 17 Aug 2020

Kuntimalla Sudheer Babu (Assistant Professor) Dr. Yugandhar Garapati (Assistant Professor) Sri Sowmya Gudipati (Assistant Professor) Ponnuru Sowjanya (Assistant Professor) TOTAL NO OF SHEET: 12 NO OF FIG: 12 2020101863

FIG. 4: IS A FLOW-CHART FORM, AN OVERVIEW OF A METHOD FOR MICROPAYMENT TRANSACTIONS IN WHICH INCLUDES A SELECTIVE DEPOSIT PROTOCOL THAT ELIMINATES THE RISK TO THE USER OF BEING CHARGED IN EXCESS OF WHAT HE ACTUALLY SPENT.

FOR Dr. B. Madhuravani (Professor) Mrs. Sameera Divanu (Assistant Professor) Mrs. M. Trupthi (Assistant Professor) Mrs. Gnyanadeepa Yaganti (Assistant Professor) Mrs. K Swathi (Assistant Professor) Mrs. Sneha Bushetty (Assistant Professor) 17 Aug 2020

Kuntimalla Sudheer Babu (Assistant Professor) Dr. Yugandhar Garapati (Assistant Professor) Sri Sowmya Gudipati (Assistant Professor) Ponnuru Sowjanya (Assistant Professor) TOTAL NO OF SHEET: 12 NO OF FIG: 12 2020101863

FIG. 5: IS A BLOCK DIAGRAM ILLUSTRATING THE COMPONENTS OF A MICROPAYMENT SYSTEM FOR ESTABLISHING PAYMENT FOR A TRANSACTION.

FOR Dr. B. Madhuravani (Professor) Mrs. Sameera Divanu (Assistant Professor) Mrs. M. Trupthi (Assistant Professor) Mrs. Gnyanadeepa Yaganti (Assistant Professor) Mrs. K Swathi (Assistant Professor) Mrs. Sneha Bushetty (Assistant Professor) 17 Aug 2020

Kuntimalla Sudheer Babu (Assistant Professor) Dr. Yugandhar Garapati (Assistant Professor) Sri Sowmya Gudipati (Assistant Professor) Ponnuru Sowjanya (Assistant Professor) TOTAL NO OF SHEET: 12 NO OF FIG: 12 2020101863

FIG. 6: IS A FLOW-CHART FORM, AN OVERVIEW OF A METHOD FOR MICROPAYMENT TRANSACTIONS.

FOR Dr. B. Madhuravani (Professor) Mrs. Sameera Divanu (Assistant Professor) Mrs. M. Trupthi (Assistant Professor) Mrs. Gnyanadeepa Yaganti (Assistant Professor) Mrs. K Swathi (Assistant Professor) Mrs. Sneha Bushetty (Assistant Professor) 17 Aug 2020

Kuntimalla Sudheer Babu (Assistant Professor) Dr. Yugandhar Garapati (Assistant Professor) Sri Sowmya Gudipati (Assistant Professor) Ponnuru Sowjanya (Assistant Professor) TOTAL NO OF SHEET: 12 NO OF FIG: 12 2020101863

FIG. 7:IS A SCHEMATIC BLOCK DIAGRAM ILLUSTRATING THE COMPONENTS OF A MICROPAYMENT SYSTEM FOR ESTABLISHING PAYMENT FOR A TRANSACTION.

FOR Dr. B. Madhuravani (Professor) Mrs. Sameera Divanu (Assistant Professor) Mrs. M. Trupthi (Assistant Professor) Mrs. Gnyanadeepa Yaganti (Assistant Professor) Mrs. K Swathi (Assistant Professor) Mrs. Sneha Bushetty (Assistant Professor) 17 Aug 2020

Kuntimalla Sudheer Babu (Assistant Professor) Dr. Yugandhar Garapati (Assistant Professor) Sri Sowmya Gudipati (Assistant Professor) Ponnuru Sowjanya (Assistant Professor) TOTAL NO OF SHEET: 12 NO OF FIG: 12 2020101863

FIG. 8: IS A DIAGRAM OF THE TRANSMISSION OF AN ENCRYPTED MESSAGE FROM ONE LOCATION TO ANOTHER.

FOR Dr. B. Madhuravani (Professor) Mrs. Sameera Divanu (Assistant Professor) Mrs. M. Trupthi (Assistant Professor) Mrs. Gnyanadeepa Yaganti (Assistant Professor) Mrs. K Swathi (Assistant Professor) Mrs. Sneha Bushetty (Assistant Professor) 17 Aug 2020

Kuntimalla Sudheer Babu (Assistant Professor) Dr. Yugandhar Garapati (Assistant Professor) Sri Sowmya Gudipati (Assistant Professor) Ponnuru Sowjanya (Assistant Professor) TOTAL NO OF SHEET: 12 NO OF FIG: 12 2020101863

FIG. 9: IS A DIAGRAM OF AN ENCRYPTION MODULE USED WITH THE COMMUNICATION SYSTEM OF FIG. 8.

FOR Dr. B. Madhuravani (Professor) Mrs. Sameera Divanu (Assistant Professor) Mrs. M. Trupthi (Assistant Professor) Mrs. Gnyanadeepa Yaganti (Assistant Professor) Mrs. K Swathi (Assistant Professor) Mrs. Sneha Bushetty (Assistant Professor) 17 Aug 2020

Kuntimalla Sudheer Babu (Assistant Professor) Dr. Yugandhar Garapati (Assistant Professor) Sri Sowmya Gudipati (Assistant Professor) Ponnuru Sowjanya (Assistant Professor) TOTAL NO OF SHEET: 12 NO OF FIG: 12 2020101863

FIG. 10: IS A DIAGRAM OF A FINITE FIELD PROCESSOR USED IN THE ENCRYPTION AND DECRYPTION MODULE OF FIG. 9.

FOR Dr. B. Madhuravani (Professor) Mrs. Sameera Divanu (Assistant Professor) Mrs. M. Trupthi (Assistant Professor) Mrs. Gnyanadeepa Yaganti (Assistant Professor) Mrs. K Swathi (Assistant Professor) Mrs. Sneha Bushetty (Assistant Professor) 17 Aug 2020

Kuntimalla Sudheer Babu (Assistant Professor) Dr. Yugandhar Garapati (Assistant Professor) Sri Sowmya Gudipati (Assistant Professor) Ponnuru Sowjanya (Assistant Professor) TOTAL NO OF SHEET: 12 NO OF FIG: 12 2020101863

FIG. 11: IS A FLOW CHART SHOWING MOVEMENT OF THE ELEMENTS THROUGH THE PROCESSOR OF FIG.10 IN COMPUTING AN INVERSE FUNCTION.

FOR Dr. B. Madhuravani (Professor) Mrs. Sameera Divanu (Assistant Professor) Mrs. M. Trupthi (Assistant Professor) Mrs. Gnyanadeepa Yaganti (Assistant Professor) Mrs. K Swathi (Assistant Professor) Mrs. Sneha Bushetty (Assistant Professor) 17 Aug 2020

Kuntimalla Sudheer Babu (Assistant Professor) Dr. Yugandhar Garapati (Assistant Professor) Sri Sowmya Gudipati (Assistant Professor) Ponnuru Sowjanya (Assistant Professor) TOTAL NO OF SHEET: 12 NO OF FIG: 12 2020101863

FIG. 12: IS A FLOW CHART SHOWING MOVEMENT OF ELEMENTS THROUGH THE PROCESSOR OF FIG. 10 TO COMPUTE THE ADDITION OF TWO POINTS.