HK40107407A - System, device and method for digital payment - Google Patents

Description

Systems, devices and methods for digital payments

Technical Field

Some of the implementation methods described herein generally relate to payment systems and methods, and more specifically to digital payments via digital networks.

Background Technology

Digital payment systems enable purchases in virtual stores via the internet and in physical stores using digital wallets. These systems allow users to pay for goods using their credit cards or other payment methods such as PayPay, cryptocurrency, etc.

However, in order to use a digital wallet, a payment card needs to be uploaded to the digital wallet application. Therefore, users without a payment card cannot use the digital wallet application.

Summary of the Invention

The following descriptions, by way of example only, describe implementations related to systems, methods, and products for purchasing goods and services.

One example implementation may include a payment server comprising a processing circuitry configured to: issue payment elements for executing one or more payments via a communication network, wherein the payment elements include a user identification string; send the user identification string to a user application installed on a user device; receive a payment request message from a payment receiving unit when the user identification string is provided to the payment receiving unit via the user device for payment; send a purchase permission request message to a user account holder server; and send a reply message to the payment receiving unit as a response to the payment permission request.

For example, the response message includes an approval message, and the processing circuitry is configured to: send the requested payment to the payment receiving unit; and receive the payment from the user account holder server based on the requested payment.

For example, a user identification string may include at least one of the following: user ID number, user code, payment account number, and phone number.

For example, the user identification string is encrypted.

For example, when the response message includes a rejection message, the processing circuitry is configured to send a rejection message to the payment receiving unit.

For example, when the response message includes an approval message, the processing circuitry is configured to: send a payment request message to the user account holder server; and receive a payment confirmation message from the user account holder server.

For example, the processing circuitry is configured to: after the payment process is completed at the user application in the user device, request the deletion of the payment element; issue a new payment element for the user to use in the next payment, wherein the new payment element includes a new user identification string; and send the new payment element to the user application at the user device.

For example, the payment request message includes: a user identifier string, the requested payment amount, the payment method, and the recipient data.

For example, the payment confirmation message includes at least one of the following: the date of payment, user data, account holder details, payee data, payment method, and the requested amount to be paid to the payee.

For example, the permission request message may include at least: a user identifier string, recipient data, payment method, and the requested payment amount.

For example, the user account holder includes at least one of the following: banks and banking centers.

For example, the user application includes a digital wallet.

For example, the user equipment includes at least one of the following: a desktop computer, a laptop computer, a mobile device, or a mobile phone.

Another implementation may include a product comprising one or more tangible computer-readable non-transitory storage media, the tangible computer-readable non-transitory storage media including program instructions for performing payments via a communication network, wherein execution of the program instructions includes: issuing payment elements for performing one or more payments via the communication network, wherein the payment elements include a user identification string; sending the user identification string to a user application installed on a user device; receiving a payment request message from the payment receiving unit when the user identification string is provided to the payment receiving unit for payment via the user device; sending a purchase permission request message to a user account holder server; and sending a reply message to the payment receiving unit as a response to the payment permission request.

For example, when the reply message includes a permission message, the execution of the program instructions includes: sending the requested payment to the payment receiving unit; and receiving the payment from the user account holder server based on the requested payment.

For example, when the reply message includes a rejection message, the execution of the program instructions includes sending a rejection message to the payment receiving unit.

For example, when the reply message includes a permission message, the execution of the program instructions includes: sending a payment request message to the user account holder server; and receiving a payment confirmation message from the user account holder server.

For example, the execution of the program instructions includes: after completing the payment process at the user application on the user device, requesting the deletion of the payment element; issuing a new payment element for the user to use in the next payment, wherein the new payment element includes a new user identification string; and sending the new payment element to the user application on the user device.

Another example of the implementation includes a payment server comprising a processing circuitry configured to: receive a user identification string from a user account holder server, wherein the user identification string is configured to associate with a user account at the user account holder server without exposing other details of the user to the payment receiving unit; issue a payment element based on the user identification string; send the payment element to a user application installed on a user device, the user application being configured to perform a payment using the payment element at the payment receiving unit; and conduct a payment transaction with the payment receiving unit.

For example, the payment transaction includes: sending a payment request message to a payment server; receiving a payment request message from a payment receiving unit at the payment server; when making a payment, the payment server is configured to send a purchase permission request message to the user account holder server; and sending a reply message to the payment receiving unit as a response to the payment permission request.

For example, the payment server is configured to: perform a registration session with the user device, wherein the registration session includes: receiving a user identification string from the user device; and issuing a payment element based on the identification string, wherein the payment element will be downloaded and installed on the payment application on the user device.

For example, the payment server is configured to: perform a registration session with the user device, wherein the registration session includes: receiving user information from the user device; receiving an identification string from a user account holder server; and issuing a payment element based on the identification string, wherein the payment element will be downloaded and installed on the payment application on the user device.

For example, the user information includes username, user address, user email address, user ID number, and user bank account details.

Solutions to deficiencies in the technical field can be understood from the description of this disclosure. More specifically, the implementations described herein enable payment for purchases using a user ID string.

Attached Figure Description

Figure 1 shows a block diagram of a system for performing payments over a network according to some illustrative embodiments.

Figure 2 shows a flowchart of a method for performing payments over a network according to an illustrative embodiment.

Figure 3 shows a flowchart of a method for performing payment over a network according to a second illustrative embodiment.

Figure 4 shows a flowchart of a method for performing payment over a network according to a third illustrative embodiment.

Figure 5 illustrates the frame structure of a payment request message according to some other illustrative embodiments.

Figure 6 illustrates the frame structure of a payment confirmation message according to some other illustrative embodiments.

