WO2018185816A1 - 購入システム、購入処理方法、購入対象サーバ、及びコンピュータプログラム - Google Patents

購入システム、購入処理方法、購入対象サーバ、及びコンピュータプログラム Download PDF

Info

Publication number
WO2018185816A1
WO2018185816A1 PCT/JP2017/013973 JP2017013973W WO2018185816A1 WO 2018185816 A1 WO2018185816 A1 WO 2018185816A1 JP 2017013973 W JP2017013973 W JP 2017013973W WO 2018185816 A1 WO2018185816 A1 WO 2018185816A1
Authority
WO
WIPO (PCT)
Prior art keywords
purchase
information
user
screen
advance payment
Prior art date
Application number
PCT/JP2017/013973
Other languages
English (en)
French (fr)
Inventor
和人 林
Original Assignee
株式会社One Tap BUY
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by 株式会社One Tap BUY filed Critical 株式会社One Tap BUY
Priority to PCT/JP2017/013973 priority Critical patent/WO2018185816A1/ja
Priority to JP2019510515A priority patent/JP6913160B2/ja
Publication of WO2018185816A1 publication Critical patent/WO2018185816A1/ja

Links

Images

Classifications

    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06QINFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00Payment architectures, schemes or protocols
    • G06Q20/04Payment circuits
    • G06Q20/06Private payment circuits, e.g. involving electronic currency used among participants of a common payment scheme
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06QINFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00Payment architectures, schemes or protocols
    • G06Q20/22Payment schemes or models
    • G06Q20/28Pre-payment schemes, e.g. "pay before"

