Payment and charging system using URL media and internet sites.

Abstract

It provides a means to charge money to an outside medium (URL vault) or to make payments with money outside the medium using a medium (URL medium) and an internet site (vault site), and supports the settlement of various transactions and various charges. To provide safer, more convenient, and more economical payment and charging methods.

Description

[Technical field]

[0001] Use a medium to make payments or charge. [Background technology]

[0002] (Types of payment and overview) There are RF card payment, URL-NFC-CC payment (see Korean Patent No. 10-2016-0063699 (KR No. 10-1751640) and 10-2017-0096573 (KR No. 10-1941587)), app and smartphone payment (WeChat Pay and ALIPay), etc. The above types of payment differ in the systems and methods that connect the medium and "storing money" and the medium and "storing money".

[0003] (Definition and types of media) Media are owned by users and store the information and methods required for payment and charging. There are RF cards, URL-NFC-CC, and apps & smartphones (smartphones with apps installed).

[0004] ("Storing Money") RF card payments store money on the RF card, URL-NFC-CC payments store money in an account (CC account) connected to a system that complies with credit card standards, and app & smartphone payments store money in an account (app & smartphone account) connected to a system that uses an app and a mobile communication network.

[0005] (System and method for connecting media and "saving money") RF card payments do not require a connection means, URL-NFC-CC payments connect using the credit card communication network and the Internet, and app and smartphone payments connect using the app, a smartphone equipped with a USIM card, and the app and mobile communication network.

[0006] (Credit card communication network) The credit card communication network is a communication network that connects media that comply with credit card standards (URL-NFC-CC), CC-POS, and the CCP server of the credit card company's CCC server.

[0007] (Application & Mobile Communication Network) Application & Mobile Communication Network is a communication network in which the medium (Application & Smartphone: smartphone with application and USIM), application POS, application server, etc. are connected to the mobile communication network.

[0008] (Types of payment channels and their relationship with media) Payment channels include those that require face-to-face tagging (RF card payment), those that use different communication networks (URL-NFC-CC payment), those that incur fees, those that require special equipment, and those that use the internal operation of the media and external communication networks (app & smartphone payment). The types of channels, channel costs, and payment competitiveness vary depending on the media.

[0009] (Relationship between payment process and media) The payment process can be divided into the payment request process, the user verification process, and the payment process, but the content, order, and competitiveness of the payment process differ depending on the media.

[0010] (Relationship between types of transactions and charge and media) a) Face-to-face transactions without verifying the user, b) Face-to-face transactions where the user is verified after a payment is requested, c) Face-to-face transactions where the user is verified after a payment is requested, d) Non-face-to-face transactions where the user is verified after a payment is requested, e) Non-face-to-face transactions where the user is verified after a payment is requested, f) Face-to-face transactions using two media without verifying the user, g) Face-to-face transactions using two media after verifying the user, h) Face-to-face transactions where provisional payment is made, i) Non-face-to-face charge where the user is verified before charging, j) Face-to-face charge where money is paid to three parties and the three parties act as agents for the charge, k) Face-to-face charge where money (coupons) generated from transactions etc. are charged, l) Non-face-to-face charge where money (coupons) generated from transactions etc. are charged. The types of transactions and charge and their competitiveness differ depending on the media.

[0011] (Payment process by medium) a) RF card payments do not have a user verification process, instead, the RF card is tagged into the RF card payment machine to request a payment (payment request process), and the money on the RF card is deducted and paid (money payment process). b) URL-NFC-CC payments send credit card information (CC information) to the credit card company's CCP server via the credit card network (payment request process), and the CCW-URL-PWD and CCW-URL are sent to the credit card company's CCW server (user verification process), and the money from the account (CC account) linked to the credit card network is transferred to another account (money payment process). c) App & smartphone payments send the app PWD to the app & smartphone and generate a QR code (user verification process), and the QR code is sent to the app server via the app POS and app & mobile communication network (payment request process), and the money from the account (app & smartphone account) linked to the app & mobile communication network is transferred to another account (money payment process).

[0012] (Order of payment request process and user authentication process by medium) RF cards do not authenticate the user, so there is no order, URL-NFC-CC can change the order of payment request process and user authentication process, and apps and smartphones can only perform the user authentication process first and then the payment request process. Summary of the Invention [Problem to be solved by the invention]

[0013] Providing simpler, more economical payment and recharge methods.

[0014] Provide payment and charging methods that can be applied to a wider variety of transactions.

[0015] We provide payment and charging methods that are structurally insulated from hacking.

[0016] Providing payment and charging methods that can support additional services more economically. [Means for solving the problem]

[0017] (Payment in face-to-face transactions without user verification, see Figures 5 and 6) A system and method in which the URL medium, user, URL-POS, safe server, URL safe, collection account, payment request, safe URL, URL-POS information, payment command, money, payment command result, payment result, etc. operate organically, using the URL medium and an Internet site to make a payment with money outside the URL medium.

[0018] (Payment in face-to-face transactions where the user is confirmed after a payment is requested, see Figures 7 and 8) Payment is made with money outside the URL medium using a URL medium and an Internet site in a system and method in which the URL medium, user, URL-POS, terminal, safe server, URL safe, collection account, payment request, safe URL, URL-POS information, safe site, terminal information, safe URL-PWD, result of safe URL-PWD confirmation, order details, order confirmation, payment command, money, result of payment command, and payment result all operate organically.

[0019] (Payment for face-to-face transactions where payment is requested after verifying the user, see Figures 9 and 10) Payment is made with money outside the URL medium using a URL medium and an Internet site in a system and method in which the URL medium, user, terminal, URL-POS, safe server, URL safe, collection account, safe URL, safe site, terminal information, safe URL-PWD, result of safe URL-PWD verification, payment schedule, payment request, URL-POS information, payment command, money, result of payment command, and payment result all operate organically.

[0020] (Payment of non-face-to-face transactions in which the user is confirmed after a payment is requested, see Figures 11 and 12) Payment is made with money outside the URL medium using the URL medium and an internet site in a system and method in which the URL medium, user, terminal, sales server, safe server, URL safe, collection account, sales server connection command, sales site, payment request, order number, sales server information, safe URL, safe site, terminal information, safe URL-PWD, results of safe URL-PWD confirmation, order details, order confirmation, payment command, money, results of payment command, and payment results all operate organically.

[0021] (Payment of non-face-to-face transactions in which payment is requested after verifying the user, see Figures 13 and 14) Payment is made with money outside the URL medium using a URL medium and an Internet site in a system and method in which the URL medium, user, terminal, sales server, safe server, URL safe, collection account, safe URL, safe site, terminal information, safe URL-PWD, result of safe URL-PWD verification, payment schedule, sales server connection command, sales site, payment request, sales server information, payment command, money, result of payment command, and payment result all operate organically.

[0022] (Payment for face-to-face transactions using two URL mediums without verifying the user, see Figures 15 and 16) Payment is made with money outside the URL medium using a URL medium and an Internet site in a system and method in which URL medium B, URL medium S, user B, terminal, safe server, URL safe B, collection account S, safe URL-B, safe site B, terminal information, payment request, safe URL-S, payment command, money, result of payment command, payment result, etc. operate organically.

[0023] (Payment for face-to-face transactions using two URL media after verifying a user, see Figures 17 and 18) Payment is made with money outside the URL medium using a URL medium and an Internet site in a system and method in which URL medium B, URL medium S, user B, terminal, safe server, URL safe B, collection account S, safe URL-B, safe site B, terminal information, safe URL-B-PWD, result of safe URL-B-PWD verification, payment request, safe URL-S, payment command, money, result of payment command, payment result, etc. operate organically.

[0024] (Payment of face-to-face transactions with provisional settlement, see Figures 19 and 20) Payment is made with money outside the URL medium using a system and method in which the URL medium, user, URL-POS, payment request, safe URL, and payment result all operate organically.

[0025] (Non-face-to-face charging that charges after verifying the user, see Figures 21 and 22) Money is charged outside the URL medium using the URL medium and an internet site in a system and method in which the URL medium, user, terminal, safe server, money supply, URL safe, safe URL, safe site, safe URL-PWD, result of safe URL-PWD verification, charge request, charge command, money, result of charge command, charge result, etc. operate organically.

[0026] (Face-to-face charging where money is paid to three parties and charging is performed on behalf of the other parties, see Figures 23 and 24) Money is charged outside the URL medium using the URL medium and an internet site in a system and method in which the URL medium, user, URL-POS, safe server, money supply, URL safe, charging agent request, safe URL, URL-POS information, charging command, money, charging command result, charging agent result, etc. operate organically.

[0027] (Face-to-face charging of coupons generated through transactions, etc., see Figures 25 and 26) A coupon is charged outside of the URL medium using the URL medium and an internet site in a system and method in which the URL medium, user, URL-POS, safe server, URL safe, charge request, safe URL, URL-POS information, coupons, charge results, etc. operate organically.

[0028] (Non-face-to-face charging, which charges coupons generated through transactions, etc., see Figures 27 and 28) A system and method in which the URL medium, user, terminal, sales server, safe server, URL safe, charge request, URL medium information, sales server information, coupons, and charge results operate organically, and a coupon is charged outside the URL medium using the URL medium and an internet site. Effect of the Invention

[0029] It can provide simpler and more economical payment and top-up methods.

[0030] It is possible to provide simpler, more economical payment and charging methods that can be applied to a variety of transactions.

[0031] It is possible to provide payment and charging methods that are structurally resistant to hacking.

[0032] It is possible to provide payment and recharge methods that can further reduce fees.

[0033] We can provide payment and charging methods that can create greater added value. [Brief description of the drawings]

[0034] Figure 1 shows the block diagram and flow chart of the system for charging an RF card and making payments with the money on the RF card.

[0035] Figure 2 is a diagram of the system configuration that uses the URL-NFC-CC and the credit card communication network and Internet site to make payments with money outside the URL-NFC-CC. (It can be compared with Figure 7 of the invention.)

[0036] Figure 3 is a flow chart of Figure 2 (which can be compared with Figure 8 of the invention).

[0037] Figure 4 is a configuration diagram and a flow chart of a system that uses an app & smartphone and an app & mobile communication network to make payments with money outside the app & smartphone (these are configuration diagrams and flow charts of WeChat Pay and ALIPAY). (It can be compared with Figures 7 and 8 of the invention.)

