JP2010122806A - Ic card settlement terminal, controller thereof, and program - Google Patents

Abstract

<P>PROBLEM TO BE SOLVED: To easily cope with even a case where kinds of electronic money that can be used in each terminal are different, and to solve a security problem. <P>SOLUTION: A main controller 11 stores multiple kinds of brand applications 25 (A, B, ... n). An application management unit 21 starts only preset brand applications among the multiple brand applications 25 as initial processing to establish connection. This start is performed using an execution file path generated according to registered information and a prescribed rule. <P>COPYRIGHT: (C)2010,JPO&INPIT

Description

  The present invention relates to a cashless payment system using electronic money, and more particularly to an IC card payment terminal that can handle a plurality of types of IC cards.

  In a cashless payment system using electronic money using a non-contact IC card or a mobile phone with a non-contact IC card function (hereinafter referred to as an IC card), payment processing to the IC card and usage amount The IC card settlement terminal having the IC card reader / writer (R / W) performs the access process to the IC card including the subtracting process in accordance with an instruction from a host terminal such as a POS register.

  Here, there are currently a plurality of types of IC cards. That is, for electronic money, electronic money brands with different specifications are prescribed by each company, IC cards for electronic money are issued, and software for portable terminals is released. That is, a plurality of IC card issuing / settlement companies issue and manage their own brand IC cards. Recently, there is an increasing need for a multi-brand payment terminal that can use (a plurality of types of) electronic money of a plurality of brands with a single payment terminal.

  In such an IC card settlement terminal that can handle a plurality of types of IC cards, a processing function for each brand handled by the terminal itself is required. This is because, for example, the communication with the IC card is a secret communication (encrypted communication), so key information for that purpose is necessary. However, when dealing with multiple brands, the key information for each brand is retained. There is a need to.

  The main processing function of the IC card payment terminal is to deduct the usage amount from the IC card held by the customer or add the amount, and generate detailed information (transaction information) indicating the result of the payment processing, etc. Recording and sending the detailed information to the center server of each electronic money brand company (IC card issuing / settlement company).

  As described above, communication with the IC card is encrypted to enhance security, and the terminal needs to hold confidential information such as a key for encryption / decryption. Different for each money brand. Moreover, since the specifications of the IC card are different for each brand, the IC card read / write method is also different. Even when the transaction information is transmitted to the center server of each company, the communication specification is different as well as the connection destination (IP address of the center server of each company) is different. Therefore, conventionally, processing related to all electronic money brands handled by the settlement terminal is realized on one program, so that one settlement terminal handles electronic money of a plurality of brands.

For example, the prior art disclosed in Patent Document 1 is known.
The invention of Patent Document 1 enables quick settlement processing for a plurality of types of electronic money. Patent Document 1 includes a plurality of settlement units 103A to 103C that perform settlement processing of electronic money that can be handled, and a selection unit that reads information about all the electronic money that can be handled. It is disclosed that the settlement units 103A to 103C are operated in accordance with the result of media detection by the selection unit.
JP 2008-16016 A

  In the prior art, a single program operates confidential information defined by each electronic money brand. Moreover, a single program operates not only confidential information but various information, such as the said transaction information, for example.

  For example, in the case of payment terminals corresponding to electronic money brands A, B and C, for example, processing related to an IC card of brand A (communication with IC card (such as authentication processing and data read / write processing), payment processing) If there is a defect in the program that executes the transaction information transmission process to the center server of the brand A), the service related to the other brands B and C as well as the brand A (processing related to the IC card) In addition, for example, not only the information of brand A but also the information of other brands may be destroyed.

  Also, in electronic money systems, confidential information is an important element for ensuring the safety / reliability of the entire system, and some electronic money brand companies feel resistance to handling confidential information in the form of living with other brands. There are security problems such as requiring individualization of each function related to electronic money.

  In addition, there are cases where the combination of electronic money brands that are desired to be usable differs for each store where a payment terminal is installed. For example, there is a demand to make the electronic money brands A and B available in the store 1, the electronic money brands A and C in the store 2, and the electronic money brands B and C in the store 3. Alternatively, it is conceivable that there is a store that is not limited to the use of a plurality of brands, and that only one arbitrary brand can be used.

  In response to the above requirements, when using one or a plurality of electronic money brands with a single program, it is necessary to create a program for each electronic money brand and its combination. That is, for example, if there are three brands A, B, and C, it is necessary to create and prepare at least seven patterns of programs A, B, C, A + B, A + C, B + C, and A + B + C. Further, it is necessary to verify that each pattern is normally operated every time it is created.

  At present, there are at least three electronic money brands. For this reason, creating many patterns of programs in accordance with the store requirements has problems such as an increase in manufacturing cost and deterioration in quality.

  Further, as a technique for individualizing each program, there is a technique in which a memory area in which each program operates is virtualized and a memory space that can be used by each program is limited. In this method, each application is individualized, and each application has no correlation and can be operated independently. However, each application is selectively operated and controlled by a command from a host device like a payment terminal. In such a case, it has been a problem in comprehensively controlling each application.

