Method for downloading programs on payment terminals and payment terminals
The method addresses memory and security limitations in payment terminals by using a two-stage boot loader and encrypted updates triggered by a specific touchscreen operation, enabling secure and efficient program updates despite limited volatile memory.
Patent Information
- Authority / Receiving Office
- JP · JP
- Patent Type
- Patents
- Current Assignee / Owner
- NIDEC INSTR CORP
- Filing Date
- 2022-10-19
- Publication Date
- 2026-06-17
AI Technical Summary
Existing payment terminals face challenges in updating programs due to limited memory capacity, particularly volatile memory, and security concerns when rewriting programs to non-volatile memory.
A method involving a two-stage boot loader process and a memory data rewriting program that encrypts and decrypts program updates, allowing updates only when a specific touchscreen operation is performed, ensuring the update process is secure and can handle programs larger than volatile memory capacity by dividing and downloading in parts.
Enables secure and efficient program updates on payment terminals with limited memory, maintaining security and operability by separating server operations and ensuring the update process is executed only when a specific operation is performed.
Smart Images
Figure 0007875097000001 
Figure 0007875097000002 
Figure 0007875097000003
Abstract
Description
Technical Field
[0001] The present invention relates to a payment terminal used for online payment and the like, and particularly relates to a method for downloading a program to a payment terminal and a payment terminal capable of executing such a downloading method.
Background Art
[0002] In order to perform online payment at a sales location such as a store, a payment terminal connected to a payment server via a network is used. The payment terminal is configured as, for example, a so-called embedded computer device having a touch screen for input. Since authentication media such as credit cards, prepaid cards, and two-dimensional codes are often used in online payment, the payment terminal may include a reader unit for reading data from the authentication media, and may further include a display provided independently of the touch screen. In the payment terminal, a minimum configuration for functioning as a computer, that is, a processor such as a CPU (Central Processing Unit) that operates based on a program, a volatile memory such as a RAM (Random Access Memory), and a non-volatile memory such as a ROM (Read Only Memory) or a flash memory are mounted on a module board, and this module board is generally attached to a main board. The main board is provided with an I / O (Input / Output) interface for connection to a network, a touch screen, and the like.
[0003] Since payment terminals are computer devices, they require computer programs such as firmware and operating systems (OS) to function, and these programs are written to non-volatile memory. It is desirable to be able to rewrite the programs already written to payment terminals with new versions for functional improvements. However, for security reasons, payment terminals often have a structure that prevents the removal of module boards from the main board, making it difficult to directly write new versions of programs to non-volatile memory. Furthermore, the memory provided in payment terminals, especially volatile memory, has a small capacity, and even if an attempt is made to temporarily store the target program in volatile memory for updating via a network, it may not be possible to store the entire program in volatile memory. To address these challenges, Patent Document 1 discloses a computer device that operates based on firmware, comprising a first ROM storing startup firmware including a startup program for starting a processor such as a CPU and a communication program for server connection, a RAM for temporarily storing data downloaded from a server, and a second ROM for storing control firmware that controls the operation of the computer device. The invention also discloses downloading a program for erasing and writing the control firmware stored in the second ROM, as well as a new version of the control firmware, from the server. Furthermore, Patent Document 1 describes how, when downloading the control firmware, the control firmware is divided and downloaded, stored in RAM, and written from RAM to the second ROM in parallel, thereby enabling the writing of control firmware larger than the RAM capacity to the second ROM. [Prior art documents] [Patent Documents]
[0004] [Patent Document 1] Japanese Patent Publication No. 2002-175193 [Overview of the project] [Problems that the invention aims to solve]
[0005] The technology described in Patent Document 1 enables program updates when the capacity of volatile memory such as RAM is small, but when applied to a payment terminal, there is room for improvement in terms of ensuring security.
[0006] The object of the present invention is to provide a download method that can be applied when downloading a program to a payment terminal with a small memory capacity, particularly a small volatile memory capacity, and that provides sufficient security, as well as a payment terminal capable of executing such a download method. [Means for solving the problem]
[0007] One embodiment of the download method is a method for downloading a program in a payment terminal that performs online payments and is configured as a computer device equipped with a processor that operates on a program, non-volatile memory, volatile memory, and a touchscreen, comprising: a determination step of determining whether a specific operation on the touchscreen has been performed when the payment terminal is powered on; a download step of downloading a memory data rewriting program from a program server to volatile memory when it is determined that a specific operation has been performed; and an update step of, after the download step, causing the processor to execute the memory data rewriting program, thereby downloading and storing a program to be updated, which is at least partially encrypted, from the program server to volatile memory, decrypting the encrypted portion of the program to be updated, and then rewriting the program in the non-volatile memory with the program to be updated stored in the volatile memory.
[0008] In one embodiment of the download method, at least a portion of the program to be updated is encrypted, and the memory data rewriting program itself, which performs the program rewriting process on the payment terminal, including the decryption process, is also downloaded. By ensuring that at least a portion of the memory data rewriting program does not exist on the payment terminal during normal operation, unauthorized analysis of the program to be updated and rewriting of program data in non-volatile memory by malicious programs can be suppressed, thereby enhancing security when updating programs on the payment terminal. Furthermore, since the update process is executed only when a specific operation is performed on the touchscreen when the payment terminal is powered on, security can be improved in this respect as well.
[0009] In one embodiment of the download method, it is preferable that the processor normally starts the payment terminal based on the program in non-volatile memory when it is determined in the determination step that a specific operation has not been performed. With this configuration, it is possible to select between normal startup and execution of update processing depending on whether a specific operation is performed when the power is turned on, improving the maintainability of the payment terminal. Furthermore, when normally started, the operability of the payment terminal is improved by configuring it to communicate with the payment server after normal startup to perform online payment. In the network to which the payment terminal is connected, the program server and the payment server may be provided independently. By providing these servers independently, it is possible to separate the server operation entities, such as the payment terminal manufacturer operating the program server and the payment service provider operating the payment server.
[0010] In one embodiment of the download method, when the power is turned on, a first boot loader stored in the non-volatile memory built into the processor is started, and the first boot loader starts a second boot loader stored in non-volatile memory, and the determination step and the download step are executed by the second boot loader. By configuring it in this way, it becomes possible for the boot rotor to perform complex processing, including the startup of the normal operation program, and the program size limitations for the program that executes the determination step and the download step are relaxed.
[0011] In one embodiment of the download method, during the update process, the program to be updated is divided into multiple rewrite data, one set of rewrite data is downloaded and stored in volatile memory, and the program in non-volatile memory is rewritten with the stored set of rewrite data. This process can be repeated until the program in non-volatile memory is rewritten by the entire program to be updated. By adopting such a configuration, it becomes possible to perform the update process even when the capacity of volatile memory is small compared to the size of the program to be updated.
[0012] In one embodiment of the download method, the payment terminal can be shut down or restarted after the update process is complete. This configuration ensures that the payment terminal operates reliably with the updated program, and also improves security by ensuring that the memory data rewriting program stored in volatile memory is reliably erased.
[0013] One embodiment of a payment terminal is a payment terminal that connects to a payment server to perform online payments, and comprises a processor that operates based on a program, non-volatile memory, volatile memory, and a touchscreen connected to the processor, the non-volatile memory stores a boot loader that the processor executes after the payment terminal is powered on, and a program necessary for performing online payments, the boot loader causes the processor to execute a determination process to determine whether a specific operation on the touchscreen has been performed, a download process to download a memory data rewriting program from the program server to the volatile memory when it is determined that the specific operation has been performed, and a startup process to start the memory data rewriting program, the memory data rewriting program causes the processor to execute a process to download and store a program to be updated, which is at least partially encrypted, from the program server to the volatile memory, a process to decrypt the encrypted portion of the program to be updated, and a process to rewrite the program in the non-volatile memory with the program to be updated stored in the volatile memory.
[0014] In one embodiment of a payment terminal, at least a portion of the program to be updated is encrypted, and the memory data rewriting program itself, which performs the program rewriting process on the payment terminal, including the decryption process, is also downloaded so that at least a portion of the memory data rewriting program does not exist on the payment terminal during normal operation. This suppresses unauthorized analysis of the program to be updated and rewriting of program data in non-volatile memory by malicious programs, thereby enhancing security when updating programs on the payment terminal. Furthermore, since the update process is executed only when a specific operation is performed on the touchscreen when the payment terminal is powered on and before the normally operating program starts, security is also improved in this respect.
[0015] In one embodiment of a payment terminal, it is preferable that the boot loader, when it determines in the determination process that a specific operation has not been performed, instructs the processor to normally start the program in non-volatile memory. With this configuration, it is possible to select between normal startup and the execution of an update process depending on whether a specific operation is performed when the power is turned on, thereby improving the maintainability of the payment terminal. [Effects of the Invention]
[0016] According to the present invention, even in payment terminals with limited memory capacity, particularly limited volatile memory capacity, it becomes possible to update programs stored in the payment terminal, such as firmware and the operating system, online while maintaining sufficient security. [Brief explanation of the drawing]
[0017] [Figure 1] This is a block diagram showing a payment terminal as one embodiment of the present invention. [Figure 2] This is a flowchart showing the operation of a payment terminal. [Figure 3] This figure shows an example of the operation to switch to update mode. [Figure 4] This is a flowchart explaining the update process. [Modes for carrying out the invention]
[0018] Next, embodiments of the present invention will be described with reference to the drawings. Figure 1 is a block diagram showing the configuration of a payment terminal according to one embodiment of the present invention. The payment terminal 10 shown in Figure 1 is used to perform online payments by connecting to a payment server 31 via a network 30, and includes a touchscreen 12 operated by the user's finger or the like for input, a display 13 provided independently of the touchscreen 12 to present information to the user, and a reader unit 14 that reads data from an authentication medium. The authentication medium is, for example, a credit card, a prepaid card, or a two-dimensional code. When the authentication medium is a card medium such as a credit card or a prepaid card, the reader unit 14 is configured as a magnetic card reader or an IC card reader, depending on whether the card medium is a magnetic card or an IC card. When the authentication medium is a two-dimensional code such as a QR code (registered trademark), the reader unit 14 is configured as a camera that reads the two-dimensional code. Smartphones and smartwatches that perform contactless short-range communication can also be used as authentication mediums, and when such authentication mediums are used, a reader unit 14 that is compatible with such authentication mediums is used. Of course, it is preferable that the reader unit 14 be configured to support multiple types of authentication media.
[0019] Inside the main body of the payment terminal 10, a main board 15 is provided. On the main board 15, an I / O interface 16 is provided, and a module board 20 is attached. Since the payment terminal 10 is a computer device, the module board 20 is provided with a minimum configuration for functioning as a computer device, that is, a volatile memory 23 that is composed of a CPU 21, a non-volatile memory 22, and a RAM, etc., and functions as a main storage device connected to the CPU 21. The CPU 21 is a processor that operates based on a program, and a microprocessor, MPU (microprocessing unit), etc. may be used instead of the CPU 21. The non-volatile memory 22 is composed of a rewritable ROM or flash memory, and firmware, an OS, various application programs, etc. for operating the payment terminal 10 are also stored in the non-volatile memory 22. The non-volatile memory 22 also functions as an external storage device in the payment terminal as a computer device. In the module board 20, the CPU 21, the non-volatile memory 22, and the volatile memory 23 are interconnected via an internal bus 24. The CPU 21 is of a one-chip configuration and, in addition to an arithmetic unit 25 generally provided in a CPU or a microprocessor, etc., has a non-volatile storage section 26 that is a very small-capacity non-volatile storage area.
[0020] The module board 20 is electrically connected to the main board 15 via a connection section 27. As a result, the internal bus 24 of the module board 20 is also electrically connected to the I / O interface 16 on the main board 15. The I / O interface 16 constitutes an interface for the touch screen 12, the display 13, and the reader section 14, and also functions as a network interface for the network 30. A pair of connectors can be used in the connection section 27 to make the module board 20 removable from the main board 15. However, for improving the security in the payment terminal 10, it is preferable to solder the module board 20 to the main board 15 in the connection section 27 so that the two are not easily separated.
[0021] Next, we will explain the operation of the payment terminal 10, particularly its operation when powered on. The payment terminal 10 operates by the CPU 21 executing firmware and the OS stored in the non-volatile memory 22. However, the firmware and OS cannot be executed immediately when powered on; the environment for executing the firmware and OS must be prepared before execution can begin. For this purpose, a program called a boot loader is provided, and the CPU 21 first executes the boot loader. In the payment terminal 10 shown in Figure 1, the boot loader is divided into two parts: a first boot loader stored in the non-volatile memory 26 of the CPU 21 and a second boot loader stored in the non-volatile memory 22. The first boot loader is executed first when the CPU 21 starts up due to power-on or when the CPU 21 is reset. After performing minimal processing such as initializing each memory, it starts the second boot loader. By executing the second boot loader, the CPU 21 sets up the environment of the payment terminal 10 and then starts the firmware and OS. In the payment terminal 10 of this embodiment, programs such as firmware and the OS stored in the non-volatile memory 22 can be updated online before the firmware and OS are started. Therefore, the second boot loader also includes program code for performing online updates of the firmware and OS. Updating programs such as firmware and the OS online before the firmware and OS are started is called an update process, and the mode in which the update process is performed among the processing modes of the payment terminal 10 is called the update mode.
[0022] Figure 2 is a flowchart showing the operation of the payment terminal 10. When the power of the payment terminal 10 is turned on, first, in step 101, the first bootloader stored in the non-volatile memory unit 26 in the CPU 21 is started. By executing the first bootloader, the CPU 21 initializes the memory in step 102 and then starts the second bootloader in step 103. In the memory initialization of step 102, the non-volatile memory 22 and the volatile memory 23 are allocated to specific addresses within the memory space of the CPU 21, and the content of the volatile memory 23, which was indeterminate due to power-on, is cleared.
[0023] When the second bootloader is started in step 103, by executing the second bootloader, the CPU 21 determines in step 104 whether an operation for transitioning the payment terminal 10 to the update mode has been performed. The operation for transitioning to the update mode is, for example, an operation on the touch screen 12, and is an operation that is not normally performed on the touch screen 12 in the payment terminal 10 and is a predefined operation. As an example, when the user moves their finger along the trajectory indicated by the dashed line in Figure 3 on the touch screen 12 immediately after power-on, it can be determined that the operation for transitioning to the update mode has been performed. Alternatively, when a specific operation such as pressing is performed on the touch screen 12 at the time of power-on, it can also be determined that the operation for transitioning to the update mode has been performed. When the operation for transitioning to the update mode has been performed, based on the second bootloader, the CPU 21 communicates with the program server 32 on the network 30 to download a program for rewriting memory data in step 105, starts the program, and ends the processing as the second bootloader. As a result, next, the CPU 21 executes the update processing described later in step 106, and then executes the process of turning off the power of the payment terminal 10 in step 107. Thereby, the payment terminal 10 is in the power-off state and a series of processes ends.
[0024] If the operation to switch to update mode is not performed in step 104, after the second boot loader completes its processing as prescribed, in step 111, the payment terminal 10 starts up normally using the firmware or OS in the non-volatile memory 22, and the payment terminal 10 becomes capable of sending and receiving payment data to and from the payment server 31 via the network 30. In this state, the CPU 21 performs normal payment processing as a payment terminal 10, as shown in step 112, and in step 113, it determines whether the user has instructed a power off (i.e., shutdown). If a power off is not instructed, the payment processing shown in step 112 is repeated. On the other hand, if a power off is instructed in step 113, the CPU 21 proceeds to step 107 and performs the process of turning off the power of the payment terminal 10.
[0025] Next, the update process will be explained in detail. In this embodiment, the program to be updated is the program stored in the non-volatile memory 22, excluding the second boot loader. The size of the program to be updated may be larger than the capacity of the volatile memory 23, and it may not be possible to store it in the volatile memory 23 in a single download from the program server 32. Therefore, in this embodiment, the program to be updated is divided into multiple small program data files so that it can be stored in the volatile memory 23, and downloaded to the payment terminal 10. The small program data obtained by dividing the program to be updated is called rewritten data. In the update process, one set of rewritten data is downloaded from the program server 32 and stored in the volatile memory 23, and the non-volatile memory 22 is rewritten with this stored rewritten data. This process is repeated so that the entire program to be updated stored in the non-volatile memory 22 is overwritten with the new version of the program. Furthermore, since security must be ensured for the payment terminal 10, the program to be updated is encrypted, and the encrypted program is downloaded to the payment terminal 10. Encrypting the program and decrypting the encrypted program takes computation time, which hinders the speed of the program update process, so only a part of the downloaded program may be encrypted instead of the entire program. If the program to be updated is divided into multiple rewrite data as described above, then, for example, encrypted and unencrypted rewrite data may be downloaded alternately, so that approximately 50% of the program to be updated as a whole is downloaded encrypted.
[0026] To realize the update process in this embodiment, the memory data rewriting program downloaded to the payment terminal 10 prior to the update process consists of a program portion that downloads and stores the rewrite data from the program server 32 into the volatile memory 23, and transfers and writes the rewrite data stored in the volatile memory 23 to the non-volatile memory 22, and a program portion that decrypts the encrypted rewrite data stored in the volatile memory. This memory data rewriting program is then executed by the CPU 21 while it is downloaded from the program server 32 into the volatile memory 23 and expanded on the volatile memory 23.
[0027] Figure 4 is a flowchart of the update process. When the memory data rewriting program is downloaded to the volatile memory 23 by the second boot loader, the memory data rewriting program is started in step 121. By executing the memory data rewriting program, the CPU 21 connects to the program server 32 in step 122, using a network address such as an IP address already defined in the program. Then, in step 123, the CPU 21 receives one set of rewrite data from the program server 32 and stores it in the volatile memory 23. If the rewrite data is encrypted, the CPU 21 decrypts the rewrite data in step 124. After that, in step 125, the CPU 21 transfers the rewrite data on the volatile memory 23 to the non-volatile memory 22 and rewrites the program in the non-volatile memory 22. Then, in step 126, the CPU 21 determines whether it has finished receiving all the data of the program to be updated. If there is any rewrite data that has not been received and downloaded, the process is repeated from step 123 to perform the same process for the next set of rewrite data. On the other hand, if the CPU 21 determines in step 126 that it has received all the data to be rewritten, in step 127 the CPU 21 disconnects communication with the program server 32 and, in step 128 to prevent misuse of the memory data rewriting program, erases the memory data rewriting program stored in the volatile memory 23 and terminates the update process. Once the update process is complete, as shown in Figure 2, the CPU 21 executes a process to shut down the payment terminal 10 in step 107. Note that when shutting down the payment terminal 10 after the update process, a restart may be performed by turning the power off and then on again.
[0028] In the update process described above, the memory data rewriting program exists only in volatile memory 23, and since the power is cut off in step 107 after the update process, the memory data rewriting program may be erased by the power cut off after the update process without executing step 128. If the program is stored in non-volatile memory 22 in an encrypted state and decryption is performed when the program is executed, the decryption program portion of the memory data rewriting program can be kept resident in volatile memory 23 or stored in non-volatile memory 22 without being erased.
[0029] In this embodiment, the program server 32 can be configured, for example, as a server used in an NFS (Network File System) operating on a network. In the configuration shown in Figure 1, the payment server 31 and the program server 32 are provided separately on the network 30, but the payment server 31 and the program server 32 can also be consolidated into a single server. However, the payment server 31 is generally operated by a payment service provider and may exist in multiple locations on the network, while the programs provided by the program server 32 are expected to be specific to each payment terminal 10 model, requiring the manufacturer of the payment terminal 10 to be involved in its operation. Therefore, it is preferable to provide the payment server 31 and the program server 32 separately.
[0030] As described above, the payment terminal 10 of this embodiment allows for updates to its firmware, OS, and other programs while maintaining security and without being limited by the memory capacity of the payment terminal 10. [Explanation of Symbols]
[0031] 10...Payment terminal, 12...Touchscreen, 13...Display, 14...Reader unit, 15...Main board, 16...I / O interface, 20...Module board, 21...CPU, 22...Non-volatile memory, 23...Volatile memory, 24...Internal bus, 25...Arithmetic unit, 26...Non-volatile storage unit, 27...Connection unit, 30...Network. 31...Payment server, 32...Program server.
Claims
1. A method for downloading a program for a payment terminal that performs online payments, configured as a computer device equipped with a program-based processor, non-volatile memory, volatile memory, and a touchscreen, A determination step to determine whether a specific operation on the touchscreen was performed when the payment terminal was powered on, When it is determined that the aforementioned specific operation has been performed, a download step is performed in which a program for rewriting memory data is downloaded from the program server to the volatile memory. After the download step, the update step involves causing the processor to execute the memory data rewriting program, thereby downloading and storing the program to be updated, which is at least partially encrypted, from the program server into the volatile memory, decrypting the encrypted portion of the program to be updated, and then rewriting the program in the non-volatile memory with the program to be updated stored in the volatile memory. A download method that includes [this feature].
2. The download method according to claim 1, wherein, when the determination step determines that the specific operation has not been performed, the processor normally starts the payment terminal based on the program in the non-volatile memory.
3. The download method according to claim 2, wherein the payment terminal communicates with the payment server after normal startup to perform the online payment.
4. The download method according to claim 3, wherein the program server and the payment server are independently provided in the network to which the payment terminal is connected.
5. When the power is turned on, the first boot loader stored in the non-volatile memory built into the processor is started, and the first boot loader starts the second boot loader stored in the non-volatile memory. The download method according to claim 1 or 2, wherein the determination step and the download step are performed by the second boot loader.
6. The download method according to claim 1 or 2, wherein in the update step, the program to be updated is divided into multiple rewrite data, one set of rewrite data is downloaded and stored in the volatile memory, and the program in the non-volatile memory is rewritten with the stored one set of rewrite data, and this process is repeated until the program in the non-volatile memory is rewritten by the entire program to be updated.
7. The download method according to claim 1 or 2, wherein the payment terminal is shut down or restarted after the completion of the update process.
8. A payment terminal that connects to a payment server to perform online payments, A processor that operates based on a program, Non-volatile memory, volatile memory, and touchscreen connected to the aforementioned processor, It has, The non-volatile memory stores the boot loader that the processor executes after the payment terminal is powered on, and the programs necessary for executing the online payment. The boot loader causes the processor to perform a determination process to determine whether a specific operation on the touchscreen has been performed, a download process to download a memory data rewriting program from the program server to the volatile memory when it is determined that the specific operation has been performed, and a startup process to start the memory data rewriting program. The memory data rewriting program causes the processor to perform the following processes: download a program to be updated, which is at least partially encrypted, from the program server to the volatile memory and store it there; decrypt the encrypted portion of the program to be updated; and rewrite the program in the non-volatile memory with the program to be updated stored in the volatile memory.
9. The payment terminal according to claim 8, wherein the boot loader, when it determines in the determination process that the specific operation has not been performed, causes the processor to normally start the program necessary for executing the online payment in the non-volatile memory.