[0038] Figure 5 is a diagram showing the configuration of a system for making payments with money outside the URL medium, using a URL medium and an Internet site in a face-to-face transaction that does not verify the user (see claim 1).

[0039] FIG. 6 is a flow chart of FIG. 5 (see claim 2).

[0040] Figure 7 is a diagram showing the configuration of a system for making a payment with money outside the URL medium using a URL medium and an Internet site in a face-to-face transaction that confirms the user after requesting a payment (see claim 3).

[0041] FIG. 8 is a flow chart of FIG. 7 (see claim 4).

[0042] Figure 9 is a diagram showing the configuration of a system that uses a URL medium and an Internet site in a face-to-face transaction that requests payment after verifying the user, and makes a payment with money outside the URL medium (see claim 5).

[0043] FIG. 10 is a flow chart of FIG. 9 (see claim 6).

[0044] Figure 11 is a configuration diagram of a system for making a payment with money outside the URL medium using a URL medium and an Internet site in a non-face-to-face transaction that confirms the user after requesting a payment (see claim 7).

[0045] FIG. 12 is a flow chart of FIG. 11 (see claim 8).

[0046] Figure 13 is a diagram showing the configuration of a system that uses a URL medium and an Internet site for non-face-to-face transactions that request payment after verifying the user, and allows payment with money outside the URL medium.

[0047] Figure 14 is a flow chart of Figure 21.

[0048] Figure 15 is a configuration diagram of a system for making a payment with money outside the URL medium, using two URL media and an Internet site in a face-to-face transaction without verifying the user (see claim 9).

[0049] FIG. 16 is a flow chart of FIG. 15 (see claim 10).

[0050] Figure 17 is a diagram of the system configuration that uses two URL media and an Internet site in a face-to-face transaction that verifies the user, and makes payments with money outside the URL media.

[0051] Figure 18 is a flow chart of Figure 17.

[0052] Fig. 19 is a diagram showing the configuration of a system that uses a URL medium in a face-to-face transaction for provisional settlement and settles with money outside the URL medium (see claim 15).

[0053] FIG. 20 is a flow chart of FIG. 19 (see claim 16).

[0054] FIG. 21 is a diagram showing the configuration of a system for charging money outside of a URL medium using a URL medium and an Internet site in a non-face-to-face charging method in which the user is confirmed before charging (see claim 11).

[0055] FIG. 22 is a flow chart of FIG. 21 (see claim 12).

[0056] FIG. 23 is a diagram showing the configuration of a system for charging money to an outside URL medium using a URL medium and an Internet site in face-to-face charging, where money is paid to three parties and the charging is performed on their behalf (see claim 13).

[0057] FIG. 24 is a flow chart of FIG. 23 (see claim 14).

[0058] Figure 25 is a diagram showing the configuration of a system for charging coupons generated from transactions etc., using a URL medium and an Internet site for face-to-face charging, and charging coupons outside the URL medium.

[0059] Figure 26 is a flow chart of Figure 25.

[0060] Figure 27 is a diagram showing the configuration of a system for non-face-to-face charging, which charges coupons generated by transactions, etc., by using a URL medium and an Internet site to charge coupons outside the URL medium.

[0061] Figure 28 is a flow chart of Figure 27. DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS

[0062] DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS Hereinafter, preferred embodiments of the present invention will be described in detail with reference to the accompanying drawings. The terms used in this specification and the claims should not be construed as being limited to their ordinary or dictionary meanings, but should be construed in a meaning and concept that matches the technical subject matter of the present invention.

[0063] The embodiments described in this specification and the configurations illustrated in the drawings are preferred embodiments of the present invention, and do not represent all of the technical ideas of the present invention. There may be various equivalents and modifications that can replace them at the time of this application.

[0064] A URL (Uniform Resource Locator) refers to the location of a file on a web server that provides web documents and various services.

[0065] <Charging and payment with conventional RF cards, see Figure 1>

[0066] (Overview of RF card charging system and operation)

[0067] The user, RF card charger, RF card, money transmission & RF card charge request, RF card charge, etc. operate organically to charge money onto the RF card.

[0068] The user transmits a money transfer & RF card charge request to the RF card charger, and the RF card charger transmits the RF card charge to the RF card in response to the money transfer & RF card charge request to charge the money.

[0069] (Overview of RF card payment system and operation)

[0070] The user, RF card payment machine, RF card, RF card payment request, RF card payment, etc. all function organically, and payment is made with money on the RF card.

[0071] The user transfers a RF card payment request to the RF card payment machine, and the RF card payment machine transfers the RF card payment to the RF card for payment.

[0072] (Description of RF card elements)

[0073] An RF card is a medium that can store money as electronic information and transmit electronic information to the outside.

[0074] A user is a person who owns an RF card.

[0075] An RF card charger is a device that can receive money and charge money onto an RF card.

[0076] Money transfer & RF charge request is a request to transfer money and charge money to an RF card.

[0077] RF card charge allows you to charge money onto an RF card.

[0078] An RF card payment machine is a device that allows you to make payments with money on an RF card.

[0079] An RF card payment request is a request to make a payment with money on an RF card.

[0080] RF card payment is payment made with money on an RF card.

[0081] (About Korea's T-money (transport card)) Korea's T-money is a kind of RF card, which loads money into a central T-money account as electronic information and does not distinguish between users. The central T-money account manages the serial number and charge amount of T-money, and deducts the charge amount from the T-money charge amount without verifying the user. Since the user is not verified, if T-money is lost, the balance cannot be compensated.

[0082] (Characteristics of RF card payments) a) Money is stored inside the RF card, b) A payment request is made by tagging the RF card to an RF card payment machine, c) there is no user verification process, d) The payment process is made by deducting money from the RF card, e) If the RF card is lost, the balance cannot be compensated, f) no confidential information is used when making payments, g) payments can only be made at the store that issued the RF card, h) it cannot be applied to various transactions, i) it cannot be used for large payments, j) an RF card is created for each store, and k) money is transferred to the seller in advance.

[0083] (Comparison of RF cards and URL media) a) RF cards store money internally, but URL media stores it externally, b) RF cards do not have any secret information, but URL media does have secret information (safe URL-PWD), c) If an RF card is lost, the balance is not protected, but if a URL media is lost, the balance is protected, d) RF cards are difficult to apply to face-to-face transactions, but URL media can be applied to a variety of transactions, e) RF cards must be issued for each store, but URL media can be used for transactions at many stores in one place.

[0084] (Problems with RF card payments) a) RF cards are charged with small amounts of money, so they have not become a common means of payment; b) They can only be used at stores that have loaded RF cards; c) It is difficult to universally apply the payment system; d) The balance of a lost RF card is not protected; e) They cannot be applied to various transactions, so they have not become a common means of payment; and f) It is difficult to create added value.

[0085] <See Figures 2 and 3 for conventional URL-NFC-CC payment, which can be compared with Figures 7 and 8 for the present invention.>

[0086] (URL-NFC-CC payment system and overview)

[0087] The user, URL-NFC-CC, CC-POS, terminal, CCC server, CC account, collection account, CC-payment request, CC information, CCW-URL, CCW site, terminal information, CCW-URL-PWD, CCW-URL-PWD confirmation result, order details, order confirmation, CC-payment instruction, money, CC-payment instruction result, CC-payment result, etc. operate organically, and payment is made with money outside the URL-NFC-CC using the credit card communication network that communicates the URL-NFC-CC and CC information, and the internet site (CCW site) that corresponds to the CCW-URL.

[0088] (URL-NFC-CC payment details)

[0089] A URL-NFC-CC that can store CC information and CCW-URL, transfer CC information to CC-POS, and transfer CCW-URL to a terminal; a CC-POS that can receive a CC-payment request including order details from a user, receive CC information from URL-NFC-CC, transfer the CC-payment request to the CCP server of the CCC server, receive CC-payment results from the CCP server and pass them on to the user; a terminal that can receive a CCW-URL from URL-NFC-CC, connect to the CCW server of the CCC server in response to the CCW-URL, communicate CCW site and terminal information with the CCW server, receive CCW-URL-PWD from a user and transfer it to the CCW server, receive CCW-URL-PWD confirmation results and order details from the CCW server and transfer them to the user, receive order confirmation from a user and transfer it to the CCW server, and receive CC-payment results from the CCW server and pass them on to the user. A payment system including a CC-payment request from a CC-POS, a CC-payment command to a CC account, a result of the CC-payment command from the CC account, and a CC-payment result to the CC-POS; and a CCW server that can be connected to a terminal and can communicate with the terminal to communicate CCW site and terminal information, receive a CCW-URL-PWD from the terminal, transfer the result of the CCW-URL-PWD confirmation and order details to the terminal, receive an order confirmation from the terminal, and transfer the CC-payment result to the terminal; a CC account that can receive a CC-payment command from the CCP server, transfer money to a collection account, and transfer the result of the CC-payment command to the CCP server; and a collection account that can collect money; and a) a CC-POS receives a CC-payment request including order details from a user, receives CC information from the URL-NFC-CC, and transfers the CC-payment request to the CCP server of the CCC server; and the CCP server manages the CC-payment request; b) the terminal, receiving a CCW-URL from the URL-NFC-CC, connecting to a CCW server of the CCC server in response to the CCW-URL, communicating CCW site and terminal information with the CCW server, receiving a CCW-URL-PWD from the user and transmitting it to the CCW server;c) the CCW server transfers the result of the CCW-URL-PWD confirmation and the order details to the terminal; d) the terminal transfers the result of the CCW-URL-PWD confirmation and the order details to the user, and receives the order confirmation from the user and transfers it to the CCW server; e) the CCP server transfers the CC-payment command to the CC account; f) the CC account transfers the money to the collection account; the collection account collects the money; the CC account transfers the result of the CC-payment command to the CCP server; and g) the CCP server transfers the CC-payment result to the CC-POS; the CC-POS transfers the CC-payment result to the user; the CCW server transfers the CC-payment result to the terminal; and the terminal transfers the CC-payment result to the user; a payment method including the steps of making a payment with money outside the URL-NFC-CC using a credit card communication network that communicates CC information with the URL-NFC-CC and a CCW site corresponding to the CCW-URL of the URL-NFC-CC;