Also, in the unlikely event that an illegal program enters the payment terminal, various problems (for example, erasure, falsification, leakage, etc.) may occur due to the operation of this program.
There are also concerns about living with other brands. That is, for example, there are voices concerned about the possibility that other brand applications may try to steal their own brand data.

  The problem of the present invention is that in an IC card payment terminal that can handle multiple brands, even if the corresponding brand or combination of brands is different for each payment terminal, it can be handled simply by setting / changing registration information, An object of the present invention is to provide an IC card payment terminal, its control device, program, etc., which can be controlled so that it cannot substantially operate even if a program enters, and which cannot access data of other brands.

  The IC card payment terminal of the present invention is an IC card payment terminal that can handle a plurality of types of IC cards, and each application module that executes a process corresponding to each IC card corresponding to each of the various IC cards. Manages and controls the application module storage unit to be stored and the various application modules, and controls data access to a storage device, communication control to an external device, or communication control with an IC card according to a request from the application module A common processing unit that executes a registration information storage unit that stores in advance registration information related to any one or more of the various application modules, and an initial process, Various application modules Of having an application module management means for activating an application module that is registered in the registration information storage unit, and a startup application management information storage means for storing management information of the application modules activated.

  In the IC card payment terminal, first, instead of collecting a plurality of types of brand applications on a single program as in the prior art, an application module that is an independent application for each brand is generated and stored in advance. . Then, only the application modules registered in the registration information storage unit are stored. Accordingly, it is possible to easily and freely set a brand or a combination of a plurality of brands for each settlement terminal by simply changing the registration contents of the registration information storage means.

  In addition, for example, the application module management unit generates path information based on the registration information, activates the application module using the path information, and if the activation is successful, the application module management unit Then, the management information relating to the activated application module is stored in the activated application management information storage means.

  For example, the name of the application module is included in the registration information, and the various application modules are stored in a storage location determined in advance based on the name and a predetermined rule. The application module management unit generates the path information indicating the storage location of the application module based on the name included in the registration information and the predetermined rule.

  As described above, if it is a valid application module, it is stored in a storage location determined based on its name and a predetermined rule. Therefore, even if an application other than a valid application module exists, it is not started and a connection is not established.

  Further, for example, the common processing unit performs data access control to the storage device, communication control to an external device, or communication control with an IC card in response to an arbitrary request from an arbitrary application module. Then, it is checked whether or not the management information relating to the request source application module is stored in the activated application management information storage means, and if it is not stored, the request is rejected.

  As described above, applications other than legitimate application modules are controlled so that they are not started, but even if this application is in an operational state, the processing performed through the common processing unit is substantially It will be impossible to execute.

  Also, for example, when the common processing unit performs data access control to the storage device in response to a request from the application module, the name of the access target data file included in the request and the startup application management information A file path for accessing the data file is generated using the path information stored in the storage means, and the data file to be accessed is accessed using the file path.

  With the above configuration, an arbitrary application module (including a valid one) cannot access a data file of another application module.

  According to the IC card payment terminal of the present invention, its control device, program, etc., in the IC card payment terminal that can handle a plurality of brands, even if the corresponding brand or combination of brands is different for each payment terminal, the registration information It can be dealt with just by setting / changing, and it can be controlled so that it can not operate substantially even if a malicious program enters, and other brand data cannot be accessed.

Embodiments of the present invention will be described below with reference to the drawings.
FIGS. 1A and 1B show a configuration example of the IC card settlement terminal of this example.
FIG. 1A shows a configuration example of the IC card payment terminal of this example and a configuration example of the entire cashless payment system including this terminal.

The illustrated IC card settlement terminal 10 includes a main control unit 11, a storage device 12, a communication control unit (for main station) 13, a communication control unit (for center) 14, and a communication control unit (for card) 15.
A communication control unit (vs. main station) 13 is a functional unit that communicates with the main station (upper controller) 1, and a communication control unit (vs. center) 14 communicates with external devices such as the center server 2 via a network (Internet). Etc.), and the communication control unit (counter card) 15 is a functional unit that communicates with the IC card 3. Although these are not specifically described, the main station 1 is a POS terminal, for example, and the center server 2 is a server device of the IC card issuing / settlement company described above. The communication control unit (card) 15 includes, for example, an antenna and a communication circuit. The IC card 3 is not limited to an IC card, and may be, for example, a mobile phone equipped with an IC card function.

