JP 4901053 B2 2012.3.21
`
`(19) Japan Patent Office (JP)
`
`(12) Japanese Patent (B2)
`
`(11) Japanese Patent Number
`
`(45) Publication date: March 21, 2012
`
`(24) Registration date: January 13, 2012
`
`4901053
`(P4901053)
`
`(51) Int. Cl.
`
`G06Q 20/06 (2012.01)
`G06Q 20/00 (2012.01)
`G06Q 20/02
`(2012.01)
`G06Q 20/36
`(2012.01)
`
`(21) Application number
`
`2016-511243
`(P2002-511243)
`
`(73) Patent Rights
`Holder
`
`FI
`
`G06F 17/60 410C
`G06F 17/60 410E
`G06F 17/60 400
`G06F 17/60 412
`G06F 17/60 432A
`
`Number of claims: 12 (Total of 62 pages)
`
`500277663
`Makoto Jogu
`1-8-4 Gakuenkita, Nara-shi, Nara-ken
`
`(86) (22) Date of application
`(86) International Application
`No.
`(87) International Publication
`Number
`(87) International Publication
`Date
`Examination Request Date
`(31) Priority Rights Claim No.
`
`(32) Priority Date
`(33) Priority Rights Application
`Country
`(31) Priority Rights Claim No.
`
`(32) Priority Date
`(33) Priority Rights Claim
`Country
`(31) Priority Rights Claim No.
`
`(32) Priority Date
`(33) Priority Rights Claim
`Country
`
`June 13, 2001
`PCT/JP2001/005039
`
`W02001/097118
`
`(74) Agent
`
`100104444
`Patent Attorney Hidetsugu Ueba
`
`December 20, 2001
`
`(72) Inventor
`
`Makoto Jogu
`1-8-4 Gakuenkita, Nara-shi, Nara-ken
`
`(72) Inventor
`
`Sadayuki Kou
`2-4-10-402 Heiwa, Minami-ku, Fukuoka-shi, Fukuoka-
`ken
`
`Examiner
`
`Susumu Awa
`
`March 28, 2008
`2000178188
`(P2000178188)
`June 14, 2000
`Japan (JP)
`
`Patent Application
`2000-221240
`(P2000-221240)
`July 21, 2000
`Japan (JP)
`
`2000-402918
`(P2000-402918)
`December 28, 2000
`Japan (JP)
`
`Continued on last page.
`
`(54) [TITLE OF THE INVENTION]
`Payment method using mobile phone, and mobile phone
`(57) [Claims]
`[Claim 1]
`A payment system equipped with a mobile phone, a terminal that accepts payments using the mobile phone, and a
`computer that manages the mobile phone and payments made by the terminal;
`wherein the mobile phone comprises
`a means of requesting the computer to generate a one-time identifier to enable the balance of the petty cash account;
`a means of entering the desired transfer amount to be transferred from the original account to the petty cash account;
`a means of transmitting the input transfer amount to the computer;
`a means of receiving the one-time identifier and the balance of the petty cash account sent from the computer;
`
`GOOG-1006
`Google LLC v. RFCyber Corp. / Page 1 of 121
`
`

`