Figure 7 illustrates the frame structure of a permission request message according to some other illustrative embodiments.

Figure 8 shows the frame structure of a response message according to some other illustrative embodiments.

Figure 9 illustrates the frame structure of a user identifier string according to some illustrative embodiments.

Figure 10 shows a manufactured product according to some illustrative embodiments.

Figure 11 shows a block diagram of another embodiment of a system for performing payments over a network, according to some illustrative embodiments.

Detailed Implementation

In the following detailed description, numerous specific details are set forth in order to provide a thorough understanding of some implementations. However, those skilled in the art will understand that some implementations can be practiced without these specific details. In other instances, well-known methods, processes, components, units, and/or circuits have not been described in detail to avoid obscuring the discussion.

The discussion in this document using terms such as “processing,” “computing,” “calculating,” “determining,” “establishing,” “analyzing,” and “checking” can refer to the operation and/or processing of a computer, computing platform, computing system, or other electronic computing device, which manipulates and/or converts data represented as physical (e.g., electronic) quantities in computer registers and/or memory into other data that are similarly represented as physical quantities in computer registers and/or memory, or other information storage media that may store instructions for performing the operation and/or processing.

As used herein, the terms “plurality” and “a plurality” include, for example, “multiple” or “two or more”. For example, “multiple items” includes two or more items.

References to "one embodiment," "implementation," "illustrative embodiment," "various embodiments," etc., indicate that the embodiment described as such may include a particular feature, structure, or characteristic, but not every embodiment necessarily includes that particular feature, structure, or characteristic. Furthermore, repeated use of the phrase "in one embodiment" does not necessarily refer to the same embodiment, but it can refer to the same embodiment.

As used herein, unless otherwise stated, the use of ordinal adjectives such as “first,” “second,” “third,” etc., to describe common objects merely indicates that different instances of similar objects are mentioned and is not intended to imply that the objects described in this way must be arranged in a given order, whether temporally, spatially, or orally, or in any other way.

As used herein, the term "circuit system" can refer to, is a part of, or includes, an application-specific integrated circuit (ASIC), integrated circuit, electronic circuit, processor (shared, dedicated, or grouped), and/or memory (shared, dedicated, or grouped) that executes one or more software or firmware programs, combinational logic circuits, and/or other suitable hardware components that provide the described functionality. In some illustrative embodiments, the circuit system may be implemented by one or more software or firmware modules, or the functionality associated with the circuit system may be implemented by one or more software or firmware modules. In some illustrative embodiments, the circuit system may include logic that is at least partially operable in hardware.

The term "logic" can refer to computational logic, for example, in a circuit system embedded in a computing device, and/or in the memory of a computing device. For example, this logic can be accessed by a processor of the computing device to execute computational logic to perform computational functions and/or operations. In one example, logic can be embedded in various types of memory and/or firmware, such as silicon blocks of various chips and/or processors. Logic can be included in various circuit systems and/or implemented as part of various circuit systems, such as radio circuit systems, receiver circuit systems, control circuit systems, transmitter circuit systems, transceiver circuit systems, processor circuit systems, etc. In one example, logic can be embedded in volatile and/or non-volatile memory, including random access memory, read-only memory, programmable memory, magnetic memory, flash memory, persistent memory, etc. Logic can be executed by one or more processors using memory, such as registers, latches, buffers, etc., connected to one or more processors as needed to execute the logic.

As used below, a "module" is an object file that contains code used to extend the running kernel environment.

As used in this article, the term "software engine" as used below refers to an object file containing code for extending the kernel environment in which it runs.

The term “loyalty club customer” as used below refers to a business-to-business (B2B) customer who has products from a loyalty club and operates loyalty-based mobile services, such as loyalty card applications for their customer base.

As used below, the term "back-end platform" refers to the cloud platform or back-end server of a digital wallet system, which is configured to manage and control digital wallet services and interact with selected third-party systems, as well as digital wallet modules and/or digital wallet engines and/or digital wallet software development kits (SDKs).

The term "EMV," as used below, refers to a payment method based on the technological standards of smart payment cards, payment terminals, and ATMs. EMV originally stood for "Europay, Mastercard, and Visa," the three companies that created the global payment standard.

As used below, "EMV terminal" refers to a payment terminal, also known as a point-of-sale (POS) terminal, credit card terminal, etc. An EMV terminal is a device that interacts with payment cards (such as Europay, Mastercard, and Visa) for electronic funds transfers. This terminal typically consists of a secure keypad for entering a PIN, a screen, a device for collecting information from the payment card, and a network connection for accessing authorized payment networks.

In some illustrative embodiments, the payment terminal may allow merchants to collect the required credit card and/or debit card information and transmit the data to an authorized merchant service provider and/or bank for transferring funds to the merchant. The terminal may also allow merchants and/or their customers to swipe, insert, and/or hold their cards near the device to collect information.

The term "issuer NFC-EMV SDK" as used below can include, for example, an SDK issued and managed by an issuer. Such an SDK may be supported by a single issuer and, when integrated into a mobile application, allows payment elements to communicate with EMV terminals via the NFC protocol.

As used below, the term "server-side SDK" refers to a front-end digital wallet software program. In some illustrative implementations, this program may reside and be integrated within a client platform, and it can manage end-user front-end payment interactions through a connection between the client platform and a client mobile application. For example, transactions may be managed by the client platform against a provider's POS that the client platform can connect to.

The term "Customer Relationship Manager (CRM) Application Programming Interface (API)" as used below refers to an API configured to communicate with a customer CRM. The customer CRM is configured to manage one or more customer rewards programs.