Definitions

  • the present invention relates to a purchase system, a purchase processing method, a purchase target server, and a computer program capable of applying a prepaid amount using a prepaid method such as a prepaid card as a purchase cost when purchasing (shopping) via a network.
  • a user purchases a prepaid card sold at a store or the like, and a user uses an input operation such as a card ID recorded on the purchased prepaid card. This is done with a terminal device.
  • the card ID or the like is transmitted from the user's communication terminal device to the system side, and the system side can recognize the prepaid card purchased by the user, the amount of the advance payment, and the like. Examples of using a prepaid card with a prepaid card for online purchase are also disclosed in Patent Documents 1 and 2 below.
  • the login destination is a user terminal used by the user (see the description in paragraph 0080 etc. of Patent Document 1), and in the above Patent Document 2, the login destination is the communication of the user terminal.
  • the login destination is a system that provides a shopping service that uniquely requires a login, since a login to a shopping page is unnecessary (see the description in paragraphs 0067 to 0071 of Patent Document 2).
  • Patent Documents 1 and 2 above the balance of the prepaid card is merely displayed on the user terminal (FIGS. 5A and 13A of Patent Document 1 and FIG. 5 of Patent Document 2).
  • A) and the like there is also a problem that it is difficult to smoothly perform a user operation for transmitting an instruction to purchase a product or the like to a system such as a shopping site by using a prepayment related to the prepaid method.
  • the present invention has been made in view of such circumstances, and a purchase system that enables a purchase via a network to be performed even for a system that requires login, using a prepaid method such as a prepaid card.
  • An object of the present invention is to provide a purchase processing method, a purchase target server, and a computer program. It is another object of the present invention to provide a purchase system, a purchase processing method, a purchase target server, and a computer program that enable a user to smoothly perform a purchase instruction operation using a prepaid method according to a prepaid method.
  • the present invention provides a purchase target server that provides a purchase opportunity of a purchase target to a user through a network, and receives the purchase target purchase instruction sent from a communication terminal device.
  • a prepayment management server that manages information according to the user's prepayment related to the prepaid method for each user
  • the purchase target server is user login information sent from the communication terminal device And receiving the login information of the user based on the received user login information, and means for transmitting inquiry information of the advance payment related to the user who has completed the login to the advance payment management server, the advance payment
  • the money management server receives the inquiry information, the money management server notifies the advance payment of the user to be inquired.
  • the purchase target server that provides the purchase opportunity of the purchase target to the user through the network performs the purchase processing of the purchase target in response to receiving the purchase target purchase instruction sent from the communication terminal device.
  • the purchase system includes a prepayment management server that manages information according to the prepayment of the user according to the prepaid method for each user, and the purchase target server includes the communication terminal device.
  • the prepayment management server A step of transmitting advance payment information for notifying the advance payment of the user to be an elephant to the purchase target server, and the purchase target server is further notified by the received advance payment information when receiving the advance payment information.
  • the communication terminal device When receiving the purchase screen information, the communication terminal device generates and displays a purchase screen based on the received purchase screen information, and instructs the purchase of the purchase target using the advance payment on the displayed purchase screen.
  • the present invention provides the purchase opportunity of the purchase object to the user through the network, and performs the purchase process of the purchase object in response to receiving the purchase instruction of the purchase object sent from the external communication terminal device.
  • the purchase target server when user login information sent from an external communication terminal device is received, means for performing user login processing based on the received user login information, and inquiries about advance payment related to the user who has completed login Means for transmitting information according to the user's advance payment related to the prepaid method to an external advance payment management server that manages for each user, and the advance payment information for notifying the advance payment of the user along with the transmission of the inquiry information Operation to instruct the purchase of the purchase target using the advance payment notified by the received advance payment information.
  • Reception characterized in that it comprises the means for generating a purchase screen information relating to the purchase screen capable, and means for transmitting the generated purchase screen information to the outside of the communication terminal apparatus.
  • the present invention comprises means for comparing the purchase cost of the purchase object with the amount of the advance payment notified in the received advance payment information, and when the purchase cost of the purchase object is equal to or less than the amount of the advance payment, The purchase screen information is generated. Further, the present invention generates means for generating non-purchasable screen information relating to a non-purchasable screen indicating that the purchase of the purchase target is not possible when the purchase cost of the purchase target exceeds the amount of the advance payment, and generated And means for transmitting purchase-impossible screen information to an external communication terminal device.
  • the present invention is characterized by comprising means for calculating a deficiency for the purchase of the purchase target at the amount of the advance payment, and generating purchase impossibility screen information relating to the purchase impossibility screen indicating the calculated deficiency. And Further, the present invention is characterized in that purchase prohibition screen information relating to a purchase impossibility screen indicating payment of a prepayment for the purchase impossibility cancellation of the purchase target is generated.
  • the present invention is characterized in that purchase-impossible screen information related to a purchase-impossible screen capable of accepting an operation instruction for switching to display of a deposit receipt screen for advance payment is generated.
  • the purchase prohibition screen information related to the purchase prohibition screen indicating the purchase amount reduction of the purchase target is solved for the purchase prohibition cancellation of the purchase target. It is made to produce
  • the purchase prohibition screen information related to the purchase prohibition screen capable of accepting the operation of specifying the purchase target purchase amount is generated. It is characterized by that.
  • a purchase target server that provides a purchase opportunity for a purchase target to a user through a network performs purchase processing of the purchase target in response to receiving a purchase target purchase instruction sent from an external communication terminal device.
  • the purchase processing method when user login information sent from an external communication terminal device is received, a step of performing user login processing based on the received user login information, and inquiry information of a prepayment related to the user who has completed login , A step of transmitting information corresponding to the user's advance payment related to the prepaid method to an external advance payment management server that manages for each user, and the advance payment information for notifying the user's advance payment as the inquiry information is transmitted If the payment is received, the advance payment notified by the received advance payment information is used to indicate the purchase of the purchase target.
  • Generating a purchase screen information relating to the purchase screen that can be accepted operation that, characterized by comprising a step of transmitting the generated purchase screen information to the outside of the communication terminal apparatus.
  • a server computer that provides a purchase opportunity for a purchase target to a user through a network executes the purchase process for the purchase target in response to receiving a purchase instruction for the purchase target sent from an external communication terminal device.
  • the computer program for receiving the user login information sent from the external communication terminal device to the server computer the step of performing the user login process based on the received user login information, and the user who has completed the login
  • Sending the inquiry information of the prepayment to the external prepayment management server that manages the information corresponding to the prepayment of the user related to the prepaid method for each user, and sending the inquiry information, the user prepayment If you received prepayment information to notify Generating purchase screen information relating to a purchase screen capable of accepting an operation for instructing purchase of the purchase object using the advance payment notified in step, and transmitting the generated purchase screen information to an external communication terminal device And executing a step.
  • the purchase target server uses the completion of login as a trigger to acquire information on the advance payment of the user who has completed login from the advance payment management server, and allocates the advance payment related to the acquired information to the purchase cost.
  • the user since the user is presented with a screen on which a purchase instruction can be issued, the user can purchase a desired target online with a prepaid card or the like simply by operating the purchase instruction.
  • a prepayment related to the prepaid method in the present invention a prepayment corresponding to a prepaid card issued by various entities is applicable, and further, a bank is established for a user who has opened an account with a financial institution such as a bank. Since the debit card issued by the company can be used to purchase various products, in the present invention, the depositing of the account according to the debit card (including the cash card including the debit card function) is also a prepaid method in a broad sense. It corresponds to such advance payment.
  • the purchase target of the present invention includes a wide range of items that can be purchased with advance payments. For example, various products and services fall under the purchase target, and an electronic currency in which a predetermined amount can be purchased with advance payments. (Electronic money), virtual currency, and the like are also included in the purchase target of the present invention.
  • the purchase impossible screen indicating that the purchase is impossible is presented to the user, so that the user can grasp that the advance payment by the prepaid method cannot cope. Thus, it can be avoided that the user is unnecessarily confused.
  • the shortage amount for the purchase is calculated and presented on the non-purchasable screen, it becomes possible for the user to grasp the specific shortage amount, and it is possible to cope with the purchase cannot be made with the advance payment It becomes easy to do.
  • the present invention in order to be able to resolve the purchase prohibition on the purchase impossibility screen, specific contents such as additional payment of the advance payment are presented, so that it is easy to achieve the purchase with the advance payment. Further, in the present invention, since the purchase impossible screen related to the purchase impossible screen that can accept the operation instruction for switching the display to the screen that accepts the additional payment of the advance payment is generated, the additional payment of the advance payment is smoothly performed. Accordingly, it becomes easier to purchase a purchase target desired by the user with a prepayment.
  • the purchase target designated by the user when the purchase target designated by the user can reduce the purchase amount, specific contents such as purchase amount reduction are presented in order to be able to resolve the purchase impossibility. It is easier to achieve purchases with gold. Further, in the present invention, since the purchase prohibition screen information related to the purchase prohibition screen capable of accepting the operation of specifying the purchase amount is generated, the purchase amount can be smoothly reduced when the user allows it. , Making purchases with advance payments easier.
  • the user can issue a purchase instruction with a prepayment by a prepaid method. This can be realized, and the user can smoothly perform the operation of the purchase instruction by the advance payment. Further, in the present invention, when the purchase cost is equal to or less than the amount of the advance payment, a purchase screen on which the user can operate the purchase instruction is presented, so online purchase using the advance payment such as a prepaid card Can be done smoothly.
  • the purchase impossible screen indicating that the purchase is not possible is presented to the user. You can avoid getting confused.
  • the user since the shortage amount for the required purchase amount is presented on the purchase impossible screen, the user can grasp the specific shortage amount at a glance and cope with the situation where the purchase cannot be made with the advance payment Can support.
  • the purchase target specified by the user when the purchase target specified by the user can reduce the purchase amount, specific contents such as a reduction in the purchase amount are presented so that the purchase prohibition can be resolved on the non-purchasable screen. Therefore, it is possible to support purchases with advance payments. Further, according to the present invention, since the change of the purchase amount can be designated, the user can smoothly cope with the case where the purchase amount is reduced.
  • (A) is the schematic which shows a prepaid use setting screen
  • (b) is the schematic which shows an example of a goods order screen.
  • (A) is the schematic which shows an example of a purchase screen
  • (b) is the schematic which shows an example of a purchase impossible screen. It is the schematic which shows an example of the purchase impossible screen which described reduction of the purchase amount etc. It is the schematic which shows an example of the non-purchasable screen which described reduction etc. of merchandise items.
  • It is a 1st flowchart which shows the process sequence of a purchase processing method.
  • It is a 2nd flowchart which shows the process sequence of a purchase processing method.
  • It is a 3rd flowchart which shows the process sequence of a purchase processing method.
  • FIG. 1 It is the schematic which shows an example of the sales merchandise screen of a modification.
  • A is schematic which shows an example of the purchase screen of a modification
  • (b) is schematic which shows an example of the purchase impossible screen of a modification.
  • A is the schematic which shows the memory content of the user terminal which concerns on 2nd Embodiment
  • (b) is the schematic which shows the memory content of the purchase object server of 2nd Embodiment.
  • FIG. 1 shows a general outline configuration of a purchase system 1 according to the first embodiment of the present invention.
  • the purchase system 1 can use a prepayment related to a prepaid method (for example, various cards such as a prepaid card) for payment required for purchasing an online product (corresponding to an example of a purchase target) via the network NW.
  • a prepayment related to a prepaid method for example, various cards such as a prepaid card
  • an online product corresponding to an example of a purchase target
  • the prepayment included in the prepaid card is used, and as the prepayment related to the prepaid method, either a single-use type or a chargeable type of prepayment can be used. It is necessary that the business entity that manages the advance payment can be identified. Therefore, in this embodiment, when identifying a user who uses a prepayment, a prepaid issued by an entity that collects expenses (including a prepayment) for a certain period (for example, monthly) to the user. A pattern using a prepayment method is applied.
  • Examples of collection of expenses at regular intervals include water and utility costs for water and sewage, electricity and gas, fixed and mobile phones (including smartphones), communication costs for the use of data communications, newspapers and magazines, etc.
  • Purchase costs, lease costs for various leased items, rental costs for rental properties, security costs paid to security companies, purchase costs for periodic purchases, etc. can be assumed, and among these costs paid in units of fixed periods, By collecting the amount of the advance payment, the advance payment of the user is surely generated every fixed period, and a situation in which the advance payment can be applied to various purchases can be created.
  • a prepaid card issued by a communication carrier entity that collects communication costs related to a communication device (communication terminal device) used by a user is used.
  • the communication carrier entity constructs a communication carrier system 4 in order to perform various management processes associated with communication.
  • the usage state of the user's prepaid card (the balance of the prepayment related to the prepaid card) And the like).
  • the prepayment management server 5 can provide money amount information and the like corresponding to the prepayment related to the prepaid card through the network NW.
  • the purchase system 1 uses the shopping system 2 to be used.
  • the shopping system 2 includes a purchase target server 80 that receives orders, instructions, and the like of product purchases from users via a network NW.
  • User terminals T1, T2, T3 and the like used by a user to whom a user ID is assigned correspond to communication terminal devices, specifically, a personal computer (stationary or portable personal computer) having a communication function, A kind of computer-like device having a communication function such as a portable terminal (tablet, smartphone, PDA with communication function, mobile phone, etc.) can be applied as a user terminal.
  • a personal computer stationary or portable personal computer
  • a kind of computer-like device having a communication function such as a portable terminal (tablet, smartphone, PDA with communication function, mobile phone, etc.) can be applied as a user terminal.
  • FIG. 2 shows a main internal configuration of the advance payment management server 5 included in the communication carrier system 4.
  • the prepayment management server 5 manages the amount information related to the prepayment according to the user's prepaid card for each user.
  • a mode of one server device is shown as the prepayment management server 5, but the prepayment is performed by performing distributed processing and the like on the management processing related to the prepaid cart and distributing the management of data to the database device.
  • the management server 5 can be constructed by combining a plurality of server computers and database systems, and the construction of such a plurality of devices also corresponds to the prepayment management server 5 in the present invention.
  • the communication carrier system 4 includes various servers in addition to the prepayment management server 5.
  • examples of various servers include a server responsible for communication processing, communication costs (prepaid There are servers that handle management processing such as collection (withdrawal etc.) of cards (which may include advance payment of cards).
  • a prepayment management server 5 As a prepayment management server 5 in the present embodiment, a general server computer is applied, and various devices are connected to an MPU 5a (control unit 5a) that performs overall control and various processes via an internal connection line 5h.
  • Various devices include a communication module 5b, a RAM 5c, a ROM 5d, an input interface 5e, an output interface 5f, a mass storage system (HDD system) 5g, and the like.
  • the communication module 5b is a communication device (communication means) corresponding to a connection module with the network NW and conforms to a required communication standard (for example, a LAN module).
  • the communication module 5b is connected to the network NW via a required communication device (not shown, for example, a router or the like), and enables communication with the purchase target server 80 or the user terminal of the shopping system 2. Yes.
  • the RAM 5c temporarily stores contents and files associated with the processing of the MPU 5a
  • the ROM 5d stores programs and the like that define the basic processing contents of the MPU 5a.
  • the input interface 5e is connected to a keyboard 5i, a mouse, and the like for receiving operation instructions from the system administrator of the communication carrier system 4, and transmits the operation instructions received from the system administrator to the MPU 5a.
  • the output interface 5f is connected to a display 5j (display output device), and outputs the contents accompanying the processing of the MPU 5a to the display 5j so that the system administrator can check the current processing contents and the like. .
  • the large-capacity storage system 5g (corresponding to storage medium means) stores programs, databases (DB), and the like.
  • the server system program P1, the management program P2, and the prepaid DB (database) 6 are stored. I remember it.
  • the server system program P1 defines various processes according to the server operation system.
  • the MPU 5a executes processes based on the specified contents, so that the prepayment management server 5 is a basic server. Fulfills the function.
  • the management program P2 will be described later, and the prepaid DB 6 and the like will be described first.
  • FIG. 3 shows an example of the contents of the prepaid DB 6, and a communication carrier entity that collects communication costs related to a communication device used by a communication carrier user signs a contract with the user regarding the use of the communication device, etc.
  • a communication user ID for user identification is issued for each user.
  • the prepaid DB 6 includes a communication PW (password) in the item of this communication user ID. ), Card ID (identification information for identifying a prepaid card used by the user), prepaid amount, usage history, and the like are associated with each other to ensure necessary information.
  • the prepayment management server 5 MPU 5a
  • the prepayment management server 5 can grasp various information for each user.
  • a user of a communication carrier can apply for the use of a prepaid card issued by the communication carrier entity when making a contract with the communication carrier entity regarding the use of communication equipment or after the contract.
  • the user who applied for the use of the card pays a prepayment (predetermined amount) related to the prepaid card together with a communication fee to be paid every month.
  • the monthly advance payment for the prepaid card can be selected at a certain amount desired by the user when applying for the use of the prepaid card.
  • the user selects any amount of 10,000 yen, 20,000 yen, 30,000 yen, 50,000 yen, 100,000 yen, etc. as the monthly advance payment for the prepaid card, and the selected amount and communication
  • the user pays the communication carrier entity every month the sum of the communication fee according to the amount. Since the prepaid card used in the present embodiment has the above-mentioned specifications, it becomes a charge type, and the card ID is attached to the prepaid card that is actually delivered to the user as in the case of the conventional prepaid card. It is a thing. Further, in addition to paying the prepayment in units of months as described above, the prepayment management server 5 also allows the user to charge (pay) the prepayment of the prepaid card as needed.
  • FIG. 4 shows an example of the charge screen 9 used when the user additionally charges (pays) a prepaid card advance payment.
  • An entity that issues a prepaid card in this embodiment, a communication carrier entity) distributes application software (application) corresponding to the charge screen 9 shown in FIG. 4 so that it can be downloaded to a communication terminal device used by the user.
  • the user activates such a prepaid charge application, displays the charge screen 9 on the communication terminal device used by the user, and performs an operation of additionally depositing the required advance payment as appropriate. become.
  • the charge screen 9 includes a charge amount designation field 9a for a prepaid money, and is arranged so that a charge button 9b and a cancel button 9c can be selected.
  • a charge button 9b In the user's communication terminal device, when the charge button 9b is selected in the state where the amount of advance payment desired by the user is designated in the charge amount designation field 9a, charging is performed with the designated amount of advance payment.
  • a confirmation screen (not shown) is displayed and the charge execution button included in the confirmation screen is selected, charge information (user communication user ID, etc.) is charged to charge the specified advance payment amount.
  • the charge screen 9 is built in such a manner that information including the information is transmitted to the prepayment management server 5.
  • the cancel button 9c on the charge screen 9 When the selection operation of the cancel button 9c on the charge screen 9 is performed, the prepaid charge processing is canceled and the display is switched to a home screen of a prepaid charge application (not shown).
  • the prepayment management server 5 When the prepayment management server 5 receives the charge information, the prepayment DB 6 shown in FIG. 3 updates the information stored in the prepayment amount and usage history items associated with the communication user ID included in the received charge information. Then, a process of reflecting the charge amount included in the charge instruction information in the advance payment amount is performed. Thereby, the user can charge a prepayment suitably as needed. The additionally charged advance payment is collected (billed) together when the next communication fee is collected.
  • the communication PW (password) associated with the communication user ID in the prepaid DB 6 is set by the user (registered user) who receives provision of various services from the communication carrier entity. Information indicating a password. This communication PW is used together with the communication user ID during processing that requires user authentication.
  • the card ID associated with the communication user ID in the prepaid DB 6 is information for identifying the prepaid card distributed to the user corresponding to the communication user ID.
  • the prepaid amount associated with the communication user ID in the prepaid DB 6 is information indicating the latest balance of the prepaid card used by the user corresponding to the communication user ID (corresponding to the amount information of the prepaid amount). This prepaid amount is updated by increasing / decreasing at any time as the prepaid card is used or the prepaid card is charged (payment of monthly prepaid money, etc.).
  • the use history item in the prepaid DB 6 information indicating a history of using a prepaid card by a user of a communication carrier corresponding to the communication user ID is sequentially stored in time series.
  • the stored information includes the date of use of the prepaid card, the amount used (a minus amount means the purchase of a product / service using the prepaid card, and a plus amount means a charge to the prepaid card. ), Which is intended for use.
  • the information stored in this usage history item corresponds to the information (purchase completion information, etc.) sent to the advance payment management server 5 from the server related to the prepaid card usage institution / business.
  • the MPU 5a of the prepayment management server 5 receives such purchase completion information or information such as completion of payment of the prepayment, the MPU 5a stores the information in the use history item of the prepaid DB 6.
  • the management program P2 is installed in the large-capacity storage system 5g via a storage medium such as an optical disk.
  • the processing contents defined by the management program P2 are mainly the construction / update of the prepaid DB 6 shown in FIG. There are processing related to this, payment related processing associated with the use of a prepaid card, etc., and the control contents performed by the MPU 5a for these processing are defined.
  • a user who newly applied for the use of a prepaid card is generated, and this user information (communication user ID, communication PW, card ID, etc.) is stored in the communication carrier system 4.
  • the MPU 5 a performs processing for newly storing the notified user information in the prepaid DB 6.
  • the MPU 5a performs a process of storing the payment contents in the use history item of the prepaid DB 6 together with the completion date and time of the payment process.
  • information (charge information indicating communication user ID, use or charge amount, etc.) associated with the charge of the prepaid card is obtained from the communication carrier system 4 (a server that collects communication expenses etc.) or the communication terminal device of the user, etc.
  • the MPU 5a stores the received information in the usage history item of the prepaid DB 6 in association with the communication user ID included in the received date and time together with the reception date and time of the information. Control processing will be performed.
  • the MPU 5a updates the prepaid DB 6 usage history item as described above, the prepaid amount stored in the prepaid DB 6 prepaid amount item is also updated according to the change in the usage history. Process to update to the amount.
  • the MPU 5 a When the prepaid card management server 5 receives prepaid card prepaid inquiry information (information including the communication user ID) from an external server affiliated with the use of the prepaid card, the MPU 5 a The prepaid amount associated with the included communication user ID is identified from the prepaid DB 6, and the prepaid information (information including the communication user ID and the prepaid amount) for notifying the specified prepaid amount is sent to the external server of the inquiry source The control processing to be transmitted to is performed. Further, upon receiving purchase completion information (communication user ID, advance payment usage information indicating the usage amount of advance payment, etc.) from an external server, the MPU 5a performs a process to settle the amount included in the information. With the completion of the settlement, the MPU 5a updates the above-described usage history item of the prepaid DB 6.
  • the MPU 5a sends the same information as above to the prepaid DB 6 when the charge information (including the communication user ID and the charge amount) is received from the user's communication terminal device.
  • the charge amount is updated in association with the communication user ID, and the prepayment information indicating the updated charge amount (available prepayment) is sent to an external server (prepayment inquiry before a certain time). (Equivalent to the server that sent the information).
  • FIG. 5 shows the purchase target server 80 included in the shopping system 2.
  • the purchase target server 80 constitutes a basic part of the shopping system 2 and performs processing necessary for providing an online shopping service (purchase opportunity for purchase target) to the user.
  • FIG. 5 only one purchase target server 80 is shown, but for example, by performing distributed processing on various processes performed by the purchase target server 80, a plurality of server computers and database systems are combined to purchase the target server. 80 may be configured, and such a configuration of a plurality of apparatuses also corresponds to the purchase target server 80 in the present invention.
  • the purchase target server 80 will be described.
  • a general server computer is applied, and various devices are connected to the MPU 80a (control unit 80a) that performs overall control and various processes by an internal connection line 80h.
  • Various devices include a communication module 80b, a RAM 80c, a ROM 80d, an input interface 80e, an output interface 80f, a mass storage system (HDD system) 80g, and the like.
  • the communication module 80b is a communication device (communication means) corresponding to a connection module with a network and conforms to a required communication standard (for example, a LAN module).
  • the communication module 80b is connected to a network (an internal network of the shopping system 2 or an external network NW) via required communication equipment (not shown; for example, a router or the like), and user terminals T1, T2, T3 And other external servers (such as various servers such as the advance payment management server 5 of the communication carrier system 4).
  • the RAM 80c temporarily stores contents and files associated with the processing of the MPU 80a
  • the ROM 80d stores programs and the like that define the basic processing contents of the MPU 80a.
  • the input interface 80e is connected to a keyboard 80i, a mouse, and the like for receiving an operation instruction from a system administrator of the shopping system 2, and transmits the operation instruction received from the system administrator to the MPU 80a.
  • the output interface 80f is connected to a display 80j (display output device), and outputs the contents accompanying the processing of the MPU 80a to the display 80j so that the system administrator can check the current processing contents and the like. .
  • the large-capacity storage system 80g (corresponding to storage medium means) stores programs, databases (DB), and the like, and in this embodiment, stores system programs P10, sales programs P11, user DBs 81, product DBs 82, and the like. ing.
  • the system program P10 defines various processes according to the operation system for the server, and the MPU 80a executes processes based on the specified contents, so that the purchase target server 80 functions as a server computer. Fulfill.
  • the sales program P11 will be described later, and the user DB 81 will be described first.
  • FIG. 6 shows an outline of the contents of the user DB 81.
  • the user DB 81 is a database that stores various types of information of users registered in the shopping service provided by the shopping system 2, and a user ID for identifying the user is given to the registered user from the shopping system 2 in accordance with the user registration.
  • the user DB 81 stores various information in association with the assigned user ID. Specifically, the user DB 81 stores the user name, address, telephone number, mail address, UID (identification information of the user terminal), occupation, PW (password), and the like for each user ID.
  • the registered mail address is used as a login ID at the time of login, and the PW uses alphanumeric information set by the user at the time of user registration.
  • the business company (business entity) that operates the shopping service provided by the shopping system 2 is affiliated with the prepaid card service provided by the communication carrier entity that operates the communication carrier system 4, and the communication carrier entity By using a prepaid card to be issued, it is possible to purchase various products (purchase targets) sold through the above shopping service.
  • information necessary for the use of a prepaid card is also stored in the user DB 81 for a user who applied for the use of a prepaid card of a communication carrier entity when performing user registration for a shopping service or after user registration.
  • information items necessary for the use of a prepaid card include a card use item indicating that the use of a prepaid card is set at the user terminal, a communication user ID issued by the communication carrier entity, And items for storing the card ID of the prepaid card used by the user, and information corresponding to these items is stored in association with the user ID.
  • the information provided by the user is stored in the user DB 81 in association with the user ID by providing the information about the prepaid card) to the shopping system 2 from the user.
  • the card usage information for notifying the communication user ID, the card ID, and the like is transmitted from the user terminal to the purchase target server 80.
  • the communication user ID included in the card use information is stored in the user DB 81 in association with the user ID.
  • a registered user of a shopping service requests a communication carrier entity to provide information related to its prepaid card to the entity that operates the shopping service, so that the communication carrier entity operates the shopping service operation business. It is also possible to provide information on the prepaid card of the requested user to the body and store it in the user DB 81.
  • the prepaid card cannot be used for the shopping service only by applying for the use of the prepaid card to the communication carrier entity, and the prepaid use setting screen 17 in FIG. By setting the use of the prepaid card, the prepaid card can be used for the shopping service.
  • User information stored in the user DB 81 is also updated as appropriate.
  • information about the new user is added to the user DB 81, and when the user registration is canceled, information about the user is added. Is deleted from the user DB 81.
  • the product DB 82 stored in the large-capacity storage system 80g is a database that stores information on a large number of products sold by the shopping service, and is associated with product IDs for identifying products, It stores various information such as information (various specifications, etc.), product images, unit prices, inventory quantity, and the like.
  • the sales program P11 of the present embodiment is installed in the large-capacity storage system 80g via a storage medium such as an optical disk, and is executed by the MPU 80a for user login, product purchase (shopping), use of a prepaid card, and the like. Control processing is specified.
  • the communication module 80b receives user login information (which may include the UID of the user terminal) including the user's email address and password transmitted from the user terminal, the user's login is received.
  • user login information which may include the UID of the user terminal
  • the sales program P11 defines that the MPU 80a performs a process (login process) for determining whether or not matching information is stored in the user DB 81 of FIG.
  • login disable information indicating that the login information does not match is transmitted to the user terminal that is the login information transmission source using the communication module 80b.
  • the sales program P11 defines that the control is performed by the MPU 80a.
  • the user ID corresponding to the login information is set as the login completion for the user ID corresponding to the login information, and is in the login state.
  • the login state information indicating this is stored in the RAM 80c or the like, and the MPU 80a performs a process of transmitting login completion information indicating the completion of login to the user terminal of the user who has completed the login.
  • the login state information is stored together with the user ID in the RAM 80c until logoff information is received from the user terminal.
  • the MPU 80a For the user who has entered the login state, the MPU 80a performs a process of determining whether or not the information “use” is stored in the item “card use” of the user DB 81 shown in FIG. In the case where “use” information is stored, inquiry information (information including a communication user ID and a card ID) for inquiring about a prepaid payment of a prepaid card of a logged-in user (a user who has completed login) is used as a communication carrier system. The MPU 80a performs the process of transmitting to the prepayment management server 5 in FIG.
  • the address information for sending information to the advance payment management server 5 is notified to the shopping system 2 in advance and stored in the large-capacity storage system 80g of the purchase target server 80, and the MPU 80a stores this information.
  • Various information is transmitted to the prepayment management server 5 based on the address information.
  • the prepayment management server 5 when the prepayment information for notifying the prepayment of the inquired user is received from the prepayment management server 5 with the transmission of the inquiry information, the received prepayment information is stored in the RAM 80c in the login status information of the user.
  • the MPU 80a performs a process of storing the information in association with each other.
  • the MPU 80a does not perform the inquiry information transmission process. Further, when the purchase target server 80 receives prepaid use information indicating that the prepaid card is used from the user terminal, the “card use” item of the user DB 81 is associated with the user ID included in the prepaid use information, and “ The MPU 80a performs a process of storing information “used”. Then, if information is already stored in each item of “communication user ID” and “card ID” of the user DB 81 in association with the user ID storing the information of “use”, the card can be used. The MPU 80a performs processing for transmitting the card usable information to the user terminal that has transmitted the prepaid usage information.
  • the MPU 80a requests information on card settings.
  • the MPU 80a performs processing for transmitting the card setting request information to that effect to the user terminal that is the transmission source of the prepaid use information.
  • the purchase target server 80 receives the card setting information sent from the user terminal in response to the transmission of the card setting request information, it is associated with the user ID included in the card setting information and “
  • the MPU 80a performs processing for storing the communication user ID and the card ID information included in the card setting information in each item of “communication user ID” and “card ID”, and transmits the card usable information to the user terminal.
  • the MPU 80a performs control processing.
  • the purchase target server 80 receives prepaid non-use information indicating that the prepaid card is not used from the user terminal, it is associated with the user ID included in the prepaid non-use information in the “card use” item of the user DB 81.
  • the MPU 80a performs the process of storing the information “not used” and the MPU 80a performs the control process of transmitting the prepaid information to the user terminal.
  • the setting of use or non-use of a prepaid card can be changed at any time according to the information sent from the user terminal, and items related to the prepaid card in the user DB 81 (card use, communication user)
  • the information stored in (ID, card ID) is also updated as appropriate.
  • the purchase target server 80 When the purchase target server 80 receives a product information request (a request including information such as a product ID) to be described later from the user terminal of the logged-in user, the product information (product image) associated with the received product ID , Information indicating product specifications, unit prices, etc.) is read from the product DB 82 and transmitted to the user terminal that is the source of the product information request.
  • a product information request a request including information such as a product ID
  • the product information product image
  • the purchase target server 80 receives purchase order information specifying the product ID, purchase amount, and purchase amount (amount obtained by multiplying the purchase amount by the unit price) from the user terminal of the logged-in user.
  • the MPU 80a temporarily stores the received purchase order information in the RAM 80c, and determines whether or not the user of the user terminal that has sent the purchase order information is set to use a prepaid card. This determination is made based on whether or not “use” information is stored in the “card use” item in the user DB 81.
  • the MPU 80a When it is determined that the user of the user terminal that has transmitted the purchase order information does not set the use of the prepaid card, the MPU 80a identifies the purchase amount related to the purchase order information, and then purchases the purchase price by credit card or bank transfer. Information to request payment settlement is transmitted to the user terminal.
  • the MPU 80a stores the purchase amount included in the received purchase order information in the RAM 80c and the logged-in user ID. The MPU 80a determines whether or not the purchase amount exceeds the amount of the advance payment as compared to the amount of the advance payment indicated by the advance payment information stored in association with. If the purchase amount exceeds the amount of the advance payment, the purchase funds are insufficient. Therefore, the shortage amount is calculated, and the MPU 80a determines that the purchase according to the received purchase order information is not possible.
  • the MPU 80a If it is determined that the purchase is not possible, the MPU 80a generates purchase-impossible screen information for causing the user terminal to display a purchase-impossible screen indicating that purchase is not possible, and has transmitted the purchase order information. Process to send to.
  • This generated non-purchasable screen information includes text information indicating that the purchase is not possible, and in addition to the shortage amount for the purchase of the product selected by the user, the purchase is not possible including information for resolving the shortage amount for the purchase. It depends on the screen. Specifically, the information for eliminating the shortage amount corresponds to information (text information) according to the notation indicating the charge (addition of advance payment) to the prepaid card.
  • MPU80a generates non-purchasable screen information related to non-purchasable screens that can accept an instruction operation to switch to displaying the prepaid charge acceptance screen so that the prepaid card shortage can be smoothly resolved Like to do. Specifically, the MPU 80a generates screen information indicating that purchase is not possible including a link instruction for starting an application related to the charge screen 9 shown in FIG.
  • the MPU 80a uses a prepaid card as information corresponding to the purchase impossibility.
  • the notation indicating the reduction of the item of the product to be purchased include the notation indicating the reduction of the item of the product to be purchased, and generate the purchase impossible screen information related to the purchase impossible screen that can accept the item reduction operation of the product, and purchase A process of transmitting the order information to the user terminal that has transmitted the order information is performed.
  • the non-purchasable screen information generated in this case includes information (text information) according to the above-described notation and information (item reduction instruction information) that enables an operation for accepting an item reduction of a product. Yes.
  • the MPU 80a uses the prepaid card as information for eliminating the shortage amount.
  • purchase not included screens that include a notation that indicates the reduction of the purchase amount of the product to be purchased and that can accept the purchase amount specification operation (operation to specify the reduction)
  • the information is generated and transmitted to the user terminal that has transmitted the purchase order information.
  • the purchase impossible screen information generated in this case includes information (text information) according to the above-described notation, and information (purchase amount reduction instruction information) that enables an operation to be received to reduce the number of products purchased. It has become.
  • the MPU 80a determines that the purchase is possible with the prepayment, and uses the prepayment notified by the prepayment information.
  • a process of generating purchase screen information related to a purchase screen that can accept an operation instructing purchase of a purchase target and transmitting the generated purchase screen information to the user terminal is performed.
  • the purchase screen information is the content for confirming the purchase of the product designated by the user using the advance payment (if the user designates a plurality of purchase quantities or items of a plurality of types of products, also confirm them together) Text content).
  • the MPU 80a receives the RAM 80c. Compare the purchase amount included in the purchase order information stored in to the available advance payment amount included in the newly received advance payment information to determine whether the purchase amount exceeds the advance payment amount. to decide. When it is determined that the purchase amount is equal to or less than the amount of the advance payment, the MPU 80a determines that the purchase can be made with the advance payment, and performs processing for generating purchase screen information and transmitting it to the user terminal.
  • the MPU 80a executes the purchase process according to the received purchase instruction.
  • the MPU 80a performs a process of transmitting purchase completion information for notifying that the purchase of the product designated by the user is completed to the user terminal that has transmitted the purchase instruction.
  • the MPU 80a identifies the use amount of the prepayment, and prepayment use information (information including a communication user ID) that notifies the use amount of the specified prepayment Is transmitted to the advance payment management server 5.
  • FIG. 7 shows a main internal configuration of a smartphone 10 (communication terminal device) that is an example of a user terminal (T1, T2, T3, etc.) that uses a communication carrier provided by the communication carrier system 4.
  • the smartphone 10 corresponds to a kind of computer (computer equipped with communication means and storage means) that performs various processes according to a program.
  • the smartphone 10 is connected to a CPU 10a (processor 10a) that performs overall control and various processes via an internal connection line 10i, a communication / call module 10b (corresponding to communication means), a RAM 10c, a ROM 10d, an input / output interface 10e, and an operation.
  • Various devices such as a unit 10h and a storage unit (corresponding to storage means) 10g are connected.
  • the user terminal is a communication terminal device other than a smartphone (such as a computer or a tablet having a communication function)
  • the basic configuration is the same as that shown in FIG. An overview of all types of communication terminal devices is shown.
  • the communication / call module 10b of the smartphone 10 includes a function for making a call to a predetermined telephone number (calling function) and a function for receiving a call (incoming call function) in addition to wireless communication processing via the network.
  • the RAM 10c temporarily stores contents, files, data, information and the like accompanying the processing of the CPU 10a.
  • the ROM 10d stores a program that defines the basic processing contents of the CPU 10a, and also stores identification information (UID) that identifies the smartphone 10. This UID is included in the transmission content when communicating (transmitting) with the communication / call module 10b described above (for example, transmission is performed including the UID in the header of the transmission packet).
  • the input / output interface 10i is connected to a display 10f having a touch panel function, and performs processing for outputting various screens (see screens shown in FIGS. 8 to 14 and the like) generated by the control processing of the CPU 10a to the display 10f. As a result, the output screen content is displayed on the display 10f.
  • the input / output interface 10e also performs a process of sending the operation content received by the user touching the surface of the display 10f to the CPU 10a. It should be noted that the operation content received by the user touching the surface of the display 10f changes appropriately according to the displayed screen content.
  • the operation unit 10h is a hard button provided on the housing of the smartphone 10, and when the operation unit 10h is operated, the fact that the operation unit 10h has been operated is transmitted to the CPU 10g.
  • the meaning of the operation of the operation unit 10h varies depending on the processing status of the smartphone 10. For example, when the operation unit 10h is operated in a state where the application is activated, an operation for ending the application is performed. In this case, the operation of the operation unit 10h receives an application end instruction from the user.
  • the shopping application P21 for shopping service installed in the storage unit 10g
  • the operation unit 10h is operated while the shopping application P21 is activated. Then, the smartphone 10 accepts the end instruction of the shopping application P21, and the logoff instruction of the shopping application P2 is transmitted to the shopping system 2.
  • the storage unit 10g stores (installs) programs such as the OS program P20, the shopping application P21, and other various applications (for example, a prepaid charge application corresponding to the charge screen 9 in FIG. 4).
  • the OS program P20 is a basic program corresponding to an operating system, and defines the processing of the CPU 10a for the smartphone 10 to function as a kind of computer.
  • One of basic processes defined by the OS program P20 is to display a home screen on the display 10f first when the smartphone 10 is ready for use. Arrangement of icons and the like corresponding to various applications installed in the unit 10g is also due to processing defined by the OS program P20.
  • the shopping application P21 memorize
  • storage part 10g is an application program (computer program) for online shopping services which the shopping system 2 provides, As a purchase opportunity of various goods used as a purchase object, a sales merchandise screen, merchandise order It is defined that the CPU 10a performs various controls in accordance with processing for displaying a screen, a purchase screen, and the like on the user terminal and transmitting an instruction accompanying a user operation on the displayed screen to the shopping system 2.
  • the CPU 10a functions as a means for generating various screens according to the specified contents.
  • the shopping application P21 includes screen data corresponding to each part (button or the like) arranged in various screens, text information corresponding to various notations, and the like in addition to the program code defining the processing.
  • a shopping icon for starting the shopping application P21 is displayed in the home screen based on the OS program P20.
  • the smartphone 10 accepts a user operation for selecting the shopping icon, if the user is already logged in at that time, a sale for providing the user with a purchase opportunity that can specify various products to be purchased from a plurality of items. If a product screen or the like is displayed on the display 10f and the login state is not set, the CPU 10a performs processing for generating a login screen and displaying it on the display 10f.
  • FIG. 8 shows an example of the login screen 15 displayed on the display 10f, which is generated based on the screen data for the login screen by the processing of the CPU 10a.
  • the login screen 15 has a mail address input field 15a, a password input field 15b, and a selectable login button 15c.
  • the data of the parts corresponding to each part arranged in this way also includes screen data for the login screen.
  • the soft keyboard 14 is displayed on the display 10f by a function corresponding to the processing specified by the OS program P20 described above, and the user appropriately operates each key included in the soft keyboard 14 Thus, predetermined contents are input to the input fields 15a and 15b.
  • the password to be entered is determined for each user at the time of user registration with the shopping service.
  • the smartphone 10 When the smartphone 10 accepts the selection operation of the login button 15c in a state where predetermined contents are input to the input fields 15a and 15b, the input contents are transmitted to the shopping system 2 as user login information. Data that specifies the contents of such creation (data written in a script language, etc.) is also included in the screen data for the login screen (such selection is possible) The same is true for other screen data). If the smartphone 10 receives login impossible information from the shopping system 2 (purchase target server 80) in response to the transmission of the login information via the login screen 15 as described above, the password is used to secure another input opportunity.
  • the CPU 10a performs a process of displaying on the display 10f a login screen (which is structurally equivalent to that shown in FIG. 8) indicating that they do not match.
  • FIG. 9 shows an example of the sale product screen 16 displayed on the display 10f, which is displayed based on the fact that the smartphone 10 has received login completion information sent from the purchase target server 80 after the login is completed. .
  • product images 16a to 16f showing various products to be purchased are arranged so that they can be selected as thumbnails. As shown in FIG. 9, the products presented in this way may belong to various categories, or may be various products in one product category.
  • FIG. 9 shows a state in which a total of six product images 16a to 16f are represented, by performing a scroll operation or the like on the sales product screen 16, the sales product screen 16 can view six or more product images. It is possible.
  • the sales product screen 16 is arranged so that a setting button 16g can be selected at the upper right of the screen, and upon accepting the selection of the setting button 16g, various setting menu items related to the shopping function can be selected for each item. It is displayed (not shown).
  • the menu items corresponding to the setting button 16g include items related to prepaid card use settings.
  • FIG. 10A shows an example of the prepaid use setting screen 17, and when the selection operation of the item related to the prepaid card use setting in the menu item corresponding to the setting button 16g is received, the CPU 10a controls The screen is displayed on the display 10f.
  • the prepaid use setting screen 17 includes a selectable prepaid use selection field 17a and a prepaid non-use selection field 17b, and only one of the selection fields 17a and 17b can be selected. Further, the prepaid use setting screen 17 has an OK button 17c and a return button 17d that can be selected, and upon accepting a selection operation of the return button 17d, a process of switching the display of the display 10f to the sales product screen 16 of FIG.
  • the CPU 10a performs.
  • the CPU 10a performs a process of transmitting the prepaid use information to the purchase target server 80. It will be.
  • the smartphone 10 receives the prepaid use information sent from the purchase target server 80 in response to the transmission of the prepaid use information, the use setting of the prepaid card is completed, and the CPU 10a displays the display on the display 10f in FIG. The process of switching to the sales merchandise screen 16 is performed.
  • the smartphone 10 receives the card setting request information sent from the purchase target server 80 in response to the transmission of the prepaid use information, the communication user ID input field provided by the prepaid card issuer communication carrier entity, prepaid
  • the CPU 10a performs a process for displaying on the display 10f a card information input screen (not shown) having a card ID input field for the card and an OK button.
  • the OK button selection operation is performed in a state where necessary information such as each ID is input on the card information input screen, the input information is transmitted to the purchase target server 80 to set the use of the prepaid card.
  • the CPU 10a performs a process of switching the display on the display 10f to the sales merchandise screen 16 in FIG.
  • the smartphone 10 accepts a selection operation of the OK button 17c in the state where the prepaid non-use selection column 17b is selected on the prepaid use setting screen 17 of FIG. 10A
  • the prepaid non-use information is obtained from the purchase target server 80.
  • the CPU 10a performs a process of transmitting to.
  • the smartphone 10 receives the prepaid information from the purchase target server 80 in response to the transmission of the prepaid non-use information
  • the prepaid card is set in an unusable state, and then the CPU 10a displays the display 10f. Is switched to the sales merchandise screen 16 in FIG.
  • the user terminal side can appropriately switch the setting to use or not use a prepaid card in this way, thereby improving user convenience.
  • FIG. 10B shows the product order screen 18 displayed on the display 10f when the selection operation of the product image 16a at the upper left is accepted on the sales product screen 16 of FIG. 9 accepts the selection operation of the product images 16a to 16f, the product information request is transmitted to the purchase target server 80 for the products related to the product images 16a to 16f that are the selection operation targets. It is built.
  • the smartphone 10 receives the product information sent from the purchase target server 80 in response to the transmission of the product information request, the smartphone 10 temporarily stores the received product information in the RAM 10c, and based on the product information, FIG.
  • the CPU 10a performs processing for generating and displaying the product order screen 19 shown in b).
  • the product order screen 18 includes a detailed product image 18a having a size larger than the product image 16a shown in FIG. 9 and product detailed information 18b (text information describing the product name, model number, price, description about the product, etc.) and A purchase quantity designation field 18c in which a purchase quantity (number of purchases) can be designated, a cart button 18d with a word to put in a cart, a purchase order button 18e with a word to proceed to purchase, and a return button 18f can be selected. It is arranged.
  • the purchase amount designation column 18c accepts an operation for designating a purchase amount (purchase number) desired by the user.
  • the user can confirm the details of the product, and if the result of the confirmation indicates that the product is not to be purchased, the user selects the return button 18f. A selection operation will be performed.
  • the smartphone 10 accepts the selection operation of the return button 18, the CPU 10a performs a process of switching the display on the display 10f to the sales merchandise screen 16 in FIG.
  • the user If the user confirms the screen content of the product order screen 18 and determines that the product shown on the product order screen 18 is to be secured for purchase, the user performs an operation of selecting the cart button 18d. It will be. When it is desired to secure a plurality of product purchase quantities, the user operates the purchase quantity designation field 18c to designate a desired purchase quantity (number of purchases), and then selects the cart button 18d. Will do.
  • the smartphone 10 accepts the selection operation of the cart button 18d, the CPU 10a stores the product ID, the price, the designated purchase amount, and the like corresponding to the product shown on the product order screen 18 in the RAM 10c as product securing information. A process of temporarily storing and a process of switching the display on the display 10f to the sales merchandise screen 16 of FIG. 9 are performed. By performing such processing by the CPU 10a, the user can have an opportunity to continuously purchase (shopping) other products after securing a desired product.
  • the user confirms the screen content of the product order screen 18 and determines that the product shown on the product order screen 18 is to be purchased, the user performs an operation of selecting the purchase order button 18e.
  • the smartphone 10 accepts the selection operation of the purchase order button 18, the CPU 10 a once displays a product ID, a price (amount required for purchase), a designated purchase amount, and the like corresponding to the product shown on the product order screen 18. Then, after organizing as product securing information and storing it in the RAM 10c, processing for generating purchase order information corresponding to the content of the product securing information and transmitting the generated purchase order information to the purchase target server 80 is performed.
  • FIG. 11A shows an example of the purchase screen 19 displayed on the display 10f, and the smartphone 10 has received the purchase screen information transmitted from the purchase target server 80 along with the transmission of the purchase order information described above.
  • This screen is displayed when the purchase target server 80 determines that the product can be purchased with a prepayment by a prepaid card.
  • the purchase screen 19 shows information 19a (product name, unit price, purchase amount, etc.) of the product to be purchased at the top of the screen, and purchaseable information showing that the product can be purchased with a prepaid card below it.
  • a purchase button 19c is arranged, and a purchase button 19c, a purchase cancel button 19d, and a shopping continuation button 19e (corresponding to a button to be put in a cart) in which the word “continue shopping” is arranged so as to be selectable are arranged below the purchaseable information 19b. .
  • the smartphone 10 accepts the selection operation of the purchase button 19c, the purchase instruction operation for the product (purchase target) specified by the user using the advance payment of the prepaid card according to the content of the purchaseable information 19 included in the purchase screen 19 Therefore, the CPU 10a performs a process of transmitting a purchase instruction to purchase the product using the advance payment to the purchase target server 80.
  • FIG. 14 shows an example of the purchase completion screen 23 displayed on the display 10 f.
  • the smartphone 10 receives purchase completion information from the purchase target server 80 in response to transmitting a purchase instruction to the purchase target server 80.
  • the screen is displayed.
  • the purchase completion screen 23 includes a text part 23a indicating that the purchase has been completed, and a return button 23b in which a word indicating return to the sales product screen 16 is written. It is possible to grasp that has been completed. Further, when the selection operation of the return button 23b is performed, the product securing information temporarily stored in the RAM 10c is deleted, and the CPU 10a performs a process of switching the display of the display 10f to the sales product screen 16 of FIG. I am doing so.
  • the smartphone 10 accepts a selection operation of the purchase cancel button 19d
  • the purchase instruction is canceled, and the product temporarily stored in the RAM 10c is secured.
  • the CPU 10a performs a process of deleting information and switching the display of the display 10f to the sales merchandise screen 16 of FIG.
  • the product once purchased by the user can be canceled even at the purchase confirmation stage, and the user can continue the product selection operation smoothly on the sales product screen 16 of FIG. I can do it.
  • the CPU 10 deletes the product securing information temporarily stored in the RAM 10c. Instead, the CPU 10a performs a process of switching the display of the display 10f to the sales merchandise screen 16 of FIG. In this way, the user can continue to select other products while securing the user's desired purchase product (a plurality of product items can be purchased).
  • FIG. 11B shows an example of the purchase impossibility screen 20 displayed on the display 10f, and the purchase impossibility screen information transmitted from the purchase target server 80 with the transmission of the purchase order information described above is displayed on the smartphone.
  • 10 is a screen that is displayed when received, and is displayed when the purchase target server 80 determines that the product cannot be purchased with a prepaid payment using a prepaid card.
  • the purchase disapproval screen 20 shows information 20a (product name, unit price, purchase amount, etc.) of a product to be purchased at the top of the screen, and below that it indicates that the product cannot be purchased with a prepaid card advance payment.
  • the purchase prohibition information 20b shown is arranged.
  • Specific information included in the purchase prohibition information 20b includes not only that the product cannot be purchased with the advance payment, but also the shortage amount included in the purchase prohibition screen information (3000 in the example of FIG. 11B). (Yen) and how to deal with the inability to purchase.
  • the charge to the prepaid card (payment of prepaid money) is shown as a way of handling. Since the purchase disabling information 20b describes the above-described contents, the user can confirm the situation in which the purchase with the prepaid card is not possible, and can easily grasp how to deal with the purchase disapproval.
  • the purchase prohibition screen 20 is arranged below the purchase prohibition information 20b so that the purchase cancel button 20d and the charge button 20e can be selected.
  • the purchase cancel button 20d is selected when the user gives up the purchase using the prepaid card.
  • the purchase cancel button 19d included in the purchase screen 19 in FIG. When the selection operation of the cancel button 20d is accepted, the purchase instruction is canceled, the product securing information temporarily stored in the RAM 10c is deleted, and the display 10f is displayed on the sales product screen 16 in FIG.
  • the CPU 10a performs a process of switching between.
  • the charge button 20e is selected and operated when the user decides to charge the prepaid card (pay the advance payment) in accordance with the handling method shown in the purchase impossibility information 20b.
  • the charge button 20e is linked to the activation of the prepaid charge application corresponding to the charge screen 9 of FIG. 4, and when the selection operation of the charge button 20a is accepted, the prepaid charge application is activated, and FIG.
  • the CPU 10a performs a process of switching the display 10f to the charge screen 9 (prepayment deposit acceptance screen).
  • the user enters a charge amount designation column 9 a in an amount equal to or greater than the shortage amount shown in the purchase disapproval information 20 b of the purchase disapproval screen 20 in FIG.
  • the charge button 9b is selected and designated. With such a selection operation of the charge button 9b, the CPU 10a performs control to transmit charge information to the advance payment management server 5.
  • the display 10f is controlled to be switched to the purchase screen 19 shown in FIG.
  • the purchase button 19c is selected, the product designated by the user can be purchased.
  • the prepayment amount of the prepaid card is insufficient, charging is made possible as appropriate during a series of purchase operation processing. You can complete the purchase with a prepaid card.
  • FIG. 12 shows an example of the purchase disapproval screen 21 displayed on the display 10f.
  • the purchase amount of the product to be purchased is plural (in the case of FIG. 12, the purchase amount is “3”). This is different from the case of the purchase impossible screen 20 shown in FIG. That is, the purchase disapproval screen 21 of FIG. 12 shows information 20a (product name, unit price, etc.) of a product to be purchased at the top of the screen, and includes a purchase quantity designation column 21b below it, Below the column 21b is arranged purchase prohibition information 21c indicating that the product cannot be purchased with the prepayment of the prepaid card, and below the recalculation button 21d, the charge button 21f, and the purchase cancel button 21g. It is arranged.
  • the purchase impossible screen 21 in FIG. 12 has a purchase amount of “3”, and the purchase amount can be reduced. Therefore, the purchase impossible screen information corresponding to the display of the purchase impossible screen 20 in FIG.
  • the content of the item also includes purchase amount reduction instruction information, and such content cannot be purchased
  • a purchase amount designation column 21b is arranged below the product information 20a.
  • the CPU 10a performs a process of generating a purchase impossibility screen 21 in which a recalculation button 21d is arranged below the purchase additional information 20b. Further, the purchase prohibition information 21c included in the purchase prohibition screen 21 reduces the purchase amount as a way of dealing with the content of the purchase prohibition information 20b included in the purchase prohibition screen 20 in FIG. It has been added.
  • the recalculation button 21d of the purchase disapproval screen 21 is in a state where the selection operation is not possible (inactive) when the numerical value designated in the purchase amount designation column 21b has not been reduced from the state initially displayed on the display 10f. (A state indicated by a broken line in FIG. 12), and is selected so that the selection operation can be performed in a state where an operation for reducing the quantity in the purchase quantity designation number field 21b from the first numerical value is accepted. ing.
  • the user performs an operation of designating the quantity in the purchase quantity designation number column 21b so that it falls within the amount of the prepayment amount of the prepaid card in consideration of the shortage indicated in the purchase impossibility information 21b (FIG. 12). In this case, since the shortage amount is 900 yen and the product unit price is 1000 yen, the user designates the purchase amount from “3” to “2” or less).
  • the CPU 10a orders the product with the numerical value of the reduced purchase quantity.
  • the process of transmitting the purchase order information (product ID, numerical value of the reduced purchase amount, information including the purchase amount) to the purchase target server 80 is performed again.
  • the purchase screen information is transmitted from the purchase target server 80 in response to the transmission of the purchase order information with the reduced purchase amount, and the CPU 10a receives the purchase screen information based on the reception of the purchase screen information (FIG. 11 (a) purchase screen 19) is generated, and the display 10f is switched to the generated purchase screen.
  • the charge button 21f and the purchase cancel button 21g included in the purchase prohibition screen 21 in FIG. 12 function in the same manner as the charge button 20e and the purchase cancel button 20d in the purchase prohibition screen 20 in FIG. ing.
  • FIG. 13 shows an example of the purchase prohibition screen 22 displayed on the display 10f, and there are a plurality (two) of items (types of products) to be purchased, and the purchase of each purchase target product.
  • the amount is also plural, which is different from the case of the non-purchasable screen 21 shown in FIG. That is, the purchase impossible screen 22 of FIG. 13 shows information 22a (product name, unit price, etc.) of the first product to be purchased at the top of the screen, and the purchase amount designation for the first product below A column 22b is included, the second product information 22c is shown below the column 22b, a purchase quantity designation column 22d for the second product is included below, and the purchase impossibility information 22e is arranged below the column 22b. Below that, a recalculation button 22f, a charge button 22g, and a purchase cancel button 22h are arranged to be selectable.
  • the purchase impossibility screen 22 in FIG. 13 is a case where a plurality (two) types of products are ordered by operating the shopping continuation button 19e on the product order screen 18 in FIG. In addition, the screen is displayed when purchase is not possible when there are a plurality of purchase amounts of two types of products. Therefore, the non-purchasable screen information corresponding to the non-purchasable screen 22 shown in FIG. 13 is the content of the non-purchasable screen information corresponding to the non-purchasable screen 21 shown in FIG. Information indicating reduction of items is included, and item reduction instruction information is included. When the smartphone 10 receives such purchase-impossible screen information, the CPU 10a generates the purchase-disabled screen 22 shown in FIG. 13 based on the received purchase-disabled screen information.
  • the purchase quantity designation fields 22b and 22d of the purchase impossible screen 22 in FIG. 13 it is possible to designate the purchase quantity to be reduced, and “0” can be designated as the numerical value of the purchase quantity, and “0” is designated.
  • the product to be purchased is deleted.
  • the purchase impossibility information 22e included in the purchase disapproval screen 22 is the same as the purchase impossibility information 21c included in the purchase impossibility screen 21 shown in FIG. It has become.
  • the recalculation button 22f, charge button 22g, and purchase cancel button 22h included in the purchase impossibility screen 22 in FIG. 13 are equivalent to the recalculation button 21d, charge button 21f, and purchase cancel button 21g in the purchase impossibility screen 21 in FIG.
  • the recalculation button 22f is not activated immediately after being displayed, and an operation for designating the reduction of the numerical values in the purchase amount designation fields 22b and 22d is performed.
  • Built to be active selectively arithmetic modifier
  • the processing contents of the purchase processing method based on a series of processing by the advance payment management server 5, the purchase target server 80, the user terminal T1, etc. (for example, the smartphone 10) of the purchase system 1 having the above-described configuration will be described with reference to FIGS. 17 will be described based on the first to third flowcharts 17 (the processing itself of the purchase target server 80 also corresponds to the purchase processing method). It is assumed that the use of a prepaid card is set in advance on the prepaid use setting screen 17 in FIG. 10A at the stage of starting the process of the first flowchart.
  • the first flowchart in FIG. 15 shows a processing procedure after the user logs in to the shopping system 2 (purchasing target server 80) that provides an online shopping service (product purchase opportunity) using the user terminal T1. It is a thing.
  • This first flowchart starts with the user terminal T1 (smartphone 10) starting from a state in which the user performs an icon selection operation corresponding to a shopping service on the home screen and displays the login screen 15 in FIG. (S1).
  • the user terminal T1 determines whether or not there is a login operation such as an email address input operation, a password input operation, and a login button 15c selection operation (S2). If there is no login operation (S2: NO), the login operation is waited.
  • the user's login information (entered e-mail address and password and user terminal)
  • the user terminal transmits information including the UID to be identified) to the purchase target server 80 of the shopping system 2 (S3).
  • the purchase target server 80 (MPU 80a) is in a stage of determining whether or not the login information has been received (S10), and when the login information is not received (S10: NO), the purchase target server 80 is in a waiting state for reception. If login information has been received (S10: YES), whether or not there is a match between the information stored in the user DB 81 shown in FIG. The purchase target server 80 determines (S11). When the matching information is not stored (S11: NO), the purchase target server 80 transmits a mismatch notification to the access source user terminal. In this case, the user terminal T1 is triggered by the reception of the mismatch notification, returning to the stage of S1, displaying the login screen 15 again, and presenting the user with an opportunity to input correct login information.
  • the purchase target server 80 indicates that the user who has transmitted the login information has entered the login state. (Information including the user ID and the like) is stored in the RAM 80c, and login completion information for notifying login completion is transmitted to the user terminal T1 (S12).
  • the user terminal T1 switches the display on the display 10f from the login screen 15 to the display on the sales merchandise screen 16 shown in FIG. 9 by receiving the login completion information from the purchase target server 80 (S4).
  • the product order screen 18 in FIG. 10B is displayed, and operations such as selection of a product to be purchased and designation of a purchase amount are accepted. It shall be (S5).
  • the purchase target server 80 determines whether or not the information “use” is stored in the “card use” item of the user DB 81 for the user who has completed the login (S13). When the information of “use” is not stored (S13: NO), processing related to purchase is performed by credit card, bank transfer, or the like as in the conventional case, and thus description in this case is omitted. On the other hand, when the information of “use” is stored (S13: YES), the purchase target server 80 inquires for the advance payment of the prepaid card of the logged-in user (information including the communication user ID and the card ID). ) Is transmitted to the advance payment management server 5 of the communication carrier system 4 (S14).
  • the prepayment management server 5 of the communication carrier system 4 is in a stage of determining whether or not the prepayment inquiry information from the purchase target server 80 has been received (S20), and does not receive the inquiry information (S20: NO), waiting for reception. On the other hand, when the inquiry information is received (S20: YES), the prepayment management server 5 specifies the amount of the prepayment associated with the communication user ID included in the inquiry information from the prepaid DB 6 of FIG. S21). Then, the purchase target server 80 transmits the advance payment information for notifying the specified advance payment amount to the purchase target server 80 (S22).
  • the purchase target server 80 determines whether or not the advance payment information has been received (S15). If the advance payment information has not been received (S15: NO), the purchase waiting server 80 is waiting for reception. When the prepayment information is received (S15: YES), the received prepayment information is stored in the RAM 80c in association with the login status information of the user (S16).
  • the second flowchart of FIG. 16 shows that purchase order information is sent to the purchase target server 80 in response to the selection operation of the purchase order button 18e being performed on the product order screen 18 of FIG. It shows that the transmission process is being performed (S30).
  • the purchase target server 80 determines whether or not the purchase order information has been received (S40), and if it has not been received (S40: NO), the purchase target server 80 is in a reception waiting state. On the other hand, when the purchase order information is received (S40: YES), the purchase target server 80 indicates the purchase cost of the product notified by the received purchase order information as the amount of the advance payment of the user (the advance payment information stored in the RAM 80c). To determine whether or not the purchase is possible (S41).
  • the purchase target server 80 determines that the purchase is not possible (S41: NO), calculates the shortage of the advance payment with respect to the purchase cost, and calculates that the purchase is impossible.
  • the purchase impossible screen information related to the purchase impossible screen indicating the shortage amount and the method of canceling the purchase impossible is generated and transmitted to the user terminal T1 (S42).
  • the purchase target server 80 transmits the purchase impossible screen information, the purchase target server 80 returns to the stage of S40 and determines whether or not the purchase order information has been received.
  • the user terminal T1 determines whether or not purchase-impossible screen information sent from the purchase target server 80 has been received (S31).
  • the purchase-prohibited screen information is received (S31: YES)
  • the purchase impossible screen information information indicating that purchase is not possible and information indicating a shortage amount
  • the purchase impossible screen 20 shown in FIG. 11B is generated (S33).
  • the generated non-purchasable screen 20 is displayed on the display 10 (S34).
  • the purchase is canceled. Since a plurality of contents can be assumed, the processing after the display of the purchase impossibility screen 20 is omitted in the second flowchart.
  • step S41 determines in step S41 that the purchase cost is equal to or less than the amount of the advance payment and the purchase is possible (S41: YES)
  • the advance payment is made. Is used to generate purchase screen information related to a purchase screen that can accept an operation for instructing the purchase of a product designated by the user (S43), and the generated purchase screen information is transmitted to the user terminal T1 (S44).
  • the user terminal T1 When the purchase screen information is transmitted from the purchase target server 80 to the user terminal T1, the user terminal T1 proceeds to the case where the purchase impossible screen information is not received (S31: NO) in step S31, and then the purchase screen information is displayed. It is determined whether or not it has been received (S32), and when purchase screen information is received (S32: YES), the user terminal T1 performs the processing shown in the third flowchart of FIG. If purchase screen information is not received (S32: NO), the process returns to the step S31.
  • the user terminal T1 In the third flowchart of FIG. 17, the user terminal T1 generates the purchase screen 19 of FIG. 11A based on the received purchase screen information (S50), and displays the generated purchase screen 19 on the display 10f ( S51). Then, the user terminal T1 determines whether or not the selection operation of the purchase button 19c is accepted on the displayed purchase screen 19 (S52). If the selection operation of the purchase button 19c is not accepted (S52: NO), the shopping is performed. It is determined whether or not an operation for selecting the continuation button 19e has been accepted (S53). When the selection operation of the shopping continuation button 19e is accepted (S53: YES), in order to be able to purchase other products, the process returns to the step S4 in the first flowchart of FIG. 15, and the display on the display 10f is displayed. Switch to 16.
  • the user terminal T1 When the selection operation of the purchase button 19c is received at the stage of S52 (S52: YES), the user terminal T1 receives a purchase instruction operation for purchasing a product by payment from the prepaid card shown on the purchase screen 19 Accordingly, a purchase instruction corresponding to the content is transmitted to the purchase target server 80 (S56).
  • the purchase target server 80 determines whether or not a purchase instruction from the user terminal T1 has been received after transmitting the purchase screen information in the step S44 of the second flowchart (S60), and has not received it. If this is the case (S60: NO), it will be in a reception waiting state.
  • the purchase target server 80 performs a purchase process according to the purchase instruction based on the received purchase instruction (S61). Then, the purchase target server 80 transmits purchase completion information to the user terminal T1 (S62).
  • the user terminal T1 After transmitting the purchase instruction at the stage of S56, the user terminal T1 determines whether or not the purchase completion information from the purchase target server 80 has been received (S57), and if not received (S57: NO), a state of waiting for reception is set. When the purchase completion information is received (S57: YES), the user terminal T1 generates and displays the purchase completion screen 23 shown in FIG. 14 (S58). With this purchase completion screen 23, the user confirms that the purchase process based on the purchase instruction has been completed.
  • the purchase target server 80 transmits the purchase completion information in step S62, specifies the amount of the advance payment used by the prepaid card, and manages the advance payment usage information for notifying the specified usage amount. It transmits to the server 5 (S63).
  • the prepayment management server 5 determines whether or not the prepayment usage information from the purchase target server 80 has been received after transmitting the prepayment information in the stage of S22. (S23), if the prepayment information is not received (S23: NO), it becomes a reception waiting state, and if the prepayment information is received (S23: YES), the prepayment information included in the received prepayment information A payment process for the amount is performed (S24), and the use history of the prepaid DB 6 is updated when the payment is completed.
  • a prepaid card can be used for smooth shopping, and the card ID of the prepaid card is input for shopping. Since it is possible to use a prepaid card with no prepaid card, the operation burden on the user is reduced. In addition, if the prepaid card advance payment is insufficient for the purchase cost of the product, it will be clearly stated how to cancel the purchase (charge for prepaid card, reduction of purchase amount, reduction of the items for purchase, etc.) Therefore, the merchandise sales side can avoid missing the user's purchase opportunity online with a prepaid card.
  • 1st Embodiment of this invention is not limited to the content mentioned above, Various modifications can be considered.
  • the login by the login screen 15 shown in FIG. 8 is performed immediately after the shopping application P21 is started.
  • the product order screen 18 shown in FIG. 10B is displayed on the display 10f.
  • the login screen 15 of FIG. 8 may be displayed on the display 10f at the timing when the user performs the selection operation of the purchase order button 18e.
  • the selection operation of the login button 15c is performed in a state where a predetermined email address and password are entered in the email address input field 15a and the password input field 15b on the login screen 15, the login information and the purchase order button 18e are displayed.
  • the CPU 10a performs a process of transmitting purchase order information associated with the selection operation to the purchase target server 80.
  • the purchase target server 80 that has received the login information determines that the login has been completed if the email address and password included in the login information are stored in the user DB 81, and based on the purchase order information received from that, the prepaid card Judge whether the purchase is possible or not by the advance payment by.
  • the purchase target server 80 When it is determined that the purchase is possible, the purchase target server 80 generates purchase screen information related to the purchase screen (for example, the purchase screen 19 shown in FIG. 11A) and transmits it to the user terminal. Will generate purchase impossible screen information related to the purchase impossible screen (for example, the purchase impossible screen 20 shown in FIG. 11B) and transmit it to the user terminal.
  • a purchase screen for example, purchase screen 19
  • a purchase impossible screen for example, purchase is not possible
  • the login screen 15 is displayed so that an e-mail address, a password, and the like can be input again.
  • examples of purchase objects for which the shopping service provides a purchase opportunity are not limited to the products shown on the sales product screen 16 in FIG. 9, and other types of products can of course be applied to the present invention. is there. For example, it is possible to purchase information, purchase rights, purchase financial products, and the like. In addition to products, the present invention can be applied to various services (moving, cleaning, repair, etc.). Further, when the product provided by the shopping service is of a single type and the user specifies only the purchase amount, the sales product screen 16 for presenting a plurality of products as shown in FIG. 9 is presented on the user terminal. Instead, a sales product screen for designating the purchase amount may be presented.
  • a configuration may be adopted in which a screen on which a financial product can be purchased is presented after a login screen mainly for purchasing electrical appliances.
  • a screen that mainly handles miscellaneous goods it may be configured to present a screen on which a service such as repair related to it or a moving service unrelated to it can be purchased.
  • a service such as repair related to it or a moving service unrelated to it can be purchased.
  • Such a configuration can be realized by various configurations. For example, on a product category screen mainly handled at the time of login, a button or the like that can be changed to a purchase screen of a product category different from the product category is presented. Thus, it is possible to realize such a configuration that, by pressing the button, another product category can be changed to a screen that can be purchased.
  • FIG. 18 shows a state in which an example of the sales product screen 30 of the modification is displayed on the display 10f.
  • the sales product screen 30 of this modification is a case where the purchase object by the prepaid card is an electronic currency, and when a shopping application for electronic currency purchase is installed in the user terminal and this application is activated, the login screen 15 of FIG. When the login is completed along with the transmission of the login information, the sales merchandise screen 30 in FIG. 18 is displayed on the display 10f of the user terminal.
  • the sales product screen 30 for electronic currency purchase includes a purchase amount designation field 30a and a purchase button 30b, and the user performs an operation for designating the purchase amount (purchase amount) of the electronic currency in the purchase quantity designation field 30a.
  • the user terminal accepts a selection operation of the purchase button 30b in a state where the purchase amount is specified, a process of transmitting purchase order information in electronic currency including the specified purchase amount (purchase amount) to the purchase target server 80 is performed.
  • the terminal (CPU 10a) will do.
  • the purchase target server 80 when the purchase target server 80 receives the purchase order information from the user terminal associated with the logged-in user ID, as described above, the user terminal associated with the logged-in user ID uses the prepaid card. If the use of a prepaid card is set, the purchase amount included in the received purchase order information is stored in advance payment information stored in association with the logged-in user ID.
  • the MPU 80a determines whether or not the purchase amount exceeds the amount of the advance payment compared to the amount of the advance payment shown. If it is determined that the purchase amount does not exceed the advance payment amount and is less than or equal to the advance payment amount, the MPU 80a determines that the purchase is possible with the advance payment, and uses the advance payment to confirm the purchase of the electronic currency to be purchased.
  • the purchase screen information including the contents to be purchased (text contents for confirming that the electronic currency is purchased with the purchase amount specified by the user) is generated and transmitted to the user terminal.
  • FIG. 19 (a) shows a purchase screen 31 displayed on the display 10f of the user terminal when the user terminal receives purchase screen information corresponding to the purchase of the electronic currency described above.
  • This purchase screen 31 is purchaseable information 31a which describes the content of confirming that electronic money is purchased with a prepaid card (10,000 yen) with a purchase amount (10,000 yen) designated by the user.
  • a purchase button 31b and a return button 31c are arranged below it.
  • the user terminal gives a purchase instruction (instruction to purchase the electronic currency with the purchase amount designated by the user) to purchase the electronic currency with the contents described in the purchaseable information 31a.
  • the user terminal (CPU 10a) performs processing to be transmitted to the purchase target server 80.
  • the processing of the purchase target server 80 that has received the purchase instruction is the same as described above, and the purchase process is executed based on the purchase instruction (see step S61 in the third flowchart of FIG. 17). Further, when the selection operation of the return button 31c is performed, the display of the display 10f is switched to the sales merchandise screen 30 in FIG. 18 so that the user can change the purchase amount.
  • the purchase target server 80 compares the purchase amount with the amount of the advance payment and determines that the purchase amount exceeds the amount of the advance payment, the MPU 80a determines that the purchase cannot be made with the advance payment.
  • the shortage amount due to the advance payment is calculated, and the purchase impossible screen information related to the purchase impossible screen including the fact that the electronic currency as the purchase target cannot be purchased is generated using the advance payment, and is transmitted to the user terminal. Process to send.
  • the purchase-impossible screen information generated in this modification is that the purchase amount can be reduced for the electronic currency to be purchased. Is included.
  • FIG. 19B shows a purchase impossibility screen 32 displayed on the display 10f of the user terminal when the user terminal receives the purchase impossibility screen information corresponding to the above-described electronic currency.
  • This purchase screen 31 is an unpurchasable information 32a stating that 5,000 yen is insufficient to purchase electronic money with a purchase amount (10,000 yen) designated by the user with a prepayment card.
  • a charge button 32b and a return button 32c are arranged below it.
  • the purchase impossibility information 32a describes the reduction of the purchase amount in addition to the prepaid card charge as a method of canceling the purchase impossibility.
  • the contents when the selection operation of the charge button 32b and the return button 32c is performed are the same as described above.
  • the modification examples shown in FIGS. 18 and 19 can also be applied to purchase targets other than electronic currency.
  • purchase targets such as virtual currency, gold, platinum, other prepaid cards, etc.
  • the sales merchandise screen 30 shown in FIG. 18 can be displayed by transitioning from the sales merchandise screen 16 as shown in FIG.
  • the purchase target corresponding to the sales product screen 30 is included in the plurality of product images 16a and the like arranged in the sales product screen 16, and the product image selection operation corresponding to the purchase target is performed.
  • the sales consumption screen 30 is displayed.
  • the login operation can be performed by switching to the display of the login screen 15 in response to the selection operation of the purchase button 30b on the sales product screen 30 being accepted as in the case described above. It is also possible to make it.
  • the charge screen 9 shown in FIG. 4 can be displayed on the user terminal without performing the login operation of the prepayment management server 5, but the prepayment is similar to the login to the shopping service.
  • the management server 5 may also require a login operation, and the charge screen 9 of FIG. 4 may be displayed after the login related to the login operation is completed.
  • the login operation is required in this way, when the selection operation of the charge buttons 20e, 21f, and 22g is performed on the purchase impossible screens 20, 21, and 22 in FIGS.
  • Such a login screen is displayed on the user terminal, the communication user ID or the card ID is input, and the login button selection operation is performed, so that the communication user ID or the card ID is included.
  • a login request is sent from the user terminal to the advance payment management server 5.
  • the prepayment management server 5 determines whether or not the login is appropriate based on whether or not the communication user ID or the card ID included in the login request is stored in the prepaid DB 6.
  • the user terminal displays the charge screen 9 shown in FIG. 4 based on the fact that the login completion from the advance payment management server 5 is received.
  • purchase screen information for displaying the purchase screen 19 shown in FIG. 11A, or purchase impossible screen information for displaying the purchase impossible screens 20, 21, and 22 shown in FIGS. Is described as including text and instructions according to the information displayed on the screen, but purchase screen information and non-purchasable screen information can be information including contents including various numerical values instead of text. .
  • purchase screen information and non-purchasable screen information can be information including contents including various numerical values instead of text.
  • the first number included in the information is 0, it means purchase screen information, and when the first number is 1, it is determined that it means purchase impossible screen information. If the number of 1 is used as purchase screen information or non-purchasable screen information, the processing load on the purchase target server 80 can be reduced and the amount of communication information can be reduced.
  • the notation content of the purchaseable information 19b included in the purchase screen 19 shown in FIG. 11 (a), and FIGS. 13 the notation contents of the purchase disapproval information 20b, 21c, 22e included in the purchase disapproval screens 20, 21, 22 are included in the shopping application P21 in advance, and are appropriately selected when the screens 19, 20, 21, 22 are generated.
  • the predetermined notation is read out.
  • the purchase impossibility information 20b, 21c, and 22e includes a shortage amount, for example, when the number 1 is used as the purchase disapproval screen information. It is assumed that the purchase target server 80 generates non-purchasable screen information including a numerical value of a shortage amount (for example, 10,000 when there is a shortage of 10,000 yen).
  • the purchase impossibility screens 20, 21 and 22 shown in FIGS. 11 (b), 12 and 13 differ in the manner of canceling the purchase impossibility.
  • numerical values representing the purchase impossibility screen information are used.
  • a number of 2 or 3 is used, and when the first number included in the information (screen information that is not available for purchase) is 1, as shown in FIG.
  • the first number is 2, it is made to correspond to the purchase impossible information 21c of the purchase impossible screen 21 in FIG. 12 when the first number is 2, and when the first number is 3, It is conceivable to correspond to the purchase prohibition information 22c on the purchase prohibition screen 22.
  • these purchase prohibition information 20b, 21c, and 22c since the method of canceling the purchase prohibition is different, it is necessary to use each of them separately. Therefore, by changing the first numerical value as described above, the purchase prohibition screen Even if the information is a number, it can be handled.
  • the notation according to these purchase impossibility information 20b, 21c, 22c is included in the shopping application P21 in advance, and the purchase impossibility information 20b, 21c, 22c used by the user terminal (CPU 10a) based on the above-described numbers. The contents of the notation will be distinguished.
  • non-purchasable information 21c on the non-purchasable screen 21 in FIG. 12 as a method of resolving the non-purchasable, in addition to the prepaid card charge, a reduction in the purchase amount is described.
  • disabling information 22c the reduction of the merchandise item is described.
  • the promotion of the use of the prepaid card is emphasized, only the prepaid card charge may be described as a method of canceling the inability to purchase.
  • the method of canceling the purchase prohibition is left to the user's judgment, the notation of how to cancel the purchase prohibition can be omitted.
  • the prepaid card use setting is made through the prepaid use setting screen 17 in FIG. 10A.
  • the prepaid card use setting is made.
  • the use of the prepaid use setting screen 17 in FIG. 10A can be omitted.
  • the prepaid use setting screen 17 of FIG. 10A may be displayed every time a purchase is made, and the user may be able to appropriately set the use or nonuse of the prepaid card for each purchase.
  • the processing load of the purchase target server 80 is reduced, it is also possible to make the specification such that the processing relating to the determination of whether or not purchase is possible (processing such as S41 to S43 in the second flowchart in FIG. 16) is performed on the user terminal side. Is possible.
  • the purchase target server 80 receives and acquires the advance payment information from the advance payment management server 5 (see S15 in the first flowchart of FIG. 19)
  • the purchase advance server 80 obtains the acquired advance payment information (information indicating the advance payment amount). Transmit to the user terminal T1.
  • the user terminal T1 Upon receipt of the advance payment information, the user terminal T1 temporarily stores it in the RAM 10c.
  • the purchase cost of the purchase target is compared with the amount of the advance payment related to the advance payment information stored in the RAM 10c. As a result of the comparison, if the purchase cost exceeds the amount of the advance payment, the process of generating and displaying the purchase impossible screen 20 as shown in FIG. Is included in the shopping application P21 in advance, extracted and used, and if the purchase cost is equal to or less than the amount of the advance payment, it is determined that the purchase is possible, and a purchase screen as shown in FIG. 19 is generated and displayed by the process of the user terminal itself.
  • the communication carrier entity that collects communication costs related to communication devices has been described.
  • the prepaid card is a prepaid card issued by an entity that can be collected (identified and collected by the user) by adding the amount of the advance payment to the cost paid by the user, It can be widely used as a prepayment related to the prepaid method in the invention.
  • debit cards including cash cards having a debit card function
  • financial institutions such as banks can be used for purchasing various products
  • depositing accounts according to debit cards is performed.
  • the prepayment related to the prepaid method is applicable.
  • a server device constituting a system for managing a debit card in a financial institution such as a bank corresponds to a prepayment management server, and performs the above-described processing with the purchase target server 80.
  • a server device constituting a system for managing a debit card in a financial institution such as a bank corresponds to a prepayment management server, and performs the above-described processing with the purchase target server 80.
  • the purchase system according to the second embodiment of the present invention performs the processing according to the first embodiment described above on a website basis, and uses the various screens shown in FIGS. 4 and 8 to 14 as web page screens of the website. It is intended to be displayed.
  • the same reference numerals are used as in the first embodiment, and the contents of the second embodiment will be described below. .
  • the shopping system 2 constructs a shopping site on the network NW, and the purchase target server 80 included in the shopping system 2 plays the role of a web server and responds to access from the user terminal.
  • the various screens described in the first embodiment are displayed on the user terminal via the website so that the user can purchase the product.
  • FIG. 20A shows the contents of a program or the like in the second embodiment stored in the storage unit 10g by the smartphone 10 (see FIG. 7) as an example of a user terminal, and is specific to the second embodiment.
  • the browser application P22 (browser application) is newly stored.
  • the browser application P22 performs processing in cooperation with the shopping application P21 ′ for the second embodiment. For example, when a shopping icon on the home screen of the user terminal is selected, the shopping system 2 (purchasing target server 80). After the access, the CPU 10a generates a web page screen based on the web page data transmitted from the shopping system 2 based on the process defined by the browser application P22. The screen is displayed on the display 10f. In addition, when the selection operation of each button included in the web page screen is received, an operation notification indicating that the button has been selected is transmitted to the shopping system 2 (purchasing target server 80). Based on this, the CPU 10a controls.
  • FIG. 20B shows the contents of a program and the like stored in the large-capacity storage system 80g of the purchase target server 80 of the shopping system 2, and a new web server program P12 as unique to the second embodiment.
  • a website DB 85 storing web page data corresponding to a plurality of web pages constituting the website to be constructed on the network.
  • the web server program P12 reads screen information constituting a required web page from the website DB 85 according to the access status from the user terminal and transmits it to the access source user terminal. It also stipulates that required screen information is transmitted in accordance with the information indicating the operation content transmitted.
  • the transaction program button P11 ′ of the second embodiment performs processing in cooperation with the processing of the web server program P12, and the content of processing to be executed (determination of purchase availability etc.) is basically the first. This is the same as the embodiment.
  • a prepaid card usage application is made in advance to an entity that provides a shopping service, and the communication user ID, card ID, card settings, and the like are also stored in the user DB 81 when applying.
  • the purchase target server 80 displays login screen information for displaying the login screen 15 of FIG. 8 in accordance with the access.
  • the login screen information is received at the user terminal, the login screen 15 is generated and displayed on the display 10f by processing of the browser application P22 based on the login screen information.
  • the login screen 15 displayed as a web page the same user operation as in the first embodiment is performed, and the user's login information is transmitted from the user terminal to the purchase target server 80.
  • the processing contents described in the first flowchart of FIG. 15 of the first embodiment are performed.
  • the login completion notification is not transmitted to the user terminal, but screen information corresponding to the sales product screen 16 in FIG. 9 is transmitted from the purchase target server 80 to the user terminal. Then, the sales product screen is displayed on the user terminal as a web page. Then, when an operation for selecting a desired product image from a plurality of product images included in the sales product screen is performed, the selection content is transmitted from the user terminal to the purchase target server 80, and the selected product image is displayed. Screen information corresponding to the product order screen for the product (see the product order screen 18 in FIG. 10B) is transmitted from the purchase target server 80 to the user terminal, and the user terminal serves as a web page based on the received screen information. Generate and display a product order screen.
  • purchase order information is transmitted from the user terminal to the purchase target server 80, as in the first embodiment. Thereafter, the processing described in the second flowchart of FIG. 16 of the first embodiment is performed, but the purchase unavailable screen information and purchase screen information transmitted from the purchase target server 80 to the user terminal are the purchase unavailable screen as a web page, It differs from the first embodiment in that it is information for displaying a purchase screen on a user terminal.
  • the purchase impossibility screen information transmitted from the purchase target server 80 to the user terminal is the user terminal with the purchase impossibility screens 20, 21, and 22 shown in FIGS.
  • the contents (each button, text notation, etc.) constituting the non-purchasable screens 20, 21, 22 are changed to contents including a markup language description such as HTML language. It has become.
  • the purchase screen information transmitted from the purchase target server 80 to the user terminal is information for generating and displaying the purchase screen 19 shown in FIG. 11A as a web page on the user terminal.
  • the contents (each button, text portion, etc.) constituting the purchase screen 19 are contents including a description of a markup language system such as HTML language.
  • the second embodiment has basically the same configuration as the first embodiment, and performs the same processing.
  • the invention according to the second embodiment is configured such that the contents according to the first embodiment are performed on a website basis, thereby performing the processing contents of the present invention with a flexible system configuration. There is a merit that can be. Also in the second embodiment, the contents of the various modifications described in the first embodiment can be applied with the contents according to the second embodiment. For example, when determining whether purchase is possible on the user terminal side, a script corresponding to the determination process is included in the screen information transmitted from the purchase target server 80 to the user terminal in order to display each screen as a web page on the user terminal. Information describing the processing of the system is included so that necessary processing can be performed on the web page as appropriate.
  • the present invention can be suitably used for making it possible to smoothly use a prepaid card for payment of purchase costs for online purchases.