[0090] (URL-NFC-CC element description)

[0091] CC information is information that complies with credit card standards (ISO / IEC JTC1 / SC17, ISO 7816, ISO 14443, etc.).

[0092] CC information is the basis of payment for URL-NFC-CC, and is stored in URL-NFC-CC. It is the basis for generating CCW-URL, CCW-URL-PWD, and CCW server of CCC server, and is used in the payment request process and is transmitted to CCP server of CCC server via credit card communication network. It is not used in the user verification process and cannot support connection to CCW server of CCC server.

[0093] The CCW-URL is a URL that is subordinate to the CC information and helps to connect to the CCW server or CCW site.

[0094] CCW-URL is stored in URL-NFC-CC, CCW-URL-PWD is set, and is used when verifying the user of CC information. It is used to log in to the CCW server, and cannot use the credit card communication network, cannot support connecting to the CCP server, and cannot be used for transactions that do not verify the user, online transactions, transactions that use two media, or charges.

[0095] URL-NFC-CC is a medium that stores CC information and CCW-URL in compliance with credit card standards, and has CCW-URL-PWD set.

[0096] URL-NFC-CC cannot be used for online payments and two-media payments and top-ups by storing money externally and transmitting CC information to the CCP server via the credit card communication network and transmitting CCW-URL to the CCW server via the Internet.

[0097] URL-NFC-CC is a credit card and must comply with credit card standards, so the system construction costs and fees are high.

[0098] The user is the credit card subscriber and the owner of the URL-NFC-CC.

[0099] CC-POS is a point-of-sale system that supports credit card standards.

[0100] CC-POS can communicate CC information but cannot communicate CCW-URL. It connects to peripheral devices through the credit card communication network and does not support online payment, dual-media payment and charging, but supports general credit cards.

[0101] The CCC server is composed of a CCP server that complies with credit card standards and a CCW server that depends on the CCP server, and is the server that manages URL-NFC-CC payments.

[0102] The CCC server supports payment but not charging. The payment request process and the payment process use the CCP server, but the user verification process uses the CCW server. The CCP server and the CCW server communicate to make the payment. It supports credit card payment and executes the payment when the CC information matches the CCW-URL and CCW-URL-PWD. The system construction cost is high, so online payment and payment using two media are not supported.

[0103] CC accounts are connected to the credit card network, hold funds, and make payments according to CC information. They do not support online payments or payments or recharges using two different media.

[0104] The terminal, terminal information, and collection account in Figures 2 and 3 are different from the terminal, terminal information, and collection account in the present invention in terms of communication method and peripheral devices.

[0105] A CCW site is an Internet site that is subordinate to CC information and connected to a corresponding CCW-URL to verify the user.

[0106] The CCW site is provided by the CCW server and the CCW-URL-PWD is set, and the login is determined using the CCW-URL and CCW-URL-PWD. The CCW site cannot pass the CC-payment request, does not support CC information, and cannot connect to the CCP server.

[0107] CCW-URL-PWD is subordinate to the CC information and CCW-URL and is secret information set to log in to the CCW site.

[0108] The CCW-URL-PWD is set in conjunction with the URL-NFC-CC, CC information, CCW-URL and CCW site, is not stored on any media, is remembered by the user and is used by the CCW server to verify the user.

[0109] The result of the CCW-URL-PWD check is the result of checking the CCW-URL-PWD.

[0110] The CC-Payment Request, CC-Payment Instruction, CC-Payment Instruction Result, and CC-Payment Result utilize things related to credit cards, but the payment request, payment instruction, payment instruction result, and payment result of the invention do not utilize things related to credit cards.

[0111] The CC-payment request of a URL-NFC-CC payment includes CC information, but the payment request of the present invention does not include CC information.

[0112] (Characteristics of URL-NFC-CC Payment) a) Everything related to payment is subordinate to the credit card system, b) Money is stored outside the URL-NFC-CC, c) The payment request process transfers CC information to the CCP server through the credit card communication network, d) The user verification process involves the CCW server verifying the user using CCW-URL and CCW-URL-PWD, e) In the payment process, money outside the URL-NFC-CC (CC account) is transferred to another account, f) The order of the payment request process and the user verification process can be changed, g) The medium stores CC information and CCW-URL separately and transmits CC information and CCW-URL to the outside in a different way, so the production costs of the medium are high, h) The CC information requesting payment and the CCW-URL verifying the user have different paths and attributes, so the system construction costs and operation costs are high, i) It is not possible to charge using URL-NFC-CC, j) It cannot be applied to non-face-to-face transactions (KR No. 10-1751640 and KR No. 10-1941587 are patents for face-to-face transactions), k) It cannot be used to make payments using two URLs-NFC-CC, l) Because it uses the payment channel and system of a credit card, fees are charged based on credit card standards, m) Because an internet site is not used to request a payment, the exposure of the internet site is limited, and n) Because the exposure of the internet site is limited, the creation of added value using the internet site is also limited.

[0113] (About CC information) CC information is the basis for URL-NFC-CC, CCW-URL, CCW-URL-PWD, CCW site, CCC server (CCP server + CCW server), etc., in compliance with credit card standards, but this invention does not have CC information or a concept comparable to this.

[0114] (Comparison between CCW-URL and safe URL) a) CCW-URL is generated subordinate to CC information, but safe URL is created independently, b) CCW-URL is subordinate to CC information and supports payment, but safe URL supports payment independently, c) CCW-URL cannot request payment, but safe URL can request payment, d) CCW-URL connects to CCW server subordinate to CC information, but safe URL connects to independent safe server, e) CCW-URL cannot be used for transactions that do not verify users, online transactions, or transactions or charges that use two media, but safe URL can support such transactions and charges.

[0115] (Comparison between CCW site and safe site) a) CCW site is subordinate to CC information, but safe site is independent, b) CCW site has CCW-URL-PWD that is subordinate to CC information, but safe site has independent safe URL-PWD, c) CCW site uses CCW-URL and CCW-URL-PWD that are subordinate to CC information to decide login, but safe site uses independent safe URL and safe URL-PWD to decide login, d) CCW site does not support transactions that do not verify users, online transactions, or transactions or charges that use two media, but safe site can support such transactions and charges.

[0116] (Comparison between CCW-URL-PWD and safe URL-PWD) a) CCW-URL-PWD is set corresponding to CCW-URL subordinate to CC information, but safe URL-PWD is set corresponding to an independent safe URL, b) CCW-URL-PWD is used as secret information to log in to CCW site subordinate to CC information, but safe URL-PWD can be used as secret information to log in to an independent safe site, c) CCW-URL-PWD is settled when CC information and CCW-URL match, but safe URL-PWD can be settled when it matches safe URL, d) CCW-URL-PWD does not support transactions that do not verify the user, online transactions, or transactions or charges that use two media, but safe URL-PWD can support such transactions and charges.

[0117] (Comparison between URL-NFC-CC and URL medium) a) URL-NFC-CC complies with credit card standards, but URL medium does not comply with credit card standards, b) URL-NFC-CC stores CC information that complies with credit card standards, but URL medium does not store information that complies with credit card standards, c) URL-NFC-CC has different payment request information and user authentication information, but the URL medium is the same; d) URL-NFC-CC does not support online transactions or transactions or recharges using two media, but the URL medium can support such transactions and recharges.

[0118] (Comparison between CC-POS and URL-POS) a) CC-POS complies with credit card standards, but URL-POS does not comply with credit card standards. b) CC-POS does not support online transactions or transactions or charges that use two media, but URL-POS can support such payments and charges.

[0119] (Comparison between CCC Server and Vault Server) a) The CCC Server complies with credit card standards, but the Vault Server does not; b) The CCC Server is composed of a CCP Server and a CCW Server, and the Vault Server is composed of one web server; c) The CCC Server performs the payment request process and the money payment process on the CCP Server and the user verification process on the CCW Server, but the Vault Server performs the three processes on one server; d) The CCC Server does not support online transactions or transactions or charges that use two media, but the Vault Server can support such transactions and charges.

[0120] (Comparison of CCW Server, Vault Server, and CCC Server) CCW Server and Vault Server are both Internet-based web servers, but there are some differences between them:

[0121] a) The CCW server is subordinate to the CCP server, but the vault server is independent, b) The CCW server only performs the user verification process, which is part of the payment process, but the vault server performs the entire payment process, and c) The CCW server communicates with the CCP server for offline payments, but the vault server does not need to communicate with other servers for offline payments.

[0122] (Comparison between CC Account and URL Vault) a) CC Account is connected to the credit card network, but URL Vault is not connected to the credit card network, b) CC Account cannot be charged using a medium (URL-NFC-CC), but URL Vault can be charged using a medium (URL medium).

[0123] (Problems with URL-NFC-CC payments) a) A credit card system must be used. b) The production costs of the medium (URL-NFC-CC) are high. c) The costs of maintaining the system are high because the attributes of the channel requesting payment and the channel verifying the user are different. d) Fees are charged for using the credit card system. e) It is not possible to support online transaction payments. f) It is not possible to support payments using two media (URL-NFC-CC). g) It is not possible to charge using the medium (URL-NFC-CC). h) Fees are charged for using the credit card system even when paying with the user's own money. i) Creation of added value is limited.

[0124] <Conventional app and smartphone payments (WeChat Pay and ALIPAY), see Figure 4>

[0125] (Overview of app and smartphone payment systems)

[0126] The user, app POS, app & smartphone, app server, app & smartphone account, collection account, app, app payment request, app launch command, app PWD, result of app PWD confirmation, QR code generation command, QR code, app POS information, app payment command, money, result of app payment command, app payment result, etc. all work organically and make a payment with money outside the medium (app & smartphone) using the medium (app & smartphone) and app & mobile communication network.

[0127] (Details of app and smartphone payment operations)