As used below, the term “credit card issuer” can refer to a global company, such as a credit union, that is configured to issue credit cards or payment cards or to grant other companies (such as banks or other credit unions or other businesses) the right to issue credit cards and provide credit to their customers (“issuer”).

As used below, the term "payment service provider (PSP)" can refer to a global company, such as a credit union, which is configured to issue credit cards or payment cards and/or other payment methods and pay for purchases made through the issued cards.

As used below, the term "credit card scheme" can include payment networks linked to credit cards and/or debit cards and/or prepaid cards, for example, banks and/or any other qualified financial institutions and/or credit agencies that can be members of the payment network. For instance, a member of a credit card scheme can be a card issuer and/or a merchant operating on the network of that scheme. Members can also set various rules and restrictions for their schemes.

The term "issuer platform" as used below can include servers such as Mastercard, Visa, EuroPay, and American Express, which can be configured to allow card issuance.

The term “(one or more) cards” as used below can include, for example, prepaid cards, credit cards, debit cards, etc., created and issued by an issuer.

As used below, the term "merchant POS" can include, for example, a credit card terminal of a particular merchant and/or supplier and/or store, on which various payment transactions can be made when an end user decides to use its customer mobile application for payment transactions.

As used below, the term "customer platform" can include, for example, a partner's customer's technology platform configured to interface with a digital wallet to provide payments through the digital wallet platform. The backend technology platform communicates with the customer's mobile application and with the digital wallet SDK, based on the payment configuration selected by the customer and/or partner. For example, the platform may be cloud-based, running on platforms such as Amazon Web Services (AWS) and/or Microsoft Azure.

As used below, the term "customer credit card terminal" can include transaction terminals, EMV, and/or non-EMV that a customer platform can use to generate payment elements for each end-user credit card associated with that customer mobile application. For example, such terminals may reside at a payment gateway company or a processor company.

As used below, the term "customer mobile application" can include at least one application installed on a customer's mobile device, such as an application from a loyalty-based organization, an e-wallet application, etc. A customer mobile application may include a digital wallet SDK and can interact with digital wallet platforms and customer platforms. A customer mobile application can be configured to run on mobile device operating systems such as iOS and Android or React.

As used below, the term "customer CRM" can include, for example, a platform used by a customer to manage their customer base and their rewards programs, as well as other such procedures across various segments and programs, organized by loyalty programs.

The term "digital wallet rules engine" as used below may include, for example, a management system where customers can define various rules, including Merchant Category Codes (MCCs), where MCCs include a generic code on the card scheme that defines various purchase/merchant category (such as, for example, clothing, sneakers, etc.) codes and restrictions for transactions made by end users.

As used below, the term "end user" may include one or more users who use a customer's mobile application.

As used below, the term "payment element" can include a unique placeholder called a payment element, which is configured to include encrypted information about a user's payment capabilities, such as credit card, debit card, or bank transfer information. For example, if the card number is 1234 5678 8765 4321, the payment element identifier could be, for example, E67TL8GC27X. In some illustrative embodiments, the payment element can be configured to access, retrieve, and maintain, for example, a customer's credit card information, to ensure a higher level of security for both the customer and the business. The payment element can be stored on the customer's platform and/or the customer's mobile application.

As used below, a "Payment Element Service Provider (TSP)" is an entity certified by, for example, MasterCard, Visa, or any other issuer, that is authorized to generate EMV payment elements. A TSP can include entities within the payment ecosystem configured to provide registered payment element requesters. For example, a merchant holding a card credential—with an "Agent" Master Account (PAN) value, also referred to as a payment element. This service can be provided, for example, by a gateway service if needed.

First, refer to Figure 1, which shows a block diagram of a system 100 for performing payments via network 175 according to some illustrative embodiments.

In some illustrative embodiments, system 100 may include a payment manager server 110 configured to manage payments over network 175 via one or more payment applications 150. For example, the payment applications may be installed on user equipment 140.

In some illustrative embodiments, the payment server 110 may include a processing circuitry 120. For example, the processing circuitry 120 may be operatively coupled to the payment element issuer module 130 and the communication unit 125.

For example, the processing circuit system 120 may include circuits, logic, memory, operating system, one or more core computers, graphics processors, digital signal processors, etc.

In some illustrative embodiments, the payment element issuer module 130 may be implemented by software and/or by hardware and/or by a combination of software and hardware.

In some illustrative embodiments, the communication unit 125 may include at least one of the following: a wireless local area network (WLAN) transceiver, a local area transceiver (LAN), a cellular transceiver, a short-range communication transceiver (e.g., a near field communication (NFC) transceiver), a satellite transceiver, etc.

In some illustrative embodiments, the processing circuitry 120 may be configured to issue payment element 132 for executing one or more payments via a communication network, wherein payment element 132 may include a user identification string 135. For example, the processing circuitry 120 may be configured to operate the payment element issuer module 130 to issue payment element 132 that may include a user identification (ID) string 135. For example, the user ID string 135 may be encrypted and may include at least one of the following: user identification number, user code, account number, and/or telephone number.

In some illustrative embodiments, the processing circuitry 120 may be configured to send the payment element 132 along with the user identification string 135 to a user application 155 installed on the user device 150. For example, the user application 150 may include a digital wallet if desired.

In some illustrative embodiments, user equipment 140 may include a processing circuitry system 145 and a communication unit 160. For example, the processing circuitry system 145 may include circuitry, logic, memory, an operating system, one or more multi-core computers, a graphics processor, a digital signal processor, etc. For example, the communication unit 160 may include at least one of the following: a wireless local area network (WLAN) transceiver, a local area network (LAN) transceiver, a cellular transceiver, a short-range communication transceiver (e.g., a near field communication (NFC) transceiver), a satellite transceiver, etc.