Landscapes

  • Business, Economics & Management (AREA)
  • Accounting & Taxation (AREA)
  • Strategic Management (AREA)
  • Physics & Mathematics (AREA)
  • General Business, Economics & Management (AREA)
  • General Physics & Mathematics (AREA)
  • Engineering & Computer Science (AREA)
  • Theoretical Computer Science (AREA)
  • Financial Or Insurance-Related Operations Such As Payment And Settlement (AREA)

Abstract

【課題】オンラインでの商品購入にプリペイドカードを用いる場合、カードIDの入力を不要にして、スムーズにプリペイドカードで支払いを行えるようにする。 【解決手段】オンラインでの商品購入機会を提供するショッピングシステム2の購入対象サーバ80は、ユーザ端末T1からログイン情報を受信してログイン処理を行い、ログインが完了したユーザのプリペイドカードの前払い金の金額を、プリペイドカードの発行元である事業体の前払い金管理サーバ5へ問い合わせる。前払い金管理サーバ5は、問合せに応じて前払い金を通知する前払い金情報を取引サーバ80へ送信する。購入対象サーバ80は、前払い金情報を受信すると、通知された前払い金に基づき、ユーザの購入注文に対してプリペイドカードによる購入可否を判断し、購入可能と判断した場合、プリペイドカードを用いて購入を行う旨を確認する画面をユーザ端末に表示させる。