FIG. 1B shows a functional configuration example of the main control unit 11 of the IC card settlement terminal 10.
The main control unit 11 includes functional units of a framework 20 and brand applications A, B, C,... N (collectively referred to as brand application 25).

  The framework 20 manages and controls the various brand applications 25 and controls data access to the storage device 12 or external devices (the center server 2 and the main station 1) in response to a request from the brand application 25. It is a common processing unit that executes communication control or communication control with the IC card 3.

  The framework 20 includes functional units such as an application management unit 21, a higher-level communication control unit 22, a data control unit 23, and an R / W communication control unit 24. Although not shown in FIG. 1, in the framework 20, a processing function unit (center communication control unit) that controls the communication control unit (to the center) 14 and executes communication processing with the center server 2. Is also present.

  The application management unit 21 executes management / control of the various brand applications 25. In addition, the above-mentioned “data access control to the storage device 12, communication control to the external device (center server 2 or main station 1), or communication control to the IC card 3” is performed by the data control unit 23 or the upper communication control. This is performed by the unit 22 (or a center communication control unit not shown) or the R / W communication control unit 24.

  The main control unit 11 is a CPU / MPU, and executes a predetermined application program stored in advance in a memory (not shown) or the storage device 12, thereby processing functions of the framework 20 (the respective functional units 21 to 21). 24 processing functions), the processing functions of each brand application 25 are realized. In other words, an application program for causing the main control unit 11 to execute the processes of the flowcharts shown in FIGS. 2, 6 (a), (b), and 7 described later is stored in the storage device 12 or the like. It will be what. Further, table information and the like necessary for these processes are also stored in the storage device 12 or the like. That is, information shown in FIG. 3 and FIG. 4 to be described later is stored in advance in the storage device 12 or the like. Further, table information shown in FIG. 5 to be described later is also generated by processing to be described later and stored in a memory or storage device 12 (not shown).

  Regarding the main control unit 11 having the above-described configuration, first, application modularization by brand is performed. That is, there are independent brand applications A, B, C,... N for each brand. Each brand application 25 is managed and controlled by the framework 20 which is a common processing unit, or various processes (communication with the center server 2) via the framework 20 by issuing a request to the framework 20. Communication with the IC card, access to the storage device 12, communication with the main station 1, etc.).

  That is, each brand application 25 issues a request to the R / W communication control unit 24 when performing communication with an IC card, for example. Accordingly, the R / W communication control unit 24 controls the communication control unit (for card) 15 and executes communication processing with the IC card 3.

  Here, the R / W communication control unit 24 may reject the request (for example, when it is determined to be illegal). The same applies to the other control units 22 and 23 (or the center communication control unit (not shown)).

  The data control unit 23 executes access processing (data read / write, etc.) to the storage device 12 in response to a request from an arbitrary brand application 25. However, the request may be rejected as described above.

  Similarly, the host communication control unit 22 controls the communication control unit (to the main station) 13 and executes communication processing with the main station (the controller) 1 in response to a request from an arbitrary brand application 25. . A center communication control unit (not shown) also controls the communication control unit (to the center) 14 in response to a request from an arbitrary brand application 25 to execute communication processing with an external device such as the center server 2.

  Also, not all of the brand applications A, B, C,... N operate. That is, the application management unit 21 activates only the registered brand application based on pre-registered information (such as installed application information 30 in FIG. 3 described later).

  As described above, in the past, for example, when there are three brands A, B, and C, for example, only A, B only, C only, A + B, A + C, B + C, A + B + C, It was necessary to create "one program". For example, even if it is confirmed that the programs “A only” and “B only” operate normally, the program “A + B” does not always operate normally. For this reason, after creating the program “A + B”, it was necessary to verify it.

  On the other hand, in the configuration of the present example, first, the brand applications A, B, and C, which are individual applications for each brand, are stored in the terminal 10. If only A is registered in the installed application information 30, this terminal 10 is the same as the one in which the "A only" program of the above seven patterns is installed. Similarly, when it is desired to set “A + B”, A and B may be registered in the installed application information 30. The same applies to other patterns. Furthermore, for example, when “A + B + C + D” is desired, the brand application D is additionally stored in the terminal 10 and then A, B, C, and D are registered in the installed application information 30.

  As described above, in the configuration of the present example, with respect to the IC card payment terminal 10 that can support a plurality of brands (a plurality of types of electronic money; a plurality of types of IC cards), the brand ( Even when one or a plurality of brands are different, it is only necessary to create an individual application for each brand, and it is not necessary to create an application for each brand combination. For example, in the above examples A, B, and C, conventionally, it was necessary to create seven patterns, but in this example, only three patterns need be created. Of course, it is not necessary to perform the above verification of the application for each combination pattern of each brand.

  In addition, since an execution file path, which will be described later, is generated and a brand application is started using this execution file path with respect to the startup process, even if an application (such as an illegal program) other than the legitimate brand application 25 enters. This unauthorized program can be prevented from being activated. In addition, even if this malicious program or the like is activated without permission, since it is checked using the table 40 as will be described later, this malicious program or the like becomes substantially inoperable (at least via the framework 20). Processing, that is, processing performed on the IC card, the storage device 12, and the external device cannot be realized).

FIG. 2 shows a flowchart of the startup process of the framework 20.
This process is executed by the application management unit 21.
As shown in FIG. 2, when the framework 20 is activated, first, the application management unit 21 reads information stored in the installed application information table 30 (an example is shown in FIG. 3; described later) ( Step S12). In the figure, it is first determined whether or not there is an unprocessed brand application 25 (step S11), but this determination process may be performed after step S12. The process of step S11 determines whether or not the processes after step S12 have been performed for all brand applications 25 registered in the installed application information table 30.

  Further, the processing in step S12 is to read one of the records in the installed application information table 30. That is, information on any one registered brand application 25 is read out. Every time information related to one brand application 25 (processing target application) is read, the processing from step S13 is executed.