In some illustrative embodiments, when payment is made by user equipment 140 at payment receiving unit 165, for example by providing a user ID string to receiving unit 165 and/or a payment terminal (not shown) at a merchant point of sale (POS), processing circuitry 120 may be configured to receive a payment request message 180 from payment receiving unit 165 and, in response, send a purchase authorization request message 190 to user account holder server 170. For example, payment receiving unit 165 may include a payment terminal, digital wallet, bank, banking center, cryptocurrency wallet, blockchain server, etc. Payment receiving unit 165 may be implemented in hardware, software, and/or any combination of hardware and software.

In some illustrative embodiments, the user account holder server 170 may include a payment authorization module 172. The payment authorization module 172 may be configured to generate an authorization confirmation message 195. For example, the user account holder server 170 may include a bank, a banking center, a cryptocurrency account, and any other type of account. It should be understood that the payment authorization module 172 may be implemented via software and/or hardware and/or a combination of software and hardware.

For example, payment request message 180 may include a user identification string, the requested payment amount, recipient data, and other data (if needed).

For example, payment permission request message 190 may include a user identification string, the requested payment amount, recipient data, and other data (if needed).

For example, the approval confirmation message 195 may include the payment date, user data, account holder data, payment recipient data, the requested payment amount, and any other data (if needed).

In some illustrative embodiments, the processing circuitry 120 may be configured to send a reply message 185 to the payment receiving unit 165 as a response to the purchase approval request message 190.

For example, response message 185 may include an approval or rejection instruction, user data, the date of payment, the requested payment amount, payee data, and/or any other data (if needed). For example, when the response message includes an approval message 185, processing circuitry 120 may be configured to send the requested payment to payment receiving unit 165 and receive payment from user account holder server 170 based on the requested payment. Conversely, when response message 185 includes a rejection message, processing circuitry 120 may be configured to send a rejection message (not shown) to payment receiving unit 165.

In some other illustrative embodiments, when the response message 185 includes an approval message (not shown), such as an indication of payment approval, the processing circuitry 120 may be configured to send the payment request message 180 to the user account holder server 170 and receive a payment confirmation message from the user account holder server 170.

In one illustrative embodiment, after the payment process has been completed, the processing circuitry 120 can be configured to request the deletion of payment element 155 from user equipment 150 and can issue a new payment element to be used in the next payment. For example, the new payment element may include a new user ID string. The processing circuitry 120 can then send the new payment element to user application 150 at user equipment 140.

In another implementation, the user ID string can be replaced with a new user ID string at user application 150.

In some other implementations, payment element 132 and the user ID string may be retained after the payment process is completed.

Advantageously, System 100 can be configured to receive payments from users, for example, through a digital wallet application using the user ID string 135, in a simple manner similar to today's standard payments made by credit card companies. System 100 can provide users with the ability to easily pay for products and services in stores and online through their bank accounts, just as is customary today with credit card systems.

In some illustrative embodiments, system 100 includes a high-security infrastructure that relies on encrypted payment elements, which can be generated by a central system controlling data elements for payment requests. System 100 can issue a unique user ID string 135 for each transaction, thereby increasing transaction security and providing a robust model for each transaction with its own "address" and its own definition.

In some illustrative implementations, system 100 is configured to generate a “payment method” for each transaction and each customer. The infrastructure of system 100 may not require unique integration for each fund and can operate universally across all funds and/or payment systems, regardless of the type of enterprise, funds, its hardware, its software, etc.

In some illustrative embodiments, system 100 is configured to connect banking systems to the world of payments within a business, such as in stores and/or online, without requiring the creation of a complex and new system for each business, and without requiring the replication of the system within the business. System 100 can be a generic system suitable for all and configured to connect banking systems to businesses, for example, for payments made directly from bank accounts.

Referring now to Figure 2, which illustrates a flowchart of a method 200 for performing a payment via network 200, based on some illustrative embodiments, a server, such as payment manager server 110 (Figure 1), may issue a payment element for performing the payment, such as payment element 132 (Figure 1) (text box 210). For example, the payment element may include a user ID string, such as user ID string 135 (Figure 1). The payment element may be sent to a user device, such as user device 140 (Figure 1), and may be installed and/or loaded into a user application, such as application 155 (Figure 1) (text box 220).

In some illustrative embodiments, the payment process 225 may begin when the payment manager server receives a user ID string from the payee followed by a payment request (e.g., payment request 180 (Figure 1)) (text box 230). In response to the payment request, the server may send a payment permission request (e.g., payment permission request 190 (Figure 1)) to the account holder server (e.g., account holder server 170 (Figure 1)) (text box 240).

In some illustrative implementations, the payment manager server may receive a response message (e.g., response message 185 (Figure 1)) from the account holder server (text box 250). If the response message indicates that the requested payment is permitted (text box 270), the payee may receive payment from either the payment manager server or the account holder server (text box 275).

In some illustrative implementations, the payment manager server may send a payment confirmation message to the payee (text box 260). It should be understood that the method 200 described above can be applied to each payment request.

Referring now to FIG3, which illustrates a flowchart of a method 300 for performing a payment over a network, and according to some other illustrative embodiments, a server (e.g., payment manager server 110 (FIG. 1)) may issue a payment element (e.g., payment element 132 (FIG. 1)) for performing the payment (text box 310). For example, the payment element may include a user ID string, such as user ID string 135 (FIG. 1). The payment element may be sent to a user device, such as user device 140 (FIG. 1), and may be installed and/or loaded into a user application, such as application 155 (FIG. 1) (text box 320).