[0128] An app / smartphone having an app installed, an app PWD set, and a USIM inserted, which is capable of receiving an app start command from a user, running the app, receiving the app PWD from the user, checking the app PWD, transmitting the result of the app PWD check to the user, receiving a QR code generation command from the user, generating a QR code, transferring the QR code to an app POS, receiving an app-payment result from an app server, and passing the app-payment result to the user; an app POS which receives an app-payment request from a user, receives the QR code from the app / smartphone, connects to the app server, transmits the app-payment request including app POS information and the QR code to the app server, receives the app-payment result from the app server and passes it on to the user; an app server which connects to an app POS, receives app POS information and an app-payment request from the app POS, transmits an app-payment command to an app / smartphone account corresponding to the QR code, receives the result of the app-payment command from the app / smartphone account, and passes the app-payment result to the app POS or the app / smartphone; a) an app&smartphone account capable of receiving an app-payment command from an app server, transferring money to a collection account, and passing a result of the app-payment command to the app server; and a collection account capable of collecting money; and a) a step in which the app&smartphone receives an app-payment request from a user; b) the app&smartphone receives an app start command from the user, executes the app, receives an app PWD from the user, confirms the app PWD, notifies the user of the result of the app PWD confirmation, receives a QR code generation command from the user, generates a QR code, and transmits the QR code to the app POS; c) the app POS connects to the app server and transmits an app-payment request including app POS information and the QR code to the app server; d) the app server transmits the app-payment command to the app&smartphone account corresponding to the QR code; e) the app&smartphone account transfers the money to the collection account; and the collection account collects the money;A step in which the app & smartphone account transfers the result of the app-payment command to the app server; and f) the app server transfers the result of the app-payment to the app POS or the app & smartphone, and the app POS or the app & smartphone notifies the user of the result of the app-payment; A payment is made with money outside the medium (app & smartphone) using the medium (app & smartphone) and the app & mobile communication network;

[0129] (Explanation of app & smartphone elements)

[0130] The app is application software that assists with payments and charging.

[0131] The app is provided by the app server and installed on a smartphone with a USIM card. It can set and check the app PWD, store electronic information that can generate a QR code, generate a QR code, and support QR codes.

[0132] The QR code is a user ID and is used as log information for the app server.

[0133] The QR code is generated on the app & smartphone after the app password is confirmed, and is generated every time a payment or charge is made. It is generated on the medium (app & smartphone) and transmitted to the app POS and app server, and is used at a different stage from the app password and is linked to the app & smartphone account.

[0134] A smartphone is a mobile communication device that has a USIM card installed and can install apps. The USIM card identifies the user and connects to the mobile communication network. Without a USIM card, apps cannot be used.

[0135] USIM cards are provided to mobile network subscribers and are used to verify users on WeChat Pay and ALIPAY, helping them connect to the mobile network; without a USIM card, payments and recharges cannot be made.

[0136] The present invention does not require a USIM and has no concept comparable to a USIM.

[0137] Smartphone information is information about the smartphone on which the app is installed and includes USIM information, but the terminal information of the present invention does not include USIM information.

[0138] App & Smartphone is a medium that combines an app with a smartphone equipped with a USIM card.

[0139] The app & smartphone saves the app password, stores the digital information of the QR code, determines login only with the app password, verifies the user with the app password, generates a QR code after verifying the app password, generates a QR code every time a payment or charge is made, and transmits the QR code to the app POS to execute the payment request process and user verification process.

[0140] The electronic information in a QR code is stored in memory and cannot be seen with the naked eye.

[0141] A user is someone who owns a smartphone with a USIM card installed and owns the medium (app & smartphone).

[0142] App POS is a store sales system that has an app installed.

[0143] The app POS receives an app-payment request from the user, receives a QR code from the app and smartphone, connects to the app and mobile communication network, and transmits the app-payment request including the QR code to the app server.

[0144] App POS information is information about the app POS.

[0145] The application server is a server that manages applications that support payments and charging.

[0146] The application server provides the application and connects to the medium (application & smartphone) on which the application is installed, recognizes the QR code as the user ID, executes the payment process according to the QR code without storing the application password and without executing the user verification process, and communicates with the medium (application & smartphone) and application POS via the application & mobile communication network.

[0147] The app & smartphone account is an account that is connected to the app & mobile communication network, holds money, and supports payments and recharges by responding to QR codes.

[0148] An application launch command is a command to execute an application, and the present invention has no concept comparable to this.

[0149] The application password is secret information that allows you to log in to the medium (application and smartphone).

[0150] The app PWD is stored on the medium (app & smartphone) to generate a QR code (=user ID) on the medium (app & smartphone), is not transferred to the app server, and is used for a purpose and process different from the QR code.

[0151] The result of app PWD verification is the result of the medium (app & smartphone) verifying the app PWD.

[0152] The QR code generation command is a command to generate a QR code, and the present invention has no concept comparable to this.

[0153] The application-payment request, application-payment command, application-payment command result, and application-payment result are different from the invention's payment request, payment command, and the result of the payment command, because the application is used.

[0154] The app payment request for app & smartphone payment includes a QR code, but the payment request of the present invention does not include a QR code.

[0155] (Comparison between app and internet site)

[0156] 1) An app is installed on a device such as a smartphone or an app POS, while an internet site is hosted on a web server.

[0157] 2) An app works in conjunction with the device on which it is installed, while an internet site works in conjunction with a web server.

[0158] 3) While an app runs independently on a device, it connects to an app server when necessary, but on an internet site, all operations are linked to a web server.

[0159] 4) Because apps are installed on devices, it is difficult to update service changes in real time. However, because internet sites are provided by web servers, it is easy to update service changes in real time.

[0160] 5) Apps have a high possibility of being hacked because the medium (app & smartphone) on which the app is installed is managed by the individual, but internet sites are managed by a specialized agency, so the possibility of being hacked is low.

[0161] 6) Information stored and managed by an app is prone to leaking when the medium (app and smartphone) on which the app is installed is replaced, but information stored and managed through an internet site is not leaked when the medium (URL medium) is replaced.

[0162] 7) The app can only be operated on the device on which it is installed, but the internet site can be operated on any device with an internet connection.

[0163] 8) Apps & smartphones (medium) use apps & mobile communication networks, but URLs (medium) use the internet.

[0164] (Characteristics of App & Smartphone (Medium) Payment) a) Money is stored outside the app & smartphone, b) The payment request process transfers the QR code to the app POS and app server via the app & mobile communication network, c) The user authentication process involves the app & smartphone verifying the app PWD, d) The payment process transfers money outside the app & smartphone to another account, e) The payment request process is performed after the user authentication process (the order cannot be changed), f) The QR code, which is the user ID, must be created every time a payment or charge is made, g) The app PWD is used to generate the QR code, and the QR code is used to provide money (the app PWD, which is confidential information, and the QR code, which is the user ID, are not used at the same time for the same purpose), h) The app and a smartphone with a USIM are required, i) The user's own smartphone must be used for payment, j) The app and smartphone must store and manage the app PWD, k) The app must be run to create a QR code, l) The app is highly susceptible to hacking, m) If the smartphone is lost, The electronic information of the QR code and the application PWD are easily leaked, n) changes to services and contents cannot be reflected in real time, and o) it is difficult to create added value by using the Internet site.

[0165] (Comparison between "App PWD and QR Code in Figure 4" and "Safe URL-PWD and Safe URL of the Invention") Figure 4 shows that after generating a QR code for a user ID using the app PWD, only the QR code is used to log in to the app server. However, the present invention does not generate a user ID, but uses the safe URL-PWD and safe URL to log in to the safe server.

[0166] (Comparison between QR code and safe URL) a) QR code is a user ID of the app server without route attributes, but safe URL is a user ID of the safe server using the Internet route, b) QR code logs in to the app server alone, but safe URL logs in to the safe site with safe URL-PWD, c) QR code is generated every time you pay or charge, but safe URL does not need to be created, d) QR code is used after password (app PWD) is confirmed, but safe URL can be used without password (safe URL-PWD) confirmation, e) QR code cannot connect to Internet sites, but safe URL can connect to Internet sites, f) QR code requires a smartphone with USIM, but safe URL does not require USIM and smartphone.

[0167] (Comparison between App PWD and Safe URL-PWD) a) App PWD is secret information for logging in to the medium (app & smartphone) alone, while Safe URL-PWD is secret information for logging in to the internet site (safe site) together with the safe URL, etc. b) App PWD is used as information for generating the QR code of the user ID, while Safe URL-PWD is not used as information for generating the user ID c) App PWD is stored in the medium (app & smartphone), while Safe URL-PWD is not stored in the medium (URL medium) d) App PWD is confirmed by the medium (app & smartphone), while Safe URL-PWD is confirmed by the server.

[0168] (Comparison between App & Smartphone and URL Medium) a) App & Smartphone is configured by installing an app on a smartphone with a USIM card, while URL medium does not require an app, USIM card, or smartphone; b) App & Smartphone stores app PWD, but URL medium does not store safe URL-PWD; c) App & Smartphone checks app PWD, but URL medium does not check safe URL-PWD; d) App & Smartphone generates a QR code for user ID, but URL medium does not generate user ID; e) App & Smartphone needs a function to communicate with user, but URL medium does not have a function to communicate with user.

[0169] (Comparison of smartphone and terminal of the invention in App & Smartphone) a) Smartphone needs USIM, but terminal does not need USIM, b) Smartphone installs app, but terminal does not install app, c) Smartphone includes media function, but terminal does not include media function, d) Smartphone saves app PWD and verifies user in app PWD, but terminal does not save safe URL-PWD and cannot verify user.

[0170] (Comparison between App POS and URL-POS) a) App POS requires an app, but URL-POS does not require an app; b) App POS receives QR codes, but URL-POS does not receive QR codes; c) App POS passes QR codes to the app server, but URL-POS cannot pass QR codes.

[0171] (Comparison between App Server and Safe Server) a) App Server manages apps that support payment and charging, while Safe Server manages internet sites that support payment and charging, b) App Server does not store App PWD, while Safe Server stores Safe URL-PWD, c) App Server does not check App PWD, while Safe Server checks Safe URL-PWD, d) App Server only executes payment process, while Safe Server executes payment request process, user verification process and payment process, e) App Server only checks user by QR code, while Safe Server checks user by safe URL and safe URL-PWD.

[0172] (Problems with payments using the medium (app & smartphone) in Figure 4) a) The cost of constructing the medium (app & smartphone) is high. b) An app is used, which is always at risk of being hacked. c) The smartphone must belong to the user. d) A QR code must be created every time a payment or charge is made. e) The app password must be saved on the smartphone. f) A process is required to run the app. g) The order of the user verification process and the payment request process cannot be changed, so various transactions cannot be supported. h) Internet sites that can create added value cannot be used. i) There is a high possibility that the app password and other information will be leaked when the smartphone is lost or replaced. j) Costs are incurred for using the mobile communication network.