An example of the installed application information table is shown in FIG.
The installed application information table 30 shown in FIG. 31, various information such as application name 32, service type 33, and operation parameter 34.

  Application No. 31 is a serial number (serial number) on the table 30 and has no particular meaning. As described above, each record in the table 30 is a record in which various information related to one brand application 25 is registered. Of course, as described above, not all of the brand applications A to n are registered. This registered information includes an application name 32, a service type 33, and an operation parameter 34 in the illustrated example.

  First, the application name 32 is the name of the brand application 25. In the illustrated example, brand_a, brand_b, and the like are registered. For example, brand_a is the name of the brand application A.

  The service type 33 is the service type of the brand application A. The service type is, for example, identification information used by the main station 1 to specify arbitrary application processing for the IC card payment terminal 10. The operation parameter 34 is not particularly described here and will not be described here.

  Based on the information of one record read in step S12, first, the process of step S13 is performed. That is, for the processing target application, the execution file path of the brand application 25 is generated based on the application name 32 by a predetermined generation method. Then, the brand application 25 is activated using this execution file path (step S13). This execution file path generation process will be described below using an example shown in FIG.

  First, an execution file of each brand application 25 is created in advance and stored in, for example, the storage format shown in FIG. For example, “brand_a.exe” shown in FIG. 4 is an execution file that realizes the function of the brand application A. “Brand_b.exe” is an execution file of the brand application B. Others are the same. Each execution file is stored and managed in advance according to the path shown in FIG. That is, for example, the “brand_a.exe” is stored under the root path “C: / appl / brand_a /”. Here, appl, brand_a, brand_b, etc. are folder names.

  That is, in this example, there are folders for storing each executable file under the common path “C: / appl”, and the name of each folder is the name of the executable file stored in the folder. It has the same name (excluding the extension) (for example, “brand_a” for “brand_a.exe”). That is, for each brand application, there is a folder having the same name as the application name 32 under the appl folder, and an executable file having the same name as the application name 32 (+ specific extension; .exe in this example) is stored in this folder. There is.

  Such rules (rules) are determined in advance (however, the above rules are examples, and the rules may be freely determined), and a predetermined execution is performed under a predetermined route path according to the rules (rule). The executable file of each brand application 25 is stored with the file name. Therefore, in the process of step S13, the execution file path can be generated according to this rule. The execution file path is the root path + execution file name.

  For example, when the application name 32 is “brand_a”, the root path = “C: / appl / brand_a /” and the execution file name = “brand_a.exe” are generated, and the execution file path = “C: /Appl/brand_a/brand_a.exe ”can be generated.

  The application name 32 is not limited to the above example. For example, the application name 32 may be specified by a full path, or may be the address of a physical memory in which each brand application 25 is stored when the file system cannot be used. In this example, the storage path name and the execution file name are generated from the application name 32. However, necessary information such as a path name, an execution file name, and an application name may be separately defined.

  If the brand application 25 to be processed is valid, the executable file should be stored with a predetermined file name in a predetermined storage location in accordance with the above rules (rules). Therefore, if the generated executable file path is used, the brand application 25 to be processed should be able to be activated. On the other hand, an application created and stored by a third party who does not know this rule (rule) should not be able to be activated even if the generated executable file path is used.

  Thus, as described above, in step S13, application startup is attempted using the generated executable file path. If the application cannot be started, it is determined that there is no execution file (NO in step S14), and the process returns to step S11. Note that NO in step S14 also means that the processing target may be a malicious program as described above.

  If all brand applications registered in the installed application information table 30 have been processed (step S11, NO), this process ends. On the other hand, if an unprocessed registered application remains, the process advances to step S12 to execute a process related to the unprocessed registered application.

  On the other hand, when the brand application 25 can be started by the generated execution file path (step S14, YES), after assigning an arbitrary communication port number to the brand application 25 (step S15), this communication port number And the predetermined management information related to the brand application is registered in the application management information table 40 (step S16). That is, the generated route path, communication port number, etc. are registered. The communication port number may be arbitrarily determined, but a unique number is assigned so as not to overlap. The communication port number is a port number used for communication between the brand application 25 and the framework 20 later (may be considered the same as the port number in TCP / IP). That is, the connection between the framework 20 and the application 25 can be established thereby.

  Conventionally, each application on the terminal 10 (not only the brand application 25 but also all applications; therefore, the framework 20 is included) includes the OS (operating system) of the terminal 10 for each application. A unique ID (application ID) is assigned for management and control.

  The framework 20 can know the application ID of each brand application by the function of the OS. Thus, the framework 20 registers the application ID of the brand application 25 that has been activated in the table 40 together with the route path, the communication port number, and the like.

  In the application management information table 40, only the brand application 25 that has been registered in the table 30 in advance and has been activated (the possibility of being an unauthorized program is extremely low) is registered. Therefore, as will be described later, stronger security can be realized by performing a check with reference to this table 40 in the subsequent normal processing.

FIG. 5 shows an example of the application management information table 40.
The application management information table 40 shown in FIG. 5 includes an application No. 41, an application ID 42, a service type 43, a framework-application communication port number 44 (hereinafter referred to as communication port number 44 for short), and a route path 45. Consists of various information.

  Application No. 41 is a serial number or the like on the table 40 as with the application No. 31 and is arbitrarily assigned. The service type 43 corresponds to the service type 33. Therefore, in step S <b> 16, the service type 33 of the processing target brand application is stored in the service type 43. The route path 45 stores the route path generated in step S13. For example, in the above example, “C: / appl / brand_a /” is stored in the root path 45. As described above, the application ID 42 is the application ID of the processing target brand application 25 that has been activated. The communication port number 44 stores the communication port number arbitrarily assigned in step S15.

  For communication between the framework and the application, an event may be used or polling may be used. If an OS is used, message communication provided by the OS may be used. Therefore, the communication port number is an example, and is not limited to this example. In short, information necessary for communication between the framework and the application may be generated and registered in the application management information table 40. In other words, any information that is necessary for establishing a connection between the framework 20 and the application 25 may be used.