`JP 6280656 B2 February 14, 2018
`
`(2)
`
`a means of storing the received one-time identifier;
`a means of storing the balance of the received petty cash account;
`a means for determining whether or not the one-time identifier stored in the mobile phone is valid;
`as a result of the determination of the one-time identifier, if the one-time identifier is valid, a means for receiving the
`payment amount transmitted from the terminal;
`a means for determining whether or not the received payment amount is within the balance of the petty cash account stored
`in the mobile phone;
`as a result of the determination of the payment amount, if the payment amount is within the balance of the petty cash
`account, a means for transmitting the received one-time identifier to the terminal, and
`a means for updating the balance of the petty cash account by subtracting the payment amount from the balance of the
`retail account;
`the terminal comprises
`a means of transmitting the payment amount to the mobile phone,
`a means for receiving the one-time identifier sent from the mobile phone, and
`a means for transmitting the payment amount and the received one-time identifier to the computer;
`the computer comprises
`a means of storing the balance of a petty cash account,
`a means for receiving the transfer amount sent from the mobile phone,
`a means of generating a one-time identifier in response to a request from the mobile phone,
`a means of updating the balance of the petty cash account stored in the computer by transferring the received transfer
`amount from the original account to the petty cash account,
`a means of transmitting the generated one-time identifier and the balance of the updated retail account to the mobile phone,
`a means of receiving the payment amount and one-time identifier sent from the terminal, and
`a means of recording the received payment amount and one-time identifier.
`[Claim 2]
`The payment system according to claim 1, wherein the mobile phone further comprises a means for transmitting
`identification information necessary for user authentication to the computer
`[Claim 3]
`The payment system according to claim 2, wherein the identification information comprises user-specific information
`unique to the user.
`[Claim 4]
`The payment system according to claim 3, wherein the mobile phone further comprises a means for storing the user-
`specific information.
`[Claim 5]
`The payment system according to claim 3, wherein the user-specific information comprises the telephone number of the
`mobile phone.
`[Claim 6]
`The payment system according to claim 5, wherein the user-specific information further comprises a password.
`[Claim 7]
`The payment system according to claim 3, wherein the user-specific information comprises a user identifier given to the
`user in advance.
`[Claim 8]
`The payment system according to claim 7, wherein the user-specific information further comprises a password.
`[Claim 9]
`The payment system according to claim 3, wherein the identification information further comprises telephone-specific
`information specific to the mobile phone.
`[Claim 10]
`The payment system according to claim 9, wherein the mobile phone further comprises a means for storing the phone-
`specific information.
`[Claim 11]
`The payment system according to claim 10, wherein the phone-specific information comprises the serial number of the
`mobile phone.
`[Claim 12]
`The payment system according to claim 10, wherein the phone-specific information comprises the subscriber identifier of
`the mobile phone.
`
`GOOG-1006
`Google LLC v. RFCyber Corp. / Page 2 of 121
`
`

`

`JP 6280656 B2 February 14, 2018
`
`(3)
`
`[Detailed Description of the Invention]
`Technical Field
`The present invention relates to a mobile phone and a payment method using the mobile phone; more specifically, it
`relates to a service that mediates payments at virtual stores and brick-and-mortar stores on the Internet.
`Prior Art
`Currently, various payment methods using mobile phones have been proposed. Nikkei Electronics "Payment by
`Mobile Phone" No. 769, published by Nikkei BP (May 8, 2000), pageS109 to 129 describes mobile phones that are
`equipped with IC cards. In this mobile phone, the credit card number is recorded in advance on the IC card in a
`secure state, and the credit card number is encrypted and transmitted at the time of payment. Also described is a
`mobile phone equipped with readers / writers for a contactless IC card. In this mobile phone, electronic values such
`as the frequency of a prepaid card are downloaded and transferred wirelessly to a contactless IC card by a reader /
`writer. The user makes a payment using this contactless IC card.
`Although the credit card number is encrypted on the mobile phone equipped with the above IC card, since the credit
`card number is still being sent, e-commerce on the Internet is not sufficiently secure.
`On the other hand, in a mobile phone equipped with the above reader / writer, the user must carry a contactless IC
`card with the mobile phone. In addition, readers / writers experience many problems such as large size and high cost.
`Aside from this, various payment methods using mobile phones have been proposed. In such cases, credit inquiry is
`required at the time of payment, and payment data need to be sent. There is a problem therein in that it is necessary
`to emit radio waves at the time of payment, it cannot be used outside the radio wave range, and it takes time to
`complete the payment.
`Disclosure of Invention
`The present invention has been developed to solve the above-stated problems. An object of the present invention is
`to provide a mobile phone having high security and ease of use, and a payment method using the mobile phone.
`The payment method using a mobile phone according to the present invention is a method of mediating payment
`between a seller and a buyer who is a user of the mobile phone, comprising, in a server computer that has an account
`for each user to store the user's money, a step of receiving the amount sent from the mobile phone, a step of
`depositing the received amount into the user's account and updating the balance of that account, a step of sending the
`renewed account balance to the mobile phone, a step of receiving the payment amount, a step of subtracting the
`received payment amount from the balance of the account, and a step of paying the received payment amount to the
`seller. Here, the server computer may be installed in a mobile phone office (company), a financial institution
`(company), a payment institution (company), etc., but its location is not particularly limited.
`On the other hand, the mobile phone according to the present invention is a mobile phone used for payment between
`a seller and a buyer who is a user of the mobile phone, wherein an account for accumulating the user's money is set
`up on the server computer for each user, the mobile phone equipped with a means for inputting a desired amount to
`be credited to the account according to the user's operation, a transmission / reception means that sends the entered
`amount to the computer of the mobile phone office and receives the balance of the virtual account sent from the
`server computer, and a means of remembering the balance of the received account.
`According to this payment method or mobile phone, the user uses the mobile phone to transmit the desired amount
`to the financial institution or payment institution through the mobile phone office or mobile phone office. The
`mobile phone office, financial institution or payment institution receives the amount transmitted from the mobile
`phone, deposits the amount into the user's account, updates the balance of the account and sends it to the mobile
`phone. The mobile phone receives and stores the balance of the account sent from the mobile phone office.
`Therefore, the user can make a payment by using the mobile phone like a wallet. Here, it is not necessary to send a
`credit number or the like, so security is high. In addition, it is easy to use because it is not necessary to carry an IC
`card or the like.
`Best Mode for Carrying Out the Invention
`
`GOOG-1006
`Google LLC v. RFCyber Corp. / Page 3 of 121
`
`