[0173] The claims and charges of the present invention will now be described with reference to the following five drawings.

[0174] <Payments in person without user authentication, see Figures 5 and 6>

[0175] A URL medium that can store safe URLs and pass safe URLs to URL-POS;

[0176] URL-POS that can receive payment requests, etc. from users, receive safe URLs from URL media, connect to a safe server according to the safe URL, transmit URL-POS information and payment requests, etc. to the safe server, receive payment results, etc. from the safe server, and pass them on to users;

[0177] A safe server that can connect to URL-POS corresponding to a safe URL, receive URL-POS information and payment requests from URL-POS, transmit payment commands to the URL safe, receive payment command results from the URL safe, and pass payment results to the URL-POS;

[0178] A URL vault that can receive payment instructions, etc. from the vault server, transmit money to a collection account, and pass the results of payment instructions, etc. to the vault server;

[0179] A payment system, including a collection account from which money can be collected; and

[0180] a) A step in which the URL-POS receives a payment request, etc. from a user, receives a safe URL from a URL medium, connects to a safe server according to the safe URL, and transmits URL-POS information and the payment request, etc. to the safe server;

[0181] b) The vault server connects to the URL-POS in response to the vault URL and transmits a payment command, etc. to the URL vault;

[0182] c) The URL safe transfers the money to the collection account, the collection account collects the money, and the URL safe transfers the result of the payment command to the safe server;

[0183] d) a step in which the safe server transfers the payment result, etc. to the URL-POS; e) a step in which the URL-POS transfers the payment result, etc. to the user;

[0184] Using a URL medium and an Internet site (safe site), payment is made with money outside the URL medium (URL safe).

[0185] FIG. 6 of FIG. 5 is useful for small value payments.

[0186] <Face-to-face payment that confirms the user after receiving the payment request, see Figure 7 and Figure 8>

[0187] A URL medium that can store safe URLs and pass them to URL-POS or terminals;

[0188] URL-POS that can receive payment requests, etc. from users, receive safe URLs from URL media, connect to a safe server according to the safe URL, transmit URL-POS information and payment requests, etc. to the safe server, receive payment results, etc. from the safe server, and pass them on to users;

[0189] A terminal that can receive a vault URL from a URL medium, connect to a vault server or vault site in response to the vault URL, transmit terminal information, etc. to the vault server, receive a vault URL-PWD, etc. from a user and transmit them to the vault server, receive the results of the vault URL-PWD confirmation and order details, etc. from the vault server and transmit them to the user, receive order confirmation, etc. from the user and transmit them to the vault server, and receive payment results, etc. from the vault server and pass them on to the user.

[0190] A vault server that can connect to URL-POS according to a vault URL, receive URL-POS information and payment requests from URL-POS, connect to a terminal according to a vault URL, communicate vault site and terminal information with the terminal, receive vault URL-PWD from the terminal, transfer the result of vault URL-PWD confirmation and order details to the terminal, receive order confirmation from the terminal, transfer payment commands to URL vault, receive the result of payment command from URL vault, and transfer payment results to URL-POS or the terminal;

[0191] A URL vault that can receive payment instructions etc. from the vault server, transfer money to a collection account, and pass the results of payment instructions etc. to the vault server;

[0192] A payment system, including a collection account from which money can be collected; and

[0193] a) A step in which the URL-POS receives a payment request, etc. from a user, receives a safe URL from a URL medium, connects to a safe server according to the safe URL, delivers URL-POS information and a payment request, etc. to the safe server, and the safe server manages the URL-POS information, the payment request, etc.;

[0194] b) A step in which the terminal receives a safe URL from a URL medium, connects to a safe server or a safe site in response to the safe URL, transmits terminal information, etc. to the safe server, receives a safe URL-PWD, etc. from a user, and transmits them to the safe server;

[0195] c) The safe server transmits the result of the safe URL-PWD verification and the order details to the terminal; d) The terminal transmits the result of the safe URL-PWD verification and the order details to the user, or receives an order confirmation from the user and transmits it to the safe server;

[0196] e) the vault server transfers the payment command, etc. to the URL vault;

[0197] f) a step in which the URL vault transfers money to a collection account, the collection account collects money, and the URL vault transfers the result of the payment command to the vault server; g) a step in which the vault server transfers the payment result to the URL-POS or the terminal, and the URL-POS or the terminal transfers the payment result to the user;

[0198] Using a URL medium and an Internet site (safe site), payment is made with money outside the URL medium (URL safe).

[0199] <Face-to-face payment, receiving a payment request after verifying the user, see Figure 9 and Figure 10>

[0200] A URL medium that can store safe URLs and pass them to terminals and URL-POS;

[0201] A terminal that can receive a vault URL from a URL medium, connect to a vault server or a vault site in response to the vault URL, transmit terminal information, etc. to the vault server, receive a vault URL-PWD, etc. from a user and transfer it to the vault server, receive the results of the vault URL-PWD confirmation, etc. from the vault server and transmit them to the user, receive a payment schedule, etc. from the user and transmit them to the vault server, and receive payment results, etc. from the vault server and pass them on to the user.

[0202] URL-POS that can receive payment requests, etc. from users, receive safe URLs from URL media, connect to a safe server according to the safe URL, transfer URL-POS information and payment requests, etc. to the safe server, receive payment results, etc. from the safe server, and pass them on to users;

[0203] A safe server that can connect to a terminal in response to a safe URL, communicate safe site and terminal information, etc. with the terminal, receive safe URL-PWD, etc. from the terminal, transfer safe URL-PWD confirmation results, etc. to the terminal, receive payment schedules, etc. from the terminal, connect to a URL-POS in response to a safe URL, receive URL-POS information and payment requests, etc. from the URL-POS, transfer payment commands, etc. to the URL safe, receive payment command results, etc. from the URL safe, and pass payment results, etc. to the terminal or the URL-POS;

[0204] A URL vault that can receive payment instructions etc. from the vault server, transfer money to a collection account, and pass the results of payment instructions etc. to the vault server;

[0205] A payment system, including a collection account from which money can be collected; and

[0206] a) A step in which the terminal receives a safe URL from a URL medium, connects to a safe server or a safe site in response to the safe URL, transmits terminal information, etc. to the safe server, receives safe URL-PWD, etc. from the user and transmits them to the safe server; b) A step in which the safe server transmits the result of safe URL-PWD confirmation, etc. to the terminal; c) A step in which the terminal transmits the result of safe URL-PWD confirmation, etc. to the user, receives a payment schedule, etc. from the user and transmits them to the safe server, and the safe server manages the payment schedule, etc.;

[0207] d) The URL-POS receives a payment request, etc. from a user, receives a safe URL from a URL medium, connects to a safe server according to the safe URL, and transmits URL-POS information and the payment request, etc. to the safe server;

[0208] e) the vault server transfers the payment command, etc. to the URL vault;

[0209] f) The URL safe transfers the money to the collection account; the collection account collects the money; and the URL safe transfers the results of the payment command to the safe server;

[0210] g) a step in which the safe server transfers the payment result, etc. to the terminal or URL-POS; h) a step in which the URL-POS or the terminal transfers the payment result, etc. to the user;

[0211] Using a URL medium and an Internet site (safe site), payment is made with money outside the URL medium (URL safe).

[0212] 7, 8, 9 and 10 are useful for transactions with large settlement amounts.

[0213] <Non-face-to-face payment that confirms the user after receiving the payment request, see Figure 11 and Figure 12>

[0214] You can save the safe URL and transfer the safe URL to your device. URL Media;

[0215] A terminal that can connect to a sales server or sales site in response to a user's sales server connection command, receive a payment request including URL medium information and order details from a user and transmit it to the sales server, receive a safe URL from the URL medium, connect to a safe server or vault site in response to a safe URL, transmit terminal information, etc. to the safe server, receive a safe URL-PWD, etc. from a user and transmit it to the safe server, receive the result of safe URL-PWD confirmation and order details from the safe server and transmit them to the user, receive an order confirmation, etc. from a user and transmit it to the safe server, and receive a payment result, etc. from the safe server or sales server and pass it on to the user;

[0216] A sales server that can connect to a terminal, communicate sales site and terminal information with the terminal, receive payment requests from the terminal, connect to a safe server or a safe site according to URL media information, transmit sales server information and payment requests to the safe server, receive payment results from the safe server and pass them to the terminal;

[0217] A safe server that can connect to a sales server in response to URL medium information, receive sales server information and payment requests from the sales server, connect to a terminal in response to a safe URL, communicate safe site and terminal information with the terminal, receive safe URL-PWD, etc. from the terminal, transfer safe URL-PWD confirmation results and order details to the terminal, receive order confirmation, etc. from the terminal, transfer payment commands, etc. to the URL safe, receive payment command results, etc. from the URL safe, and transfer payment results, etc. to the sales server or the terminal;

[0218] A URL vault that can receive payment instructions etc. from the vault server, transfer money to a collection account, and pass the results of payment instructions etc. to the vault server;

[0219] A payment system, including a collection account from which money can be collected; and

[0220] a) The terminal connects to the sales server or the sales site in response to the user's command to connect to the sales server, receives a payment request including URL media information and order details from the user, and transmits the request to the sales server;

[0221] b) the step of the sales server connecting to the terminal, connecting to the vault server or the vault site according to the URL medium information, transmitting the sales server information and the payment request, etc. to the vault server, and the vault server managing the payment request, etc.;

[0222] c) the terminal receives a safe URL from a URL medium, connects to a safe server or a safe site in response to the safe URL, transmits terminal information, etc. to the safe server, receives a safe URL-PWD, etc. from a user, and transmits them to the safe server;

[0223] d) the safe server transfers the result of the safe URL-PWD confirmation and the order details to the terminal; e) the terminal transfers the result of the safe URL-PWD confirmation and the order details to the user, or receives an order confirmation from the user and transfers it to the safe server; f) the safe server transfers a payment command to the URL safe;

[0224] g) The URL Vault transfers the money to the collection account; the collection account collects the money; and the URL Vault transfers the results of the payment command, etc. to the vault server;