FIG. 6A shows a normal activation process flow of each brand application.
When each brand application 25 is activated by the process of step S13 by the framework 20, it first performs an internal initialization process (step S21). The contents of this initial process will not be described in particular. Then, a communication port number request is issued to the framework 20, and the communication port number assigned to the blunt application 25 is acquired (step S22). Thereafter, the communication port number is used particularly when the framework 20 communicates with the brand application 25 (such as an instruction message forwarding described later).

  Then, the state shifts to a data reception waiting state (step S23). That is, the framework 20 responds to this instruction every time it receives an arbitrary operation instruction message from the upper terminal (main station 1), for example, as will be described later with reference to FIG. This instruction message is transferred (forwarded) to the brand application 25 to be used. The process of step S23 means, for example, shifting to the reception waiting state for the forwarded instruction message, but is not limited to this example. In this reception waiting state, the communication port number acquired in step S22 is monitored.

  FIG. 6B shows a processing example of the framework 20 when the communication port number request is received in step S22. This process is executed by the application management unit 21. This process can be executed after the process of FIG. 2 is completed.

  First, although not specifically described, the framework 20 can know the application ID of each application (including the framework itself) managed by the OS by the function of the OS. Can be recognized (step S31). Thus, it is checked whether or not the requesting brand application 25 is registered in the application management information table 40. That is, the application management information table 40 is searched to check whether or not the application ID of the requesting brand application 25 is registered (whether or not there is a match with the application ID 42) (step S32).

  If registered (step S32, YES), the communication port number 44 assigned to the brand application 25 is returned to the requesting brand application 25 (step S33). Thereby, the requesting brand application 25 can acquire the communication port number in the process of step S22.

  On the other hand, when it is not registered (step S32, NO), it is determined that the request source application may be an unauthorized application, and an abnormal response is made (step S34). In this case, the requesting brand application 25 cannot acquire the communication port number in the process of step S22.

  After completion of the processing of FIGS. 2 and 6 at the time of activation, the IC card settlement terminal 10 shifts to the normal processing mode. Thereafter, normal processing, for example, IC card settlement processing, settlement detail data transmission processing to the center server 2, and the like are executed.

FIG. 7 shows a flowchart of this normal process.
The host terminal (main station 1) instructs the IC card settlement terminal 10 to execute processing of an arbitrary service type. The host terminal (main station 1) is a POS register or the like as described above. For example, when a customer uses an IC card of any kind among various IC cards handled by the IC card settlement terminal 10, a store clerk or the like When the host terminal is operated to instruct the IC card settlement processing to be executed, the host terminal includes the service type corresponding to the instruction in the command and transmits the command to the IC card settlement terminal 10 (step S41).

  Upon receiving this command (operation instruction message) (step S51), the application management unit 21 of the framework 20 of the IC card payment terminal 10 confirms the service type in this command (step S52), and the application management of FIG. The information table 40 is searched to check whether or not the corresponding application exists (step S53). That is, it is checked whether or not the same service type 43 as the command service type is registered.

  If the corresponding application is not registered in the table 40 (step S53, NO), the process proceeds to step S56, and an operation result message is returned to the upper terminal.

  On the other hand, when the corresponding application exists (step S53, YES), the communication port number 44 of the record of the corresponding application is acquired. Then, the command is forwarded (transmitted) to the communication port indicated by the communication port number 44 (step S54).

  Here, consider a case where, for example, an unauthorized application is stored as the brand application 25 and information related to the unauthorized application is registered in the on-board application information table 30. Even in this case, if the third party related to the unauthorized application does not know the predetermined “regulation” described above, the determination in step S14 is NO. That is, unless the storage location (folder name, etc.) of the unauthorized application and the execution file name are set in accordance with the above “regulation”, the unauthorized program cannot be started by the generated execution file path. Therefore, this unauthorized program is not registered in the application management information table 40 of FIG. 5, and no communication port number is assigned.

  As a result, it is possible to prevent an unauthorized program from executing an unauthorized process. Further, even if the unauthorized program tries to start and operate without receiving the activation process or instruction from the framework 20, it becomes substantially inoperable by the process of FIG. 8 described later. Details will be described later.

  Each brand application 25 that has been able to acquire the communication port number assigned to itself by executing the process of step S33 monitors the communication port of the communication port number in the data reception waiting state shifted in step S23, Wait for command forwarding from the framework 20.

  Each brand application 25 analyzes the content of the received command when the command is forwarded (when the operation instruction message is received) (step S61), and the processing operation indicated by the command content. Is performed (step S62). Then, when the execution of the processing operation is completed, the operation result is returned to the framework 20 (its application management unit 21) (step S63). In this case, when receiving this reply (operation result) (step S55), the framework 20 returns this operation result information to the upper terminal 1 (step S56). The upper terminal 1 receives the operation result information and executes a predetermined process (step S42).