Description

購入システム、購入処理方法、購入対象サーバ、及びコンピュータプログラム
 本発明は、ネットワーク経由で購入(ショッピング)を行う場合の購入費用として、プリペイドカード等のプリペイド方式による前払い金を充当できるようにした購入システム、購入処理方法、購入対象サーバ、及びコンピュータプログラムに関する。
 従来、通信機能を有するコンピュータ、スマートフォン、携帯電話機のような通信端末装置を用いてネットワーク経由によるオンラインで、各種商品,サービス等を購入できるようにしたシステムが一般に利用されている。
 オンラインでの購入に対するプリペイドカードの使い方としては、先ず、ユーザは店舗等で販売されているプリペイドカードを購入し、その購入したプリペイドカードに記されたカードID等の入力操作をユーザの使用する通信端末装置で行うことになる。このような入力操作を行うことで、カードID等がユーザの通信端末装置からシステム側へ送信されて、システム側は、ユーザの購入したプリペイドカード及び前払い金の額などを認識できるようになる。なお、オンラインでの購入に対してプリペイドカード等による前払い金を用いる例は、下記の特許文献1、2にも開示されている。
特開2016-71658号公報 特開2006-177366号公報
 オンラインで各種商品を購入可能とする機会を提供するショッピングサイトのようなシステムでは、確実な決済を実現するため,ログインを伴うユーザ認証を独自に行うのが一般的である。しかし、上記の特許文献1では、ログイン先をユーザの使用するユーザ端末にしており(特許文献1の段落0080等の記載参照)、また、上記の特許文献2では、ログイン先をユーザ端末の通信を介在するキャリアサーバにして、ショッピングページへのログインを不要にすることから(特許文献2の段落0067~0071等の記載参照)、独自にログインを要求するショッピングサービスを提供するシステムで、プリペイド方式による前払い金で購入を行えるようにした場合、上記の特許文献1、2で開示される方法を用いることができないという問題がある。
 また、上記の特許文献1、2では、単にプリペイドカードの残高をユーザ端末に表示するに留まるので(特許文献1の図5(A)、図13(A)、及び特許文献2の図5(A)等参照)、プリペイド方式に係る前払い金を用いて商品等の購入する旨の指示をショッピングサイトのようなシステムへ伝えるためのユーザ操作をスムーズに行いにくいという問題もある。
 本発明は、斯かる事情に鑑みてなされたものであり、プリペイドカード等のプリペイド方式による前払い金を用いて、ネットワーク経由による購入を、ログインの必要なシステムに対しても行えるようにした購入システム、購入処理方法、購入対象サーバ、及びコンピュータプログラムを提供することを目的とする。
 また、本発明は、プリペイド方式に係る前払い金による購入指示操作をユーザがスムーズに行えるようにした購入システム、購入処理方法、購入対象サーバ、及びコンピュータプログラムを提供することを目的とする。
 上記課題を解決するために本発明は、ネットワークを通じて購入対象の購入機会をユーザに提供する購入対象サーバが、通信端末装置から送られる購入対象の購入指示を受信することに応じて、前記購入対象の購入処理を行う購入システムにおいて、プリペイド方式に係るユーザの前払い金に応じた情報をユーザごとに管理する前払い金管理サーバを備え、前記購入対象サーバは、前記通信端末装置から送られるユーザログイン情報を受信した場合、受信したユーザログイン情報に基づき、ユーザのログイン処理を行う手段と、ログインの完了したユーザに係る前払い金の問合せ情報を前記前払い金管理サーバへ送信する手段とを備え、前記前払い金管理サーバは、問合せ情報を受信した場合、問合せ対象となるユーザの前払い金を通知する前払い金情報を前記購入対象サーバへ送信する手段を備え、前記購入対象サーバは更に、前払い金情報を受信した場合、受信した前払い金情報で通知される前払い金を用いて前記購入対象の購入を指示する操作の受付が可能な購入画面に係る購入画面情報を生成する手段と、生成した購入画面情報を前記通信端末装置へ送信する手段とを備え、前記通信端末装置は、購入画面情報を受信した場合、受信した購入画面情報に基づき購入画面を生成して表示する手段と、表示した購入画面で、前払い金を用いて前記購入対象の購入を指示する操作を受け付けた場合、前払い金を用いて前記購入対象を購入する旨の購入指示を前記購入対象サーバへ送信する手段とを備えることを特徴とする。
 また、本発明は、ネットワークを通じて購入対象の購入機会をユーザに提供する購入対象サーバが、通信端末装置から送られる購入対象の購入指示を受信することに応じて、前記購入対象の購入処理を行う購入システムによる購入処理方法において、前記購入システムは、プリペイド方式に係るユーザの前払い金に応じた情報をユーザごとに管理する前払い金管理サーバを備えており、前記購入対象サーバは、前記通信端末装置から送られるユーザログイン情報を受信した場合、受信したユーザログイン情報に基づき、ユーザのログイン処理を行うステップと、ログインの完了したユーザに係る前払い金の問合せ情報を前記前払い金管理サーバへ送信するステップとを備え、前記前払い金管理サーバは、問合せ情報を受信した場合、問合せ対象となるユーザの前払い金を通知する前払い金情報を前記購入対象サーバへ送信するステップを備え、前記購入対象サーバは更に、前払い金情報を受信した場合、受信した前払い金情報で通知される前払い金を用いて前記購入対象の購入を指示する操作の受付が可能な購入画面に係る購入画面情報を生成するステップと、生成した購入画面情報を前記通信端末装置へ送信するステップとを備え、前記通信端末装置は、購入画面情報を受信した場合、受信した購入画面情報に基づき購入画面を生成して表示するステップと、表示した購入画面で、前払い金を用いて前記購入対象の購入を指示する操作を受け付けた場合、前払い金を用いて前記購入対象を購入する旨の購入指示を前記購入対象サーバへ送信するステップとを備えることを特徴とする。
 さらに、本発明は、ネットワークを通じて購入対象の購入機会をユーザに提供しており、外部の通信端末装置から送られる購入対象の購入指示を受信することに応じて、前記購入対象の購入処理を行う購入対象サーバにおいて、外部の通信端末装置から送られるユーザログイン情報を受信した場合、受信したユーザログイン情報に基づき、ユーザのログイン処理を行う手段と、ログインの完了したユーザに係る前払い金の問合せ情報を、プリペイド方式に係るユーザの前払い金に応じた情報をユーザごとに管理する外部の前払い金管理サーバへ送信する手段と、問合せ情報の送信に伴って、ユーザの前払い金を通知する前払い金情報を受信した場合、受信した前払い金情報で通知される前払い金を用いて前記購入対象の購入を指示する操作の受付が可能な購入画面に係る購入画面情報を生成する手段と、生成した購入画面情報を外部の通信端末装置へ送信する手段とを備えることを特徴とする。
 本発明は、前記購入対象の購入費用を、受信した前払い金情報で通知される前払い金の金額と比較する手段を備え、前記購入対象の購入費用が前払い金の金額以下である場合に、前記購入画面情報を生成するようにしてあることを特徴とする。
 また、本発明は、前記購入対象の購入費用が前払い金の金額を超える場合、前記購入対象の購入が不可である旨を示す購入不可画面に係る購入不可画面情報を生成する手段と、生成した購入不可画面情報を外部の通信端末装置へ送信する手段とを備えることを特徴とする。
 本発明は、前払い金の金額での前記購入対象の購入に対する不足額を算出する手段を備え、算出した不足額を示す購入不可画面に係る購入不可画面情報を生成するようにしてあることを特徴とする。
 また、本発明は、前記購入対象の購入不可解消に対して前払い金の入金を示す購入不可画面に係る購入不可画面情報を生成するようにしてあることを特徴とする。
 本発明は、前払い金の入金受付画面の表示に切り替える操作指示の受付が可能な購入不可画面に係る購入不可画面情報を生成するようにしてあることを特徴とする。
 また、本発明は、前記購入対象が、購入量を削減可能である場合、前記購入対象の購入不可解消に対して、前記購入対象の購入量削減を示す購入不可画面に係る購入不可画面情報を生成するようにしてあることを特徴とする。
 さらに、本発明は、前記購入対象が、購入量を削減可能である場合、前記購入対象の購入量の指定操作の受付が可能な購入不可画面に係る購入不可画面情報を生成するようにしてあることを特徴とする。
 本発明は、ネットワークを通じて購入対象の購入機会をユーザに提供する購入対象サーバが、外部の通信端末装置から送られる購入対象の購入指示を受信することに応じて、前記購入対象の購入処理を行う購入処理方法において、外部の通信端末装置から送られるユーザログイン情報を受信した場合、受信したユーザログイン情報に基づき、ユーザのログイン処理を行うステップと、ログインの完了したユーザに係る前払い金の問合せ情報を、プリペイド方式に係るユーザの前払い金に応じた情報をユーザごとに管理する外部の前払い金管理サーバへ送信するステップと、問合せ情報の送信に伴って、ユーザの前払い金を通知する前払い金情報を受信した場合、受信した前払い金情報で通知される前払い金を用いて前記購入対象の購入を指示する操作の受付が可能な購入画面に係る購入画面情報を生成するステップと、生成した購入画面情報を外部の通信端末装置へ送信するステップとを備えることを特徴とする。
 本発明は、ネットワークを通じて購入対象の購入機会をユーザに提供するサーバコンピュータに、外部の通信端末装置から送られる購入対象の購入指示を受信することに応じて、前記購入対象の購入処理を実行させるためのコンピュータプログラムにおいて、前記サーバコンピュータに、外部の通信端末装置から送られるユーザログイン情報を受信した場合、受信したユーザログイン情報に基づき、ユーザのログイン処理を行うステップと、ログインの完了したユーザに係る前払い金の問合せ情報を、プリペイド方式に係るユーザの前払い金に応じた情報をユーザごとに管理する外部の前払い金管理サーバへ送信するステップと、問合せ情報の送信に伴って、ユーザの前払い金を通知する前払い金情報を受信した場合、受信した前払い金情報で通知される前払い金を用いて前記購入対象の購入を指示する操作の受付が可能な購入画面に係る購入画面情報を生成するステップと、生成した購入画面情報を外部の通信端末装置へ送信するステップとを実行させることを特徴とする。
 本発明にあっては、購入対象サーバが、ログイン完了をトリガーにして、ログイン完了のユーザの前払い金の情報を前払い金管理サーバから取得し、その取得した情報に係る前払い金を購入費用に充てられるように、ユーザが購入指示を出すことが可能な画面をユーザに提示するので、ユーザは単に購入指示の操作を行うだけで、プリペイドカード等による前払い金で所望の対象をオンラインで購入できるようになり、独自にログインを要求するシステムに対しても前払い金による購入が可能になると共に、前払い金による購入指示操作をスムーズに行えるようになる。
 なお、本発明におけるプリペイド方式に係る前払い金としては、各種事業体が発行するプリペイドカードに応じた前払い金が該当し、さらには、銀行等の金融機関等に対して口座を開設したユーザに銀行等が発行するデビットカードは、各種商品の購入に使用可能であることから、本発明では、デビットカード(デビットカード機能を含むキャッシュカードも含む)に応じた口座の入金も、広義のプリペイド方式に係る前払い金に該当するものとする。また、本発明の購入対象としては、前払い金で購入可能なものが広く含まれることになり、例えば、各種商品、各種サービスが購入対象に該当すると共に、前払い金により所定金額を購入できる電子通貨(電子マネー)、仮想通貨等も本発明の購入対象に含まれる。
 本発明にあっては、購入費用が前払い金の金額以下である場合、ユーザが購入指示の操作を行える購入画面が提示されるようになるので、プリペイドカード等の前払い金を用いてオンラインでの購入をスムーズに行える。
 本発明にあっては、購入費用が前払い金の金額を上回る場合、購入が不可である旨を示す購入不可画面をユーザに提示するので、プリペイド方式による前払い金等では対応できないことユーザが把握できるようになり、ユーザが無用に混乱する状態になるのを回避できる。
 また、本発明にあっては、購入不可画面において購入に対する不足額が算出されて提示されるので、具体的な不足額をユーザが把握できるようになり、前払い金による購入ができないことへの対応を行いやすくなる。
 本発明にあっては、購入不可画面において、購入不可を解消できるようにするために、前払い金の追加入金といった具体的な内容が提示されるので、前払い金による購入を達成しやすくなる。
 また、本発明にあっては、前払い金の追加入金を受け付ける画面に表示を切り替えるための操作指示の受付が可能な購入不可画面に係る購入不可画面を生成するので、前払い金の追加入金をスムーズに行えるようになり、それに伴い、ユーザが所望する購入対象を前払い金で購入しやすくなる。
 本発明にあっては、ユーザの指定した購入対象が、購入量を削減可能である場合、購入不可を解消できるようにするために、購入量削減といった具体的な内容が提示されるので、前払い金による購入を達成しやすくなる。
 また、本発明にあっては、購入量を指定の操作の受付が可能な購入不可画面に係る購入不可画面情報を生成するので、ユーザが許容するときはスムーズに購入量を削減できるようになり、前払い金での購入が実行しやすくなる。
 本発明にあっては、ユーザは購入対象サーバにログインを行えば、プリペイド方式による前払い金での購入指示を出すことができるので、独自にログインを要求するシステムに対しても前払い金による購入を実現できると共に、前払い金による購入指示の操作をユーザはスムーズに行うことができる。
 また、本発明にあっては、購入費用が前払い金の金額以下である場合、ユーザが購入指示の操作を行える購入画面が提示されるので、プリペイドカード等の前払い金を用いたオンラインでの購入をスムーズに行える。
 本発明にあっては、購入費用が前払い金の金額を上回る場合、購入が不可である旨を示す購入不可画面をユーザに提示するので、プリペイド方式による前払い金等で購入できない事態についてユーザが無用に混乱するようになるのを回避できる。
 また、本発明にあっては、購入不可画面において、必要な購入額に対する不足額が提示されるので、具体的な不足額をユーザは一目で把握でき、前払い金による購入ができない状況への対応を支援できる。
 本発明にあっては、購入不可画面において、購入不可を解消できるようにするために、前払い金の追加入金といった具体的な内容が提示されるので、前払い金による購入を支援できる。
 また、本発明にあっては、前払い金の追加入金を受け付けられるようにするので、前払い金の追加入金をスムーズに行うことができ、それに伴い、一連の購入操作を途切れさせることなく、ユーザが所望する購入対象を前払い金で購入することを実現できる。
 本発明にあっては、ユーザの指定した購入対象が、購入量を削減可能である場合、購入不可画面において購入不可を解消できるようにするために、購入量の削減といった具体的な内容が提示されるので、前払い金による購入を支援できる。
 また、本発明にあっては、購入量の変更が指定できるので、購入量削減を行う場合の対応をユーザはスムーズに行える。