`

`JP 6280656 B2 February 14, 2018
`
`(4)
`Hereinafter, embodiments of the present invention will be described in detail with reference to drawings. The same
`or corresponding parts in the drawings are designated by the same reference numerals and the description thereof is
`not repeated.
`[First Embodiment]
`1. Service overview
`An embodiment of the present invention relates to a computer system for realizing a new service provided by a
`mobile phone company (referred to as "wallet service," hereinafter simply referred to as "the present service"). The
`present service allows you to use your mobile phone like a wallet. The outline of this service will be described
`below.
`When purchasing a mobile phone, a credit card number, cash card number, etc. is registered with the mobile phone
`company in addition to the bank account with which the call charges are deducted. The mobile phone company sets
`up a virtual account for each mobile phone user. The user requests the mobile phone company to deposit the
`advance payment into the virtual account before the payment by using the mobile phone. The mobile phone
`company uses a pre-registered bank account, credit card number, cash card number, etc. to request the user for the
`advance payment. The payment method of the advance payment can be selected by the user. After requesting the
`prepayment, the mobile phone company deposits the prepayment into the virtual account and then sends the balance
`of the virtual account to the mobile phone. The mobile phone stores the balance of the transmitted virtual account.
`The user uses this mobile phone instead of a wallet to make a payment at a virtual store or at a brick-and-mortar
`store on the Internet. The store charges the mobile phone company.
`2. Advance payment method
`Next, four types of advance payment methods will be described.
`2-11. When paying together with the call charge
`FIG. 1 is a schematic diagram showing the transfer of funds when the advance payment is paid together with the call
`charge.
`As shown in FIG. 1, the mobile phone company (mobile phone office) 10 is provided with a personal information
`database 11. The personal information of each user 12 is registered in the personal information database 11.
`Specifically, a virtual account 110 is set up to accumulate advance payments (advance payments for mobile phone
`companies). In addition to the telephone numbers of mobile phoneS13, e-mail addresses, passwords, usage status,
`key codes, account numbers, credit card numbers, debit card numbers, etc. are registered in advance.
`First, the user 12 uses the mobile phone 13 to transmit the desired prepaid amount and the payment method (here,
`“added to the call charge”) to the mobile phone company 10. At this time, the telephone number of the mobile phone
`13 is also transmitted.
`The mobile phone company 10 searches the personal information database 11 based on the transmitted mobile
`phone number, and inquires about the usage status of the virtual account 110 of the user 12. If there is no problem
`with user 12 (if the usage status is "OK"), the mobile phone company 10 adds the sent prepaid amount to the prepaid
`balance of the virtual account 110, and sends the latest updated prepaid balance. On the other hand, if the payment
`of user 12 is delayed or the use of this service is suspended, the usage status is "NG". In this case, the mobile phone
`company 10 notifies the user 12 that the service cannot be used through the mobile phone 13.
`If the user 12 selects "add to call charge" as the payment method as described above, the mobile phone company 10
`sends the usage statement 15 of this service together with the invoice 14 of the basic charge and the call charge to
`user 12.
`The mobile phone company 10 requests the bank 17 of the user 12 to withdraw the usage fee based on the account
`number registered in the personal information database 11. In response to this, the bank 17 transfers the funds from
`the account 16 of the user 12 to the account 19 of the mobile phone company 10 opened in the bank 18.
`2-2. When paying by credit card
`FIG. 2 is a schematic diagram showing the transfer of funds when the advance payment is paid by credit card. In this
`case, as shown in FIG. 2, the user 12 transmits the prepaid amount and the payment method (here, “credit card”) to
`the mobile phone company 10 using the mobile phone 13. If there is no problem with the usage status of the user 12,
`the mobile phone company 10 requests the credit card company 20 for approval based on the credit card number
`registered in advance.
`
`GOOG-1006
`Google LLC v. RFCyber Corp. / Page 4 of 121
`
`

`

`JP 6280656 B2 February 14, 2018
`
`(5)
`
`If the credit company 20 can approve it, the credit company 20 notifies the mobile phone company 10 to that effect.
`In response to this, the mobile phone company 10 updates the prepaid balance of the virtual account 110 and sends
`the latest prepaid balance to the mobile phone 13. On the other hand, if the approval cannot be obtained, the credit
`sales company 20 notifies the mobile phone company 10 to that effect. In response to this, the mobile phone
`company 10 notifies the user 12 that the payment by credit card cannot be made without updating the prepaid
`balance.
`If the payment is approved, the credit sales company 20 transfers the prepaid amount desired by the user 12 to the
`account 19 of the mobile phone company 10. The credit company 20 then requests the bank 17 to withdraw the
`prepaid amount from the user 12's account 16. In response, the bank 17 transfers the funds from the account 16 of
`the user 12 to the credit company 20.
`2-3. When paying with a debit card
`FIG. 3 is a schematic diagram showing the transfer of funds when the advance payment is paid by a debit card. In
`this case, as shown in FIG. 3, the user 12 transmits the prepaid amount and the payment method (here, “debit card”)
`to the mobile phone company 10 using the mobile phone 13.
`If there is no problem with the usage status of the user 12, the mobile phone company 10 requests the bank 17 that
`issued the debit card based on the debit card number registered in advance to transfer the funds. When the transfer
`request is approved, the bank 17 sends the transfer data to the clearing center 21 and notifies the mobile phone
`company 10 of the completion of the transfer. In response to this, the mobile phone company 10 updates the prepaid
`balance and sends the latest prepaid balance to the mobile phone 13. On the other hand, if the bank 17 does not
`approve the transfer request, it notifies the mobile phone company 10 that the transfer cannot be made. In response
`to this, the mobile phone company 10 notifies the user 12 that the payment cannot be made with the debit card
`without updating the prepaid balance.
`The clearing center 21 offsets and aggregates the transfer based on the transfer data transmitted from a large number
`of banks in addition to the bank 17, and transmits the payment data between the banks to the payment bank 22. In
`response, the clearing bank 22 transfers funds from the bank 17 to the merchant bank 23. In response, the merchant
`bank 23 deposits the funds into the account 19 of the mobile phone company 10.
`2-4. When paying by automatic withdrawal
`FIG. 4 is a schematic diagram showing the transfer of funds when the advance payment is paid by automatic
`deduction from the bank account.
`In this case, as shown in FIG. 4, the user 12 uses the mobile phone 13 to transmit the prepaid amount and the
`payment method (here, “automatic withdrawal”) to the mobile phone company 10. If there is no problem with the
`usage status of the user 12, the mobile phone company 10 requests the bank 17 to withdraw the funds based on the
`pre-registered account number. If the withdrawal is possible, the bank 17 notifies the mobile phone company 10 to
`that effect. In response to this, the mobile phone company 10 updates the prepaid balance and sends the latest
`prepaid balance to the mobile phone 13. If the withdrawal is not possible, the bank 17 notifies the mobile phone
`company 10 to that effect. In response to this, the mobile phone company 10 notifies the user 12 that the payment
`cannot be made. Upon receiving the withdrawal request from the mobile phone company 10, the bank 17
`immediately transfers the funds from the account 16 of the user 12 to the account 19 of the mobile phone company
`10. Separately, the usage statement 15 is sent to the user 12 together with the invoice 14.
`3. Payment
`Next, a method of making a payment with the above-mentioned advance payment using the mobile phone 13 will be
`described.
`3-1. Payment at a virtual store on the Internet
`FIG. 5 is a schematic diagram showing a method of making a payment using a mobile phone at a virtual store on the
`Internet. As shown in FIG. 5, the user 12 first orders a product or service from a virtual store 24 on the Internet
`using a mobile phone 13 or a personal computer 40, and the payment method (here, "mobile phone payment") is
`selected. When using the personal computer 40, the user 12 manually inputs the telephone number of the mobile
`phone 13 into the personal computer 40 and transmits the telephone number to the virtual store 24 via the Internet 60.
`Upon receiving the order, the virtual store 24 requests the mobile phone company 10 to charge the payment amount
`based on the transmitted mobile phone number. Upon receiving the billing request, the mobile phone company 10
`notifies the virtual store 24 that the service cannot be used if there is a problem with the usage status of the user 12.
`
`GOOG-1006
`Google LLC v. RFCyber Corp. / Page 5 of 121
`
`

`

`JP 6280656 B2 February 14, 2018
`
`(6)
`
`In response to this, the virtual store 24 notifies the user 12 that the service cannot be used. If there is no problem
`with the usage status of the user 12, the mobile phone company 10 sends an e-mail to the mobile phone 13 of the
`user 12 based on the e-mail address of the user 12 registered in advance. The electronic invoice is for confirming the
`payment from the virtual account 110 to the user 12. In addition, the user 12 who receives the electronic invoice
`selects whether or not to approve the payment. When the user 12 approves the payment, the mobile phone 13 that
`receives the electronic invoice verifies the prepaid balance; if the prepaid balance is less than the payment amount,
`the mobile phone 13 notifies the mobile phone company 10 that the payment cannot be made due to insufficient
`balance. In response to this, the mobile phone company 10 notifies the user 12 through the virtual store 24 that the
`payment cannot be made because the balance is insufficient. When the user 12 cancels or refuses the payment, the
`mobile phone company 10 is notified of the cancellation or refusal of the payment. In response to this, the mobile
`phone company 10 notifies the virtual store 24 that the payment cannot be made because the payment has been
`canceled or rejected. In response to this, the virtual store 24 notifies the user 12 that the payment cannot be made.
`In addition, when the user 12 approves the payment and the result of the verification of the prepaid balance shows
`that the payment amount is within the prepaid balance, the mobile phone company 10 is notified that the payment is
`approved. At this time, the password, mobile phone number, key code, etc. registered in advance in the mobile
`phone company 10 are also transmitted. The mobile phone company 10 searches the personal information database
`11 based on the transmitted mobile phone number, and determines whether or not the transmitted password and key
`code match the pre-registered password and key code, respectively. If the key codes do not match, the mobile phone
`company 10 notifies the user 12 that the service cannot be used because the key code is abnormal, and also notifies
`the user 12 through the virtual store 24 that the payment cannot be made. If both match, the mobile phone company
`10 updates the prepaid balance by subtracting the payment amount from the prepaid balance of the virtual account
`110, and transmits the updated prepaid balance to the mobile phone 13. In response to this, the mobile phone 13
`updates the internal prepaid balance. In addition, the mobile phone company 10 notifies the virtual store 24 of the
`completion of payment. In response to this, the virtual store 24 notifies the user 12 that the payment has been
`completed.
`After that, the virtual store 24 delivers the ordered product to the user 12 or provides the ordered service to the user
`12. The mobile phone company 10 deposits the above payment amount into the virtual store 24. The virtual store 24
`pays the mobile phone company 10 a fee for using this service.
`3-2. Payment at a brick-and-mortar store
`FIG. 6 is a schematic diagram showing a method of making a payment using a mobile phone at a brick-and-mortar
`store. As shown in FIG. 6, at a brick-and-mortar store, the user 12 sets the mobile phone 13 in the reading device
`270 connected to the POS terminal 27. The clerk inputs the amount of the product into the POS terminal 27 and
`calculates the payment amount. This payment amount is transmitted from the POS terminal 27 to the mobile phone
`13 through the reader 270. The mobile phone 3 compares the balance stored inside with the payment amount, and if
`payment is not possible, sends an error message to the POS terminal 27. On the other hand, if payment is possible,
`the mobile phone 13 transmits the mobile phone number and the key code to the POS terminal 27. The mobile phone
`number cannot be entered directly into the POS terminal 27 by hand. The POS terminal 27 that has received the
`mobile phone number and the key code completes the payment and notifies the mobile phone 13 to that effect. Upon
`completion of the payment, the mobile phone 13 stores the payment amount in the internal memory, and the
`payment mode is turned off. After that, the user 12 removes the mobile phone 13 from the reader 270.
`Next, the mobile phone number and key code are transmitted to the mobile phone company 10 together with the
`payment amount. In response to this, the mobile phone company 10 updates the prepaid balance by subtracting the
`payment amount from the prepaid balance of the virtual account 110, and notifies the POS terminal 27 of the
`completion of the payment.
`4. Hardware configuration
`FIG. 7 is a block diagram showing the hardware configuration of the mobile phone 13 and the server computer
`(hereinafter, simply referred to as a server) 30 installed in the mobile phone company 10.
`As shown in FIG. 7, the mobile phone 13 comprises a data processing unit 131 composed of a CPU, a RAM 132, a
`ROM 133 such as an EEPROM, an antenna 134, a transmission / reception unit 135, an input device 136 such as a
`numeric keypad and a cursor key, a display device 137 such as a liquid crystal display, a battery 138, and an
`interface (I / F) unit 139.
`
`GOOG-1006
`Google LLC v. RFCyber Corp. / Page 6 of 121
`
`

`

`JP 6280656 B2 February 14, 2018
`
`(7)
`
`The mobile phone 13 is attached to the power adapter 140, and current is supplied from the power adapter 140 to the
`battery 138 through the I / F unit 139 to charge the battery 138. The data processing unit 131 executes a normal
`mobile phone function by using the RAM 132, the RO M 133, the transmission / reception unit 135, the input device
`136, the display device 137, and the I / F unit 139, and also performs the payment function described later.
`The server 30 installed in the mobile phone company 10 is equipped with a data processing unit 301 composed of
`CPU and a database 302. The database 302 comprises a personal information database 11, a usage history database
`28, and a payment history database 29. The data processing unit 301 executes a payment function described later
`using the database 302. The data processing unit 301 is connected to the radio base station 303. Radio waves are
`transmitted and received between the antenna 304 of the radio base station 303 and the antenna 134 of the mobile
`phone 13. The usage history database 28 is a log file for recording the details of data transactions with the mobile
`phone 13. Specifically, the deposit / withdrawal date / time, deposit / withdrawal amount, balance, etc. of the virtual
`account 110 are recorded. The payment history database 29 is a log file for recording the details of data transactions
`with stores. Specifically, the payment date and time, the payment amount, and the like are recorded.
`5. Processing operation at the time of prepayment
`5-1. When paying together with the call charge
`FIG. 8 is a flowchart showing the operation of the mobile phone 13 and the server 30 when the advance payment
`shown in FIG. 1 is paid together with the call charge. FIG. 9 is a transition diagram of the display screen displayed
`on the display device 137 of the mobile phone 13 in this case.
`First, the data processing unit 131 of the mobile phone 13 displays the screen D1 shown in FIG. 9 on the display
`device 17 and prompts the user 12 to enter the password. When the user 12 operates the input device 136 and inputs
`the password, the input device 136 gives the input password to the data processing unit 131 (S101).
`Subsequently, the data processing unit 131 verifies the entered password by comparing the entered password with
`the password registered in advance in the RAM 132 or the ROM 133 (S102). If the entered password is incorrect,
`the data processing unit 131 displays the screen D2 shown in FIG. 9 on the display device 137 (S103). On the other
`hand, if the entered password is correct, the data processing unit 131 displays the screen D3 shown in FIG. 9 on the
`display device 137, and prompts the user 12 to select one from among "(cid:1720) 1 (cid:1730) pay money", "(cid:1720) 2 (cid:1730) "look in your
`wallet" and "(cid:1720) 3 (cid:1730) put money in your wallet". When the user 12 operates the input device 136 and selects "(cid:1720) 3 (cid:1730)
`put money in your wallet", the data processing unit 131 displays the screen D4 on the display device 137 and
`prompts the user 12 to input the prepaid amount. At this time, if there are no unreported data (details will be
`described later), the prepaid balance stored in RAM132 is displayed as the current balance. If there are no
`unreported data, the unreported payment amount is subtracted from the prepaid balance stored in RAM 132 to
`calculate the true prepaid balance and this is displayed as the current balance. When the user 12 operates the input
`device 136 to input the desired prepaid amount, the input device 136 gives the input prepaid amount to the data
`processing unit 131 (S104).
`Subsequently, the data processing unit 131 displays the screen D5 on the display device 137 and prompts the user 12
`to select a payment method for the prepaid amount. When the user 12 operates the input device 136, in addition to
`the payment method of "adding to the call charge", several payment methods of "credit", "debit card", and
`"automatic withdrawal" are displayed. Here, it is assumed that the user 12 selects the payment method of "adding to
`the call charge".
`In response to this, the input device 136 gives the data processing unit 131 a selection of a payment method of
`"adding to the call charge" (S105).
`Subsequently, the data processing unit 131 gives the selected payment method and the input prepaid amount to the
`transmission / reception unit 135, and the transmission / reception unit 135 transmits these to the mobile phone
`company 10 (S106). At this time, the mobile phone number unique to the user 12 stored in the RO M 133 in advance,
`the key code unique to the mobile phone 13 stored in the ROM 133 in advance, and the unreported data stored in the
`RAM 132, are sent together.
`
`GOOG-1006
`Google LLC v. RFCyber Corp. / Page 7 of 121
`
`

`