Here, as an example of the processing operation in step S62, a case where an IC card settlement process of an arbitrary brand is instructed will be described.
In this case, the brand application 25 that executes the processing operation in step S62 first calls the R / W communication control unit 24 of the framework 20 to execute communication processing control with the IC card. In other words, the R / W communication control unit 24 controls the communication control unit (to the card) 15 in response to a request from the brand application so as to perform communication with the IC card. Payment processing is performed to add or subtract.

  At that time, in order to acquire key information or the like necessary for the secret communication with the IC card 3 from the storage device 12 (tamper-resistant memory as a part thereof), the data control unit 23 is called to Requests reading of key information and the like.

  Further, when the payment process is normally completed, the brand application 25 calls the data control unit 23 of the framework 20 and performs process control for storing the detailed information (transaction information) of the payment process in the storage device 12, for example. Let it run. That is, the data control unit 23 executes processing for storing the transaction information in the storage device 12 in response to a request from the brand application 25.

  Here, the R / W communication control unit 24 and the data control unit 23 may reject the request from the application 25 in some cases. This is not limited to the control units 23 and 24, and may be the same in all the processing function units in the framework 20. That is, when the host communication control unit 22 or the application management unit 21 (or the center communication control unit) is called from an arbitrary application 25 and receives an arbitrary request, the request may be rejected.

  That is, the R / W communication control unit 24, the data control unit 23, and the like confirm whether or not the brand application 25 that has made the call is an application other than a legitimate application (such as an unauthorized application). If it is determined that the application is an unauthorized application, the request is rejected and the requested processing operation is not executed.

  The process for checking whether the program is a malicious program is performed with reference to the table 40. That is, it is checked whether the calling brand application is registered in the table 40, and if not registered, the request is rejected. This check is performed using, for example, the application ID. That is, since the processing function unit (R / W communication control unit 24, data control unit 23, etc.) that has received the call knows the application ID of the caller application as in the case of FIG. The process of FIG. 8 is executed using the application ID. If it is confirmed that there is no problem after executing the fraud check process of FIG. 8, the process according to the request is executed.

  In the fraud check process of FIG. 8, based on the application ID of the calling brand application, it is checked whether or not this application ID is registered in the application management information table 40 of FIG. 5 (step S71). That is, it is checked whether or not there is an application ID 42 that matches the application ID of the calling brand application.

If it is not registered (step S72, NO), access (request) is rejected as the possibility of an unauthorized application (step S74).
On the other hand, if registered (step S72, YES), processing according to the request from the application 25 is executed (step S73). For example, in the case of the R / W communication control unit 24, communication with the IC card 3 is permitted and executed. For example, in the case of the data control unit 23, access to the storage device 12 is permitted, and data read / write processing or the like is executed.

  Here, regarding the access processing with respect to the storage device 12, each brand application 25 can be controlled so as not to access the data of the other brand applications 25.

Although this control process is not particularly shown, for example, the following process is performed.
First, when the file structure on the settlement terminal of this example is, for example, the example shown in FIG. 4, for each brand application, all the data files of the application are the same location (same folder as the execution file (.exe) of the application). Or a folder below this folder). For example, taking the brand application A as an example, all of the data files are stored in the folder “brand_a” shown in FIG. Alternatively, it is stored in an arbitrary folder (not shown, for example, brand_a / brand_a1) below “brand_a”. However, here, it is assumed that all data is stored in the folder “brand_a”.

  As described above, the execution file “brand_a.exe” is also stored in the folder “brand_a”. That is, in other words, the data of each brand application 25 is stored in a storage location that can be accessed by the same path information as the execution file path generated for starting the brand application.

  In this description, as an example, a data file with the file name “filename” is stored in the folder “brand_a” as a data file of the brand application A.

  In this example, when accessing any data file, each brand application 25 calls the data control unit 23 to notify only the file name (no path information). Therefore, in the above example, the brand application A notifies the data control unit 23 of the file name “filename” of the data file to be accessed.

  As described above, the data control unit 23 performs the fraud check as described above using the application ID of the calling brand application 25 (in this example, “a1”), but determines that there is no fraud and stores it. When accessing the device 12, path information of the data file is generated.

  That is, the application management information table 40 in FIG. 5 is searched using the application ID of the calling brand application 25 to obtain the route path 45 of the corresponding record. Thus, in the example of the brand application A, the root path “C: / appl / brand_a /” is acquired. Then, path conversion is performed using the acquired root path and the notified file name. That is, by combining the above “C: / appl / brand_a /” and “filename”, a path to be actually accessed is “C: / appl / brand_a / filename” (execution file path is generated) As well).

  The data control unit 23 executes file access processing for the storage device 12 using the generated execution file path. Therefore, each brand application 25 can access only the file of its own brand. For example, for the brand application B, even if a file with the same name (file with the file name “filename”) exists, the data control unit 23 now executes the execution file in response to an access request to the “filename” from the brand application B. Since the path “C: / appl / brand_b / filename” is generated, “filename” in the folder “brand_a” is never accessed.

  Moreover, even if an arbitrary valid application (assumed to be brand application B) attempts unauthorized access, it cannot be accessed. That is, it is assumed that the brand application of the brand application B previously acquires the file configuration shown in FIG. 4 by some method, and includes processing for accessing the file of the brand application A in the brand application B based on this. That is, it is assumed that not only the file name is specified as described above but also “C: / appl / brand_a / filename” is specified including path information.

  Even in this case, the data control unit 23 treats the “C: / appl / brand_a / filename” as a file name and performs the above processing, so the execution file path = “C: / appl / brand_b / filename / C: / Only meaningless information like “appl / brand_a / filename” is generated. Therefore, the brand application B cannot access the file of the brand application A.

  As described above, in the payment terminal 10 of this example, each brand application 25 can be restricted so that only files under the storage folder of the execution file of the application can be accessed. In other words, each brand application can be restricted so that it cannot access files of other brand applications.

  In this example, the use of the R / W communication function and the data processing function from each brand application has been described. Of course, other physically connected devices (LCD, LCD display device, various storage devices) In addition, it is possible to restrict access to each function created by an input device such as a switch) or software and provided by the framework.