[0225] h) a step in which the safe server transfers the payment result, etc. to the sales server or the terminal; i) a step in which the sales server transfers the payment result, etc. to the terminal; and the terminal transfers the payment result, etc. to the user;

[0226] Using a URL medium and an Internet site (safe site), payment is made with money outside the URL medium (URL safe).

[0227] The payment request can include URL media information, which the URL-POS can use to connect to the vault server or the vault site.

[0228] <Non-face-to-face payment, receiving a payment request after verifying the user, see Figure 13 and Figure 14>

[0229] You can save the safe URL and transfer the safe URL to your device. URL Media;

[0230] A terminal that can receive a safe URL from a URL medium, connect to a safe server or a safe site in response to the safe URL, pass terminal information, etc. to the safe server, receive a safe URL-PWD, etc. from a user and transfer it to the safe server, receive the results of the safe URL-PWD confirmation, etc. from the safe server and pass them on to the user, receive a payment schedule, etc. from a user and send it to the safe server, connect to a sales server or sales site in response to a user's sales server connection command, receive a payment request, etc. including URL medium information, etc. from the user and send it to the sales server, receive an order number, etc. from the sales server and pass it on to the user, and receive payment results, etc. from the safe server or sales server and pass them on to the user.

[0231] A sales server that can connect to a terminal, communicate with a sales site and the terminal, receive payment requests from the terminal, transfer order numbers to the terminal, connect to a safe server according to URL media information, and pass sales server information and payment requests to the safe server or receive payment results from the safe server and transfer them to the terminal;

[0232] A safe server that can connect to a terminal in response to a safe URL, communicate safe site and terminal information, etc. with the terminal, receive safe URL-PWD, etc. from the terminal, transfer safe URL-PWD confirmation results, etc. to the terminal, receive payment schedules, etc. from the terminal, connect to a sales server, receive sales server information and payment requests, etc. from the sales server, transfer payment commands, etc. to the URL safe, receive payment command results, etc. from the URL safe, and pass payment results, etc. to the terminal, sales server, etc.;

[0233] A URL vault that can receive payment instructions etc. from the vault server, transfer money to a collection account, and pass the results of payment instructions etc. to the vault server;

[0234] A payment system, including a collection account from which money can be collected; and

[0235] a) A step in which the terminal receives a safe URL from a URL medium, connects to a safe server or a safe site in response to the safe URL, passes terminal information, etc. to the safe server, or receives a safe URL-PWD, etc. from the user and transmits it to the safe server; b) The safe server transmits a result of the safe URL-PWD confirmation to the terminal; c) The terminal passes a result of the safe URL-PWD confirmation to the user, or receives a payment schedule, etc. from the user and transmits it to the safe server, the safe server manages the payment schedule, and the terminal connects to a sales server or a sales site in response to the user's command to connect to the sales server, receives a payment request, etc. including URL medium information, from the user and transmits it to the sales server;

[0236] d) The sales server transfers the order number, etc. to the terminal, connects to the safe server according to the URL media information, and transfers the sales server information and a payment request, etc. to the safe server; the terminal can pass the order number, etc. to the user;

[0237] e) the vault server transfers the payment command, etc. to the URL vault;

[0238] f) The URL safe transfers the money to the collection account; the collection account collects the money; and the URL safe transfers the results of the payment command to the safe server;

[0239] g) A payment method including a step in which the safe server transfers the payment result, etc. to the terminal or the sales server, the sales server transfers the payment result, etc. to the terminal, and the terminal notifies the user of the payment result, etc.

[0240] Using the URL medium and an internet site (safe site), payment is made with money outside the URL medium (URL safe). The payment request can include URL medium information.

[0241] The sales server can use the URL media information to connect to the vault server or vault site.

[0242] <Face-to-face payment using two URL mediums without user verification, see Figure 15 and Figure 16>

[0243] You can save the safe URL-B, etc., or transfer the safe URL-B to the terminal URL medium B;

[0244] A URL medium S that can store the safe URL-S and pass the safe URL-S to a terminal;

[0245] A terminal capable of receiving a safe URL-B from URL medium B, connecting to a safe server or safe site B in response to the safe URL-B, transmitting terminal information, etc. to the safe server, receiving a payment request, etc. from user B and transmitting it to the safe server, receiving a safe URL-S from URL medium S, connecting to the safe server in response to the safe URL-S, receiving payment results, etc. from the safe server and passing them on to user B;

[0246] A vault server that can connect to a terminal in response to vault URL-B, communicate vault site B and terminal information with the terminal, receive payment requests from the terminal, connect to a terminal in response to vault URL-S, transfer payment commands to URL vault B, receive the results of the payment commands from URL vault B, and pass the payment results to the terminal;

[0247] URL safe B, which can receive payment instructions etc. from the safe server, transfer money to collection account S, and pass the results of the payment instructions etc. to the safe server;

[0248] a payment system including a collection account S from which money can be collected; and

[0249] a) The terminal receives safe URL-B from URL medium B, connects to the safe server or safe site B in response to safe URL-B, transmits terminal information, etc. to the safe server, receives a payment request, etc. from user B and transfers it to the safe server, and the safe server manages the payment request, etc.; The terminal receives safe URL-S from URL medium S, and connects to the safe server in response to safe URL-S;

[0250] b) The vault server transfers the payment command etc. to URL vault B;

[0251] c) URL Vault B transfers the money to Collection Account S; Collection Account S collects the money; URL Vault B transfers the results of the payment command, etc. to the vault server;

[0252] d) a step in which the safe server transfers the payment result, etc. to the terminal; e) a step in which the terminal transfers the payment result, etc. to User B;

[0253] Using a URL medium and an Internet site (safe site), payment is made with money outside the URL medium (URL safe).

[0254] <Checking User B and making a face-to-face payment using two URL media, see Figure 17 and Figure 18>

[0255] You can save the safe URL-B, etc., or transfer the safe URL-B to the terminal URL medium B;

[0256] You can save the safe URL-S and transfer the safe URL-S to the terminal URL medium S;

[0257] A terminal that can receive safe URL-B from URL medium B, connect to a safe server or safe site B in response to safe URL-B, pass terminal information, etc. to the safe server, receive safe URL-B-PWD, etc. from user B and forward it to the safe server, receive the results of safe URL-B-PWD confirmation, etc. from the safe server and forward them to user B, receive a payment request, etc. from user B and pass them to the safe server, receive safe URL-S from URL medium S, connect to a safe server or safe site S in response to safe URL-S, and receive payment results, etc. from the safe server and pass them to user B.

[0258] A safe server that can connect to a terminal in response to safe URL-B, communicate terminal information, etc. with safe site B and the terminal, receive safe URL-B-PWD, etc. from the terminal, transfer the result of safe URL-B-PWD confirmation, etc. to the terminal, receive a payment request, etc. from the terminal, connect to a terminal in response to safe URL-S, transfer a payment command, etc. to URL safe B, receive the result of the payment command, etc. from URL safe B, and transfer the payment result, etc. to the terminal;

[0259] URL safe B, which can receive payment instructions etc. from the safe server, transfer money to collection account S, and pass the results of the payment instructions etc. to the safe server;

[0260] a payment system including a collection account S from which money can be collected; and

[0261] a) A step in which the terminal receives safe URL-B from URL medium B, connects to a safe server or safe site B in response to safe URL-B, and passes terminal information, etc. to the safe server, or receives safe URL-B-PWD, etc. from user B and transfers them to the safe server;

[0262] b) the safe server transfers the result of the safe URL-B-PWD confirmation to the terminal; c) the terminal transfers the result of the safe URL-B-PWD confirmation to user B, receives a payment request from user B and transfers it to the safe server, the safe server manages the payment request, the terminal receives safe URL-S from URL medium S and connects to the safe server or safe site S in response to safe URL-S; d) the safe server transfers the payment command to URL safe B;

[0263] e) URL Vault B transfers the money to Collection Account S; Collection Account S collects the money; URL Vault B transfers the results of the payment command, etc. to the vault server;

[0264] f) a step in which the safe server transfers the payment result, etc. to the terminal; g) a step in which the terminal transfers the payment result, etc. to user B;

[0265] Using a URL medium and an Internet site (safe site), payment is made with money outside the URL medium (URL safe).

[0266] Figures 15, 16, 17 and 18 are useful in the absence of URL-POS.

[0267] <Payment of face-to-face transactions with provisional settlement, see Figures 19 and 20>

[0268] A URL medium that can store safe URLs and pass safe URLs to URL-POS;

[0269] A payment system including a URL-POS that can receive a safe URL from a URL medium, make a payment according to the safe URL, store the safe URL and the payment result, and pass the payment result to a user; and

[0270] a) A step in which a URL medium transfers a safe URL to a URL-POS;

[0271] b) A payment method including a step in which the URL-POS makes a payment according to the safe URL, stores the safe URL and the payment result, and transmits the payment result to the user;

[0272] Using the URL medium, payment is made with money outside the URL medium (URL vault).

[0273] Figures 19 and 20 are useful in cases such as transportation systems (where network connections are difficult and payments are made quickly) or when making repeated small payments.

[0274] <Online charge that received a charge request after confirming the user, see Figure 21 and Figure 22>

[0275] You can save the safe URL and transfer the safe URL to your device. URL Media;

[0276] A terminal that can receive a safe URL from a URL medium, connect to a safe server or a safe site in response to the safe URL, transmit terminal information, etc. to the safe server, receive a safe URL-PWD, etc. from a user and transfer it to the safe server, receive a safe URL-PWD confirmation result, etc. from the safe server and transmit it to the user, receive a charge request, etc. from a user and transmit it to the safe server, and receive a charge result, etc. from the safe server and pass it on to the user;

[0277] A safe server that can connect to a terminal in response to a safe URL, communicate safe site and terminal information, etc. with the terminal, receive safe URL-PWD, etc. from the terminal, transfer the result of safe URL-PWD confirmation, etc. to the terminal, receive a charge request, etc. from the terminal, transfer a charge command, etc. to a money supply point, receive the result of the charge command, etc. from the money supply point, and pass the charge result, etc. to the terminal;

[0278] A money supply station that can receive charge commands etc. from the vault server, transfer money to the URL vault, and pass the results of charge commands etc. to the vault server;

[0279] A recharge system that includes a URL safe that can be recharged with money;