In some illustrative embodiments, the payment process 325 may begin when the payment manager server receives a payment request (e.g., payment request 180 (Figure 1)) from the payee (text box 330). In response to the payment request, the server may send a payment permission request (e.g., payment permission request 190 (Figure 1)) to the account holder server (e.g., account holder server 170 (Figure 1)) (text box 340).

In some illustrative implementations, the payment manager server may receive a response message (text box 350) from the account holder server, such as a payment approval response message 185 (Figure 1). In response, the payment manager server may send the requested payment to the payee (text box 360) and, as feedback, receive the amount of the payment to the payee from the user account holder server (text box 370).

In some illustrative implementations, the payment manager server may send a request to delete a payment element or a user ID string, or both, and may issue a new payment element or a new user ID string, or both (text box 380). It should be understood that the method 300 described above can be applied to each payment request.

Referring now to Figure 4, which illustrates a flowchart of a method 400 for performing a payment over a network, according to some other illustrative embodiments, a server (e.g., payment manager server 110 (Figure 1)) may issue a payment element (e.g., payment element 132 (Figure 1)) for performing the payment (text box 410). For example, the payment element may include a user ID string, such as user ID string 135 (Figure 1). The payment element may be sent to a user device, such as user device 140 (Figure 1), and may be installed and/or loaded into a user application, such as application 155 (Figure 1) (text box 420).

In some illustrative embodiments, the payment process 425 may begin when the payment manager server receives a user ID string from the payee followed by a payment request (e.g., payment request 180 (Figure 1)) (text box 430). In response to the payment request, the server may send a payment permission request (e.g., payment permission request 190 (Figure 1)) to the account holder server (e.g., account holder server 170 (Figure 1)) (text box 440).

In some illustrative embodiments, the payment manager server may receive a response message (text box 450) from the account holder server, such as a payment approval response message 185 (FIG. 1). In this embodiment, the payment may be completed, for example, by the user account holder server, and the payment manager server may receive a payment confirmation message (text box 460) from the user account holder server. For example, the payment confirmation message may include an indication of the amount paid to the payee.

In some illustrative implementations, the payment manager server may send a request to delete a payment element or a user ID string, or both, and may issue a new payment element or a new user ID string, or both (text box 470). It should be understood that the method 400 described above can be applied to each payment request.

Referring now to Figure 5, which is a schematic diagram of the frame structure of a payment request message 500, according to some other illustrative embodiments, the payment request message 500 may include, for example, the following fields: header 510, user ID string 520, payment unit 530, total requested payment 540, payee data 550, payment method 560, and footer 570. It should be understood that the above are merely examples, and the payment request message may also contain other fields.

In some illustrative implementations, header 510 may include a message ID and any other fields. User ID string 520 may include, for example, a user identifier, user code, account number, phone number, and/or any other data. Payment unit 530 may include a currency type, such as US dollars, euros, cryptocurrency, etc. Total field 540 may include the requested payment amount. Payee data field 550 may include, for example, payee name, payee ID, payee bank account number, payee IBAN, payee SWIPT, etc. Payment method field 560 may include, for example, the number of payments, credit payment, debit payment, remittance, etc. Footer 570 may include, for example, an error detection number, an error correction number, etc.

Referring now to Figure 6, which is a schematic diagram of the frame structure of a payment confirmation message 600, according to some other illustrative embodiments, the payment confirmation message 600 may include, for example, the following fields: header 610, account holder server data 620, user data 630, payment date 640, total requested payment 650, payee data 660, payment method 670, and footer 680. It should be understood that the above are merely examples, and other fields may also be included in the payment request message.

In some illustrative implementations, header 610 may include a message ID and any other fields. User account holder data 620 may include, for example, a server IP address, user account ID, etc. User data field 630 may include a user ID string, user bank account data, etc. Date field 640 may include the date and time of the transaction, etc. Payment unit 640 may include a currency type, such as US dollars, euros, cryptocurrency, etc. Total field 650 may include the requested payment amount, for example. Payee data field 660 may include, for example, payee name, payee ID, payee bank account number, payee IBAN, payee SWIPT, etc. Payment method field 670 may include, for example, the number of payments, credit payment, debit payment, remittance, etc. Footer 670 may include, for example, an error detection number, an error correction number, etc.

Referring now to Figure 7, which is a schematic diagram of the frame structure of a grant request message 700, according to some illustrative embodiments, the grant request message 700 may include, for example, the following fields: header 710, user ID string 720, payment unit 730, requested payment sum 740, payee data 750, payment method 760, and footer 770. It should be understood that the above are merely examples, and other fields may be included in the payment request message.

In some illustrative implementations, header 710 may include a message ID and any other fields. User ID string 720 may include, for example, a user identifier, user code, account number, phone number, and/or any other data. Payment unit 730 may include a currency type, such as US dollars, euros, cryptocurrency, etc. Total field 740 may include the requested payment amount. Payee data field 750 may include, for example, payee name, payee ID, payee bank account number, payee IBAN, payee SWIPT, etc. Payment method field 760 may include, for example, the number of payments, credit payment, debit payment, remittance, etc. Footer 770 may include, for example, an error detection number, an error correction number, etc.

Referring now to Figure 8, which is a schematic diagram of the frame structure of a response message 800, the response message 800 may include, for example, the following fields: header 810, allow/deny field 820, user data field 830, date field 840, total requested payment 850, payee data field 860, and footer 870. It should be understood that the above are merely examples, and other fields may be included in the payment request message.