本発明の第1実施形態に係る購入システムの全体的な構成を示す概略図である。 前払い金管理サーバの主要な内部構成を示すブロック図である。 プリペイドDB(データベース)の一例を示す図表である。 チャージ画面の一例を示す概略図である。 購入対象サーバの主要な内部構成を示すブロック図である。 ユーザDBの一例を示す図表である。 ユーザ端末の一例であるスマートフォン(通信端末装置)の主要な内部構成を示すブロック図である。 ログイン画面を示す概略図である。 販売商品画面の一例を示す概略図である。 (a)はプリペイド使用設定画面を示す概略図であり、(b)は商品注文画面の一例を示す概略図である。 (a)は購入画面の一例を示す概略図であり、(b)は購入不可画面の一例を示す概略図である。 購入量の削減等を表記した購入不可画面の一例を示す概略図である。 商品品目の削減等を表記した購入不可画面の一例を示す概略図である。 購入完了画面を示す概略図である。 購入処理方法の処理手順を示す第1フローチャートである。 購入処理方法の処理手順を示す第2フローチャートである。 購入処理方法の処理手順を示す第3フローチャートである。 変形例の販売商品画面の一例を示す概略図である。 (a)は変形例の購入画面の一例を示す概略図であり、(b)は変形例の購入不可画面の一例を示す概略図である。 (a)は第2実施形態に係るユーザ端末の記憶内容を示す概略図、(b)は第2実施形態の購入対象サーバの記憶内容を示す概略図である。
 図1は、本発明の第1実施形態に係る購入システム1の全体的な概要の構成を示す。購入システム1は、ネットワークNWを介したオンラインによる商品(購入対象の一例に相当)の購入に要する支払いについて、プリペイド方式(例えば、プリペイドカード等の各種カード)に係る前払い金を使用できるようにしたものであり、その際、プリペイドカード等のカードIDの入力を行わなくても、プリペイドカード等の前払い金を使用可能にして、ユーザの利便性を高めたことが特徴になっている。
 本実施形態では、プリペイドカードに含まれる前払い金を用いるようにしており、プリペイド方式に係る前払い金としては、使い切りタイプ又は前払い金のチャージ可能なタイプのいずれの利用も可能であるが、前払い金を使用するユーザを、前払い金の管理を行う事業体が識別できるようになっていることが必要となる。そのため、本実施形態では、前払い金を使用するユーザを識別するにあたり、一定期間(例えば、月単位)ごとの費用(前払い金を含む費用)の徴収をユーザに対して行う事業体が発行するプリペイド方式の前払い金を用いるパターンを適用している。
 一定期間ごとの費用徴収の例としては、上下水道、電気、及びガスの使用に係る水道光熱費、固定・携帯電話機(スマートフォン含む)等及びデータ通信の使用に係る通信費、新聞・雑誌等の購入費、各種リース品のリース費、賃貸物件の賃貸費、警備会社へ支払う警備費、定期購入品の購入費等が想定でき、このような一定期間ごとの単位で支払われる費用の中に、前払い金分の金額を上乗せして徴収することにより、一定期間ごとにユーザの前払い金が確実に発生し、各種購入に前払い金を充当できる状況を作り出すことができる。
 図1に示す本実施形態では、ユーザの使用する通信機器(通信端末装置)に係る通信費の徴収を行う通信キャリア事業体が発行するプリペイドカードを用いる例となっている。通信キャリア事業体は、通信に伴う各種管理処理を行うために、通信キャリアシステム4を構築しており、このシステムの中に、ユーザのプリペイドカードの使用状態等(プリペイドカードに係る前払い金の残高等)を管理する前払い金管理サーバ5を含んでいる。前払い金管理サーバ5は、ネットワークNWを通じて、プリペイドカードに係る前払い金に応じた金額情報等を提供できるようになっている。
 また、図1に示す本実施形態では、購入対象の一例として、eコマースで販売される各種商品の場合を説明したものになっており、ユーザからの商品の購入注文を受け付けるショッピング事業会社が構築するショッピングシステム2を購入システム1は用いている。このショッピングシステム2は、ネットワークNWを通じてユーザからの商品購入の注文、指示等を受信する購入対象サーバ80等により構成される。
 また、ショッピングシステム2が構築するeコマース(オンライン)で販売される各種商品の購入機会の提供を受けるユーザ(U1、U2、U3等)は、ショッピングを利用できるようにするため、ショッピングシステム2が提供するショッピングサービスに登録しており、ユーザ登録の完了により、ショッピングシステム2からユーザIDがユーザごとに付与(発行)されている。ユーザIDが付与されたユーザが使用するユーザ端末T1、T2、T3等は、通信端末装置に相当し、具体的には、通信機能を具備するパーソナルコンピュータ(据え置き型又は携帯型のパーソナルコンピュータ)、携帯型端末(タブレット、スマートフォン、通信機能付きPDA、携帯電話等)などの通信機能を具備した一種のコンピュータ的な装置をユーザ端末として適用できる。以下、本発明の第1実施形態について詳説していく。
 図2は、通信キャリアシステム4に含まれる前払い金管理サーバ5の主要な内部構成を示している。前払い金管理サーバ5は、ユーザのプリペイドカードに応じた前払い金に係る金額情報をユーザごとに管理するものである。なお、図2では、前払い金管理サーバ5として一台のサーバ装置の態様を示すが、プリペイドカートに係る管理処理について分散処理等を行うと共に、データの管理もデータベース装置に分散させて、前払い金管理サーバ5を、複数のサーバコンピュータ及びデータベースシステム等を組み合わせて構築することも可能であり、このような複数装置で構築される場合も、本発明における前払い金管理サーバ5に相当する。なお、通信キャリアシステム4は、図示していないが、前払い金管理サーバ5の他にも、各種サーバを含んでおり、例えば、各種サーバの例としては、通信処理を担うサーバ、通信費用(プリペイドカードの前払い金を含む場合あり)の徴収(引落等)等の管理処理を担うサーバ等がある。
 本実施形態における前払い金管理サーバ5としては、一般的なサーバコンピュータを適用しており、全体的な制御及び各種処理を行うMPU5a(制御部5a)に、各種デバイス等を内部接続線5hで接続したものになっており、各種デバイス等には、通信モジュール5b、RAM5c、ROM5d、入力インタフェース5e、出力インタフェース5f、大容量記憶システム(HDDシステム)5g等がある。
 通信モジュール5bは、ネットワークNWとの接続モジュールに相当する通信デバイス(通信手段)であり、所要の通信規格に応じたものである(例えばLANモジュール)。通信モジュール5bは、所要の通信機器(図示は省略。例えばルータ等が該当)を介してネットワークNWと接続されており、ショッピングシステム2の購入対象サーバ80やユーザ端末等との通信を可能にしている。
 RAM5cは、MPU5aの処理に伴う内容、ファイル等を一時的に記憶するものであり、ROM5dは、MPU5aの基本的な処理内容を規定したプログラム等を記憶するものである。入力インタフェース5eは、通信キャリアシステム4のシステム管理者等からの操作指示等を受け付けるキーボード5i、マウス等が接続されるものであり、システム管理者等から受け付けた操作指示等をMPU5aへ伝える。出力インタフェース5fは、ディスプレイ5j(表示出力装置)が接続されるものであり、MPU5aの処理に伴う内容をディスプレイ5jへ出力し、システム管理者等が現在の処理内容等を確認できるようにしている。
 大容量記憶システム5g(記憶媒体手段に相当)は、プログラム及びデータベース(DB)等を記憶するものであり、本実施形態ではサーバシステムプログラムP1、管理プログラムP2、及びプリペイドDB(データベース)6等を記憶している。
 サーバシステムプログラムP1は、サーバ用のオペレーションシステムに応じた各種処理を規定したものであり、この規定内容に基づいた処理をMPU5aが実行することで、前払い金管理サーバ5はサーバとしての基本的な機能を果たす。管理プログラムP2の説明は後述し、先に、プリペイドDB6等の説明を行う。
 図3は、プリペイドDB6の中身の一例を示しており、通信キャリアのユーザの使用する通信機器に係る通信費の徴収を行う通信キャリア事業体は、通信機器の使用等に関してユーザと契約を結んでおり、その際、通信機器の通信量等をユーザごとに特定するため、ユーザ識別用の通信ユーザIDをユーザごとに発行しており、プリペイドDB6は、この通信ユーザIDの項目に通信PW(パスワード)、カードID(ユーザの使用するプリペイドカードを識別する識別情報)、前払い金額、及び使用履歴等の項目を対応づけて所要の情報を確保している。このように、通信ユーザIDに対応づけてユーザごとの各項目に応じた情報を格納することで、前払い金管理サーバ5(MPU5a)は、ユーザごとの各種情報を把握できることになる。
 通信キャリアのユーザは、通信キャリア事業体に対して通信機器の使用等に関する契約を行うとき、又は契約後においても、通信キャリア事業体が発行するプリペイドカードの利用を申し込み可能になっており、プリペイドカードの使用を申し込んだユーザは、毎月支払う通信費用と共に、プリペイドカードに係る前払い金(一定額)を支払うことになる。プリペイドカードの毎月の前払い金は、プリペイドカードの利用申込時に、ユーザの希望する一定金額を選択できるようになっている。
 例えば、プリペイドカードの毎月の前払い金として、1万円、2万円、3万円、5万円、10万円等のいずれかの額をユーザが選択し、この選択された額と、通信量に応じた通信費用とを加えた額を、ユーザは通信キャリア事業体に毎月支払うことになる。本実施形態で用いるプリペイドカードは、上述した仕様であることから、チャージ式のタイプとなり、また、実際にユーザへ届けられるプリペイドカードには、従来のプリペイドカードと同様に、カードIDが付されたものになっている。さらに、上述したように前払い金を月単位で支払うことに加えて、ユーザは所要時に適宜、プリペイドカードの前払い金をチャージ(入金)することも前払い金管理サーバ5は可能にしている。
 図4は、ユーザが追加でプリペイドカードの前払い金をチャージ(入金)する場合に用いるチャージ画面9の一例を示している。プリペイドカードを発行する事業体(本実施形態では、通信キャリア事業体)は、図4に示すチャージ画面9に応じたアプリケーションソフト(アプリ)をユーザの使用する通信端末装置にダウンロードできるように配布にしており、ユーザは、このようなプリペイドチャージ用のアプリを起動することで、自身の使用する通信端末装置にチャージ画面9を表示させて、所要の前払い金を適宜、追加入金する操作を行うことになる。
 チャージ画面9は、前払い金のチャージ金額指定欄9aを含むと共に、チャージボタン9b及びキャンセルボタン9cを選択可能に配置している。ユーザの通信端末装置にて、チャージ金額指定欄9aでユーザの所望する前払い金の金額を指定した状態で、チャージボタン9bの選択操作が行われると、指定した前払い金の金額でチャージを行う旨の確認画面(図示せず)が表示され、その確認画面に含まれるチャージ実行のボタンの選択操作が行われると、指定した前払い金の金額をチャージする旨のチャージ情報(ユーザの通信ユーザID等も含む情報)が前払い金管理サーバ5へ送信するように、チャージ画面9は作り込まれている。なお、チャージ画面9のキャンセルボタン9cの選択操作が行われたときは、前払い金のチャージ処理はキャンセルされて、図示しないプリペイドチャージ用のアプリのホーム画面に表示が切り替わる。
 前払い金管理サーバ5は、チャージ情報を受信すると、図3に示すプリペイドDB6において、受信したチャージ情報に含まれる通信ユーザIDに対応づけられた前払い金額及び使用履歴の項目に格納される情報を更新し、チャージ指示情報に含まれるチャージ金額を、前払い金額に反映する処理を行う。これにより、ユーザは必要に応じて、前払い金を適宜チャージできる。なお、追加的にチャージされた前払い金は、次回の通信費の徴収の際、一緒に徴収(請求)される。
 図3のプリペイドDB6の説明に戻ると、プリペイドDB6において通信ユーザIDと対応付けられる通信PW(パスワード)は、通信キャリア事業体から各種サービスの提供を受けるユーザ(登録ユーザ)が、自身で設定するパスワードを示す情報である。この通信PWは、ユーザ認証が必要な処理時に通信ユーザIDと共に使用されることになる。また、プリペイドDB6において通信ユーザIDと対応付けられるカードIDは、その通信ユーザIDに応じたユーザへ配布したプリペイドカードを識別する情報である。さらに、プリペイドDB6において通信ユーザIDと対応付けられる前払い金額は、その通信ユーザIDに応じたユーザが使用するプリペイドカードの最新の残高を示す情報になっており(前払い金の金額情報に相当)、この前払い金額は、プリペイドカードの使用、又はプリペイドカードへのチャージ(毎月の前払い金の支払い等)により随時、増減して更新される。
 そして、プリペイドDB6における使用履歴の項目には、通信ユーザIDに応じた通信キャリアのユーザがプリペイドカードを使用した履歴を示す情報が順次、時系列で格納されている。格納される情報としては、プリペイドカードの使用年月日、使用額(マイナスの金額は、プリペイドカードを用いた商品・サービス等の購入を意味し、プラスの金額は、プリペイドカードへのチャージを意味)、使用対象等が含んだものになっている。この使用履歴の項目に格納される情報は、プリペイドカードの使用先の機関・事業体に係るサーバから前払い金管理サーバ5へ送られてくる情報(購入完了の情報等)に応じたものであり、前払い金管理サーバ5のMPU5aは、このような購入完了の情報又は前払い金の入金完了等の情報を受信すると、プリペイドDB6の使用履歴の項目に格納することになる。
 次に、大容量記憶システム5gに記憶される管理プログラムP2が規定するプログラミング内容について説明する。管理プログラムP2は光ディスク等の記憶媒体を介して大容量記憶システム5gにインストールされており、管理プログラムP2が規定する処理内容としては、主に、上述した図3に示すプリペイドDB6の構築・更新等に係る処理、プリペイドカードの使用等に伴う決済関連処理があり、これらの処理についてMPU5aが行う制御内容を規定している。
 まず、プリペイドDB6の構築・更新等に係る処理としては、プリペイドカードの利用を新たに申し込んだユーザが発生し、このユーザの情報(通信ユーザID、通信PW、カードID等)が通信キャリアシステム4から前払い金管理サーバ5へ通知されると、MPU5aは、通知されたユーザの情報をプリペイドDB6へ新たに格納する処理を行うことになる。また、ユーザのプリペイドカードの使用に伴う決済処理が完了した場合、その決済処理の完了日時と共に、決済内容をプリペイドDB6の使用履歴の項目に格納する処理をMPU5aが行うことになる。
 さらに、プリペイドカードのチャージに伴う情報(通信ユーザID、使用又はチャージの金額等を示すチャージ情報)を、通信キャリアシステム4(通信費用等の徴収を行うサーバ)又はユーザの通信端末装置等から、前払い金管理サーバ5等が受信した場合、MPU5aは、その情報の受信日時と共に、受信した情報をプリペイドDB6の使用履歴の項目へ、その受信した日時に含まれる通信ユーザIDと対応づけて格納する制御処理を行うことになる。そして、MPU5aは、上述したようにプリペイドDB6の使用履歴の項目を更新した場合、それに伴い、プリペイドDB6の前払い金額の項目に格納される前払い金の額も、使用履歴の変動に合わせて、最新の額に更新する処理を行う。
 また、プリペイドカードの使用を提携している外部のサーバから、プリペイドカードの前払い金の問合せ情報(通信ユーザIDを含む情報)を、前払い金管理サーバ5が受信すると、MPU5aは、その問合せ情報に含まれる通信ユーザIDに対応付けられた前払い金額を、プリペイドDB6から特定し、その特定した前払い金額を通知する前払い金情報(通信ユーザID及び前払い金額等を含む情報)を問合せ元の外部のサーバへ送信する制御処理を行うことになる。また、外部のサーバから購入完了の情報(通信ユーザID、前払い金の使用金額等を示す前払い金使用情報)を受信すると、その情報に含まれる金額を決済するための処理をMPU5aが行う。なお、この決済完了に伴い、上述したプリペイドDB6の使用履歴の項目の更新をMPU5aは行うことになる。
 さらに、プリペイドカードの前払い金の問合せ情報を受信してから一定の時間内(例えば、30分以内、又は1~2時間以内など)に、その問合せ情報に含まれる通信ユーザIDと同じ通信ユーザIDを含むチャージ情報(プリペイドカードのチャージに伴う情報であり、通信ユーザID及びチャージ金額等を含む情報)を、ユーザの通信端末装置から受信した場合、MPU5aは、プリペイドDB6に対して、上記と同様に、チャージ金額の更新等を通信ユーザIDに対応づけて行うと共に、更新したチャージ金額(使用可能な前払い金を)を示す前払い金情報を、外部のサーバ(一定の時間前に前払い金の問合せ情報を送信してきたサーバに相当)へ送信する制御を行う。このような処理をMPU5aが行うことで、ユーザがプリペイドカードで購入を行う際に、プリペイドカードの前払い金が不足する場合を、前払い金のチャージで回避できるようになる。
 図5は、ショッピングシステム2に含まれる購入対象サーバ80を示している。この購入対象サーバ80は、ショッピングシステム2の基幹部分を構成しており、オンラインのショッピングサービス(購入対象の購入機会)をユーザに提供する上で必要な処理を行う。なお、図5では1台の購入対象サーバ80を示すに留めるが、例えば、購入対象サーバ80が行う各種処理について分散処理等を行うことで複数のサーバコンピュータ及びデータベースシステム等を組み合わせて購入対象サーバ80を構成してもよく、このような複数装置による構成の場合も、本発明における購入対象サーバ80に相当する。以下、購入対象サーバ80について説明する。
 本実施形態における購入対象サーバ80としては、一般的なサーバコンピュータを適用しており、全体的な制御及び各種処理を行うMPU80a(制御部80a)に、各種デバイス等を内部接続線80hで接続したものになっており、各種デバイス等には、通信モジュール80b、RAM80c、ROM80d、入力インタフェース80e、出力インタフェース80f、大容量記憶システム(HDDシステム)80g等がある。
 通信モジュール80bは、ネットワークとの接続モジュールに相当する通信デバイス(通信手段)であり、所要の通信規格に応じたものである(例えばLANモジュール)。通信モジュール80bは、所要の通信機器(図示は省略。例えばルータ等が該当)を介してネットワーク(ショッピングシステム2の内部ネットワーク又は外部のネットワークNW)と接続されており、ユーザ端末T1、T2、T3等及び外部の各種サーバ(通信キャリアシステ4の前払い金管理サーバ5といった各種サーバ等)との通信を可能にする。
 RAM80cは、MPU80aの処理に伴う内容、ファイル等を一時的に記憶するものであり、ROM80dは、MPU80aの基本的な処理内容を規定したプログラム等を記憶するものである。入力インタフェース80eは、ショッピングシステム2のシステム管理者等からの操作指示等を受け付けるキーボード80i、マウス等が接続されるものであり、システム管理者等から受け付けた操作指示等をMPU80aへ伝える。出力インタフェース80fは、ディスプレイ80j(表示出力装置)が接続されるものであり、MPU80aの処理に伴う内容をディスプレイ80jへ出力し、システム管理者等が現在の処理内容等を確認できるようにしている。
 大容量記憶システム80g(記憶媒体手段に相当)は、プログラム及びデータベース(DB)等を記憶するものであり、本実施形態ではシステムプログラムP10、販売プログラムP11、ユーザDB81、及び商品DB82等を記憶している。システムプログラムP10は、サーバ用のオペレーションシステムに応じた各種処理を規定したものであり、この規定内容に基づいた処理をMPU80aが実行することで、購入対象サーバ80はサーバコンピュータとしての基本的な機能を果たす。販売プログラムP11の説明は後述し、先に、ユーザDB81について説明する。
 図6は、ユーザDB81の中身の概要を示している。ユーザDB81は、ショッピングシステム2が提供するショッピングサービスに登録したユーザの各種情報を格納したデータベースであり、ユーザ登録にあわせて、ユーザを識別するユーザIDがショッピングシステム2から登録ユーザに付与されており、ユーザDB81では、付与されたユーザIDに対応付けて各種情報を格納している。具体的にユーザDB81は、ユーザIDごとに、ユーザの氏名、住所、電話番号、メールアドレス、UID(ユーザ端末の識別情報)、職業、PW(パスワード)等を記憶している。なお、本実施形態では、登録されたメールアドレスをログイン時のログインIDとして用いており、また、PWはユーザ登録時にユーザ自身が設定した英数字情報を用いている。
 また、ショッピングシステム2が提供するショッピングサービスを運営する事業会社(事業体)は、通信キャリアシステム4を運営する通信キャリア事業体が提供するプリペイドカードサービスと提携しており、この通信キャリア事業体が発行するプリペイドカードを用いて、上記のショッピングサービスで販売される各種商品(購入対象)を購入できるようにしている。
 そのため、ショッピングサービスへのユーザ登録を行う際、又はユーザ登録後に、通信キャリア事業体のプリペイドカードの使用を申し込んだユーザについて、プリペイドカードの使用に必要な情報もユーザDB81に格納するようにしている。ユーザDB81において、プリペイドカードの使用に必要な情報の項目としては、ユーザ端末でプリペイドカードの使用を設定したことを示すカード使用の項目、そのユーザが通信キャリア事業体から発行された通信ユーザID、及びそのユーザが使用するプリペイドカードのカードIDを格納する項目等があり、これらの項目に応じた情報がユーザIDに対応付けられて格納される。
 ユーザ登録時にショッピングサービスを提供する事業体へプリペイドカードの使用を申し込むユーザについては、ユーザに関する情報と共に、上述したプリペイドカードに関連する通信ユーザID、カードID、及びカード設定の内容等を示す情報(プリペイドカードに関する情報)が、ショッピングシステム2へユーザから提供することで、ユーザの提供した情報がユーザIDに対応づけてユーザDB81に格納される。このように、ユーザ登録時にプリペイドカードの使用申し込みが行われると、ユーザ端末から通信ユーザID及びカードID等を通知するカード使用情報が購入対象サーバ80へ送信されてくるので、MPU80aは、受信したカード使用情報に含まれる通信ユーザID等をユーザIDと対応づけてユーザDB81に格納する処理を行う。
 なお、ショッピングサービスの登録ユーザが、通信キャリア事業体に、自身のプリペイドカードに関する情報を、ショッピングサービスを運営する事業体に提供することを依頼することで、通信キャリア事業体がショッピングサービスの運営事業体に、依頼のあったユーザのプリペイドカードに関する情報を提供して、ユーザDB81に格納することも可能である。また、本実施形態では、通信キャリア事業体にプリペイドカードの使用を申し込んだだけでは、ショッピングサービスにプリペイドカードを使用することができず、後述する図10(a)のプリペイド使用設定画面17等でプリペイドカードの使用を設定することで、ショッピングサービスにプリペイドカードの使用が可能となる。
 ユーザDB81に格納されるユーザ情報も適宜更新されており、新たにユーザがショッピングサービスに登録すると、その新たなユーザに関する情報がユーザDB81に追加され、また、ユーザ登録を解除すると、そのユーザに関する情報はユーザDB81から削除される。
 また、大容量記憶システム80gに記憶される商品DB82は、ショッピングサービスで販売される多数の商品の情報を格納したデータベースになっており、商品を識別する商品IDに対応付けて、商品名、商品に関する情報(各種仕様など)、商品の画像、単価、在庫数等の各種情報を格納したものになっている。
 次に、購入対象サーバ80の大容量記憶システム80gに記憶される販売プログラムP11が規定する処理内容について説明する。本実施形態の販売プログラムP11は、光ディスク等の記憶媒体を介して大容量記憶システム80gにインストールされており、ユーザのログイン、商品購入(ショッピング)、及びプリペイドカードの使用等に関してMPU80aが実行する各種制御処理等を規定したものになっている。
 先ず、ユーザのログインについて、ユーザ端末から送信されてきたユーザのメールアドレス及びパスワードを含むユーザのログイン情報(ユーザ端末のUID等が含まれていてもよい)を通信モジュール80bで受信すると、受信したログイン情報(ユーザログイン情報)について、図6のユーザDB81の中に一致する情報が格納されているか否かを判断する処理(ログイン処理)をMPU80aが行うことを販売プログラムP11は規定する。
 受信したログイン情報(ユーザログイン情報)がユーザDB81に格納されていないと判断した場合、ログイン情報不一致の旨を示すログイン不可情報をログイン情報の送信元のユーザ端末へ通信モジュール80bを用いて送信する制御をMPU80aが行うことを販売プログラムP11は規定する。一方、受信したログイン情報がユーザDB81に格納されていると判断した場合、そのログイン情報に応じたユーザIDについてログイン完了として、そのユーザIDをログイン中の状態に設定し、ログイン中の状態であることを示すログイン状態情報をRAM80c等に記憶すると共に、ログインが完了したユーザのユーザ端末へログイン完了の旨を示すログイン完了情報の送信処理をMPU80aが行うことになる。なお、ログイン状態情報は、ユーザ端末からのログオフ情報を受信するまで、RAM80cにユーザIDと共に記憶されることなる。
 ログイン状態となったユーザについては、図6に示すユーザDB81の「カード使用」の項目に、「使用」という情報が格納されているか否かを判定する処理をMPU80aは行う。「使用」の情報が格納されている場合、そのログイン中のユーザ(ログインの完了したユーザ)のプリペイドカードの前払い金を問い合わせる問合せ情報(通信ユーザID及びカードIDを含む情報)を、通信キャリアシステム4の前払い金管理サーバ5へ送信する処理をMPU80aは行う。なお、前払い金管理サーバ5へ情報を送るためのアドレス情報は、事前にショッピングシステム2へ通知されて、購入対象サーバ80の大容量記憶システム80gに記憶されているものとし、MPU80aは、この記憶されたアドレス情報に基づき、前払い金管理サーバ5へ各種情報を送信する。
 そして、問合せ情報の送信に伴って、前払い金管理サーバ5から、問合せ対象のユーザの前払い金を通知する前払い金情報を受信すると、受信した前払い金情報を、RAM80cに、そのユーザのログイン状態情報と対応づけて記憶する処理をMPU80aは行うことになる。
 なお、ユーザDB81の「カード使用」の項目に、「使用」の情報が格納されていなければ、MPU80aは上記の問合せ情報の送信処理を行わない。また、プリペイドカードを使用する旨のプリペイド使用情報をユーザ端末から購入対象サーバ80が受信すると、そのプリペイド使用情報に含まれるユーザIDに対応づけて、ユーザDB81の「カード使用」の項目に、「使用」という情報を格納する処理をMPU80aは行う。そして、「使用」という情報を格納したユーザIDに対応づけて既に、ユーザDB81の「通信ユーザID」、及び「カードID」の各項目に情報が格納されていれば、カード使用可能を通知するカード使用可能情報を、プリペイド使用情報を送信してきたユーザ端末へ送信する処理をMPU80aは行う。
 一方、「使用」という情報を格納したユーザIDに対応付けられる「通信ユーザID」、及び「カードID」の各項目に未だ情報が格納されていない場合、MPU80aは、カード設定に関する情報を要求する旨のカード設定要求情報を、プリペイド使用情報の送信元のユーザ端末へ送信する処理をMPU80aは行う。なお、このカード設定要求情報の送信に応じて、ユーザ端末から送られてきたカード設定情報を購入対象サーバ80が受信すると、そのカード設定情報に含まれるユーザIDに対応づけて、ユーザDB81の「通信ユーザID」、及び「カードID」の各項目に、カード設定情報に含まれる通信ユーザID、及びカードIDの情報を格納する処理をMPU80aは行うと共に、カード使用可能情報をユーザ端末へ送信する制御処理をMPU80aは行う。
 また、プリペイドカードを使用しない旨のプリペイド不使用情報をユーザ端末から購入対象サーバ80が受信すると、そのプリペイド不使用情報に含まれるユーザIDに対応づけて、ユーザDB81の「カード使用」の項目に、「不使用」という情報を格納する処理をMPU80aは行うと共に、プリペイド不可情報をユーザ端末へ送信する制御処理をMPU80aは行う。このようにユーザ端末から送られてくる情報により、プリペイドカードの使用又は不使用の設定は随時、変更可能であり、このような変更に伴い、ユーザDB81におけるプリペイドカードに関する項目(カード使用、通信ユーザID、カードID)に格納される情報も適宜更新される。
 購入対象サーバ80が、ログイン中のユーザのユーザ端末から、後述する商品情報要求(商品ID等の情報を含む要求)を受信した場合、受信した商品IDに対応付けられた商品情報(商品の画像、商品の仕様、単価等を示す情報)を、商品DB82から読み出して、商品情報要求の送信元のユーザ端末へ送信する処理をMPU80aが行うことになる。
 また、購入対象サーバ80が、ログイン中のユーザのユーザ端末から、購入対象となる商品ID、購入量、及び購入金額(購入量に単価を乗じた額)を指定する購入注文情報を受信した場合、MPU80aは、受信した購入注文情報をRAM80cに一旦記憶すると共に、その購入注文情報を送ってきたユーザ端末のユーザがプリペイドカードの使用を設定しているか否かを判断する。この判断は、ユーザDB81の中の「カード使用」の項目に「使用」の情報が格納されているか否かで判断される。
 購入注文情報を送信したユーザ端末のユーザがプリペイドカードの使用を設定していないと判断した場合、MPU80aは、購入注文情報に係る購入金額を特定して、クレジットカード又は銀行振込等で購入代金の支払い決済を依頼する旨の情報をユーザ端末へ送信することになる。
 また、購入注文情報を送信したユーザ端末のユーザがプリペイドカードの使用を設定していると判断した場合、MPU80aは、受信した購入注文情報に含まれる購入金額を、RAM80cに、ログイン中のユーザIDと対応づけて記憶されている前払い金情報で示される前払い金の金額と比較して、購入金額が前払い金の金額を超えるか否かをMPU80aは判断する。購入金額が前払い金の金額を上回る場合、購入資金が不足するので、その不足額を算出し、受信した購入注文情報に係る内容では購入不可であるとMPU80aは判断する。
 購入不可と判断した場合、MPU80aは、購入不可である旨を示す購入不可画面をユーザ端末で表示されるようにするための購入不可画面情報を生成して、購入注文情報を送信してきたユーザ端末へ送信する処理を行うことになる。この生成される購入不可画面情報は、購入不可である旨を示すテキスト情報を含むと共に、ユーザの選択した商品の購入に対する不足額に加えて、購入に対する不足額の解消に対する情報を含んだ購入不可画面に応じたものとなっている。不足額を解消するための情報としては具体的に、プリペイドカードへのチャージ(前払い金の追加)を示す表記に応じた情報(テキスト情報)等が相当する。
 前払い金の不足をスムーズに解消できるように、プリペイドカードへのチャージについて、MPU80aは、前払い金のチャージ受付画面の表示に切り替える指示操作の受付が可能な購入不可画面に係る購入不可画面情報を生成するようにしている。具体的には、図4に示すチャージ画面9に係るアプリの起動を行うリンク指示を含む購入不可画面情報をMPU80aは生成することになる。
 さらに、購入不可と判断した場合で、購入注文情報に含まれる商品の識別情報(商品ID)が複数あるとき(商品品目が複数あるとき)、MPU80aは、購入不可への対応情報として、プリペイドカードへのチャージに加えて、購入対象となる商品の品目の削減を示す表記を含ませると共に、商品の品目削減の操作の受付が可能な購入不可画面に係る購入不可画面情報を生成して、購入注文情報を送信してきたユーザ端末へ送信する処理を行うことになる。この場合に生成される購入不可画面情報は、上述した表記に応じた情報(テキスト情報)、及び商品の品目削減の操作受付を可能にする情報(品目削減指示情報)を含んだものになっている。
 さらにまた、購入不可と判断した場合で、購入注文情報に含まれる商品の購入量が複数のため購入量の削減が可能であるとき、MPU80aは、不足額を解消するための情報として、プリペイドカードへのチャージに加えて、購入対象となる商品の購入量の削減を示す表記を含ませると共に、購入量の指定操作(削減を指定する操作)の受付が可能な購入不可画面に係る購入不可画面情報を生成して、購入注文情報を送信してきたユーザ端末へ送信する処理を行うことになる。この場合に生成される購入不可画面情報は、上述した表記に応じた情報(テキスト情報)、及び商品の購入量数削減の操作受付を可能にする情報(購入量削減指示情報)を含んだものになっている。
 一方、購入金額が前払い金の金額を上回らずに、前払い金の金額以下であると判断した場合、前払い金で購入可能とMPU80aは判断し、前払い金情報で通知される前払い金を用いて前記購入対象の購入を指示する操作の受付が可能な購入画面に係る購入画面情報を生成し、ユーザ端末へ送信する処理を行う。なお、購入画面情報は、前払い金を用いてユーザの指定した商品の購入を確認する内容(ユーザが複数の購入量、又は複数種類の商品の品目を指定する場合は、それらも併せて確認するテキスト内容)等を含むものになっている。
 なお、購入不可と判断して購入不可画面情報をユーザ端末へ送信した場合であっても、その購入不可画面情報の送信から一定の時間内(例えば、30分以内、又は1~2時間以内など)に、購入不可画面情報を送信したログイン中のユーザについての前払い金情報(通信ユーザID及び使用可能な前払い金額等を含む情報)を前払い金管理サーバ5から新たに受信すると、MPU80aは、RAM80cに記憶されている購入注文情報に含まれる購入金額を、新たに受信した前払い金情報に含まれる使用可能な前払い金の金額と比較して、購入金額が前払い金の金額を超えるか否かを判断する。そして、購入金額が前払い金の金額以下であると判断した場合、前払い金で購入可能になったとMPU80aは判断し、購入画面情報を生成してユーザ端末へ送信する処理を行う。
 上述した内容の購入画面情報を送信したことに伴って、ユーザ端末から送られてきた購入指示を購入対象サーバ80は受信すると、MPU80aは、受信した購入指示に応じた購入処理を実行する。そして、購入処理が完了すると、MPU80aは、ユーザの指定した商品の購入が完了した旨を通知する購入完了情報を、購入指示を送信してきたユーザ端末へ送信する処理を行う。また、完了した購入処理において、前払い金を使用した場合は、前払い金の使用金額をMPU80aが特定し、その特定した前払い金の使用金額を通知する前払い金使用情報(通信ユーザIDを含む情報)を前払い金管理サーバ5へ送信する処理を行う。
 図7は、通信キャリアシステム4が提供する通信キャリアを使用するユーザ端末(T1、T2、T3等)の一例であるスマートフォン10(通信端末装置)の主要な内部構成を示している。スマートフォン10は、プログラムに従って各種処理を行う一種のコンピュータ(通信手段及び記憶手段を具備したコンピュータ)に該当する。スマートフォン10は、全体的な制御及び各種処理を行うCPU10a(プロセッサ10a)に、内部接続線10iを介して、通信・通話モジュール10b(通信手段に相当)、RAM10c、ROM10d、入出力インタフェース10e、操作部10h、記憶部(記憶手段に相当)10g等の各種デバイス等を接続したものになっている。なお、ユーザ端末がスマートフォン以外の通信端末装置であっても(通信機能を有するコンピュータ、又はタブレット等)、基本的な構成は、図7に示すものと同等になるので、図7は、ユーザ端末のあらゆる種類の通信端末装置の概要を示すものになる。
 スマートフォン10の通信・通話モジュール10bは、ネットワークを介した無線通信処理に加えて、CPU10aの制御に従って所定の電話番号へ電話をかける機能(発呼機能)及び電話を受ける機能(着呼機能)等を有する。RAM10cは、CPU10aの処理に伴う内容、ファイル,データ、情報等を一時的に記憶するものである。ROM10dは、CPU10aの基本的な処理内容を規定したプログラム等を記憶すると共に、スマートフォン10を識別する識別情報(UID)等も格納している。なお、このUIDは、上述した通信・通話モジュール10bで通信(送信)する際、送信内容に含まれるようになっている(例えば、送信パケットのヘッダ等にUIDを含めて送信が行われる)。
 入出力インタフェース10iは、タッチパネル機能を具備したディスプレイ10fを接続しており、CPU10aの制御処理により生成された各種画面(図8~14等に示す画面参照)をディスプレイ10fに出力する処理を行い、それにより、出力した画面内容がディスプレイ10fに表示されることになる。また、入出力インタフェース10eは、ディスプレイ10fの表面をユーザがタッチすることで受け付けた操作内容をCPU10aへ送る処理も行う。なお、ユーザがディスプレイ10fの表面をタッチすることで受け付ける操作内容は、表示している画面内容に応じて適宜、変化する。
 操作部10hは、スマートフォン10の筐体に設けられたハードボタンであり、操作部10hが操作されると、操作された旨がCPU10gに伝えられる。操作部10hの操作による意味合いは、スマートフォン10の処理状況により様々なものになり、例えば、アプリを起動している状況で、操作部10hが操作されると、アプリを終了する動作が行われるので、この場合、操作部10hの操作は、アプリの終了指示をユーザから受け付けることになる。本発明の場合、後述するように、ショッピングサービス用のショッピングアプリP21(記憶部10gにインストールされているもの)を用いるので、ショッピングアプリP21を起動している状態で、操作部10hが操作されると、ショッピングアプリP21の終了指示をスマートフォン10が受け付けたことになって、ショッピングアプリP2のログオフ指示がショッピングシステム2へ送信されることになる。
 記憶部10gは、OSプログラムP20、ショッピングアプリP21、及びその他の各種アプリ等(例えば、図4のチャージ画面9に応じたプリペイドチャージ用のアプリ等)のプログラムを記憶(インストール)している。OSプログラムP20は、オペレーティングシステムに相当する基本プログラムであり、スマートフォン10が一種のコンピュータとして機能するためのCPU10aの処理を規定している。OSプログラムP20が規定する基本的な処理の一つとしては、スマートフォン10が使用できる状態になったときに、最初にディスプレイ10fにホーム画面を表示することが挙げられ、このホーム画面においては、記憶部10gにインストールされている各種アプリに応じたアイコン等を配置することも、OSプログラムP20の規定する処理によるものとなる。
 記憶部10gに記憶されるショッピングアプリP21は、ショッピングシステム2が提供するオンラインのショッピングサービス用のアプリケーションプログラム(コンピュータプログラム)であり、購入対象となる各種商品の購入機会として、販売商品画面、商品注文画面、購入画面等をユーザ端末に表示させて、表示されている画面におけるユーザ操作に伴う指示等をショッピングシステム2へ送信する処理等に応じた各種制御をCPU10aが行うことを規定する。このような規定内容により、CPU10aは各種画面の生成手段等として機能する。なお、ショッピングアプリP21は、処理を規定したプログラムコードに加えて、各種画面の中で配置する各パーツ(ボタン等)に応じた画面データ、及び各種表記に応じたテキスト情報等も含んでいる。
 ダウンロード又は記憶媒体等を通じてスマートフォン10に取得されたショッピングアプリP21は、記憶部10gへインストールされてインストールが完了すると、OSプログラムP20に基づくホーム画面の中に、ショッピングアプリP21を起動させるためのショッピングアイコンが選択可能に配置されることになる。そして、このショッピングアイコンを選択するユーザ操作をスマートフォン10が受け付けると、そのときに既にログイン状態であれば、購入対象となる各種商品を複数の中から指定できる購入機会をユーザに提供するための販売商品画面等をディスプレイ10fに表示し、ログイン状態でなければ、CPU10aは、ログイン用の画面を生成してディスプレイ10fに表示する処理を行う。
 図8は、ディスプレイ10fに表示されるログイン画面15の一例を示し、CPU10aの処理により、ログイン画面用の画面データに基づき生成される。ログイン画面15は、メールアドレス入力欄15a、パスワード入力欄15b、及び選択可能なログインボタン15cを配置している。このように配置された各部に応じたパーツのデータも、ログイン画面用の画面データは含んでいる。ログイン画面15を表示した状態で、上述したOSプログラムP20が規定する処理に応じた機能により、ディスプレイ10fにソフトキーボード14を表示し、このソフトキーボード14に含まれる各キーをユーザが適宜操作することで、各入力欄15a、15bに所定の内容を入力していくことになる。なお、入力するパスワードは、ショッピングサービスへのユーザ登録時に、ユーザごとに定められたものである。
 そして、各入力欄15a、15bへ所定の内容が入力された状態で、ログインボタン15cの選択操作をスマートフォン10が受け付けると、入力された内容がユーザのログイン情報として、ショッピングシステム2へ向けて送信されるように作り込みされており、このような作り込みの内容等を規定したデータ(スクリプト系言語等で記載されたデータ)も、ログイン画面用の画面データに含まれる(このような選択可能なボタンに関する内容は、他の画面データでも同様である)。上記のようなログイン画面15を介したログイン情報の送信に応じて、ショッピングシステム2(購入対象サーバ80)からログイン不可情報をスマートフォン10が受信すれば、再度の入力機会を確保するために、パスワードが一致しなかった旨を示すログイン画面(構成的には図8と同等のもの)をディスプレイ10fに表示する処理をCPU10aは行う。
 図9は、ディスプレイ10fに表示される販売商品画面16の一例を示し、ログインが完了して、購入対象サーバ80から送られるログイン完了情報をスマートフォン10が受信したことに基づき表示されるものである。販売商品画面16は、購入対象となる各種商品を示す商品画像16a~16fがサムネイル的に選択可能に配置する。このように提示される商品は、図9が示すように、多様なカテゴリーに属するものであってもよいし、一つの商品カテゴリー内の種々の商品であってもよい。なお、図9では、計六つの商品画像16a~16fを表した状態を示すが、販売商品画面16に対してスクロール操作等を行うことで、販売商品画面16は六以上の商品画像の閲覧が可能になっている。また、販売商品画面16は、画面右上に設定ボタン16gを選択可能に配置しており、この設定ボタン16gの選択を受け付けると、ショッピング機能に関する各種設定用のメニュー項目が、項目ごとに選択可能に表示されるようになっている(図示せず)。設定ボタン16gに応じたメニュー項目の中には、プリペイドカードの使用設定に関する項目が含まれている。
 図10(a)は、プリペイド使用設定画面17の一例を示し、上述した設定ボタン16gに応じたメニュー項目の中のプリペイドカードの使用設定に関する項目の選択操作を受け付けた場合に、CPU10aの制御によってディスプレイ10fに表示される画面になっている。プリペイド使用設定画面17は、選択可能なプリペイド使用選択欄17a及びプリペイド不使用選択欄17bを含み、各選択欄17a、17bは、いずれか一方のみが選択可能となっている。また、プリペイド使用設定画面17は、OKボタン17c及び戻るボタン17dを選択可能に有しており、戻るボタン17dの選択操作を受け付けると、図9の販売商品画面16にディスプレイ10fの表示を切り替える処理をCPU10aは行う。
 また、プリペイド使用選択画面17で、プリペイド使用選択欄17aが選択された状態で、OKボタン17cの選択操作をスマートフォン10が受け付けると、プリペイド使用情報を購入対象サーバ80へ送信する処理をCPU10aが行うことになる。そしてプリペイド使用情報の送信に応じて、購入対象サーバ80から送られるプリペイド使用可能情報をスマートフォン10が受信すると、プリペイドカードの使用設定が完了したことになり、CPU10aは、ディスプレイ10fの表示を図9の販売商品画面16に切り替える処理を行う。
 一方、プリペイド使用情報の送信に応じて、購入対象サーバ80から送られるカード設定要求情報をスマートフォン10が受信した場合、プリペイドカード発行元の通信キャリア事業体が付与する通信ユーザIDの入力欄、プリペイドカードのカードIDの入力欄、及びOKボタン等を有するカード情報入力画面(図示せず)がディスプレイ10fに表示する処理をCPU10aは行う。そして、カード情報入力画面で各ID等の必要な情報が入力された状態でOKボタンの選択操作が行われた場合、入力された情報を購入対象サーバ80へ送信してプリペイドカードの使用設定を完了し、それから、CPU10aは、ディスプレイ10fの表示を図9の販売商品画面16に切り替える処理を行う。
 また、図10(a)のプリペイド使用設定画面17で、プリペイド不使用選択欄17bが選択された状態で、OKボタン17cの選択操作をスマートフォン10が受け付けると、プリペイド不使用情報を購入対象サーバ80へ送信する処理をCPU10aが行う。そして、プリペイド不使用情報の送信に応じて、購入対象サーバ80からプリペイド不可情報をスマートフォン10が受信すると、プリペイドカードが使用不可の状態に設定されたことになり、それからCPU10aは、ディスプレイ10fの表示を図9の販売商品画面16に切り替える処理を行う。このようにプリペイドカードの使用又は不使用の設定切り替えを、本実施形態ではユーザ端末側で適宜行えるようにしてユーザの利便性を高めている。
 図10(b)は、図9の販売商品画面16で、左上の商品画像16aの選択操作を受け付けたことに伴って、ディスプレイ10fに表示される商品注文画面18を示す。図9の販売商品画面16は、商品画像16a~16fの選択操作を受け付けると、選択操作対象となった商品画像16a~16fに係る商品について、商品情報要求を購入対象サーバ80へ送信するように作り込まれている。スマートフォン10は、商品情報要求の送信に応じて、購入対象サーバ80から送られてくる商品情報を受信すると、受信した商品情報をRAM10cに一時的に記憶すると共に、その商品情報に基づき図10(b)に示す商品注文画面19を生成して表示する処理をCPU10aが行う。
 商品注文画面18は、図9に示す商品画像16aより大きいサイズの詳細商品画像18a、商品詳細情報18b(商品名、型番、価格、商品に関する説明等を記したテキスト情報)を含むと共に、商品の購入量(購入数)の指定が可能な購入量指定欄18c、カートに入れるという文言を記したカートボタン18d、購入に進むという文言を記した購入注文ボタン18e、及び戻るボタン18fを選択可能に配置している。購入量指定欄18cは、ユーザの希望する購入量(購入数)を指定する操作を受け付けるものとなっている。
 上記のような構成の商品注文画面18をユーザに提示することで、ユーザは商品の詳細を確認することができ、確認の結果、商品を購入しないと判断した場合、ユーザは、戻るボタン18fの選択操作を行うことになる。戻るボタン18の選択操作をスマートフォン10が受け付けると、CPU10aはディスプレイ10fの表示を図9の販売商品画面16に切り替える処理を行う。
 また、ユーザが商品注文画面18の画面内容を確認した結果、商品注文画面18に示される商品を購入のために確保しておきたいと判断した場合、ユーザは、カートボタン18dの選択操作を行うことになる。なお、商品の購入量を複数確保することを希望する場合、ユーザは、購入量指定欄18cを操作して、所望の購入量(購入数)を指定してから、カートボタン18dの選択操作を行うことになる。そして、カートボタン18dの選択操作をスマートフォン10が受け付けると、CPU10aは、商品注文画面18で示される商品に応じた商品ID、価格、及び指定されている購入量などを、RAM10cに商品確保情報として一時的に記憶する処理を行うと共に、ディスプレイ10fの表示を図9の販売商品画面16に切り替える処理を行う。このような処理をCPU10aが行うことで、ユーザは、所望の商品を確保した上で、他の商品の購入(ショッピング)を続けて行う機会を持てることになる。
 さらに、ユーザが商品注文画面18の画面内容を確認した結果、商品注文画面18に示される商品を購入すると判断した場合、ユーザは、購入注文ボタン18eの選択操作を行うことになる。購入注文ボタン18の選択操作をスマートフォン10が受け付けると、CPU10aは、商品注文画面18で示される商品に応じた商品ID、価格(購入に必要な金額)、及び指定されている購入量などを一旦、商品確保情報として整理してRAM10cに記憶してから、この商品確保情報の内容に応じた購入注文情報を生成し、生成した購入注文情報を購入対象サーバ80へ送信する処理を行う。
 図11(a)は、ディスプレイ10fに表示される購入画面19の一例を示し、上述した購入注文情報の送信に伴って、購入対象サーバ80から送信されてきた購入画面情報をスマートフォン10が受信した場合に表示される画面であり、プリペイドカードによる前払い金で、商品の購入が可能であると購入対象サーバ80で判定された場合に表示されるものになっている。購入画面19は、画面上部に、購入対象となる商品の情報19a(商品名、単価、購入量など)を示すと共に、その下方にプリペイドカードにより商品の購入が可能である旨を示す購入可能情報19bを配置し、購入可能情報19bの下方に購入ボタン19c、購入キャンセルボタン19d、買い物を続けるという文言を記した買い物継続ボタン19e(カートに入れるボタンに相当)を選択操作可能に配置している。
 スマートフォン10が、購入ボタン19cの選択操作を受け付けた場合、購入画面19に含まれる購入可能情報19の内容に従い、プリペイドカードの前払い金を用いてユーザの指定した商品(購入対象)の購入指示操作を受け付けたことになり、前払い金を用いて商品を購入する旨の購入指示を購入対象サーバ80へ送信する処理をCPU10aが行うことになる。
 図14は、ディスプレイ10fに表示される購入完了画面23の一例を示し、購入指示を購入対象サーバ80へ送信することに応じて、購入対象サーバ80から購入完了情報をスマートフォン10が受信した場合に表示される画面になっている。購入完了画面23は、購入が完了した旨を示すテキスト部23a、及び販売商品画面16へ戻る旨の文言を記した戻るボタン23bを含んでおり、テキスト部23aの内容により、ユーザは無事、購入が完了したことが把握できるようになっている。また、戻るボタン23bの選択操作が行われると、RAM10cに一時的に記憶されていた商品確保情報等が削除されて、図9の販売商品画面16にディスプレイ10fの表示を切り替える処理をCPU10aが行うようにしている。
 また、図11(a)に示す購入画面19において、スマートフォン10が、購入キャンセルボタン19dの選択操作を受け付けた場合、購入指示がキャンセルされたことなり、RAM10cに一時的に記憶されていた商品確保情報等を削除して、図9の販売商品画面16にディスプレイ10fの表示を切り替える処理をCPU10aが行う。このような処理をCPU10aが行うことで、ユーザが一旦購入しようとしていた商品を、購入確認の段階でもキャンセル可能にすると共に、図9の販売商品画面16でユーザが引き続き商品の選定作業をスムーズに行えるようにしている。
 さらに、図11(a)に示す購入画面19において、スマートフォン10が、買い物継続ボタン19eの選択操作を受け付けた場合、CPU10は、RAM10cに一時的に記憶されていた商品確保情報等を削除することなく、図9の販売商品画面16にディスプレイ10fの表示を切り替える処理をCPU10aが行う。このようにすることで、ユーザの購入希望商品を確保しながら、ユーザが他の商品の選定も引き続き行えるようにしている(複数の商品品目の購入が可能となる)。
 一方、図11(b)は、ディスプレイ10fに表示される購入不可画面20の一例を示し、上述した購入注文情報の送信に伴って、購入対象サーバ80から送信されてきた購入不可画面情報をスマートフォン10が受信した場合に表示される画面であり、プリペイドカードによる前払い金では、商品の購入が不可能であると購入対象サーバ80で判定されたときに表示されるものになっている。購入不可画面20は、画面上部に、購入対象となる商品の情報20a(商品名、単価、購入量など)を示すと共に、その下方にプリペイドカードの前払い金では商品の購入が不可である旨を示す購入不可情報20bを配置している。
 この購入不可情報20bが含む具体的な情報としては、前払い金では商品購入が不可である旨に加えて、購入不可画面情報に含まれている不足額(図11(b)の例では、3000円)が記されると共に、購入不可解消のための対応の仕方も記されている。図11(b)に示す例では、対応の仕方として、プリペイドカードへのチャージ(前払い金の入金)が示されている。購入不可情報20bは、上述した内容を記すので、プリペイドカードによる購入が不可である状況をユーザは確認できると共に、購入不可の対応の仕方も容易に把握することできる。
 また、購入不可画面20は、購入不可情報20bの下方に、購入キャンセルボタン20d、及びチャージボタン20eを選択可能に配置している。購入キャンセルボタン20dは、プリペイドカードによる購入をユーザが諦めた場合に選択操作されるものであり、図11(a)の購入画面19に含まれる購入キャンセルボタン19dと同様に、スマートフォン10が、購入キャンセルボタン20dの選択操作を受け付けた場合、購入指示がキャンセルされたことなり、RAM10cに一時的に記憶されていた商品確保情報等を削除して、図9の販売商品画面16にディスプレイ10fの表示を切り替える処理をCPU10aが行う。
 チャージボタン20eは、購入不可情報20bに示された対応の仕方に従って、プリペイドカードへのチャージ(前払い金の入金)を行うことをユーザが決断した場合に選択操作されるものである。チャージボタン20eは、図4のチャージ画面9に応じたプリペイドチャージ用のアプリの起動にリンクしており、チャージボタン20aの選択操作を受け付けると、プリペイドチャージ用のアプリを起動させて、図4のチャージ画面9(前払い金の入金受付画面)にディスプレイ10fの表示を切り替えさせる処理をCPU10aが行うことになる。
 図4のチャージ画面9において、購入不可を解消するため、ユーザは、チャージ金額指定欄9aに、図11(b)の購入不可画面20の購入不可情報20bに示された不足額以上の金額を指定して、チャージボタン9bの選択操作を行うことになる。このようなチャージボタン9bの選択操作により、CPU10aは、チャージ情報を前払い金管理サーバ5へ送信する制御を行うことになる。また、このチャージ情報の送信に応じて、購入対象サーバ80から購入画面情報を受信すると、図11(a)に示す購入画面19にディスプレイ10fの表示を切り替える制御を行うことになり、この後は、上述した場合と同様に、購入ボタン19cの選択操作を行えば、ユーザの指定した商品を購入できる。このように本実施形態では、プリペイドカードの前払い金が不足する場合は、一連の購入操作処理の中で、適宜、チャージ可能にしていることから、一旦、購入不可になっても、その購入不可を解消して、プリペイドカードによる購入を完了できる。
 また、図12は、ディスプレイ10fに表示される購入不可画面21の一例を示し、購入対象の商品の購入量が複数(図12の場合、購入量は「3」)になっている点が、図11(b)に示す購入不可画面20の場合と異なる。すなわち、図12の購入不可画面21は、画面上部に、購入対象となる商品の情報20a(商品名、単価など)を示すと共に、その下方に購入量指定欄21bを含み、さらに、購入量指定欄21bの下方には、プリペイドカードの前払い金では商品の購入が不可である旨を示す購入不可情報21cを配置し、その下方に、再計算ボタン21d、チャージボタン21f、及び購入キャンセルボタン21gを配置している。
 図12の購入不可画面21は、商品の購入量が「3」であり、購入量の削減が可能であることから、図11(b)の購入不可画面20の表示に応じた購入不可画面情報の内容に、購入不可の解消の仕方として購入対象となる商品の購入量の削減を示す情報が含まれると共に、購入量削減指示情報を含んだものになっており、このような内容の購入不可画面情報をスマートフォン10が受信することで、この購入不可画面情報に含まれる購入量削減指示情報に基づき、図12に示すように、商品の情報20aの下方に購入量指定欄21bを配置すると共に、購入付加情報20bの下方に再計算ボタン21dを配置した購入不可画面21をCPU10aは生成する処理を行っている。また、購入不可画面21が含む購入不可情報21cは、図11(b)の購入不可画面20が含む購入不可情報20bの内容に、購入不可解消のための対応の仕方として、購入量の削減を追加したものになっている。
 購入不可画面21が有する再計算ボタン21dは、購入量指定欄21bに指定される数値が、最初にディスプレイ10fに表示された状態から削減されていない場合は、選択操作が不可の状態(アクティブでない状態)になっており(図12において破線で示す状態)、購入量指定数欄21bの数量を、最初の数値から削減する操作を受け付けた状態で、選択操作が可能になるように作り込まれている。ユーザは、購入不可情報21bに示される不足額を考慮して、プリペイドカードの前払い金の金額に収まるように、購入量指定数欄21bの数量を指定する操作を行うことになる(図12の場合、不足額が900円であり、商品単価は1000円であることから、購入量を「3」から「2」以下にする指定をユーザは行うことになる)。
 購入量指定数欄21bの数量を、最初の数値から削減する操作が行われた状態で、再計算ボタン21dの選択操作を受け付けると、CPU10aは、削減された購入量の数値で商品を注文する購入注文情報(商品ID、削減された購入量の数値、購入金額を含む情報)を購入対象サーバ80へ再度、送信する処理を行う。このような購入量を削減した購入注文情報の送信に応じて、購入対象サーバ80からは購入画面情報が送信されてくるので、この購入画面情報を受信したことに基づき、CPU10aは購入画面(図11(a)の購入画面19参照)を生成して、ディスプレイ10fの表示を、生成した購入画面に切り替える処理を行う。なお、図12の購入不可画面21に含まれるチャージボタン21f及び購入キャンセルボタン21gは、図11(b)の購入不可画面20のチャージボタン20e及び購入キャンセルボタン20dと同等の働きをするものになっている。
 さらに、図13は、ディスプレイ10fに表示される購入不可画面22の一例を示し、購入対象となる商品の品目(商品の種類)が複数(二つ)であると共に、各購入対象の商品の購入量も複数になっている点が、図12に示す購入不可画面21の場合と異なる。すなわち、図13の購入不可画面22は、画面上部に、購入対象となる一つ目の商品の情報22a(商品名、単価など)を示すと共に、その下方に一つ目の商品に対する購入量指定欄22bを含み、その下方に、二つ目の商品の情報22cを示すと共に、その下方に二つ目の商品に対する購入量指定欄22dを含み、さらにその下方には、購入不可情報22eを配置し、その下方に、再計算ボタン22f、チャージボタン22g、及び購入キャンセルボタン22hを選択可能に配置している。
 図13の購入不可画面22は、図10(b)の商品注文画面18で、買い物継続ボタン19eの操作が行われることなどで、複数(二つ)の種類の商品が注文された場合で、且つ、二つの種類の商品の購入量がそれぞれ複数のときに、購入不可となった場合に表示される画面になっている。そのため、図13の購入不可画面22に応じた購入不可画面情報は、図12に示す購入不可画面21に応じた購入不可画面情報の内容に、購入不可の対応の仕方として購入対象となる商品の品目の削減を示す情報が含まれると共に、品目削減指示情報を含んだものになっている。このような内容の購入不可画面情報をスマートフォン10が受信することで、CPU10aは、受信した購入不可画面情報に基づき、図13に示す購入不可画面22を生成することになる。
 図13の購入不可画面22の購入量指定欄22b、22dは、購入量を削減する指定が可能であると共に、購入量の数値として「0」も指定可能になっており、「0」を指定した場合は、購入対象の商品を削除したことになる。また、購入不可画面22が含む購入不可情報22eも、図12の購入不可画面21が含む購入不可情報21cの内容に、購入不可解消のための対応の仕方として、商品の削除を追加したものになっている。なお、図13の購入不可画面22に含まれる再計算ボタン22f、チャージボタン22g及び購入キャンセルボタン22hは、図12の購入不可画面21の再計算ボタン21d、チャージボタン21f及び購入キャンセルボタン21gと同等の働きをするものになっており、例えば、再計算ボタン22fは、表示された直後はアクティブになっておらず、購入量指定欄22b、22dの数値の削減を指定する操作が行われることで、アクティブ(選択可能)になるように作り込まれている。
 次に、上述した構成の購入システム1の前払い金管理サーバ5、購入対象サーバ80、及びユーザ端末T1等(例えば,スマートフォン10)による一連の処理に基づく購入処理方法の処理内容を、図15~17の第1~3フローチャートに基づき説明していく(購入対象サーバ80の処理自体も購入処理方法に該当)。なお、第1フローチャートの処理を開始する段階で、図10(a)のプリペイド使用設定画面17にて、事前にプリペイドカードの使用が設定されているものとする。
 図15の第1フローチャートは、ユーザがユーザ端末T1を用いてオンラインでのショッピングサービス(商品の購入機会)を提供するショッピングシステム2(購入対象サーバ80)へログインを行うときからの処理手順を示したものである。この第1フローチャートは、ユーザ端末T1(スマートフォン10)で、ユーザがホーム画面において、ショッピングサービスに応じたアイコンの選択操作が行われて、図8のログイン画面15を表示した状態から開始されるものとする(S1)。このログイン画面15において、メールアドレスの入力操作、パスワードの入力操作、及びログインボタン15cの選択操作というログイン操作の有無を、ユーザ端末T1は判断する(S2)。ログイン操作が無い場合(S2:NO)、ログイン操作待ちの状態となり、また、ログイン操作が有った場合(S2:YES)、ユーザのログイン情報(入力されたメールアドレス及びパスワード、並びにユーザ端末を識別するUID等を含む情報)をショッピングシステム2の購入対象サーバ80へユーザ端末は送信する(S3)。
 購入対象サーバ80(MPU80a)は、ログイン情報を受信したか否かを判断する段階になっており(S10)、ログイン情報を受信しない場合(S10:NO)、受信待ちの状態となる。また、ログイン情報を受信した場合(S10:YES)、受信したログイン情報に含まれるメールアドレス、パスワード等が、図6に示すユーザDB81に格納される情報の中で一致するものがあるか否かを購入対象サーバ80は判断する(S11)。一致する情報が格納されていない場合(S11:NO)、購入対象サーバ80は不一致通知をアクセス元のユーザ端末へ送信することになる。なお、この場合は、ユーザ端末T1に、不一致通知の受信をトリガーに、S1の段階に戻って、再度、ログイン画面15を表示して、正しいログイン情報の入力機会をユーザに提示する。
 一方、ユーザDB81の中に、受信したログイン情報と一致するものがある場合(S11:YES)、購入対象サーバ80は、ログイン情報を送信してきたユーザがログイン状態になったことを示すログイン状態情報(ユーザID等を含む情報)をRAM80cに記憶すると共に、ログイン完了を通知するログイン完了情報をユーザ端末T1へ送信する(S12)。なお、ユーザ端末T1は、購入対象サーバ80からのログイン完了情報の受信をトリガーに、ディスプレイ10fの表示を、ログイン画面15から、図9に示す販売商品画面16の表示に切り替えて(S4)、ユーザが所望する商品画像16a等の選択操作を受け付けることで、図10(b)の商品注文画面18を表示するなどして、購入対象となる商品の選択、購入量の指定等の操作を受け付けるものとする(S5)。
 また、購入対象サーバ80は、ログイン完了のユーザについて、ユーザDB81の「カード使用」の項目に、「使用」という情報が格納されているか否かを判断する(S13)。「使用」という情報が格納されていない場合(S13:NO)、従来と同様に、クレジットカード又は銀行振込等で購入に関する処理が行われることになるので、この場合の説明は省略する。一方、「使用」という情報が格納されている場合(S13:YES)、購入対象サーバ80は、ログイン中のユーザのプリペイドカードの前払い金を問い合わせる問合せ情報(通信ユーザID及びカードID等を含む情報)を、通信キャリアシステム4の前払い金管理サーバ5へ送信する(S14)
 通信キャリアシステム4の前払い金管理サーバ5は、購入対象サーバ80からの前払い金の問合せ情報を受信したか否かを判断する段階になっており(S20)、問合せ情報を受信しない場合(S20:NO)、受信待ちの状態になっている。一方、問合せ情報を受信した場合(S20:YES)、前払い金管理サーバ5は、その問合せ情報に含まれる通信ユーザIDに対応付けられた前払い金の金額を、図3のプリペイドDB6から特定する(S21)。そして、購入対象サーバ80は、その特定した前払い金の金額を通知する前払い金情報を購入対象サーバ80へ送信する(S22)。
 また、購入対象サーバ80は、問合せ情報を送信した後、前払い金情報を受信したか否かを判断しており(S15)、前払い金情報を受信していない場合(S15:NO)、受信待ちの状態になっており、前払い金情報を受信した場合(S15:YES)、受信した前払い金情報を、RAM80cに、そのユーザのログイン状態情報と対応づけて記憶する(S16)。
 図16の第2フローチャートは、ユーザ端末T1において、図10(b)の商品注文画面18で、購入注文ボタン18eの選択操作が行われたことに伴って、購入注文情報を購入対象サーバ80へ送信する処理が行われていることを示す(S30)。
 購入対象サーバ80は、購入注文情報を受信したか否かを判断しており(S40)、受信していない場合(S40:NO)、受信待ちの状態となる。一方、購入注文情報を受信したとき(S40:YES)、購入対象サーバ80は、受信した購入注文情報で通知される商品の購入費用を、ユーザの前払い金の金額(RAM80cに記憶した前払い金情報に基づく金額)と比較し、購入が可能であるか否かを判断する(S41)。
 購入費用が前払い金の金額を超える場合、購入対象サーバ80は、購入不可であると判断し(S41:NO)、購入費用に対する前払い金の不足額を算出して、購入不可である旨、算出した不足額、及び購入不可の解消の仕方等を示す購入不可画面に係る購入不可画面情報を生成してユーザ端末T1へ送信する(S42)。なお、購入対象サーバ80は、購入不可画面情報を送信すると、S40の段階へ戻り、購入注文情報を受信したか否かを判断することになる。
 ユーザ端末T1は、購入注文情報を送信した後、購入対象サーバ80から送られる購入不可画面情報を受信したか否かを判断しており(S31)、購入不可画面情報を受信した場合(S31:YES)、購入不可画面情報に含まれる情報(購入不可である旨、及び不足額を示す情報)を用いて、例えば、図11(b)に示す購入不可画面20を生成し(S33)、その生成した購入不可画面20をディスプレイ10に表示する(S34)。
 なお、ユーザ端末T1が購入不可画面20を表示した後のユーザの選択肢として、購入不可画面20のテキスト部20cに記載されている対処方(前払い金の入金等)の他に、購入をキャンセルする等が複数の内容が想定できることから、購入不可画面20の表示以降の処理は、第2フローチャートにおいて省略する。
 購入対象サーバ80側の処理に戻って、購入対象サーバ80は、S41の段階で、購入費用が前払い金の金額以下であり、購入が可能であると判断した場合(S41:YES)、前払い金を用いてユーザの指定した商品の購入を指示する操作の受付が可能な購入画面に係る購入画面情報を生成し(S43)、その生成した購入画面情報をユーザ端末T1へ送信する(S44)。
 購入画面情報が購入対象サーバ80からユーザ端末T1へ送信されてくると、ユーザ端末T1は、S31の段階で、購入不可画面情報を受信しない場合(S31:NO)を進み、それから購入画面情報を受信したか否かを判断し(S32)、購入画面情報を受信した場合(S32:YES)、ユーザ端末T1は、図21の第3フローチャートで示される処理を行う。なお、購入画面情報を受信しない場合(S32:NO)、S31の段階に処理が戻ることになる。
 図17の第3フローチャートにおいて、ユーザ端末T1は、受信した購入画面情報に基づき、図11(a)の購入画面19を生成し(S50)、その生成した購入画面19をディスプレイ10fに表示する(S51)。それから、ユーザ端末T1は、表示した購入画面19で、購入ボタン19cの選択操作を受け付けたか否かを判断し(S52)、購入ボタン19cの選択操作を受け付けていない場合(S52:NO)、買い物継続ボタン19eの選択操作を受け付けたか否かを判断する(S53)。買い物継続ボタン19eの選択操作を受け付けた場合(S53:YES)、他の商品の購入が行えるようにするため、図15の第1フローチャートにおけるS4の段階へ戻り、ディスプレイ10fの表示を販売商品画面16に切り替える。
 また、買い物継続ボタン19eの選択操作を受け付けていない場合(S53:NO)、次に、購入キャンセルボタン19dの選択操作を受け付けたか否かを判断し(S54)、購入キャンセルボタン19dの選択操作を受け付けた場合(S54:YES)、RAM10cに記憶していた購入注文情報を削除してから(S55)、第1フローチャートにおけるS4の段階へ戻り、ディスプレイ10fの表示を販売商品画面16に切り替える。そして、購入キャンセルボタン19dの選択操作を受け付けていない場合(S54:NO)、S52の段階へ処理が戻ることになる。
 S52の段階で、購入ボタン19cの選択操作を受け付けた場合(S52:YES)、ユーザ端末T1は、購入画面19で示されるプリペイドカードからの支払で商品の購入を行う旨の購入指示操作を受け付けたことになり、その内容に応じた購入指示を購入対象サーバ80へ送信する(S56)。
 購入対象サーバ80は、第2フローチャートのS44の段階で購入画面情報を送信してからは、ユーザ端末T1からの購入指示を受信したか否かを判断しており(S60)、受信していない場合(S60:NO)、受信待ちの状態となる。また、購入指示を受信した場合(S60:YES)、購入対象サーバ80は、受信した購入指示に基づき、その購入指示に応じた購入処理を行う(S61)。それから、購入対象サーバ80は、購入完了情報をユーザ端末T1へ送信する(S62)。
 ユーザ端末T1は、S56の段階で購入指示を送信してからは、購入対象サーバ80からの購入完了情報を受信したか否かを判断しており(S57)、受信していない場合(S57:NO)、受信待ちの状態となる。また、購入完了情報を受信した場合(S57:YES)、ユーザ端末T1は図14に示す購入完了画面23を生成して表示する(S58)。この購入完了画面23により、ユーザは、購入指示による購入処理が完了したことを確認することになる。
 また、購入対象サーバ80は、S62の段階で購入完了情報を送信してから、プリペイドカードの使用した前払い金の金額を特定し、その特定した使用金額を通知する前払い金使用情報を前払い金管理サーバ5へ送信する(S63)。
 図15の第1フローチャートに示すように、前払い金管理サーバ5は、S22の段階で前払い金情報を送信してからは、購入対象サーバ80からの前払い金使用情報を受信したか否かを判断し(S23)、前払い金情報を受信しなかった場合(S23:NO)、受信待ちの状態となり、前払い金情報を受信した場合(S23:YES)、受信した前払い金情報に含まれる前払い金の金額の決済処理を行い(S24)、決済完了に伴い、プリペイドDB6の使用履歴を更新する。
 以上のように、本発明では、独自にオンラインを要求するショッピングサービスにおいても、プリペイドカードを用いてスムーズにショッピングを行うことができ、また、ショッピングを行うにあたり、プリペイドカードのカードIDの入力を行わなくてもプリペイドカードによる前払い金を使えることから、ユーザの操作負担も低減される。さらに、商品の購入費用に対して、プリペイドカードの前払い金が不足する場合は、購入不可の解消の仕方(プリペイドカードのチャージ、購入量の削減、購入対象の商品品目の削減など)が明記されるので、商品販売側としては、プリペイドカードでのオンラインによるユーザの購入機会を逃がさないようにできる。
 なお、本発明の第1実施形態は上述した内容に限定されるものではなく、様々な変形例が考えられる。例えば、図8に示すログイン画面15によるログインは、上述したように、ショッピングアプリP21を起動した直後に行うタイミングする他、例えば、ディスプレイ10fに図10(b)の商品注文画面18を表示した状態で、ユーザが購入注文ボタン18eの選択操作を行ったタイミングで、図8のログイン画面15をディスプレイ10fに表示するようにしてもよい。この場合、ログイン画面15において、メールアドレス入力欄15a及びパスワード入力欄15bに所定のメールアドレスとパスワードを入力した状態でログインボタン15cの選択操作が行われると、ログイン情報と、購入注文ボタン18eを選択操作したことに伴う購入注文情報とを購入対象サーバ80へ送信する処理をCPU10aは行うことになる。
 そして、ログイン情報を受信した購入対象サーバ80は、ログイン情報に含まれるメールアドレス及びパスワード等がユーザDB81に格納されていれば、ログイン完了と判断し、それから受信した購入注文情報に基づき、プリペイドカードによる前払い金により購入が可能か否かを判断する。購入可能と判断した場合、購入対象サーバ80は、購入画面(例えば、図11(a)に示す購入画面19)に係る購入画面情報を生成してユーザ端末へ送信し、購入不可と判断した場合は、購入不可画面(例えば、図11(b)に示す購入不可画面20)に係る購入不可画面情報を生成してユーザ端末へ送信することになる。
 従って、上述した変形例におけるユーザ端末で表示される画面の遷移としては、商品注文画面18からログイン画面15を経由して、購入画面(例えば、購入画面19)又は購入不可画面(例えば、購入不可画面20)のいずれかが表示される流れとなり、この変形例の場合でも、独自にオンラインを要求するショッピングサービスに対し、プリペイドカードを用いてスムーズにショッピングを行うことができる。なお、上述した変形例の場合で、ログイン情報を送信してログイン不可と判断された場合は、再度、メールアドレス及びパスワード等を入力できるようにログイン画面15が表示される。
 また、ショッピングサービスが購入機会を提供する購入対象の例は、図9の販売商品画面16で示すような商品に限定されるものではなく、他の種類の商品も勿論、本発明に適用可能である。例えば、情報の購入、権利の購入、金融商品の購入なども可能である。また、商品以外にも各種サービス(引っ越し、クリーニング、修理など)にも本発明は適用可能である。また、ショッピングサービスが提供する商品が単一種類であり、購入量だけをユーザが指定するような場合では、図9のような複数の商品を提示する販売商品画面16をユーザ端末に提示するのではなく、購入量を指定する販売商品画面を提示するようにしてもよい。さらに、一の商品カテゴリーをメインに扱う画面においてログインした上で、他の商品カテゴリーを購入できる構成としてもよい。例えば、電化製品の購入をメインとするログイン画面を経た上で、金融商品を購入できる画面が提示される構成にしてもよい。また、雑貨品をメインに扱う画面においてログインした上で、それと関係がある修理等のサービス又はそれと関係がない引越しサービスなどを購入可能な画面を提示するよう構成してもよい。このような構成は、種々の構成によって実現可能であるが、例えば、ログイン時にメインに扱われる商品カテゴリーの画面において、当該商品カテゴリーと異なる商品カテゴリーの購入画面に遷移可能なボタン等が提示されることで、当該ボタンの押下げによって、他の商品カテゴリーを購入可能な画面に遷移できるような構成によって実現することが可能である。
 図18は、変形例の販売商品画面30の一例がディスプレイ10fに表示した状態を示す。この変形例の販売商品画面30は、プリペイドカードによる購入対象が電子通貨の場合であり、電子通貨購入用のショッピングアプリがユーザ端末にインストールされて、このアプリが起動すると、図8のログイン画面15を表示し、ログイン情報の送信に伴いログインが完了すると、図18の販売商品画面30がユーザ端末のディスプレイ10fに表示されることになる。
 この電子通貨購入用の販売商品画面30は、購入量指定欄30a及び購入ボタン30bを含んでおり、購入量指定欄30aで電子通貨の購入量(購入金額)をユーザが指定する操作を行い、購入量を指定した状態で、購入ボタン30bの選択操作をユーザ端末が受け付けると、指定した購入量(購入金額)等を含む電子通貨の購入注文情報を購入対象サーバ80へ送信する処理を、ユーザ端末(CPU10a)は行うことになる。
 この変形例の場合、購入対象サーバ80は、ログイン中のユーザIDに係るユーザ端末から上記の購入注文情報を受信すると、上述したように、ログイン中のユーザIDに係るユーザ端末がプリペイドカードの使用を設定しているかを判断し、プリペイドカードの使用を設定している場合は、受信した購入注文情報に含まれる購入金額を、ログイン中のユーザIDと対応づけて記憶されている前払い金情報で示される前払い金の金額と比較して、購入金額が前払い金の金額を超えるか否かをMPU80aは判断する。購入金額が前払い金の金額を上回らずに、前払い金の金額以下であると判断した場合、前払い金で購入可能とMPU80aは判定し、前払い金を用いて購入対象である電子通貨の購入を確認する内容(電子通貨を、ユーザの指定した購入量で購入する旨を確認するテキスト内容)を含む購入画面情報を生成して、ユーザ端末へ送信する処理を行う。
 図19(a)は、上述した電子通貨の購入の場合に応じた購入画面情報をユーザ端末が受信した場合に、ユーザ端末のディスプレイ10fで表示される購入画面31を示している。この購入画面31は、電子通貨をユーザの指定した購入量(10,000円)で、プリペイドカードによる前払い金(10,000円)にて購入する旨を確認する内容を記した購入可能情報31aを配置すると共に、その下方に購入ボタン31b及び戻るボタン31cを配置したものになっている。購入ボタン31bの選択操作を受け付けると、ユーザ端末は、購入可能情報31aに記された内容で電子通貨を購入する旨の購入指示(電子通貨をユーザの指定した購入金額で購入する指示)を、購入対象サーバ80へ送信する処理をユーザ端末(CPU10a)は行う。なお、購入指示を受信した購入対象サーバ80の処理は、上述した説明と同様であり、購入指示に基づき購入処理を実行することになる(図17の第3フローチャートのS61の段階参照)。また、戻るボタン31cの選択操作が行われたときは、図18の販売商品画面30にディスプレイ10fの表示を切り替えて、ユーザが購入量の変更等を行えるようにしている。
 一方、上記の変形例の場合で、購入対象サーバ80が、購入金額を前払い金の金額と比較して、購入金額が前払い金の金額を超えると判断した場合、前払い金で購入不可とMPU80aは判定すると共に、前払い金による不足額を算出して、前払い金を用いて購入対象である電子通貨の購入が不可である旨を含む購入不可画面に係る購入不可画面情報を生成し、ユーザ端末へ送信する処理を行う。この変形例で生成する購入不可画面情報は、購入対象の電子通貨は、購入量の削減が可能であることから、購入不可の解消の仕方として、プリペイドカードのチャージに加えて、購入量の削減を含んだものになっている。
 図19(b)は、上述した電子通貨の場合に応じた購入不可画面情報をユーザ端末が受信した場合に、ユーザ端末のディスプレイ10fで表示される購入不可画面32を示している。この購入画面31は、電子通貨をユーザの指定した購入量(10,000円)で、プリペイドカードによる前払い金にて購入するには、5,000円が不足する旨を記した購入不可情報32aを配置すると共に、その下方にチャージボタン32b及び戻るボタン32cを配置したものになっている。購入不可情報32aは、購入不可の解消の仕方として、プリペイドカードのチャージに加えて、購入量の削減を記したものになっている。なお、チャージボタン32b及び戻るボタン32cの選択操作が行われた場合の内容は、上述した説明と同様である。
 また、図18、19に示す変形例は、電子通貨以外の購入対象にも適用可能であり、例えば、仮想通貨、金、プラチナ、他のプリペイドカード等といった購入量を指定するような購入対象に幅広く利用できる。さらに、図18に示す販売商品画面30は、図9のような販売商品画面16から遷移して表示させるようにすることも可能である。この場合は、販売商品画面16の中に配置される複数の商品画像16a等の中に、販売商品画面30に応じた購入対象を含ませておき、その購入対象に応じた商品画像の選択操作が行われることで、販売消費画面30が表示されるようになる。さらにまた、ログインは最初に行う替わりに、上述した場合と同様に、販売商品画面30の購入ボタン30bの選択操作を受け付けたことに応じてログイン画面15の表示に切り替えて、ログイン操作を行えるようにすることも可能である。
 また、図4に示すチャージ画面9は、上述した説明では、前払い金管理サーバ5のログイン操作を行うことなく、ユーザ端末で表示できるようにしたが、ショッピングサービスへのログインと同様に、前払い金管理サーバ5へもログイン操作を必要として、そのログイン操作に関するログインが完了してから、図4のチャージ画面9が表示されるようにしてもよい。このようにログイン操作を必要とする場合は、図11(b)、12、13の購入不可画面20、21、22でチャージボタン20e、21f、22gの選択操作が行われると、図8に示す様なログイン画面をユーザ端末に表示させて、通信ユーザID又はカードID等の入力操作を行わせて、ログインボタンの選択操作が行われたことに伴って、通信ユーザID又はカードID等を含むログイン要求を、ユーザ端末から前払い金管理サーバ5へ送るようにする。前払い金管理サーバ5は、ログイン要求に含まれる通信ユーザID又はカードID等が、プリペイドDB6に格納されているか否かでログインの適否を判定し、格納されている場合は、ログイン完了をユーザ端末へ通知し、ユーザ端末は、前払い金管理サーバ5からのログイン完了を受信したことに基づき、図4に示すチャージ画面9を表示することになる。
 さらに、図11(a)に示す購入画面19を表示させるための購入画面情報、又は図11(b)、12、13に示す購入不可画面20、21、22を表示させるための購入不可画面情報は、画面に示す情報に応じたテキスト及び指示等を含むものとして説明したが、購入画面情報及び購入不可画面情報は、テキスト等ではなく、各種数値を含む内容の情報にすることも可能である。例えば、情報に含まれる最初の数字が0のときは、購入画面情報を意味し、最初の数字が1のときは、購入不可画面情報を意味するものと、取り決めておき、このように0又は1の数字を、購入画面情報又は購入不可画面情報にすると、購入対象サーバ80の処理負担を低減できると共に、通信情報量の削減を図れる。
 なお、購入画面情報又は購入不可画面情報として、0又は1の数字を用いる場合、図11(a)に示す購入画面19が含む購入可能情報19bの表記内容、及び図11(b)、12、13に示す購入不可画面20、21、22が含む購入不可情報20b、21c、22eの表記内容は、ショッピングアプリP21に予め含ませておき、各画面19、20、21、22の生成時に、適宜、所定の表記を読み出すことになる。また、購入不可情報20b、21c、22eは、不足額を含むので、このような不足額は、例えば、購入不可画面情報として、1の数字を用いたときは、その1の数字の次に、不足額の数値(例えば、1万円が不足するときは、10000という数字)を含ませた購入不可画面情報を、購入対象サーバ80は生成するものとする。
 さらに、図11(b)、12、13に示す購入不可画面20、21、22では、購入不可の解消の仕方が異なるので、これらを使い分けるようにするためには、購入不可画面情報を表す数値としては、上述した最初の数字に1を用いる他に、2又は3の数字を用いるようにし、情報(購入不可画面情報)に含まれる最初の数字が1のときは、図11(b)の購入不可画面20の購入不可情報20bに対応させ、最初の数字が2のときは、図12の購入不可画面21の購入不可情報21cに対応させ、最初の数字が3のときは、図13の購入不可画面22の購入不可情報22cに対応させることが考えられる。すなわち、これらの購入不可情報20b、21c、22cでは、購入不可の解消の仕方が異なっているので、それぞれを使い分ける必要があることから、上述したように最初の数値を変えることにより、購入不可画面情報を数字にした場合でも対応可能となる。なお、これらの購入不可情報20b、21c、22cに応じた表記は、ショッピングアプリP21に予め含ませておき、上述した数字により、ユーザ端末(CPU10a)が、使用する購入不可情報20b、21c、22cの表記内容を区別することになる。
 また、図12の購入不可画面21の購入不可情報21cでは、購入不可の解消の仕方として、プリペイドカードのチャージの他に、購入量の削減を記し、さらに、図13の購入不可画面22の購入不可情報22cでは、商品品目の削減を記すようにしたが、プリペイドカードの使用促進を重視するときは、購入不可の解消の仕方としては、プリペイドカードのチャージのみを記すようにしてもよい。また、購入不可の解消の仕方をユーザの判断に委ねる場合などでは、購入不可の解消の仕方の表記は省略することも可能である。
 さらに、上記の例では、プリペイドカードの使用設定は、図10(a)のプリペイド使用設定画面17を通じて行うようにしていたが、ショッピングシステム2へのユーザ登録時に、プリペイドカードの使用設定を行っておき、図10(a)のプリペイド使用設定画面17の使用を省略することも可能である。一方、図10(a)のプリペイド使用設定画面17は、購入を行うごとに表示するようにして、購入ごとに、プリペイドカードの使用又は不使用をユーザが適宜設定できるようにしてもよい。
 さらにまた、購入対象サーバ80の処理負担の低減を行う場合は、購入の可否判断等に関する処理(図16の第2フローチャートのS41~S43等の処理)をユーザ端末側で行う仕様にすることも可能である。この場合、購入対象サーバ80は、前払い金管理サーバ5から前払い金情報を受信して取得すると(図19の第1フローチャートのS15参照)、この取得した前払い金情報(前払い金額を示す情報)をユーザ端末T1へ送信する。
 ユーザ端末T1は、前払い金情報を受信すると、RAM10cに一時的に記憶し、図10(b)の商品注文画面18で購入注文ボタン18eの選択操作を受け受けると、購入注文情報を購入対象サーバ80へ送信するのではなく、購入対象の購入費用を、RAM10cに記憶する前払い金情報に係る前払い金の金額と比較する。比較の結果、購入費用が、前払い金の金額を上回ると、図11(b)に示すような購入不可画面20を生成して表示する処理をユーザ端末自身の処理で行う(画面のテキスト表記等は、ショッピングアプリP21に予め含ませておき、抽出して使用する。また、購入費用が、前払い金の金額以下であれば、購入可能と判断し、図11(b)に示す様な購入画面19を生成して表示することをユーザ端末自身の処理で行う。
 さらに、本発明に用いるプリペイドカードの発行元として、上述した実施形態では、通信機器に係る通信費の徴収を行う通信キャリア事業体で説明したが、これに限定されるものではなく、一定期間単位でユーザから支払われる費用の中に、前払い金分の金額を上乗せして徴収(ユーザを識別して徴収)することが可能な事業体が発行するようなプリペイドカードの前払い金であれば、本発明におけるプリペイド方式に係る前払い金として広く用いることが可能である。さらには、銀行等の金融機関が発行するデビットカード(デビットカード機能を有するキャッシュカードも含む)は、各種商品の購入に使用可能であることから、本発明では、デビットカードに応じた口座の入金も、プリペイド方式に係る前払い金に該当し、適用可能になっている。この場合、銀行等の金融機関においてデビットカードの管理を行うシステムを構成するサーバ装置が、前払い金管理サーバに該当し、購入対象サーバ80との間で、上述した処理を行うことになる。上述したように、本発明の第1実施形態では多様な変形例を考えることができ、また、これらの各変形例は、適宜組み合わせて用いることも可能である。
 本発明の第2実施形態に係る購入システムは、上述した第1実施形態に係る処理をウェブサイトベースで行い、図4、8~14に示す各種画面を、ウェブサイトのウェブページ画面としてユーザ端末に表示するようにしたものである。なお、第2実施形態でも、ハード的な構成は第1実施形態と同様であるため、符号については第1実施形態と同じものを用いて、第2実施形態の内容を以下に説明していく。
 第2実施形態では、ショッピングシステム2が、ネットワークNW上に、ショッピングサイトを構築しており、ショッピングシステム2に含まれる購入対象サーバ80がウェブサーバ的な役割を果たし、ユーザ端末からのアクセスに応じて第1実施形態で説明した各種画面をウェブサイト経由でユーザ端末に表示することで、ユーザが商品の購入を行えるようにしている。
 図20(a)は、ユーザ端末の一例としてスマートフォン10(図7参照)が記憶部10gに記憶する第2実施形態におけるプログラム等の内容を示したものであり、第2実施形態特有のものとして、新たに、ブラウザアプリP22(ブラウザアプリ)を記憶している。このブラウザアプリP22は、第2実施形態用のショッピングアプリP21′と連携した処理を行うことなり、例えば、ユーザ端末のホーム画面におけるショッピングアイコンが選択されると、ショッピングシステム2(購入対象サーバ80)が構築するウェブサイトへアクセスし、アクセス以降は、ショッピングシステム2から送信されてくるウェブページデータに基づくウェブページ画面を、ブラウザアプリP22が規定する処理に基づきCPU10aが生成し、生成した各ウェブページ画面をディスプレイ10fに表示することになる。また、ウェブページ画面に含まれる各ボタンの選択操作を受け付けた場合、そのボタンの選択された旨の操作通知をショッピングシステム2(購入対象サーバ80)へ送信することも、ブラウザアプリP22の規定に基づきCPU10aが制御することになる。
 図20(b)は、ショッピングシステム2の購入対象サーバ80の大容量記憶システム80gに記憶するプログラム等の内容を示したものであり、第2実施形態特有のものとして、新たにウェブサーバプログラムP12を記憶すると共に、ネットワーク上に構築するウェブサイトを構成する複数のウェブページに応じたウェブページデータを格納したウェブサイトDB85も記憶している。ウェブサーバプログラムP12は、ユーザ端末からのアクセス状況に応じて、ウェブサイトDB85から所要のウェブページを構成する画面情報を読み出してアクセス元のユーザ端末へ送信するものであり、アクセス元のユーザ端末から送信されてくる操作内容を示す情報に応じて、所要の画面情報を送信することも規定する。
 また、第2実施形態の取引プログラムボタンP11′は、ウェブサーバプログラムP12の処理と連携して処理を行うものとなっており、実行する処理内容(購入の可否判断等)は基本的に第1実施形態と同様である。なお、第2実施形態でも事前にプリペイドカードの使用申し込みを、ショッピングサービスを提供する事業体へ行っており、申し込みの際、通信ユーザID、カードID、カード設定等もユーザDB81に格納される。
 上述した第2実施形態では、最初にユーザ端末が購入対象サーバ80へアクセスすると、購入対象サーバ80は、そのアクセスに応じて、図8のログイン画面15を表示させるためのログイン画面情報をユーザ端末へ送信し、ユーザ端末では、ログイン画面情報を受信すると、そのログイン画面情報に基づき、ブラウザアプリP22の処理により、ログイン画面15を生成してディスプレイ10fに表示する。なお、ウェブページとして表示したログイン画面15では、第1実施形態と同様のユーザ操作が行われて、ユーザのログイン情報がユーザ端末から購入対象サーバ80へ送信されることになり、ログイン処理等に関しては、第1実施形態の図15の第1フローチャートで説明した処理内容が行われる。
 そして、ログイン完了になると、第2実施形態では、ログイン完了通知がユーザ端末へ送信されるのではなく、図9の販売商品画面16に応じた画面情報が購入対象サーバ80からユーザ端末へ送信されて、ウェブページとして販売商品画面がユーザ端末で表示される。そして、この販売商品画面に含まれる複数の商品画像の中から、所望の商品画像を選択する操作を行うと、その選択内容がユーザ端末から購入対象サーバ80へ送信され、選択された商品画像に係る商品の商品注文画面(図10(b)の商品注文画面18参照)に応じた画面情報が、購入対象サーバ80からユーザ端末へ送信され、ユーザ端末は、受信した画面情報に基づきウェブページとして商品注文画面を生成して表示する。
 表示した商品注文画面で、購入ボタン(図10(b)の購入ボタン18c参照)の選択操作を行うと、第1実施形態と同様、ユーザ端末から購入注文情報が購入対象サーバ80へ送信され、以降は第1実施形態の図16の第2フローチャートで説明した処理が行われるが、購入対象サーバ80からユーザ端末へ送信される購入不可画面情報、購入画面情報は、ウェブページとして購入不可画面、購入画面をユーザ端末で表示させるための情報になっている点が、第1実施形態と異なる。
 すなわち、第2実施形態において、購入対象サーバ80からユーザ端末へ送信される購入不可画面情報は、図11(b)、12、13に示す購入不可画面20、21、22をウェブページとしてユーザ端末で生成されて表示させるための情報となっており、購入不可画面20、21、22を構成する内容(各ボタン、テキスト表記等)をHTML言語等のマークアップランゲージ系の記述等を含む内容になっている。同様に、第2実施形態において、購入対象サーバ80からユーザ端末へ送信される購入画面情報は、図11(a)に示す購入画面19をウェブページとしてユーザ端末で生成されて表示させるための情報となっており、購入画面19を構成する内容(各ボタン、テキスト部等)をHTML言語等のマークアップランゲージ系の記述等を含む内容になっている。
 このことは、第2実施形態で図10のプリペイド使用設定画面17、図14の購入完了画面23等をユーザ端末で表示させる場合でも同様である。なお、上述した内容以外について、第2実施形態は基本的に第1実施形態と同様の構成であり、同様の処理を行う。
 このように第2実施形態に係る発明は、第1実施形態に係る内容をウェブサイトベースで行うようにしたものになっており、それにより柔軟なシステム構成で、本発明の処理内容を行うことができるメリットがある。なお、第2実施形態においても、第1実施形態で説明した各種変形例の内容を、第2実施形態に即した内容で適用することができる。例えば、ユーザ端末側で購入の可否を判断する場合は、ウェブページとして各画面をユーザ端末で表示させるために購入対象サーバ80からユーザ端末へ送信する画面情報の中に、判断処理に応じたスクリプト系の処理を記述した情報を含ませて、適宜ウェブページ上で所要の処理を行えるようにしている。
 本発明は、オンラインでの購入対象の購入費用の支払いについて、プリペイドカードをスムーズに使用できるようにすることに対して好適に利用可能である。
 1 購入システム
 2 ショッピングシステム
 4 通信キャリアシステム
 5 前払い金管理サーバ
 6 プリペイドDB
 9 チャージ画面
 10 スマートフォン
 10a CPU
 15 ログイン画面
 16 販売商品画面
 17 プリペイド使用設定画面
 18 商品注文画面
 19 購入画面
 20~22 購入不可画面
 23 購入完了画面
 80 購入対象サーバ
 81 ユーザDB
 P11 販売プログラム(コンピュータプログラム)
 P21 ショッピングアプリ
 T1~T3 ユーザ端末
 U1~U3 ユーザ

Claims (12)

  1.  ネットワークを通じて購入対象の購入機会をユーザに提供する購入対象サーバが、通信端末装置から送られる購入対象の購入指示を受信することに応じて、前記購入対象の購入処理を行う購入システムにおいて、
     プリペイド方式に係るユーザの前払い金に応じた情報をユーザごとに管理する前払い金管理サーバを備え、
     前記購入対象サーバは、
     前記通信端末装置から送られるユーザログイン情報を受信した場合、受信したユーザログイン情報に基づき、ユーザのログイン処理を行う手段と、
     ログインの完了したユーザに係る前払い金の問合せ情報を前記前払い金管理サーバへ送信する手段と
     を備え、
     前記前払い金管理サーバは、
     問合せ情報を受信した場合、問合せ対象となるユーザの前払い金を通知する前払い金情報を前記購入対象サーバへ送信する手段を備え、
     前記購入対象サーバは更に、
     前払い金情報を受信した場合、受信した前払い金情報で通知される前払い金を用いて前記購入対象の購入を指示する操作の受付が可能な購入画面に係る購入画面情報を生成する手段と、
     生成した購入画面情報を前記通信端末装置へ送信する手段と
     を備え、
     前記通信端末装置は、
     購入画面情報を受信した場合、受信した購入画面情報に基づき購入画面を生成して表示する手段と、
     表示した購入画面で、前払い金を用いて前記購入対象の購入を指示する操作を受け付けた場合、前払い金を用いて前記購入対象を購入する旨の購入指示を前記購入対象サーバへ送信する手段と
     を備えることを特徴とする購入システム。
  2.  ネットワークを通じて購入対象の購入機会をユーザに提供する購入対象サーバが、通信端末装置から送られる購入対象の購入指示を受信することに応じて、前記購入対象の購入処理を行う購入システムによる購入処理方法において、
     前記購入システムは、プリペイド方式に係るユーザの前払い金に応じた情報をユーザごとに管理する前払い金管理サーバを備えており、
     前記購入対象サーバは、
     前記通信端末装置から送られるユーザログイン情報を受信した場合、受信したユーザログイン情報に基づき、ユーザのログイン処理を行うステップと、
     ログインの完了したユーザに係る前払い金の問合せ情報を前記前払い金管理サーバへ送信するステップと
     を備え、
     前記前払い金管理サーバは、
     問合せ情報を受信した場合、問合せ対象となるユーザの前払い金を通知する前払い金情報を前記購入対象サーバへ送信するステップを備え、
     前記購入対象サーバは更に、
     前払い金情報を受信した場合、受信した前払い金情報で通知される前払い金を用いて前記購入対象の購入を指示する操作の受付が可能な購入画面に係る購入画面情報を生成するステップと、
     生成した購入画面情報を前記通信端末装置へ送信するステップと
     を備え、
     前記通信端末装置は、
     購入画面情報を受信した場合、受信した購入画面情報に基づき購入画面を生成して表示するステップと、
     表示した購入画面で、前払い金を用いて前記購入対象の購入を指示する操作を受け付けた場合、前払い金を用いて前記購入対象を購入する旨の購入指示を前記購入対象サーバへ送信するステップと
     を備えることを特徴とする購入処理方法。
  3.  ネットワークを通じて購入対象の購入機会をユーザに提供しており、外部の通信端末装置から送られる購入対象の購入指示を受信することに応じて、前記購入対象の購入処理を行う購入対象サーバにおいて、
     外部の通信端末装置から送られるユーザログイン情報を受信した場合、受信したユーザログイン情報に基づき、ユーザのログイン処理を行う手段と、
     ログインの完了したユーザに係る前払い金の問合せ情報を、プリペイド方式に係るユーザの前払い金に応じた情報をユーザごとに管理する外部の前払い金管理サーバへ送信する手段と、
     問合せ情報の送信に伴って、ユーザの前払い金を通知する前払い金情報を受信した場合、受信した前払い金情報で通知される前払い金を用いて前記購入対象の購入を指示する操作の受付が可能な購入画面に係る購入画面情報を生成する手段と、
     生成した購入画面情報を外部の通信端末装置へ送信する手段と
     を備えることを特徴とする購入対象サーバ。
  4.  前記購入対象の購入費用を、受信した前払い金情報で通知される前払い金の金額と比較する手段を備え、
     前記購入対象の購入費用が前払い金の金額以下である場合に、前記購入画面情報を生成するようにしてある請求項3に記載の購入対象サーバ。
  5.  前記購入対象の購入費用が前払い金の金額を超える場合、前記購入対象の購入が不可である旨を示す購入不可画面に係る購入不可画面情報を生成する手段と、
     生成した購入不可画面情報を外部の通信端末装置へ送信する手段と
     を備える請求項4に記載の購入対象サーバ。
  6.  前払い金の金額での前記購入対象の購入に対する不足額を算出する手段を備え、
     算出した不足額を示す購入不可画面に係る購入不可画面情報を生成するようにしてある請求項5に記載の購入対象サーバ。
  7.  前記購入対象の購入不可解消に対して前払い金の入金を示す購入不可画面に係る購入不可画面情報を生成するようにしてある請求項5又は請求項6に記載の購入対象サーバ。
  8.  前払い金の入金受付画面の表示に切り替える操作指示の受付が可能な購入不可画面に係る購入不可画面情報を生成するようにしてある請求項7に記載の購入対象サーバ。
  9.  前記購入対象が、購入量を削減可能である場合、前記購入対象の購入不可解消に対して、前記購入対象の購入量削減を示す購入不可画面に係る購入不可画面情報を生成するようにしてある請求項5乃至請求項8のいずれか1項に記載の購入対象サーバ。
  10.  前記購入対象が、購入量を削減可能である場合、前記購入対象の購入量の指定操作の受付が可能な購入不可画面に係る購入不可画面情報を生成するようにしてある請求項5乃至請求項9のいずれか1項に記載の購入対象サーバ。
  11.  ネットワークを通じて購入対象の購入機会をユーザに提供する購入対象サーバが、外部の通信端末装置から送られる購入対象の購入指示を受信することに応じて、前記購入対象の購入処理を行う購入処理方法において、
     外部の通信端末装置から送られるユーザログイン情報を受信した場合、受信したユーザログイン情報に基づき、ユーザのログイン処理を行うステップと、
     ログインの完了したユーザに係る前払い金の問合せ情報を、プリペイド方式に係るユーザの前払い金に応じた情報をユーザごとに管理する外部の前払い金管理サーバへ送信するステップと、
     問合せ情報の送信に伴って、ユーザの前払い金を通知する前払い金情報を受信した場合、受信した前払い金情報で通知される前払い金を用いて前記購入対象の購入を指示する操作の受付が可能な購入画面に係る購入画面情報を生成するステップと、
     生成した購入画面情報を外部の通信端末装置へ送信するステップと
     を備えることを特徴とする購入処理方法。
  12.  ネットワークを通じて購入対象の購入機会をユーザに提供するサーバコンピュータに、外部の通信端末装置から送られる購入対象の購入指示を受信することに応じて、前記購入対象の購入処理を実行させるためのコンピュータプログラムにおいて、
     前記サーバコンピュータに、
     外部の通信端末装置から送られるユーザログイン情報を受信した場合、受信したユーザログイン情報に基づき、ユーザのログイン処理を行うステップと、
     ログインの完了したユーザに係る前払い金の問合せ情報を、プリペイド方式に係るユーザの前払い金に応じた情報をユーザごとに管理する外部の前払い金管理サーバへ送信するステップと、
     問合せ情報の送信に伴って、ユーザの前払い金を通知する前払い金情報を受信した場合、受信した前払い金情報で通知される前払い金を用いて前記購入対象の購入を指示する操作の受付が可能な購入画面に係る購入画面情報を生成するステップと、
     生成した購入画面情報を外部の通信端末装置へ送信するステップと
     を実行させることを特徴とするコンピュータプログラム。
PCT/JP2017/013973 2017-04-03 2017-04-03 購入システム、購入処理方法、購入対象サーバ、及びコンピュータプログラム WO2018185816A1 (ja)

Priority Applications (2)

Application Number Priority Date Filing Date Title
PCT/JP2017/013973 WO2018185816A1 (ja) 2017-04-03 2017-04-03 購入システム、購入処理方法、購入対象サーバ、及びコンピュータプログラム
JP2019510515A JP6913160B2 (ja) 2017-04-03 2017-04-03 購入システム、購入処理方法、購入対象サーバ、及びコンピュータプログラム

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
PCT/JP2017/013973 WO2018185816A1 (ja) 2017-04-03 2017-04-03 購入システム、購入処理方法、購入対象サーバ、及びコンピュータプログラム

Publications (1)

Publication Number Publication Date
WO2018185816A1 true WO2018185816A1 (ja) 2018-10-11

Family

ID=63713054

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/JP2017/013973 WO2018185816A1 (ja) 2017-04-03 2017-04-03 購入システム、購入処理方法、購入対象サーバ、及びコンピュータプログラム

Country Status (2)

Country Link
JP (1) JP6913160B2 (ja)
WO (1) WO2018185816A1 (ja)

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2020067867A (ja) * 2018-10-25 2020-04-30 株式会社メルカリ プログラム、情報処理方法、および情報処理装置

Families Citing this family (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP7271197B2 (ja) * 2019-01-17 2023-05-11 株式会社メルカリ プログラム、情報処理方法、情報処理端末

Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2002049859A (ja) * 2000-07-31 2002-02-15 Akira Nakazawa オンライン・プリペイド課金管理システム
JP2004133693A (ja) * 2002-10-10 2004-04-30 Casio Comput Co Ltd プリペイド型電子マネー決済システム、方法、及びプログラム
JP2004341793A (ja) * 2003-05-15 2004-12-02 Nifty Corp プリペイド決済方式に関連する情報処理方法及びプログラム並びにシステム
JP2006155030A (ja) * 2004-11-26 2006-06-15 Matsushita Electric Ind Co Ltd 決済端末

Patent Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2002049859A (ja) * 2000-07-31 2002-02-15 Akira Nakazawa オンライン・プリペイド課金管理システム
JP2004133693A (ja) * 2002-10-10 2004-04-30 Casio Comput Co Ltd プリペイド型電子マネー決済システム、方法、及びプログラム
JP2004341793A (ja) * 2003-05-15 2004-12-02 Nifty Corp プリペイド決済方式に関連する情報処理方法及びプログラム並びにシステム
JP2006155030A (ja) * 2004-11-26 2006-06-15 Matsushita Electric Ind Co Ltd 決済端末

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2020067867A (ja) * 2018-10-25 2020-04-30 株式会社メルカリ プログラム、情報処理方法、および情報処理装置

Also Published As

Publication number Publication date
JPWO2018185816A1 (ja) 2020-02-20
JP6913160B2 (ja) 2021-08-04

Similar Documents

Publication Publication Date Title
JP5882122B2 (ja) カード支払情報通知システム、カード支払情報通知方法及びカード支払情報通知プログラム
JP5068284B2 (ja) クレジットカード番号を用いたプリペイド決済システム及びプリペイド決済の方法
JP6059319B1 (ja) 代金支払管理システム、及び代金支払管理方法
JP6065475B2 (ja) 決済装置、及び決済方法
JP2011186660A (ja) 電子商取引システム、決済サーバ、およびプログラム
JP4326165B2 (ja) Icカード及び電子マネー入金システム
JPWO2018042666A1 (ja) 情報処理装置、支払仲介サーバ、支払仲介システム、情報処理方法、および支払仲介方法
WO2017047779A1 (ja) 株式売買システム、株式売買方法、証券システム、売買端末、及びコンピュータプログラム
JP6694838B2 (ja) 金融商品購入システム、金融商品購入方法、通信端末装置、及びコンピュータプログラム
JP6913160B2 (ja) 購入システム、購入処理方法、購入対象サーバ、及びコンピュータプログラム
US7103571B2 (en) Electronic settlement system using prepaid type electronic money
JP6499358B2 (ja) 決済管理装置及び決済管理方法
JP6110039B1 (ja) 金融商品購入システム、金融商品購入方法、取引サーバ、及びコンピュータプログラム
JP2013065360A (ja) 決済システム
JP2022157843A (ja) 情報処理装置、情報処理方法及び情報処理プログラム
JP2005250899A (ja) プリペイド決済装置、プリペイド決済システム、プリペイド決済方法、及びプログラム
JP7406141B2 (ja) 仮想通貨決済支援装置、仮想通貨決済支援システム、仮想通貨決済支援方法、及び仮想通貨決済支援プログラム
JP6982208B1 (ja) 情報処理装置、情報処理方法、および情報処理プログラム
JP6844905B2 (ja) 積立購入システム、積立購入方法、積立購入装置、及びコンピュータプログラム
JP6952828B2 (ja) 金融商品購入システム、金融商品購入方法、通信端末装置、及びコンピュータプログラム
JP2010176446A (ja) 商品授受システム、商品サーバ、プログラム、商品授受方法
JP2016110491A (ja) 取引情報処理システム
JP2020098494A (ja) 処理システム、処理装置、処理方法及びプログラム
JP7260701B1 (ja) 情報処理装置及び情報処理方法
JP7239256B1 (ja) 電子通貨システム

Legal Events

Date Code Title Description
121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 17904727

Country of ref document: EP

Kind code of ref document: A1

ENP Entry into the national phase

Ref document number: 2019510515

Country of ref document: JP

Kind code of ref document: A

NENP Non-entry into the national phase

Ref country code: DE

122 Ep: pct application non-entry in european phase

Ref document number: 17904727

Country of ref document: EP

Kind code of ref document: A1