[0280] a) A step in which the terminal receives a safe URL from a URL medium, connects to a safe server or a safe site in response to the safe URL, transmits terminal information, etc. to the safe server, and receives a safe URL-PWD, etc. from a user and transmits them to the safe server;

[0281] b) the safe server transmits the result of the safe URL-PWD verification to the terminal; c) the terminal transmits the result of the safe URL-PWD verification to the user, or receives a charge request from the user and transmits the result to the safe server; d) the safe server transmits a charge command to the cash supply point;

[0282] e) the cash supply office transmits money to the URL safe; the URL safe charges money; and the cash supply office transmits the result of the charge command to the safe server;

[0283] f) a step in which the safe server transmits the charge result, etc. to the terminal; g) a step in which the terminal transmits the charge result, etc. to the user;

[0284] Using a URL medium and an Internet site (vault site), money is charged to an outside URL medium (URL vault).

[0285] <Face-to-face charging where money is paid to three parties and charging is done on your behalf, see Figures 23 and 24>

[0286] A URL medium that can store safe URLs and pass safe URLs to URL-POS;

[0287] URL-POS that can receive money and a charge request from a user, receive a safe URL from a URL medium, connect to a safe server according to the safe URL, transmit URL-POS information and a charge request to the safe server, receive charge results from the safe server, and pass them on to the user;

[0288] A safe server that can connect to a URL-POS in response to a safe URL, receive URL-POS information and a charge request from the URL-POS, transmit a charge command to a cash supply point, receive a charge command result from the cash supply point, and pass a charge result to the URL-POS;

[0289] A money supply station that can receive charge commands etc. from the vault server, transfer money to the URL vault, and pass the results of charge commands etc. to the vault server;

[0290] A recharge system that includes a URL safe that can be recharged with money;

[0291] a) A step in which the URL-POS receives money and a charge request from a user, receives a safe URL from a URL medium, connects to a safe server according to the safe URL, and transmits URL-POS information and a charge request to the safe server;

[0292] b) The safe server connects to the URL-POS and transmits a charge command, etc. to the cash supply point;

[0293] c) the cash supply office transmits money to the URL safe; the URL safe charges money; and the cash supply office transmits the result of the charge command to the safe server;

[0294] d) a step in which the safe server transmits a charge result, etc. to the URL-POS; and e) a step in which the URL-POS transmits a charge result, etc. to the user.

[0295] Using a URL medium and an Internet site (safe site), money is charged to an outside URL medium (URL safe).

[0296] 23 and 24 can support charging by providing cash or the like at a store or the like.

[0297] <Offline recharge, which recharges coupons generated through transactions, etc. See Figures 25 and 26>

[0298] A URL medium that can store safe URLs and pass safe URLs to URL-POS;

[0299] URL-POS that can receive a coupon charge request, etc. from a user, receive a safe URL from a URL medium, connect to a safe server according to the safe URL, and transmit URL-POS information and a coupon charge request, etc. to the safe server or receive a coupon charge result, etc. from the safe server and pass it to the user;

[0300] A safe server that can connect to URL-POS in response to a safe URL, receive URL-POS information and coupon charge requests from URL-POS, transfer money to the URL safe, and pass coupon charge results to URL-POS;

[0301] A charging system that includes a URL safe where you can collect money;

[0302] a) A step in which the URL-POS receives a coupon charge request, etc. from a user, receives a safe URL from a URL medium, connects to a safe server according to the safe URL, and transmits URL-POS information and the coupon charge request, etc. to the safe server;

[0303] b) the vault server connects to the URL-POS and transfers the coupon to the URL vault;

[0304] c) The URL vault receives the coupon; the vault server transfers the coupon charge result to the URL-POS;

[0305] d) URL-POS transmits the coupon charge result to the user;

[0306] Using a URL medium and an Internet site (safe site), money (coupons) is charged to the outside of the URL medium (URL safe).

[0307] 25 and 26 are useful for charging coupons generated in offline transactions, and the coupon charge request can include coupons generated in the transaction.

[0308] <Online recharge, which recharges coupons generated from transactions, etc. See Figures 27 and 28>

[0309] URL media that can store URL media information and pass URL media information to users;

[0310] A terminal that can receive coupon charge requests, including URL media information, from users and send them to a sales server, or receive coupon charge results from a sales server and pass them on to users.

[0311] A sales server that receives a coupon charge request, etc. from the terminal, connects to a vault server or a vault site according to URL medium information, transmits sales server information and a coupon charge request, etc. to the vault server, or receives a coupon charge result, etc. from the vault server and passes it to the terminal;

[0312] A safe server that can connect to a sales server according to URL media information, receive sales server information and coupon charge requests from the sales server, transfer money to the URL safe, and pass coupon charge results to the sales server;

[0313] A charging system that includes a URL safe where you can collect money;

[0314] a) The terminal receives a coupon charge request including URL media information from the user and transmits the request to the sales server;

[0315] b) the sales server connects to the safe server or the safe site according to the URL medium information, and transmits the sales server information and a coupon charge request to the safe server;

[0316] c) The vault server connects with the merchant server and transfers the money to the URL vault;

[0317] d) URL Vault collects the money;

[0318] e) the safe server transmits the coupon charge result, etc. to the sales server;

[0319] f) a step in which the sales server transmits the coupon charge result to the terminal; g) a step in which the terminal notifies the user of the coupon charge result;

[0320] Using a URL medium and an Internet site (safe site), money (coupons) is charged to the outside of the URL medium (URL safe).

[0321] The coupon charge request may include URL media information and money (such as a coupon).

[0322] Figures 27 and 28 are useful for charging coupons generated through online transactions.

[0323] URL medium payment process) The payment request process transmits the safe URL and related information to the safe server via the Internet, the user authentication process is performed by the safe server authenticating the user with the safe URL and safe URL-PWD, and the monetary payment process is performed by paying with money outside the URL medium (URL safe).

[0324] <Terminology of the invention>

[0325] (URL medium) A URL medium is a medium that stores a safe URL. URL medium B and URL medium S are URL media that store different safe URLs.

[0326] The URL medium can store more URL medium information and representative electronic information, and the safe URL-PWD can be set. The URL medium can provide the safe URL, URL medium information, representative electronic information, etc. to the outside without storing money internally. The URL medium can support connecting to the safe server or safe site, and can support making payments with money in the URL safe or charging money to the URL safe. The URL medium does not store the safe URL-PWD internally, does not have the function to check the safe URL-PWD, and can be used in conjunction with a collection account when collecting money. The URL medium does not store CC information that complies with credit card standards or QR codes that require an app.

[0327] (URL media information, representative electronic information) URL media information is non-electronic information (e.g., serial number, etc.) corresponding to a URL medium or a safe URL, and can be displayed on the surface of a URL medium. The URL media information can assist in connecting to a safe server or a safe site. Representative electronic information is electronic information (e.g., serial number, etc.) corresponding to a URL medium or a safe URL. The representative electronic information can assist in connecting to a safe server or a safe site.

[0328] (User) User owns the URL medium, and User B owns URL medium B.

[0329] (URL Safe) A URL safe can hold money corresponding to URL media. Examples of URL safes include bank accounts and coupon repositories.

[0330] The URL Vault can be charged with money or transferred to an external party, such as money or balance information.

[0331] (Safe site) A safe site is an Internet site that can make payments with money in the URL safe or assist in loading money into the URL safe. Safe site B and safe site S are included in the safe sites.

[0332] The safe site can support the connection of the URL medium's safe URL, URL medium information, and representative electronic information. The safe site can support safe URL-PWD, can support logging in with safe URL and safe URL-PWD, and can support various transactions, recharges, additional services, etc., and can include advertisements, etc.

[0333] (Vault Server) The vault server is a web server that supports making payments with money in the URL vault or charging money to the URL vault. The vault server can centralize everything necessary for making payments or charging.

[0334] The safe server can provide a safe site and additional services, can store the safe URL-PWD, and can decide login with the safe URL and safe URL-PWD. The safe server can execute the payment request process, user verification process, and money payment process, and can support various transactions and recharges, communicate with external servers, and can receive money (coupons) from outside and recharge the URL safe.

[0335] (Safe URL) A safe URL is a URL that can help you connect to a safe server or a safe site. Safe URL-B and Safe URL-S are also safe URLs.

[0336] The safe URL can help connect to other things and can include representative digital information, etc. The safe URL can be saved in the form of digital information or image in URL media and can be used as a user ID, etc. The safe URL can be set with safe URL-PWD, etc., and can also be used when collecting money.

[0337] (Money supplying place) A money supplying place can supply money to a URL safe. Money supplying places include bank accounts, securities accounts, credit cards, URL-POS collection accounts, safe servers, etc. One URL safe can be a money supplying place for another URL safe.

[0338] The money supply can automatically transfer money to URL vaults etc.

[0339] (Collection Account) A collection account can receive money. Collection accounts include bank accounts, and collection account S is a collection account that corresponds to safe URL-S.

[0340] (Terminal) A terminal is an electronic device that has the function of communicating with URL media, exchanging information with users, and connecting to the Internet.

[0341] A typical terminal is a smartphone, but terminals can also be PCs, wall pads, and TVs that have devices that can communicate with URL media.

[0342] The terminal of the invention does not require a USIM or app, and one terminal can connect to a sales site and the other terminal can connect to a vault server or vault site to make payments, and can also function as a URL-POS.

[0343] (Device information) Device information is information held by a device, such as the device's IP, OS serial number, MAC address, device identification information (IMEI: International Mobile Equipment Identity), etc. Device information can be provided to the outside or used as information to identify the device, user, etc.

[0344] (URL-POS) URL-POS is a store sales system or point-of-sale information management system that is composed of sales devices and sales functions and manages sales information. URL-POS can be composed of an ordering device, a charging device, a credit card payment device, a device that communicates with URL media, a balance confirmation device (a device that checks the balance of the URL safe), and a management computer. URL-POS can be composed of a sales server (= an Internet server that supports online sales) and operation software. URL-POS can include a ticket machine, a washing machine, a car wash, etc. that can support payment of URL media while providing services, etc.

[0345] URL-POS can use the internal menu and the vault server menu, and can pass the information necessary for payments, charging, and operating the system to the vault server.