In some illustrative implementations, header 810 may include a message ID and any other fields. The permit/deny field 820 may include a permit flag and/or a denial flag and/or any other indication. User data field 830 may include a user ID string, user bank account data, etc. Date field 840 may include the date and time of the transaction, etc. Sum field 850 may include the requested payment amount. Payee data field 860 may include, for example, payee name, payee ID, payee bank account number, payee IBAN, payee SWIPT, etc. Footer 870 may include, for example, an error detection number, an error correction number, etc.

Referring now to Figure 9, which is a schematic diagram of the frame structure of a user ID string 900, according to some illustrative embodiments, the user ID 900 may include a header 910, a user ID 920, a user code 930, a user payment account 940, a user phone number 950, and a footer 960.

In some illustrative embodiments, header 910 may include a message ID and any other fields. User ID field 920 may include, for example, a national security number, driver's license number, passport number, ID number, etc. User code field 830 may include, for example, a personal code issued to the user. User payment account field 940 may include, for example, a user's bank account number. Telephone number field 950 may include, for example, a user's mobile phone number, user's office phone number, user's landline phone number, etc. Footer 960 may include, for example, an error detection number, an error correction number, etc.

In some illustrative implementations, the user ID string 940 may be included in protocol messages, such as payment request message 500 (Figure 5), permission request message 700 (Figure 7), payment element 155 (Figure 1), etc.

According to some illustrative embodiments, referring to FIG10, FIG10 is a schematic diagram of manufacturing product 1000. Product 1000 may include one or more tangible computer-readable non-transitory storage media 1010, which may include computer-executable instructions 1030 implemented by processing device 1020. When executed by at least one computer processor, the computer-executable instructions 1030 are operable to enable at least one processing circuit system 120 (FIG. 1) to implement one or more program instructions for purchasing goods and/or services via a network, and/or to execute, trigger, and/or implement one or more operations, communications, and/or functions as described above with reference to FIG1 to FIG9. The phrase "non-transitory machine-readable medium" is intended to include all computer-readable media, with the sole exception of transient propagation signals.

In some illustrative embodiments, product 1000 and/or machine-readable storage medium 910 may include one or more types of computer-readable storage media capable of storing data, including volatile memory, non-volatile memory, removable or non-removable memory, erasable or non-erasable memory, writable or rewritable memory, etc. For example, machine-readable storage medium 510 may include any type of memory, such as, for example, RAM, DRAM, ROM, programmable ROM (PROM), erasable programmable ROM (EPROM), electrically erasable programmable ROM (EEPROM), flash memory, hard disk drive (HDD), solid-state drive (SDD), fusion drive, etc. The computer-readable storage medium may include any suitable medium relating to downloading or transferring a computer program from a remote computer to a requesting computer via a communication link, such as a modem, radio, or network connection, carried by a data signal contained in a carrier wave or other propagation medium.

In some illustrative embodiments, the processing device 1020 may include logic. The logic may include instructions, data, and/or code, which, when executed by a machine, can cause the machine to perform the methods, processes, and/or operations described herein. The machine may include, for example, any suitable processing platform, computing platform, computing device, processing device, computing system, processing system, computer, processor, etc., and may be implemented using any suitable combination of hardware, software, firmware, etc.

In some illustrative embodiments, the processing device 1020 may include or be implemented as software, firmware, software modules, applications, programs, subroutines, instructions, instruction sets, computational code, words, values, symbols, etc. Instructions 1040 may include any suitable type of code, such as source code, compiled code, interpreted code, executable code, static code, dynamic code, etc. Instructions can be implemented according to predefined computer languages, methods, or syntaxes to instruct the processor to perform specific functions. Instructions can be implemented using any suitable high-level, low-level, object-oriented, visual, compiled, and/or interpreted programming languages, such as C, C++, C#, Java, Python, assembly language, machine code, etc.

It should be understood that the system and/or method for generating maps of underground utilities has been described above by way of example only. Other embodiments may be implemented based on the detailed description and the appended claims.

It should be understood that similar reference numerals in the accompanying drawings indicate similar elements in multiple figures, and not all components and/or steps need to be described and shown with reference to the accompanying drawings for all embodiments or arrangements.

It should also be understood that the implementations, arrangements, and/or arrangements of the systems and methods disclosed herein may be incorporated as software algorithms, applications, programs, modules, or code residing in hardware, firmware, and/or on computer-usable media (including software modules and browser plugins), which may be executed in the processor of a computer system or computing device to configure the processor and/or other elements to perform the functions and/or operations described herein.

It should be understood that, according to at least one embodiment, when executed, one or more computer programs, modules, and/or applications performing the methods of the present invention do not need to reside on a single computer or processor, but can be distributed in a modular style across multiple different computers or processors to implement various aspects of the systems and methods disclosed herein.

Therefore, the illustrative embodiments and arrangements of this system and method provide computer-implemented methods, computer systems, and computer program products for processing code. The flowcharts and block diagrams in the accompanying drawings illustrate the architecture, functionality, and operation of possible implementations of the system, method, and computer program product according to various embodiments and arrangements. In this regard, each block in a flowchart or block diagram may represent a module, segment, or code portion, and each block in a flowchart or block diagram includes one or more executable instructions for implementing a specific logical function.

It should also be noted that in some alternative implementations, the functions marked in the boxes may not occur in the order shown in the figures. For example, two boxes shown consecutively may be executed substantially simultaneously, or these boxes may sometimes be executed in reverse order, depending on the functions involved. It should also be pointed out that each box in the block diagram and/or flowchart, and combinations of boxes in the block diagram and/or flowchart, may be implemented by a hardware-based system or a combination of dedicated hardware and computer instructions for a specific purpose that performs a specific function or action.