`JP 6280656 B2 February 14, 2018
`
`(8)
`
`The mobile phone number is pre-programmed into a ROM 133 such as EEPROM when the mobile phone company
`10 sells the mobile phone 13. The key code is the serial number and the control number unique to each mobile
`phone (referred to as subscriber ID (identifier), phone ID, terminal ID, etc.) when the mobile phone manufacturer
`manufactures the mobile phone that are re-programmed to ROM 133 such as EEPROM. Therefore, the mobile
`phone number is unique to the user 12, and the same mobile phone number can be registered even if the mobile
`phone 13 is replaced. However, the user 12 itself cannot rewrite the mobile phone number; the mobile phone
`company 10 will rewrite it at the request of the user 12. On the other hand, the key code is unique to the mobile
`phone 13. When the serial number is used for the key code, not only the user 12 but also the mobile phone company
`10 cannot overwrite it. When a control number such as the subscriber ID mentioned above is used for the key code,
`the mobile phone company 10 can overwrite it, but the user 12 cannot.
`Subsequently, the data processing unit 131 determines whether or not the previous processing has been completed
`normally (S107), and if the processing has not been completed normally, displays that fact on the display device 137
`(S108), and disconnects (S109). On the other hand, if it ends normally, the connection is temporarily disconnected
`without displaying the abnormal end (S109).
`On the other hand, in the server 30 installed in the mobile phone company 10, the data processing unit 301 receives
`the prepaid amount, the payment method, the mobile phone number and the key code transmitted from the mobile
`phone 13 through the wireless base station 303 (S201).
`Subsequently, the data processing unit 301 searches the personal information database 11 based on the received
`mobile phone number (S202).
`Thereafter, the data processing unit 301 compares the received key code with the key code of the searched personal
`information database 11 and confirms whether or not the key codes match (S203). If the key codes match, the data
`processing unit 301 checks the usage status of the personal information database 11 and determines whether or not
`there is a problem (S204). If the key codes do not match in step S202, or if there is a p