Here, modularization of the brand application will be described with reference to FIGS. 9 (a) and 9 (b).
FIG. 9A is a functional block diagram of a conventional main control unit. As described above, conventionally, processing related to all electronic money brands handled by the payment terminal has been realized on one program. Here, a payment terminal that handles brand A and brand B is taken as an example.

  In this example, brand A and brand B applications exist on one program. However, as shown in the figure, for both brand A and brand B, the applications are separated by function, and both brands are grouped for each function.

  That is, the function of each brand application is divided into modules for each function of the command processing unit (including data control) 110, the center communication unit 120, and the IC card R / W unit 130 as shown in the figure. As shown in the figure, both brand A and brand B applications exist for each functional unit 110, 120, and 130. As a function of "one program", there is a main station communication processing unit 100, but this is not a brand but a common function.

  The main station communication processing unit 100 controls the communication control unit (for main station) 13 to perform communication with the main station 1 (higher-level terminal), for example, an arbitrary command (instruction) from the main station 1 (higher-level terminal). If it is received, it is passed to the command processing unit 110.

  For example, when the command processing unit 110 receives an instruction from the host terminal, the command processing unit 110 interprets the instruction and executes a process according to the instruction. For example, an IC card payment process is executed, and a process for storing the payment result (transaction information) in the storage device 12 is executed. However, at that time, the IC card R / W unit 130 is requested to execute communication processing with the IC card for IC card settlement processing. For example, when a brand A IC card settlement process is instructed, the brand A application is executed in each of the command processing unit 110 and the IC card R / W unit 130.

For example, “brand A” 111 in the illustrated command processing unit 110 means an application that executes processing of the command processing unit related to brand A. Others are the same.
In the above-described conventional configuration, for example, when the command processing unit 110 is taken as an example, it has a “brand A” 111 and a “brand B” 112. In other words, the application of the command processing unit 110 is ““ brand A ”111+“ brand B ”112”.

  Here, for example, in the past, there was only an application of only “Brand A” 111 and an application of only “Brand B” 112, but in order to make it possible to deal with both brands A and B later, When “Brand A” 111+ “Brand B” 112 ”is created, the operation of each of the application only for“ Brand A ”111 and the application only for“ Brand B ”112 should be verified in the past without any problem. However, the application ““ brand A ”111+“ brand B ”112” does not always work without any problem.

  For this reason, conventionally, after creating an application of “Brand A” 111+ “Brand B” 112, it is necessary to verify that it operates without any problem. Not only does it take time to create each application (7 patterns in the above example), but it also takes time to confirm that it operates without problems.

  On the other hand, the brand application 25 of this example (here, brand applications A and B as an example) is a module in which the various functions described above are modularized for each brand, as shown in FIG. 9B. .

  For example, in the brand application A, applications of various functional units related to the brand A shown in FIG. 9A are collected (modularized). That is, the brand application A has all of the brand A111, brand A121, and brand A131 shown in FIG. Similarly, the brand application B has all of the brand B112, the brand B122, and the brand B132 shown in FIG.

  In other words, in this configuration, an application that performs various processes related to cashless payment using electronic money, such as IC card payment processing, payment data (transaction details, etc.) storage processing, data transmission processing to the center, etc. The application is modularized independently for each electronic money type (for each IC card type). Accordingly, each brand application 25 is referred to as “an independent application module for each brand (for each electronic money type; for each IC card type)” or “an application module corresponding to each type of IC card”.

  Here, it has been described that seven patterns corresponding to the brands A, B, and C are necessary in the past, but here, for simplicity, the case corresponding to the brands A and B is taken as an example. Three patterns of “A only”, “B only”, and “A + B” are conceivable. In this case, the example shown in FIG. 9A corresponds to “one program” corresponding to “A + B”, but it is necessary to create “one program” for each of the other two patterns. is there. That is, each functional unit 110, 120, and 130 has only one brand A111, brand A121, and brand A131, and each functional unit 110, 120, and 130 has only brand B112, brand B122, and brand B132, respectively. It is necessary to create "one program" having.

  On the other hand, in the case of this example shown in FIG. 9B, if each of the illustrated brand applications A and B is prepared in advance, the installation of FIG. 3 to be described later is performed for each store (each terminal 10). By setting the application information table 30, any of the above three patterns can be handled.

For example, brand A 111 in FIG. 9A and brand A 111 in FIG. 9B are not necessarily the same, but the processing functions themselves are the same.
Since each of the modular brand applications 25 accesses data using the virtual memory space (controlled by the OS), the operation of an arbitrary application affects other applications (the data, etc.). There is nothing. In other words, you can build a firewall.

  As described above, in the IC card settlement terminal 10 of this example, first, an independent application module (each brand) corresponding to each of a plurality of brands (a plurality of types of electronic money; a plurality of types of IC cards). Applications A, B, C, etc.) are generated and stored in advance. Then, the framework 20 activates only those registered in the table 30 among the plurality of application modules. Thus, simply changing / setting the table 30 (addition / deletion of application registration, etc.), for each terminal 10, one brand or a combination of a plurality of brands corresponding to the terminal 10 can be easily set / changed. (Feature 1).

  Further, when the application module is activated, the framework 20 generates an executable file path in accordance with the information in the table 30 and a predetermined rule, and tries to activate it using the executable file path. Even if an unauthorized application enters and the information is illegally stored in the table 30, the application is not activated unless the predetermined rule is known (feature 2).

  Furthermore, since the framework 20 establishes a connection with the application module that can be activated, there is no connection with the framework 20 even if there is an application module that is activated without being controlled by the framework 20. (Characteristic 3).

  Furthermore, the framework 20 controls data access to the storage device 12, communication control to external devices (main station 1 and center server 2), IC card 3 and the like in response to a request from an arbitrary application module 25. However, if there is a request from an application module that is not registered in the table 40, that is, an application module that has not been activated, the request is rejected. For example, even if there is a request from an unauthorized application module, the request is rejected because it is not registered in the table 40. Therefore, an illegal application module is processed through at least the framework 20, that is, data access control to the storage device 12, communication control to an external device (the main station 1 or the center server 2), and the IC card 3. Thus, the communication control cannot be performed (feature 4).

  When performing data access control to the storage device 12 in response to a request from the application module, the framework 20 uses the path information (such as the root path) of the execution file path registered at the time of startup to request the requested data. Because the file is accessed, each application module can only access its own data file. That is, for example, even if a valid application module tries to access data of another application module, it cannot be performed. Of course, an unauthorized application cannot access any data (feature 5).

  The present invention can be realized only by the above feature 1, or by any combination of two or more including the feature 1. That is, for this combination, feature 1 + feature 2, feature 1 + feature 3, feature 1 + feature 4, feature 1 + feature 5, feature 1 + feature 2 + feature 3, feature 1 + feature 2 + feature 4, feature 1 + feature 2 + feature 5, Feature 1 + feature 2 + feature 3 + feature 4 and feature 1 + feature 2 + feature 3 + feature 4 + feature 5 can be established.