[0346] (URL-POS information) URL-POS information is information held by URL-POS (URL-POS IP, OS serial number, MAC address, device identification information (IMEI: International Mobile Equipment Identity), etc.). URL-POS information can be provided to an external party or used as information to identify the URL-POS or the operator of the URL-POS.

[0347] (Money) Money is something that has economic value. Money can include money (e.g., coupons) issued by a vault server or a sales server.

[0348] (Safe URL-PWD) Safe URL-PWD is secret information that can help you pay with money in the URL safe or charge money to the URL safe. Safe URL-PWD can be set in association with the URL medium, safe site, safe URL, etc.

[0349] The safe URL-PWD can be memorized by the user and used as login information, and can also be used as information to verify the user.

[0350] (Results of safe URL-PWD verification) The results of safe URL-PWD verification are the results of checking the safe URL-PWD, safe URL, device information, etc.

[0351] (Comparison of CCC Server, App Server, and Vault Server) The CCC server is composed of a CCP server that supports the payment request process and the payment process in response to CC information that complies with credit card standards, and a CCW server that supports the user verification process in response to CCW-URL, and is a server that supports payment with money outside the medium (URL-NFC-CC) (does not support recharge); the app server is a server that supports apps & smartphones and apps, recognizes QR codes as user IDs, and supports payment with money outside the medium (app & smartphone) (app & smartphone account) and recharge money outside the medium. The vault server is a server that supports URL media and vault sites, etc., and supports payment with money outside the URL media (URL vault) and recharge money outside the URL media (URL vault).

[0352] The order number is a number that represents an order. The order number can be used to specify the contents of an order, etc.

[0353] The order details may include items, prices, etc. The order details may be included in a payment request.

[0354] The order confirmation is to confirm the contents of your order and may include related information.

[0355] The payment schedule informs you that you are planning to make a payment with money from the URL Vault and can include related information.

[0356] The payment request is a request to make a payment with URL Vault money and may include related information.

[0357] The payment request may include URL media information, representative electronic information, order details, etc. The payment request does not include CC information that complies with credit card standards or QR codes that require an app.

[0358] The payment command commands a payment to be made with money in the URL vault and may include related information.

[0359] The result of a payment command is the result of executing the payment command and may include related information.

[0360] The payment result is the result of executing the payment, which may include related information and may be delivered via the vault site, text, etc.

[0361] A charge request is a request to charge money to the URL vault, and can include related information (URL medium information, representative electronic information, monetary information, etc.) and can be executed automatically according to pre-setup.

[0362] The charge result is the result of the charge and may include related information, and may be distributed via the safe site or text.

[0363] The charge command commands the charging of money to the URL vault and may include related information.

[0364] The charge command result is the result of executing the charge command and may include associated information.

[0365] The charge request is a request to a third party to charge money to the URL vault, and may include information related to transmitting the money to the third party.

[0366] The charge result is the result of executing the charge request, and may include related information and may be delivered via the safe site or text.

[0367] A connection may be made primarily and then secondarily for the same purpose.

[0368] A connection command is a command to make a connection and may include related information.

[0369] A sales site is an Internet site that sells goods and services.

[0370] Advertisement means any information or content other than information relating to payments or charges.

[0371] (Characteristics and advantages of URL media payment) a) URL media payment stores money outside the URL media (URL vault), b) URL media payment transfers vault URL and information to the vault site or vault server when requesting payment, c) URL media payment transfers vault URL-PWD to the vault server via the vault site when verifying the user, d) URL media payment transfers money outside the URL media (URL vault) to another account, e) URL media payment payment request process and user verification process can be reversed, f) URL media payment uses only one type of information (vault URL), so the production cost of the medium (URL media) is low, g) URL media payment payment request path and user verification path are different, but the information used (vault URL) is the same, h) URL media payment can be charged using the URL media, i) URL media payment can support various transactions, j) URL media payment has no or low fees, k) Payment via URL medium can structurally prevent hacking, l) Payment via URL medium protects the remaining balance even if the URL medium is lost, m) Payment via URL medium is advantageous for creating added value using the Internet site because the entire payment process is done using the Internet site, n) Payment via URL medium can support payment using only the URL medium without a smartphone, o) Payment via URL medium does not involve information leakage even if the smartphone is lost, p) Payment via URL medium can reflect changes in services and contents in real time, and q) Payment via URL medium does not require a credit card system or app.

[0372] <Explanation of symbols>

[0373] 110-1, 110-2, 110-3, 110-4: RF card (RF card payment medium)

[0374] 120-1, 120-2, 120-3, 120-4: User

[0375] 130-1, 130-2: RF card charger

[0376] 140-3, 140-4: RF card payment machine

[0377] 210, 310: URL-NFC-CC (=URL-NFC-CC payment medium)

[0378] 220, 320: User

[0379] 230, 330: CC-POS

[0380] 240, 340: Terminal

[0381] 250, 350: CCC Server

[0382] 270, 370: Collection account

[0383] 280, 380: CC account

[0384] 410-1, 410-2: Apps & Smartphones (payment medium for apps & smartphones)

[0385] 420-1, 420-2: User

[0386] 430-1, 430-2: App POS

[0387] 450-1, 450-2: Application server

[0388] 470-1, 470-2: Collection account

[0389] 480-1, 480-2: App & Smartphone Account

[0390] 510, 610, 710, 810, 910, 1010, 1110, 1210, 1310, 1410, 1510B, 1510S, 1610B, 1610S, 1710B, 1710S, 1810B, 1810S, 1910, 2010, 2110, 2210, 2310, 2410, 2510, 2610, 2710, 2810: URL medium

[0391] 520, 620, 720, 820, 920, 1020, 1120, 1220, 1320, 1420, 1520B, 1620B, 1720B, 1820B, 1920, 2020, 2120, 2220, 2320, 2420, 2520, 2620, 2720, 2820: User

[0392] 530, 630, 730, 830, 930, 1030, 1130, 1230, 1330, 1430, 1930, 2030, 2330, 2430, 2530, 2630, 2730, 2830: URL-POS

[0393] 740, 840, 940, 1040, 1140, 1240, 1340, 1440, 1540, 1640, 1740, 1840, 2140, 2240, 2740, 2840: Terminal

[0394] 550, 650, 750, 850, 950, 1050, 1150, 1250, 1350, 1450, 1550, 1650, 1750, 1850, 2150, 2250, 2350, 2450, 2550, 2650, 2750, 2850: Vault Server

[0395] 2160, 2260, 2360, 2460: Money Supply

[0396] 570, 670, 770, 870, 970, 1070, 1170, 1270, 1370, 1470, 1570S, 1670S, 1770S, 1870S: Collection Account

[0397] 580, 680, 780, 880, 980, 1080, 1180, 1280, 1380, 1480, 1580B, 1680B, 1780B, 1880B, 2180, 2280, 2380, 2480, 2580, 2680, 2780, 2880: URL safe.

Claims

1. A URL storage medium owned by a user, capable of storing a safe URL for connecting to a safe server described below and transmitting the safe URL to a URL-POS described below and a terminal described below; A URL-POS, which is composed of any one of an order device, a charge device, a credit card payment device, a device communicating with a URL medium, a balance confirmation device, and a management computer, which can receive a payment request and order details from a user, receive the vault URL from the URL storage medium, connect to a vault server corresponding to the vault URL, transmit the payment request and order details to the vault server, receive a payment result from the vault server, and transmit it to the user; a terminal which is an electronic device having a function of communicating with a URL storage medium, exchanging information with a user, and connecting to the Internet, which is capable of receiving the safe URL from the URL storage medium, connecting to the safe server in response to the safe URL, transmitting terminal information to the safe server, receiving a safe URL-PWD from the user which the user remembers and uses as login information, transmitting the safe URL-PWD confirmation result and order details from the safe server and transmitting them to the user, receiving an order confirmation from the user and transmitting it to the safe server, and receiving the payment result from the safe server and transmitting it to the user; a safe server which is a web server supporting payment with money in the URL safe described below, which connects to the URL-POS which has received the safe URL, receives the payment request and order details from the URL-POS, connects to the terminal which has received the safe URL, receives the safe URL-PWD, transfers the safe URL-PWD confirmation result and the order details to the terminal, receives the order confirmation from the terminal, transmits a payment command to the URL safe described below, receives the result of the payment command from the URL safe described below, and transmits the payment result to the URL-POS and the terminal; a URL vault that holds money corresponding to the URL storage medium, capable of receiving the payment instruction from the vault server, transferring money to a collection account described below, and transmitting the results of the payment instruction to the vault server; and a collection account through which said money can be collected from said URL vault; A payment system in which the vault server confirms the user with the vault URL and vault URL-PWD, transmits a payment command to the URL vault in response to the payment request and order confirmation, and the URL vault transfers money to a collection account in response to the payment command.

2. a) A step in which a URL-POS, which is composed of an ordering device, a charge device, a credit card payment device, a device communicating with a URL medium, a balance confirmation device, or a management computer, receives a payment request and order details from a user, receives a safe URL for connecting to a safe server from a URL storage medium owned by the user, connects to a safe server corresponding to the safe URL, transmits the payment request and order details to the safe server, and the safe server manages the payment request; b) a terminal, which is an electronic device having a function of communicating with a URL storage medium, a function of exchanging information with a user, and a function of connecting to the Internet, receives the safe URL from the URL storage medium, connects to the safe server corresponding to the safe URL, receives a safe URL-PWD from the user, which is to be memorized by the user and used as login information, and transmits the safe server; c) the safe server transmits the result of the safe URL-PWD verification and the order contents to the terminal; d) the terminal transmitting the result of the safe URL-PWD verification and the order contents to the user, receiving an order verification from the user, and transmitting the order verification to the safe server; e) the vault server transmits a payment command to a URL vault that holds money corresponding to the URL storage medium; f) the URL vault transferring money to a collection account, the collection account collecting the money, and the URL vault transferring a payment result resulting from a payment command to the vault server; g) the safe server transmitting the payment result to the URL-POS and the terminal; and h) the URL-POS and the terminal transmitting the payment result to the user; A payment method in which the vault server confirms the user with the vault URL and vault URL-PWD, transmits a payment command to the URL vault in response to the payment request and order details, and the URL vault transfers money to a collection account in response to the payment command.

Images