The terminology used herein is for describing particular embodiments only and is not intended to limit the invention. As used herein, the singular forms “a,” “an,” and “the” are also intended to include the plural forms unless the context clearly indicates otherwise. It should also be understood that when the terms “comprising” and/or “including” are used in this specification, they specify the presence of stated features, integrals, steps, operations, elements, and/or components, but do not exclude the presence or addition of one or more other features, integrals, steps, operations, elements, components, and/or groups thereof.

Furthermore, the wording and terminology used herein are for descriptive purposes and should not be considered limiting. The terms “including,” “comprising,” or “having,” “containing,” “involving,” and variations thereof, as used herein, are intended to cover the items listed thereafter and their equivalents, as well as any additional items.

Now refer to Figure 11. Figure 11 shows a block diagram of another embodiment of a system 1100 configured to perform payments over a network, according to some illustrative embodiments.

In some illustrative embodiments, system 1100 may include user equipment 1101. For example, the user equipment may include a payment application (not shown). The payment application may be configured to perform payments at points of sale and/or over a network using a user identifier (ID) string.

In some illustrative embodiments, user equipment 1101 may include a mobile phone, tablet computer, or mobile computer, such as, for example, a laptop computer.

In some illustrative embodiments, system 1100 may include a payment server 1102. For example, payment server 1102 may be configured to pay for purchases completed by a payment application and/or request another device to perform payments at a POS.

In some illustrative embodiments, system 1100 may include a user account holder server 1103. For example, user account holder server 1103 may be a server of a bank, a banking center, an organization with loyalty programs, etc.

In some illustrative embodiments, user device 1101 (e.g., a mobile device, phone, etc.) may request user account server 1103 to issue a user ID string (dashed line 1111). User device 1101 may perform registration with payment server 1102 (line 1114). For example, in this illustrative embodiment, user device 1101 transmits the user ID string to payment server 1102 during registration without exposing any other information about the user. In response, payment server 1102 may issue payment elements to be downloaded to, for example, a payment application installed on user device 1101 (line 1115).

In some other illustrative embodiments, user device 1101 (e.g., mobile device, mobile phone, etc.) may perform registration with payment server 1102 (line 1114). For example, in this illustrative embodiment, user device 1101 may provide usage and/or details to payment server 1102 when performing registration. For example, user information may include username, user address, user email address, user ID number, user bank account details, and details of any other requested information. Payment server 1102 may deliver user information to user account server 1103 and may receive user ID string (dashed line 1112). In response, payment server 1102 may issue payment elements to be downloaded to, for example, a payment application installed on user device 1101 (line 1115).

In some illustrative embodiments, system 1100 may include a payment receiving unit 1104. For example, payment receiving unit 1104 may include a payment terminal and/or cash register at a POS terminal.

In some illustrative embodiments, the payment server 1102 may send payment elements to a user application installed on the user equipment 1101. For example, the payment application may be configured to use the payment elements to perform a payment at the payment receiving unit 1104.

In some illustrative embodiments, the payment server 1102 may execute payment transactions (line 1117) using the payment receiving unit 1104.

For example, a payment transaction (line 1117) may include sending a payment request message (line 1116) to a payment server 1102, and receiving a payment request message (line 1116) from a payment receiving unit 1104 at the payment server 1102. When making a payment, the payment server 1102 may be configured to send a purchase approval request message (line 1113) to a user account holder server 1103, and send a reply message (line 1113) as a response to the payment approval request to the payment receiving unit 1104.

In another illustrative embodiment, the payment server 1102 can transfer the required payment to the payment receiving unit 1104.

The aforementioned systems and methods enable users of payment applications to purchase goods and services without credit cards and/or debit cards and/or any other payment cards. Payments can be completed directly from the user's bank account without exposing its details and/or bank account details to the payment server and/or payment receiving unit.

The subject matter described above is provided by way of illustration only and should not be construed as limiting. Various modifications and changes may be made to the subject matter described herein without following the exemplary implementations and applications shown and described and without departing from the true spirit and scope of the invention as set forth in the appended claims.

Claims (33)