(A), (b) is a figure which shows the structural example of the IC card payment terminal of this example. It is a flowchart figure of the starting process of a framework. It is a figure which shows an example of the loading application information table. It is a figure which shows the storage format of each brand application. It is a figure which shows an example of an application management information table. (A) is the normal starting process of each brand application, (b) is a flowchart figure of the process of the framework accompanying this. It is a flowchart figure of a normal process. It is a flowchart figure of a fraud check process. (A) is a functional block diagram of the conventional main control part, (b) is a figure which shows the structure of the application module of this example.

Explanation of symbols

1 Master station (host controller)
2 Center server 3 IC card 10 IC card settlement terminal 11 Main control unit 12 Storage device 13 Communication control unit (to main station)
14 Communication control unit (to center)
15 Communication control unit (to card)
20 Framework 21 Application management unit 22 Host communication control unit 23 Data control unit 24 R / W communication control unit 25 Brand application 30 On-board application information table 31 Application No.
32 Application name 33 Service type 34 Operation parameter 40 Application management information table 41 Application No.
42 Application ID
43 Service type 44 Framework-application communication port number 45 Route path

Claims (7)

An IC card payment terminal that can handle multiple types of IC cards,
In correspondence with each of the various IC cards, an application module storage unit that stores various application modules that execute processing corresponding to the IC card;
A common processing unit that manages and controls the various application modules, and executes data access control to a storage device, communication control to an external device, or communication control with an IC card in response to a request from the application module. Have
The common processing unit includes:
Registration information storage means for storing registration information relating to any one or more application modules of the various application modules in advance;
As an initial process, among the various application modules, an application module management unit that activates an application module registered in the registration information storage unit;
A startup application management information storage means for storing management information of the started application module;
An IC card settlement terminal characterized by comprising:   The application module management unit generates path information based on the registration information, activates the application module using the path information, and establishes a connection to the activated application module when the activation is successful. The IC card settlement terminal according to claim 1, wherein management information relating to the activated application module is stored in the activated application management information storage means. The registration information includes the name of the application module,
The various application modules are stored in advance in storage locations that are determined based on their names and predetermined rules.
3. The IC card according to claim 2, wherein the application module management unit generates the path information indicating a storage location of the application module based on a name included in the registration information and the predetermined rule. Payment terminal.   In response to an arbitrary request from any of the application modules, the common processing unit performs the request when executing data access control to the storage device, communication control to an external device, or communication control with an IC card. 4. The apparatus according to claim 1, wherein it is checked whether or not the management information relating to the original application module is stored in the activated application management information storage means, and if not stored, the request is rejected. The IC card payment terminal according to any one of the above.   When performing data access control to the storage device in response to a request from the application module, the common processing unit stores the name of the data file to be accessed included in the request and the startup application management information storage unit 4. A file path for accessing the data file is generated using the path information, and the data file to be accessed is accessed using the file path. The IC card payment terminal described. A control device for an IC card settlement terminal that can handle a plurality of types of IC cards,
In correspondence with each of the various IC cards, an application module storage unit that stores various application modules that execute processing corresponding to the IC card;
A common processing unit that manages and controls the various application modules, and executes data access control to a storage device, communication control to an external device, or communication control with an IC card in response to a request from the application module. Have
The common processing unit includes:
Registration information storage means for storing registration information related to any one or more application modules of the various application modules in advance;
As an initial process, among the various application modules, an application module management unit that activates an application module registered in the registration information storage unit;
A startup application management information storage means for storing management information of the started application module;
A control device for an IC card settlement terminal, comprising: An IC card payment terminal computer that can handle multiple types of IC cards.
In correspondence with each of the various IC cards, an application module storage unit that stores various application modules that execute processing corresponding to the IC card;
A common processing unit that manages and controls the various application modules, and executes data access control to a storage device or communication control to an external device or communication control with an IC card in response to a request from the application module;
In the common processing unit, registration information storage means for storing registration information related to any one or more application modules of the various application modules in advance, and the registration information storage of the various application modules as an initial process. Application module management means for starting application modules registered in the means, and startup application management information storage means for storing management information of the started application modules,
Program to function as.

Images