1. A payment server, the payment server comprising a processing circuitry system, wherein the processing circuitry system is configured to: Issuing a payment element for executing one or more payments via a communication network, wherein the payment element includes a user identification string configured to identify a user account at a user account holder server without exposing one or more details of the user to a payment receiving unit; Send the user identification string to the user application installed on the user's device; When the user equipment provides the user identifier string to the payment receiving unit to make a payment, a payment request message is received from the payment receiving unit; Send a purchase permission request message to the user account holder server; and A reply message is sent to the payment receiving unit as a response to the payment approval request. 2. The payment server according to claim 1, wherein, when the reply message includes an approval message, the processing circuitry is configured to: Send the requested payment to the payment receiving unit; and Payment is received from the user account holder's server based on the requested payment. 3. The payment server according to claim 1, wherein the user identifier string includes at least one of the following: User ID, user code, payment account, and phone number. 4. The payment server according to claim 1, wherein the user identifier string is encrypted. 5. The payment server according to claim 1, wherein when the reply message includes a rejection message, the processing circuitry is configured to send a rejection message to the payment receiving unit. 6. The payment server according to claim 1, wherein, when the reply message includes an approval message, the processing circuitry is configured to: Send the payment request message to the user account holder's server; and Receive payment confirmation message from the user account holder's server. 7. The payment server according to claim 1, wherein the processing circuit system is configured to: After the payment process is completed at the user application in the user device, a request is made to delete the payment element; Issue a new payment element that the user will use in the next payment, wherein the new payment element includes a new user identification string; and The new payment element is sent to the user application on the user device. 8. The payment server according to claim 1, wherein the payment request message includes: The user identification string, the requested payment amount, the payment method, and the payee data. 9. The payment server according to claim 1, wherein the payment confirmation message includes at least one of the following: payment date, user data, account holder details, payee data, payment method, and the requested amount for payment to the payee. 10. The payment server according to claim 1, wherein the permission request message includes at least: the user identifier string, payee data, payment method, and the requested payment amount. 11. The payment server according to claim 1, wherein the user account holder includes at least one of the following: a bank and a banking center. 12. The payment server according to claim 1, wherein the user application includes a digital wallet. 13. The payment server according to claim 1, wherein the user equipment includes at least one of the following: a desktop computer, a laptop computer, a mobile device, or a mobile phone. 14. The payment server according to claim 1, wherein the payment server is configured to: Execute a registration session with the user equipment, wherein the registration session includes: Receive a user identifier string from the user equipment; and The payment element is issued based on the identifier string, and the payment element will be downloaded and installed on the payment application on the user's device. 15. The payment server according to claim 1, wherein the payment server is configured to: Execute a registration session with the user equipment, wherein the registration session includes: Receive user information from the user equipment; Receive an identifier string from the user account holder server; and The payment element is issued based on the identifier string, and the payment element will be downloaded and installed on the payment application on the user's device. 16. The payment server according to claim 15, wherein the user information includes: username, user address, user email address, user identifier, and user bank account details. 17. A product comprising one or more tangible computer-readable non-transitory storage media, the tangible computer-readable non-transitory storage media including program instructions for performing payment via a communication network, wherein execution of the program instructions includes: Issuing a payment element for executing one or more payments through the communication network, wherein the payment element includes a user identification string configured to identify a user account at a user account holder server without exposing one or more details of the user to a payment receiving unit; Send the user identification string to the user application installed on the user's device; When the user equipment provides the user identifier string to the payment receiving unit to make a payment, a payment request message is received from the payment receiving unit; Send a purchase permission request message to the user account holder's server; and A reply message is sent to the payment receiving unit as a response to the payment approval request. 18. The product of claim 17, wherein, when the response message includes a permission message, the execution of the program instructions includes: Send the requested payment to the payment receiving unit; and Payment is received from the user account holder's server based on the requested payment. 19. The product of claim 17, wherein the user identification string includes at least one of the following: User ID, user code, account, and phone number. 20. The product of claim 17, wherein, when the reply message includes a rejection message, the execution of the program instructions includes sending a rejection message to the payment receiving unit. 21. The product of claim 17, wherein, when the response message includes a permission message, the execution of the program instructions includes: Send the payment request message to the user account holder's server; and Receive payment confirmation message from the user account holder's server. 22. The product according to claim 17, wherein the execution of the program instructions includes: After the payment process is completed at the user application in the user device, a request is made to delete the payment element; Issue a new payment element that the user will use in the next payment, wherein the new payment element includes a new user identification string; and The new payment element is sent to the user application on the user device. 23. The product of claim 17, wherein the payment request message includes at least one of the following: The user identification string, the requested payment amount, the payment method, and the payee data. 24. The product of claim 17, wherein the payment confirmation message includes at least one of the following: the date of payment, user data, account holder details, payee data, payment method, and the requested amount for payment to the payee. 25. The product of claim 17, wherein the permission request message includes at least: the user identifier string, payee data, payment method, and the requested payment amount. 26. The product according to claim 17, wherein the execution of the program instructions includes: Execute a registration session with the user equipment, wherein the registration session includes: Receive a user identifier string from the user equipment; and The payment element is issued based on the identifier string, and the payment element will be downloaded and installed on the payment application on the user's device. 27. The payment server according to claim 17, wherein the execution of the program instructions includes: Execute a registration session with the user equipment, wherein the registration session includes: Receive user information from the user equipment; Receive an identifier string from the user account holder server; and The payment element is issued based on the identifier string, and the payment element will be downloaded and installed on the payment application on the user's device. 28. The product according to claim 27, wherein the user information includes: username, user address, user email address, user identifier, and user bank account details. 29. A payment server, the payment server being configured to: Receive a user identifier string from the user account holder server, wherein the user identifier string is configured to connect to the user account at the user account holder server without exposing other user details to the payment receiving unit; Payment elements are issued based on the user identifier string; The payment element is sent to a user application installed on the user's device, the user application being configured to perform a payment using the payment element at the payment receiving unit; and The payment transaction is conducted with the payment receiving unit. 30. The payment server according to claim 29, wherein the payment transaction includes: Send a payment request message to the payment server; The payment server receives the payment request message from the payment receiving unit. During payment, the payment server is configured to send a purchase permission request message to the user account holder server; and A reply message is sent to the payment receiving unit as a response to the payment approval request. 31. The payment server according to claim 29, wherein the payment server is configured to: Execute a registration session with the user equipment, wherein the registration session includes: Receive a user identifier string from the user equipment; and The payment element is issued based on the identifier string, and the payment element will be downloaded and installed on the payment application on the user's device. 32. The payment server according to claim 29, wherein the payment server is configured to: Execute a registration session with the user equipment, wherein the registration session includes: Receive user information from the user equipment; Receive an identifier string from the user account holder's server; and The payment element is issued based on the identifier string, and the payment element will be downloaded and installed on the payment application on the user's device. 33. The payment server according to claim 32, wherein the user information includes: username, user address, user email address, user identifier, and user bank account details.