Personal electronic settlement system, its terminal, and management apparatus

[Technical Field to which the Invention Affiliates] The present invention relates to an electronic payment system that provides a payment function in retail sales transactions represented by a credit card (bank card), and particularly ensures the safety of payment and is smooth. It enables payment processing.

[0002] In recent years, with the spread of bank cards typified by credit cards, credit card payments in retail sales have become commonplace. However, on the other hand, troubles such as forgery of credit cards, fraudulent use by others, and fraudulent billing by retailers are increasing, and improvement of security as a payment system is required. Recently, IC card type credit cards have also appeared as one of the measures to prevent counterfeiting of credit cards.

[0003] Hereinafter, a conventional credit card payment system including an IC card type credit card will be described.

[0004] Conventionally, in payment by a bank card typified by a credit card, as disclosed in Japanese Patent Publication No. 3-32100, data communication is performed between the terminal of the store and the control center to obtain credit. Many payment systems for making inquiries and credit card payments have been proposed, and FIG. 42, which is used, shows the configuration of a conventional general payment system.

[0005] In FIG. 42, the credit settlement terminal 4201 is a terminal installed at a store and performing a credit payment operation at the store. The credit card payment terminal 4201 is connected to the remote payment system 4202 via the telephone line 4204, the public network 4203, and the communication line 4205. The credit card payment terminal 4201 is equipped with a card reader that reads the information stored in the credit card 4200, a modem for connecting to the public network 4203, and a printer that prints a statement.

[0006] The payment system 4202 is an information processing system that performs credit payment processing, and the payment system 4202 manages consumer credit information and account information under a credit service contract with the consumer. ing.

[0007] The credit card 4200 has the owner's name and credit card number stamped on the surface of the card, and the owner's signature written on the surface of the card, and ID information is stored inside. There are two types of credit card 4200, one is a magnetic card type and the other is an IC card type. The difference between the two is the difference in the external interface, and in order to read the internal information, the card corresponding to each type Need a reader. In addition to credit card ID information, some cards can store various types of personal information.

[0008] In the payment system configured as described above, credit card payment is performed by the following procedure.

[0009] First, the consumer hands the credit card 4200 to the clerk of the store and requests the credit settlement. The clerk makes the card reader of the credit payment terminal 4201 read the credit card 4200 and operates the credit payment.

[0010] Then, the credit payment terminal 4201 reads the ID information from the credit card 4200, and transmits a message requesting credit inquiry and credit payment to the payment system 4202 by data communication by a modem. The payment system 4202 performs a credit inquiry process and a credit card payment process based on the ID information and the amount information included in the message, and sends a payment completion message to the credit card payment terminal 4201. Then, the credit card payment terminal 4201 prints the statement from the printer.

[0011] The clerk asks the consumer to sign the statement, and further collates and confirms the signature written on the statement with the signature written on the credit card 4200, and together with the usage copy, the credit card. Return the 4200 to the consumer to complete the credit card payment.

[0012] [Problems to be Solved by the Invention] However, in the conventional payment system, since the credit card is handed over to the clerk of the store, the credit card number is known to the store and the credit card number is misused. was there.

[0013] Further, in the conventional payment system, since the store takes the initiative in the payment processing work, the store tricks the consumer into performing the payment processing at a price higher than the actual price of the product. There was a case.

[0014] Further, in the conventional payment system, since the credit card is set directly in the credit payment terminal installed in the store, the store modifies the credit payment terminal and falsifies the information in the card. Alternatively, personal information other than credit card ID information may be illegally read.

[0015] Further, in the conventional payment system, the consumer needs to carry one credit card for one credit service, contracts with a plurality of credit card companies, and receives a plurality of credit services. It was inconvenient for consumers to carry a number of cards with them.

[0016] Further, in the conventional payment system, since a physical card called a credit card is used as a means of authentication, the consumer can once again cancel the transaction once the credit payment has been made. There was the inconvenience of having to go to the place where I made a deal.

[0017] Further, in the conventional payment system, it is necessary to print the calculation sheet on paper, and the printing time has been a bottleneck for improving the efficiency of sales. On the other hand, the credit card payment terminal needs to be equipped with a printer, which has been a bottleneck in making the credit card payment terminal compact and reducing costs.

[0018] Further, in the conventional payment system, it is necessary for the consumer to sign the statement, and the time required for the clerk to request the consumer to sign and actually have the sign signed is credit. It occupies most of the time required for payment, which has been a bottleneck for improving sales efficiency.

[0019] The present invention solves the problems of such a conventional payment system, and is a payment means excellent in security and convenience.<u style="single">Terminal that can be used for</u>Is intended to provide.

[Means for Solving the Problems] Therefore, in the present invention,<u style="single">Execute payment processing</u>CPU and<u style="single">Stores payment history data indicating the history of payment processing executed by the CPU.</u>Equipped with storage means and data communication means<u style="single">In the payment processing terminal, when new payment history data is stored in the storage means due to the CPU executing the payment processing, the free capacity is increased based on the free capacity of the storage means.</u><u style="single">Au (Au&gt; 0)</u><u style="single">When it is less than, it is determined that the data update process for having the server connected via the communication network update the payment history data stored in the storage means is necessary, and the server performs the data update process. In order to make a request, the terminal generates an upload data message including the payment history data stored in the storage means, transmits the upload data message to the server via the data communication means, and then transmits the upload data message. , The memory in which the server that received the upload date message preferentially assigns a local address to the latest payment history data based on the time when the CPU executes the payment process recorded in the payment history data. The update data stored in the means is received from the server via the data communication means.</u>It is configured to do.

[Embodiments of the Invention]<u style="single">Hereinafter, embodiments of the present invention will be described with reference to the drawings.</u>(Embodiment 1) A first embodiment of the present invention will be described with reference to FIGS. 1 to 41.

[0116] In the credit payment system of the first embodiment, when an individual consumer purchases a product at a general retail store, a credit card, a usage statement, etc. are used between the consumer and the retail store. It is a system that makes credit card payments by wireless communication without directly handing over the credit card. This is called a personal remote credit card payment system, and the credit card payment service provided by this system is called a personal remote credit card payment service. I will call it.

As shown in the system configuration diagram of FIG. 1, this personal remote credit payment system includes a personal credit terminal 100 having two systems of two-way wireless communication function and an electronic credit card function, and a retail store. A communication network connecting a credit card payment device 101 that performs credit card payment processing at a store, a payment system 103 that performs credit card payment processing at a credit service company or a payment processing company, a personal credit terminal 100, a credit card payment device 101, and a payment system 103. A service providing system 102 that provides a personal remote credit payment service, a digital public network 108 that provides a data transmission path in the network, and a wireless connection that connects the personal credit terminal 100 to the digital public network 108. It is equipped with a telephone base station 104.

[0118] The personal credit terminal 100 is a mobile radiotelephone terminal having two types of two-way wireless communication functions of infrared rays and a digital radiotelephone and an electronic credit card function. In addition, the credit card payment device 101 that performs credit card payment processing at retail stores also has two two-way communication functions of infrared communication and digital telephone communication.

[0119] In FIG. 1, 105 is a transmission line for infrared communication between the personal credit terminal 100 and the credit settlement device 101, and 106 is between the personal credit terminal 100 and the base station 104. Indicates a transmission line for digital wireless communication, 107 is a digital communication line connecting the base station 104 and the digital public network 108, 109 is a digital communication line connecting the digital public network 108 and the service providing system 102, and 110 is a credit. A digital telephone communication line connecting the payment device 101 and the digital public network 108, 111 indicates a digital communication line connecting the service providing system 102 and the payment system 103.

[0120] The following form is assumed as the normal operation form of the personal remote credit payment service.

[0121] The payment system 103 is installed in a credit card company or a payment processing company, and the credit payment device 101 is installed in a retail store, and a consumer carries a personal credit terminal 100. The service providing system 102 is installed in a company that provides a personal remote credit payment service, and when the credit card company provides a personal remote credit payment service, the service providing system 102 is installed in the credit card company. Will be done.

[0122] As a premise, the consumer has a membership contract for a credit service with a credit card company, and a personal remote credit payment service with a company that provides a personal remote credit payment service. In addition, we have a membership contract with a telephone company and a wireless telephone service contract. Similarly, retailers also enter into credit service merchant agreements with credit card companies and personal remote credit payment service merchants with companies that provide personal remote credit payment services. We have a contract and a digital telephone communication service contract with a telephone company.

[0123] If the personal remote credit payment service is provided by a company other than the credit card company, the company that provides the personal remote credit payment service may contact the credit card company. Instead of a credit card company, it issues electronic credit cards to members who have a contract with a credit service, and has a contract to operate a personal remote credit payment service.

[0124] When the payment processing company performs credit payment processing using the payment system 103, the credit card company makes a contract with the payment processing company for the credit payment processing to be performed by the payment processing company. It is tied.

[0125] In the following, in order to simplify the explanation of this system, the consumer owned by the personal credit terminal 100 is the user, the retail store where the credit payment device 101 is installed is the merchant, and the credit is credited. The sales clerk who operates the payment device 101 is the person in charge (Operator), the company that provides the personal remote credit payment service is the service provider (Service Provider), the credit card company that performs credit payment processing using the payment system 103, or A payment processing company will be referred to as a payment processing institution (Transaction Processor).

[0126] In this system, when a user pays a merchant for a product by credit, payment information is electronically exchanged between the personal credit terminal 100, the credit payment device 101, and the service providing system 102. Further, the credit payment process is performed by electronically exchanging payment information between the service providing system 102 and the payment system 103.

[0127] Basically, the service providing system 102 receives a payment request and a payment request from the personal credit terminal 100 and the credit payment device 101, respectively, collates the payment request and the payment request, and collates with the user. Request payment processing from payment system 103 on behalf of the merchant. Then, the payment system performs the actual payment processing.

At this time, the personal credit terminal 100 and the credit settlement device 101 perform infrared communication using the transmission line 105, and the personal credit terminal 100 and the service providing system 102 are connected to the transmission line 106 and the base station. 104, and digital telephone communication by digital wireless telephone is performed via digital communication line 107, digital public network 108, and digital communication line 109, and the credit settlement device 101 and the service providing system 102 are connected to the digital telephone communication line 110, Digital telephone communication is performed via the digital public network 108 and the digital communication line 109. Then, the service providing system 102 and the payment system 103 perform digital data communication via the digital communication line 111.

[0129] Payment information exchanged in communication between the personal credit terminal 100 and the service providing system 102, communication between the credit payment device 101 and the service providing system 102, and communication between the service providing system 102 and the payment system 103. Are all encrypted and communicated. For encryption, information is electronically sealed and communicated by combining private key cryptographic processing and public key cryptographic processing.

[0130] Next, each component constituting the system will be described.

[0131] First, the personal credit terminal 100 will be described.

[0132] FIGS. 2 (a) and 2 (b) are external views of the front side and the back side of the personal credit terminal 100, respectively.

[0133] In FIG. 2A, 200 is an infrared communication port (infrared light receiving / emitting unit) that performs infrared communication with the credit settlement device 101, 201 is an antenna that receives and transmits radio waves of a digital radiotelephone, and 202 is a receiver. -Speaker, 203 is a color liquid crystal display (LCD) with 120 x 160 pixel display, 204 is a mode switch to switch the operation mode of the personal credit terminal 100, 205 is a call switch for digital radiotelephone, 206 is digital radio The telephone end switch, 207 is a function switch, 208 is a ten-key switch, 209 is a power switch, and 210 is a microphone.

[0134] Further, in FIG. 2 (b), 211 is an execution switch that prompts execution of processing accompanied by user confirmation such as payment of payment, confirmation of payment contents, cancellation of credit transaction, and 212 is a headset. A headset jack for connecting.

[0135] The personal credit terminal 100 has two operation modes, a credit card mode and a digital radiotelephone mode, which are switched by a mode switch 204. The personal credit terminal 100 operates as a digital radiotelephone in the digital radiotelephone mode, and operates as an electronic credit payment means, that is, an electronic credit card in the credit card mode.

[0136] electronic credit card, Kure of the credit card company by the user as a premise the membership agreement JIT service, is registered to the personal credit terminal 100. When the user has a membership contract for a plurality of credit services, a plurality of credit cards are registered in the terminal 100.

[0137] When making a call using this personal credit terminal 100, for example, the user first sets the operation mode to the digital radiotelephone mode with the mode switch 204, and then uses the numeric keypad switch 208 to change the telephone number. Enter and press call switch 205. With the above operation, the user can make a call to the entered telephone number.

[0138] Further, when a call is received from the personal credit terminal 100, the personal credit terminal 100 emits a ring tone regardless of the operation mode at that time. In this case, pressing the call switch 205 automatically switches to the digital radiotelephone mode, and the user can receive the call.

[0139] When paying the merchant by credit, first, the mode switch 204 sets the operation mode to the credit card mode, and the function switch 207 selects the credit card to be used for payment. Next, on the numeric keypad switch 208, enter the amount to be paid, point the infrared communication port 200 toward the merchant's credit card payment device 101, and press the execution switch 211. By the above operation, the personal credit terminal 100 performs infrared communication with the credit payment device 101 and digital wireless telephone communication with the service providing system 102, and exchanges payment information with each other. , Perform credit card payment processing. The internal configuration and detailed operation of the personal credit terminal 100 will be described later.

[0140] Next, the credit card payment device 101 will be described.

[0141] FIG. 3 is an external view of the credit card payment device 101. This device is an RS-232C cable that connects a credit card payment terminal 300 that has a credit card payment processing function and a digital telephone device function, a cash register 311 that calculates the price of a product, and a credit card payment terminal 300 and a cash register 301. It is equipped with a 313 and an infrared light receiving / receiving module 301 connected to a credit card payment terminal 300 via a serial cable 310.

[0142] In FIG. 3, 302 is a color liquid crystal display (LCD) displaying 320 × 240 pixels, 303 is a handset, 304 is a mode switch for switching an operation mode of a credit card payment terminal 300, and 305 is a hook switch for a telephone. , 306 is a function switch, 307 is a numeric keypad switch, 308 is an execution switch that prompts execution of processing that involves confirmation of a merchant, such as payment of payment, confirmation of payment details, and cancellation of credit transactions, and 309 is a power switch. Moreover, 312 is a credit settlement switch that specifies the settlement processing by the credit of the cash register 311.

[0143] The credit card payment terminal 300 has two operation modes, a credit card payment mode and a digital telephone mode, which are switched by a mode switch 304. In the digital telephone mode, it operates as a digital telephone device, and in the credit payment mode, it operates as a credit payment processing terminal of a personal remote credit payment service.

[0144] When making a call from the credit card payment terminal 300, for example, the person in charge first sets the operation mode to the digital telephone mode with the mode switch 304, and then inputs the telephone number with the numeric keypad switch 307. By the above operation, the person in charge can make a call to the entered telephone number.

[0145] Further, when a call is received from the credit card payment terminal 300, the credit card payment terminal 300 emits a ring tone regardless of the operation mode. In this case, by raising the telephone device 303 or pressing the hook switch 305, the telephone mode is automatically switched and the person in charge can receive the call.

[0146] Further, when performing the credit settlement process, first, the cash register 311 calculates the total amount from the product price, the tax, and the like, and informs the user of the total amount. Next, according to the request of the user who wishes to pay by credit, the credit settlement switch 312 of the cash register 311 is pressed, and the user waits for the payment operation to be performed on the personal credit terminal 100. When the user performs a payment operation, the payment amount entered by the user is displayed on the LCD 302, and the result of the user's credit inquiry is also displayed. The person in charge confirms the contents and presses the execution switch 308.

[0147] By the above operation, the credit card payment device 101 exchanges payment information with the personal credit terminal 100 and the service providing system 102, respectively, and performs credit card payment processing. The internal configuration and detailed operation of the credit card payment terminal 300 will be described later.

Next, the service providing system 102 will be described.

[0149] FIG. 4 is a block configuration diagram of the service providing system 102. The service providing system 102 performs data processing of payment information exchanged with each of the personal credit terminal 100, the credit payment device 101, and the payment system 103 in the personal remote credit payment service, and controls the data communication at that time. The service server 400 to be performed, the service director information server 401 that manages the attribute information about the user, the merchant, and the payment processing institution and the history information of the service provided by the service providing system 102, the user attribute information, and the personal credit terminal 100. The user information server 402 that manages the data in the data, the merchant information server 403 that manages the attribute information of the merchant and the data in the credit payment terminal 300, and the attribute information of the payment processing institution and the history information of the payment processing are managed. It is equipped with a payment processing institution information server 404 and a management system 407 in which the service provider manages the operation of the service provision system 102. Each server 400 to 404 and the management system 407 are composed of one or more computers. Has been done.

[0150] Further, the service server 400, the service director information server 401, the user information server 402, the merchant information server 403, and the payment processing institution information server 404 are connected to the ATM-LAN switch 405 by the ATM-LAN cable 409,410,411,412,413, respectively. The service server 400 accesses the service director information server 401, the user information server 402, the merchant information server 403, or the payment processing institution information server 404 via the ATM-LAN switch 405.

[0151] Further, the ATM-LAN switch 405 is connected to the ATM switch 406 by the ATM-LAN cable 415. A digital communication line 109 connected to the digital public network 108 and a digital communication line 111 connected to the payment system 103 are connected to the ATM exchange 404, and the service server 400 is connected to the ATM exchange 405 via the ATM-LAN switch 405 and the ATM exchange 406. Communicates with a personal credit terminal 100, a credit card payment device 101, and a payment system 103.

[0152] The management system 407 is connected to the ATM-LAN switch 406 by the ATM-LAN cable 414, and further connected to the ATM switch 406 by the ATM-LAN cable 416. The management system 407 uses the service server 400, the service director information server 401, the user information server 402, the merchant information server 403, or the payment processing institution information via the ATM-LAN switch 408, the ATM switch 406, and the ATM-LAN switch 405. Access the server 404 and manage the operation of the service providing system 102.

[0153] The ATM switch 406 operates as a data communication switch in communication between the outside and the inside of the service providing system 102 and communication between the inside of the service providing system 102. In addition, the ATM switch 406 supports a plurality of communication methods and has a communication adapter function. For example, in the communication between the service server 400 and the credit settlement device 101, first, the ISDN data packet is exchanged between the credit settlement device 101 and the ATM exchange 406, and the ATM exchange 406 exchanges the ISDN data packet to the ATM packet. The ATM packet is exchanged between the ATM switch 406 and the service server 400 by converting to and vice versa. Similarly, in the communication between the service server 400 and the personal credit terminal 100 and the communication between the service server 400 and the payment system 103, the ATM exchange 406 corresponds to each communication method and of the communication data. Perform the conversion.

[0154] Further, in order to reduce communication costs between the personal credit terminal 100 and the service providing system 102 and between the credit payment device 101 and the service providing system 102, the service providing system 102 is usually a personal remote credit. It is installed in each area that provides payment services. Therefore, the ATM switch 406 is connected to a dedicated digital communication line 417 that connects to a service providing system in another region. In this case, the service providing systems 102 share data with each other and perform data processing in cooperation with each other.

Next, the payment system 103 will be briefly described.

[0156] FIG. 5 is a block configuration diagram of the payment system 103. The payment system 103 includes a transaction processing server 500 that processes payment information data to be exchanged with the service providing system 102 in a personal remote credit payment service, and a subscriber information server 501 that manages personal information of credit service subscribers. The member store information server 502 that manages the information of the member stores of the credit service, the transaction information server 503 that manages the transaction information of credit settlement, and the management system 506 that the payment processing institution manages the operation of the payment system 103. Each of the servers 500 to 503 and the management system 506 is composed of one or a plurality of computers.

Further, the transaction processing server 500, the subscriber information server 501, the member store information server 502, and the transaction information server 503 are connected to the ATM-LAN switch 504 by the ATM-LAN cables 508,509,510,511, respectively, and are connected to the transaction processing server. Accesses the subscriber information server 501, the member store information server 502, or the transaction information server 503 via the ATM-LAN switch 504.

[0158] Further, the ATM-LAN switch 504 is connected to the ATM switch 505 by the ATM-LAN cable 513. A digital communication line 111 connected to the service providing system 102 is connected to the ATM exchange 505, and the transaction processing server communicates with the service providing system 102 via the ATM-LAN switch 504 and the ATM exchange 505.

In the personal remote credit payment service, the payment processing performed by the payment system 103 is performed by the transaction processing server 500, the subscriber information server 501, and the member store information server in response to the payment request from the service providing system 102. It is established by updating the information of 502 and the transaction information server 503, respectively.

Further, in the ATM exchange 505, in addition to the digital communication line 111 connected to the service providing system 102, the bank dedicated line 515 connected to the bank online system, and the dedicated digital connected to the payment system of another payment processing institution. The line 516 is connected, and the payment system 103 communicates with the bank online system and the payment system of another payment processing institution to perform payment processing between financial institutions.

[0161] The management system 506 is connected to the ATM-LAN switch 507 by the ATM-LAN cable 512, and further connected to the ATM switch 505 by the ATM-LAN cable 514. The management system 506 accesses the transaction processing server 500, the subscriber information server 501, the member store information server 502, or the transaction information server 503 via the ATM-LAN switch 507, the ATM switch 505, and the ATM-LAN switch 504. , Operates and manages the payment system 103.

[0162] The ATM exchange 505 operates as a data communication exchange in communication between the outside and the inside of the payment system 103 and communication between the inside of the payment system 103. In addition, the ATM switch 505 has a communication adapter function corresponding to a plurality of communication methods, and is used for communication between the transaction processing server 500 and the service providing system 102, and communication between the transaction processing server 500 and the bank online system. In the communication between the transaction processing server 500 and the payment system of another payment processing institution, the ATM exchange 505 converts the communication data according to each communication method.

[0163] Next, the personal remote credit payment service provided by this system will be described.

[0164] The personal remote credit card payment service is roughly divided into four processes: "payment", "cancellation", "customer service call", and "inquiry call".

[0165] "Payment" is a process in which a user pays a merchant by credit, and "Cancel" is a personal remote. -The process of canceling a transaction completed by the "payment" process of the credit card payment service by wireless communication based on the agreement between the user and the merchant. The "customer service call" is the "payment" of the personal remote credit card payment service. "Inquiry call" is a personal remote credit card payment service that enables the merchant to contact the user who has made a transaction even if he / she does not know the user's phone number. It is a process that enables a user to make an inquiry to a merchant who has made a transaction by the "payment" process without knowing his / her own phone number.

[0166] First, the flow of processing of "payment" will be described.

[0167] FIG. 6 shows the flow of processing of payment of the personal remote credit payment service. In addition, (a) to (h) of FIG. 7 show a display example of LCD203 of the personal credit terminal 100 in the above-mentioned "payment" processing, and (a) to (g) of FIG. 8 are credit settlement. A display example of LCD 302 of the terminal 300 is shown.

[0168] FIG. 7 (a) is an initial screen when the personal credit terminal is in the digital radiotelephone mode, FIG. 7 (b) is an initial screen when the personal credit terminal is in the credit card mode, and FIG. 8 (a) is. The initial screen when the credit card payment terminal is in the digital telephone mode, and FIG. 8 (b) is the initial screen when the credit card payment mode is in the credit card payment mode.

[0169] The process of "payment" begins with the user presenting what to purchase to the person in charge and the person in charge calculating the amount of the item.

[0170] In FIG. 6, the person in charge first calculates the total amount of the price using the cash register 311 of the credit card settlement device (the billing amount is calculated by the cash register 600). The cash register then displays the calculated total amount (display of billed amount 601). The person in charge tells the user the total price of the item and asks for the payment method (present the billing amount and ask for the payment method 602). The user wants "payment" for the personal remote credit card payment service (instructs "payment" for the personal remote credit card payment service 603), while the person in charge presses the credit card payment switch 312 of the credit card payment device. Press (press the credit card payment switch 604) to instruct the user to start the payment operation on the personal credit terminal 100 (instruct to start the payment operation 606). At this time, a credit settlement command is transmitted from the cash register 311 to the credit settlement terminal 300 via the RS-232C cable 313. The credit card payment terminal 300 automatically enters the credit card payment mode, and the LCD 302 displays a screen as shown in FIG. 8 (c) (payment operation waiting display 605).

[0171] The user sets the personal credit terminal 100 to the credit card mode with the mode switch 204, switches the credit card displayed on the LCD 203 with the function switch 207, and selects the credit card to be used for payment. At this time, the personal credit terminal 100 changes from the screen of FIG. 7 (b) to the screen of FIG. 7 (c). Then, with the function switch 207, select "Payment" from the menu and press the execute switch 211. Then, the personal credit terminal 100 becomes the screen shown in FIG. 7 (d). As shown in FIG. 7 (e), the user inputs the amount to be paid by the numeric keypad switch 208, specifies the payment option by the function switch 207, and presses the execution switch 211. Then, the confirmation screen shown in FIG. 7 (f) is displayed, and the user points the infrared communication port 200 toward the credit card payment terminal 300 and presses the execution switch 21 (payment operation 607). Then, the personal credit terminal 100 transmits a message indicating the payment amount, the payment offer 608, to the credit payment device 101 by infrared communication.

[0172] The credit card payment terminal 300 receives the payment offer 608 from the infrared light receiving / emitting module 301, collates the payment amount and the billing amount in the payment offer 608, and sends a response message to the payment offer and a payment offer response 609 by infrared rays. It is transmitted to the personal credit terminal 100 by communication. Further, the credit settlement terminal 300 transmits a message requesting the user's credit inquiry, the credit inquiry request 610, to the service providing system 102 by digital telephone communication. At this time, the credit card payment terminal 300 displays the screen shown in FIG. 8 (d) (credit inquiry display 611).

[0173] On the other hand, the personal credit terminal 100 receives the payment offer response 609 from the infrared communication port 200, collates the billed amount and the payment amount in the payment offer response 609, and requests the payment of the payment by credit, the payment. Request 613 is sent to the service providing system 102 via digital radiotelephone communication. At this time, the personal credit terminal 100 displays the screen shown in FIG. 7 (g) (payment processing in progress display 612).

[0174] The service providing system 102 receives the credit inquiry request 610 from the credit card payment terminal 300 and the payment request 613 from the personal credit terminal 100, respectively, collates the contents thereof, and further, the credit status of the user. Investigate, generate a response message for the credit inquiry request, credit inquiry response 614, and send it to the credit settlement terminal 300.

[0175] The credit settlement terminal 300 receives the credit inquiry response 614 from the service providing system 102, displays the content of the credit inquiry response 614 as shown in FIG. 8 (e), and obtains the result of the credit inquiry by the person in charge. (Credit inquiry result display 615).

[0176] The person in charge confirms the credit inquiry result, presses the execution button 308 of the credit card payment terminal 300, and instructs the start of the payment process (payment process request operation 616). Then, the credit card payment terminal 300 sends a message requesting payment processing, a payment request 617, to the service providing system 102 by digital telephone communication, and displays the screen of FIG. 8 (f) (payment in progress display 618). ..

[0177] The service providing system 102 receives the payment request 617 from the credit card payment terminal 300, and transmits a message requesting the payment process to the payment system 103, the payment request 619, to the payment system 103. A The payment system 103 receives the payment request 619 from the service providing system 102, performs the payment processing, and sends a message indicating that the payment processing is completed and a payment completion notification 620 to the service providing system 102.

[0178] The service providing system 102 receives the payment completion notification 620 from the payment system 103, and sends a message indicating that the payment process is completed, the payment completion notification 621, to the credit card payment terminal 300.

[0179] The credit card payment terminal 300 receives the payment completion notification 621, displays the content of the payment completion notification 621 as shown in FIG. 8 (g), and notifies the person in charge that the payment process is completed ( Payment completion display 622). Further, the credit card payment terminal 300 issues an electronic receipt 623 and transmits it to the service providing system 102 by digital telephone communication.

[0180] The service providing system 102 receives the receipt 623 issued by the credit payment terminal 300, generates the receipt 624 converted into the data format for the personal credit terminal, and uses digital wireless telephone communication to personalize the receipt 624. Send to credit terminal 100.

[0181] The personal credit terminal 100 receives the receipt 624 from the service providing system 102, displays the contents of the receipt 624 as shown in FIG. 7 (h), and indicates that the payment process is completed. Notify the user (receipt display 625).

[0182] As described above, the "payment" process of the personal remote credit card payment service is performed. The details of the contents of the data exchanged between the devices in the above-mentioned "payment" process will be described later.

Next, the flow of the cancel process will be described.

[0184] FIG. 9 shows the flow of cancellation processing of the personal remote credit payment service.

Further, (a) to (h) of FIG. 10 show a display example of the LCD 203 of the personal credit terminal 100 in the above-mentioned cancellation process, and (a) to (g) of FIG. 11 show an example of display of the LCD 203 of the personal credit terminal 100. , A display example of LCD 302 of the credit card payment terminal 300 is shown.

[0186] As for the situation of processing the "cancellation" of the personal remote credit payment service, there are cases where the user and the merchant are close enough to reach each other, and cases where the user and the merchant are far away from each other. is there. The difference between the two cases is whether the user and the merchant agree on the initial "cancellation" process by voice or by telephone, and the flow of processing after the agreement is It's the same. Therefore, here, a case where both are separated from each other will be described.

[0187] The process of "cancellation" begins when the user and the person in charge of the merchant agree to perform the process of "cancellation" for the transaction once completed by the process of "settlement". ..

[0188] In FIG. 9, first, the user and the person in charge of the merchant agree to perform the "cancel" process by telephone (voice call 900), and both start the cancel operation.

[0189] First, the person in charge of the merchant puts the credit payment terminal 300 into the credit payment mode with the mode switch 304, and displays the screen of FIG. 11 (a). With the function switch 306, select Sales Cancel from the menu as shown in the screen of FIG. 11 (b), and press the execute switch 307. Then, the sales history list shown in FIG. 11 (c) is displayed on the credit card payment terminal 300, and the person in charge selects and executes the transaction to be canceled with the function switch 306 as shown in the screen shown in FIG. 11 (d). Press switch 308. Then, the confirmation screen shown in Fig. 11 (e) is displayed, and the person in charge presses the execution switch 308 (cancel operation 901).

[0190] Then, the credit card payment terminal 300 transmits a message requesting the processing of "cancellation", a cancellation request 903, to the service providing system 102 by digital telephone communication. At this time, the credit card payment terminal 300 displays the screen shown in FIG. 11 (f) (cancellation processing display 902).

On the other hand, the user sets the personal credit terminal 100 to the credit card mode with the mode switch 204, switches the credit card displayed on the LCD 203 with the function switch 207, and selects the credit card used for payment. Further, with the function switch 207, select Cancel from the menu as shown in the screen of FIG. 10 (a), and press the execute switch 211. Then, the screen of the purchase history list shown in FIG. 10B is displayed on the personal credit terminal 100, and the user selects the transaction to be canceled with the function switch 207 and presses the execution switch 211. Then, the confirmation screen shown in Fig. 10 (c) is displayed, and the user presses the execution switch 211 (cancel operation 904).

[0192] The personal credit terminal 100 transmits a message requesting the processing of "cancellation", a cancellation request 906, to the service providing system 102 by digital wireless telephone communication. At this time, the personal credit terminal 100 displays the screen shown in FIG. 10 (d) (cancellation processing display 905).

[0193] The service providing system 102 receives the cancellation request 903 from the credit card payment terminal 300 and the cancellation request 903 from the personal credit terminal 100, respectively, collates the contents thereof, and sets the payment system 103 to the cancellation request 903. A message requesting "cancellation" processing, cancellation request 907, is sent.

[0194] The payment system 103 receives the cancellation request 907 from the service providing system 102, cancels the requested transaction, and sends a message indicating that the cancellation processing is completed, a cancellation completion notification 908, to the service providing system 102. Send to.

[0195] The service providing system 102 receives the cancellation completion notification 908 from the payment system 103, and sends a message indicating that the cancellation process is completed and the cancellation completion notification 909 to the credit card payment terminal 300 by digital telephone communication. Further, a message indicating that the cancellation process is completed and a cancellation process receipt 910 are generated for the personal credit terminal 100 and transmitted by digital wireless telephone communication.

[0196] The credit card payment terminal 300 receives the cancellation completion notification, displays the content of the cancellation completion notification as shown in FIG. 11 (g), and notifies the person in charge that the cancellation process is completed (cancellation process). Completion display 911).

[0197] The personal credit terminal 100 receives the cancellation processing receipt, displays the cancellation processing receipt as shown in FIG. 10 (e), and notifies the user that the cancellation processing is completed (cancellation processing). Receipt display 912).

[0198] As described above, the "cancellation" process of the personal remote credit payment service is performed. After that, the person in charge can make another telephone call (voice call 914) with the user by operating the customer service call (customer service call 913). The customer service call will be described below. Further, in the above-mentioned "cancellation" process, the details of the contents of the data exchanged between the devices will be described later.

Next, the flow of processing of the customer service call will be described.

[0200] FIG. 12 (a) shows the processing flow of the customer service call of the personal remote credit payment service. Further, (a) to (b) of FIG. 13 show a display example of the LCD 203 of the personal credit terminal 100 in the above-mentioned processing of the customer service call, and (a) to (g) of FIG. A display example of LCD 302 of the credit card payment terminal 300 is shown.

[0201] "Customer Service Call" enables a user who has made a transaction by processing "Payment" of a personal remote credit payment service, even if the merchant does not know the user's telephone number. It is a process to do. Therefore, the "customer service call" is premised on the fact that there has previously been a transaction between the user and the merchant by processing the "payment" of the personal remote credit payment service.

[0202] The processing of the "customer service call" begins when the person in charge of the merchant starts the operation of the "customer service call" on the credit card payment terminal 300.

[0203] In FIG. 12 (a), first, the person in charge of the merchant sets the credit payment terminal 300 to the credit payment mode with the mode switch 304, and displays the screen of FIG. 14 (a). Next, the person in charge selects "sales history" from the menu with the function switch 306 and presses the execution switch 308. Then, the credit card payment terminal 300 displays the sales history list shown in FIG. 14 (b). With the function switch 306, the person in charge selects the transaction made with the user who wants to make a telephone contact, as shown in the screen of Fig. 14 (c), and also from the operation menu at the bottom of the screen, "Telephone". Select and press execute switch 308 (Customer Service Call Operation 1200). Then, the credit settlement terminal 300 automatically enters the digital telephone mode, displays the screen shown in FIG. 14 (d) (display during connection processing, in progress 1201), and makes a customer service call to the service providing system 102. A message requesting processing, customer service call request 1202, is sent by digital telephone communication.

[0204] The service providing system 102 receives the customer service call request 1202, collates it with the access control information set by the user, and sends a message calling the user, the customer service call 1203, to the user's personalized communication by digital radiotelephone communication. Send to credit terminal 100. Further, the service providing system 102 transmits a message permitting a call with the user, a customer service call request answer 1204, to the credit settlement terminal 300 by digital telephone communication.

[0205] The credit card payment terminal 300 receives the customer service call request response 1204 from the service providing system 102, displays the screen of FIG. 14 (e), and informs the person in charge that the user is being called (during calling). Display 1206).

[0206] On the other hand, the personal credit terminal 100 receives the customer service call 1203, outputs a ringtone, displays the screen of FIG. 13 (a), and informs the user that a call is received from the merchant. Notify (Incoming call display 1205). When the user presses the call switch 205 (call operation 1207), the personal credit terminal 100 sends a message indicating that the user has accepted the incoming call, the incoming call answering 1208, to the service providing system 102 by digital radiotelephone communication. Display the screen shown in Fig. 13 (b) (in-call display 1209).

[0207] The service providing system 102 receives the incoming call answering 1208, and transmits a message indicating that the user has accepted the call, the calling answering 1210, to the credit settlement terminal 300 by digital telephone communication.

[0208] The credit card payment terminal 300 receives the call answer 1210, displays the screen of FIG. 14 (f) (in-call display 1211), and the merchant enters a call state with the user (voice call 1212).

[0209] As described above, the processing of the "customer service call" of the personal remote credit payment service is performed.

[0210] For the customer service call, the person in charge of the merchant selects "phone" from the operation menu at the bottom of the screen on the sales history details screen shown in FIG. 14 (g) and presses the execution switch 308 (customer service). The process can also be started by calling operation 1200), and on the completion screen of the process of "Cancel" in Fig. 11 (g), select "Customer Service Call" from the operation menu at the bottom of the screen and switch to execute. You can also start the process by pressing 308 (Customer Service Call Operation 1200).

[0211] In the process of the above-mentioned "customer service call", the details of the contents of the data exchanged between the devices will be described later.

[0212] Next, the flow of processing of the "inquiry call" will be described.

[0213] Fig. 12 (b) shows the processing flow of the inquiry call of the personal remote credit card payment service.

[0214] Further, (b) to (f) of FIG. 13 show a display example of the LCD 203 of the personal credit terminal 100 in the above-mentioned processing of the "inquiry call", and (h) and (f) of FIG. Shows a display example of LCD 302 of the credit card payment terminal 300.

[0215] "Inquiry call" enables a user to make an inquiry call to a merchant who has made a transaction by processing "payment" of a personal remote credit payment service without knowing his / her own telephone number. It is a process to do.

[0216] The process of "inquiry call" starts from the point where the user starts the operation of "inquiry call" on the personal credit terminal 100.

[0217] In FIG. 12 (b), the user first sets the personal credit terminal 100 to the credit card mode with the mode switch 204, and displays the screen of FIG. 13 (c). Next, as shown in the screen of FIG. 13 (d), the user selects usage history from the menu with the function switch 207, and presses the execution switch 211. Then, the sales history list shown in FIG. 13 (e) is displayed on the personal credit terminal 100. The user uses the function switch 207 to select a transaction made with a merchant who intends to make a telephone contact, as shown in the screen shown in FIG. 13 (f), and also selects "inquiry" from the operation menu at the bottom of the screen. Then press execute switch 211 (inquiry call operation 1213). Then, the personal credit terminal 100 automatically enters the digital radiotelephone mode, displays the screen shown in FIG. 13 (g) (indication during connection processing in progress 1214), and makes an "inquiry call" to the service providing system 102. A message requesting processing, inquiry call request 1215, is sent by digital radiotelephone communication.

[0218] The service providing system 102 receives the inquiry call request 1215, and transmits a message calling the merchant, the inquiry call 1216, to the credit settlement terminal 300 of the merchant by digital telephone communication. Further, the service providing system 102 transmits a message permitting a call with the merchant, an inquiry call request answer 1217, to the personal credit terminal 100 by digital radiotelephone communication.

[0219] The personal credit terminal 100 receives the inquiry call request response 1217 from the service providing system 102, displays the screen of FIG. 13 (h), and notifies the user that the merchant is being called (calling display). 1219).

[0220] On the other hand, the credit card payment terminal 300 receives the inquiry call 1216, outputs a ringtone, displays the screen of FIG. 14 (h), and notifies the merchant that a call is received from the user ( Incoming call display 1218). When the person in charge of the merchant picks up the handset 303 (call operation 1220), the credit settlement terminal 300 sends a message indicating that the merchant has accepted the incoming call, an incoming call answering 1221, to the service providing system 102 by digital telephone communication. Display the screen shown in Fig. 14 (f) (in-call display 1222).

[0221] The service providing system 102 receives the incoming call answering 1221 and transmits the call answering 1223, a message indicating that the merchant has accepted the call, to the personal credit terminal 100 by digital radiotelephone communication.

[0222] The personal credit terminal 100 receives the call answer 1223, displays the screen of FIG. 13 (b) (in-call display 1224), and the user enters a call state with the merchant (voice call 1225).

[0223] As described above, the processing of the "inquiry call" of the personal remote credit settlement service is performed.

[0224] For the inquiry call, the user selects "inquiry" from the operation menu at the bottom of the screen on the usage history details screen shown in FIG. 13 (i) and presses the execution switch 211 (inquiry call operation 1213). Can also start the process.

[0225] In the process of the above-mentioned "inquiry call", the details of the contents of the data exchanged between the devices will be described later.

Next, the internal configuration of the personal credit terminal 100 will be described.

FIG. 15A is a block configuration diagram of the personal credit terminal 100. This terminal is a CPU (Central Processing Unit) 1500 that processes transmitted data and received data according to a program stored in ROM (Read Only Memory) 1501 and controls other components via bus 1529. The RAM (Random Access Memory) 1502 that stores the data processed by the CPU 1500 and the data processed by the CPU 1500, the terminal ID, telephone number, user ID of the user, and the private key and public key of the personal credit terminal 100. , And EEPROM (Electric Erasable Programable Read Only) that stores the service provider ID, telephone number, and service provider public key of the service provider system 102. Memory) 1503, LCD controller 1504 that controls the operation of LCD203 according to the control of CPU1500 and displays the image set by CPU1500 on the LCD, and encryption that performs data encryption processing and decryption processing under the control of CPU1500. A processing processor 1505, a data codec 1506 that encodes transmitted data and decodes received data under the control of CPU 1500, an infrared communication module 1507 that transmits and receives infrared light during infrared communication, and a mode switch by the user. 204, call switch 205, end switch 206, function switch 207, ten-key switch 208, power switch 209, and key operation control unit 1509 that detects the switch operation of execution switch 211, speaker 1510, receiver 202, or headset jack 212. Audio processing unit 1511 that drives and amplifies the analog audio signal input from the microphone 210 or headset jack 212, encoding the analog audio signal 1542 to digital audio data, and decoding the digital audio data to the analog audio signal 1543. The audio coden 1512 that performs the above, the channel coden 1513 that generates the transmission data on the wireless channel and extracts the data addressed to itself from the received data, and the serial digital signal 1547 input from the channel coden 1513, are the PLL 1516. The modulator 1514 that converts the oscillating electric signal 1552 supplied from the , The demodulation unit 1515 that supplies the serial digital signal 1548 to the channel codec 1513 and the analog transmission signal 1549 supplied from the modulation unit 1514 are converted into radio waves and output from the antenna 201. Upon reception, the analog reception signal 1550 is input to the demodulator 1515.RF unit 1517, battery capacity detection unit 1518 that detects the battery capacity of the personal credit terminal 100, activation control of channel codec 1513, PLL 1516 and RF unit 1517, key operation control unit 1509, channel codec 1513 and battery capacity. It is equipped with an interrupt signal input from the detection unit 1518, and a control logic unit 1508 that acts as an interface when the CPU 1500 accesses the key operation control unit 1509, the voice processing unit 1511, and the internal registers of the channel codec. ing.

[0228] The cryptographic processing processor 1505 has a function of encryption and decryption of the private key method and a function of encryption and decryption of the public key method, and the encryption method and the key set by the CPU 1500 are used by the CPU 1500. The set data is encrypted or decrypted.

[0229] Further, the data codec 1506 encodes the transmitted data and decodes the received data under the control of the CPU 1500. In this case, the coding includes communication control information and error correction information, and is actually Decoding means the process of generating the data to be transmitted to, and the decoding is the process of performing error correction processing on the received data, removing excess communication control information, and generating the data originally intended to be transmitted by the sender. Means processing. The data codec 1506 has a data coding and decoding function in digital radiotelephone data communication and a data coding and decoding function in infrared communication, and the CPU1500 is used for data set by the CPU1500. Performs the coding process and the decoding process set by.

Further, as shown in FIG. 15B, the infrared communication module 1507 includes a series-parallel conversion circuit 1560 that performs bidirectional conversion between parallel data and serial data, and a series-parallel conversion. A modulation / demodulation circuit 1561 that modulates the digital signal 1562 converted to serial data by the circuit 1560 into a signal that is actually transmitted as infrared data, and demolishes the received analog signal 1565 into a serial digital signal 1563, and a modulation / demodulation circuit 1561. It is provided with an infrared light receiving / emitting unit 200 that converts the modulated signal 1564 into infrared light and emits light, and also converts the received infrared light into an analog signal 1565.

[0231] Further, in the key operation control unit 1509 for detecting the switch operation by the user, the user can use the mode switch 204, the call switch 205, the end switch 206, the function switch 207, the numeric keypad switch 208, the power switch 209, or the execution switch 211. When either is pressed, the key operation control unit 1509 asserts the interrupt signal 1538 prompting the processing corresponding to the switch operation to the CPU 1500. Further, as shown in FIG. 18A, the key operation control unit 1509 includes a key operation control register (KEYCTL) 1812 for setting the enable / disable of each switch.

[0232] Further, as shown in FIG. 18A, the voice processing unit 1511 includes a voice processing unit control register (SCTL) that controls the voice processing operation.

Further, the audio codec 1512 encodes the analog audio signal 1542 input from the audio processing unit 1511 into digital audio data, and decodes the digital audio data input from the channel codec 1513 into an analog audio signal 1543. To do. The analog audio signal 1543 is supplied to the audio processing unit 1511, and the audio processing unit 1511 amplifies the analog audio signal 1543 and drives the receiver 202 to output audio from the receiver 202. Further, the digital voice data generated by the coding is supplied to the channel codec 1513 and actually converted into transmission data on the wireless channel.

[0234] Further, two types of data are input to the channel codec 1513 as data to be transmitted. One is digital audio data input from the audio codec 1512, and the other is data communication data input from the CPU 1500 via the control logic unit 1508.

[0235] The channel codec 1513 adds identification information between digital voice data and data communication data as header information to the respective data, and further converts the data into a digital wireless telephone data format to serialize the digital signal 1547. Is supplied to the modulation unit 1514.

[0236] On the contrary, the channel codec 1513 first collates the terminal ID with respect to the serial digital signal 1548 input from the demodulator 1515, extracts only the data addressed to itself, and further, the digital wireless telephone. The communication control information of the above is removed, and the digital voice data and the data communication data are identified from the data header information and supplied to the voice codec 1512 and the control logic unit 1508, respectively. Further, the channel codec 1513 asserts the interrupt signal 1554 when receiving a digital radiotelephone and when receiving data communication data. The interrupt signal 1554 is an interrupt signal that prompts the CPU 1500 to process an incoming digital radiotelephone and to process data communication data.

[0237] In order to perform such an operation, the channel codec 1513 has an ID register (ID) 1805 for storing the terminal ID and a channel codec control register for controlling the operation of the channel coden 1513, as shown in FIG. 18A. (CHCTL) 1806, audio transmission buffer 1807 for storing digital audio data input from audio codec 1512, audio reception buffer 1808 for storing digital audio data extracted from received data, and input from control logic unit 1508. It includes a data transmission buffer 1809 for storing the data communication data to be received, and a data reception buffer 1810 for storing the data communication data extracted from the received data.

[0238] The modulation unit 1514 converts the serial digital signal 1547 input from the channel codec 1513 into an analog transmission signal 1549 using the oscillating electric signal 1552 supplied from the PLL 1516 as a baseband, and supplies the signal to the RF unit. The analog transmission signal 1549 supplied to the RF unit is output from the antenna 201 as a radio wave.

On the contrary, when the antenna 201 receives the radio wave, the analog reception signal 1550 is input from the RF unit 1517 to the demodulation unit 1515. The demodulation unit 1515 demodulates the analog reception signal 1550 using the oscillating electric signal 1553 supplied from the PLL 1516 as the base band of the analog reception signal 1550, and supplies the serial digital signal 1548 to the channel codec 1513.

Further, the battery capacity detection unit 1518 that detects the battery capacity sends an interrupt signal 1557 when the battery capacity of the personal credit terminal 100 becomes equal to or less than the value Q (Q&gt; 0) set by the CPU 1500. Assert. The interrupt signal 1557 is an interrupt signal that prompts the CPU 1500 to back up the data on the RAM 1502, and Q is a value sufficient for the personal credit terminal 100 to perform the backup process.

Further, as shown in FIG. 18A, the control logic unit 1508 includes a frame counter (FRAMEC) 1800, a start frame register (FRAME) 1801, a clock counter (CLOCKC) 1802, and an update time register. It contains five registers (UPTIME) 1803 and interrupt register (INT) 1804.

[0242] The frame counter 1800 is a counter that counts the number of frames of a digital wireless telephone, the activation frame register 1801 is a register that stores the frame number to be activated next time, and the clock counter 1802 is a counter that counts the current time. The time register 1803 is a register that stores the time when the personal credit terminal 100 communicates with the service providing system 102 to update the data on the RAM 1502 (update process), and the interrupt register 1804 is sent to the CPU 1500. This is a register that indicates the cause of the interruption.

[0243] Generally, in a digital radiotelephone, the control data of the control channel of the digital radiotelephone is intermittently received and collated with the terminal ID to realize an incoming call addressed to oneself. The personal credit terminal 100 uses the frame counter 1800 and the activation frame register 1801 to perform intermittent reception of control data. The frame number to be started next time is stored in the start frame register 1801 in advance, and when the frame counter 1800 counts up and becomes equal to the value of the start frame register 1801, the control logic unit 1508 receives the address data. The channel codec 1513, PLL1516, and RF unit 1517 are activated via the signal line 1558 to receive control data.

Further, when any of the interrupt signals 1538, 1554, and 1557 of the interrupt signal 1538, 1554, and 1557 is asserted, the control logic unit 1508 sets the interrupt factor in the interrupt register (INT) 1804 and sets the interrupt signal 1519. Assert and prompt CPU1500 for interrupt processing. The CPU1500 reads the interrupt register 1804 in interrupt processing and performs processing according to the interrupt factor.

Each bit field of this interrupt register (INT) 1804 is meant as shown in FIG. 18 (b).

[0246] Bit 31 indicates the state of the power switch 209, and when the value is 0, it indicates that it is in the power-off state, and when the value is 1, it indicates that it is in the power-on state.

[0247] Bit 30 indicates the state of digital radiotelephone communication, and when the value is 0, it indicates that digital radiotelephone communication is not being performed, and when the value is 1, digital radiotelephone communication is performed. Indicates that you are in a state of being.

[0248] Bit 29 indicates the occurrence of a frame interrupt that prompts intermittent reception of control data, and when the value is 1, it indicates that a frame interrupt has occurred. This bit field is set to 1 when the value of the frame counter 1800 matches the value of the startup frame register 1801.

[0249] Bit 28 indicates that an incoming call interrupt has occurred, and when the value is 1, it indicates that a digital radiotelephone has been received. This bit field is set to 1 when the terminal IDs match and the interrupt signal 1554 is asserted in the intermittent reception of control data of the digital radiotelephone.

[0250] Bit 27 indicates that a data reception interrupt has occurred, and when the value is 1, it indicates that data reception data has been received. This bit field is set to 1 when data communication data is received and the interrupt signal 1554 is asserted in digital radiotelephone communication.

[0251] Bit 26 indicates the occurrence of an update interrupt that prompts the data update process, and when the value is 1, it indicates that the update interrupt has occurred. This bit field is set to 1 when the value of the clock counter 1802 matches the value of the update time register 1803.

[0252] Bit 25 indicates the occurrence of a battery interrupt prompting the backup process, and when the value is 1, it indicates that the battery interrupt has occurred. This bit field is set to 1 when the interrupt signal 1557 input from the battery capacity detector 1518 is asserted.

[0253] Bit 24 indicates that a key interrupt has occurred due to a switch operation, and when the value is 1, it indicates that a key interrupt has occurred.

[0254] Bits 0 to 9 correspond to switches 0 to 9 of the ten-key switch 208, respectively, and bits 10 and 11 correspond to switches "*" and "#" of the ten-key switch, respectively. Bits 12 to 15 correspond to the switches "F1" to "F4" of the function switch 207, respectively, and bits 16 to 20 correspond to the power switch 209, the execution switch 211, and the mode switch 204, respectively. , Corresponds to the call switch 205 and the end switch 206, and when the value of the bit is 1, it indicates that the switch corresponding to the bit is pressed.

Next, the data stored in the RAM 1502 will be described.

[0256] FIG. 16 is a schematic diagram of a RAM map of the data stored in the RAM 1502.

[0257] The RAM 1502 has five areas: a basic program area 1600, a service data area 1601, a user area 1602, a work area 1603, and a temporary area 1604. The basic program area 1600 stores upgraded modules of programs stored in ROM 1501 and patch programs.

The user area 1602 is an area that can be freely used by the user, the work 1603 area is a work area used by the CPU 100 when executing a program, and the temporary area 1604 is information received by the personal credit terminal 100. Is an area that temporarily stores. The service data area 1601 is an area for storing ID information, credit card information, history information, etc. of the personal remote credit payment service, and the data in this area is managed by the service providing system 102.

[0259] The service data area 1601 further includes data management information 1605, personal information 1606, photo data 1607, user setting information 1608, telephone information 1609, credit card list 1610, usage history list 1611, and actual data area 1612. There are 8 areas. The data management information 1605 is an area for storing management information of information stored in the service data area 1601, the personal information 1606 is an area for storing information such as the user's name, age, and gender, and the photo data area 1607 is. The area for storing the data of the user's face photograph, the user setting information 1608 is an area for storing the user setting information related to the personal remote credit payment service, and the telephone information 1609 stores the information related to the digital wireless telephone. The area, the credit card list 1610 is an area for storing the list information of the credit card registered by the user, the usage history list 1611 is the area for storing the usage history information of the personal remote credit payment service, and the actual data area 1612 is. This area stores the actual data of the information managed in the other seven areas.

Next, the information stored in the service data area 1601 will be described in detail.

[0261] FIG. 17 is a schematic diagram showing in detail the relationship of the information stored in the service data area 1601.

[0262] Data management information 1605 includes update date and time 1700, next update date and time 1701, terminal status 1702, personal information address 1703, photo data address 1704, user setting information address 1705, telephone information address 1706, credit card list address 1707. , And the usage history list address 1708 consists of nine pieces of information.

[0263] The update date and time 1700 indicates the date and time when the service providing system 102 last updated the data in the service data area 1601, and the next update date and time 1701 indicates the update of the data in the service data area 1601 by the next service providing system 102. Indicates the scheduled date and time of. The personal credit terminal 100 automatically starts the data update process at the set time of the next update date and time 1701.

[0264] The data update process is a process of having the service providing system 102 update the data in the service data area 1601. The data update process will be described in detail later.

[0265] Terminal status 1702 indicates the status of the personal credit terminal 100, personal information address 1703, photo data address 1704, user setting information address 1705, telephone information address 1706, credit card list address 1707, and usage history. The list address 1708 indicates the start address of the area in which the personal information 1606, the photo data 1607, the user setting information 1608, the telephone information 1609, the credit card list 1610, and the usage history list 1611 are stored, respectively.

[0266] The telephone information 1609 is further composed of three pieces of information: a calling telephone number 1709, a telephone directory address 1710, and a shortened dial setting file address 1711. The calling telephone number 1709 indicates the telephone number of the telephone that the user made last time, and this information is used when the digital radio telephone is resent. The telephone directory address 1710 and the abbreviated dial setting file address 1711 indicate addresses on the actual data area in which the telephone directory information and the abbreviated dial setting file are stored, respectively.

[0267] The credit card list 1610 stores list information of credit cards registered by the user. In the credit card list 1610, for one credit card, credit card name 1712 (1719), credit card number 1713 (1720), expiration date 1714 (1721), credit card status 1715 (1722), image data Seven pieces of information are stored: address 1716 (1723), object data address 1717 (1724), and access time 1718 (1725).

The credit card status 1715 (1722) indicates whether the credit card is valid and the usage limit, and the image data address 1716 (1723) stores the image data of the credit card. Indicates the address on the physical data area 1612. The object data address 1717 (1724) indicates the address where the object data of the program of the credit card is stored, and the access time 1718 (1725) indicates the latest time when the user used the credit card. ..

[0269] The object data address 1717 (1724) stores a local address indicating an address on the physical data area 1612 or a remote address indicating an address on the user information server 402 of the service providing system 102. If the remote address is stored at the object data address 1717 (1724), when the user selects and tries to use the credit card, the personal credit terminal 100 receives the object from the service providing system 102. Download the data to the temporary area 1604 and run the credit card program. Simply displaying the credit card will display the image data in the physical data area 1612 indicated by the image data address 1716 (1723) and will not download the object data.

The address stored in the object data address 1717 (1724) is determined by the service providing system 102. During the data update process, the access times of each credit card are compared, and the local address is assigned to the credit card with the latest access time. However, if there is enough capacity in the physical data area 1612, the object data addresses of all credit cards may be local addresses.

[0271] In the usage history list 1611, for the use of one personal remote credit payment service, the request number 1726 (1730), the service code 1727 (1731), the usage time 1728 (1732), and the usage information address 1729 are shown. The four information of (1733) is stored.

[0272] Request number 1726 (1730) is a number that uniquely indicates a transaction with a merchant, and the number issued by the personal credit terminal 100 when generating payment offer 608, service code 1727 (1731), is The code number indicating the type of credit card service used, the usage time 1728 (1732) indicates the time when the personal / remote credit payment service was used, and the usage information address 1729 (1733) indicates the address where the receipt is stored. ..

[0273] The usage information address 1729 (1733) stores a local address indicating an address on the physical data area 1612 or a remote address indicating an address on the user information server 402 of the service providing system 102.

[0274] When the remote address is stored in the usage information address 1729 (1733), when the user accesses the usage history information, the personal credit terminal 100 transmits the usage information from the service providing system 102 to a temporary area. Download to 1604 and display on LCD 203.

The address stored in usage information address 1729 (1733) is also determined by the service providing system. During the data update process, the usage time of each usage information is compared, and a local address is assigned to the usage information with the latest usage time. However, if there is enough capacity in the physical data area 1612, all usage information addresses may be local addresses.

Next, the processing performed by the CPU 1500 will be described.

[0277] FIG. 19 is a conceptual diagram of a flow of processing performed by the CPU 1500.

As shown in FIG. 19, the processing of the CPU 1500 can be roughly divided into 10 types of processes and an interrupt processing 1901.

The 10 types of processes are power-on process, wireless telephone process, credit card process, inquiry call process, customer service call process, data update process, backup process, remote access process, session establishment process, and power-off process. And these 10 kinds of processes are executed in the main loop 1900.

[0280] In each process, a word field indicating the status (status) of the process exists in RAM1502 corresponding to the process, and the CPU 1500 executes each process according to the value of this process status.

[0281] The power-on process is a process of performing initial operation processing when the user turns on the power switch, the wireless telephone process is a process of performing processing in digital wireless telephone mode, and the credit card process is in credit card mode. Processing process, inquiry call process is process of processing "inquiry call", customer service call process is process of processing "customer service call", data update process is process of processing data update, backup The process is a process that performs backup processing, the remote access process is a process that accesses data on the user information server of the service providing system, and the session establishment process is a process that establishes a communication session with the service providing system. The process and power-off process are processes that perform termination processing when the user turns off the power switch.

[0282] In FIG. 19, resetting the personal credit terminal proceeds to step 1902, where the CPU 1500 activates the power-on process.

Next, in step 1903, it is checked whether or not the power-on process is active, and if it is inactive, the process proceeds to step 1905, and if it is active, the process proceeds to step 1904, and the power-on process is performed. Execute for a certain period of time and proceed to step 1905.

[0284] In step 1905, it is checked whether or not the radiotelephone process is active, and if it is inactive, the process proceeds to step 1907, and if it is active, the process proceeds to step 1906, and the radiotelephone process is performed for a certain period of time. Execute and proceed to step 1907.

[0285] In step 1907, it is checked whether or not the credit card process is active, and if it is inactive, the process proceeds to step 1909, and if it is active, the process proceeds to step 1908, and the credit card process is performed for a certain period of time. Execute and proceed to step 1909. In step 1909, it is checked whether the inquiry call process is active, and if it is inactive, the process proceeds to step 1911. If it is active, the inquiry call process proceeds to step 1910, and the inquiry call process is executed for a certain period of time. , Proceed to step 1911. In step 1911, it is checked whether the customer service call process is active, and if it is inactive, the process proceeds to step 1913, and if it is active, the process proceeds to step 1912, and the customer service call process is executed for a certain period of time. Then proceed to step 1913.

[0286] In step 1913, it is checked whether or not the data update process is active, and if it is inactive, the process proceeds to step 1915, and if it is active, the process proceeds to step 1914, and the data update process is performed for a certain period of time. Execute and proceed to step 1915.

[0287] In step 1915, it is checked whether or not the backup process is active, and if it is inactive, the process proceeds to step 1917, and if it is active, the process proceeds to step 1916, and the backup process is executed for a certain period of time. Then proceed to step 1917.

[0288] In step 1917, it is checked whether or not the remote access process is active, and if it is inactive, the process proceeds to step 1919, and if it is active, the process proceeds to step 1918, and the remote access process is performed for a certain period of time. Execute and proceed to step 1919. In step 1919, it is checked whether the session establishment process is active, and if it is inactive, the process proceeds to step 1921, and if it is active, the process proceeds to step 1920, and the session establishment process is executed for a certain period of time. , Proceed to step 1921.

[0289] In step 1921, it is checked whether or not the power-off process is active, and if it is active, the process proceeds to step 1922, the power-off process is executed, and if it is inactive, the process returns to step 1903. When the interrupt signal 1518 is asserted, the CPU executes interrupt processing 1901 and returns to the processing of the original main loop 1900.

[0290] In the interrupt process 1901, first, in step 1923, the CPU 1500 reads the interrupt register (INT) 1804 and copies it to the word interrupt on the RAM (work area). At this time, the interrupt register (INT) 1804 read by the CPU is echo-reset.

Next, in step 1924, it is checked from the value of bit 28 of interrupt whether or not it is an incoming call interrupt, and if it is not an incoming call interrupt (interrupt (bit28) = 0), the process proceeds to step 1926 and the incoming call interrupt is performed. In the case (interrupt (bit28) = 1), the process proceeds to step 1925, the process status of the wireless telephone process is set to active, and the process proceeds to step 1926.

[0292] In step 1926, it is checked from the value of bit 26 of interrupt whether or not it is an update interrupt, and if it is not an update interrupt (interrupt (bit26) = 0), the process proceeds to step 1928, and if it is an update interrupt (interrupt). (bit26) = 1) proceeds to step 1927, sets the process status of the data update process to active, and proceeds to step 1928.

[0293] In step 1924, it is checked from the value of bit 25 of interrupt whether or not it is a backup interrupt, and if it is not a backup interrupt (interrupt (bit25) = 0), the process proceeds to step 1930, and if it is a backup interrupt (interrupt). (bit25) = 1) proceeds to step 1929, sets the process status of the backup process to active, and proceeds to step 1930.

[0294] In step 1930, it is checked from the value of bit 24 of interrupt whether or not it is a key interrupt, and if it is not a key interrupt (interrupt (bit24) = 0), the interrupt process is terminated and the original main loop is used. Returning to the process, in the case of key interrupt (interrupt (bit24) = 1), the process proceeds to step 1931.

[0295] In step 1931, the value of the "power supply" bit (bit16) of interrupt is checked, and if it is 0, the interrupt processing is terminated and the process returns to the original main loop processing. If it is 1, the power supply is returned. It is determined that the switch has been operated, and the process proceeds to step 1932.

[0296] In step 1932, the value of the "power display" bit (bit31) of interrupt is examined, and if it is 0, it is determined that the power-off operation has been performed, and the process proceeds to step 1934. It is determined that the power-on operation has been performed, and the process proceeds to step 1933.

[0297] In step 1933, the process status of the power-on process is set to active, the interrupt process is terminated, and the process returns to the original main loop process.

[0298] In step 1934, the process status of the power-off process is set to active, the interrupt process is terminated, and the process returns to the original main loop process.

[0299] In the interrupt process 1901, the process whose process status becomes active returns to the main loop and is executed in the main loop.

[0300] Next, the digital signature processing and the sealing process performed when the personal credit terminal generates a message to be transmitted to the credit payment terminal and the service providing system will be described.

[0301] Since the digital signature processing and the sealing process are performed in the same way on the credit card payment terminal, the characters are not referred to as users, merchants, and service providers in the following, but Mr. A and Mr. B. So, the characters will be generalized and explained.

[0302] Digital signatures are electronically sent to messages by utilizing the property of public key cryptography that "messages encrypted with a private key can only be decrypted with the public key corresponding to the private key." It is a process of giving a digital signature.

[0303] FIGS. 20 (a) and 20 (b) are a flow diagram showing a procedure of digital signature processing when Mr. A's digital signature is given to a message, and a conceptual explanatory diagram of the flow, respectively.

[0304] First, in step 2000, the CPU performs a hash function operation on the message 2003 to generate a message digest 2004.

Next, in step 2001, the CPU uses a cryptographic processor to encrypt the message digest 2004 with Mr. A's private key to generate a digital signature 2005.

Next, in step 2002, the CPU adds the digital signature 2005 to the original message 2003. By the above procedure, the CPU generates message 2006 with Mr. A's digital signature.

[0307] 2006 in FIG. 20 (b) illustrates the digitally signed message of Mr. A. In the following, the digitally signed message shall be illustrated as in 2006 in the drawing. And.

[0308] Next, the sealing process will be described. The sealing process uses the property of public key cryptography that "a message encrypted with a public key can only be decrypted with the private key corresponding to the public key" to specify the content of the message. It is a process that makes it readable only by humans.

[0309] FIGS. 21 (a) and 21 (b) are a flow diagram showing a procedure for sealing a digitally signed message of Mr. A to Mr. B, a destination, and a conceptual explanatory diagram of the flow, respectively. is there.

[0310] First, in step 2100, the CPU uses a random function to generate a private key type encryption key and a private key 2104. Next, in step 2101, the CPU uses a cryptographic processor to encrypt the digitally signed message 2006 with the private key 2104.

Next, in step 2102, the CPU uses an encryption processing processor to encrypt the private key 2104 with the public key of Mr. B, the destination.

Next, in step 2103, the CPU adds the output 2106 of step 2102 to the output 2105 of step 2101. By the above procedure, a sealed message 2107 is generated for Mr. B.

[0313] 2007 in FIG. 21 (b) illustrates a sealed message addressed to Mr. B. In the following, the sealed message is illustrated in the drawing as in 2007. I decided to.

[0314] Next, a process of decrypting the encryption of the sealed message and a process of verifying the digital signature performed when the personal credit terminal receives the message from the service providing system will be described. Even in this case, the characters will be generalized and explained.

[0315] First, the decoding process will be described.

[0316] FIGS. 22 (a) and 22 (b) are a flow diagram showing a procedure for decoding a message sealed to Mr. B, and a conceptual explanatory diagram of the flow, respectively.

[0317] First, in step 2200, the CPU sends the message 2202 sealed to Mr. B to the part 2203 in which the private key is encrypted with Mr. B's public key and the part of the message encrypted with the private key. Divided into 2204, using an encryption processing processor, the part 2203 in which the private key is encrypted with Mr. B's public key is decrypted with Mr. B's private key, and the private key 2205 is taken out.

Next, in step 2201, the CPU uses a cryptographic processor to decrypt part 2204 of the message encrypted with the private key with the private key 2205.

[0319] The sealed message is decrypted by the above procedure.

[0320] Next, the digital signature verification process will be described.

[0321] FIGS. 23 (a) and 23 (b) are a flow diagram showing a procedure for verifying the digital signature of a message with a digital signature of Mr. A, the sender of the message, and a conceptual explanatory diagram of the flow, respectively. is there.

[0322] First, in step 2300, the CPU performs a hash function operation on the part of the message (Message '2303) in the digitally signed message 2206 to generate the message digest 2305.

[0323] Next, in step 2301, the CPU uses a cryptographic processor to decrypt the digitally signed portion 2304 in the digitally signed message 2206 with Mr. A's public key.

Next, in step 2302, the CPU compares the output 2305 of step 2300 with the output 2304 of step 2301, and if the contents match, it is determined that the verification has passed, and if they do not match, Determine that a verification error has occurred.

[0325] The digital signature verification process is performed by the above procedure.

Next, the internal configuration of the credit card payment terminal 300 will be described.

FIG. 24A is a block configuration diagram of the credit card payment terminal 300. This terminal 300 is a CPU (Central Processing Unit) 2400 that processes transmitted data and received data according to a program stored in ROM (Read Only Memory) 2401 and controls other components via bus 2429. RAM (Random Access Memory) 2402 that stores the data processed by CPU2400 and the data processed by CPU2400, hard disk 2403 that stores the actual data of the information specified by the management information of the data on RAM2402, and credit. EEPROM (Electric) that stores the terminal ID, telephone number, merchant ID, private key and public key of the payment terminal 300, and the service provider ID, telephone number, and public key of the service provider of the service providing system 102. Erasable Programable Read Only Memory) 2404, LCD controller 2405 that controls the operation of LCD302 according to the control of CPU2400 and displays the image set by CPU2400 on LCD302, and encryption that performs data encryption processing and decryption processing under the control of CPU2400. The processing processor 2406, the data codec 2407 that encodes the transmitted data and decodes the received data under the control of the CPU 2400, and the infrared module 301 are connected via the serial port 2409 with the serial cable 310 to connect the parallel data and serial. Detects the switch operation of the series-parallel conversion circuit 2460 circuit that performs bidirectional conversion with data and the mode switch 304, hook switch 305, function switch 306, ten-key switch 307, execution switch 308 or power switch 309 by the merchant. The key operation control unit 2411 that asserts the interrupt signal 2439, the voice processing unit 2413 that drives the speaker 2412 and the receiver of the handset 303 and amplifies the analog voice signal input from the microphone of the handset 303, and the digital of the analog voice signal 2444. A voice codec 2414 that encodes voice data and decodes digital voice data into an analog voice signal 2443, generates transmission data on a communication channel, and separates digital voice data and data communication data from received data. The channel codec 2415 that performs the above, the digital communication adapter 2416 that converts the digital signal 2448 to the data format of digital telephone communication, and the reverse conversion, the RS-232C interface 2417 that connects the RS-232C cable 313, and the key. Processing of interrupt signals input from operation control unit 2411, channel codec 2415 or RS-232C interface 2417, and interface for CPU 2400 to access internal registers of key operation control unit 2411, voice processing unit 2413 or channel codec 2415. Played the role ofIt is equipped with a control logic unit 2410.

[0328] The cryptographic processing processor 2406 has functions of encryption and decryption of the private key method and encryption and decryption of the public key method, and is set by the CPU 2400 with the encryption method and the key set by the CPU 2400. The encrypted data is encrypted or decrypted.

[0329] Further, the data codec 2407 performs the coding of the transmitted data and the decoding of the received data under the control of the CPU 2400, and the coding in this case includes the communication control information and the error correction information. , Means the process of generating the data that is actually transmitted, and the decoding is the process of performing error correction processing on the received data, removing excess communication control information, and the data that the sender originally intended to transmit. It means the process to generate. The data codec 2407 has a data coding and decoding function in digital telephone data communication and a data coding and decoding function in infrared communication, and the data set in the CPU 2400 can be converted to the CPU 2400. Performs the set coding processing and decoding processing.

[0330] Further, as shown in FIG. 24 (b), the infrared module 301 connected to the series-parallel conversion circuit 2408 via the serial cable 310 and the serial port 2409 is a serial port that is an interface with the credit payment terminal 300. Modulation / demodulation circuit 2456 that actually modulates the 2455 and the digital signal 2458 input from the series-parallel conversion circuit 2408 into the signal 2460 transmitted as infrared rays, or demolishes the received analog signal 2461 to the serial digital signal 2459. It also includes an infrared light receiving / receiving unit 2457 that converts the signal 2460 modulated by the modulation / demodulation circuit 2456 into infrared light and emits light, or converts the received infrared light into an analog signal 2461.

[0331] The infrared module 301 transmits and receives infrared rays during infrared communication. The infrared module 301 converts the transmission data set by the CPU 2400 into infrared rays and transmits the infrared rays, and also converts the received infrared rays into the received data.

[0332] Further, the key operation control unit 2411 asserts the interrupt signal 2439 when the merchant presses any of the mode switch 304, the hook switch 305, the function switch 306, the numeric keypad switch 307, the execution switch 308, or the power switch 209. .. This interrupt signal 2439 prompts the CPU 2400 to perform processing corresponding to the switch operation. Further, as shown in FIG. 27 (a), the key operation control unit 2411 includes a key operation control register (KEYCTL) 2710 for setting the enable / disable of each switch. The CPU2400 accesses this key operation control register (KEYCTL) 2710 to enable / disable each switch.

[0333] As shown in FIG. 27 (a), the voice processing unit 2413 includes a voice processing unit control register (SCTL) 2709 that controls the voice processing operation. The CPU 2400 accesses the voice processing unit control register (SCTL) 2709 to control the operation of the voice processing unit 2413. For example, when a digital telephone incoming call request is received, the CPU 2400 accesses the voice processing unit control register (SCTL) 2709 and sets to output the digital telephone ringtone. By doing so, the voice processing unit 2413 drives the speaker 2412, and the ringtone of the digital telephone is output.

Further, the audio codec 2414 encodes the analog audio signal 2444 input from the audio processing unit 2413 into digital audio data, and decodes the digital audio data input from the channel codec 2415 into an analog audio signal 2443. To do. The analog audio signal 2443 is supplied to the audio processing unit 2413, and the audio processing unit 2413 amplifies the analog audio signal 2443 and drives the receiver of the receiver 303, so that audio is output from the receiver. On the other hand, the digital voice data generated by the coding is supplied to the channel codec 2415 and converted into transmission data on the communication channel.

[0335] Two types of data are input to the channel codec 2415 as data to be transmitted. One is digital voice data input from the voice codec 2414, and the other is data communication data input from the CPU via the control logic unit 2410.

[0336] The channel codec 2415 adds identification information between digital audio data and data communication data as header information to each data, and provides a digital signal 2448 in which digital audio data and data communication data are multiplexed. Supply to the digital communication adapter 2416.

On the contrary, the channel codec 2415 first collates the terminal ID with the digital signal 2448 input from the digital communication adapter 2416, and then, from the data header information, digital audio data and data communication data. And are supplied to the voice codec 2412 and the control logic unit 2410, respectively. Further, the channel codec 2415 asserts the interrupt signal 2449 when receiving a digital telephone call and when receiving data communication data. The interrupt signal 2449 prompts the CPU 2400 to process an incoming digital call and to process data communication data.

[0338] In order to perform such an operation, the channel codec 2415 has an ID register (ID) 2703 for storing the terminal ID and a channel codec control register for controlling the operation of the channel coden 2415, as shown in FIG. 27 (a). (CHCTL) 2704, audio transmission buffer 2705 that stores digital audio data input from audio codec 2414, audio reception buffer 2706 that stores digital audio data extracted from received data, and input from control logic unit 2410. It includes a data transmission buffer 2707 for storing the data communication data to be received, and a data reception buffer 2708 for storing the data communication data extracted from the received data.

[0339] The digital communication adapter 2416 encodes the digital signal 2448 into the format of digital telephone communication and outputs it to the digital telephone communication line 110. Conversely, the digital communication adapter 2416 decodes the signal received from the digital telephone communication line 110 and supplies the digital signal 2448 to the channel codec 2415.

[0340] The RS-232C interface 2417 is an interface circuit for connecting the RS-232C cable 313, and the credit card payment terminal communicates with the cache register 311 via the RS-232C interface 2417. The RS-232C interface 2417 asserts the interrupt signal 2452 when it receives data from the cache register 311. The interrupt signal 2452 prompts the CPU 2400 to process data communication with the cache register 311 via the RS-232C interface 2417.

Further, as shown in FIG. 27A, the control logic unit 2410 has three internal clock counters (CLOCKC) 2700, update time register (UPTIME) 2701, and interrupt register (INT) 2702. Built-in register.

The clock counter is a counter that counts the current time, and the update time register is a process in which the credit settlement terminal 300 communicates with the service providing system to update the data on the RAM 2402 and the hard disk 2403 (data update process). The register that stores the time to perform the operation, the interrupt register, is a register that indicates the cause of the interrupt to the CPU 2400.

When any of the interrupt signals 2439, 2449, and 2452 is asserted, the control logic unit 2410 sets the interrupt factor in the interrupt register (INT) 2702 and asserts the interrupt signal 2418. , Prompts the CPU for interrupt processing. The CPU2400 reads the interrupt register in interrupt processing and performs processing according to the interrupt factor.

Each bit field in the interrupt register (INT) is meant as shown in FIG. 27 (b).

[0345] Bit 31 indicates the state of the power switch, and when the value is 0, it indicates that it is in the power-off state, and when the value is 1, it indicates that it is in the power-on state.

[0346] Bit 30 indicates the state of digital telephone communication, and when the value is 0, it indicates that digital telephone communication is not being performed, and when the value is 1, it indicates that digital telephone communication is being performed. Indicates that there is.

[0347] Bit 28 indicates that an incoming call interrupt has occurred, and when the value is 1, it indicates that a digital call has been received. This bitfield is set to 1 when a digital call arrives and the interrupt signal 2449 is asserted.

[0348] Bit 27 indicates that a data reception interrupt has occurred, and when the value is 1, it indicates that data reception data has been received. This bit field is set to 1 when data communication data is received and the interrupt signal 2449 is asserted in digital telephone communication.

[0349] Bit 26 indicates the occurrence of an update interrupt that prompts the data update process, and when the value is 1, it indicates that the update interrupt has occurred. This bit field is set to 1 when the value of the clock counter matches the value of the update time register.

[0350] Bit 25 indicates the occurrence of an external IF interrupt that prompts the processing of data communication with the cache register 311. When the value is 1, it indicates that an external IF interrupt has occurred. This bit field is set to 1 when the interrupt signal 2452 input from RS-232C interface 2417 is asserted.

[0351] Bit 24 indicates that a key interrupt has occurred due to a switch operation, and when the value is 1, it indicates that a key interrupt has occurred.

[0352] Bits 0 to 9 correspond to switches 0 to 9 of the ten-key switch, respectively, and bits 10 and 11 correspond to the "*" and "#" switches of the ten-key switch, respectively. , Bits 12 to 15 correspond to the function switch "F1" to "F4", respectively, and bits 16 to 18 correspond to the power switch, execution switch, mode switch, and call switch, respectively. Bit 20 corresponds to a hook switch, and when the value of the bit is 1, it indicates that the switch corresponding to that bit has been pressed.

Next, the data stored in the RAM 2402 will be described.

[0354] FIG. 25 is a schematic diagram of a RAM map of the data stored in the RAM 2402.

[0355] The RAM 2402 has five areas: a basic program area 2500, a service data area 2501, a merchant area 2502, a work area 2503, and a temporary area 2504. The basic program area 2500 stores upgraded modules of programs stored in ROM 2401 and patch programs. The merchant area 2502 is an area that can be freely used by the merchant, the work 2503 area is a work area that the CPU 100 uses when executing a program, and the temporary area 2504 is a temporary area that receives information received by the credit card payment terminal. This is the storage area.

[0356] The service data area 2501 is an area for storing ID information of a personal remote credit payment service, handling credit card information, and history information, and the data in this area is managed by the service providing system.

[0357] The service data area 2501 further includes five areas: data management information 2505, merchant setting information 2506, telephone information 2507, credit card list 2508, and sales history list 2509.

[0358] The data management information 2505 is an area for storing the management information of the information stored in the service data area 2501, and the merchant setting information 2506 is an area for storing the merchant setting information related to the personal remote credit payment service. , Phone information 2507 is an area for storing information related to digital phones, Credit card list 2508 is an area for storing list information of credit cards that can be handled by merchants, Sales history list 2509 is a personal remote credit This is an area for storing history information of sales in the payment service.

Next, the information stored in the service data area 2501 will be described in detail.

[0360] FIG. 26 is a schematic diagram showing in detail the relationship of the information stored in the service data area 2501.

[0361] Data management information 2505 is 7 of update date and time 2600, next update date and time 2601, terminal status 2602, merchant setting information address 2603, telephone information address 2604, credit card list address 2605, and sales history list address 2606. It consists of two pieces of information.

[0362] The update date and time 2600 indicates the date and time when the service providing system 102 last updated the data in the service data area 2501, and the next update date and time 2601 indicates the update of the data in the service data area 2501 by the next service providing system 102. Indicates the scheduled date and time of. The credit card payment terminal automatically starts the data update process at the set time of the next update date and time 2601. The data update process is a process of having the service providing system 102 update the data in the service data area 2501. The data update process will be described in detail later.

[0363] Terminal status 2602 indicates the status of the credit settlement terminal, and merchant setting information address 2603, telephone information address 2604, credit card list address 2605, and sales history list address 2606 are merchant setting information 2506, respectively. Indicates the first address of the area where telephone information 2507, credit card list 2508, and usage history list 2509 are stored.

[0364] The telephone information 2507 is further composed of three pieces of information: a calling telephone number 2607, a telephone directory address 2608, and a shortened dial setting file address 2609. The calling phone number 2607 indicates the phone number of the last call made by the merchant, and this information is used when resending the digital radiotelephone. The telephone directory address 2608 and the abbreviated dial setting file address 2609 indicate addresses on the hard disk 2403 in which the telephone directory information and the abbreviated dial setting file are stored, respectively.

[0365] The credit card list 2508 stores list information of credit cards that can be handled by the merchant. In the credit card list 2508, two pieces of information, a credit card name 2610 (2612, 2614) and a service code list address 2611 (2613, 2615), are stored for one credit card. The credit card name 2610 (2612,2614) indicates the name of the credit card that the merchant can handle, and the service code list address 2611 (2613,2615) is one of the services provided by that credit card. Indicates the address on hard disk 2403 that contains the service code list that indicates the types of services that can be handled by.

[0366] The sales history list 2509 is an area for storing sales history information in the personal remote credit payment service. In the sales history list 2509, for the sale of one personal remote credit payment service, transaction number 2616 (2620), service code 2617 (2621), sales time 2618 (2622), sales information address 2619 (2623) Contains four pieces of information.

[0367] The transaction number 2616 (2620) is a number uniquely indicating a transaction with the user, and the number issued by the credit card settlement terminal when generating the payment offer response 609, the service code 2617 (2621) is a number that the user can use. The code number indicating the type of credit card service used, the sales time 2618 (2622) is the time of sale by the personal remote credit payment service, and the sales information address 2619 (2623) is the address where the payment completion notification is stored. Shown.

[0368] The sales information address 2619 (2623) stores a local address indicating an address on the hard disk 2403 or a remote address indicating an address on the merchant information server 402 of the service providing system 102. When the remote address is stored in the sales information address 2619 (2623), when the merchant accesses the sales history information, the credit settlement terminal downloads the sales information from the service providing system to the temporary area and displays the LCD. Display on.

The address stored in the sales information address 2619 (2623) is determined by the service providing system. During the data update process, the sales time of each sales information is compared, and a local address is assigned to the sales information with the latest sales time. However, if there is enough capacity on the hard disk 2403, all sales information addresses may be local addresses.

Next, the processing performed by the CPU 2400 will be described.

[0371] FIG. 28 is a conceptual diagram of a flow of processing performed by the CPU 2400.

As shown in FIG. 28, CPU processing can be roughly divided into 10 types of processes and interrupt processing 2801.

[0373] The 10 types of processes are power-on process, telephone process, credit payment process, customer service call process, inquiry call process, data update process, remote access process, session establishment process, external IF communication process, and power-off. It is a process, and these 10 types of processes are executed in the main loop 2800. Each process has a word field on RAM2402 that indicates the status (status) of the process, and CPU2400 executes each process according to the value of this process status.

[0374] The power-on process is a process of performing initial operation processing when the merchant turns on the power switch, the telephone process is a process of performing processing in digital telephone mode, and the credit settlement process is processing in credit settlement mode. Process to be performed, customer service call process is process to process "customer service call", inquiry call process is process to process "inquiry call", data update process is process to process data update, remote access process Is a process that accesses data on the merchant information server of the service providing system, a session establishment process is a process that establishes a communication session with the service providing system, and an external IF communication process is a cache register 311. The power-off process, which is the process of performing data communication, is a process of terminating when the merchant turns off the power switch.

[0375] In FIG. 28, when the credit payment terminal is reset, the process proceeds to step 2802, and the CPU 2400 sets the power-on process to active. Next, in step 2803, it is checked whether the power-on process is active, and if it is inactive, the process proceeds to step 2805, and if it is active, the process proceeds to step 2804, and the power-on process is executed for a certain period of time. Then proceed to step 2805.

[0376] In step 2805, it is checked whether or not the telephone process is active, and if it is inactive, the process proceeds to step 2807, and if it is active, the process proceeds to step 2806, and the telephone process is executed for a certain period of time. Then proceed to step 2807.

[0377] In step 2807, it is checked whether or not the credit settlement process is active, and if it is inactive, the process proceeds to step 2809, and if it is active, the process proceeds to step 2808, and the credit settlement process is carried out for a certain period of time. Execute and proceed to step 2809.

[0378] In step 2809, it is checked whether the customer service call process is active, and if it is inactive, the process proceeds to step 2811, and if it is active, the process proceeds to step 2810, and the customer service call process is performed. Execute for a certain period of time and proceed to step 2811.

[0379] In step 2811, it is checked whether or not the inquiry call process is active, and if it is inactive, the process proceeds to step 2813, and if it is active, the process proceeds to step 2812, and the inquiry call process is performed for a certain period of time. Execute and proceed to step 2813. In step 2813, it is checked whether the data update process is active, and if it is inactive, the process proceeds to step 2815, and if it is active, the process proceeds to step 2814, and the data update process is executed for a certain period of time. , Proceed to step 2815.

[0380] In step 2815, it is checked whether or not the remote access process is active, and if it is inactive, the process proceeds to step 2817, and if it is active, the process proceeds to step 2816, and the remote access process is performed for a certain period of time. Execute and proceed to step 2817. In step 2817, it is checked whether the session establishment process is active, and if it is inactive, the process proceeds to step 2819, and if it is active, the process proceeds to step 2818, and the session establishment process is executed for a certain period of time. , Proceed to step 2819.

[0381] In step 2819, it is checked whether or not the external IF communication process is active, and if it is inactive, the process proceeds to step 2821, and if it is active, the process proceeds to step 2820, and the external IF communication process is started. Execute for a certain period of time and proceed to step 2821.

[0382] In step 2821, it is checked whether or not the power-off process is active, and if it is active, the process proceeds to step 2822, the power-off process is executed, and if it is inactive, the process returns to step 2803.

[0383] Further, when the interrupt signal 2418 is asserted, the CPU 2400 executes the interrupt processing 2801 and returns to the processing of the original main loop 2800.

[0384] In the interrupt process 2801, first, the CPU 2400 reads the interrupt register (INT) 2702 in step 2823 and copies it to the word interrupt on the work area 2503 of the RAM 1502. At this time, the interrupt register (INT) 2702 read by the CPU 2400 is echo-reset.

Next, in step 2824, it is checked from the value of bit 28 of interrupt whether or not it is an incoming call interrupt, and if it is not an incoming call interrupt (interrupt (bit28) = 0), the process proceeds to step 2826 and the incoming call interrupt is performed. In the case (interrupt (bit28) = 1), the process proceeds to step 2825, the process status of the telephone process is set to active, and the process proceeds to step 2826.

[0386] In step 2826, it is checked from the value of bit 26 of interrupt whether or not it is an update interrupt, and if it is not an update interrupt (interrupt (bit26) = 0), the process proceeds to step 2828, and if it is an update interrupt (interrupt). (bit26) = 1) proceeds to step 2827, sets the process status of the data update process to active, and proceeds to step 2828.

[0387] In step 2828, it is checked from the value of bit 25 of interrupt whether or not it is an external IF interrupt, and if it is not an external IF interrupt (interrupt (bit25) = 0), the process proceeds to step 2830 and the external IF interrupt is performed. In the case (interrupt (bit25) = 1), the process proceeds to step 2829, the process status of the external IF communication process is set to active, and the process proceeds to step 2830.

[0388] In step 2830, it is checked from the value of bit 24 of interrupt whether or not it is a key interrupt, and if it is not a key interrupt (interrupt (bit24) = 0), the interrupt process is terminated and the original main loop is used. Returning to the process, in the case of key interrupt (interrupt (bit24) = 1), the process proceeds to step 2831.

[0389] In step 2831, the value of the "power supply" bit (bit16) of interrupt is checked, and if it is 0, the interrupt processing is terminated and the process returns to the original main loop processing. If it is 1, the power supply is returned. It is determined that the switch has been operated, and the process proceeds to step 2832.

[0390] In step 2832, the value of the power display bit (bit31) of interrupt is examined, and if it is 0, it is determined that the power-off operation has been performed, and the process proceeds to step 2834. It is determined that the power-on operation has been performed, and the process proceeds to step 2833.

[0391] In step 2833, the process status of the power-on process is set to active, the interrupt process is terminated, and the process returns to the original main loop process.

[0392] In step 2834, the process status of the power-off process is set to active, the interrupt process is terminated, and the process returns to the original main loop process.

[0393] In the interrupt process 2801, the process whose process status becomes "active" returns to the main loop and is executed in the main loop.

Next, the information stored in the user information server 402 of the service providing system 102 will be described.

[0395] FIG. 29 is a schematic diagram showing information stored in the user information server 402 for one user.

[0396] In the user information server 402, for one user, user data management information 2900, personal information 2901, photo data 2902, terminal property 2903, user setting information 2904, access control information 2905, terminal data 2906, telephone. Information 2907, credit card list 2908, and usage history list 2909 are stored. The user data management information 2900 is management information of information stored in the user information server 402 for one user.

[0397] Personal information 2901 is information about the individual user such as the user's age, date of birth, occupation, account number, contract details, etc., and a part of this information corresponds to the personal information 1606 of the personal credit terminal 100. are doing.

[0398] The photo data 2902 is the data of the user's face photo, and the terminal property 2903 is the model number, serial number, RAM capacity, stored program version, etc. of the personal credit terminal 100 of the personal credit terminal 100. Attribute information.

[0399] The user setting information 2904 is the user setting information related to the personal remote credit payment service, and is the information corresponding to the user setting information 1608 of the personal credit terminal 100.

[0400] Access control information 2905 is user setting information regarding access control in a customer service call, terminal data 2906 is RAM data of a personal credit terminal 100, and telephone information 2907 is information related to a digital wireless telephone. This information corresponds to the telephone information 1609 of the personal credit terminal 100.

[0401] The credit card list 2908 is the list information of the credit card registered by the user, and the usage history list 2909 is the usage history information of the personal remote credit payment service.

[0402] User data management information 2900 includes user name 2910, user ID 2911, user status 2912, personal information address 2913, photo data address 2914, user public key 2915, terminal property address 2916, user setting information address 2917, It consists of 15 pieces of information: access control information address 2918, update date and time 2919, next update date and time 2920, terminal data address 2921, telephone information address 2922, credit card list address 2923, and usage history list address 2924.

[0403] The user status 2912 indicates the status of the personal credit terminal 100, and is information corresponding to the terminal status 1702 of the personal credit terminal 100.

[0404] The update date and time 2919 indicates the date and time when the data in the service data area 1601 of the personal credit terminal 100 was last updated, and the next update date and time 2920 indicates the scheduled date and time when the data in the next service data area 1601 is updated. , Corresponds to the update date and time 1700 and the next update date and time 1701 of the personal credit terminal 100, respectively.

[0405] Personal information address 2913, photo data address 2914, terminal property address 2916, user setting information address 2917, access control information address 2918, terminal data address 2921, telephone information address 2922, credit card list address 2923, And usage history list address 2924 are personal information 2901, photo data 2902, terminal property 2903, user setting information 2904, access control information 2905, terminal data 2906, telephone information 2907, credit card list 2908, and usage, respectively. Indicates the address on the user information server 402 where the history list 2909 is stored.

[0406] The terminal data 2906 is data on the RAM 1502 of the personal credit terminal 100 at the time of the previous update processing, and is used as data comparison and backup data at the time of the next update processing.

[0407] The credit card list 2908 and the usage history list 2909 are also information corresponding to the credit card list 1610 and the usage history list 1611 of the personal credit terminal 100, respectively. However, the image data address 2944, the object data address 2945, and the usage information address 2954 all indicate addresses on the user information server 402.

Next, the information stored in the merchant information server 403 of the service providing system 102 will be described.

[0409] FIG. 30 is a schematic diagram showing information stored in the merchant information server 403 for one merchant.

[0410] In the merchant information server 403, for one merchant, merchant data management information 3000, merchant information 3001, terminal property 3002, merchant setting information 3003, terminal data 3004, telephone information 3005, credit card list 3006, And 8 types of information of sales history list 3007 are stored.

[0411] The merchant data management information 3000 is management information of information stored in the merchant information server 403 with respect to one merchant.

[0412] Merchant information 3001 is information about the merchant such as the merchant's address, account number, contract details, etc., and terminal property 3002 is the model number, serial number, RAM capacity, hard disk capacity, and hard disk capacity of the credit card payment terminal 300. It is the attribute information of the credit card payment terminal 300 such as the version of the program.

[0413] The merchant setting information 3003 is the merchant setting information related to the personal remote credit payment service, and is the information corresponding to the merchant setting information 2506 of the credit payment terminal 300.

[0414] The terminal data 3004 is the data of the RAM 2402 of the credit settlement terminal 300, the data of the hard disk 2403, and the telephone information 3005 is information related to the digital telephone, and is the information corresponding to the telephone information 2507 of the credit settlement terminal 300.

[0415] The credit card list 3008 is the list information of credit cards that can be handled by the merchant, and the sales history list 3007 is the sales history information in the personal remote credit settlement service.

[0416] Merchant data management information 3000 includes merchant name 3008, merchant ID 3009, merchant status 3010, merchant information address 3011, merchant public key 3012, terminal property address 3013, merchant setting information address 3014, update date and time 3015, next time. It consists of 13 pieces of information: update date and time 3016, terminal data address 3017, telephone information address 3018, credit card list address 3019, and sales history list address 3020.

[0417] The merchant status 3010 indicates the status of the credit card payment terminal 300, and is information corresponding to the terminal status 2602 of the credit card payment terminal 300.

[0418] The update date and time 3015 indicates the date and time when the data of the service data area 2501 of the credit card payment terminal 300 was last updated, and the next update date and time 3016 indicates the scheduled date and time when the data of the next service data area 2501 is updated. It corresponds to the update date and time 2600 of the credit card payment terminal 300 and the next update date and time 2601.

[0419] Merchant information address 3011, terminal property address 3013, merchant setting information address 3014, terminal data address 3017, telephone information address 3018, credit card list address 3019, and sales history list address 3020, respectively. Indicates the address on the merchant information server 403 that stores the merchant information 3001, terminal property 3002, merchant setting information 3003, terminal data 3004, telephone information 3005, credit card list 3006, and sales history list 3007.

[0420] The terminal data 3004 is data between the RAM 2402 of the credit card payment terminal 300 and the hard disk 2403 when the update process was performed last time, and is used as data comparison and backup data in the next update process.

[0421] The credit card list 3008 and the sales history list 3007 are also information corresponding to the credit card list 2508 and the sales history list 2509 of the credit payment terminal 300, respectively. However, all sales information addresses 3043 indicate addresses on the merchant information server 403.

Next, the information stored in the payment processing institution information server 404 of the service providing system 102 will be described.

[0423] FIG. 31 is a schematic diagram showing information stored in the settlement processing institution information server 404 for one settlement processing institution.

[0424] In the payment processing institution information server 404, four types of information, payment processing institution data management information 3100, payment processing institution information 3101, credit card list 3102, and sales history list 3103, are provided for one payment processing institution. Is stored.

[0425] The settlement processing institution data management information 3100 is information management information stored in the settlement processing institution information server 404 with respect to one settlement processing institution. The payment processing institution information 3101 is information about the payment processing institution such as the address, account number, and contract details of the payment processing institution, and the credit card list 3102 is the list information of credit cards that can be handled by the payment processing institution, and the payment history. Listing 3103 is the payment history information for the personal remote credit card payment service.

[0426] Settlement processing institution data management information 3100 includes settlement processing institution name 3104, settlement processing institution ID 3105, settlement processing institution status 3106, settlement processing institution information address 3107, settlement processing institution public key 3108, credit card list address 3109. , And the payment history list address 3110 7 pieces of information.

[0427] The payment processing institution status 3106 indicates the payment processing service status of the payment system 103, and the payment processing institution information address 3107, the credit card list address 3109, and the payment history list address 3110 are the payment processing institutions, respectively. Indicates the address on the payment processing institution information server 404 that stores information 3101, credit card list 3102, and payment history list 3103.

[0428] Credit card list 3102 shows list information of credit cards that can be handled by the payment processing institution. In the credit card list 3102, two pieces of information, a credit card name 3111 (3113,3115) and a service code list address 3112 (3114,3116), are stored for one credit card.

[0429] The credit card name 3111 (3113,3115) indicates the name of the credit card that the payment processing institution can handle, and the service code list address 3112 (3114,3116) is provided by that credit card. Among the services, the address on the payment processing institution information server 404 in which the service code list indicating the types of services that the payment processing institution can handle is stored is shown.

[0430] The payment history list 3103 is an area for storing the history information of the payment in the personal remote credit payment service.

[0431] In the payment history list 3103, for the payment of one personal remote credit payment service, the payment number 3117 (3121), the service code 3118 (3122), the payment time 3119 (3123), and the payment information address 3120 ( 3124) 4 information is stored.

[0432] The payment number 3117 (3121) is a number issued by the payment system when generating a payment completion notification 620 that uniquely indicates the payment process, and the service code 3118 (3122) is the type of credit card service used by the user. The code number indicating, the payment time 3119 (3123) is the time when the payment was made by the personal remote credit payment service, and the payment information address 3120 (3124) is the payment processing institution that stores the payment completion notification issued by the payment system 103. Indicates the address on the information server 404.

Next, the information stored in the service director information server 401 of the service providing system 102 will be described.

[0434] FIG. 32 is a schematic diagram showing information stored in the service director information server 401.

[0435] The service director information server 401 stores five types of information: a user list 3200, a merchant list 3201, a payment processing institution list 3202, a service provision history list 3203, and a payment processing institution table 3204.

[0436] User list 3200 is a list of attribute information of all users who have a contract with a service provider, and merchant list 3201 is a list of attribute information of all merchants who have a contract with a service provider, and a payment processing institution. List 3202 is a list of attribute information of all payment processing institutions that have contracts with service providers, and service provision history list 3203 is a list of history information of services provided by the personal remote credit payment service. The payment processing institution table 3204 is table information in which the optimum payment processing institution is associated with the request of the personal remote credit payment service from the user and the merchant.

[0437] There are four types of user list 3200 for one user: user name 3205 (3209), user ID 3206 (3210), user telephone number 3207 (3211), and service list address 3208 (3212). Information is stored.

Service list address 3208 (3212) indicates an address on the service director information server 401 that stores a list of service codes available to the user.

In the Merchant List 3201, for one Merchant, the Merchant Name 3213 (3218), Merchant ID 3214 (3219), Merchant Phone Number 3215 (3220), Service List Address 3216 (3221), Customer Table Five types of information at address 3217 (3222) are stored.

The service list address 3216 (3221) indicates an address on the service director information server 401 that stores a list of service codes that can be handled by the merchant.

[0441] Customer table address 3217 (3222) indicates an address on the service director information server 401 that stores table information indicating the correspondence between the customer number and the user ID.

[0442] In the settlement processing institution list 3202, for one settlement processing institution, the settlement processing institution name 3223 (3227), the settlement processing institution ID 3224 (3228), the settlement processing institution communication ID 3225 (3229), the service list, etc. Four types of information at address 3226 (3230) are stored.

[0443] The payment processing institution communication ID 3225 (3229) indicates the ID of the payment system 103 when the service providing system 102 communicates with the payment system 103 via the digital communication line 111, and the service list address 3226 (3230). ) Indicates the address on the service director information server 401 that stores the list of service codes that can be handled by the payment processing institution.

[0444] In the service provision history list 3203, for one service provision of the personal remote credit payment service, the service provision number 3231 (3235), the service code 3232 (3236), the service provision time 3233 (3237), Four pieces of information at the service provision information address 3234 (3238) are stored.

[0445] The service provision number 3231 (3235) is a number uniquely indicating the processing in the service provision system 102 in one service provision, and the service code 3232 (3236) is a code indicating the type of credit card service used by the user. The number, service provision time 3233 (3237) is the time when the service of the personal remote credit payment service was provided, and the service provision information address 3234 (3238) is the history information of the processing in the service provision system 102 in one service provision. Indicates the stored service director information server 401 address.

[0446] Next, the download process performed when the data at the remote address is accessed in the personal credit terminal 100 or the credit payment terminal 300 will be described. Hereinafter, this process will be referred to as a remote access process.

[0447] FIG. 33 (a) shows the procedure of the remote access process, and FIGS. 34 (a) and 34 (b) show the contents of the messages to be exchanged. If the accessed data is at a remote address, the personal credit terminal 100 (credit payment terminal 300) generates a message requesting data from the service providing system 102, a remote access request 3300, and sends it to the service providing system 102. To do.

As shown in FIG. 34 (a), the remote access request 3300 includes header information indicating that the message is a remote access request 3300, a remote access request header 3400, a data address 3401 indicating a remote address, and a user. The data consisting of the ID (merchant ID) 3402 and the issue date and time 3403 indicating the date and time when this remote access request 3300 was issued is digitally signed by the user (merchant) 3404 and sealed to the service provider. ..

[0449] The service providing system 102 receives the remote access request 3300, decrypts the code, checks the digital signature, and sends the requested data to the personal credit terminal 100 (credit payment terminal 300), a remote message. Generates access data 3301 and sends it to the personal credit terminal 100 (credit payment terminal 300).

As shown in FIG. 34 (b), the remote access data 3301 includes header information indicating that the message is remote access data 3301, a remote access data header 3408, requested data 3409, and a service provider. The data consisting of ID 3410 and the issue date and time 3411 indicating the issue date and time of this remote access data 3301 is digitally signed by the service provider and sealed to the user (merchant).

[0451] The personal credit terminal 100 (credit payment terminal 300) receives the remote access data 3301, decrypts the encryption, checks the digital signature, stores it in the temporary area, and accesses the data.

[0452] Next, the data update process performed by the personal credit terminal 100 and the credit payment terminal 300 in the data update process will be described.

[0453] FIG. 33 (b) shows the procedure of the data update process, and FIGS. 34 (c) to 34 (f) and 35 (a) show the contents of the messages to be exchanged.

[0454] In the data update process, the personal credit terminal 100 (credit payment terminal 300) first generates and transmits a message requesting data update processing and a data update request 3302 to the service providing system 102.

As shown in FIG. 34 (c), the data update request 3302 includes header information indicating that the message is a data update request 3302, a data update request header 3416, a user ID (merchant ID) 3417, and the like. The data consisting of the issue date and time 3418, which indicates the date and time when the data update request 3302 was issued, is digitally signed by the user (merchant) and sealed to the service provider.

[0456] The service providing system 102 receives the data update request 3302, decrypts the code, checks the digital signature, and generates a data update request response 3303, a message indicating that the request is ready. Send to personal credit terminal 100 (credit payment terminal 300).

As shown in FIG. 34 (d), the data update request response 3303 includes header information indicating that the message is the data update request response 3303, a data update request response header 3423, a service provider ID 3424, and the like. The data consisting of the issue date and time 3425, which indicates the date and time when the data update request response 3303 was issued, is digitally signed by the service provider and sealed to the user (merchant).

[0458] The personal credit terminal 100 (credit payment terminal 300) receives the data update request response 3303, decrypts the code, checks the digital signature, and RAM1502 (in the case of the credit payment terminal 300, RAM2402 and hard disk 2403). ) Data is uploaded to the service providing system 102. A message and upload data 3304 are generated and sent to the service providing system.

As shown in FIG. 34 (e), the upload data 3304 includes header information indicating that the message is the upload data 3304, the upload data header 3430, and RAM1502 (in the case of the credit payment terminal 300, RAM2402 and the hard disk). The digital signature of the user (merchant) is applied to the data consisting of the compressed data of 2403), the terminal data 3431, the user ID (merchant ID) 3432, and the issue date and time 3433 indicating the date and time when the upload data 3304 was issued. It is done and sealed to the service provider.

[0460] The service providing system 102 receives the uploaded data 3304, decrypts the code, and checks the digital signature. Then, the compressed terminal data 3431 is decompressed and collated with the terminal data 2906 (terminal data 3004) on the user information server 402 (merchant information server 403).

Then, a new terminal data 2906 (terminal data 3004) is generated, a message for updating the data of the personal credit terminal 100 (credit payment terminal 300), and update data 3305 are generated to generate the personal credit terminal 100 (terminal data 3004). Send to the credit payment terminal 300).

As shown in FIG. 34 (f), the update data 3305 includes header information indicating that the message is update data 3305, update data header 3438, compressed data of new terminal data, terminal data 3439, and the like. The data consisting of the service provider ID 3440 and the issue date and time 3441 indicating the date and time when this update data 3305 was issued is digitally signed by the service provider and sealed to the user (merchant).

[0463] The personal credit terminal 100 (credit payment terminal 300) receives the update data 3305, decrypts the code, checks the digital signature, decompresses the compressed terminal data 3439, and RAM1502 (credit payment terminal). In the case of 300, update the data of RAM2402 and hard disk 2403).

[0464] In the generation of new terminal data, the service providing system 102 compares the access times of the respective credit cards with respect to the personal credit terminal 100 when the capacity of the physical data area 1612 is insufficient, and the access times. Assigns a local address to the object data address of a recent credit card, compares the usage time of each usage information, assigns a local address to the usage information address of the latest usage information, and also credit payment terminal 300 On the other hand, if the capacity of the hard disk 2403 is insufficient, the usage times of each sales information are compared, and a local address is assigned to the sales information address of the sales information whose usage time is the latest.

[0465] Further, when the service providing system 102 collates the uploaded data with the terminal data, if an unauthorized alteration of the data is found, the personal credit terminal 100 (credit) is used instead of the update data 3305. A message for stopping the function of the payment terminal 300) and a function stop command 3305'are generated and sent to the personal credit terminal 100 (credit payment terminal 300).

As shown in FIG. 35 (a), the function stop command 3305'has header information indicating that the message is the function stop command 3305', the function stop command header 3500, the service provider ID 3501, and this function. The data consisting of the issue date and time 3502 indicating the date and time when the stop instruction 3305'was issued is digitally signed by the service provider and sealed to the user (merchant).

[0467] In this case, the personal credit terminal 100 (credit payment terminal 300) that has received the function stop command 3305'decrypts the code, checks the digital signature, and sets the terminal status 1702 (terminal status 2602) to ". Change to "Unusable" and it becomes unusable.

Further, the backup process performed by the personal credit terminal 100 in the backup process is performed in the same procedure as the data update process. However, after receiving the update data 3305 and updating the data in RAM1502, change the terminal status 1702 to "writable" and add new data to RAM until the battery capacity is sufficient. Prohibit input.

[0469] Next, in the process of "payment", the details of the contents of the data exchanged between the devices will be described.

[0470] FIGS. 36 (a) to (f), 37 (a) to (c), 38 (a), and (b) show the contents of the messages to be exchanged in the process of "payment". ..

[0471] First, when the user performs the payment operation 607, the personal credit terminal 100 generates a payment offer 608 and transmits it to the credit payment terminal 300 by infrared communication.

As shown in FIG. 36 (a), the payment offer 608 includes header information indicating that the message is a payment offer 608, a payment offer header 3600, a service code 3601, a service provider ID 3602, and a merchant. A request number 3603 arbitrarily generated as a unique number to indicate the transaction, a payment amount 3604 entered by the user, a payment option code 3605 indicating the payment option entered by the user, and an expiration date 3606 of this payment offer 608. The data consisting of the issue date and time 3607, which indicates the date and time when the payment offer 608 was issued, is digitally signed by the user. The credit card payment terminal 300 receives the payment offer 608, matches the payment amount 3404 with the billed amount, matches whether the payment option 3405 is an available option, and sends the payment offer response 609 via infrared communication. It sends to the personal credit terminal 100, generates a credit inquiry request 610, and sends it to the service providing system 102 by digital telephone communication.

As shown in FIG. 36 (b), the payment offer response 609 includes header information indicating that the message is a payment offer response 609, a payment offer response header 3608, and a personal credit terminal 100 paying offer response 609. The response message 3609 displayed on the LCD 203 when the payment is received, the transaction number 3610 arbitrarily generated as a number uniquely indicating the transaction with the user, the billing amount 3611, and the expiration date 3612 of this payment offer response 609. The data consisting of the merchant ID 3613 and the issue date and time 3614, which indicates the date and time when the payment offer response 609 was issued, is digitally signed by the merchant. Response message 3609 is a text message set by the merchant's options and may not be set.

As shown in FIG. 36 (c), the authorization request 610 includes header information indicating that the message is an authorization request 610, an authorization request header 3615, a payment offer 608, and a payment offer response 609. , The data consisting of the person in charge name 3616, the merchant ID 3617, and the issue date and time 3618 indicating the date and time when this authorization request 610 was issued is digitally signed by the merchant and sealed to the service provider. The person in charge name 3616 is the information to be set in the merchant's option, and may not be set.

[0475] The personal credit terminal 100 receives the payment offer response 609, collates the payment amount 3404 with the billing amount, generates a payment request 613, and transmits it to the service providing system 102 by digital radiotelephone communication. ..

As shown in FIG. 36 (d), the payment request 613 includes header information indicating that the message is a payment request 613, a payment request header 3623, a payment offer 608, a payment offer response 609, and a user ID 3624. The data consisting of the issue date and time 3625 indicating the date and time when the payment request 613 was issued is digitally signed by the user and sealed to the service provider.

[0477] The service providing system 102 receives the credit inquiry request 610 and the payment request 613, decrypts the encryption, and checks the digital signature, respectively. Then, the request number, the transaction number, and the merchant ID are collated, and the merchant and the user who are trying to make a transaction correspond to the issued credit inquiry request 610 and the payment request 613, respectively, and further, the credit inquiry request. The contents of 610 and payment request 613 are collated to generate a credit inquiry response 614, which is transmitted to the credit settlement terminal 300 by digital telephone communication.

[0478] As shown in FIG. 36 (e), the authorization inquiry response 614 processes the authorization inquiry with header information indicating that the message is the authorization inquiry response 614, the authorization inquiry response header 3630, the transaction number 3631, and so on. The reference number 3632, which is arbitrarily generated as a unique number, the inquiry result 3633, which indicates the result of the authorization inquiry, the photo data 363 of the user's face, the expiration date 3635, which indicates the expiration date of this authorization response 614, and the service. The data consisting of the provider ID 3636 and the issue date and time 3637 indicating the date and time when this authorization inquiry response 614 was issued is digitally signed by the service provider and sealed to the merchant. If there is a problem with the user's credit status as a result of the credit inquiry, the photo data 3634 will not be set.

[0479] The credit settlement terminal 300 receives the credit inquiry response 614, decrypts the code, checks the digital signature, and displays the result of the credit inquiry on the LCD 302.

Next, when the person in charge of the merchant performs the payment processing request operation 616, the credit payment terminal 300 generates the payment request 617 and transmits it to the service providing system 102 by digital telephone communication.

As shown in FIG. 36 (f), the payment request 617 includes header information indicating that the message is a payment request 617, a payment request header 3642, a payment offer 608, a payment offer response 609, and a service provision. It consists of a reference number 3643 issued by system 102, an expiration date 3644 indicating the expiration date of this payment request 617, a contact name 3645, a merchant ID 3646, and an issue date and time 3647 indicating the date and time when this payment request 617 was issued. The data is digitally signed by the merchant and sealed to the service provider. The person in charge name 3616 is the information to be set in the merchant's option, and may not be set.

[0482] The service providing system 102 receives the payment request 617, decrypts the code, checks the digital signature, and collates the contents of the payment request 617 with the payment request 613. Then, with reference to the payment processing institution table 3204, the payment processing institution requesting payment is determined, and the generated payment request 619 is transmitted to the payment system 103 of the payment processing institution.

As shown in FIG. 37 (a), the payment request 619 includes header information indicating that the message is the payment request 619, the payment request header 3700, and the credit card number 3701 corresponding to the service code specified by the user. The request number 3702 issued by the personal credit terminal 100, the payment amount 3703, the payment option code 3704, the merchant account number 3705 indicating the account number of the merchant, and the transaction number 3706 issued by the credit payment terminal 300. , The data consisting of the expiration date 3707 indicating the expiration date of this payment request 619, the service provider ID 3708, and the issue date and time 3709 indicating the date and time when this payment request 619 was issued is digitally signed by the service provider and settled. It is a sealed letter addressed to the processing institution.

[0484] The payment system 103 receives the payment request 619, decrypts the code, checks the digital signature, performs the payment process, generates the payment completion notification 620, and sends it to the service providing system 102.

As shown in FIG. 37 (b), the payment completion notification 620 is a header information indicating that the message is a payment completion notification 620, a payment completion notification header 3714, and a number uniquely indicating the payment process of the payment system 103. Arbitrarily generated payment number 3715, credit card number 3716, request number 3717, payment amount 3718, payment option code 3719, merchant account number 3720, transaction number 3721, and digital signature of the payment processing agency. Payment information 3722 for service providers, payment information 3723 for merchants with a digital signature of the payment processing institution, payment information 3724 for users with a digital signature of the payment processing institution, payment processing institution ID 3725, and this payment is completed. The data consisting of the issue date and time 3726, which indicates the date and time when the notification was issued, is digitally signed by the payment processing institution and sealed to the service provider.

[0486] The service providing system 102 receives the payment completion notification 620, decrypts the code, checks the digital signature, generates the payment completion notification 621, and transmits the payment completion notification 621 to the credit payment terminal 300 by digital telephone communication.

As shown in FIG. 37 (c), the payment completion notification 621 includes header information indicating that the message is the payment completion notification 621, a payment completion notification header 3731, a payment number 3732, and a digital payment processing institution. The signed payment information 3723 for the merchant, the number generated as a unique number to indicate the user to the merchant, the customer number 3733, the decrypted payment request 3648, and the information related to the processing in the service providing system 102. The data consisting of the service provider processing information 3734, the service provider ID 3735, and the issue date and time 3736 indicating the date and time when this payment completion notification 621 was issued was digitally signed by the service provider and sealed to the merchant. It is a thing. The service provider processing information 3734 is information set by the option of the service provider, and may not be set.

[0488] The credit card payment terminal 300 receives the payment completion notification 621, decrypts the code, checks the digital signature, and displays the content on the LCD 302. Then, the credit card payment terminal 300 generates a receipt 623 and transmits it to the service providing system 102 by digital telephone communication.

As shown in FIG. 38 (a), the receipt 623 includes header information indicating that the message is receipt 623, a receipt header 3800, and a product name 3801 indicating the name of the product sold. Sales information 3802, payment number 3803, transaction number 3804, payment offer 608, contact name 3805, merchant ID 3806, and the date and time when this receipt 623 was issued, showing additional information about the merchant-to-user transaction. The data consisting of the issue date and time of 3807 shown is digitally signed by the merchant and sealed to the service provider. The sales information 3802 and the person in charge name 3805 are information set by the merchant's option, and may not be set.

[0490] The service providing system 102 receives the receipt 623, decrypts the code, checks the digital signature, generates the receipt 624, and transmits it to the personal credit terminal 100 by digital radiotelephone communication.

As shown in FIG. 38 (b), the receipt 624 includes header information indicating that the message is the receipt 624, a receipt header 3812, a decrypted receipt 3808, and a payment processing institution. Digitally signed payment information 3724 for users, service provider processing information 3813 indicating information on processing in the service providing system 102, service provider ID 3814, and issuance date and time 3815 indicating the date and time when this receipt 624 was issued. The data consisting of the data is digitally signed by the service provider and sealed to the user. The service provider processing information 3813 is information set by the option of the service provider, and may not be set.

[0492] The personal credit terminal 100 receives the receipt 624, decrypts the code, checks the digital signature, and displays the contents on the LCD 203.

[0493] Next, the details of the contents of the data exchanged between the devices in the "cancel" process will be described.

[0494] FIGS. 39 (a) to 39 (f) show the contents of the messages to be exchanged in the "cancel" process.

[0495] First, when the person in charge of the merchant performs the cancel operation 901, the credit settlement terminal 300 generates a cancellation request 903 and transmits it to the service providing system 102 by digital telephone communication.

On the other hand, when the user performs the cancel operation 904, the personal credit terminal 100 generates a cancel request 906 and transmits it to the service providing system 102 by digital wireless telephone communication.

As shown in FIG. 39 (a), the cancellation request 903 includes header information indicating that the message is a cancellation request 903, a cancellation request header 3900, a payment completion notification 3737 that decrypts the code, and this cancellation. The data consisting of the expiration date 3901 indicating the expiration date of the request 903, the contact person name 3902, the merchant ID 3903, and the issue date and time 3904 indicating the date and time when the cancellation request 903 was issued is digitally signed by the merchant to provide the service. It is a sealed letter addressed to the person. The person in charge name 3916 is information set by the merchant's option, and may not be set.

As shown in FIG. 39 (b), the cancellation request 906 includes header information indicating that the message is a cancellation request 906, a cancellation request header 3909, a decrypted receipt 3816, and the cancellation request. Data consisting of an expiration date 3910 indicating the expiration date of 906, a user ID 3911, and an issue date and time 3912 indicating the date and time when this cancellation request 906 was issued is digitally signed by the user and sealed to the service provider. Is.

[0499] The service providing system 102 receives the cancellation request 903 and the cancellation request 906, decrypts the encryption, and checks the digital signature, respectively. Then, the request number, the transaction number, and the merchant ID are collated, and the merchant and the user who are trying to perform the cancellation process deal with the issued cancellation request 903 and the cancellation request 906, respectively, and further, the cancellation request 903 and the cancellation request 903 The content of the cancellation request 906 is collated, the cancellation request 907 is generated, and the cancellation request 907 is transmitted to the payment system 103.

As shown in FIG. 39 (c), the cancellation request 907 includes header information indicating that the message is a cancellation request 907, a cancellation request header 3917, a payment completion notification 3727 in which the code is decrypted, and this cancellation. The data consisting of the expiration date 3918 indicating the expiration date of request 907, the service provider ID 3919, and the issue date and time 3920 indicating the date and time when this cancellation request 907 was issued is digitally signed by the service provider and addressed to the settlement processing institution. It is a sealed letter.

[0501] The payment system 103 receives the cancellation request 907, decrypts the code, checks the digital signature, performs the cancellation process, generates the cancellation completion notification 908, and sends it to the service providing system 102.

As shown in FIG. 39 (d), the cancellation completion notification 908 uniquely includes the header information indicating that the message is the cancellation completion notification 908, the cancellation completion notification header 3925, and the cancellation process performed by the payment system 103. The number shown, the cancellation number 3926, the decrypted cancellation request 3921, the cancellation information 3927 for the service provider with the digital signature of the payment processing institution, and the cancellation information 3928 for the merchant with the digital signature of the payment processing institution. A service that digitally signs the payment processing institution for data consisting of cancellation information 3929 for users who have digitally signed the payment processing institution, payment processing institution ID 3930, and issuance date and time 3931 indicating the date and time when this payment completion notification was issued. It is a sealed letter addressed to the provider. The service providing system 102 receives the cancellation completion notification 908, decrypts the code, checks the digital signature, generates the cancellation completion notification 909 and the cancellation processing receipt 910, and generates the cancellation completion notification 909 and the cancellation processing receipt 910, respectively, and the credit card payment terminal 300 and the personal. -Send to credit terminal 100.

As shown in FIG. 39 (e), the cancellation completion notification 909 decrypts the header information indicating that the message is the cancellation completion notification 909, the cancellation completion notification header 3936, the cancellation number 3937, and the code. Issued cancellation request 3905, payment processing information 3928 for merchants digitally signed by the payment processing institution, service provider processing information 3938 showing information about processing in the service providing system, service provider ID 3939, and this cancellation completion notification 909. The data consisting of the issue date and time of 3940, which indicates the date and time of the date, was digitally signed by the service provider and sealed to the merchant. The service provider processing information 3938 is information set by the option of the service provider, and may not be set.

As shown in FIG. 39 (f), the cancellation processing receipt 910 contains header information indicating that the message is the cancellation processing receipt 910, the cancellation processing receipt header 3945, the cancellation number 3946, and the code. Decrypted cancellation request 3913, digitally signed payment information 3929 of the payment processing institution, service provider processing information 3947 showing information about processing in the service providing system, service provider ID 3948, and this cancellation processing receipt. The data consisting of the issue date and time 3949, which indicates the date and time when the document 910 was issued, is digitally signed by the service provider and sealed to the user. The service provider processing information 3947 is information set by the option of the service provider, and may not be set.

[0505] The credit card payment terminal 300 receives the cancellation completion notification 909, decrypts the code, checks the digital signature, and displays the contents on the LCD 302. On the other hand, the personal credit terminal 100 also receives the cancellation processing receipt 910, decrypts the code, checks the digital signature, and displays the contents on the LCD 203.

Next, in the processing of the customer service call, the details of the contents of the data exchanged between the devices will be described.

[0507] FIGS. 40 (a) to 40 (e) show the contents of the messages to be exchanged in the processing of the customer service call.

[0508] First, when the person in charge of the merchant performs the customer service call operation 1200, the credit settlement terminal 300 generates the customer service call request 1202 and transmits it to the service providing system 102 by digital telephone communication.

As shown in FIG. 40 (a), the customer service call request 1202 includes header information indicating that the message is the customer service call request 1202, the customer service call request header 4000, and a number indicating the user. The customer number 4001 issued during the "payment" process, the request number 4002 uniquely indicating this customer service call request, the contact name 4003, the merchant ID 4004, and the date and time when this customer service call request 1202 was issued. The data consisting of the issue date and time of 4005 shown is digitally signed by the merchant and sealed to the service provider. The person in charge name 4003 is the information to be set in the merchant's option, and may not be set.

[0510] The service providing system 102 receives the customer service call request 1202, decrypts the code, and checks the digital signature. Then, the service providing system 102 determines the user from the customer table, collates it with the access control information of the user, generates the customer service call 1203 and the customer service call request response 1204, and generates the customer service call request response 1204, respectively, and the user's personal credit terminal. Send to 100 and credit payment terminal 300.

As shown in FIG. 40 (b), the customer service call 1203 includes header information indicating that the message is the customer service call 1203, a customer service call header 4010, a contact name 4011, and a merchant ID 4012. A digital signature of the service provider for data consisting of the merchant name 4013, the request number 4014 set by the credit payment terminal 300, the service provider ID 4015, and the issue date and time 4016 indicating the date and time when this customer service call 1203 was issued. It is done and sealed to the user. The person in charge name 4011 is the information to be set in the merchant's option, and may not be set.

As shown in FIG. 40 (c), the customer service call request response 1204 includes header information indicating that the message is the customer service call request response 1204, the customer service call request response header 4021, and the service providing system 102. Service provider for data consisting of response message 4022 from, request number 4023 set by credit settlement terminal 300, service provider ID 4024, and issue date and time 4025 indicating the date and time when this customer service call request response 1204 was issued. It was digitally signed and sealed to the merchant.

[0513] The credit card payment terminal 300 receives the customer service call request response 1204, decrypts the code, checks the digital signature, and displays "calling".

[0514] The personal credit terminal 100 receives the customer service call 1203, decrypts the code, checks the digital signature, and notifies the user of the incoming call. Then, when the user performs the call operation 1207, the personal credit terminal 100 transmits the incoming call answering 1208 to the service providing system 102. Upon receiving the incoming call answer 1208, the service providing system 102 transmits the call answer 1210 to the credit card payment terminal 300, and the credit card payment terminal 300 and the personal credit terminal 100 are in a call state. As shown in FIG. 40 (d), the incoming call answering 1208 is composed of header information indicating that the message is an incoming call answering 1208, an incoming call answering header 4030, and a request number 4031 set by the credit card settlement terminal 300, and is called. As shown in FIG. 40 (e), the response 1210 is composed of header information indicating that the message is a call response 1210, a call response header 4032, and a request number 4033 set by the credit card settlement terminal 300.

[0515] Next, in the process of the "inquiry call", the details of the contents of the data exchanged between the devices will be described.

[0516] FIGS. 41 (a) to 41 (e) show the contents of the messages to be exchanged in the processing of the "inquiry call".

[0517] First, when the user performs the inquiry call operation 1213, the personal credit payment terminal 100 generates the inquiry call request 1215 and transmits the inquiry call request 1215 to the service providing system 102 by digital wireless telephone communication.

As shown in FIG. 41 (a), the inquiry call request 1215 includes header information indicating that the message is the inquiry call request 1215, an inquiry call request header 4100, a merchant ID 4101, a contact name 4102, and the like. The data consisting of request number 4103, which uniquely indicates this inquiry call request, user ID 4104, and issue date and time 4105, which indicates the date and time when this inquiry call request 1215 was issued, is digitally signed by the user and sealed to the service provider. It is a digital version. The person in charge name 4103 is information set by the merchant's option at the time of processing "payment", and may not be set.

[0519] The service providing system 102 receives the inquiry call request 1215, decrypts the code, and checks the digital signature. Then, the service providing system 102 generates an inquiry call 1216 and an inquiry call request response 1217, and transmits the inquiry call to the credit payment terminal 300 and the personal credit payment terminal 100, respectively.

As shown in FIG. 41 (b), the inquiry call 1216 is set by the header information indicating that the message is the inquiry call 1216, the inquiry call header 4110, the customer number 4111, and the personal credit terminal 100. The data consisting of request number 4112, service provider ID 4113, and issue date and time 4114 indicating the date and time when this inquiry call 1216 was issued is digitally signed by the service provider and sealed to the merchant.

As shown in FIG. 41 (c), the inquiry call request response 1217 includes header information indicating that the message is an inquiry call request response 1217, an inquiry call request response header 4119, and a response from the service providing system 102. The service provider's digital data consists of message 4120, request number 4121 set by the personal credit payment terminal 100, service provider ID 4122, and issue date and time 4123 indicating the date and time when this inquiry call request response 1217 was issued. It is signed and sealed to the user.

[0522] The personal credit terminal 100 receives the inquiry call request response 1217, decrypts the code, checks the digital signature, and displays "calling". The credit card payment terminal 300 receives the inquiry call 1216, decrypts the code, checks the digital signature, and notifies the merchant of the incoming call. Then, when the merchant performs the call operation 1220, the credit settlement terminal 300 transmits the incoming call answering 1221 to the service providing system. The service providing system that receives the incoming call answer 1221 sends the call answer 1223 to the personal credit terminal, and the personal credit terminal 100 and the credit payment terminal 300 are in a call state.

As shown in FIG. 41 (d), the incoming call answering 1221 includes header information indicating that the message is an incoming call answering 1221, an incoming call answering header 4128, and a request number 4129 set by the personal credit settlement terminal 100. The call response 1223 is composed of the header information indicating that the message is the call response 1223, the call response header 4130, and the request number 4131 set by the personal credit settlement terminal 100, as shown in FIG. 41 (e). Consists of.

(Embodiment 2) Next, a second embodiment of the present invention will be described. In the second embodiment, a personal remote credit card payment system that enables efficient processing of the personal remote credit card payment service will be described.

[0525] The basic configuration of this personal remote credit payment system is the same as that of the first embodiment, and as shown in FIG. 1, two systems of two-way wireless communication function and an electronic credit card function. A personal credit terminal 100 with a credit card, a credit card payment device 101 that performs credit payment processing at a retail store, a payment system 103 that performs credit payment processing at a credit service company or a payment processing company, a personal credit terminal 100, and credit. A service providing system 102 that provides a personal remote credit payment service located at the center of a communication network connecting the payment device 101 and the payment system 103, a digital public network 108 that provides a data transmission path in the network, and personal credit. It is equipped with a wireless telephone base station 104 that connects the terminal 100 to the digital public network 108.

[0526] The personal credit terminal 100 is a mobile radiotelephone terminal having two types of two-way wireless communication functions of infrared rays and a digital radiotelephone and an electronic credit card function. In addition, the credit card payment device 101 that performs credit card payment processing at retail stores also has two two-way communication functions of infrared communication and digital telephone communication.

[0527] In FIG. 1, 105 is a transmission line for infrared communication between the personal credit terminal 100 and the credit settlement device 101, and 106 is between the personal credit terminal 100 and the base station 104. Indicates a transmission line for digital wireless communication, 107 is a digital communication line connecting the base station 104 and the digital public network 108, 109 is a digital communication line connecting the digital public network 108 and the service providing system 102, and 110 is a credit. A digital telephone communication line connecting the payment device 101 and the digital public network 108, 111 indicates a digital communication line connecting the service providing system 102 and the payment system 103. In particular, the digital communication line 109 and the digital communication line 111 operate as a plurality of communication lines by multiplexing.

[0528] The normal operation mode of the personal remote credit payment service is the same as that of the first embodiment, and has the following form.

[0529] The payment system 103 is installed in a credit card company or a payment processing company, and the credit payment device 101 is installed in a retail store, and a consumer carries a personal credit terminal 100. The service providing system 102 is installed in a company that provides a personal remote credit payment service, and when the credit card company provides a personal remote credit payment service, the service providing system 102 is installed in the credit card company. Will be done.

[0530] As a premise, the consumer has a membership contract for a credit service with a credit card company, and a personal remote credit payment service with a company that provides a personal remote credit payment service. In addition, we have a membership contract with a telephone company and a wireless telephone service contract. Similarly, retailers also enter into credit service merchant agreements with credit card companies and personal remote credit payment service merchants with companies that provide personal remote credit payment services. We have a contract and a digital telephone communication service contract with a telephone company.

[0531] If the personal remote credit card payment service is provided by a company other than the credit card company, the company that provides the personal remote credit card payment service may be one or more credit card companies. They have a contract to issue an electronic credit card instead of a credit card company to a member who has a contract for a credit service and operate a personal remote credit payment service.

[0532] When the payment processing company performs credit payment processing using the payment system 103, the payment processing company performs credit payment processing with one or more credit card companies. Has a contract on behalf of.

[0533] When the payment system that performs the credit payment process differs depending on the credit card, a plurality of payment systems are connected to the service providing system 102 by a digital communication line in the same manner as the payment system 103 of FIG. Will be done.

[0534] In the following, in order to simplify the explanation of this system, the consumer owned by the personal credit terminal 100 is the user, the retail store where the credit payment device 101 is installed is the merchant, and the credit is credited. The sales clerk who operates the payment device 101 is the person in charge (Operator), the company that provides the personal remote credit payment service is the service provider (Service Provider), the credit card company that performs credit payment processing using the payment system 103, or A payment processing company will be referred to as a payment processing institution (Transaction Processor).

[0535] In this system, when a user pays a merchant for a product by credit, payment information is electronically exchanged between the personal credit terminal 100, the credit payment device 101, and the service providing system 102. Further, the credit payment process is performed by electronically exchanging payment information between the service providing system 102 and the payment system 103.

[0536] Basically, the service providing system 102 receives a payment request and a payment request from the personal credit terminal 100 and the credit payment device 101, respectively, collates the payment request and the payment request, and collates with the user. Request payment processing from payment system 103 on behalf of the merchant. Then, the payment system performs the actual payment processing.

At this time, the personal credit terminal 100 and the credit settlement device 101 perform infrared communication using the transmission line 105, and the personal credit terminal 100 and the service providing system 102 are connected to the transmission line 106 and the base station. 104, and digital telephone communication by digital wireless telephone is performed via digital communication line 107, digital public network 108, and digital communication line 109, and the credit settlement device 101 and the service providing system 102 are connected to the digital telephone communication line 110, Digital telephone communication is performed via the digital public network 108 and the digital communication line 109. Then, the service providing system 102 and the payment system 103 perform digital data communication via the digital communication line 111.

[0538] Payment information exchanged in communication between the personal credit terminal 100 and the service providing system 102, communication between the credit payment device 101 and the service providing system 102, and communication between the service providing system 102 and the payment system 103. Are all encrypted and communicated. For encryption, information is electronically sealed and communicated by combining private key cryptographic processing and public key cryptographic processing.

[0539] Next, each component constituting this system will be described.

[0540] First, the personal credit terminal 100 will be described. The appearance of the personal credit terminal 100 is the same as that of the first embodiment, and has the appearances of the front side and the back side shown in FIGS. 2 (a) and 2 (b).

[0541] The personal credit terminal 100 has three operation modes, a credit card mode, a digital radiotelephone mode, and a personal information management mode, which are switched by a mode switch 204. The personal credit terminal 100 operates as a digital radiotelephone in the digital radiotelephone mode, and operates as an electronic credit payment means, that is, an electronic credit card in the credit card mode.

[0542] An electronic credit card is registered in the personal credit terminal 100 on the premise of a membership contract of a credit service with a credit card company by a user. When the user has a membership contract for a plurality of credit services, the plurality of credit cards are registered in the personal credit terminal 100.

[0543] The personal information management mode is an operation mode for managing the personal information of the user stored inside the personal credit terminal 100, and in the personal information management mode, the user can use the registered personal information and photo data. Etc. and set user setting information.

[0544] When making a call using this personal credit terminal 100, for example, the user first sets the operation mode to the digital radiotelephone mode with the mode switch 204, and then uses the numeric keypad switch 208 to change the telephone number. Enter and press call switch 205. With the above operation, the user can make a call to the entered telephone number.

[0545] Further, when a normal telephone call is made to the personal credit terminal 100, the personal credit terminal 100 emits a ring tone regardless of the operation mode at that time. In this case, pressing the call switch 205 automatically switches to the digital radiotelephone mode, and the user can receive the call.

[0546] When paying the merchant by credit, first, the mode switch 204 sets the operation mode to the credit card mode, and the function switch 207 selects the credit card to be used for payment. Next, on the numeric keypad switch 208, enter the amount to be paid, point the infrared communication port 200 toward the merchant's credit card payment device 101, and press the execution switch 211. By the above operation, the personal credit terminal 100 performs infrared communication with the credit payment device 101 and digital wireless telephone communication with the service providing system 102, and exchanges payment information with each other. Perform credit card payment processing.

[0547] Next, the credit card payment device 101 will be described. The appearance of the credit card payment device 101 is the same as that of the first embodiment, and has the appearance shown in FIG.

[0548] The credit card payment terminal 300 has three operation modes of a credit card payment mode, a digital telephone mode, and a merchant information management mode, which are switched by a mode switch 304. In the digital telephone mode, it operates as a digital telephone device, and in the credit payment mode, it operates as a credit payment processing terminal of a personal remote credit payment service.

[0549] The merchant information management mode is an operation mode for managing the merchant information stored inside the credit card payment terminal 300, and in the merchant information management mode, the merchant can refer to the registered merchant information and the like, and , Set the merchant setting information.

[0550] When making a call from the credit card payment terminal 300, for example, the person in charge first sets the operation mode to the digital telephone mode with the mode switch 304, and then inputs the telephone number with the numeric keypad switch 307. By the above operation, the person in charge can make a call to the entered telephone number.

[0551] Further, when a normal telephone call is made to the credit card payment terminal 300, the credit card payment terminal 300 emits a ring tone regardless of the operation mode. In this case, by raising the telephone device 303 or pressing the hook switch 305, the telephone mode is automatically switched and the person in charge can receive the call.

[0552] Further, when performing the credit settlement process, first, the cash register 311 calculates the total amount from the product price, the tax, and the like, and informs the user of the total amount. Next, according to the request of the user who wishes to pay by credit, the credit settlement switch 312 of the cash register 311 is pressed, and the user waits for the payment operation to be performed on the personal credit terminal 100. When the user performs a payment operation, the payment amount entered by the user is displayed on the LCD 302, and the result of the user's credit inquiry is also displayed. The person in charge confirms the contents and presses the execution switch 308.

[0553] By the above operation, the credit card payment device 101 exchanges payment information with the personal credit terminal 100 and the service providing system 102, respectively, and performs credit card payment processing.

[0554] Next, the service providing system will be described. The service providing system 102 has the same block configuration as that of the first embodiment, and as shown in FIG. 4, the personal credit terminal 100, the credit payment device 101, and the payment system in the personal remote credit payment service. The service server 400 that processes the data of the payment information exchanged with each of the 103 and controls the data communication at that time, the attribute information about the user, the merchant, and the payment processing institution, and the history information of the service provided by the service providing system 102. The service director information server 401 that manages the user information server 401, the user information server 402 that manages the user attribute information and the data in the personal credit terminal 100, and the merchant attribute information and the data in the credit payment terminal 300 are managed. The computer information server 403 is provided, the payment processing institution information server 404 that manages the attribute information of the payment processing institution and the history information of the payment processing, and the management system 407 in which the service provider manages the operation of the service providing system 102. Each server 400 to 404 and management system 407 are composed of one or more computers, respectively.

[0555] Further, the service server 400, the service director information server 401, the user information server 402, the merchant information server 403, and the payment processing institution information server 404 are connected to the ATM-LAN switch 405 by the ATM-LAN cable 409,410,411,412,413, respectively. The service server 400 accesses the service director information server 401, the user information server 402, the merchant information server 403, or the payment processing institution information server 404 via the ATM-LAN switch 405.

[0556] Further, the ATM-LAN switch 405 is connected to the ATM switch 406 by the ATM-LAN cable 415. A digital communication line 109 connected to the digital public network 108 and a digital communication line 111 connected to the payment system 103 are connected to the ATM exchange 404, and the service server 400 is connected to the ATM exchange 405 via the ATM-LAN switch 405 and the ATM exchange 406. Communicates with a personal credit terminal 100, a credit card payment device 101, and a payment system 103.

The management system 407 is connected to the ATM-LAN switch 406 by the ATM-LAN cable 414 and further to the ATM switch 406 by the ATM-LAN cable 416. The management system 407 uses the service server 400, the service director information server 401, the user information server 402, the merchant information server 403, or the payment processing institution information via the ATM-LAN switch 408, the ATM switch 406, and the ATM-LAN switch 405. Access the server 404 and manage the operation of the service providing system 102.

[0558] The ATM switch 406 operates as a data communication switch in communication between the outside and the inside of the service providing system 102 and communication between the inside of the service providing system 102. In addition, the ATM switch 406 supports a plurality of communication methods and has a communication adapter function. For example, in the communication between the service server 400 and the credit settlement device 101, first, the ISDN data packet is exchanged between the credit settlement device 101 and the ATM exchange 406, and the ATM exchange 406 exchanges the ISDN data packet to the ATM packet. The ATM packet is exchanged between the ATM switch 406 and the service server 400 by converting to and vice versa. Similarly, in the communication between the service server 400 and the personal credit terminal 100 and the communication between the service server 400 and the payment system 103, the ATM exchange 406 corresponds to each communication method and of the communication data. Perform the conversion.

[0559] Further, in order to reduce communication costs between the personal credit terminal 100 and the service providing system 102 and between the credit payment device 101 and the service providing system 102, the service providing system 102 is usually a personal remote credit. It is installed in each area (service area) that provides payment services. Therefore, the ATM switch 406 is connected to a dedicated digital communication line 417 that connects to a service providing system in another region. In this case, the service providing systems 102 share data with each other and perform data processing in cooperation with each other.

[0560] The mechanism of data sharing and cooperative processing between service providing systems will be described in detail later.

Next, the payment system 103 will be described. The payment system 103 has the block configuration shown in FIG. 5, as in the first embodiment. In the personal remote credit payment service, the credit payment processing performed by the payment system 103 is performed by the transition processing server 500, the subscriber information server 501, the member store information server 502, in response to the payment request from the service providing system 102. And, it is established by updating the information of the transaction information server 503.

[0562] Further, in the ATM exchange 505, in addition to the digital communication line 111 connected to the service providing system 102, the bank dedicated line 515 connected to the bank online system, and the dedicated digital connected to the payment system of another payment processing institution. The line 516 is connected, and the payment system 103 communicates with the bank online system and the payment system of another payment processing institution to perform payment processing between financial institutions.

[0563] The management system 506 is connected to the ATM-LAN switch 507 by the ATM-LAN cable 512, and further connected to the ATM switch 505 by the ATM-LAN cable 514. The management system 506 accesses the transition processing server 500, the subscriber information server 501, the member store information server 502, or the transaction information server 503 via the ATM-LAN switch 507, the ATM switch 505, and the ATM-LAN switch 504. Then, the operation management of the payment system 103 is performed.

[0564] The ATM exchange 505 operates as a data communication exchange in communication between the outside and the inside of the payment system 103 and communication between the inside of the payment system 103. In addition, the ATM switch 505 has a communication adapter function corresponding to a plurality of communication methods, and communicates between the transition processing server 500 and the service providing system 102, and between the transition processing server 500 and the bank online system. In the communication between the transaction processing server 500 and the payment system of another payment processing institution, the ATM exchange 505 converts the communication data according to each communication method.

Next, the personal remote credit payment service provided by this system will be described.

[0566] The personal remote credit payment service is roughly divided into four processes: "payment", "cancellation", "customer service call", and "inquiry call".

[0567] "Payment" is a process in which a user pays a merchant by credit, and "Cancel" is a personal remote. -The process of canceling a transaction completed by the "payment" process of the credit card payment service by wireless communication based on the agreement between the user and the merchant. The "customer service call" is the "payment" of the personal remote credit card payment service. "Inquiry call" is a personal remote credit card payment service that enables the merchant to contact the user who has made a transaction even if he / she does not know the user's phone number. It is a process that enables a user to make an inquiry to a merchant who has made a transaction by the "payment" process without knowing his / her own phone number.

FIG. 43 shows the flow of processing of payment in this personal remote credit payment service, and FIG. 44 shows a display example of LCD 203 of the personal credit terminal 100 during this payment processing. (A) to (i) are shown, and a display example of the LCD 302 of the credit card payment terminal 300 is shown in FIGS. 8 (a) to (g).

Further, FIG. 9 shows a flow of cancellation processing in this personal remote credit payment service, and also shows a display example of LCD 203 of the personal credit terminal 100 during this cancellation processing. 10 (a) to (h) are shown, and a display example of the LCD 302 of the credit card payment terminal 300 is shown in FIGS. 11 (a) to 11 (g).

[0570] Further, the flow of processing of the customer service call in this personal remote credit payment service is shown in FIG. 45 (a), and the personal credit terminal 100 at the time of processing this customer service call. Display examples of LCD 203 are shown in FIGS. 13 (a) to 13 (b), and display examples of LCD 302 of the credit card payment terminal 300 are shown in FIGS. 14 (a) to (g).

Further, the flow of processing of the inquiry call in this personal remote credit payment service is shown in FIG. 45 (b), and the LCD 203 of the personal credit terminal 100 at the time of processing this inquiry call. Display examples of the above are shown in FIGS. 13 (b) to 13 (f), and display examples of the LCD 302 of the credit card payment terminal 300 are shown in FIGS. 14 (h) and (f).

[0572] The flow of each of these processes is substantially the same as that described in the first embodiment.

Next, the internal configuration of the personal credit terminal 100 will be described.

FIG. 15A is a block configuration diagram of the personal credit terminal 100. This terminal has a CPU (Central Processing Unit) 1500 that processes transmitted data and received data according to a program stored in ROM (Read Only Memory) 1501 and controls other components via bus 1529. , RAM (Random Access Memory) 1502 that stores the data processed by the CPU 1500 and the data processed by the CPU 1500, the terminal ID, telephone number, user ID of the user, and the private key and public key of the personal credit terminal 100. In addition, the service provider ID of the service providing system 102, the telephone number (the telephone number of the service providing system is digitally signed by the service provider), and the EEPROM containing the public key of the service provider ( Electric Erasable Programmable Read Only Memory) 1503, LCD controller 1504 that controls the operation of LCD203 according to the control of CPU1500 and displays the image set by CPU1500 on the LCD, and encryption that performs data encryption processing and decryption processing under the control of CPU1500. A processing processor 1505, a data codec 1506 that encodes transmitted data and decodes received data under the control of CPU 1500, an infrared communication module 1507 that transmits and receives infrared light during infrared communication, and a mode switch by the user. 204, call switch 205, end switch 206, function switch 207, ten-key switch 208, power switch 209, and key operation control unit 1509 that detects the switch operation of execution switch 211, and speaker 1510, receiver 202, or headset jack 212. The audio processing unit 1511 that drives the connected headset and amplifies the analog audio signal input from the microphone 210 or the headset, the coding of the analog audio signal 1542 to digital audio data, and the analog audio signal 1543 of the digital audio data. A voice codec 1512 that decodes to, a channel coden 1513 that generates transmission data on a wireless channel and extracts data addressed to itself from received data, and a serial digital signal input from the channel codec 1513. The modulator 1514 that converts 1547 into an analog transmission signal 1549 that uses the oscillating electrical signal 1552 supplied from the PLL 1516 as the base band, and the oscillating electrical signal 1553 supplied from the PLL 1516 as the base band of the analog reception signal 1550. The demodulator 1515 that demolishes the 1550 and supplies the serial digital signal 1548 to the channel codec 1513, and the analog transmission signal 1549 supplied from the modulator 1514 are converted into radio waves and output from the antenna 201, and conversely, the radio radio waves. Is received by the antenna 201, the analog received signal 15 is sent to the demodulator 1515.RF unit 1517 for inputting 50, battery capacity detection unit 1518 for detecting the battery capacity of the personal credit terminal 100, activation control of channel codec 1513, PLL 1516 and RF unit 1517, key operation control unit 1509, channel codec 1513. And the processing of the interrupt signal input from the battery capacity detection unit 1518, and the role of the interface when the CPU 1500 accesses the internal registers of the key operation control unit 1509, the voice processing unit 1511, the voice codec 1512, and the channel codec. It is equipped with a control logic unit 1508 that fulfills.

[0575] The cryptographic processing processor 1505 has a function of encryption and decryption of the private key method and a function of encryption and decryption of the public key method, and the encryption method and the key set by the CPU 1500 are used by the CPU 1500. The set data is encrypted or decrypted. Using the encryption and decryption function of this encryption processing processor 1505, the message is digitally signed or sealed, and the encrypted message is decrypted or digitally signed. The digital signature of the message is verified.

[0576] Further, the data codec 1506 encodes the transmitted data and decodes the received data under the control of the CPU 1500. In this case, the coding includes communication control information and error correction information, and is actually Decoding means the process of generating the data to be transmitted to, and the decoding is the process of performing error correction processing on the received data, removing excess communication control information, and generating the data originally intended to be transmitted by the sender. Means processing. The data codec 1506 has a data coding and decoding function in digital radiotelephone data communication and a data coding and decoding function in infrared communication, and the CPU1500 is used for data set by the CPU1500. Performs the coding process and the decoding process set by.

[0577] For example, when a message subjected to digital signature processing and sealing processing is transmitted by digital wireless telephone communication, the CPU 1500 uses a cryptographic processing processor 1505 to perform digital signature processing and sealing of the message. Processing is performed, and a message that has undergone digital signature processing and sealing processing using the data codec 1506 is encoded into the data format of the data communication of the digital wireless telephone, and the control logic unit 1508 is used to encode the message. It is sent to the channel codec 1513 via.

[0578] On the contrary, when the message subjected to the digital signature processing and the sealing process is received by the digital wireless telephone communication, the CPU 1500 receives the received message via the control logic unit 1508, and the channel codec. Read from 1513, the data codec 1506 is used to decrypt the received message, and the encryption processor 1505 is used to decrypt the encrypted message and verify the digital signature applied to the message. Perform processing.

Similarly, when transmitting a message subjected to digital signature processing and sealing processing by infrared communication, the CPU 1500 uses the encryption processing processor 1505 to perform digital signature processing and sealing processing of the message. Then, using the data codec 1506, the message subjected to the digital signature processing and the sealing process is encoded into the data format of the infrared communication and sent to the infrared communication module 1507.

[0580] Conversely, when a message subjected to digital signature processing and sealing processing is received by infrared communication, the CPU 1500 reads the received message from the infrared communication module 1507 and uses the data codec 1506. Then, the received message is decrypted, and further, the encryption processing processor 1505 is used to perform the decryption processing of the encryption of the sealed message and the verification processing of the digital signature applied to the message.

Further, as shown in FIG. 15B, the infrared communication module 1507 includes a series-parallel conversion circuit 1560 that performs bidirectional conversion between parallel data and serial data, and a series-parallel conversion. A modulation / demodulation circuit 1561 that modulates the digital signal 1562 converted to serial data by the circuit 1560 into a signal that is actually transmitted as infrared data, and demolishes the received analog signal 1565 into a serial digital signal 1563, and a modulation / demodulation circuit 1561. It is provided with an infrared light receiving / emitting unit 200 that converts the modulated signal 1564 into infrared light and emits light, and also converts the received infrared light into an analog signal 1565.

[0582] In the key operation control unit 1509 for detecting a switch operation by the user, the user can use one of the mode switch 204, the call switch 205, the end switch 206, the function switch 207, the numeric keypad switch 208, the power switch 209, or the execution switch 211. When is pressed, the key operation control unit 1509 asserts the interrupt signal 1538 prompting the processing corresponding to the switch operation. Further, as shown in FIG. 46, the key operation control unit 1509 includes a key operation control register (KEYCTL) 21612 for setting the enable / disable of each switch. The CPU1500 accesses this key operation control register (KEYCTL) 21612 to enable / disable each switch.

As shown in FIG. 46, the voice processing unit 1511 includes a voice processing unit control register (SCTL) 21611 that controls the voice processing operation. The CPU 1500 accesses the voice processing unit control register (SCTL) 21611 to control the operation of the voice processing unit 1511. For example, when a call request for a digital radiotelephone is received, the CPU 1500 accesses the voice processing unit control register (SCTL) 21611 and sets to output the ringtone of the digital radiotelephone. As a result, the voice processing unit 1511 drives the speaker 1510, and the ringtone of the digital wireless telephone is output. However, if the call is received from the service providing system 102, the ringtone is not output and the CPU 1500 starts the process of establishing a session with the service providing system. The details of the process of establishing a session will be described in detail later.

The audio codec 1512 encodes the analog audio signal 1542 input from the audio processing unit 1511 into digital audio data, and from the channel codec 1513 to the analog audio signal 1543 of the digital audio data read as the digital audio signal 1546. Decryption of. The analog audio signal 1543 is supplied to the audio processing unit 1511, and the audio processing unit 1511 amplifies the analog audio signal 1543 and drives the receiver 202 to output audio from the receiver 202. Further, the digital audio data generated by the coding is supplied to the channel codec 1513 as a digital audio signal 1546, and is actually converted into transmission data on a wireless channel.

[0585] Further, the voice codec 1512 includes a voice data encryption key register (CRYPT) 21613 for storing a secret key type encryption key used for encrypting and decrypting voice data, and the voice data encryption key register is provided. When a voice data encryption key is set in (CRYPT) 21613 by the CPU 1500, the voice codec 1512 encodes the analog voice signal 1542 into digital voice data and at the same time encrypts the digital voice data. At the same time as decoding the analog audio signal 1543, the encryption of digital audio data is decrypted.

Further, two types of data are input to the channel codec 1513 as data to be transmitted. One is digital audio data input as a digital audio signal 1546 from the audio codec 1512, and the other is data communication data input as a digital signal 1556 from the CPU 1500 via the control logic unit 1508.

[0587] The channel codec 1513 adds identification information between digital voice data and data communication data as header information to the respective data, and further converts the data into a digital wireless telephone data format to serialize the digital signal 1547. Is supplied to the modulation unit 1514.

[0588] On the contrary, the channel codec 1513 first collates the terminal ID with respect to the serial digital signal 1548 input from the demodulator 1515, extracts only the data addressed to itself, and further, the digital wireless telephone. The communication control information of the above is removed, the digital voice data and the data communication data are identified from the data header information, and the digital voice signal 1546 and the digital signal 1556 are supplied to the voice codec 1512 and the control logic unit 1508, respectively.

[0589] Further, the channel codec 1513 asserts the interrupt signal 1554 when receiving a digital radiotelephone and when receiving data communication data, and lows the control signal 1544 when receiving digital audio data. Make it a level. The interrupt signal 1554 is an interrupt signal that prompts the CPU 1500 to process an incoming digital wireless telephone call and process data communication data, and the control signal 1544 processes the digital audio data received by the audio codec 1512. It is a low-active control signal that prompts.

[0590] In order to perform such an operation, the channel codec 1513 has an ID register (ID) 21605 for storing the terminal ID and a channel codec control register (CHCTL) for controlling the operation of the channel coden 1513, as shown in FIG. From the CPU 1500 via the 21606, the audio transmission buffer 21607 that stores the digital audio data input from the audio codec 1512, the audio reception buffer 21608 that stores the digital audio data extracted from the received data, and the control logic unit 1508. It includes a data transmission buffer 21609 for storing input data communication data and a data reception buffer 21610 for storing data communication data extracted from the received data.

[0591] The control signal 1545 is a control signal indicating the operation of writing and reading by the voice codec 1512 to the voice transmission buffer 21607 and the voice reception buffer 21608 on the channel codec 1513, and the voice codec 1512 is the control signal 1545. Is set to low level to write digital audio data to the audio transmission buffer 21607, and the control signal 1545 is set to high level to read digital audio data from the audio reception buffer 21608.

[0592] The control signal 1555 is a control signal indicating the operation of writing and reading from the data transmission buffer 21609 and the data reception buffer 21610 to the data transmission buffer 21609 and the data reception buffer 21610 by the CPU 1500 via the control logic unit 1508 in the channel codec 1513. The data communication data is written to the data transmission buffer 21609 at the low level, the control signal 1555 is set to the high level, and the data communication data is read from the data reception buffer 21610.

[0593] The modulation unit 1514 converts the serial digital signal 1547 input from the channel codec 1513 into an analog transmission signal 1549 whose baseband is the oscillating electric signal 1552 supplied from the PLL 1516, and supplies the signal to the RF unit. The analog transmission signal 1549 supplied to the RF unit is output from the antenna 201 as a radio wave.

[0594] On the contrary, when the antenna 201 receives the radio wave, the analog reception signal 1550 is input from the RF unit 1517 to the demodulation unit 1515. The demodulation unit 1515 demodulates the analog reception signal 1550 using the oscillating electric signal 1553 supplied from the PLL 1516 as the base band of the analog reception signal 1550, and supplies the serial digital signal 1548 to the channel codec 1513.

Further, the battery capacity detection unit 1518 that detects the battery capacity receives an interrupt signal 1557 when the battery capacity of the personal credit terminal 100 becomes equal to or less than the value Q (Q&gt; 0) set by the CPU 1500. Is asserted. The interrupt signal 1557 is an interrupt signal that prompts the CPU 1500 to back up the data on the RAM 1502, and Q is that the personal credit terminal 100 communicates with the service providing system 102 to provide the data on the RAM 1502 as a service. This value is sufficient to perform the process of backing up to the system 102 (data backup process).

Further, as shown in FIG. 46, the control logic unit 1508 includes a frame counter (FRAMEC) 21600, a start frame register (FRAME) 21601, a clock counter (CLOCKC) 21602, and an update time register (UPTIME). It contains five registers, 21603 and interrupt register (INT) 21604.

The frame counter 21600 is a counter that counts the number of frames of a digital wireless telephone, the activation frame register 21601 is a register that stores the frame number to be activated next time, and the clock counter 21602 is a counter that counts the current date and time. The update time register 21603 is a register that stores the time when the personal credit terminal 100 communicates with the service providing system 102 to update the data on the RAM 1502 (data update process), and the interrupt register 21604. Is a register that indicates the cause of interruption to CPU1500.

[0598] In general, a digital radiotelephone intermittently receives control data of a control channel of a digital radiotelephone and collates it with a terminal ID to realize an incoming call addressed to itself. The personal credit terminal 100 uses the frame counter 21600 and the activation frame register 21601 to perform intermittent reception of control data. The frame number to be started next time is stored in the start frame register 21601 in advance, and when the frame counter 21600 counts up and becomes equal to the value of the start frame register 21601, the control logic unit 1508 sends the address data. The channel codec 1513, PLL1516, and RF unit 1517 are activated via the signal line 1558 to receive control data.

Further, in the control logic unit 1508, when the value of the clock counter 21602 matches the value of the update time register 21603, or when any of the interrupt signals 1538, 1554, 1557 is asserted. Then, the interrupt factor is set in the interrupt register (INT) 21604, the interrupt signal 1519 is asserted, and the CPU 1500 is prompted to perform the interrupt process. The CPU1500 reads the interrupt register (INT) 21604 in the interrupt process and performs the process according to the interrupt factor.

Each bit field of this interrupt register (INT) 21604 is meant as shown in FIG. 47 (a). This meaning is the same as that described with reference to FIG. 18 (b) in the first embodiment.

Next, the data stored in the RAM 1502 will be described.

[0602] FIG. 48 is a schematic diagram of a RAM map of data stored in RAM 1502.

[0603] The RAM 1502 has five areas: a basic program area 21800, a service data area 21801, a user area 21802, a work area 21803, and a temporary area 21804. The basic program area 21800 stores upgraded modules of programs stored in ROM 1501, patch programs, and additional programs.

[0604] The user area 21802 is an area that can be freely used by the user, the work 21803 area is a work area used by the CPU 100 when executing a program, and the temporary area 21804 is information received by the personal credit terminal 100. Is an area that temporarily stores. The service data area 21801 is an area for storing ID information, credit card information, history information, etc. of the personal remote credit payment service, and the data in this area is managed by the service providing system 102.

[0605] The service data area 21801 further includes data management information 21805, personal information 21806, photo data 21807, user setting information 21808, telephone information 21809, credit card list 21810, usage history list 21811, and actual data area 21812. There are 8 areas. The data management information 21805 is an area for storing management information of information stored in the service data area 21801, the personal information 21806 is an area for storing information such as the user's name, age, and gender, and the photo data area 21807 is an area for storing information. The area for storing user's face photo data, user setting information 21808 is an area for storing user setting information related to personal remote credit payment service, and telephone information 21809 is an area for storing information related to digital wireless telephone. , The credit card list 21810 is an area for storing the list information of the credit card registered by the user, the usage history list 21817 is an area for storing the usage history information of the personal remote credit payment service, and the actual data area 21812 is another. It is an area that stores the actual data of the information managed in the seven areas of.

Next, the information stored in the service data area 21801 will be described in detail.

[0607] FIG. 49 is a schematic diagram showing in detail the relationship of the information stored in the service data area 21801.

[0608] Data management information 21805 includes update date and time 21900, next update date and time 21901, terminal status 21902, personal information address 21903, photo data address 21904, user setting information address 21905, telephone information address 21906, credit card list address 21907. , And the usage history list address 21908 consists of nine pieces of information.

[0609] The update date and time 21900 indicates the date and time when the service providing system 102 last updated the data of the RAM 1502, and the next update date and time 21901 is the scheduled date and time when the data of the service data area 21801 by the next service providing system 102 is updated. Is shown.

The value of this next update date and time 21901 is set in the update time register 21603, and when the time of the next update date and time 21901 comes, the personal credit terminal 100 starts the data update process. The data update process is a process in which the service providing system 102 updates the data in the RAM 1502, and is usually performed every day during a time when the communication traffic is relatively uncrowded (eg, midnight).

[0611] Terminal status 21902 indicates the status of the personal credit terminal 100, personal information address 21903, photo data address 21904, user setting information address 21905, telephone information address 21906, credit card list address 21907, and usage history. The list address 21908 indicates the start address of the area in which the personal information 21806, the photo data 21807, the user setting information 21808, the telephone information 21809, the credit card list 21810, and the usage history list 21811 are stored, respectively.

[0612] The telephone information 21809 is further composed of three pieces of information: a calling telephone number 21909, a telephone directory address 21910, and a shortened dial setting file address 21911. The calling telephone number 21909 indicates the telephone number of the telephone that the user made last time, and this information is used when the digital radio telephone is resent. The telephone directory address 21910 and the abbreviated dial setting file address 21911 indicate addresses on the actual data area in which the telephone directory information and the abbreviated dial setting file are stored, respectively.

[0613] The credit card list 21810 stores list information of credit cards registered by the user. In the credit card list 21810, for one credit card, credit card name 21912 (21919), credit card number 21913 (21920), expiration date 21914 (21921), credit card status 21915 (21922), image data Seven pieces of information are stored: address 21916 (21923), object data address 21917 (21924), and access time 21918 (21925).

[0614] The credit card status 21915 (21922) indicates whether the credit card is valid and the usage limit, and the image data address 21916 (21923) stores the image data of the credit card. Indicates the address on the physical data area 21812. The object data address 21917 (21924) indicates the address where the object data of the program of the credit card is stored, and the access time 21918 (21925) indicates the latest time when the user used the credit card. ..

[0615] The object data address 21917 (21924) stores a local address indicating an address on the physical data area 21812 or a remote address indicating an address on the user information server 402 of the service providing system 102. If the remote address is stored at the object data address 21917 (21924), when the user selects and tries to use the credit card, the personal credit terminal 100 receives the object data from the service providing system 102. Download to temporary area 21804 (remote access) and run the credit card program. Simply displaying the credit card displays the image data in the physical data area 21812 pointed to by the image data address 21916 (21923) and does not download the object data.

The address stored in this object data address 21917 (21924) is determined by the service providing system 102. During the data update process, the access times of each credit card are compared, and the local address is assigned to the credit card with the latest access time. However, if there is enough capacity in the physical data area 21812, the object data addresses of all credit cards may be local addresses.

[0617] In the usage history list 21811, for the use of one personal remote credit payment service, the request number 21926 (21930), the service code 21927 (21931), the usage time 21928 (21932), and the usage information address 21929 The four pieces of information (21933) are stored.

[0618] Request number 21926 (21930) is a number that uniquely indicates a transaction with a merchant (from the user's perspective), a number issued by the personal credit terminal 100 when generating a payment offer 608, a service code. 21927 (21931) is the code number indicating the type of credit card service used, the usage time 21928 (21932) is the time when the personal remote credit payment service was used, and the usage information address 21929 (21933) is the receipt. Alternatively, it indicates the address where the information indicating the usage content is stored.

[0619] The usage information address 21929 (21933) stores a local address indicating an address on the physical data area 21812 or a remote address indicating an address on the user information server 402 of the service providing system 102.

[0620] When the remote address is stored in the usage information address 21929 (21933), when the user accesses the usage history information, the personal credit terminal 100 transmits the usage information from the service providing system 102 to a temporary area. Download to 21804 (remote access) and display on LCD 203.

The address stored in the usage information address 21929 (21933) is also determined by the service providing system. During the data update process, the usage time of each usage information is compared, and a local address is assigned to the usage information with the latest usage time. However, if there is enough capacity in the physical data area 21812, all usage information addresses may be local addresses.

Next, the processing performed by the CPU 1500 will be described.

[0623] FIG. 51 is a conceptual diagram of a processing flow performed by the CPU 1500.

As shown in FIG. 51, the processing performed by the CPU 1500 includes two processing routines, a main routine 22109 and an interrupt processing routine 22122. The main routine is a processing routine that processes transmitted data and received data and controls other components, and the interrupt processing routine is a processing routine that detects the process (process) required by an external interrupt. is there. Therefore, the CPU 1500 normally performs the processing of the main routine. When the interrupt signal 1519 is asserted, the CPU 1500 jumps from the main routine to the interrupt processing routine, performs interrupt processing, and when the interrupt processing is completed, returns to the main routine and resumes processing of the original main routine. ..

[0625] The processes executed by the CPU 1500 in the main routine are 17 types of processes, and the CPU 1500 dynamically selects the processes and executes the selected processes in a time-division manner. Figure 50 (a) shows 17 types of processes executed in the main routine.

The 17 types of processes executed in the main routine are a process management process that selects and manages a process executed by the CPU, a power-on process that performs initial operation processing when the power switch is turned on, and a power switch. Power-off process that performs termination processing when is turned off, and GUI (Graphical User) in digital wireless telephone mode A digital wireless telephone process that performs Interface) processing and data processing (example: speed dial setting), GUI processing in credit card mode (example: display of usage history), and a credit card process that performs data processing. A personal information management process that performs GUI processing (example: display of personal information) and data processing (example: setting of user setting information) in the personal information management mode, a payment process that performs "payment" processing, and "cancellation" "Cancellation process to process", customer service call process to process "customer service call", inquiry call process to process "inquiry call", data update process to process data update, and compulsory A forced data update process that processes data updates, a data backup process that processes data backups, a remote access process that processes remote access, and a session establishment process that processes session establishment with the service providing system. , A digital wireless telephone communication process that controls digital wireless telephone communication, and an infrared communication process that controls infrared communication.

[0627] In each process, the corresponding program modules exist in the basic program area 21802 of ROM 1501 and RAM 1502, and the CPU 1500 executes those program modules to execute each process.

[0628] Further, in each process, information indicating the status (state) of the process exists in the work area 21803 on the RAM 1502 corresponding to each process, and the startup state (active or inactive) of the process exists. ), The execution state (running or idle), and the current processing step. Active in the running state indicates that the process is started as a process executed in the main routine, inactive indicates that the process is not started, and running in the running state indicates that the process is not started. Indicates that the process is running and "idle" indicates that it is in a suspended state.

[0629] In particular, the execution state of the digital wireless telephone process, the credit card process, and the personal information management process corresponds to the operation mode of the personal credit terminal, and when the execution state of the digital wireless telephone process is running, The personal credit terminal is in the digital wireless telephone mode, when the execution state of the credit card process is "running", in the credit card mode, and when the execution state of the personal information management process is "running", it is in the personal information management mode. The execution status of the digital radiotelephone process, credit card process, and personal information management process always indicates "running" for only one process and "idle" for the others. In the following, information indicating the status of this process will be referred to as process status.

[0630] In the main routine, the CPU 1500 repeatedly executes the process management process and the process registered in the process list in a time-division manner. The process list is a list showing running processes other than the process management process, and the process management process updates this process list. The process management process is a process that is always executed in the main routine, updates the process list and the process status of each process, and selects the process to be executed in the main routine.

[0631] The process management process updates the process list based on the process generation request message sent from the other processes of the main routine or the processing of the interrupt processing routine and the process status of each process (FIG. 50). See (b)).

[0632] FIG. 51 shows the flow of processing performed by the CPU 1500 as a generalized conceptual diagram. As shown in Fig. 50 (b), the process flow is shown when N processes (N is an integer of 0 or more) are registered in the process list 22000.

[0633] In FIG. 51, first, when the personal credit terminal 100 is reset, the process proceeds to step 22100, the CPU 1500 performs the reset process, and when the reset process is completed, the process proceeds to step 22101. In the reset process, the variables defined on the RAM 1502 are initialized, the internal registers are initialized, and the process management process is generated.

[0634] In step 22101, CPU 1500 executes the process management process, updates the process list and the process status of each process, and proceeds to step 22102 (when N 1) (when N = 0). , Return to step 22101).

[0635] (When N 1) In step 22102, it is checked whether the status of the first registered process in the process list 22000 is running or idle, and if it is idle, it is checked. (If N 2) Go to step 22104 (if N = 1, go back to step 22101), if running go to step 22103, run the first process, (N ) 2) Proceed to step 22104 (If N = 1, return to step 22101).

[0636] (When N 2) From step 22104 onward, the processing for the second to Nth processes in the process list is performed in the same procedure as the processing for the first process in the process list (step 22102, step 22103). Perform sequentially. When the CPU1500 finishes the process for the Nth process (step 22106, step 22107), it returns to step 22101. That is, the CPU 1500 repeats the process corresponding to step 22101 and steps 22102 to 22107. However, the content of the process corresponding to steps 22102 to 22107 changes depending on the process management process of step 22101.

[0637] If the interrupt signal 1519 is asserted during the execution of the processing of the main routine 22109, the CPU 1500 jumps to the interrupt routine 22122. In the interrupt processing routine 22122, the CPU 1500 first reads the interrupt register (INT) in step 22110 and copies it to the word interrupt on the RAM (work area). At this time, the interrupt register (INT) read by the CPU is echo-reset, and the interrupt signal 1519 is also negated.

Next, in step 22111, it is checked from the value of bit 28 of interrupt whether or not it is an incoming call interrupt, and if it is not an incoming call interrupt (interrupt (bit28) = 0), the process proceeds to step 22113 and the incoming call interrupt is performed. In the case (interrupt (bit28) = 1), the process proceeds to step 22112, the generation request message of the digital wireless telephone process is sent to the process management process, and the process proceeds to step 22113.

[0639] In step 22113, it is checked from the value of bit 26 of interrupt whether or not it is an update interrupt, and if it is not an update interrupt (interrupt (bit26) = 0), the process proceeds to step 22115, and if it is an update interrupt (interrupt). (bit26) = 1) proceeds to step 22114, sends a data update process generation request message to the process management process, and proceeds to step 22115.

[0640] In step 22115, it is checked from the value of bit 25 of interrupt whether or not it is a backup interrupt, and if it is not a backup interrupt (interrupt (bit25) = 0), the process proceeds to step 22117, and if it is a backup interrupt (interrupt). (bit25) = 1) proceeds to step 22116, sends a backup process generation request message to the process management process, and proceeds to step 22117.

[0641] In step 22117, it is checked from the value of bit 24 of interrupt whether or not it is a key interrupt, and if it is not a key interrupt (interrupt (bit24) = 0), the interrupt process is terminated and the original main routine is used. Returning to the process, in the case of key interrupt (interrupt (bit24) = 1), the process proceeds to step 22118.

[0642] In step 22118, the value of the power bit (bit16) of interrupt is checked, and if it is 0, the interrupt processing is terminated and the process returns to the original main routine processing. If it is 1, the power supply is returned. It is determined that the switch has been operated, and the process proceeds to step 22119.

[0643] In step 22119, the value of the power display bit (bit31) of interrupt is examined, and if it is 0, it is determined that the power-off operation has been performed, and the process proceeds to step 22121. It is determined that the power-on operation has been performed, and the process proceeds to step 22120.

[0644] In step 22120, a power-on process generation request message is sent to the process management process to end the interrupt process and return to the original main routine process.

[0645] In step 22121, a power-off process generation request message is sent to the process management process to end the interrupt process and return to the original main routine process.

[0646] The CPU 1500 that has returned from the interrupt processing routine 22122 to the main routine 22109 resumes the processing of the main routine from the processing step immediately before jumping to the interrupt processing routine. In the interrupt processing routine, the process creation request message sent to the process management process is evaluated and requested in the process of the process management process in step 22101, which is executed first after returning from the interrupt processing routine to the main routine. The process is registered in the process list. Then, the requested process is executed in the subsequent processing of the main routine.

[0647] For example, when the personal credit terminal 100 is reset, nothing is registered in the process list immediately after the reset. Therefore, the CPU 1500 repeats the process management process generated by the reset process 22100 in the main routine (see Fig. 52 (a)). On the other hand, upon reset, the control logic unit 1508 sets 1 to bit 24 (key interrupt) and bit 16 (power supply) of the interrupt register (INT) to assert the interrupt signal 1519. At this time, if the power switch 209 is in the on state, the CPU 1500 executes the power-on process in the main routine after processing the interrupt processing routine by this interrupt, and if the power switch 209 is in the off state. The CPU1500 executes the power-off process in the main routine through the processing of the interrupt processing routine by this interrupt.

FIG. 52 (c) shows a processing flow when the power switch is turned off or when the power switch is in the off state at the time of reset. In the power-off process, the LCD display is erased, the key operation control register (KEYCTL) 21612 is accessed, and only the power switch 209 is set to be valid. When the processing of the power-off process is completed, the CPU 1500 shifts to the Holt state and stops the processing of the main routine. The CPU1500 returns from the halt state to the normal operating state only by interrupting by turning on the power switch, update interrupting, and battery interrupting, and after the interrupt processing routine processing, the main routine processing is performed. resume.

FIG. 52 (b) shows a processing flow when the power switch is turned on or when the power switch is in the on state at the time of reset. In the power-on process, the display of the LCD is initialized, the variables defined on RAM1502 and the internal registers are set, and the generation request message of the digital wireless telephone process, credit card process, and personal information management process is processed. Performs initial operation processing to be sent to the management process. The generation request message of these processes registers the digital wireless telephone process, the credit card process, and the personal information management process in the process list, and executes these processes in the main routine. However, since the execution state of the process status of each process is saved, the operation mode at the time of power-on becomes the operation mode at the time when the power switch was turned off last time.

[0650] FIG. 53 shows that after the processing of the power-on process is completed, or the personal credit terminal has "payment", "cancellation", "customer service call", "inquiry call", "data update", "remote". It shows the processing flow of the CPU in the steady state when processing such as "access" is not performed. At this time, three processes, the digital wireless telephone process, the credit card process, and the personal information management process, are registered in the process list, but the execution status of the process status is only one "running". , The operation mode of the personal credit terminal is the operation mode corresponding to the process whose execution state of the process status indicates "running".

[0651] The key operation performed by the user is copied to the word interrupt on the RAM 1502 as an interrupt factor of the interrupt register 21604 by the processing of the interrupt processing routine, and is a process corresponding to the operation mode of the personal credit terminal (digital). It is interpreted by a wireless telephone process, a credit card process, or a personal information management process), and processing corresponding to the user's operation is performed. Then, when the payment operation 607, the cancel operation 904, the inquiry call operation 1213, etc. are performed, or when the customer service call 1203 is received, the payment process, the cancellation process, the inquiry call process, the customer service call process, etc., respectively. Send a message to the process management process requesting the creation of the corresponding process.

[0652] For example, FIG. 54 shows a processing flow of the CPU 1500 at the time of processing payment. When the user performs the payment operation, the payment process, the session establishment process, the digital radiotelephone communication process, and the infrared communication process are started in addition to the normal process.

[0653] Next, the internal configuration of the credit card payment terminal 300 will be described.

[0654] FIG. 55 (a) is a block configuration diagram of the credit card payment terminal 300.

[0655] The credit settlement terminal 300 is a CPU that processes transmission data and reception data according to a program stored in ROM (Read Only Memory) 22501, and controls other components via bus 22259. Central Processing Unit) 22500, data processed by CPU 22500, RAM (Random Access Memory) 22502 and hard disk 22503 that store data processed by CPU 22500, terminal ID, telephone number, and merchant of credit payment terminal. ID, private key and public key, service provider ID of the service provider system, telephone number (the telephone number of the service provider system is digitally signed by the service provider), public key of the service provider. EEPROM (Electric Erasable Programmable Read Only) Memory) 22504, LCD controller 22505 that controls the operation of LCD302 according to the control of CPU22500 and displays the image set by CPU22500 on the LCD, and encryption that performs data encryption processing and decryption processing under the control of CPU22500. A processing processor 22506, a data codec 22507 that encodes transmitted data and decodes received data under the control of the CPU 22500, a serial port 22509 that connects to an infrared light receiving / emitting module 301, and bidirectional parallel data and serial data. A series-parallel conversion circuit 22508 that converts data, and a key operation control unit 22511 that detects the switch operation of the mode switch 304, hook switch 305, function switch 306, ten key switch 307, execution switch 308, or power switch 209 by the merchant. , Speaker 22512, drive the receiver of the handset 303, amplify the analog voice signal input from the microphone of the handset 303, and supply it to the voice codec 22514. A voice codec 22514 that performs conversion and decoding of digital voice data into an analog voice signal 22543, transmission data generation by multiplexing digital voice data and data communication data, and digital voice data from the multiplexed reception data. RS-, which is an interface circuit of the RS-232C cable 313 that connects the channel codec 22515, which extracts data and data, the digital communication adapter 22516, which is a communication adapter with the digital telephone communication line 110, and the cache register 311. 232C interface 22517, key operation control unit 22513, channel codec 22515, processing of interrupt signals input from RS-232C interface 22517, and CPU22500, key operation control unit 22513, voice processing unit 22513, voice codec 22514, channelIt is equipped with a control logic unit 22510 that acts as an interface when accessing the registers inside the codec.

[0656] The cryptographic processing processor 22506 has functions of encryption and decryption of the private key method and encryption and decryption of the public key method, and is set by the CPU 22500 with the encryption method and the key set by the CPU 22500. The data is encrypted or decrypted. The CPU 22500 uses the encryption / decryption function of the encryption processing processor 22506 to perform digital signature processing or sealing processing of the message, and decryption processing or decryption processing of the encryption of the sealed message. Performs digital signature verification processing for digitally signed messages.

[0657] The data codec 22507 encodes the transmitted data and decodes the received data under the control of the CPU 22500. In this case, the coding means the process of generating the data actually transmitted including the communication control information and the error correction information, and the decoding means the error correction processing of the received data and extra. It means a process of removing various communication control information and generating data originally intended to be transmitted by the sender. The data codec 22507 has the functions of data coding and decoding in digital telephone data communication and data coding and decoding in infrared communication, and is set in the CPU with respect to the data set in the CPU. Performs coding processing and decoding processing.

[0658] For example, when a message subjected to digital signature processing and sealing processing is transmitted by digital telephone communication, the CPU 22500 uses the encryption processing processor 22506 to perform digital signature processing and sealing processing of the message. Then, using the data codec 22507, the message subjected to the digital signature processing and the sealing process is encoded into the data format of the data communication of the digital telephone, and it is encoded via the control logic unit 22510. , Send to channel codec 22515.

[0659] Conversely, when a message subjected to digital signature processing and sealing processing is received by digital telephone communication, the CPU 22500 receives the received message via the control logic unit 22510, and the channel codec 22515. Read from, use the data codec 22507 to decrypt the received message, and then use the encryption processor 22506 to decrypt the encrypted message and verify the digital signature applied to the message. And do.

Similarly, when transmitting a message subjected to digital signature processing and sealing processing by infrared communication, the CPU 22500 uses the encryption processing processor 22506 to perform digital signature processing and sealing processing of the message. Then, using the data codec 22507, the message subjected to the digital signature processing and the sealing processing is encoded into the data format of infrared communication and sent to the series-parallel conversion circuit 22560.

[0661] On the contrary, when the message subjected to the digital signature processing and the sealing process is received by infrared communication, the CPU 22500 reads the received message from the series-parallel conversion circuit 22560 and reads the data codec 22507. The received message is decrypted, and the encryption processing processor 22506 is used to decrypt the code of the sealed message and to verify the digital signature applied to the message.

[0662] As shown in FIG. 55 (b), the series-parallel conversion circuit 22560 and the infrared light receiving / receiving module 301 connected via the serial port 22509 and the serial cable 310 are serial interfaces with the credit payment terminal. The port 22555 and the modulation / demodulation circuit 22556 that modulates the digital signal 22556 input from the series-parallel conversion circuit into a signal that is actually transmitted as infrared rays, or demolishes the received analog signal 22561 into a serial digital signal 22559. It is provided with an infrared light receiving / receiving unit 22557 that converts the signal 22560 modulated by the modulation / demodulation circuit 22556 into infrared light and emits light, or converts the received infrared ray into an analog signal 22651.

[0663] In the key operation control unit 22511, when the merchant presses any of the mode switch 304, the hook switch 305, the function switch 306, the numeric keypad switch 307, the execution switch 308, and the power switch 209, the key operation control unit 22511 Asserts to CPU22500 an interrupt signal 22039 that prompts processing corresponding to the switch operation. Further, as shown in FIG. 56, the key operation control unit 22511 includes a key operation control register (KEYCTL) 22610 for setting the enable / disable of each switch. The CPU22500 accesses this key operation control register (KEYCTL) 22610 to enable / disable each switch.

[0664] As shown in FIG. 56, the voice processing unit 22513 includes a voice processing unit control register (SCTL) 22609 that controls the voice processing operation. The CPU 22500 accesses the voice processing unit control register (SCTL) 22609 to control the operation of the voice processing unit 22513. For example, when a digital telephone incoming call request is received, the CPU 22500 accesses the voice processing unit control register (SCTL) 22609 and sets to output the digital telephone ringtone. As a result, the voice processing unit 22513 drives the speaker 22512 to output the ringtone of the digital telephone. However, if the call is received from the service providing system 102, the ringtone is not output and the CPU 22500 starts the process of establishing a session with the service providing system.

The audio codec 22514 encodes the analog audio signal 22544 input from the audio processing unit 22513 into digital audio data and decodes the digital audio data read from the channel codec 22515 into an analog audio signal 22543. .. The analog audio signal 22543 is supplied to the audio processing unit 22513, and the audio processing unit 22513 amplifies the analog audio signal 22543 and drives the receiver of the receiver 303, so that audio is output from the receiver. The digital voice data generated by the coding is supplied to the channel codec 22515 and converted into transmission data.

[0666] Further, the voice codec 22514 includes a voice data encryption key register (CRYPT) 22611 that stores an encryption key of a private key method used for encrypting and decrypting voice data, and this voice data encryption key register (CRYPT). ) When the voice data encryption key is set by CPU22500 in 22611, the voice codec 22514 encodes the analog voice signal 22544 into digital voice data and at the same time encrypts the digital voice data, and the digital voice data is analog. At the same time as decoding the audio signal 22543, the encryption of digital audio data is decrypted.

[0667] Two types of data are input to the channel codec 22515 as data to be transmitted. One is digital audio data input as a digital audio signal 22547 from the audio codec 22514, and the other is data communication data input as a digital signal 22551 from the CPU via the control logic unit 22510.

[0668] The channel codec 22515 adds identification information of digital voice data and data communication data to each data as header information, and digitally communicates a digital signal 22548 in which the digital voice data and the data communication data are multiplexed. Supply to adapter 22516.

On the contrary, the channel codec 22515 first collates the terminal ID with the digital signal 22548 input from the digital communication adapter 22516, and then, from the data header information, digital audio data or data communication data. As a digital audio signal 22547 and a digital signal 22551, they are supplied to the audio codec 22512 and the control logic unit 22510, respectively. Further, the channel codec 22515 asserts the interrupt signal 22549 when a digital telephone is received and when the data communication data is received, and when the digital voice data is received, the control signal 22545 is set to a low level. The interrupt signal 22549 is an interrupt signal that prompts the CPU 22500 to process an incoming digital telephone call and process data communication data, and the control signal 22545 causes the audio codec 22514 to process the received digital audio data. It is a low-active control signal that prompts.

[0670] In order to perform such an operation, the channel codec 22515 has an ID register (ID) 22603 for storing the terminal ID and a channel codec control register (CHCTL) for controlling the operation of the channel coden 22515, as shown in FIG. From the CPU 22500 via the 22604, the voice transmission buffer 22605 that stores the digital voice data input from the voice codec 22514, the voice reception buffer 22606 that stores the digital voice data extracted from the received data, and the control logic unit 22510. It includes a data transmission buffer 22607 for storing input data communication data and a data reception buffer 22608 for storing data communication data extracted from the received data.

[0671] The control signal 22546 is a control signal indicating the operation of writing and reading from the channel codec 22515 to the voice transmission buffer 22605 and the voice reception buffer 22606 by the voice codec 22514, and the voice codec 22514 receives the control signal 22546. The digital audio data is written to the audio transmission buffer 22605 at a low level, the control signal 22546 is set to a high level, and the digital audio data is read from the audio reception buffer 22606.

[0672] The control signal 22550 is a control signal indicating the operation of writing and reading to the data transmission buffer 22607 and the data reception buffer 22608 by the CPU 22500 via the control logic unit 22510 in the channel codec 22515. The data communication data is written to the data transmission buffer 22607 at the low level, the control signal 22550 is set to the high level, and the data communication data is read from the data reception buffer 22608.

[0673] The digital communication adapter 22516 encodes the digital signal 22548 into the format of digital telephone communication and outputs it to the digital telephone communication line 110. Conversely, the digital communication adapter 22516 decodes the signal received from the digital telephone communication line 110 and supplies the digital signal 22548 to the channel codec 22515.

[0674] The RS-232C interface 22517 is an interface circuit for connecting the RS-232C cable 313, and the credit card payment terminal communicates with the cache register 311 via the RS-232C interface 22517. The RS-232C interface 22517 asserts the interrupt signal 22552 when it receives data from cache register 311. The interrupt signal 22552 is an interrupt signal that prompts the CPU 22500 to process data communication with the cache register 311 via the RS-232C interface 22517.

As shown in FIG. 56, the control logic unit 22510 has three built-in registers, a clock counter (CLOCKC) 22600, an update time register (UPTIME) 22601, and an interrupt register (INT) 22602. To do.

The clock counter is a counter that counts the current time, and the update time register is a process in which the credit settlement terminal 300 communicates with the service providing system to update the data on the RAM 22502 and the hard disk 22503 (data update process). The register that stores the time to perform the operation, the interrupt register, is a register that indicates the cause of the interruption to the CPU 22500.

[0677] The control logic unit 22510 determines that the value of the clock counter 22600 matches the value of the update time register 22601 and that any of the interrupt signals 22039,22549,22552 is asserted. The interrupt factor is set in the interrupt register (INT) 22602, the interrupt signal 22518 is asserted, and the CPU is prompted to perform interrupt processing. The CPU22500 reads the interrupt register in the interrupt process and performs the process according to the interrupt factor.

Each bit field of this interrupt register (INT) is meant as shown in FIG. 57 (a). This meaning is the same as that described with reference to FIG. 27 (b) in the first embodiment.

Next, the data stored in the RAM 22502 will be described.

[0680] FIG. 58 is a schematic diagram of a RAM map of data stored in RAM 22502.

[0681] The RAM 22502 has five areas: a basic program area 22800, a service data area 22801, a merchant area 22802, a work area 22803, and a temporary area 22804. The basic program area 22800 stores upgraded modules of programs stored in ROM 22501, patch programs, and additional programs. The merchant area 22802 is an area that can be freely used by the merchant, the work 22803 area is a work area used by the CPU 100 to execute a program, and the temporary area 22804 is an area that temporarily stores the information received by the credit card payment terminal. Is.

[0682] The service data area 22801 is an area for storing ID information of a personal remote credit payment service, handling credit card information, and history information, and the data in this area is managed by the service providing system. The service data area 22801 further has six areas: data management information 22805, merchant information 22806, merchant setting information 22807, telephone information 22808, credit card list 22809, and sales history list 22810.

[0683] The data management information 22805 is an area for storing management information of information stored in the service data area 22801, and the merchant information 22806 is an area for storing information such as the name of the merchant and the contents of the contract with the service provider. , Merchant setting information 22807 is an area for storing merchant setting information related to personal remote credit payment service, telephone information 22808 is an area for storing information related to digital phones, and credit card list 22809 is handled by merchants. The sales history list 22810, which is an area for storing the list information of credit cards that can be used, is an area for storing the history information of sales in the personal remote credit payment service.

Next, the information stored in the service data area 22801 will be described in detail.

[0685] FIG. 59 is a schematic diagram showing in detail the relationship of the information stored in the service data area 22801.

[0686] Data management information 22805 includes update date and time 22900, next update date and time 22901, terminal status 22902, merchant information address 22903, merchant setting information address 22904, telephone information address 22905, credit card list address 22906, sales history list. It consists of eight pieces of information at address 22907.

[0687] The update date and time 22900 indicates the date and time when the service providing system 102 last updated the data of the RAM 22502 and the hard disk 22503, and the next update date and time 22901 is the data of the service data area 22801 by the next service providing system 102. Indicates the scheduled date and time of the update. The credit card payment terminal automatically starts the data update process at the set time of the next update date and time 22901.

The value of this next update date and time 21901 is set in the update time register 21603, and when the time of the next update date and time 21901 comes, the credit card payment terminal 300 starts the data update process. The data update process is a process in which the service providing system 102 updates the data on the RAM and the hard disk, and is usually performed every day during a time when the communication traffic is relatively uncrowded (eg, midnight). ..

[0689] The terminal status 22902 indicates the status of the credit payment terminal, and the merchant information address 22903, the merchant setting information address 22904, the telephone information address 22905, the credit card list address 22906, and the sales history list address 22907 are respectively. Indicates the start address of the area where the merchant information 22806, the merchant setting information 22807, the telephone information 22808, the credit card list 22809, and the usage history list 22810 are stored.

[0690] The telephone information 22808 is further composed of three pieces of information: a calling telephone number 22908, a telephone directory address 22909, and a shortened dial setting file address 22910. The outgoing phone number 22908 indicates the phone number of the last call made by the merchant, and this information is used when resending the digital radiotelephone. The telephone directory address 22909 and the abbreviated dial setting file address 22910 indicate addresses on the hard disk 22503 in which the telephone directory information and the abbreviated dial setting file are stored, respectively.

[0691] Credit card list 22809 stores list information of credit cards that can be handled by merchants. In the credit card list 22809, two pieces of information, a credit card name 22911 (22913,22915) and a service code list address 22912 (22914,22916), are stored for one credit card. The credit card name 22911 (22913,22915) indicates the name of the credit card that the merchant can handle, and the service code list address 22912 (22914,22916) is one of the services provided by that credit card. Indicates the address on hard disk 22503 that contains a list of service codes that indicate the types of services that can be handled by. The service code list is a list of service codes that merchants can handle and payment option codes.

[0692] The sales history list 22810 is an area for storing sales history information in the personal remote credit payment service. In the sales history list 22810, for the sale of one personal remote credit payment service, transaction number 22917 (22921), service code 22918 (22922), sales time 22919 (22923), sales information address 22920 (22924). Contains four pieces of information.

[0693] The transaction number 22917 (22921) is a number uniquely indicating the transaction with the user, and the number issued by the credit card settlement terminal when generating the payment offer response 609, the service code 22918 (22922) is the user. The code number indicating the type of credit card service used by the company, the sales time 22919 (22923) is the time when the product was sold by the personal remote credit payment service, and the sales information address 22920 (22924) stores the payment completion notification. Indicates the address.

[0694] The sales information address 22920 (22924) stores a local address indicating an address on the hard disk 22503 or a remote address indicating an address on the merchant information server 403 of the service providing system 102. When the remote address is stored in the sales information address 22920 (22924), when the merchant accesses the sales history information, the credit payment terminal downloads the sales information from the service providing system to the temporary area and displays the LCD. Display on.

The address stored in the sales information address 22920 (22924) is determined by the service providing system. During the data update process, the sales time of each sales information is compared, and a local address is assigned to the sales information with the latest sales time. However, if the hard disk 22503 has sufficient capacity, all sales information addresses may be local addresses.

Next, the processing performed by the CPU 22500 will be described.

[0697] FIG. 61 is a conceptual diagram of a processing flow performed by the CPU 22500.

As shown in FIG. 61, the processing performed by the CPU 22500 includes two processing routines, a main routine 23109 and an interrupt processing routine 23122. The main routine is a processing routine that processes the transmitted data and the received data and controls other components, and the interrupt processing routine is a processing routine that detects the process (process) required by the external interrupt. Is. Therefore, the CPU22500 normally performs the processing of the main routine. When the interrupt signal 22518 is asserted, the CPU 22500 jumps from the main routine to the interrupt processing routine, performs interrupt processing, and when the interrupt processing is completed, returns to the main routine and resumes processing of the original main routine. ..

[0699] The processes executed by the CPU 22500 in the main routine are 17 types of processes, and the CPU 22500 dynamically selects the processes and executes the selected processes in a time-division manner. Figure 60 (a) shows the 17 types of processes executed in the main routine.

The 17 types of processes executed in the main routine are a process management process that selects and manages a process executed by the CPU, a power-on process that performs initial operation processing when the power switch is turned on, and a power switch. Power-off process that performs termination processing when is turned off, and GUI (Graphical User) in digital phone mode Interface) processing and data processing (example: speed dial setting) digital telephone process, GUI processing in credit payment mode (example: display of sales history), credit payment process that performs data processing, and merchant A merchant information management process that performs GUI processing (example: display of merchant information) and data processing (example: setting of merchant setting information) in the information management mode, a payment process that performs "payment" processing, and "cancellation" Cancellation process that processes "customer service call", customer service call process that processes "customer service call", inquiry call process that processes "inquiry call", data update process that processes data update, and forced data A forced data update process that processes updates, a remote access process that processes remote access, a session establishment process that processes session establishment with the service providing system, and a digital telephone communication process that controls digital telephone communication. , An infrared communication process that controls infrared communication, and an external interface communication process that controls data communication via the RS-232C interface.

[0701] Each process has a corresponding program module in ROM22501 and the basic program area 21802 of RAM22502, and CPU22500 executes those program modules to execute each process. ..

[0702] Further, in each process, information indicating the status (status) of the process exists in the work area 2503 on the RAM 22502 corresponding to each process, and the startup state (active or inactive) of the process exists. ), The execution state (running or idle), and the current processing step. Active in the running state indicates that the process is started as a process executed in the main routine, inactive indicates that the process is not started, and running in the running state indicates that the process is not started. Indicates that the process is running and "idle" indicates that it is in a suspended state.

[0703] In particular, the execution state of the digital telephone process, the credit payment process, and the merchant information management process corresponds to the operation mode of the credit payment terminal, and when the execution state of the digital telephone process is running, the credit payment terminal. Is in the digital telephone mode, when the execution state of the credit settlement process is "running", in the credit settlement mode, when the execution state of the merchant information management process is "running", it is in the merchant information management mode. The execution status of the digital telephone process, credit card payment process, and merchant information management process always indicates "running" for only one process and "idle" for the others. In the following, information indicating the status of this process will be referred to as process status.

[0704] In the main routine, the CPU 22500 repeatedly executes the process management process and the process registered in the process list in a time-division manner. The process list is a list showing running processes other than the process management process, and the process management process updates this process list. The process management process is a process that is always executed in the main routine, updates the process list and the process status of each process, and selects the process to be executed in the main routine.

[0705] The process management process updates the process list based on the process generation request message sent from the other processes of the main routine or the processing of the interrupt processing routine and the process status of each process (FIG. 60). See (b)).

[0706] Fig. 61 shows the flow of processing performed by the CPU 22500 as a generalized conceptual diagram. As shown in Fig. 60 (b), the processing flow is shown when N processes (N is an integer of 0 or more) are registered in the process list 23000.

[0707] In FIG. 61, first, when the credit payment terminal 300 is reset, the process proceeds to step 23100, and when the CPU 22500 performs the reset process and completes the reset process, the process proceeds to step 23101. In the reset process, the variables defined on the RAM 22502 are initialized, the internal registers are initialized, and the process management process is generated.

[0708] In step 23101, the CPU 22500 executes the process management process, updates the process list and the process status of each process, and proceeds to step 23102 (when N 1) (when N = 0). , Return to step 23101).

[0709] (When N 1) In step 23102, it is checked whether the status of the first registered process in the process list 23000 is running or idle, and if it is idle, it is checked. (If N 2) Go to step 23104 (if N = 1, go back to step 23101), if running go to step 23103, run the first process, (N ) 2) Proceed to step 23104 (If N = 1, return to step 23101).

[0710] (When N 2) From step 23104 onward, the processing for the second to Nth processes in the process list is performed in the same procedure as the processing for the first process in the process list (step 23102, step 23103). Perform sequentially. When the CPU 22500 finishes the process for the Nth process (step 23106, step 23107), the CPU 22500 returns to step 23101. That is, the CPU 22500 repeats the process corresponding to step 23101 and steps 23102 to 23107. However, the content of the process corresponding to steps 23102 to 23107 changes depending on the process management process of step 23101.

[0711] If the interrupt signal 22518 is asserted during the execution of the processing of the main routine 23109, the CPU 22500 jumps to the interrupt routine 23122. In the interrupt processing routine 23122, the CPU 22500 first reads the interrupt register (INT) in step 23110 and copies it to the word interrupt on the RAM (work area). At this time, the interrupt register (INT) read by the CPU is echo-reset, and the interrupt signal 22518 is also negated.

Next, in step 23111, it is checked from the value of bit 28 of interrupt whether or not it is an incoming call interrupt, and if it is not an incoming call interrupt (interrupt (bit28) = 0), the process proceeds to step 23113 and the incoming call interrupt is performed. In the case (interrupt (bit28) = 1), the process proceeds to step 23112, the generation request message of the digital telephone process is sent to the process management process, and the process proceeds to step 23113.

[0713] In step 23113, it is checked from the value of bit 26 of interrupt whether or not it is an update interrupt, and if it is not an update interrupt (interrupt (bit26) = 0), the process proceeds to step 23115, and if it is an update interrupt (interrupt). (bit26) = 1) proceeds to step 23114, sends a data update process generation request message to the process management process, and proceeds to step 23115.

[0714] In step 23115, it is checked from the value of bit 25 of interrupt whether or not it is an external IF interrupt, and if it is not an external IF interrupt (interrupt (bit25) = 0), the process proceeds to step 23117 and the external IF interrupt is performed. In the case (interrupt (bit25) = 1), the process proceeds to step 23116, the generation request message of the external IF communication process is sent to the process management process, and the process proceeds to step 23117.

[0715] In step 23117, it is checked from the value of bit 24 of interrupt whether or not it is a key interrupt, and if it is not a key interrupt (interrupt (bit24) = 0), the interrupt process is terminated and the original main routine is used. Returning to the process, in the case of key interrupt (interrupt (bit24) = 1), the process proceeds to step 23118.

[0716] In step 23118, the value of the "power supply" bit (bit16) of interrupt is checked, and if it is 0, the interrupt processing is terminated and the process returns to the original main routine processing. If it is 1, the power supply is returned. It is determined that the switch has been operated, and the process proceeds to step 23119.

[0717] In step 23119, the value of the "power display" bit (bit31) of interrupt is examined, and if it is 0, it is determined that the power-off operation has been performed, and the process proceeds to step 23121. If it is 1, it is determined that the power-off operation has been performed. It is determined that the power-on operation has been performed, and the process proceeds to step 23120.

[0718] In step 23120, a power-on process generation request message is sent to the process management process to end the interrupt process and return to the original main routine process.

[0719] In step 23121, a power-off process generation request message is sent to the process management process to end the interrupt process and return to the original main routine process.

The CPU 22500 that has returned from the interrupt processing routine 23122 to the main routine 23109 resumes the processing of the main routine from the processing step immediately before jumping to the interrupt processing routine. In the interrupt processing routine, the process creation request message sent to the process management process is evaluated and requested in the process of the process management process in step 23101, which is executed first after returning from the interrupt processing routine to the main routine. The process is registered in the process list. Then, the requested process is executed in the subsequent processing of the main routine.

[0721] For example, when the credit card payment terminal 300 is reset, nothing is registered in the process list immediately after the reset. Therefore, the CPU 22500 repeats the process management process generated by the reset process 23100 in the main routine (see Fig. 52 (a)). On the other hand, upon reset, the control logic unit 22510 sets 1 to bit 24 (key interrupt) and bit 16 (power supply) of the interrupt register (INT) to assert the interrupt signal 22518. At this time, if the power switch 309 is on, the CPU 22500 executes the power-on process in the main routine after processing the interrupt processing routine by this interrupt, and if the power switch 309 is in the off state. The CPU22500 executes the power-off process in the main routine through the processing of the interrupt processing routine by this interrupt.

FIG. 52 (c) shows a processing flow when the power switch is turned off or when the power switch is in the off state at the time of reset. In the power-off process, termination processing such as erasing the LCD display and accessing the key operation control register (KEYCTL) 22610 to enable only the power switch 309 is performed. When the processing of the power-off process is completed, the CPU22500 shifts to the Holt state and stops the processing of the main routine. The CPU22500 returns from the halt state to the normal operating state only by interrupting by turning on the power switch or by updating interrupting, and resumes the processing of the main routine after the processing of the interrupt processing routine.

FIG. 52 (b) shows a processing flow when the power switch is turned on or when the power switch is in the on state at the time of reset. In the power-on process, the display of the LCD is initialized, the variables defined on RAM22502 and the internal registers are set, and the generation request message of the digital telephone process, the credit settlement process, and the merchant information management process is processed. Performs initial operation processing to be sent to the management process. The generation request message of these processes registers the digital telephone process, the credit settlement process, and the merchant information management process in the process list, and executes these processes in the main routine. However, since the execution state of the process status of each process is saved, the operation mode at the time of power-on becomes the operation mode at the time when the power switch was turned off last time.

[0724] FIG. 62 shows that after the processing of the power-on process is completed, or the credit card payment terminal is "payment", "cancellation", "customer service call", "inquiry call", "data update", "remote access". It shows the processing flow of the CPU in the steady state when processing such as "" is not performed. At this time, three processes, the digital telephone process, the credit payment process, and the merchant information management process, are registered in the process list, but the execution status of the process status is only one, "running". The operation mode of the credit settlement terminal is the operation mode corresponding to the process in which the execution state of the process status indicates running.

[0725] The key operation performed by the merchant is copied to the word interrupt on the RAM 22502 as an interrupt factor of the interrupt register 22602 by the processing of the interrupt processing routine, and the process corresponding to the operation mode of the credit settlement terminal (digital telephone). It is interpreted by a process, a credit settlement process, or a merchant information management process), and processing corresponding to the operation of the merchant is performed. Then, when the credit settlement operation 604, the cancellation operation 901, the customer service call operation 1200, etc. are performed, or when the inquiry call 1216 is received, the payment process, the cancellation process, the customer service call process, and the inquiry call are performed, respectively. Send a message to the process management process requesting the creation of the corresponding process, such as a process.

[0726] For example, FIG. 63 shows a processing flow of the CPU 22500 at the time of processing payment. When the merchant performs the credit card payment operation, the payment process, the session establishment process, the digital telephone communication process, and the infrared communication process are started in addition to the normal process.

Next, the digital signature processing and the sealing process will be described. Digital signature processing when the personal credit terminal generates a message to be sent to the credit payment terminal and the service providing system, or when the credit payment terminal generates a message to be sent to the personal credit terminal and the service providing system. The procedure of the digital signature processing is shown in FIGS. 64 (a) and 64 (b), and the procedure of the sealing process is shown in FIGS. 65 (a) and 65 (b). In addition, the procedure for decrypting the sealed message is shown in FIGS. 66 (a) and 66 (b), and the procedure for verifying the digital signature of the digitally signed message is shown in FIGS. 67 (a) and 67 (b). ing. These procedures are substantially the same as those described with reference to FIGS. 20, 21, 22, and 23 in the first embodiment.

Next, processing in the service providing system 102 will be described.

[0729] The service providing system 102 communicates with the personal credit terminal 100, the credit card payment terminal 101, and the payment system 103, respectively, and acts as an intermediary between the user, the merchant, and the payment processing institution to act as an intermediary between the user and the payment processing institution. , A system that provides personal remote credit card payment services to merchants.

FIG. 68 shows the processing architecture in the service providing system 102.

[0731] The service providing system 102 provides a personal remote credit payment service to a user process (UP: User Process) 23802, a merchant process (MP: Merchant Process) 23802, and a payment processing institution process generated on the service server 400. (TPP: Transaction Processor Process) 23804, Service Director Process (SDP) 23801, and Service Manager Process (SMP: Service Manager) Process) Provided by the cooperative processing of 5 types of processes of 23800. In FIG. 68, the user process 23802 is a process that provides a one-to-one correspondence with the personal credit terminal 100 and serves as an interface for communication between the service providing system 102 and the personal credit terminal 100, and the merchant process 23803 is a process. The payment processing institution process 23804, which is a process that serves as an interface for communication between the service providing system 102 and the credit payment terminal 300, corresponds to the payment system 103, and is a service providing system. The service director process 23801, which is the interface for communication between 102 and the payment system 103, communicates with the user process 23802, the merchant process 23803, and the payment processing institution process 23804, respectively, to produce a personal remote credit payment service. Interface, service manager process 23800 is a process that manages user processes, merchant processes, payment processing agency processes, and service director processes on the service providing system 102. The meaning of the expression "directing a personal remote credit card payment service" will be explained in detail later.

[0732] FIGS. 69 and 70 show a list of these five types of processes.

[0733] The service providing system 102 may communicate with a plurality of personal credit terminals and a plurality of credit payment terminals at the same time, and may communicate with a plurality of personal remote credit payment services at the same time. Processing may be performed, or communication with a plurality of payment systems may be performed at the same time to process a plurality of personal remote credit payment services. Therefore, the user process, the merchant process, the payment processing institution process, and the service director process may each have a plurality of processes existing on the service server 400 at the same time. These user processes, merchant processes, payment processing agency processes, and service director processes are created, erased, and managed by the service manager process.

[0734] When the service server 400 is composed of a plurality of computers, the user process, the merchant process, the payment processing institution process, and the service director process are arranged so that the processing load of each process is distributed. In addition, it is distributed and generated on multiple computers.

[0735] Further, a set of processes that collaborate to provide one personal remote credit payment service is determined by a service manager process, and the set of processes is a user process, a merchant process, and a payment process. It consists of one or more of the institutional processes and one service director process. In the following, a set of processes that perform this cooperative processing will be referred to as a process group.

First, the user process 23802 will be described.

[0737] The user process controls communication with the personal credit terminal 100, authenticates the user, encrypts the data transmitted to the personal credit terminal 100, decrypts the data received from the personal credit terminal 100, and personalizes the data. This is a process of checking the validity of the data received from the credit terminal 100, and further performing remote access, data update, and data backup processing with the personal credit terminal 100.

The user process 23802 is a process generated by the service manager process 23800 when the service providing system 102 communicates with the personal credit terminal 100. The service manager process 23800 spawns one user process 23802 for one personal credit terminal 100 communicating with the service providing system 102. At this time, the service manager process 23800 generates the user process management information 4400 shown in FIG. 75 (a) on the memory or the hard disk of the computer constituting the service server 400, and generates the generated user process 23802. to manage.

[0739] The user process 23802 includes the user process management information 4400, the attribute information of the owner (user) of the personal credit terminal 100 managed by the user information server 402, and the data of the RAM 1502 of the personal credit terminal 100. Is given permission to access. Conversely, user process 23802 has no access to other information.

[0740] The personal credit terminal 100 and the user process 23802 have a one-to-one correspondence, and the user process 23802 is a process valid only for the personal credit terminal 100, and other personal credit terminals and other personal credit terminals. You cannot communicate directly.

[0741] The user process 23802 and the personal credit terminal 100 communicate using the messages shown in the columns 23901 and 23902 of FIG. Messages in column 23901 (Certification Test A Response, Certification Test C, Certification Test D Response, Remote Access Request, Data Update Request, Upload Data, Payment Request, Cancellation Request, Incoming Answer, Inquiry Call Request, Timeout Error Message, Session -Error message) is a message sent from the personal credit terminal to the user process, the message in column 23902 (authentication test A, authentication test B response, authentication test C response, remote access data, data update response, update data, Data update instructions, outage orders, receipts, cancellation receipts, customer service calls, inquiry call answers, call answers, timeout error messages, session error messages, timeout messages) are sent from the user process to the personal credit terminal. Indicates the message sent to. Sending any other message will not be interpreted as a valid message by each other.

[0742] Further, the user process 23802 communicates with the service director process 23801 belonging to the same process group by using the message shown in the columns 23903 and 23904 of FIG. 69 as an interface. The messages in column 23903 (receipt, cancellation receipt, customer service call, inquiry call answer, call answer, timeout error message, session error message) are messages sent from the service director process to the user process. The messages in column 23904 (Payment Request, Cancellation Request, Incoming Answer, Inquiry Call Request, Timeout Error Message, Session Error Message, Timeout Message) indicate the message sent from the user process to the service director process. .. Sending any other message will not be interpreted as a valid message by each other.

[0743] Further, the user process 23802 communicates with the service manager process 23800 using the message shown in the column 23906 of FIG. 69 as an interface. The messages in column 23906 (payment request, cancellation request, inquiry request, own process deletion request) indicate the message sent from the user process to the service manager process. In addition, column 23905 (user process creation, user process deletion) in FIG. 69 shows the action of the service manager process on the user process, and the service manager process creates and deletes the user process. The content of the message will be described in detail later.

[0744] There is no interface for communication between a user process and another user's user process, and the user process cannot communicate directly with other user processes. Similarly, there is no communication interface between the user process and the merchant process, the user process and the payment processor process, the user process and the service director process of a different process group, and the user process is the merchant process, the payment processor process, And cannot communicate directly with service director processes in different process groups.

[0745] When the personal credit terminal is used in a service area other than the service area in which the user resides, the personal credit terminal is used on the service providing system of the service area in which the user resides. A user process may be generated on the service providing system of the service area. Such a case will be described in detail later.

Next, the merchant process 23803 will be described.

[0747] The merchant process controls communication with the credit payment terminal 300, authenticates the merchant, encrypts data transmitted to the credit payment terminal 300, decrypts data received from the credit payment terminal 300, and from the credit payment terminal 300. It is a process of checking the validity of the received data of the above, and further performing remote access and data update processing with the credit settlement terminal 300.

Merchant process 23803 is a process generated by service manager process 23800 when the service providing system 102 communicates with the credit card payment terminal 300. The service manager process 23800 generates one merchant process 23803 for one credit card payment terminal 300 communicating with the service providing system 102. At this time, the service manager process 23800 generates the merchant process management information 4401 shown in FIG. 75 (b) on the memory or the hard disk of the computer constituting the service server 400, and generates the generated merchant process 23803. to manage.

[0749] The merchant process 23803 includes the merchant process management information 4401, the attribute information of the owner (merchant) of the credit payment terminal 300 managed by the merchant information server 403, and the RAM 22502 and the hard disk 22503 of the credit payment terminal 300. You are given permission to access the data. Conversely, Merchant Process 23803 has no access to other information.

[0750] The credit card payment terminal 300 and the merchant process 23803 have a one-to-one correspondence, and the merchant process 23803 is a process that is valid only for the corresponding credit card payment terminal 300, and is directly connected to other credit card payment terminals. , Cannot communicate.

[0751] The merchant process 23803 and the credit card payment terminal 300 communicate with each other using the messages shown in the columns 23907 and 23908 of FIG. 69. Messages in column 23907 (Authentication Test A Response, Authentication Test C, Authentication Test D Response, Remote Access Request, Data Update Request, Upload Data, Credit Inquiry Request, Payment Request, Receipt, Cancellation Request, Incoming Answer, Customer Service Call Requests, timeout error messages, session error messages) are messages sent from the credit settlement terminal to the merchant process, messages in column 23908 (authentication test A, authentication test B response, authentication test C response, remote access data, Data update response, update data, data update order, outage order, credit inquiry response, payment completion notification, cancellation completion notification, customer service call answer, call answer, inquiry call, timeout error message, session error message, timeout Message) indicates a message sent from the merchant process to the credit payment terminal. Sending any other message will not be interpreted as a valid message by each other.

[0752] Further, the merchant process 23803 communicates with the service director process 23801 belonging to the same process group by using the message shown in the columns 23909 and 23910 of FIG. 69 as an interface. Messages in column 23909 (credit inquiry response, settlement completion notification, cancellation completion notification, customer service call answer, call answer, inquiry call, timeout error message, session error message) are sent from the service director process to the merchant process. The messages in the 23910 column (payment completion notification, cancellation completion notification, customer service call answer, call answer, inquiry call, timeout error message, session error message, timeout message) are serviced from the merchant process. Indicates a message sent to the director process. Sending any other message will not be interpreted as a valid message by each other.

[0753] Further, the merchant process 23803 communicates with the service manager process 23800 using the message shown in the column 23912 of FIG. 69 as an interface. The messages in column 23912 (credit inquiry request, cancellation request, customer service call request, own process clearing request) indicate the message sent from the merchant process to the service manager process. In addition, the column 23911 (create merchant process, delete merchant process) in FIG. 69 shows the action of the service manager process on the merchant process, and the service manager process creates and deletes the merchant process. The content of the message will be described in detail later.

There is no interface for communication between the merchant process and other merchant processes, and the merchant process cannot communicate directly with other merchant processes. Similarly, there is no communication interface between the merchant process and the user process, the merchant process and the payment processor process, the merchant process and the service director process of a different process group, and the merchant process is the user process, the payment processor process, And cannot communicate directly with service director processes in different process groups.

Next, the settlement processing institution process 23804 will be described.

[0756] The payment processing institution process controls communication with the payment system 103, authenticates the payment processing institution, encrypts data transmitted to the payment system 103, decrypts data received from the payment system 103, and from the payment system 103. This is the process of checking the validity of the received data.

[0757] The payment processing agency process 23804 is a process generated by the service manager process 23800 when the service providing system 102 communicates with the payment system 103. One payment processing institution process 23804 is generated for communication using one communication line between the service providing system 102 and the payment system 103. The digital communication line 111 connecting the service providing system 102 and the payment system 103 operates as a plurality of communication lines by multiplexing. Therefore, when communication is performed between the service providing system 102 and the payment system 103 using a plurality of communication lines at the same time, the service manager process 23800 is a payment processing institution process in the same number as the communication lines. Generate 23804. At this time, the service manager process 23800 performs the payment processing institution process shown in FIG. 75 (c) for each of the payment processing institution processes generated on the memory or the hard disk of the computer constituting the service server 400. Generate management information 4402 to manage the payment processing institution process.

[0758] The settlement processing institution process 23804 includes the settlement processing institution process management information 4402, the attribute information of the settlement processing institution in which the settlement system 103 managed by the settlement processing institution information server 404 is installed, and the history information of the settlement processing. You are given permission to access and. Conversely, the settlement processing agency process 23804 has no access to other information.

[0759] Further, the payment processing institution process 23804 is a process effective only for the payment system 103, and cannot directly communicate with other payment systems.

[0760] The payment processing institution process 23804 and the payment system 103 communicate with each other using the messages shown in the columns 23913 and 23914 of FIG. The messages in column 23913 (payment completion notification, cancellation completion notification, timeout error message, session error message) are the messages sent from the payment system to the payment processing institution process, and the messages in column 23914 (payment request, cancellation request). , Timeout error message, session error message, timeout message) indicates the message sent from the payment processing institution process to the payment system. Sending any other message will not be interpreted as a valid message by each other.

[0761] Further, the settlement processing institution process 23804 communicates with the service director process 23801 belonging to the same process group by using the messages shown in the columns 23915 and 23916 of FIG. 69 as an interface. The messages in column 23915 (payment request, cancellation request, timeout error message, session error message) are the messages sent from the service director process to the payment processing institution process, and the messages in column 23916 (payment completion notification, cancellation). Completion notifications, session error messages, timeout messages) indicate the messages sent by the payment processor process to the service director process. Sending any other message will not be interpreted as a valid message by each other.

[0762] Further, the settlement processing institution process 23804 communicates with the service manager process 23800 using the message shown in the column 23918 of FIG. 69 as an interface. The message in column 23918 (your process clearing request) indicates the message sent by the settlement processor process to the service manager process. In addition, column 23917 (creation of settlement processing institution process, deletion of settlement processing institution process) in FIG. 69 shows the action of the service manager process on the settlement processing institution process, and the service manager process is the settlement processing institution process. Is generated and deleted. The content of the message will be described in detail later.

There is no communication interface between the settlement processing agency process and other settlement processing agency processes, and the settlement processing agency process cannot communicate directly with other settlement processing agency processes. Similarly, there is no communication interface between the payment processing institution process and the user process, the payment processing institution process and the merchant process, the payment processing institution process and the service director process of a different process group, and the payment processing institution process is the user process. , Merchant processes, and service director processes of different process groups cannot communicate directly.

Next, the service director process 23801 will be described.

The service director process is a process of directing a personal remote credit payment service by communicating with a user process, a merchant process, and a payment processing institution process belonging to the same process group, respectively. The phrase "directing a personal remote credit card payment service" means that the service director process takes the lead in processing the personal remote credit card payment service in collaboration with other member processes of the same process group. It means that.

[0766] In the service director process 23801, when the service providing system 102 processes any one of "payment", "cancellation", "customer service call", and "inquiry call" of the personal remote credit payment service. Generated by the service manager process 23800. The service manager process 23800 generates the service director process management information 4403 shown in FIG. 75 (d) on the memory or the hard disk of the computer constituting the service server 400, and generates the service director process 23801. To manage.

[0767] Each of the "payment", "cancellation", "customer service call", and "inquiry call" processing of the personal remote credit payment service has a predetermined processing sequence. The service director process processes the messages sent from the member processes of the same process group according to this determined processing sequence, and also sends a message prompting the processing to each member process. Then, each member process performs processing corresponding to the message sent from the service director process. In this way, the processing of the personal remote credit settlement service is performed by the service director process and the member processes of the same process group collaborating to perform the processing.

[0768] In the case of processing of "payment" and "cancellation", the service director process, the user process, the merchant process, and the payment processing institution process form one process group to perform each processing. , In the case of "customer service call" processing and "inquiry call" processing, the service director process, the user process, and the merchant process form one process group to perform each processing.

[0769] Further, the service director process 23801 includes the service director process management information 443, the information managed by the service director information server 404, and the information that the member processes of the same process group have access permission. Is given permission to accelerate. Conversely, the service director process 23801 has no access to other information.

[0770] Further, the service director process 23801 communicates with the user process 23802 belonging to the same process group by using the messages shown in the columns 23904 and 23903 of FIG. 70 as an interface. The messages in column 23904 (Payment Request, Cancellation Request, Incoming Answer, Inquiry Call Request, Timeout Error Message, Session Error Message, Timeout Message) are the messages sent from the user process to the service director process in 23903. The messages in the column (receipt, cancellation receipt, customer service call, inquiry call answer, call answer, timeout error message, session error message) indicate the message sent from the service director process to the user process. .. Sending any other message will not be interpreted as a valid message by each other.

Similarly, the service director process 23801 communicates with the merchant process 23803 belonging to the same process group using the messages shown in the columns 23910 and 23909 of FIG. 70 as an interface. Messages in column 23910 (payment completion notification, cancellation completion notification, customer service call answer, call answer, inquiry call, timeout error message, session error message, timeout message) are sent from the merchant process to the service director process. The message in the 23909 column (credit inquiry response, settlement completion notification, cancellation completion notification, customer service call answer, call answer, inquiry call, timeout error message, session error message) is from the service director process. Shows the message sent to the merchant process. Sending any other message will not be interpreted as a valid message by each other.

[0772] Similarly, the service director process 23801 communicates with the settlement processing institution process 23804 belonging to the same process group using the messages shown in the columns 23916 and 23915 of FIG. 70 as an interface. The messages in column 23916 (payment completion notification, cancellation completion notification, session error message, timeout message) are the messages sent from the payment processing institution process to the service director process, and the messages in column 23915 (payment request, cancellation). Requests, timeout error messages, session error messages) indicate the messages sent by the service director process to the payment processor process. Sending any other message will not be interpreted as a valid message by each other.

[0773] Further, the service director process 23801 communicates with the service manager process 23800 using the message shown in the column 23920 of FIG. 70 as an interface. The messages in column 23920 (member process request, process erase request) indicate the messages sent from the service director process to the service manager process. Also, column 23919 in Figure 70 (service director process creation, service director process deletion, payment request, credit inquiry request, cancellation request, customer service call request, inquiry request) is the service director process of the service manager process. The service manager process creates and deletes the service director process. The content of the message will be described in detail later.

There is no interface for communication between user processes in process groups different from the service director process, merchant processes in process groups different from the service director process, and payment processing institution processes in different process groups from the service director process. The service director process cannot communicate directly with user processes in different process groups, merchant processes in different process groups, and payment processing agency processes in different process groups.

Next, the service manager process 23800 will be described.

The service manager process is the process of creating and erasing the user process 23802, the merchant process 23803, the payment processing institution process 23804, and the service director process 23801, as well as creating and erasing process groups.

[0777] In the service manager process 23800, the user process management information 4400, the merchant process management information 4401, and the payment processing institution process management information 4402 shown in FIG. 75 are placed on the memory or the hard disk of the computer constituting the service server 400. , Service Director Process Management Information 4403, Process Group Management Information 4404, and Message List 4405 are generated to manage each process. Process group management information 4404 is process group management data, and message list 4405 is a list of messages pending processing by the service manager process. The role of message list 4405 will be explained in detail later.

[0778] The service manager process 23800 is a process that is always started when the service providing system provides a personal remote credit payment service. The creation and deletion of service manager processes is controlled by management system 407.

The service manager process 23800 is also granted permission to access information managed by the service director information server 401. Conversely, the service manager process 23800 has no access to other information.

[0780] Further, the service manager process 23800 communicates with the user process 23802 by using the message shown in the column of 23906 in FIG. 70 as an interface. The messages in column 23906 (payment request, cancellation request, inquiry request, own process deletion request) indicate the message sent from the user process to the service manager process. In addition, column 23905 (user process creation, user process deletion) in FIG. 70 shows the action of the service manager process on the user process, and the service manager process creates and deletes the user process.

Similarly, the service manager process 23800 communicates with the merchant process 23803 via the message shown in column 23912 of FIG. 70 as an interface. The messages in column 23912 (credit inquiry request, cancellation request, customer service call request, own process clearing request) indicate the message sent from the merchant process to the service manager process. In addition, the column 23911 (create merchant process, delete merchant process) in FIG. 70 shows the action of the service manager process on the merchant process, and the service manager process creates and deletes the merchant process.

Similarly, the service manager process 23800 communicates with the payment processing agency process 23804 using the message shown in column 23918 of FIG. 70 as an interface. The message in column 23918 (your process clearing request) indicates the message sent by the settlement processor process to the service manager process. In addition, the column 23917 (creation of payment processing institution process, deletion of payment processing institution process) in FIG. 70 shows the action of the service manager process on the payment processing institution process, and the service manager process is the payment processing institution process. Is generated and deleted.

Similarly, the service manager process 23800 communicates with the service director process 23801 via the message shown in column 23920 of FIG. 70 as an interface. The messages in column 23920 (member process request, process erase request) indicate the messages sent from the service director process to the service manager process. Also, column 23919 in Figure 70 (service director process creation, service director process deletion, payment request, credit inquiry request, cancellation request, customer service call request, inquiry request) is the service director process of the service manager process. The service manager process creates and deletes the service director process.

[0784] Further, the service manager process 23800 communicates with the service manager process of the service providing system in another service area by using the messages shown in the columns 23921 and 23922 in FIG. 70 as an interface. The messages in column 23921 (user process generation, user process erasure, home user process generation, home user process erasure, mobile user process generation, mobile user process erasure, cancellation request, inquiry call request) provide services in other service areas. The message sent from the system service manager process to the service manager process 23800 is the message in column 23922 (user process generation, user process erasure, home user process generation, home user process erasure, mobile user process generation, mobile user process). Erase, cancel request, inquiry call request) indicates a message sent from the service manager process 23800 to the service manager process of the service delivery system in another service area. Communication between service manager processes of different service provision systems takes place when providing a personal remote credit payment service across service areas. Such a case will be described in detail later.

Next, the information managed by the user information server 402 of the service providing system 102 will be described. The user information server 402 manages the attribute information of the user and the data of the RAM 1502 of the user's personal credit terminal 100. However, one user information server 402 does not manage the attribute information of all users and the RAM data of the personal credit terminal, but manages them in a distributed manner for each service area. Therefore, the user information server 402 manages the attribute information of the user residing in the service area in charge of the service providing system 102 and the RAM data of the user's personal credit terminal (hereinafter, the service area in which the user resides). Is called the user's "home service area".).

[0786] FIG. 71 is a schematic diagram showing information stored in the user information server 402 for one user. In the user information server 402, for one user, user data management information 24000, personal information 24001, photo data 24002, terminal property 24003, user setting information 24004, access control information 24005, terminal data 24006, telephone information 24007, 10 types of information are stored in the credit card list 24008 and the usage history list 24009. The detailed contents of this information are the same as those described with reference to FIG. 29 in the first embodiment.

Next, the information managed by the merchant information server 403 of the service providing system 102 will be described. The merchant information server 403 manages the attribute information of the merchant and the data of the RAM 22502 and the hard disk 22503 of the credit card payment terminal 300 of the merchant. However, one merchant information server 403 does not manage the attribute information of all merchants and the data of the credit card payment terminal, but manages them in a distributed manner for each service area. Therefore, the merchant information server 403 manages the attribute information of the merchant located in the service area in charge of the service providing system 102, and the RAM and hard disk data of the personal credit terminal of the merchant.

[0788] FIG. 72 is a schematic diagram showing information stored in the merchant information server 403 for one merchant. In the merchant information server 403, for one merchant, merchant data management information 24100, merchant information 24101, terminal property 24102, merchant setting information 24103, terminal data 24104, telephone information 24105, credit card list 24106, and sales history. Contains eight types of information in Listing 24107. The detailed contents of this information are the same as those described with reference to FIG. 30 in the first embodiment. The merchant information 24101 is information about the merchant such as the address, account number, and contract details of the merchant, and a part of this information corresponds to the merchant information 2506 of the credit card payment terminal 2410.

Next, the information managed by the payment processing institution information server 404 of the service providing system 102 will be described. The payment processing institution information server 404 manages the attribute information of the payment processing institution and the history information of the payment processing by the payment processing institution.

[0790] FIG. 73 is a schematic diagram showing information stored in the settlement processing institution information server 404 for one settlement processing institution. The payment processing institution information server 404 stores four types of information, payment processing institution data management information 24200, payment processing institution information 24201, credit card list 24202, and sales history list 24203, for one payment processing institution. To. The detailed contents of this information are the same as those described with reference to FIG. 31 in the first embodiment.

Next, the information stored in the service director information server 401 of the service providing system 102 will be described.

[0792] FIG. 74 is a schematic diagram showing information stored in the service director information server 401.

[0793] The service director information server 401 stores five types of information: a user list 4300, a merchant list 4301, a payment processing institution list 4302, a service provision history list 4303, and a payment processing institution table 4304.

[0794] User list 4300 is a list of attribute information of all users who have a contract with a service provider, and merchant list 4301 is a list of attribute information of all merchants who have a contract with a service provider, and a payment processing institution. List 4302 is a list of attribute information of all payment processing institutions that have contracts with service providers, and service provision history list 4303 is a list of history information of personal remote credit payment services provided by service provision system 102. Yes, the payment processing institution table 4304 is table information in which the optimum payment processing institution is associated with the request of the personal remote credit payment service from the user and the merchant.

[0795] The user list 4300 includes a user name 4305 (4310), a user ID 4306 (4311), a user telephone number 4307 (4312), a service list address 4308 (4313), and user information for one user. Five types of information at address 4309 (4314) are stored.

Service list address 4308 (4313) indicates an address that stores a list of service codes that can be used by a user, and user information address 4309 (4314) stores user data management information for that user. Indicates the address you are using. The list of service codes that can be used by the user and the user data management information are managed by the service director information server and the user information server in the service providing system of the user's home service area, respectively. Therefore, when the service providing system 102 is a service providing system in the user's home service area, the service list address and the user information address are the address on the service director information server 401 and the user information, respectively. The address on the server 402 is shown, and when the user's home service area and the service area of the service providing system 102 are different, the service list address and the user information address are the user's home service, respectively. The address on the service director information server and the address on the user information server in the service providing system of the area are shown.

[0797] The Merchant List 3301 includes, for one Merchant, a Merchant Name 4315 (4321), a Merchant ID 4316 (4322), a Merchant Phone Number 4317 (4323), a Service List Address 4318 (4324), and a Customer Table. Six types of information are stored: address 4319 (4325) and merchant information address 4320 (4326).

Service list address 4308 (4312) indicates an address that stores a list of service codes that can be handled by the merchant, and customer table address 4317 (4322) is the customer number and user ID. The merchant information address 4320 (4326) indicates the address where the table information (customer table) indicating the correspondence is stored, and the merchant information management information of the merchant is stored.

[0799] The list of service codes and the customer table that can be handled by the merchant, and the merchant data management information are managed by the service director information server and the user information server in the service providing system of the merchant's home service area, respectively. Will be done. Therefore, when the service providing system 102 is the service providing system of the merchant's home service area, the service list address and the customer table address indicate the address on the service director information server 401, and the user information address is , Indicates the address on the user information server 402. If the home service area of the merchant and the service area of the service provision system 102 are different, the service list address and the customer table address are on the service director information server in the service provision system of the merchant's home service area. The user information address indicates the address on the user information server in the service providing system of the merchant's home service area.

[0800] The settlement processing institution list 4302 includes the settlement processing institution name 4327 (4332), the settlement processing institution ID 4328 (4333), the settlement processing institution communication ID 4329 (4334), and the service list for one settlement processing institution. Five types of information are stored: address 4330 (4335) and settlement processing institution information address 4331 (4336).

[0801] The payment processing institution communication ID 4329 (4334) indicates the ID of the payment system 103 when the service providing system 102 communicates with the payment system 103 via the digital communication line 111, and the service list address 4330 (4335). ) Indicates the address on the service director information server 401 that stores the list of service codes that can be handled by the payment processing institution, and the payment processing institution information address 4331 (4336) is the payment processing institution of the payment processing institution. Indicates the address on the payment processing institution information server 404 in which the data management information is stored.

[0802] In the service provision history list 4303, for one service provision of the personal remote credit payment service, the service provision number 4337 (4341), the service code 4338 (4342), the service provision time 4339 (4343), And four types of information of the service provision information address 4340 (4344) are stored.

[0803] The service provision number 4337 (4341) is a number uniquely indicating the processing in the service provision system 102 in one service provision, and the service code 4338 (4342) is a code indicating the type of credit card service used by the user. The number, service provision time 4339 (4343) is the time when the service of the personal remote credit payment service was provided, and the service provision information address 4340 (4344) is the history information of the processing in the service provision system 102 in one service provision. Indicates the address on the service director information server 401 where is stored.

[0804] Next, the management data of the process generated when the service manager process 23800 manages the user process, the merchant process, the payment processing institution process, and the service director process will be described.

[0805] FIGS. 75 (a) to (f) show the structure of the management data of the process generated by the service manager process.

FIG. 75 (a) shows the data structure of the user process management information 4400 generated for one user process. The user process management information 4400 includes a user process ID 4406 indicating the process ID of the user process, a user ID 4407 corresponding to the user process, and a home process indicating the process ID of the user process on the service providing system in the user's home service area. ID4408, mobile process ID4409 indicating the process ID of the user process on the service providing system in the service area other than the user's home service area, and service ID4409 indicating the process ID of the service director process belonging to the same process group as the user process. It consists of seven types of information: the director process ID 4410, the process status 4411 indicating the execution status of the user process, and the process data area pointer 4412 indicating the memory area allocated to the user process.

When the personal credit terminal communicates with the service providing system of the user's home service area, the service manager process of the service providing system of the home service area is one user process corresponding to the personal credit terminal. In the field of user process ID 4406, set an ID that uniquely points to the user process through the service provision system of all service areas, and set "0" in the fields of home process ID 4408 and mobile process ID 4409. Set.

[0808] On the other hand, when the user uses the personal credit terminal in a service area other than the home service area and the personal credit terminal communicates with the service providing system other than the home service area, the personal credit User processes corresponding to the terminals are generated on the service providing system of the user's home service area and on the service providing system with which the personal credit terminal communicates.

[0809] In this case, the user process on the service providing system in the home service area is called a home user process (HUP), and the user process on the service providing system with which the personal credit terminal communicates is called mobile. It is called a user process (MUP: Mobile User Process). The home user process and the mobile user process communicate with each other, perform cooperative processing, and function as one user process. Specifically, the home user process accesses the user attribute information managed by the user information server and the RAM data of the user's personal credit terminal, and the mobile user process controls communication with the personal credit terminal. , And perform data processing. That is, the mobile user process accesses the user information server via the home user process.

[0810] The service manager process of the service providing system in the home service area uniquely displays the home user process in the field of user process ID 4406 in the user process management information of the home user process through the service providing system in all service areas. Set the pointing ID, set "0" in the field of home process ID 4408, and set the ID of the mobile user process in the field of mobile process ID 4409.

In addition, the service manager process of the service providing system with which the personal credit terminal communicates is entered in the field of user process ID 4406 in the user process management information of the mobile user process through the service providing system of all service areas. An ID that uniquely points to the mobile user process is set, the ID of the home user process is set in the field of home process ID 4408, and "0" is set in the field of mobile process ID 4409.

[0812] Further, the user ID 4407 and the service director process ID 4410 each indicate a user and a service director process that are unique throughout the service provision system of all service areas.

Next, FIG. 75 (b) shows the data structure of the merchant process management information 4401 generated for one merchant process. Merchant process management information 4401 includes a merchant process ID 4413 indicating the process ID of the merchant process, a merchant ID 4414 of the merchant corresponding to the merchant process, and a service indicating the process ID of the service director process belonging to the same process group as the merchant process. It consists of five types of information: the director process ID 4415, the process status 4416 indicating the execution status of the merchant process, and the process data area pointer 4417 indicating the memory area allocated to the merchant process. Merchant process ID4413, merchant ID4414, and service director process ID4415, respectively, represent a merchant process, a merchant, and a service director process that are unique throughout the service delivery system in all service areas.

Next, FIG. 75 (c) shows the data structure of the settlement processing agency process management information 4402 generated for one settlement processing agency process. The settlement processing institution process management information 4402 includes the settlement processing institution process ID 4418 indicating the process ID of the settlement processing institution process, the settlement processing institution ID 4419 of the settlement processing institution corresponding to the settlement processing institution process, and the same process as the settlement processing institution process. Service director process ID 4420 indicating the process ID of the service director process belonging to the group, process status 4421 indicating the execution status of the settlement processing agency process, and process data area pointer 4422 indicating the memory area allocated to the settlement processing agency process. It consists of 5 types of information. Payment processing institution process ID 4418, payment processing institution ID 4419, and service director process ID 4420, respectively, indicate a payment processing institution process, a payment processing institution, and a service director process that are unique throughout the service provision system of all service areas. ..

Next, FIG. 75 (d) shows the data structure of the service director process management information 4403 generated for one service director process. The service director process management information 4403 contains the service director process ID 4423 indicating the process ID of the service director process, the process group ID 4424 indicating the ID of the process group to which the service director process belongs, and the execution status of the service director process. 5 of the process status 4425 shown, the member list 4426 showing a list of process IDs of processes belonging to the same process group as the service director process, and the process data area pointer 4427 showing the memory area allocated to the service director process. It consists of types of information. Service director process ID 4423 and process group ID 4424 represent service director processes and process groups that are unique throughout the service delivery system in all service areas, respectively.

Next, FIG. 75 (e) shows the data structure of the process group management information 4404 generated for one process group. Process group management information 4404 is a process group ID 4428 indicating the process group ID, a service director process ID 4429 indicating the process ID of the process group service director process, and a member indicating a list of process IDs of processes belonging to the process group. It consists of three types of information with Listing 4430. Process group ID 4428 and service director process ID 4429 represent process groups and service director processes that are unique throughout the service delivery system in all service areas, respectively.

FIG. 75 (f) shows the data structure of message list 4405 showing messages pending processing by the service manager process.

[0818] Of the messages sent to the service manager process, payment requests and cancellation requests sent from the user process, and authorization request and cancellation request sent from the merchant process may be temporarily suspended. Yes, in this case the service manager process registers it in message list 4405.

[0819] For example, in the case of "payment" processing, if the payment request is sent to the service manager process prior to the credit inquiry request, the corresponding credit inquiry request is sent to the service manager process. Until, the payment request is registered in message list 4405. When the corresponding authorization request is sent to the service manager process, the service manager process spawns a service director process, which processes the payment request and the authorization request. Conversely, if the authorization request is sent to the service manager process before the payment request, the authorization request is registered in message list 4405 until the corresponding payment request is sent to the service manager process. Will be done. When the corresponding payment request is sent to the service manager process, the service manager process spawns a service director process, which processes the payment request and the authorization request.

[0820] In the case of the "cancel" process, if the cancellation request from the user process is sent to the service manager process before the cancellation request from the merchant process, the cancellation from the corresponding merchant process. Cancellation requests from the user process are registered in message list 4405 until the request is sent to the service manager process. When a cancellation request from the corresponding merchant process is sent to the service manager process, the service manager process spawns a service director process, and the spawned service director process cancels from the user process and the merchant process. The request is processed. Conversely, if the cancellation request from the merchant process is sent to the service manager process before the cancellation request from the user process, the cancellation request from the corresponding user process is sent to the service manager process. Until then, the cancellation request from the merchant process is registered in message list 4405. When a cancellation request from the corresponding user process is sent to the service manager process, the service manager process spawns a service director process, and the spawned service director process cancels from the user process and the merchant process. The request is processed.

The service manager process responds to each of the payment request, the credit inquiry request, the user process, and the cancellation request from the merchant process by matching the message registered in the message list 4405 with the content of the message. Detect the message.

[0822] In the message list 4405, the message pointer 4431 (4434), which is a pointer to a message, and the matching data pointer, which is a pointer to the matching data to be matched when detecting the corresponding message, are shown in the message list 4405. Three pieces of information are registered: 4432 (4435) and process ID 4433 (4436) indicating the process of the sender of the message.

[0823] Next, the details of the messages exchanged in the process of establishing a session with the service providing system by the personal credit terminal or the credit payment terminal will be described. The session establishment process is a process in which the personal credit terminal and the service providing system or the credit payment terminal and the service providing system mutually authenticate each other before starting communication. Hereinafter, this process is referred to as a session establishment process.

[0824] FIG. 76 shows a procedure of session establishment processing when connecting to a service providing system from a personal credit terminal, and FIGS. 78 (a), (b), and (c) show a personal credit terminal. Shows the content of the message exchanged with the service providing system.

[0825] FIG. 77 shows a procedure for session establishment processing when connecting to a personal credit terminal from the service providing system, and FIGS. 78 (d), (e), and (f) show the personal credit terminal. Shows the content of the message exchanged between the service provider and the service provider.

[0826] When connecting to the service providing system from the personal credit terminal, first, the personal credit terminal 100 calls the service providing system 102 and connects the line (line connection 4505). At this time, the personal credit terminal 100 transmits a message requesting a line connection of a digital radiotelephone, a call request 4500, to the digital public network 108, and the digital public network 108 sends a message calling a service providing system, an incoming call. Send request 4501 to the service delivery system. On the other hand, the service providing system sends a message permitting the call and the incoming call answering 4503 to the digital public network, and the digital public network sends a message permitting the line connection and the calling answer 4504 to the personal credit terminal. Then, the personal credit terminal and the service providing system are connected by a line (line connection 4505).

At this time, a call request 4500, a call request 4501, a call response 4503, a call response 4504, etc., which are exchanged between the personal credit terminal and the digital public network, and the digital public network and the service providing system, etc. The message depends on the protocol of the line connection from the digital radiotelephone via the transmission line 106 and the base station 104, the digital communication line 107, the digital public network 108, and the digital communication line 109.

[0828] Further, in the service providing system, the service manager process receives the incoming call request 4501 from the digital public network 108. The service manager process generates a user process corresponding to the caller's personal credit terminal from the phone number information of the caller's personal credit terminal included in the incoming call request 4501 (process generation 4502), and is generated. The user process sends an incoming call response 4503 to connect the line to the personal credit terminal.

When the line between the personal credit terminal and the user process is connected (line connection 4505), the user process generates a test message for authenticating the personal credit terminal, the authentication test A4506, and the personal credit terminal. Send to.

As shown in FIG. 78 (a), the authentication test A4506 uses header information indicating that the message is the authentication test A4506, the authentication test A header 4700, and the test pattern A4701 which is an arbitrary bit pattern. It consists of 4702 encrypted with public key.

[0831] The personal credit terminal receives the authentication test A4506, decrypts the encryption of the test pattern A with the user's private key, is a response message to the authentication test A4506, and is a test for authenticating the user process. Generate a message, Authentication Test A Response 4507, and send it to the user process.

As shown in FIG. 78 (b), the authentication test A response 4507 includes header information indicating that the message is the authentication test A response 4507, the authentication test A response header 4703, and a test pattern in which the encryption is decrypted. It consists of A4704 and 4706, which is the test pattern B4705, which is an arbitrary bit pattern, encrypted with the public key of the service provider. That is, the authentication test A response 4507 includes an authentication test B for authenticating the user process, which corresponds to the authentication test A for the test pattern A.

[0833] The user process receives the authentication test A response 4507, matches the test pattern A4701 with the received test pattern A4704, and authenticates the user. The user authentication in this case is based on the premise that the test pattern A encrypted with the user's public key can only be decrypted by the personal credit terminal having the user's private key.

The user process further decrypts the test pattern B cipher with the service provider's private key to generate a response message to authentication test B, authentication test B response 4508, and sends it to the personal credit terminal.

As shown in FIG. 78 (c), the authentication test B response 4508 includes header information indicating that the message is the authentication test B response 4508, the authentication test B response header 4707, and a test pattern in which the encryption is decrypted. It consists of B4708 and 4710, which is the session permission message 4709 encrypted with the user's public key. Session permission message 4709 is a message that permits a session with a personal credit terminal, and includes information on communication conditions.

[0836] The personal credit terminal receives the authentication test B response 4508, collates the received test pattern B4705 with the received test pattern B4708, and authenticates the user process. The authentication of the user process in this case is based on the premise that the test pattern B encrypted with the service provider's public key can only be decrypted by the service provider system having the service provider's private key.

[0837] The personal credit terminal further decrypts the encryption of the session permission message with the user's private key, and changes the communication condition with the user process to the communication condition of the session permission message.

[0838] By the above processing, the personal credit terminal and the user process authenticate each other and communicate based on common communication conditions (session establishment 4509). In the following, this state is referred to as a session establishment state.

[0839] When connecting to the personal credit terminal from the service providing system, first, the service providing system 102 calls the personal credit terminal 100 and connects the line (line connection 4605). At this time, in the service providing system 102, the service manager process generates a user process corresponding to the personal credit terminal to which the line is connected (process generation 4600), and the generated user process is digitally connected to the digital public network 108. A message requesting a wireless telephone line connection, a call request 4601, is transmitted, and the digital public network 108 sends a message calling a personal credit terminal, a call request 4602, to the personal credit terminal. On the other hand, the personal credit terminal sends a message permitting the call, the incoming call response 4603, to the digital public network, and the digital public network sends a message permitting the line connection, the calling answer 4604, to the user process. Then, the user process and the personal credit terminal are connected by a line (line connection 4605). At this time, messages such as a call request 4601, a call request 4602, a call response 4603, and a call response 4604 exchanged between the user process and the digital public network and between the digital public network and the personal credit terminal are digital. It depends on the protocol of the line connection via the communication line 109, the digital public network 108, the digital communication line 107, the base station 104, and the transmission line 106.

When the line between the user process and the personal credit terminal is connected (line connection 4605), the personal credit terminal generates a test message for authenticating the user process, authentication test C4606, to the user process. Send.

As shown in FIG. 78 (d), the authentication test C4606 provides a header information indicating that the message is the authentication test C4606, an authentication test C header 4711, and a test pattern C4712 which is an arbitrary bit pattern. It consists of 4713 encrypted with the public key of the person.

[0842] The user process receives the authentication test C4606, decrypts the code of the test pattern C with the private key of the service provider, is a response message to the authentication test C4606, and authenticates the personal credit terminal. Generates the authentication test C response 4607, which is the test message of, and sends it to the personal credit terminal.

As shown in FIG. 78 (e), the authentication test C response 4607 includes header information indicating that the message is the authentication test C response 4607, the authentication test C response header 4714, and a test pattern in which the encryption is decrypted. It consists of C4715 and 4717, which is an arbitrary bit pattern, test pattern D4716, encrypted with the user's public key. That is, the authentication test C response 4607 includes the authentication test D for authenticating the personal credit terminal, which corresponds to the authentication test C for the test pattern C.

The personal credit terminal receives the authentication test C response 4607, matches the test pattern C4712 with the received test pattern C4715, and authenticates the user process. Authentication of the user process in this case is based on the premise that test pattern C encrypted with the service provider's public key can only be decrypted by the service provider system with the service provider's private key.

[0845] The personal credit terminal further decrypts the code of the test pattern D with the user's private key to generate a response message for the authentication test D, the authentication test D response 4608, and sends it to the user process.

As shown in FIG. 78 (f), the authentication test D response 4608 includes header information indicating that the message is the authentication test D response 4608, the authentication test D response header 4718, and a test pattern in which the encryption is decrypted. It consists of D4719 and 4721, which is the session permission message 4720 encrypted with the service provider's public key. Session permission message 4720 is a message that permits a session with a user process and contains information about communication conditions.

[0847] The user process receives the authentication test D response 4608, matches the test pattern D4716 with the received test pattern D4719, and authenticates the personal credit terminal. The authentication of the personal credit terminal in this case is based on the premise that the test pattern D encrypted with the user's public key can be decrypted only by the personal credit terminal having the user's private key.

[0848] The user process further decrypts the encryption of the session permission message with the private key of the service provider, and changes the communication condition with the personal credit terminal to the communication condition of the session permission message.

[0849] By the above processing, the user process and the personal credit terminal authenticate each other and communicate based on the common communication conditions, and the session is established (session establishment 4609).

The session establishment process between the credit card payment terminal and the service providing system is performed in exactly the same procedure as the session establishment process between the personal credit terminal and the service providing system.

[0851] FIG. 79 shows a procedure of session establishment processing when connecting to a service providing system from a credit card payment terminal, and FIGS. 81 (a), (b), and (c) show a credit card payment terminal and service provision. Indicates the content of the message exchanged with the system.

[0852] FIG. 80 shows a procedure of session establishment processing when connecting to a credit card payment terminal from a service providing system, and FIGS. 81 (d), (e), and (f) show a credit card payment terminal and a service. Shows the content of the message exchanged with the providing system.

[0853] When connecting to the service providing system from the credit card payment terminal, first, the credit card payment terminal 300 calls the service providing system 102 and connects the line (line connection 4805). At this time, the credit settlement terminal 300 transmits a message requesting a line connection of a digital telephone, a call request 4800, to the digital public network 108, and the digital public network 108 sends a message calling a service providing system, a call request 4801. To the service providing system. On the other hand, the service providing system sends a message permitting the call and the incoming call response 4803 to the digital public network, and the digital public network sends a message permitting the line connection and the calling answer 4804 to the credit settlement terminal. The credit payment terminal and the service providing system are connected by a line (line connection 4805).

At this time, messages such as a call request 4800, a call request 4801, a call response 4803, and a call response 4804 exchanged between the credit settlement terminal and the digital public network, and between the digital public network and the service providing system. Depends on the protocol for line connection from the digital telephone via the digital telephone communication line 110, the digital public network 108, and the digital communication line 109.

[0855] In the service providing system, the service manager process receives the incoming call request 4801 from the digital public network 108. The service manager process generates a merchant process corresponding to the caller's credit card payment terminal from the phone number information of the caller's credit card payment terminal included in the incoming call request 4801 (process generation 4802), and the generated merchant The process sends an incoming call response 4803 to connect the line to the credit card payment terminal.

When the line between the credit card payment terminal and the merchant process is connected (line connection 4805), the merchant process generates a test message for authenticating the credit card payment terminal, the authentication test A4806, and sends it to the credit card payment terminal. To do.

As shown in FIG. 81 (a), the authentication test A4806 includes header information indicating that the message is the authentication test A4806, the authentication test A header 5000, and the test pattern A5001 which is an arbitrary bit pattern of the merchant. It consists of 5002 encrypted with a public key.

[0858] The credit settlement terminal receives the authentication test A4806, decrypts the code of the test pattern A with the private key of the merchant, is a response message to the authentication test A4806, and is a test message for authenticating the merchant process. Generates Authentication Test A Response 4807, which is, and sends it to the merchant process.

As shown in FIG. 81 (b), the authentication test A response 4807 includes header information indicating that the message is the authentication test A response 4807, the authentication test A response header 5003, and a test pattern in which the encryption is decrypted. It consists of A5004 and 5006, which is an arbitrary bit pattern, test pattern B5005, encrypted with the service provider's public key. That is, certification test A response 4807 includes certification test B for authenticating the merchant process, which corresponds to certification test A for test pattern A.

[0860] The merchant process receives the authentication test A response 4807, matches the test pattern A5001 with the received test pattern A5004, and authenticates the merchant. The merchant's authentication in this case is based on the premise that test pattern A, which is encrypted with the merchant's public key, can only be decrypted by a credit card payment terminal that has the merchant's private key.

The merchant process further decrypts the test pattern B encryption with the service provider's private key to generate a response message to authentication test B, authentication test B response 4808, and sends it to the credit card payment terminal.

As shown in FIG. 81 (c), the authentication test B response 4808 includes header information indicating that the message is the authentication test B response 4808, the authentication test B response header 5007, and a test pattern in which the encryption is decrypted. It consists of B5008 and 5010, which is the session permission message 5009 encrypted with the merchant's public key. The session permission message 5009 is a message that permits a session with the credit card payment terminal, and includes information on communication conditions.

[0863] The credit card payment terminal receives the authentication test B response 4808, collates the received test pattern B5005 with the received test pattern B5008, and authenticates the merchant process. The authentication of the merchant process in this case is based on the assumption that test pattern B encrypted with the service provider's public key can only be decrypted by the service provider system with the service provider's private key.

[0864] The credit card payment terminal further decrypts the encryption of the session permission message with the private key of the merchant, and changes the communication condition with the merchant process to the communication condition of the session permission message.

[0865] By the above processing, the credit card payment terminal and the merchant process authenticate each other and communicate based on the common communication conditions, and the session is established (session establishment 4809).

[0866] When connecting to the credit card payment terminal from the service providing system, the service providing system 102 first calls the credit card payment terminal 300 to connect the line (line connection 4905). At this time, in the service providing system 102, the service manager process generates a merchant process corresponding to the credit payment terminal to which the line is connected (process generation 4900), and the generated merchant process is digitally connected to the digital public network 108. A message requesting a telephone line connection and a call request 4901 are transmitted, and the digital public network 108 sends a message calling a credit settlement terminal and a call request 4902 to the credit settlement terminal. On the other hand, the credit card payment terminal sends a message permitting the call, the incoming call response 4903, to the digital public network, and the digital public network sends a message permitting the line connection, the calling answer 4904, to the merchant process. The merchant process and the credit card payment terminal are connected by a line (line connection 4905). At this time, messages such as a call request 4901, a call request 4902, a call response 4903, and a call response 4904 exchanged between the merchant process and the digital public network, and between the digital public network and the credit settlement terminal are digitally communicated. It depends on the protocol of the line connection via the line 109, the digital public network 108, and the digital telephone communication line 110.

[0867] When the line between the merchant process and the credit payment terminal is connected (line connection 4905), the credit payment terminal generates a test message for authenticating the merchant process, authentication test C4906, and sends it to the merchant process. To do.

As shown in FIG. 81 (d), the authentication test C4906 provides header information indicating that the message is the authentication test C4906, the authentication test C header 5011, and the test pattern C5012 which is an arbitrary bit pattern. It consists of 5013 encrypted with the public key of the person.

[0869] The merchant process receives the authentication test C4906, decrypts the code of the test pattern C with the service provider's private key, is a response message to the authentication test C4906, and authenticates the credit payment terminal. Generates a test message, authentication test C response 4907, and sends it to the credit payment terminal.

As shown in FIG. 81 (e), the authentication test C response 4907 includes header information indicating that the message is the authentication test C response 4907, the authentication test C response header 5014, and a test pattern in which the encryption is decrypted. It consists of C5015 and 5017, which is an arbitrary bit pattern, test pattern D5016, encrypted with the merchant's public key. That is, the authentication test C response 4907 includes an authentication test D for authenticating the credit card payment terminal, which corresponds to the authentication test C for the test pattern C.

[0871] The credit card payment terminal receives the authentication test C response 4907, collates the received test pattern C5012 with the received test pattern C5015, and authenticates the merchant process. The authentication of the merchant process in this case is based on the assumption that test pattern C encrypted with the service provider's public key can only be decrypted by the service provider system with the service provider's private key.

[0872] The credit card payment terminal further decrypts the code of the test pattern D with the private key of the merchant, generates a response message for the authentication test D, the authentication test D response 4908, and sends it to the merchant process.

As shown in FIG. 81 (f), the authentication test D response 4908 includes header information indicating that the message is the authentication test D response 4908, the authentication test D response header 5018, and a test pattern in which the encryption is decrypted. It consists of D5019 and 5021, which is the session permission message 5020 encrypted with the service provider's public key. Session authorization message 5020 is a message permitting a session with the merchant process, which contains information about communication conditions.

[0874] The merchant process receives the authentication test D response 4908, matches the test pattern D5016 with the received test pattern D5019, and authenticates the credit payment terminal. The credit card payment terminal authentication in this case is based on the premise that the test pattern D encrypted with the merchant's public key can only be decrypted by the credit card payment terminal with the merchant's private key.

The merchant process further decrypts the session authorization message with the service provider's private key and changes the communication conditions with the credit card payment terminal to the communication conditions of the session authorization message.

[0876] By the above processing, the merchant process and the credit card payment terminal authenticate each other and communicate based on the common communication conditions, and the session is established (session establishment 4909).

Next, the content of the message exchanged between the personal credit terminal 100 and the credit payment terminal 300 with the service providing system 102 in the processing of remote access will be described. The remote access process is a process of downloading data from the service providing system 102 when trying to access data existing at the remote address. Hereinafter, this process is referred to as a remote access process.

[0878] FIG. 82 (a) shows a procedure of remote access processing by the personal credit terminal 100, and FIGS. 83 (a) and 83 (b) are messages exchanged between the personal credit terminal 100 and the user process. Shows the contents of. If the data to be accessed exists at the remote address, the personal credit terminal 100 spawns a remote access process and initiates the remote access process. First, a session with the service providing system 102 is established to generate a remote access request 5100, a message requesting data from the user process of the service providing system 102, and send it to the user process.

As shown in FIG. 83 (a), the remote access request 5100 includes header information indicating that the message is a remote access request 5100, a remote access request header 5200, a data address 5201 indicating a remote address, and a user. The data consisting of ID5202 and the issue date and time 5203 indicating the date and time when this remote access request 5100 was issued is digitally signed by the user 5204 and sealed to the service provider.

[0880] The user process of the service providing system 102 receives the remote access request 5100, decrypts the code, checks the digital signature, and sends the requested data to the personal credit terminal 100, the remote access data 5101. Is generated and sent to the personal credit terminal 100.

As shown in FIG. 83 (b), the remote access data 5101 includes header information indicating that the message is remote access data 5101, remote access data header 5208, requested data 5209, and a service provider. The data consisting of ID5210 and the issue date and time 5211 indicating the issue date and time of this remote access data 5101 is digitally signed by the service provider and sealed to the user.

[0882] The personal credit terminal 100 receives the remote access data 5101, decrypts the code, checks the digital signature, stores it in the temporary area, and accesses the data.

Similarly, FIG. 85 (a) shows a procedure for remote access processing by the credit card payment terminal 300, and FIGS. 86 (a) and 86 (b) are exchanges between the credit card payment terminal 300 and the merchant process. Indicates the content of the message. If the data to be accessed exists at the remote address, the credit card payment terminal 300 generates a remote access process and starts the remote access process. First, a session with the service providing system 102 is established to generate a remote access request 5400, a message requesting data from the merchant process of the service providing system 102, and send it to the merchant process.

As shown in FIG. 86 (a), the remote access request 5400 includes header information indicating that the message is a remote access request 5400, a remote access request header 5500, a data address 5501 indicating a remote address, and a merchant. The data consisting of ID5502 and the issue date and time 5503, which indicates the date and time when this remote access request 5400 was issued, was digitally signed by the merchant 5504 and sealed to the service provider.

[0885] The merchant process of the service providing system 102 receives the remote access request 5400, decrypts the code, checks the digital signature, and sends the requested data to the credit card payment terminal 300, the remote access data 5401. Generate and send to the credit card payment terminal 300.

As shown in FIG. 86 (b), the remote access data 5401 includes header information indicating that the message is remote access data 5401, a remote access data header 5508, requested data 5509, and a service provider. The data consisting of ID5510 and the issue date and time 5511 indicating the date and time when this remote access data 5401 was issued is digitally signed by the service provider and sealed to the merchant.

[0887] The credit card payment terminal 300 receives the remote access data 5401, decrypts the code, checks the digital signature, stores it in the temporary area, and accesses the data.

Next, the content of the message exchanged between the personal credit terminal 100 and the credit payment terminal 300 with the service providing system 102 in the process of data update will be described. The data update process is a process in which the service providing system updates the contents of the RAM 1502 of the personal credit terminal 100, or the RAM 22502 and the hard disk 22503 of the credit card payment terminal. Hereinafter, this process is referred to as a data update process.

[0889] FIG. 82 (b) shows a procedure of data update processing in the personal credit terminal 100, and FIGS. 83 (c) to (f) and 84 (a) show the personal credit terminal 100 and the service providing system. Shows the content of the message exchanged with 102.

[0890] When the value of the clock counter matches the update time register, the personal credit terminal 100 generates a data update process and starts the data update process. The personal credit terminal 100 first establishes a session with the service providing system 102, generates a message requesting the user process of the service providing system 102 to perform data update processing, a data update request 5102, and sends the data update request 5102 to the user process. ..

As shown in FIG. 83 (c), the data update request 5102 contains header information indicating that the message is a data update request 5102, a data update request header 5216, a user ID 5217, and the data update request 5102. The data consisting of the issue date and time 5218, which indicates the issue date and time, is digitally signed by the user and sealed to the service provider.

[0892] The user process of the service providing system 102 receives the data update request 5102, decrypts the code, checks the digital signature, and generates a data update response 5103, a message indicating that the request is ready. Then send it to the personal credit terminal 100.

As shown in FIG. 83 (d), the data update response 5103 includes header information indicating that the message is the data update response 5103, a data update response header 5223, a service provider ID 5224, and the data update response. The data consisting of the issue date and time 5225, which indicates the date and time when the 5103 was issued, is digitally signed by the service provider and sealed to the user.

[0894] The personal credit terminal 100 receives the data update response 5103, decrypts the code, checks the digital signature, and generates a message to upload the data of the RAM 1502 to the service providing system 102, the upload data 5104. Send to the service providing system.

As shown in FIG. 83 (e), the upload data 5104 includes header information indicating that the message is upload data 5104, upload data header 5230, compressed data of RAM1502, terminal data 5231, and the like. The data consisting of the user ID 5232 and the issue date and time 5233 indicating the date and time when the upload data 5104 was issued is digitally signed by the user and sealed to the service provider.

[0896] The user process of the service providing system 102 receives the uploaded data 5104, decrypts the code, and checks the digital signature. Then, the compressed terminal data 5231 is decompressed and collated with the terminal data 24006 on the user information server 402 and the data managed by other user data management information 24000.

[0897] Then, a message for generating new terminal data and updating the data of the personal credit terminal 100, update data 5105, is generated and transmitted to the personal credit terminal 100.

As shown in FIG. 83 (f), the update data 5105 includes header information indicating that the message is update data 5105, update data header 5238, compressed data of new terminal data, terminal data 5239, and the like. The data consisting of the service provider ID 5240 and the issue date and time 5241 indicating the date and time when this update data 5105 was issued is digitally signed by the service provider and sealed to the user.

[0899] The personal credit terminal 100 receives the update data 5105, decrypts the code, checks the digital signature, decompresses the compressed terminal data 5239, and updates the data in the RAM 1502.

[0900] In the generation of new terminal data, the user process of the service providing system 102 compares the access times of each credit card when the capacity of the physical data area 21812 is insufficient, and the credit card having the latest access time A local address is assigned to the object data address of, and the usage time of each usage information is compared, and a local address is assigned to the usage information address of the usage information whose usage time is the latest. If it is necessary to upgrade the program of the personal credit terminal, the data in the basic program area is updated.

[0901] Further, when the user process of the service providing system 102 collates the uploaded data with the terminal data, if an unauthorized alteration of the data is found, the personal credit terminal is used instead of the update data 5105. Generates a message to stop 100 functions, a function stop command 5105', and sends it to the personal credit terminal 100.

As shown in FIG. 84 (a), the function stop command 5105'has header information indicating that the message is the function stop command 5105', the function stop command header 5300, the service provider ID 5301, and this function. The data consisting of the issue date and time 5302, which indicates the date and time when the stop instruction 5105'was issued, is digitally signed by the service provider and sealed to the user.

[0903] In this case, the personal credit terminal 100 that has received the outage command 5105'decrypts the code, checks the digital signature, changes the terminal status 21902 to "unusable", and puts it in an unusable state. Become.

By this data update process, information that is relatively frequently used is stored in the RAM of the personal credit terminal, the program of the personal credit terminal is kept at the latest version, and the terminal data is stored. Unauthorized tampering is prevented.

Similarly, FIG. 85 (b) shows a procedure of data update processing in the credit card payment terminal 300, and FIGS. 86 (c) to (f) and 84 (a) show the service provision with the credit card payment terminal 300. Shows the content of the message exchanged with system 102.

[0906] When the value of the clock counter matches the update time register, the credit settlement terminal 300 generates a data update process and starts the data update process. First, the credit payment terminal 300 establishes a session with the service providing system 102, generates a message requesting the merchant process of the service providing system 102 to perform the data update process, and generates a data update request 5402, and sends the message to the merchant process.

As shown in FIG. 86 (c), the data update request 5402 includes header information indicating that the message is a data update request 5402, a data update request header 5516, a merchant ID 5517, and this data update request 5402. The data consisting of the issue date and time 5518, which indicates the issue date and time, is digitally signed by the merchant and sealed to the service provider.

The merchant process of service delivery system 102 receives the data update request 5402, decrypts the cipher, checks the digital signature, and generates a data update response 5403, a message indicating that the request is ready. Then send it to the credit card payment terminal 300.

As shown in FIG. 86 (d), the data update response 5403 includes header information indicating that the message is a data update response 5403, a data update response header 5523, a service provider ID 5524, and this data update response. The data consisting of the issue date and time 5525, which indicates the date and time when 5403 was issued, is digitally signed by the service provider and sealed to the merchant.

[0910] The credit payment terminal 300 receives the data update response 5403, decrypts the code, checks the digital signature, uploads the data of the RAM 22502 and the hard disk 22503 to the service providing system 102, and uploads the data 5404. Generate and send to the service provider system.

As shown in FIG. 86 (e), the upload data 5404 is header information indicating that the message is the upload data 5404, the upload data header 5530, the compressed data of the RAM 22502 and the hard disk 22503, and the terminal. The data consisting of the data 5531, the merchant ID 5532, and the issue date and time 5533 indicating the date and time when the upload data 5404 was issued is digitally signed by the merchant and sealed to the service provider.

[0912] The merchant process of the service providing system 102 receives the uploaded data 5404, decrypts the encryption, and checks the digital signature. Then, the compressed terminal data 5531 is decompressed and collated with the terminal data 24104 on the merchant information server 403 and the data managed by the other merchant data management information 24100.

[0913] Then, a new terminal data is generated, a message for updating the data of the credit card payment terminal 300, and update data 5405 are generated and transmitted to the credit card payment terminal 300.

As shown in FIG. 86 (f), the update data 5405 includes header information indicating that the message is update data 5405, update data header 5538, compressed data of new terminal data, terminal data 5539, and the like. The data consisting of the service provider ID 5540 and the issue date and time 5541 indicating the date and time when this update data 5405 was issued is digitally signed by the service provider and sealed to the merchant.

[0915] The credit card payment terminal 300 receives the update data 5405, decrypts the code, checks the digital signature, decompresses the compressed terminal data 5539, and updates the data in the RAM 22502 and the hard disk 22503.

[0916] In the generation of new terminal data, the merchant process of the service providing system 102 compares the usage times of each sales information when the capacity of the hard disk 22503 of the credit payment terminal is insufficient, and the usage time is the latest. Assign a local address to the sales information address of the sales information. If it is necessary to upgrade the program of the credit card payment terminal, the data in the basic program area is updated.

[0917] Further, when the merchant process of the service providing system 102 collates the uploaded data with the terminal data, if an unauthorized alteration of the data is found, the credit payment terminal 300 is used instead of the update data 5405. Generates a message to stop the function of, the function stop command 5405', and sends it to the credit settlement terminal 300.

As shown in FIG. 87 (a), the function stop command 5405'has header information indicating that the message is the function stop command 5405', the function stop command header 5600, the service provider ID 5601, and this function. The data consisting of the issue date and time 5602, which indicates the date and time when the stop order 5405'was issued, was digitally signed by the service provider and sealed to the merchant.

[0919] In this case, the credit card payment terminal 300 that has received the outage command 5405'decrypts the code, checks the digital signature, changes the terminal status 22902 to "unusable", and becomes unusable. ..

By this data update process, information that is relatively frequently used is stored in the RAM and the hard disk of the credit payment terminal, the program of the credit payment terminal is kept at the latest version, and the terminal is also used. Unauthorized falsification of data is prevented.

[0921] Next, the content of the message exchanged between the personal credit terminal 100 and the credit payment terminal 300 with the service providing system 102 in the process of compulsory data update will be described. The forced data update process is performed by the service providing system when the contents of RAM1502 of the personal credit terminal 100 or RAM22502 and hard disk 22503 of the credit card payment terminal need to be updated immediately. It is a process to update. Hereinafter, this process is referred to as a forced data update process.

[0922] FIG. 82 (c) shows the procedure of the forced data update process in the personal credit terminal 100, and FIGS. 83 (e) and 83 (f) and 84 (a) and (b) show the personal credit. It shows the content of the message exchanged between the terminal 100 and the service providing system 102.

[0923] When the service providing system 102 needs to update the RAM data of the personal credit terminal 100 immediately, such as when the contract contents with the user are changed, first, the service providing system 102 with the personal credit terminal 100. A session is established to generate a data update instruction 5106, a message instructing the personal credit terminal 100 to perform a forced data update process, and send the data to the personal credit terminal 100.

As shown in FIG. 84 (b), the data update instruction 5106 includes header information indicating that the message is the data update instruction 5106, the data update instruction header 5307, the service provider ID 5308, and the data update instruction. The data consisting of the issue date and time 5309, which indicates the date and time when the 5106 was issued, is digitally signed by the service provider and sealed to the user.

[0925] The personal credit terminal 100 receives the data update command 5106, decrypts the code, checks the digital signature, generates a compulsory data update process, and initiates the compulsory data update process. First, the personal credit terminal 100 generates a message for uploading the data of RAM 1502 to the service providing system 102 and upload data 5107, and transmits the message to the service providing system.

[0926] The user process of the service providing system 102 receives the uploaded data 5107, decrypts the code, and checks the digital signature. Then, the compressed terminal data 5231 is decompressed and collated with the terminal data 24006 on the user information server 402.

[0927] Then, a new terminal data is generated, a message for updating the data of the personal credit terminal 100, and update data 5108 are generated and transmitted to the personal credit terminal 100.

[0928] The personal credit terminal 100 receives the update data 5108, decrypts the code, checks the digital signature, decompresses the compressed terminal data 5239, and updates the data in the RAM 1502.

[0929] Further, when the user process of the service providing system 102 collates the uploaded data with the terminal data, if an unauthorized alteration of the data is found, the personal credit terminal is used instead of the update data 5108. Generates a message to stop 100 functions, a function stop command 5108', and sends it to the personal credit terminal 100.

[0930] In this case, the personal credit terminal 100 that has received the outage command 5108'decrypts the code, checks the digital signature, changes the terminal status 21902 to "unusable", and puts it in an unusable state. Become.

Similarly, FIG. 85 (c) shows the procedure of the forced data update process in the credit payment terminal 300, and FIGS. 86 (e), (f) and 87 (a), (b) are credits. It shows the content of the message exchanged between the payment terminal 300 and the service providing system 102.

[0932] When the service providing system 102 needs to update the data of the RAM and the hard disk of the credit payment terminal 300 immediately, such as when the contract contents with the merchant are changed, first, the credit payment terminal 300 and A message for instructing the credit settlement terminal 300 to perform a forced data update process, a data update instruction 5406, is generated and sent to the credit settlement terminal 300.

As shown in FIG. 84 (b), the data update instruction 5406 includes header information indicating that the message is the data update instruction 5406, the data update instruction header 5607, the service provider ID 5608, and the data update instruction. The data consisting of the issue date and time 5609, which indicates the date and time when the 5406 was issued, is digitally signed by the service provider and sealed to the merchant.

[0934] The credit card payment terminal 300 receives the data update command 5406, decrypts the code, checks the digital signature, generates a compulsory data update process, and starts the compulsory data update process. First, the credit payment terminal 300 generates a message for uploading RAM and hard disk data to the service providing system 102 and upload data 5407, and transmits the upload data to the service providing system.

[0935] The merchant process of the service providing system 102 receives the uploaded data 5407, decrypts the encryption, and checks the digital signature. Then, the compressed terminal data 5531 is decompressed and collated with the terminal data 24104 on the merchant information server 403.

[0936] Then, new terminal data is generated, a message for updating the data of the credit payment terminal 300, update data 5408 is generated, and the data is transmitted to the credit payment terminal 300.

[0937] The credit payment terminal 300 receives the update data 5408, decrypts the code, checks the digital signature, decompresses the compressed terminal data 5539, and updates the data between the RAM and the hard disk.

[0938] Further, when the merchant process of the service providing system 102 collates the uploaded data with the terminal data and finds unauthorized falsification of the data, instead of the update data 5408, the credit payment terminal 300 Generates a message to stop the function of, the function stop command 5408', and sends it to the credit settlement terminal 300.

[0939] In this case, the credit card payment terminal 300 that has received the outage order 5408' decrypts the code, checks the digital signature, changes the terminal status 22902 to "unusable", and becomes unusable. ..

Next, the content of the message exchanged with the service providing system by the personal credit terminal 100 in the data backup process will be described. The data backup process is a process of automatically backing up the contents of the RAM 1502 to the user information server of the service providing system when the battery of the personal credit terminal 100 is low. Hereinafter, this process is referred to as a data backup process.

[0941] Fig. 82 (d) shows the procedure of data backup processing in the personal credit terminal 100, and FIGS. 83 (c) to (f) and 87 (a) show the personal credit terminal 100 and the service providing system. Shows the content of the message exchanged with 102. The data backup process is performed in almost the same procedure as the data update process. However, in the data backup process, the personal credit terminal 100 receives the update data 5112, updates the data in RAM1502, and then changes the terminal status 21902 of the personal credit terminal 100 to "writable". Prohibit input of new data into RAM until the battery capacity is sufficient.

[0942] When the battery capacity becomes Q or less, the personal credit terminal 100 generates a data backup process and starts the data backup process. The personal credit terminal 100 first establishes a session with the service providing system 102, generates a message requesting the user process of the service providing system 102 to perform data update processing, a data update request 5109, and sends the data update request 5109 to the user process. ..

[0943] The user process of the service providing system 102 receives the data update request 5109, decrypts the code, checks the digital signature, and generates a data update response 5110, a message indicating that the request is ready. Then send it to the personal credit terminal 100.

[0944] The personal credit terminal 100 receives the data update response 5110, decrypts the code, checks the digital signature, generates a message for uploading the data of RAM 1502 to the service providing system 102, upload data 5111, and provides the service. Send to the providing system.

The user process of the service providing system 102 receives the uploaded data 5111, decrypts the code, and checks the digital signature. Then, the compressed terminal data 5231 is decompressed and collated with the terminal data 24006 on the user information server 402.

[0946] Then, a new terminal data is generated, a message for updating the data of the personal credit terminal 100, update data 5112 is generated, and the data is transmitted to the personal credit terminal 100.

[0947] The personal credit terminal 100 receives the update data 5112, decrypts the code, checks the digital signature, decompresses the compressed terminal data 5239, and updates the data in the RAM 1502. In addition, change Terminal Status 21902 to "Writable" to prevent new data from entering RAM until the battery is full.

[0948] Further, when the user process of the service providing system 102 collates the uploaded data with the terminal data, if an unauthorized alteration of the data is found, the personal credit terminal is used instead of the update data 5112. Generates a message to stop 100 functions, a function stop command 5112', and sends it to the personal credit terminal 100.

[0949] In this case, the personal credit terminal 100 that has received the outage command 5112'decrypts the code, checks the digital signature, and changes the terminal status 21902 to "unusable" and "unwritable". , Becomes unusable.

[0950] Next, the content of the message exchanged between the devices in the "payment" process will be described.

[0951] FIG. 88 shows a procedure for exchanging messages between devices in the process of payment, which are shown in FIGS. 89 (a) to (f), 90 (a) to (c), 91 (a), and ( b) shows the content of the message exchanged between devices in the "payment" process. FIG. 88 is a diagram in which a portion of a message exchanged between devices is extracted from FIG. 43, and FIGS. 88 and 43 show the same payment process.

[0952] First, when the merchant presses the credit settlement switch of the register 20604, the credit settlement terminal 300 generates a settlement process and starts the processing of "payment". The credit card payment terminal 300 generates a plurality of types of payment offer responses 5701 (20609) and is in a waiting state for receiving the payment offer 5700.

[0953] Next, when the user performs the payment operation 20607, the personal credit terminal 100 generates a payment process and starts the "payment" process. The personal credit terminal 100 generates a payment offer 5700 (20608) and transmits it to the credit payment terminal 300 by infrared communication.

As shown in FIG. 89 (a), the payment offer 5700 includes header information indicating that the message is a payment offer 5700, a payment offer header 5800, a service code 5801, a service provider ID 5802, and a merchant. A request number 5803 arbitrarily generated as a unique number to indicate the transaction, a payment amount 5804 entered by the user, a payment option code 5805 indicating the payment option entered by the user, and a validity period 5806 of this payment offer 20608. The data consisting of the issue date and time 5807, which indicates the date and time when the payment offer 20608 was issued, is digitally signed by the user.

[0955] The credit card payment terminal 300 receives the payment offer 5700, matches the payment amount with the billed amount, matches whether the payment option 5805 is an available option, and responds with a plurality of types of payment offers. From 5701, select the appropriate payment offer response 5701, send it to the personal credit terminal 100 by infrared communication, generate a credit inquiry request 5702 (20610), and provide the service by digital telephone communication system 102. Send to the merchant process.

As shown in FIG. 89 (b), the payment offer response 5701 includes header information indicating that the message is the payment offer response 5701, the payment offer response header 5808, and the personal credit terminal 100 pays the payment offer response 5701. The response message 5809 displayed on the LCD 203 when the message is received, the transaction number 5810 arbitrarily generated as a unique number indicating the transaction with the user, the billing amount 5811, and the telephone number of the service providing system in the service area of the merchant. Digitally sign the merchant for data consisting of the service provider phone number 5812 indicating the date and time of issue of this payment offer response 5701, the validity period 5813 of this payment offer response 5701, the merchant ID 5814, and the issue date and time 5815 indicating the date and time when this payment offer response 5701 was issued. It was done. The service provider phone number 5812 is digitally signed by the service provider, and response message 5809 is a text message set by the merchant's options and may not be set.

As shown in FIG. 89 (c), the authorization request 5702 includes header information indicating that the message is an authorization request 5702, a credit inquiry request header 5816, a payment offer 5700, and a payment offer response 5701. , The data consisting of the person in charge name 5817, the merchant ID 5818, and the issue date and time 5819 indicating the date and time when this authorization request 5702 was issued is digitally signed by the merchant and sealed to the service provider. The person in charge name 5817 is information to be set in the merchant's option, and may not be set.

[0958] On the other hand, the personal credit terminal 100 receives the payment offer response 5701, collates the payment amount 5804 with the billing amount 5811, generates the payment request 5703 (20613), and provides the service by digital radiotelephone communication. Send to the user process of providing system 102.

As shown in FIG. 89 (d), the payment request 5703 includes header information indicating that the message is a payment request 5703, a payment request header 5824, a payment offer 5700, a payment offer response 5701, and a user ID 5825. The data consisting of the issue date and time 5826, which indicates the date and time when the payment request 5703 was issued, is digitally signed by the user and sealed to the service provider.

[0960] The transmission of the credit inquiry request 5702 by the credit card payment terminal 300 to the merchant process and the transmission of the payment request 5703 by the personal credit terminal to the user process may be performed first or at the same time. Good.

The merchant process and the user process of the service delivery system 102 receive the authorization request 5702 and the payment request 20613, respectively, decrypt the code, check the digital signature, and pay the authorization request 5820 and payment, respectively. Send request 5827 and to the service manager process. The service manager process matches the request number with the transaction number and the merchant ID, responds to the authorization request and the payment request, and spawns a service director process with the authorization request 5820 and the payment request 5827. Create a process group to process. The service director process matches the contents of the authorization request 5702 and the payment request 5700, performs the user's authorization inquiry, generates the authorization inquiry response 5840, and the merchant process seals this to the merchant and credits. The inquiry response 5704 (20614) is transmitted to the credit card payment terminal 300 by digital telephone communication.

[0962] As shown in FIG. 89 (e), the authorization inquiry response 5704 performs header information indicating that the message is the authorization inquiry response 5704, the authorization inquiry response header 5831, the transaction number 5832, and the processing of the authorization inquiry. An authorization number 5833 arbitrarily generated as a unique number, an authorization result 5834 indicating the result of a credit inquiry, user personal data 5835 consisting of a user's name, a user's age information, and a user's face photo data, and a merchant. From customer number 5836, which uniquely indicates the user to, 5837, which indicates the validity period of this authorization response 5704, service provider ID 5838, and issue date and time 5839, which indicates the date and time when this authorization response 5704 was issued. The data is digitally signed by the service provider and sealed to the merchant. If there is a problem with the user's credit status as a result of the credit inquiry, the user personal information 5834 is not set, and the customer number 5836 is previously between the user and the merchant, a personal remote credit payment service. It is set when there is a transaction by.

[0963] The credit settlement terminal 300 receives the credit inquiry response 5704, decrypts the code, checks the digital signature, and displays the result of the credit inquiry on the LCD 302.

Next, when the person in charge of the merchant performs the payment processing request operation 20616, the credit payment terminal 300 generates the payment request 5705 (20618) and transmits it to the merchant process by digital telephone communication.

As shown in FIG. 89 (f), the payment request 5705 includes header information indicating that the message is a payment request 5705, a payment request header 5844, a payment offer 5700, a payment offer response 5701, and a service provision. It consists of a reference number 5845 issued by system 102, a validity period 5846 indicating the validity period of this payment request 5705, a contact name 5847, a merchant ID 5848, and an issue date and time 5849 indicating the date and time when this payment request 5705 was issued. The data is digitally signed by the merchant and sealed to the service provider. The person in charge name 5847 is information to be set in the merchant's option, and may not be set.

[0966] The merchant process of the service providing system 102 receives the payment request 5705, decrypts the code, checks the digital signature, and sends the payment request message to the service director process. The service director process collates the contents of the payment request 5705 and the payment request 5700 to generate a payment request 5906 for the payment processing institution, and the payment processing institution process seals this to the payment processing institution and requests the payment. Send as 5706 (20619) to the payment system.

As shown in FIG. 90 (a), the payment request 5706 includes header information indicating that the message is the payment request 5706, the payment request header 5900, and the credit card number 5901 corresponding to the service code specified by the user. The request number 5902 issued by the personal credit terminal 100, the payment amount 5903, the payment option code 5904, the merchant account number 5905 indicating the account number of the merchant, and the transaction number 5906 issued by the credit payment terminal 300. , The data consisting of the validity period 5907 indicating the validity period of this payment request 5706, the service provider ID 5908, and the issue date and time 5909 indicating the date and time when this payment request 5706 was issued is digitally signed by the service provider and settled. It is a sealed letter addressed to the processing institution.

[0968] The payment system 103 receives the payment request 5706, decrypts the code, checks the digital signature, and performs the payment process. Then, the payment completion notification 5707 (20620) is generated and sent to the service providing system 102.

As shown in FIG. 90 (b), the payment completion notification 5707 includes header information indicating that the message is the payment completion notification 5707, the payment completion notification header 5914, and a number uniquely indicating the payment process of the payment system 103. Arbitrarily generated payment number 5915, credit card number 5916, request number 5917, payment amount 5918, payment option code 5919, merchant account number 5920, transaction number 5921, and digital signature of the payment processor. Payment information 5922 for service providers, payment information 5923 for merchants with a digital signature of the payment processing institution, payment information 5924 for users with a digital signature of the payment processing institution, payment processing institution ID 5925, and this payment is completed. The data consisting of the issue date and time 5926, which indicates the date and time when the notification was issued, is digitally signed by the payment processing institution and sealed to the service provider.

The payment processing institution process of the service providing system 102 receives the payment completion notification 5707, decrypts the code, checks the digital signature, and sends the payment completion notification 5927 to the service director process. The service director process generates a payment completion notification 5937 for the merchant from the payment completion notification 5927, and the merchant process seals this to the merchant and uses digital telephone communication as the payment completion notification 5708 (20621) for the merchant. Send to the credit card payment terminal 300.

As shown in FIG. 90 (c), the payment completion notification 5708 includes header information indicating that the message is a payment completion notification 5708, a payment completion notification header 5931, a payment number 5932, and a digital payment processing institution. The signed payment information 5923 for the merchant, the number generated as a unique number to indicate the user to the merchant, the customer number 5933, the decrypted payment request 5850, and the information related to the processing in the service providing system 102. The data consisting of the service provider processing information 5934 shown, the service provider ID 5935, and the issue date and time 5936 indicating the date and time when this payment completion notification 5708 was issued was digitally signed by the service provider and sealed to the merchant. It is a thing. Service provider processing information 5934 is information that is set as an option of the service provider, and may not be set.

[0972] The credit card payment terminal 300 receives the payment completion notification 5708, decrypts the code, checks the digital signature, generates a receipt 5709 (20622), and sends it to the merchant process by digital telephone communication.

As shown in FIG. 91 (a), the receipt 5709 includes header information indicating that the message is receipt 5709, a receipt header 6000, a product name 6001 indicating the name of the product sold, and a merchant. Shows sales information 6002, payment number 6003, transaction number 6004, payment offer 5700, contact name 6005, merchant ID 6006, and the date and time when this receipt 5709 was issued. The data consisting of the issue date and time of 6007 is digitally signed by the merchant and sealed to the service provider. The sales information 6002 and the person in charge name 6005 are information set by the merchant's option, and may not be set.

The merchant process of service delivery system 102 receives receipt 5709, decrypts the code, checks the digital signature, and sends receipt 6008 to the service director process. The service director process generates a receipt 6016 for the user from the receipt 6008, and the user process seals this to the user and uses it as a receipt 5710 (20624) for digital radiotelephone communication, personal credit terminal. Send to 100.

As shown in FIG. 91 (b), the receipt 5710 includes the header information indicating that the message is the receipt 5710, the receipt header 6012, the decrypted receipt 6008, and the settlement processing institution. Digitally signed payment information 5924 for users, service provider processing information 6013 indicating information on processing in the service providing system 102, service provider ID 6014, and issuance date and time 6015 indicating the date and time when this receipt 5710 was issued. The data consisting of the data is digitally signed by the service provider and sealed to the user. The service provider processing information 6013 is information set by the option of the service provider, and may not be set.

[0976] The personal credit terminal 100 receives the receipt 5710, decrypts the code, checks the digital signature, and displays the contents on the LCD 203.

[0977] Next, the content of the message exchanged between the devices in the "cancel" process will be described.

FIG. 92 shows a procedure for exchanging messages between devices in the cancel process, and FIGS. 93 (a) to 93 (f) show the contents of messages exchanged between devices in the cancel process. Shown. FIG. 92 is a diagram in which a portion of a message exchanged between devices is extracted from FIG. 9, and FIGS. 92 and 9 show the same cancellation process.

[0979] First, when the person in charge of the merchant performs the cancel operation 901, the credit card payment terminal 300 generates a cancel process and starts the "cancel" process. The credit card payment terminal 300 generates a cancellation request 6100 (903) from the payment completion notification of the transaction to be canceled, and sends it to the merchant process of the service providing system 102 by digital telephone communication.

On the other hand, when the user performs the cancel operation 904, the personal credit terminal 100 generates a cancel process and starts the "cancel" process. The personal credit terminal 100 generates a cancellation request 6101 (906) from the receipt of the transaction to be canceled and transmits it to the user process of the service providing system 102 by digital radiotelephone communication.

As shown in FIG. 93 (a), the cancellation request 6100 includes header information indicating that the message is a cancellation request 6100, a cancellation request header 6200, a payment completion notification 5937 in which the code is decrypted, and this cancellation. The data consisting of the validity period 6201 indicating the validity period of the request 6100, the contact person name 6202, the merchant ID 6203, and the issue date and time 6204 indicating the date and time when the cancellation request 6100 was issued is digitally signed by the merchant to provide the service. It is a sealed letter addressed to the person. The person in charge name 6216 is information to be set in the merchant's option, and may not be set.

Further, as shown in FIG. 93 (b), the cancellation request 6101 includes header information indicating that the message is the cancellation request 6101, the cancellation request header 6209, and the decrypted receipt 6016. The data consisting of the validity period 6210 indicating the validity period of the cancellation request 6101, the user ID 6211, and the issuance date and time 6212 indicating the date and time when the cancellation request 6101 was issued is digitally signed by the user and sealed to the service provider. It is the one that was done.

[0983] The transmission of the cancellation request 6100 by the credit card payment terminal 300 to the merchant process and the transmission of the cancellation request 6101 by the personal credit terminal to the user process may be performed first or at the same time. Good.

[0984] The merchant process and the user process of the service providing system 102 receive the cancellation request 6100 and the cancellation request 6101, respectively, decrypt the code, check the digital signature, and cancel request 6205 and cancellation request 6213, respectively. To the service manager process. The service manager process matches the request number with the transaction number and the merchant ID, associates the cancel request 6205 with the cancel request 6213, creates a service director process, and cancels the cancellation request 6205 and the cancellation request 6213. Create a process group to process. The service director process collates the contents of the cancellation request 6205 and the cancellation request 6213 to generate a cancellation request 6221 for the payment processing institution, and the payment processing institution process seals this to the payment processing institution and processes the payment. It is sent to the payment system 103 as a cancellation request 6102 (907) to the institution.

As shown in FIG. 93 (c), the cancellation request 6102 includes header information indicating that the message is the cancellation request 6102, the cancellation request header 6217, the decrypted payment completion notification 5927, and the cancellation. The data consisting of the validity period 6218 indicating the validity period of request 6102, the service provider ID 6219, and the issue date and time 6220 indicating the date and time when this cancellation request 6102 was issued is digitally signed by the service provider and addressed to the settlement processing institution. It is a sealed letter.

[0986] The payment system 103 receives the cancellation request 6102, decrypts the code, checks the digital signature, and performs the cancellation process. Then, the cancellation completion notification 6103 (908) is generated and sent to the payment processing institution process of the service providing system 102.

As shown in FIG. 93 (d), the cancellation completion notification 6103 uniquely displays the header information indicating that the message is the cancellation completion notification 6103, the cancellation completion notification header 6225, and the cancellation process performed by the payment system 103. The number shown, the cancellation number 6226, the decrypted cancellation request 6221, the cancellation information 6227 for the service provider with the digital signature of the payment processing institution, and the cancellation information 6228 for the merchant with the digital signature of the payment processing institution. A service that digitally signs the payment processing institution for data consisting of cancellation information 6229 for users who have digitally signed the payment processing institution, payment processing institution ID 6230, and issuance date and time 6231 indicating the date and time when this payment completion notification was issued. It is a sealed letter addressed to the provider.

The payment processing agency process of the service providing system 102 receives the cancellation completion notification 6103, decrypts the code, checks the digital signature, and sends the cancellation completion notification 6132 to the service director process. The service director process generates a cancellation completion notification 6241 and a cancellation processing receipt 6250 from the cancellation completion notification 6132. The merchant process seals the cancellation completion notification 6241 to the merchant and sends it to the credit card payment terminal 300 as the cancellation completion notification 6104 (909), and the user process seals the cancellation processing receipt 6250 to the user and cancels. It is sent to the personal credit terminal 100 as a processing receipt 6105 (910).

As shown in FIG. 93 (e), the cancellation completion notification 6104 decrypts the code, the header information indicating that the message is the cancellation completion notification 6104, the cancellation completion notification header 6236, the cancellation number 6237, and the code. Issued cancellation request 6205, payment information 6228 for merchants digitally signed by the payment processing institution, service provider processing information 6238 showing information about processing in the service providing system, service provider ID 6239, and this cancellation completion notification 6104. The data consisting of the issue date and time 6240, which indicates the date and time when the information was issued, was digitally signed by the service provider and sealed to the merchant. The service provider processing information 6238 is information set by the option of the service provider, and may not be set.

As shown in FIG. 93 (f), the cancellation processing receipt 6105 contains header information indicating that the message is the cancellation processing receipt 6105, the cancellation processing receipt header 6245, the cancellation number 6246, and the code. Decrypted cancellation request 6213, digitally signed payment information 6229 of the payment processing institution, service provider processing information 6247 showing information about processing in the service providing system, service provider ID 6248, and this cancellation processing receipt. The data consisting of the issue date and time 6249, which indicates the date and time when the document 6105 was issued, is digitally signed by the service provider and sealed to the user. The service provider processing information 6247 is information set by the option of the service provider, and may not be set.

[0991] The credit card payment terminal 300 receives the cancellation completion notification 6104, decrypts the code, checks the digital signature, and displays the contents on the LCD 302. On the other hand, the personal credit terminal 100 also receives the cancellation processing receipt 6105, decrypts the code, checks the digital signature, and displays the contents on the LCD 203.

[0992] Next, the content of the message exchanged between the devices in the processing of the "customer service call" will be described.

[0993] Fig. 94 (a) shows the procedure for exchanging messages between devices in the processing of the customer service call, and FIGS. 95 (a) to 95 (e) show the procedure between the devices in the processing of the customer service call. Indicates the content of the message to be exchanged with. FIG. 94 (a) is a diagram in which the part of the message exchanged between the devices is extracted from FIG. 45 (a), and FIGS. 94 (a) and 45 (a) are the same customer service call. Indicates processing.

[0994] First, when the person in charge of the merchant performs the customer service call operation 21200, the credit settlement terminal 300 generates a customer service call process and starts processing the "customer service call". The credit card payment terminal 300 generates a customer service call request 6300 (21202) and sends it to the merchant process of the service providing system 102 by digital telephone communication.

As shown in FIG. 95 (a), the customer service call request 6300 includes header information indicating that the message is a customer service call request 6300, a customer service call request header 6400, and a number indicating the user. The customer number 6401 issued during the "payment" process, the request number 6402 that uniquely indicates this customer service call request, the contact name 6403, the merchant ID 6404, and the date and time when this customer service call request 6300 was issued. The data consisting of the issue date and time 6405 shown is digitally signed by the merchant and sealed to the service provider. The person in charge name 6403 is information to be set in the merchant's option, and may not be set.

The merchant process of the service delivery system 102 receives the customer service call request 6300, decrypts the encryption, checks the digital signature, and sends the customer service call request 6406 to the service manager process. The service manager process spawns a service director process to spawn a process group that handles customer service call request 6406. The service director process determines the user corresponding to the customer number from the customer table, collates it with the user's access control information, and generates the customer service call 6417 and the customer service call answer 6426. The user process seals the customer service call 6417 to the user and sends it as customer service call 6301 (21203) to the user's personal credit terminal 100, and the merchant process sends the customer service call answer 6426 to the merchant. It is sealed and sent to the credit settlement terminal 300 as a customer service call answer 6302 (21204).

As shown in FIG. 95 (b), the customer service call 6301 includes header information indicating that the message is the customer service call 6301, a customer service call header 6410, a contact name 6411, and a merchant ID 6412. A digital signature of the service provider for data consisting of the merchant name 6413, the request number 6414 set by the credit payment terminal 300, the service provider ID 6415, and the issue date and time 6416 indicating the date and time when this customer service call 6301 was issued. It is done and sealed to the user. The person in charge name 6411 is the information to be set in the merchant's option, and may not be set.

As shown in FIG. 95 (c), the customer service call response 6302 includes header information indicating that the message is a customer service call response 6302, a customer service call response header 6421, and a response from the service providing system 102. A digital signature of the service provider for data consisting of message 6422, request number 6423 set by the credit payment terminal 300, service provider ID 6424, and issue date and time 6425 indicating the date and time when this customer service call answer 6302 was issued. It was done and sealed to the merchant.

[0999] The credit card payment terminal 300 receives the customer service call answer 6302, decrypts the code, checks the digital signature, and displays "calling".

[1000] The personal credit terminal 100 receives the customer service call 6301, decrypts the code, checks the digital signature, generates the customer service call process, and starts processing the "customer service call". The personal credit terminal 100 first outputs a ringtone from the speaker to notify the user of the incoming call. Then, when the user performs the call operation 21207, the personal credit terminal 100 generates an incoming call answering 6303 (21208) and transmits it to the user process of the service providing system 102.

[1001] The user process of the service providing system 102 receives the incoming call answering 6303, decrypts the code, and sends the incoming call answering 6433 to the service director process. The service director process generates a call answer 6440 from the incoming call answer 6433, and the merchant process seals it to the merchant and sends it to the credit settlement terminal 300 as a call answer 6304 (21210).

[1002] The credit card payment terminal 300 receives the call answer 6304, decrypts the code, and enters a voice call state between the credit card payment terminal 300 and the personal credit terminal 100.

As shown in FIG. 95 (d), the incoming call answering 6303 includes header information indicating that the message is an incoming call answering 6303, an incoming call answering header 6430, a request number 6431 set by the credit settlement terminal 300, and voice. The data consisting of the data encryption key 6432 is sealed to the service provider.

Further, as shown in FIG. 95 (e), the call response 6304 includes header information indicating that the message is the call response 6304, the call response header 6437, and the request number 6438 set by the credit settlement terminal 300. , The data consisting of the voice data encryption key 6439 is sealed to the merchant.

[1005] The voice data encryption key 6432 and the voice data encryption key 6439 are common encryption keys for encrypting voice data at the time of a call, and this voice data encryption key is used for voice data encryption of the personal credit terminal 100. The key register (CRYPT) 21613 and the voice data encryption key register (CRYPT) 22611 of the credit settlement terminal 300 are set, and the personal credit terminal 100 and the credit settlement terminal 300 encrypt the voice data to make a voice call. If the voice data is not encrypted, this voice data encryption key is not set.

[1006] Next, the content of the message exchanged between the devices in the processing of the "inquiry call" will be described.

[1007] Fig. 94 (b) shows the procedure for exchanging messages between devices in the processing of "inquiry call", and FIGS. 96 (a) to 96 (e) are exchanged between devices in the processing of "inquiry call". Indicates the content of the message to be sent. FIG. 94 (b) is a diagram in which the part of the message exchanged between devices is extracted from FIG. 45 (b), and FIGS. 94 (b) and 45 (b) process the same inquiry call. Shown.

[1008] First, when the user performs the inquiry call operation 21213, the personal credit payment terminal 100 generates an inquiry call process and starts processing the "inquiry call". The personal credit payment terminal 100 first generates an inquiry call request 6307 (21215) and transmits it to the user process of the service providing system 102 by digital wireless telephone communication.

As shown in FIG. 96 (a), the inquiry call request 6307 includes header information indicating that the message is the inquiry call request 6307, the inquiry call request header 6500, the merchant ID 6501, the contact person name 6502, and the like. The data consisting of request number 6503, which uniquely indicates this inquiry call request, user ID 6504, and issue date and time 6505, which indicates the date and time when this inquiry call request 6307 was issued, is digitally signed by the user and sealed to the service provider. It is a digital version. The person in charge name 6503 is information set in the merchant's option when processing "payment", and may not be set.

[1010] The user process of the service providing system 102 receives the inquiry call request 6307, decrypts the code, checks the digital signature, and sends the inquiry call request 6506 to the service manager process. The service manager process spawns a service director process to spawn a process group that handles query call request 6506. The service director process consults the merchant's customer table to generate inquiry call 6515 and inquiry call answer 6524. The merchant process seals the inquiry call 6515 to the merchant and sends it to the credit card payment terminal 300 as inquiry call 6307 (21216), and the user process seals the inquiry call answer 6524 to the user and makes the inquiry call answer 6308. As (21217), it is transmitted to the personal credit payment terminal 100.

As shown in FIG. 96 (b), the inquiry call 6307 is set by the header information indicating that the message is the inquiry call 6307, the inquiry call header 6510, the customer number 6511, and the personal credit terminal 100. The data consisting of request number 6512, service provider ID 6513, and issue date and time 6514 indicating the date and time when this inquiry call 6307 was issued is digitally signed by the service provider and sealed to the merchant.

As shown in FIG. 96 (c), the inquiry call response 6308 includes header information indicating that the message is the inquiry call response 6308, the inquiry call response header 6519, and the response message 6520 from the service providing system 102. , The service provider digitally signs the data consisting of the request number 6521 set by the personal credit payment terminal 100, the service provider ID 6522, and the issue date and time 6523 indicating the date and time when this inquiry call answer 6308 was issued. It is a sealed letter addressed to the user.

[1013] The personal credit terminal 100 receives the inquiry call answer 6308, decrypts the code, checks the digital signature, and displays "calling".

[1014] The credit card payment terminal 300 receives the inquiry call 6307, decrypts the code, checks the digital signature, generates an inquiry call process, and starts processing the "inquiry call". The credit card payment terminal 300 first outputs a ringtone from the speaker to notify the merchant of the incoming call. Then, when the merchant performs the call operation 1220, the credit settlement terminal 300 generates an incoming call answering 6309 (21221) and sends it to the merchant process of the service providing system 102.

[1015] The merchant process of the service providing system 102 receives the incoming call answering 6309, decrypts the encryption, and sends the incoming call answering 6531 to the service director process. The service director process generates a call answer 6538 from the incoming call answer 6531, and the user process seals this to the user and sends it to the personal credit terminal 100 as the call answer 6310 (21223).

[1016] The personal credit terminal 100 receives the call answer 6310, decrypts the code, and enters a voice call state between the personal credit terminal 100 and the credit payment terminal 300.

As shown in FIG. 96 (d), the incoming call answering 6309 includes header information indicating that the message is an incoming call answering 6309, an incoming call answering header 6528, and a request number 6529 set by the personal credit settlement terminal 100. , The data consisting of the voice data encryption key 6530 is sealed to the service provider.

Further, as shown in FIG. 96 (e), the call response 6310 includes header information indicating that the message is the call response 6310, the call response header 6535, and the request number set by the personal credit settlement terminal 100. The data consisting of 6536 and the voice data encryption key 6537 is sealed to the user.

[1019] The voice data encryption key 6530 and the voice data encryption key 6537 are common encryption keys for encrypting voice data during a voice call, and this voice data encryption key is used as the voice data of the personal credit terminal 100. Set the encryption key register (CRYPT) 21613 and the voice data encryption key register (CRYPT) 22611 of the credit payment terminal 300, and the personal credit terminal 100 and the credit payment terminal 300 encrypt the voice data to make a voice call. .. If the voice data is not encrypted, this voice data encryption key is not set.

Next, session establishment process, remote access process, data update process, forced data update process, data backup process, "payment" process, "cancel" process, "customer service call" process, and " The service manager process, service director process, user process, merchant process, and payment of the personal credit terminal 100, the credit payment terminal 300, the payment system 103, and the service providing system 102 in each processing of the "inquiry call" processing. The details of the processing performed by each process of the processing engine process will be described.

[1021] The overall processing flow of the personal credit terminal and the credit payment terminal is as described in the description of FIGS. 51 and 61, respectively. Personal credit terminals and credit payment terminals have session establishment processing, remote access processing, data update processing, forced data update processing, data backup processing, "payment" processing, "cancellation" processing, and "customer service call". The processes corresponding to each of the processes of "" and "inquiry call" are registered in the process list, and each process is executed by the process of each process of the main routine.

[1022] On the other hand, the service providing system executes each process by the coordinated processing of five types of processes: the service manager process, the service director process, the user process, the merchant process, and the settlement processing institution process.

[1023] Of the five types of processes, first, the service manager process performs other processes such as the service director process, the user process, the merchant process, and the settlement processing institution process according to the processing flow shown in FIGS. 97 to 98. to manage.

[1024] The service manager process is always running, usually in step 6600, waiting for a call request message from a personal credit terminal or credit card payment terminal, and a message from each process. .. When the service manager process receives the message, it performs the processing according to the message type shown in steps 6601 to 6618 and steps 6700 to 6709, and returns to step 6600.

[1025] When the message is an incoming call request, the service manager process performs a process generation process for generating a user process corresponding to the caller or a merchant process in step 6606.

[1026] If the message is a credit inquiry request from the merchant process, the service manager process first registers the payment request corresponding to the received credit inquiry request in the message list 4405 in step 6607. If it is not registered, in step 6608, register the received message in the message list, and if it is registered, in step 6609, generate a service director process to service. -Create a process group consisting of the director process, the user process, and the merchant process, remove the registered message from the message list in step 6610, and request and pay the service director process credit inquiry in step 6611. Send a request and.

[1027] If the message is a payment request from a user process, the service manager process first registers the credit inquiry request corresponding to the received payment request in message list 4405 in step 6612. If it is not registered, register the received message in the message list in step 6613, and if it is registered, proceed to step 6609, and if the message is a credit inquiry request. Perform the same process.

[1028] If the message is a cancellation request from the merchant process, the service manager process first sees in message list 4405 in step 6614 a cancellation request from the user process corresponding to the received cancellation request. Check if is registered, and if not, in step 6615, add the received message to the message list, and if so, in step 6616, generate a service director process. , Create a process group with the service director process, the user process, and the merchant process, remove the registered message from the message list in step 6617, and in step 6618 to the service director process, the merchant process. Send a cancellation request from and a cancellation request from the user process.

[1029] If the message is a cancellation request from a user process, the service manager process first sees in message list 4405 in step 6619 a cancellation request from the merchant process corresponding to the received cancellation request. Check if is registered, and if not, add the received message to the message list in step 6620, if so, go to step 6616 and cancel the message from the merchant process. Performs the same processing as when it was a request.

[1030] In registering the received message in the message list in step 6608, step 6613, step 6615, and step 6620, matching data is generated from the merchant ID, transaction number, and request number included in the message, and the message is generated. To the message list.

[1031] Further, in the process group generation in step 6609 and step 6616, first, the service director process is generated, the process group management information and the service director process management information are registered, and further, the user process management is performed. The information and the merchant process management information are updated to generate a process group consisting of the service director process, the user process, and the merchant process.

[1032] If the message is a customer service call request from the merchant process, the service manager process spawns a service director process in step 6704 to include the service director process and the merchant process. Creates a process group with, and in step 6705 sends a customer service call request to the service director process.

[1033] In the process group generation in step 6704, first, the service director process is generated, the process group management information and the service director process management information are registered, and the merchant process management information is updated. , Create a process group with the service director process and the merchant process.

[1034] If the message is an inquiry call request from a user process, the service manager process generates a service director process in step 6706, and the service director process and the user process are involved. Create a process group and in step 6707 send a query call request to the service director process.

[1035] In the process group generation in step 6706, first, the service director process is generated, the process group management information and the service director process management information are registered, and further, the user process management information is updated. , Create a process group with the service director process and the user process.

[1036] If the message is a member process request from the service director process, the service manager process adds the requested process to the process group of the service director process in step 6708. Perform process generation processing. At this time, if necessary, the service manager process spawns the requested process.

[1037] If the message is a process erasure request, the service manager process performs a process erasure process for erasing the requested process in step 6709. At this time, the service manager process updates the process management information of each process, the process group management information 4404, and the message list 4405 as necessary.

[1038] Further, the process generation process of step 6606 is performed according to the process flow shown in FIG. 99.

[1039] The service manager process first obtains the caller's telephone number information contained in the incoming call request, the user telephone number of the user list 4300, and the merchant telephone number of the merchant list 4301 in step 6800. Match and determine the requester. If the telephone number information matches the user telephone number, the requester is determined to be the user, the process proceeds to step 6801, and if the telephone number information matches the merchant telephone number, the requester is determined to be the merchant. Then, the process proceeds to step 6804, and if none of them match, it is determined that the call request is not from the user or the merchant, and the process generation process is terminated without generating the process.

[1040] In step 6801, the registered user process management information is examined, and it is determined whether or not the user process corresponding to the user who is the requester already exists. If the user process does not exist, the process proceeds to step 6802 to generate the user process, register the user process management information, and end the process generation process. Also, if the user process already exists, there is a possibility that fraudulent acts such as impersonation of the user have been performed, so proceed to step 6803, send an error message to the management system, and generate the process. End the process.

[1041] In step 6804, the registered merchant process management information is examined, and it is determined whether or not the merchant process corresponding to the requesting merchant already exists. If the merchant process does not exist, the process proceeds to step 6805, the merchant process is generated, the merchant process management information is registered, and the process generation process is terminated. Also, if the merchant process already exists, there is a possibility that fraudulent activity such as impersonation of the merchant has been performed, so proceed to step 6806, send an error message to the management system, and generate the process. End the process.

Next, the user process performs processing according to the message from the personal credit terminal and the message from the service director process according to the processing flow shown in FIG. 100.

[1043] The user process generated by the service manager process first performs the session establishment process with the personal credit terminal in step 6900, and in steps 6901 and 6905, the personal credit terminal or service director process. Wait for a message from. In step 6901, it is determined that the message has been received, and in step 6905, it is determined that the timeout has occurred.

[1044] When a message is received, the user process changes the process status of the user process to the "active" state in step 6902, and performs processing according to the received message in step 6903. For example, when a "payment request" is received from a personal credit terminal, step 6903 processes the "payment" in the user process. Upon completion of the processing in step 6903, the user process changes the process status to the idle state in step 6904 and returns to step 6901.

[1045] In the timeout determination in step 6905, if no new message is received during the timeout time TNRU (TNRU&gt; 0) or more, the user process times out, and in step 6906, the user process timeout process is performed. The user process timeout process erases the user process by the service manager process and disconnects the line between the user process and the personal credit terminal.

That is, if the user process does not receive a new message from the personal credit terminal or the service director process during the timeout period of TNRU or more, the user process is automatically deleted and is connected to the personal credit terminal. Line is disconnected.

Next, the merchant process performs processing according to the message from the credit card payment terminal and the message from the service director process according to the processing flow shown in FIG. 101.

[1048] As in the case of the user process, the merchant process generated by the service manager process first performs the session establishment process with the credit card payment terminal in step 7000, and the credit card payment is performed in steps 7001 and 7005. Waiting for a message from the terminal or service director process. In step 7001, the message reception is determined, and in step 7005, the timeout is determined.

[1049] When a message is received, the merchant process changes the process status of the merchant process to the "active" state in step 7002, and performs processing according to the received message in step 7003. For example, when a "credit inquiry request" is received from a credit card payment terminal, the process of "payment" in the merchant process is performed in step 7003. Upon completion of the process in step 7003, the merchant process changes the process status to the idle state in step 7004 and returns to step 7001.

[1050] In the timeout determination in step 7005, if no new message is received during the timeout time TNRM (TNRM&gt; 0) or more, the merchant process times out, and in step 7006, the merchant process timeout process is performed. The merchant process timeout process clears the merchant process by the service manager process and disconnects the line between the merchant process and the credit card payment terminal.

[1051] That is, if the merchant process does not receive a new message from the credit payment terminal or the service director process during the timeout period of TNRM or more, it is automatically deleted and the line to and from the credit payment terminal is deleted. Is disconnected.

Next, the payment processing institution process performs processing according to the message from the payment system and the message from the service director process according to the processing flow shown in FIG. 102.

[1053] The payment processing institution process generated by the service manager process first initializes the communication line with the payment system in step 7100, and in steps 7101 and 7105, the payment system or service. -Waiting for a message from the director process. In step 7101, it is determined that the message has been received, and in step 7105, it is determined that the timeout has occurred.

[1054] When the message is received, the settlement processing institution process changes the process status of the settlement processing institution process to the "active" state in step 7102, and performs processing according to the received message in step 7103. For example, when a "payment request" is received from the service director process, the "payment" process in the payment processing institution process is performed in step 7103. Upon completion of the processing in step 7103, the settlement processing agency process changes the process status to the idle state in step 7104 and returns to step 7101.

[1055] In the timeout determination of step 7105, if no new message is received for the timeout time TNRTP (TNRTP&gt; 0) or longer, the settlement processing agency process times out, and in step 7106, the settlement processing agency process timeout. Perform processing. The payment processor process time-out process clears the payment processor process by the service manager process and disconnects the line between the payment processor process and the payment system.

[1056] That is, if the payment processing institution process does not receive a new message from the payment system or the service director process during the timeout period TNRTP or more, it is automatically deleted and the line to and from the payment system is deleted. Is disconnected.

[1057] Further, when the communication cost between the user process and the personal credit terminal 100 depends on the usage time of the communication line, the timeout time TNRU becomes a value depending on the communication charge system. For example, when the communication line usage time is charged in stages, the timeout time TNRU is the maximum that is TNRU0 (TNRU0&gt; 0) or more for a certain period of time and does not exceed the change point of the next communication charge. Is the value of. In this case, the communication line between the personal credit terminal and the user process is connected for as long as possible without increasing the communication cost. Further, when the charge is linearly charged with respect to the usage time of the communication line, the timeout time TNRU becomes TNRU0 for a certain period of time.

Similarly, if the communication cost between the merchant process and the credit payment terminal 300 or the payment processing institution process and the payment system 103 depends on the usage time of the communication line, the timeout time of the user process TNRU. As in the case of, the timeout times TNRM and TNRTP are values that depend on the respective communication charge systems.

[1059] The service director process will be described in detail in the subsequent description of each process of "payment", "cancellation", "customer service call", and "inquiry call". The payment system will be described in detail in the description of each process of "payment" and "cancellation".

[1060] Next, a processing flow in the session establishment process when connecting to the user process from the personal credit terminal will be described.

[1061] FIGS. 103 and 104 show the session establishment process of the personal credit terminal and the processing flow of the user process in the session establishment process when the personal credit terminal connects to the user process, respectively.

[1062] First, in step 7200, the personal credit terminal transmits a call request 4500 to the digital public network, receives a call response 4504 from the digital public network, and connects a line with a user process. At this time, the service manager process receives the incoming call request 4501 from the digital public network and generates a user process in the process generation process of step 6606. The generated user process sends a call answer 4503 to the digital public network in step 7300 to connect the line to the personal credit terminal. The user process then generates test pattern A4701 in step 7301, encrypts test pattern A with the user's public key in step 7302, generates authentication test A4506, and in step 7303 performs authentication test A. Send to a personal credit terminal.

On the other hand, the personal credit terminal generates the test pattern B4705 in step 7201 and encrypts the test pattern B with the service provider's public key in step 7202 to generate the authentication test B, and in step 7203. At step 7211 and waiting to receive authentication test A from the user process. In step 7203, the reception of the authentication test A is determined, and in step 7211, the timeout is determined.

[1064] In the timeout determination of step 7211, if the authentication test A is not received for the timeout time TTAU (TTAU&gt; 0) or more, the personal credit terminal times out and an error message is displayed on the LCD in step 7212. Then, in step 7213, the line is disconnected and the session establishment process is terminated.

[1065] When the authentication test A is received, the personal credit terminal decrypts the encrypted test pattern A with the user's private key in step 7204, and performs the authentication test B and the encryption in step 7205. From the decrypted test pattern A, the authentication test A response 4507 is generated, and in step 7206, the authentication test A response is sent to the user process.

[1066] The user process that has sent the authentication test A to the personal credit terminal is waiting to receive the authentication test A response from the personal credit terminal in steps 7304 and 7312. In step 7304, the reception of the authentication test A response is determined, and in step 7312, the timeout is determined.

[1067] In the timeout determination in step 7312, if the authentication test A response is not received for the timeout time TTARU (TTARU&gt; 0) or longer, the user process times out, and in step 7313, the session establishment error processing is performed. End the session establishment process. The session establishment error handling erases the user process and disconnects the line by the service manager process.

[1068] When the authentication test A response is received, the user process matches the sent authentication test A test pattern A with the received authentication test A response test pattern A in step 7305, and the patterns match. If so, the process proceeds to step 7306, and if they do not match, it is determined that the user authentication has failed, and in step 7314, the session establishment error processing is performed and the session establishment processing is terminated.

[1069] The user process decrypts the encrypted test pattern B with the service provider's private key in step 7306, generates a session authorization message 4709 in step 7307, and uses the session authorization message in step 7308. Generate authentication test B response 4508 from the encrypted session permission message and test pattern B encrypted with the public key of, and send the authentication test B response to the personal credit terminal in step 7309. To do. Then, in step 7310, the user status is changed to the session establishment state, and in step 7311, the process status is changed to the idle state to end the session establishment process. Proceed to.

[1070] The personal credit terminal that has sent the authentication test A response to the user process is waiting to receive the authentication test B response from the user process in steps 7207 and 7214. In step 7207, the reception of the authentication test B response is determined, and in step 7214, the timeout is determined.

[1071] In the timeout determination of step 7214, if the authentication test B response is not received for the timeout time TTBRU (TTBRU&gt; 0) or more, the personal credit terminal times out and an error message is sent to the LCD in step 7215. Displayed, and in step 7216, the line is disconnected to end the session establishment process. When the authentication test B response is received, the personal credit terminal matches the sent authentication test B test pattern B with the received authentication test B response test pattern B in step 7208, and the patterns match. In that case, the process proceeds to step 7209, and if they do not match, it is determined that the authentication of the service provider has failed, an error message is displayed on the LCD in step 7217, and the line is connected in step 7218. Disconnect and end the session establishment process.

[1072] The personal credit terminal decrypts the encrypted session permission message with the user's private key in step 7209, changes the terminal status to the session establishment state in step 7210, and ends the session establishment process. To do.

[1073] The session establishment process when connecting to the merchant process from the credit card payment terminal is the same as the session establishment process when connecting to the user process from the personal credit terminal. FIGS. 105 and 106 show the session establishment process of the credit card payment terminal and the processing flow of the merchant process in the session establishment process when connecting to the merchant process from the credit card payment terminal, respectively.

[1074] First, in step 7400, the credit card payment terminal sends a call request 4800 to the digital public network, receives a call response 4804 from the digital public network, and connects a line with the merchant process. At this time, the service manager process receives the incoming call request 4801 from the digital public network and generates a merchant process in the process generation process of step 6606. In step 7500, the generated merchant process sends an incoming call response 4803 to the digital public network to connect the line to the credit card payment terminal. The merchant process then generates test pattern A5001 in step 7501, encrypts test pattern A with the merchant's public key in step 7502, generates authentication test A4806, and in step 7503, performs authentication test A. Send to the credit payment terminal.

On the other hand, the credit settlement terminal generates test pattern B5005 in step 7401, encrypts test pattern B with the service provider's public key in step 7402, generates authentication test B, and steps 7403. At step 7411, we are waiting to receive certification test A from the merchant process. In step 7403, the reception of the authentication test A is determined, and in step 7411, the timeout is determined.

[1076] In the timeout determination of step 7411, if the authentication test A is not received during the timeout time TTAM (TTAM&gt; 0) or more, the credit settlement terminal times out and displays an error message on the LCD in step 7412. Further, in step 7413, the line is disconnected and the session establishment process is terminated.

[1077] When the authentication test A is received, the credit settlement terminal decrypts the encrypted test pattern A with the merchant's private key in step 7404, and decrypts the authentication test B and the encryption in step 7405. From the converted test pattern A, the authentication test A response 4807 is generated, and in step 7406, the authentication test A response is sent to the merchant process.

[1078] The merchant process that has sent the authentication test A to the credit card payment terminal is waiting to receive the authentication test A response from the credit card payment terminal in steps 7504 and 7512. In step 7504, the reception of the authentication test A response is determined, and in step 7512, the timeout is determined.

[1079] In the timeout determination in step 7512, if the authentication test A response is not received for the timeout time TTARM (TTARM&gt; 0) or more, the merchant process times out, and in step 7513, the session establishment error processing is performed. End the session establishment process. The session establishment error handling clears the merchant process and disconnects the line by the service manager process.

[1080] When the authentication test A response is received, the merchant process collates the transmitted test pattern A of the authentication test A with the test pattern A of the received authentication test A response in step 7505 to match the pattern. If they match, the process proceeds to step 7506. If they do not match, it is determined that the merchant authentication has failed, and in step 7514, session establishment error processing is performed and session establishment processing ends.

[1081] The merchant process decrypts the encrypted test pattern B with the service provider's private key in step 7506, generates a session authorization message 4709 in step 7507, and merchants the session authorization message in step 7508. Generate authentication test B response 4808 from the encrypted session permission message and the test pattern B encrypted with the public key of, and send the authentication test B response to the credit settlement terminal in step 7509. .. Then, in step 7510, the merchant status is changed to the session establishment state, and in step 7511, the process status is changed to the idle state to end the session establishment process. Proceed to. The credit card payment terminal that sent the authentication test A response to the merchant process is waiting to receive the authentication test B response from the merchant process in steps 7407 and 7414. In step 7407, the reception of the authentication test B response is determined, and in step 7414, the timeout is determined.

[1082] In the timeout determination in step 7414, if the authentication test B response is not received for the timeout time TTBRM (TTBRM&gt; 0) or more, the credit settlement terminal times out and displays an error message on the LCD in step 7415. Then, in step 7416, the line is disconnected and the session establishment process is terminated.

[1083] When the authentication test B response is received, the credit settlement terminal collates the transmitted test pattern B of the authentication test B with the test pattern B of the received authentication test B response in step 7408, and the pattern is changed. If they match, the process proceeds to step 7409, and if they do not match, it is determined that the service provider authentication has failed, an error message is displayed on the LCD in step 7417, and further, in step 7418, Disconnect the line and end the session establishment process.

[1084] The credit card payment terminal decrypts the encrypted session permission message with the merchant's private key in step 7409, changes the terminal status to the session establishment state in step 7410, and ends the session establishment process. ..

[1085] Next, a processing flow in the session establishment process when connecting to the personal credit terminal from the user process will be described.

[1086] FIGS. 107 and 108 show the processing flow of the user process in the session establishment process when the user process connects to the personal credit terminal and the session establishment process of the personal credit terminal, respectively.

The user process generated by the service manager process first sends a call request 4601 to the digital public network and receives a call response 4604 from the digital public network in step 7600 for personal credit. Connect the line with the terminal. At this time, the personal credit terminal receives the incoming call request 4602 from the digital public network and transmits the incoming call response 4603 to the digital public network in step 7700 to connect the line with the user process. In addition, the personal credit terminal generates test pattern C4712 in step 7701, encrypts test pattern C with the service provider's public key in step 7702, generates authentication test C4606, and authenticates in step 7703. Send test C to the user process.

On the other hand, the user process generates test pattern D4716 in step 7601, encrypts test pattern D with the user's public key in step 7602, generates authentication test D, and steps 7603 and 7612. So, I am waiting to receive the certification test C from the personal credit terminal. In step 7603, the reception of the authentication test C is determined, and in step 7612, the timeout is determined.

[1089] In the timeout determination in step 7612, if the authentication test C is not received for the timeout time TTCU (TTCU&gt; 0) or more, the user process times out, and in step 7613, the session establishment error processing is performed and the session is performed. End the establishment process.

[1090] When the authentication test C is received, the user process decrypts the encrypted test pattern C with the service provider's private key in step 7604, and decrypts the authentication test D and the encryption in step 7605. From the test pattern C, the authentication test C response 4607 is generated, and in step 7606, the authentication test C response is sent to the personal credit terminal.

[1091] The personal credit terminal that has sent the authentication test C to the user process is waiting to receive the authentication test C response from the user process in steps 7704 and 7711. In step 7704, the reception of the authentication test C response is determined, and in step 7711, the timeout is determined.

[1092] In the timeout determination of step 7711, if the authentication test C response is not received for the timeout time TTCRU (TTCRU&gt; 0) or more, the personal credit terminal times out and an error message is sent to the LCD in step 7712. It is displayed, and in step 7613, the line is disconnected and the session establishment process is terminated.

[1093] When the authentication test C response is received, the personal credit terminal collates the transmitted test pattern C of the authentication test C with the test pattern C of the received authentication test C response in step 7705 to match the pattern. If they match, the process proceeds to step 7706. If they do not match, it is determined that the service provider authentication has failed, an error message is displayed on the LCD in step 7714, and further, in step 7613. , Disconnect the line and end the session establishment process.

[1094] The personal credit terminal decrypts the encrypted test pattern D with the user's private key in step 7706, generates a session authorization message 4720 in step 7707, and services the session authorization message in step 7708. Generate authentication test D response 4608 from test pattern D, which was encrypted with the provider's public key and decrypted the encryption, and the encrypted session permission message, and in step 7709, send the authentication test D response to the user process. To do. Then, in step 7710, the terminal status is changed to the session establishment state, and the session establishment process is terminated.

[1095] The user process that has sent the authentication test C response to the personal credit terminal is waiting to receive the authentication test D response from the personal credit terminal in steps 7607 and 7614. In step 7607, the reception of the authentication test D response is determined, and in step 7614, the timeout is determined.

[1096] In the timeout determination in step 7614, if the authentication test D response is not received for the timeout time TTDRU (TTDRU&gt; 0) or longer, the user process times out, and in step 7615, the session establishment error processing is performed. End the session establishment process.

[1097] When the authentication test D response is received, the user process matches the test pattern D of the transmitted authentication test D with the test pattern D of the received authentication test D response in step 7608, and the patterns match. If so, the process proceeds to step 7609, and if they do not match, it is determined that the user authentication has failed, and in step 7616, the session establishment error processing is performed and the session establishment processing is terminated.

[1098] The user process decrypts the encrypted session authorization message with the service provider's private key in step 7609, changes the user status to the session establishment state in step 7610, and processes in step 7611. The status is changed to the "idle" state, the session establishment process is terminated, and the user process proceeds to step 6901 in FIG. 100.

[1099] The session establishment process when connecting to the credit payment terminal from the merchant process is the same as the session establishment process when connecting to the personal credit terminal from the user process. FIGS. 109 and 110 show the processing flow of the merchant process in the session establishment process when connecting to the credit card payment terminal and the session establishment process of the credit card payment terminal, respectively, from the merchant process.

[1100] The merchant process generated by the service manager process first sends a call request 4901 to the digital public network and receives a call response 4904 from the digital public network in step 7800 to receive a credit payment terminal. Connect the line with. At this time, the credit card payment terminal receives the incoming call request 4902 from the digital public network and sends the incoming call response 4903 to the digital public network in step 7900 to connect the line with the merchant process. In addition, the credit payment terminal generates test pattern C5012 in step 7901, encrypts test pattern C with the service provider's public key in step 7902, generates authentication test C4906, and in step 7903, the authentication test. Send C to the merchant process.

[1101] Meanwhile, the merchant process generates test pattern D5016 in step 7801 and encrypts test pattern D with the merchant's public key in step 7802 to generate authentication test D, with steps 7803 and 7812. So, I am waiting to receive the authentication test C from the credit payment terminal. In step 7803, the reception of the authentication test C is determined, and in step 7812, the timeout is determined.

[1102] In the timeout determination in step 7812, if the authentication test C is not received during the timeout time TTCM (TTCM&gt; 0) or more, the merchant process times out, and in step 7813, the session establishment error processing is performed and the session is performed. End the establishment process.

[1103] When the authentication test C is received, the merchant process decrypts the encrypted test pattern C with the service provider's private key in step 7804, and decrypts the authentication test D and the encryption in step 7805. From the test pattern and C, the authentication test C response 4907 is generated, and in step 7806, the authentication test C response is sent to the credit settlement terminal.

[1104] The credit card payment terminal that has sent the authentication test C to the merchant process is waiting to receive the authentication test C response from the merchant process in steps 7904 and 7911. In step 7904, the reception of the authentication test C response is determined, and in step 7911, the timeout is determined.

[1105] In the timeout determination of step 7911, if the authentication test C response is not received for the timeout time TTCRM (TTCRM&gt; 0) or more, the credit settlement terminal times out and displays an error message on the LCD in step 7912. Then, in step 7913, the line is disconnected and the session establishment process is terminated.

[1106] When the authentication test C response is received, the credit settlement terminal collates the transmitted test pattern C of the authentication test C with the test pattern C of the received authentication test C response in step 7905, and the pattern is changed. If they match, the process proceeds to step 7906, and if they do not match, it is determined that the service provider authentication has failed, an error message is displayed on the LCD in step 7914, and further, in step 7915, Disconnect the line and end the session establishment process.

[1107] The credit settlement terminal decrypts the encrypted test pattern D with the merchant's private key in step 7906, generates the session permission message 5020 in step 7907, and provides the session permission message in step 7908. Generates Authentication Test D Response 4908 from Test Pattern D, which was encrypted with the public key of the person and decrypted the encryption, and the encrypted session authorization message, and in step 7909, sends the Authentication Test D response to the merchant process. .. Then, in step 7910, the terminal status is changed to the session establishment state, and the session establishment process is terminated.

[1108] The merchant process that has sent the authentication test C response to the credit card payment terminal is waiting to receive the authentication test D response from the credit card payment terminal in steps 7807 and 7814. In step 7807, the reception of the authentication test D response is determined, and in step 7814, the timeout is determined.

[1109] In the timeout determination in step 7814, if the authentication test D response is not received for the timeout time TTDRM (TTDRM&gt; 0) or more, the merchant process times out, and in step 7815, the session establishment error processing is performed. End the session establishment process.

[1110] When the authentication test D response is received, the merchant process matches the test pattern D of the transmitted authentication test D with the test pattern D of the received authentication test D response in step 7808, and the patterns match. If so, the process proceeds to step 7809, and if they do not match, it is determined that the merchant authentication has failed, and in step 7816, the session establishment error processing is performed and the session establishment processing is terminated.

The merchant process decrypts the encrypted session authorization message with the service provider's private key in step 7809, changes the merchant status to the session established state in step 7810, and processes in step 7811. The status is changed to the idle state, the session establishment process is completed, and the merchant process proceeds to step 7001 in FIG. 101.

[1112] Next, the processing flow in the remote access processing will be described.

[1113] Fig. 111 (a) and Fig. 112 (a) show the remote access process of the personal credit terminal and the user process of the service providing system in the remote access processing between the personal credit terminal and the service providing system, respectively. The processing flow of is shown.

[1114] The remote access process is initiated by the user accessing data present at the remote address. The personal credit terminal first generates a remote access request 5100 for the data to be accessed in step 8000, determines from the terminal status whether or not it is in the session established state in step 8001, and if it is in the session established state, it determines whether or not it is in the session established state. , The generated remote access request is sent to the user process in step 8003, and if the session is not established, the session establishment process is performed in step 8002 to establish a session with the service providing system, and then the process proceeds to step 8003. ..

[1115] The personal credit terminal that has transmitted the remote access request waits for the reception of the remote access data 5101 in step 8004 and step 8011. In step 8004, the reception of remote access data is determined, and in step 8011, the timeout is determined.

[1116] In the timeout determination of step 8011, if the remote access data is not received during the timeout time TRADU (TRADU&gt; 0) or more, the personal credit terminal times out and the user timeout error handling is performed in step 8012. And end the remote access process. In user timeout error handling, the personal credit terminal sends a user timeout error message to the user process in the service delivery system, disconnects the session and line with the user process, and displays the timeout error on the LCD. To do.

[1117] When the remote access data is received, the personal credit terminal decrypts the remote access data with the user's private key in step 8005, performs a user validity check in step 8006, and performs the remote access data. Verify the effectiveness of.

[1118] If the user validity check is passed, the personal credit terminal stores the data 5209 portion of the remote access data in the temporary area of RAM in step 8007, and stores the data address information in step 8008. , Update to the local address where the data was stored, and in step 8009, access the data stored in RAM. Then, in step 8010, it is determined from the free space of the temporary area whether or not the data update process is necessary, and if the free space of the temporary area is equal to or more than the set value AU (AU&gt; 0), the remote access is performed as it is. When the process is completed and the value is less than the set value AU, a data update process is generated and the process proceeds to the data update process.

[1119] If the user validity check fails, the personal credit terminal performs user session error processing and ends remote access processing in step 8013. In user session error handling, the personal credit terminal sends a user session error message to the user process in the service delivery system, disconnects the session and line with the user process, and displays the session error on the LCD. To do.

[1120] Further, the user validity check is a process of verifying the validity of the message received from the user process of the service providing system, and as shown in FIG. 111 (b), there are three types of user validity checks. Perform verification. First, step 8014 verifies the digital signature of the service provider, step 8015 verifies the service provider ID, and step 8016 verifies the issue time of the received message. In the verification of the issue time in step 8016, the deviation between the issue time of the received information and the current time is verified, and if the deviation is equal to or greater than the time TU (TU&gt; 0), it is determined that the information is invalid. Therefore, it is determined that the user validity check has passed only when the service provider's digital signature verification has passed, the service provider ID matches, and the issue time verification has passed, and the failure has occurred in other cases. Is determined.

[1121] On the other hand, in the user process, the remote access process is started by receiving the remote access request 5100. The user process first decrypts the received remote access request with the service provider's private key in step 8100, and in step 8101 performs a user process validity check to verify the validity of the remote access request. ..

[1122] If the user process validity check is passed, the user process generates remote access data 5101 in step 8102 and sends the generated remote access data to the personal credit terminal in step 8103. End the remote access process.

[1123] If the user process validity check fails, the user process determines that the received message is not valid, performs user process session error processing in step 8104, and ends remote access processing. .. The user process session error handling erases the user process by the service manager process and disconnects the session and line with the personal credit terminal. At this time, the user process sends a session error message indicating that an invalid message has been received to the management system 407.

[1124] Further, the user process validity check is a process for verifying the validity of the information received from the personal credit terminal, and as shown in FIG. 112 (b), there are three types of user process validity checks. Perform verification. First, step 8105 verifies the digital signature of the user, step 8106 verifies the user ID, and step 8107 verifies the issue time of the received information. In the verification of the issue time in step 8107, the deviation between the issue time of the received information and the current time is verified, and if the deviation is equal to or greater than the time TUP (TUP&gt; 0), it is determined that the information is invalid. .. Therefore, it is determined that the user process validity check is passed only when the verification of the user's digital signature is passed, the user ID matches, and the verification of the issue time is passed, and in other cases, it is determined that the user has failed. To do.

[1125] Further, FIGS. 113 (a) and 114 (a) show the processing flow of the remote access process of the credit card payment terminal and the merchant process in the remote access process of the credit card payment terminal and the service providing system, respectively. Is shown.

[1126] The remote access process is initiated by the merchant accessing the data present at the remote address. The credit settlement terminal first generates a remote access request 5400 for the data to be accessed in step 8200, determines from the terminal status whether or not it is in the session established state in step 8201, and if it is in the session established state, In step 8203, the generated remote access request is sent to the merchant process, and if the session is not established, the session establishment process is performed in step 8202 to establish a session with the service providing system, and then the process proceeds to step 8203.

[1127] credit settlement terminal that sent the remote access request, in a step 8204 and the step 8211, remote access waits for the reception of Sudeta 5401. In step 8204, the reception of remote access data is determined, and in step 8211, the timeout is determined.

[1128] In the timeout determination of step 8211, if the remote access data is not received during the timeout time TRADM (TRADM&gt; 0) or more, the credit settlement terminal times out, and in step 8212, the merchant timeout error processing is performed. And end the remote access process. In merchant timeout error handling, the credit settlement terminal sends a merchant timeout error message to the merchant process in the service delivery system, disconnects the session and line with the merchant process, and displays a timeout error on the LCD. ..

[1129] When the remote access data is received, the credit card payment terminal decrypts the remote access data with the merchant's private key in step 8205, performs the merchant validity check in step 8206, and performs the remote access data. Verify effectiveness.

[1130] If the merchant validity check is passed, the credit settlement terminal stores the data 5509 portion of the remote access data in the temporary area of RAM in step 8207, and stores the data address information in step 8208. Update to the local address where the data was stored, and in step 8209, access the data stored in RAM. Then, in step 8210, it is determined from the free space of the temporary area whether or not the data update process is necessary, and if the free space of the temporary area is equal to or more than the set value AM (AM&gt; 0), the remote access is performed as it is. When the process is completed and the value is less than the set value AM, a data update process is generated and the process proceeds to the data update process.

[1131] If the merchant validity check fails, the credit card payment terminal performs the merchant session error processing and ends the remote access processing in step 8213. In merchant session error handling, the credit settlement terminal sends a merchant session error message to the merchant process of the service delivery system, disconnects the session and line with the merchant process, and displays the session error on the LCD. ..

[1132] Further, the merchant validity check is a process for verifying the validity of the message received from the merchant process of the service providing system. As shown in FIG. 113 (b), there are three types of merchant validity checks. Perform verification. First, step 8214 verifies the digital signature of the service provider, step 8215 verifies the service provider ID, and step 8216 verifies the issue time of the received message. In the verification of the issue time in step 8216, the deviation between the issue time of the received information and the current time is verified, and if the deviation is equal to or greater than the time TM (TM&gt; 0), it is determined that the information is invalid. .. Therefore, it is determined that the merchant validity check is passed only when the service provider's digital signature is verified, the service provider ID is matched, and the issue time is verified. Otherwise, the fail is performed. It is determined that it has been done.

[1133] On the other hand, in the merchant process, the remote access process is initiated by receiving the remote access request 5400. The merchant process first decrypts the received remote access request with the service provider's private key in step 8300, and in step 8301 performs a merchant process validity check to verify the validity of the remote access request. ..

[1134] If the merchant process validity check is passed, the merchant process generates remote access data 5401 in step 8302 and sends the generated remote access data to the credit card payment terminal in step 8303 to remote. End the access process.

[1135] If the merchant process validity check fails, the merchant process determines that the received message is not valid, performs merchant process session error handling in step 8304, and terminates remote access processing. .. Merchant process session error handling erases the merchant process by the service manager process and disconnects the session and line with the credit card payment terminal. At this time, the merchant process sends a session error message to the management system 407 indicating that an invalid message has been received.

[1136] Further, the merchant process validity check is a process for verifying the validity of the information received from the credit card payment terminal, and as shown in FIG. 114 (b), the merchant process validity check has three types of verification. To do. First, step 8305 verifies the digital signature of the merchant, step 8306 verifies the merchant ID, and step 8307 verifies the issue time of the received information. In the verification of the issue time in step 8307, the deviation between the issue time of the received information and the current time is verified, and if the deviation is equal to or greater than the time TMP (TMP&gt; 0), it is determined that the information is invalid. .. Therefore, it is determined that the merchant process validity check is passed only when it passes the verification of the digital signature of the merchant, the merchant ID matches, and the verification of the issue time is passed, and otherwise it is determined that the failure is performed. To do.

[1137] Next, a processing flow in the data update process will be described.

[1138] Fig. 115 and FIG. 116 show the processing flow of the data update process of the personal credit terminal and the user process of the service providing system in the data update processing of the personal credit terminal and the service providing system, respectively. ing.

[1139] The data update process performs personal credit when the value of the clock counter of the personal credit terminal matches the update time register, or when the free space in the temporary area becomes less than the set value AU. The terminal is started by spawning a data update process.

[1140] The personal credit terminal first displays "data update in progress" on the LCD in step 8400, generates a data update request 5102 in step 8401, and in step 8402, the session is established from the terminal status. If it is in the session establishment state, the generated data update request is sent to the user process in step 8404, and if it is not in the session establishment state, the session establishment process is performed in step 8403 to provide the service. After establishing a session with the system, proceed to step 8404.

[1141] The personal credit terminal that has sent the data update request waits for the data update response 5103 to be received in step 8405 and step 8416. In step 8405, the reception of the data update response is determined, and in step 8416, the timeout is determined.

[1142] In the timeout determination in step 8416, if no data update response is received for the timeout time TRURU (TRURU&gt; 0) or longer, the personal credit terminal times out and the user timeout error handling in step 8417. And end the data update process.

[1143] When the personal credit terminal receives the data update response, the personal credit terminal decrypts the data update response with the user's private key in step 8406, performs the user validity check in step 8407, and performs the data update response. Verify the effectiveness of.

[1144] If the user validity check is passed, the personal credit terminal compresses the RAM data in step 8408 to generate upload data 5104, and in step 8409, the generated upload data is used by the user. Send to process.

[1145] If the user validity check fails, the personal credit terminal performs the user session error processing and ends the data update processing in step 8418.

[1146] The personal credit terminal that has transmitted the uploaded data waits for the reception of the message from the user process in step 8410 and step 8419. In step 8410, the reception of the message is determined, and in step 8419, the timeout is determined.

[1147] In the timeout determination in step 8419, if no message is received for the timeout time TDU (TDU&gt; 0) or longer, the personal credit terminal times out, and in step 8420, the user timeout error processing is performed. , End the data update process.

[1148] When a message from a user process is received, the personal credit terminal decrypts the received message with the user's private key in step 8411, performs a user validity check in step 8412, and receives the message. Verify the validity of the message you sent.

[1149] If the user validity check is passed, the personal credit terminal goes to step 8413, and if the user validity check fails, the personal credit terminal goes to step 8421 for the user session. Performs error processing and ends the data update process.

[1150] The personal credit terminal determines in step 8413 whether the received message is the update data 5105 or the function stop command 5105', and if it is the update data, the update data terminal in step 8414. The data compression of the data 5239 is released, the data in the RAM is updated, and in step 8415, the display of Data update in progress is released, and the data update process is terminated.

[1151] If the received message is an outage command, the personal credit terminal displays "unavailable" on the LCD in step 8422 and clears the terminal enable bit in EEPROM 1503 in step 8423. Then, the operation is disabled, and in step 8424, the terminal status is changed to disabled, and the data update process is completed.

[1152] On the other hand, in the user process, the data update process is started by receiving the data update request 5102. The user process first decrypts the received data update request with the service provider's private key in step 8500, and performs a user process validity check in step 8501 to verify the validity of the data update request. ..

[1153] If the user process validity check is passed, the user process generates a data update response 5103 in step 8502 and sends the generated data update response to the personal credit terminal in step 8503.

[1154] If the user process validity check fails, the user process determines that the received message is not valid, performs user process session error processing in step 8514, and ends the data update process. ..

[1155] The user process that has sent the data update response waits for the upload data 5104 to be received in step 8504 and step 8515. In step 8504, the reception of the uploaded data is determined, and in step 8515, the timeout is determined.

[1156] In the timeout determination in step 8515, if the upload data is not received during the timeout time TUDU (TUDU&gt; 0) or more, the user process times out, and in step 8516, the user process timeout error processing is performed. , End the data update process. The user process timeout error handling erases the user process by the service manager process and disconnects the session and line with the personal credit terminal. At this time, the user process sends a timeout error message indicating that the timeout has occurred to the management system 407.

[1157] When the upload data is received, the user process decrypts the received upload data with the service provider's private key in step 8505, performs the user process validity check in step 8506, and upload data. Verify the effectiveness of.

[1158] If the user process validity check is passed, the user process proceeds to step 8507, and if the user process validity check fails, the user process determines that the received message is not valid. , Step 8517 performs user process session error processing and ends the data update process.

[1159] The user process decompresses the terminal data 5231 of the uploaded data in step 8507, performs a data collation check in step 8508, and verifies whether the terminal data has been tampered with illegally. In the data collation check, the terminal data from which the data compression has been released is collated with the terminal data 24006 of the user information server and the data managed by the other user data management information 24000.

[1160] If the data collation check is passed, the user process first updates the access time of the credit card list 24008 of the user information server based on the terminal data from which the data has been decompressed in step 8509. Change to information, then in step 8510 generate new terminal data based on the capacity of the physical data area of the personal credit terminal and the data generation time and access time, and in step 8511 data compression. The difference between the released terminal data and the new terminal data is taken to generate update data 5105, and the generated update data is transmitted to the personal credit terminal in step 8512, and in 8513, the terminal of the user information server. Update data 24006 and end the data update process.

[1161] When the data collation check fails, it is determined that the terminal data may have been tampered with, and the user process generates the function stop instruction 5105'in step 8518, and step 8519. Then, the generated stop command is sent to the personal credit terminal, and in step 8520, the user status 24012 on the user information server is changed to "unusable", and in step 8521, the user process session error occurs. Performs processing and ends the data update process.

[1162] In the generation of new terminal data in step 8510, the data stored in the RAM is reorganized so that the temporary area becomes empty. In particular, when there is not enough space in the physical data area 21812, the access times of each credit card are compared, and a local address is assigned to the object data address of the credit card with the latest access time, and each use Compare the usage times of information and assign a local address to the usage information address of the latest usage information. If it is necessary to upgrade the program of the personal credit terminal, the data in the basic program area is updated. However, the user area is updated to the data in the user area of the terminal data received from the personal credit terminal.

[1163] Further, FIGS. 117 and 118 show the processing flow of the data update process of the credit payment terminal and the merchant process of the service providing system in the data update processing of the credit payment terminal and the service providing system, respectively. ing.

[1164] In the data update process, when the value of the clock counter of the credit settlement terminal matches the update time register, or when the free space of the temporary area becomes less than the set value AM, the credit settlement terminal performs the data update process. , Started by spawning a data update process.

[1165] The credit settlement terminal first displays "Data update in progress" on the LCD in step 8600, generates a data update request 5402 in step 8601, and in step 8602, is the session established status from the terminal status? It is determined whether or not, and if the session is established, the generated data update request is sent to the merchant process in step 8604, and if it is not in the session established state, the session establishment process is performed in step 8603, and the service providing system After establishing a session with, proceed to step 8604.

[1166] The credit card payment terminal that has sent the data update request waits for the data update response 5403 to be received in step 8605 and step 8616. In step 8605, the reception of the data update response is determined, and in step 8616, the timeout is determined.

[1167] In the timeout determination in step 8616, if the data update response is not received for the timeout time TRURM (TRURM&gt; 0) or more, the credit settlement terminal times out, and in step 8617, the merchant timeout error processing is performed. And end the data update process.

[1168] When the credit card payment terminal receives the data update response, the credit card payment terminal decrypts the data update response with the merchant's private key in step 8606, performs the merchant validity check in step 8607, and performs the data update response. Verify effectiveness.

[1169] If the merchant validity check is passed, the credit settlement terminal compresses the RAM and hard disk data in step 8608 to generate upload data 5404, and in step 8609, the generated upload. Send the data to the merchant process.

[1170] If the merchant validity check fails, the credit card payment terminal performs the merchant session error processing and ends the data update processing in step 8618.

[1171] The credit card payment terminal that has transmitted the uploaded data waits for the reception of the message from the merchant process in step 8610 and step 8619. In step 8610, the reception of the message is determined, and in step 8619, the timeout is determined.

[1172] In the timeout determination in step 8619, if no message is received for the timeout time TDM (TDM&gt; 0) or longer, the credit settlement terminal times out, and in step 8620, the merchant timeout error processing is performed. End the data update process.

When receiving a message from the merchant process, the credit card payment terminal decrypts the received message with the merchant's private key in step 8611, performs a merchant validity check in step 8612, and receives the message. Verify the validity of the message.

[1174] If the merchant validity check is passed, the credit card payment terminal proceeds to step 8613, and if the merchant validity check fails, the credit card payment terminal handles the merchant session error in step 8621. And end the data update process.

[1175] In step 8613, the credit settlement terminal determines whether the received message is the update data 5405 or the function stop command 5405', and if it is the update data, in step 8614, the terminal data of the update data. The data compression of 5539 is released, the data of the RAM and the hard disk are updated, and in step 8615, the display of "Data update in progress" is released, and the data update process is terminated.

[1176] If the received message is a function stop command, the credit card payment terminal displays "unavailable" on the LCD in step 8622 and clears the terminal enable bit of EEPROM 22504 in step 8623. The operation is disabled, and in step 8624, the terminal status is changed to disabled, and the data update process is completed.

[1177] On the other hand, in the merchant process, the data update process is started by receiving the data update request 5402. The merchant process first decrypts the received data update request with the service provider's private key in step 8700, and in step 8701 performs a merchant process validity check to verify the validity of the data update request. ..

[1178] If the merchant process validity check is passed, the merchant process generates a data update response 5403 in step 8702 and sends the generated data update response to the credit card payment terminal in step 8703.

[1179] If the merchant process validity check fails, the merchant process determines that the received message is not valid, and in step 8713, performs merchant process session error processing and ends the data update process. ..

[1180] The merchant process that has sent the data update response waits for the upload data 5404 to be received in steps 8704 and 8714. In step 8704, the reception of the uploaded data is determined, and in step 8714, the timeout is determined.

[1181] In the timeout determination in step 8714, if the upload data is not received for the timeout time TUDM (TUDM&gt; 0) or more, the merchant process times out, and in step 8715, the merchant process timeout error processing is performed. , End the data update process. The merchant process timeout error handling erases the merchant process by the service manager process and disconnects the session and line with the credit card payment terminal. At this time, the merchant process sends a timeout error message indicating that it has timed out to the management system 407.

[1182] When the upload data is received, the merchant process decrypts the received upload data with the service provider's private key in step 8705, performs the merchant process validity check in step 8706, and upload data. Verify the effectiveness of.

[1183] If the merchant process validity check is passed, the merchant process proceeds to step 8707, and if the merchant process validity check fails, the merchant process determines that the received message is not valid. , Step 8716 performs merchant process session error handling and ends the data update process.

[1184] In step 8707, the merchant process decompresses the terminal data 5531 of the uploaded data, and in step 8708, performs a data collation check to verify that the terminal data has not been tampered with. In the data collation check, the terminal data from which the data compression has been decompressed is collated with the terminal data 24006 of the merchant information server and the data managed by the other merchant data management information 24000.

[1185] If the data collation check is passed, the merchant process first generates new terminal data in step 8709 based on the capacity of the physical data area of the credit settlement terminal and the data generation time, and then steps. At 8710, the difference between the terminal data that has been decompressed and the new terminal data is taken to generate update data 5405, and the generated update data is sent to the credit settlement terminal at step 8711. Updates the terminal data 24104 of the merchant information server and ends the data update process.

[1186] When the data collation check fails, it is determined that the terminal data may have been tampered with, and the merchant process generates the stop command 5405'in step 8717, and steps 8718. Then, the generated stop command is sent to the credit settlement terminal, and in step 8719, the merchant status 24012 on the merchant information server is changed to unusable, and in step 8720, the merchant process session error handling is performed. To end the data update process.

[1187] In the generation of new terminal data in step 8709, the data stored in the RAM and the hard disk are reorganized so that the temporary area becomes empty. In particular, if there is not enough space in the actual data area, it is necessary to compare the sales times of each sales information, assign a local address to the sales information with the latest sales time, and upgrade the program of the credit settlement terminal. If there is, the data in the basic program area is also updated. However, the merchant area is updated to the data in the merchant area of the terminal data received from the credit card payment terminal.

[1188] Next, a processing flow in the forced data update process will be described. FIGS. 119 and 120 show the processing flow of the forced data update process of the personal credit terminal and the user process of the service providing system in the forced data update process of the personal credit terminal and the service providing system, respectively. Shown.

[1189] The forced data update process is performed when the service providing system 102 needs to update the RAM data of the personal credit terminal 100 immediately, such as when the contract contents with the user are changed. ..

[1190] The user process first generates a data update instruction 5106 in step 8900, determines from the terminal status whether or not it is in the session established state in step 8901, and if it is in the session established state, step 8903. Then, the generated data update command is transmitted to the personal credit terminal, and if the session is not established, the session establishment process is performed in step 8902 to establish a session with the service providing system, and then the process proceeds to step 8903.

[1191] The user process that has sent the data update instruction waits for the upload data 5107 to be received in step 8904 and step 8914. In step 8904, the reception of the uploaded data is determined, and in step 8914, the timeout is determined.

[1192] In the timeout determination in step 8914, if the upload data is not received during the timeout time TUDU (TUDU&gt; 0) or more, the user process times out, and in step 8915, the user process timeout error processing is performed. , End the forced data update process.

[1193] When the upload data is received, the user process decrypts the received upload data with the service provider's private key in step 8905, performs the user process validity check in step 8906, and upload data. Verify the effectiveness of.

[1194] If the user process validity check is passed, the user process proceeds to step 8907, and if the user process validity check fails, the user process determines that the received message is not valid. , Step 8916 performs user process session error handling and ends forced data update processing.

[1195] In step 8907, the user process decompresses the terminal data 5231 of the uploaded data, and in step 8908, performs a data collation check to verify that the terminal data has not been tampered with illegally.

[1196] If the data collation check is passed, the user process first updates the access time of the credit card list 24008 of the user information server based on the terminal data from which the data has been decompressed in step 8909. Change to information, then in step 8910 generate new terminal data based on the capacity of the physical data area of the personal credit terminal and the data generation time and access time, and in step 8911 data compression The difference between the released terminal data and the new terminal data is taken to generate update data 5108, and the generated update data is transmitted to the personal credit terminal in step 8912, and in step 8913, the user information server Update the terminal data 24006 and end the forced data update process.

[1197] When the data collation check fails, it is determined that the terminal data may have been tampered with, and the user process generates the function stop instruction 5108'in step 8917, and steps 8918. Then, the generated stop command is sent to the personal credit terminal, and in step 8919, the user status 24012 on the user information server is changed to "unusable", and in step 8920, the user process session error occurs. Performs processing and ends the forced data update process.

[1198] In the generation of new terminal data in step 8910, the data stored in the RAM is reorganized so that the temporary area becomes empty. In particular, when there is not enough space in the physical data area 21812, the access times of each credit card are compared, and a local address is assigned to the object data address of the credit card with the latest access time, and each use Compare the usage times of information and assign a local address to the usage information address of the latest usage information. If it is necessary to upgrade the program of the personal credit terminal, the data in the basic program area is updated. However, the user area is updated to the data in the user area of the terminal data received from the personal credit terminal.

[1199] On the other hand, in the personal credit terminal, the compulsory data update process is started by receiving the data update instruction 5106 and generating the compulsory data update process.

[1200] First, in step 8800, the personal credit terminal decrypts the encryption of the data update instruction with the user's private key, and in step 8801, the user validity check is performed and the validity of the data update instruction is verified. ..

[1201] If the user validity check is passed, the personal credit terminal displays "Data update in progress" on the LCD in step 8802, compresses the RAM data, and uploads the data in step 8803. Generate 5107 and send the generated upload data to the user process in step 8804.

[1202] If the user validity check fails, the personal credit terminal performs the user session error processing in step 8811 and ends the forced data update processing.

[1203] The personal credit terminal that has transmitted the uploaded data waits for the reception of the message from the user process in step 8805 and step 8812. In step 8805, the reception of the message is determined, and in step 8812, the timeout is determined.

[1204] In the timeout determination in step 8812, if no message is received during the timeout time TDU (TDU&gt; 0) or longer, the personal credit terminal times out, and in step 8813, the user timeout error processing is performed. , End the forced data update process.

[1205] When a message from the user process is received, the personal credit terminal decrypts the received message with the user's private key in step 8806, performs a user validity check in step 8807, and receives the message. Verify the validity of the message you sent.

[1206] If the user validity check is passed, the personal credit terminal goes to step 8808, and if the user validity check fails, the personal credit terminal goes to step 8814 for the user session. Performs error processing and ends the forced data update process.

[1207] In step 8808, the personal credit terminal determines whether the received message is the update data 5108 or the function stop command 5108', and if it is the update data, in step 8809, the terminal data of the update data. The data compression of 5239 is released, the data in the RAM is updated, and in step 8810, the display of "Data update in progress" is released, and the forced data update process is terminated.

[1208] If the received message is an outage command, the personal credit terminal displays "unavailable" on the LCD in step 8815 and clears the terminal enable bit in EEPROM 1503 in step 8816. Then, the operation is disabled, and in step 8817, the terminal status is changed to unusable, and the forced data update process is terminated.

[1209] Further, FIGS. 121 and 122 show a forced data update process of the credit payment terminal and a merchant process of the service providing system in the forced data update process of the credit payment terminal and the service providing system, respectively. The processing flow is shown.

[1210] For the forced data update process, it is necessary for the service providing system 102 to immediately update the RAM and hard disk data of the credit payment terminal 101, such as when the contract details with the merchant are changed. Do if.

[1211] The merchant process first generates a data update instruction 5406 in step 9100, determines from the terminal status whether or not it is in the session established state in step 9101, and if it is in the session established state, step 9103. Then, the generated data update command is transmitted to the credit settlement terminal, and if the session is not established, the session establishment process is performed in step 9102 to establish a session with the service providing system, and then the process proceeds to step 9103.

[1212] The merchant process that has sent the data update instruction waits for the upload data 5407 to be received in step 9104 and step 9113. In step 9104, the reception of the uploaded data is determined, and in step 9113, the timeout is determined.

[1213] In the timeout determination in step 9113, if the upload data is not received during the timeout time TUDM (TUDM&gt; 0) or more, the merchant process times out, and in step 9114, the merchant process timeout error processing is performed. , End the forced data update process.

[1214] When the upload data is received, the merchant process decrypts the received upload data with the service provider's private key in step 9105, performs the merchant process validity check in step 9106, and upload data. Verify the effectiveness of.

[1215] If the merchant process validity check is passed, the merchant process proceeds to step 9107, and if the merchant process validity check fails, the merchant process determines that the received message is not valid. , Step 9115 performs merchant process session error handling and ends the forced data update process.

[1216] In step 9107, the merchant process decompresses the terminal data 5531 of the uploaded data, and in step 9108, performs a data collation check to verify that the terminal data has not been tampered with.

[1217] If the data collation check is passed, the merchant process first generates new terminal data in step 9109 based on the capacity of the actual data area of the credit settlement terminal and the data generation time, and then steps. In 9110, the difference between the terminal data that has been decompressed and the new terminal data is taken to generate update data 5408, and the generated update data in step 9111 is sent to the credit settlement terminal, and in step 9112. , Updates the terminal data 24104 of the merchant information server and ends the forced data update process.

[1218] If the data collation check fails, it is determined that the terminal data may have been tampered with, and the merchant process generates the out-of-function instruction 5408'in step 9116, and steps 9117. Then, the generated outage command is sent to the credit settlement terminal, and in step 9118, the merchant status 24012 on the merchant information server is changed to "unusable", and in step 9119, the merchant process session error handling. To end the forced data update process.

[1219] In the generation of new terminal data in step 9109, the data stored in the RAM and the hard disk are reorganized so that the temporary area becomes empty. In particular, if there is not enough space in the actual data area, it is necessary to compare the sales times of each sales information, assign a local address to the sales information with the latest sales time, and upgrade the program of the credit settlement terminal. If there is, the data in the basic program area is also updated. However, the merchant area is updated to the data in the merchant area of the terminal data received from the credit card payment terminal.

[1220] On the other hand, in the credit card payment terminal, the compulsory data update process is started by receiving the data update command 5406 and generating the compulsory data update process.

[1221] First, in step 9000, the credit card payment terminal decrypts the encryption of the data update instruction with the merchant's private key, and in step 9001, the merchant validity check is performed to verify the validity of the data update instruction.

[1222] If the merchant validity check is passed, the credit settlement terminal displays "Data update in progress" on the LCD in step 9002, and compresses the data in the RAM and the hard disk in step 9003. , Generate upload data 5407 and send the generated upload data to the merchant process in step 9004.

[1223] If the merchant validity check fails, the credit card payment terminal performs the merchant session error processing in step 9011 and ends the forced data update processing.

[1224] The credit card payment terminal that has sent the uploaded data waits for the reception of the message from the merchant process in step 9005 and step 9012. In step 9005, the reception of the message is determined, and in step 9012, the timeout is determined.

[1225] In the timeout determination in step 9012, if no message is received for the timeout time TDM (TDM&gt; 0) or longer, the credit settlement terminal times out, and in step 9013, the merchant timeout error processing is performed. The forced data update process is terminated.

[1226] When a message from the merchant process is received, the credit card payment terminal decrypts the received message with the merchant's private key in step 9006, performs a merchant validity check in step 9007, and receives the message. Verify the validity of the message.

[1227] If the merchant validity check is passed, the credit card payment terminal proceeds to step 9008, and if the merchant validity check fails, the credit card payment terminal is in step 9014 to handle the merchant session error. And end the forced data update process.

[1228] In step 9008, the credit settlement terminal determines whether the received message is the update data 5408 or the function stop command 5408', and if it is the update data, in step 9009, the terminal data of the update data. The data compression of 5539 is released, the data of the RAM and the hard disk are updated, and in step 9010, the display of "Data update in progress" is released, and the forced data update process is terminated.

[1229] If the received message is a function stop command, the credit card payment terminal displays "unavailable" on the LCD in step 9015, and clears the terminal enable bit of EEPROM 1503 in step 9016. The operation is disabled, and in step 9017, the terminal status is changed to disabled, and the forced data update process ends.

[1230] Next, a processing flow in the data backup process will be described.

[1231] FIGS. 123 and 116 show the processing flow of the data update process of the personal credit terminal and the user process of the service providing system in the data backup processing of the personal credit terminal and the service providing system, respectively. The processing of the user process is the same as the data update processing.

[1232] The data backup process is started by the personal credit terminal generating a data backup process when the battery capacity of the personal credit terminal becomes Q or less.

[1233] The personal credit terminal first displays "Data update in progress" on the LCD in step 9200, generates a data update request 5109 in step 9201, and in step 9202, the session is established from the terminal status. If it is in the session establishment state, the generated data update request is sent to the user process in step 9204, and if it is not in the session establishment state, the session establishment process is performed in step 9203 to provide the service. After establishing a session with the system, proceed to step 9204.

[1234] The personal credit terminal that has sent the data update request waits for the data update response 5110 to be received in step 9205 and step 9216. In step 9205, the reception of the data update response is determined, and in step 9216, the timeout is determined.

[1235] In the timeout determination in step 9216, if no data update response is received for the timeout time TRURU (TRURU&gt; 0) or longer, the personal credit terminal times out and the user timeout error handling in step 9217. And end the data backup process.

[1236] When the personal credit terminal receives the data update response, the personal credit terminal decrypts the data update response with the user's private key in step 9206, performs the user validity check in step 9207, and performs the data update response. Verify the effectiveness of.

[1237] If the user validity check is passed, the personal credit terminal compresses the RAM data in step 9208 to generate upload data 5111, and in step 9209, the generated upload data is used by the user. Send to process.

[1238] If the user validity check fails, the personal credit terminal performs the user session error processing and ends the data backup processing in step 9218.

[1239] The personal credit terminal that has transmitted the uploaded data waits for the reception of the message from the user process in steps 9210 and 9219. In step 9210, the reception of the message is determined, and in step 9219, the timeout is determined.

[1240] In the timeout determination in step 9219, if no message is received for the timeout time TDU (TDU&gt; 0) or longer, the personal credit terminal times out, and in step 9220, the user timeout error processing is performed. , End the data backup process.

[1241] When a message from a user process is received, the personal credit terminal decrypts the received message with the user's private key in step 9211 and performs a user validity check in step 9212 to receive the message. Verify the validity of the message you sent.

[1242] If the user validity check is passed, the personal credit terminal goes to step 9213, and if the user validity check fails, the personal credit terminal goes to step 9221 for the user session. Performs error processing and ends data backup processing.

[1243] In step 9213, the personal credit terminal determines whether the received message is update data 5112 or function stop command 5112', and if it is update data, first, in step 9214, update data. Uncompress the terminal data 5239, update the RAM data, display "low battery" in step 9215, and change the terminal status to "write protected" in step 9225. This prevents new data from being written to RAM and ends the data backup process.

[1244] If the received message is an outage command, the personal credit terminal displays "unavailable" on the LCD in step 9222 and clears the terminal enable bit in EEPROM 1503 in step 9223. Then, the operation is disabled, and in step 9224, the terminal status is changed to disabled, and the data backup process is terminated.

[1245] Next, the processing flow in the processing of "settlement" will be described.

[1246] FIGS. 124 to 125 show a processing flow of a credit card payment terminal in the processing of "payment". The "payment" process is initiated by the credit card payment terminal 300 generating a payment process when the merchant presses the credit card payment switch in the register.

[1247] The credit card payment terminal first generates four types of payment offer responses 5701 corresponding to the contents of the payment offer 5700 received from the personal credit terminal in step 9300. The four types of payment offer responses are a payment offer response that indicates that the payment amount specified by the user is lower than the billing amount of the merchant, and a payment that indicates that the user specifies a credit card that the merchant cannot handle. An offer response, a payment offer response indicating that the user specifies a payment option that the merchant cannot handle, and a payment offer response that indicates that the merchant can handle the user's payment offer.

[1248] These four types of payment offer responses differ in the part of the response message 5809 and the transaction number 5810 of the payment offer response (Fig. 89 (b)), and the payment amount specified by the user is higher than the billed amount of the merchant. In the case of a payment offer response indicating that the payment is also low, the response message is set to a message indicating that the payment amount is insufficient, and the transaction number is set to zero. Also, in the case of a payment offer response indicating that the user has specified a credit card that the merchant cannot handle, the response message is set to indicate that the card is not available, and the transaction number is set to zero. To. Also, in the case of a payment offer response indicating that the user has specified a payment option that the merchant cannot handle, the response message is set to indicate that the payment option is not available, and the transaction number is set to zero. Will be done. Then, in the case of a payment offer response indicating that the user's payment offer can be handled by the merchant, a greeting message is set in the response message, and a non-zero number uniquely indicating the transaction with the user is set in the transaction number. To.

[1249] The credit card payment terminal that has generated the four types of payment offer responses displays Waiting for payment operation on the LCD in step 9301, and waits for the receipt of the payment offer 5700 by infrared communication in step 9302.

[1250] Upon receiving the payment offer from the personal credit terminal, the credit card payment terminal verifies the content of the received payment offer in steps 9303 to 9305.

[1251] If the payment amount of the payment offer is less than the billed amount, the credit card payment terminal proceeds to step 9317 to indicate that the payment amount specified by the user is lower than the billed amount of the merchant. Is transmitted to the personal credit terminal by infrared communication, and in step 9318, the shortage of the payment amount is displayed on the LCD, the process returns to step 9302, and the payment offer is received again.

[1252] If the service code of the payment offer is not in the service code list of the credit payment terminal, the credit payment terminal proceeds to step 9319 and the user specifies a credit card that the merchant cannot handle. The payment offer response indicating that is sent to the personal credit terminal by infrared communication, the credit card cannot be handled is displayed on the LCD in step 9320, the process returns to step 9302, and the payment offer is received again.

[1253] If the payment option code of the payment offer is not in the service code list of the credit card payment terminal, the credit card payment terminal proceeds to step 9321 and the user specifies a payment option that the merchant cannot handle. Send a payment offer response indicating that you are available to your personal credit terminal via infrared communication, in step 9322, display the payment option not available on the LCD, return to step 9302, and wait for the payment offer to be received again. ..

Otherwise, the credit payment terminal proceeds to step 9306 and sends a payment offer response, indicating that the merchant can handle the user's payment offer, via infrared communication to the personal credit terminal, and then , Step 9307 displays "Credit Inquiry" on the LCD, Step 9308 generates a Credit Inquiry Request 5702 from the payment offer and payment offer response, and Step 9309 from the Terminal Status, is the session established status? If it is in the session establishment state, the generated credit inquiry request is sent to the merchant process in step 9311, and if it is not in the session establishment state, the session establishment process is performed in step 9310 to provide the service provision system. After establishing a session with, proceed to step 9311.

[1255] The credit settlement terminal that has sent the credit inquiry request waits for the receipt of the credit inquiry response 5704 in step 9312 and step 9323. In step 9312, the reception of the authorization inquiry response is determined, and in step 9323, the timeout is determined.

[1256] In the timeout determination of step 9323, if the credit inquiry response is not received for the timeout time TAR (TAR&gt; 0) or more, the credit settlement terminal times out, and in step 9324, the merchant timeout error processing is performed. Perform and end the "payment" process.

When receiving the authorization inquiry response, the credit settlement terminal decrypts the authorization of the authorization inquiry response with the merchant's private key in step 9313, performs the merchant validity check in step 9314, and performs the authorization inquiry response. Verify effectiveness.

[1258] If the merchant validity check is passed, the credit card payment terminal proceeds to step 9315, and if the merchant validity check fails, the merchant session error processing is performed in step 9325, and "payment" is performed. "Ends the process.

[1259] In step 9315, the credit settlement terminal determines the credit inquiry result of the credit inquiry response, and if the credit inquiry fails, displays the credit inquiry result on the LCD in step 9326 to display the credit inquiry result of "payment". When the process is completed and the credit inquiry is passed, the credit inquiry result and the contents of the user's personal data are displayed on the LCD in step 9316.

[1260] The credit card payment terminal that displays the credit inquiry result and the contents of the user's personal data on the LCD waits for the payment processing request operation 20616 by the merchant in steps 9400 and 9413. In step 9400, the settlement processing request operation is determined by the merchant, and in step 9413, the timeout is determined.

[1261] In the timeout determination in step 9413, if the payment processing request operation by the merchant is not performed during the timeout time TMAO (TMAO&gt; 0) or more, the credit settlement terminal times out, and in step 9414, the merchant timeout. -Perform error processing and end the "payment" processing.

[1262] When a payment processing request operation is performed by a merchant, the credit card payment terminal displays "payment in progress" on the LCD in step 9401, and in step 9402, the payment request is made from the payment offer and the payment offer response. Generate a 5705 and in step 9403 send the generated payment request 5705 to the merchant process.

[1263] The credit card payment terminal that has sent the payment request 5705 to the merchant process waits in step 9404 and step 9415 to receive the payment completion notification 5708 from the merchant process. In step 9404, the reception of the settlement completion notification 5708 is determined, and in step 9415, the timeout is determined.

[1264] In the timeout determination in step 9415, if the payment completion notification 5708 is not received during the timeout time TSPCC (TSPCC&gt; 0) or longer, the credit settlement terminal times out, and in step 9416, the merchant timeout error processing. And end the "payment" process.

[1265] When the payment completion notification 5708 is received, the credit card payment terminal decrypts the received payment completion notification 5708 encryption with the merchant's private key in step 9405, and performs the merchant validity check in step 9406. Verify the validity of the received message.

[1266] If the merchant validity check is passed, the credit card payment terminal proceeds to step 9407, and if the merchant validity check fails, the credit card payment terminal handles the merchant session error in step 9417. And end the "payment" process.

[1267] The credit card payment terminal generates a receipt 5709 in step 9407 and sends the generated receipt 5709 to the merchant process in step 9408. Then, in step 9409, the decrypted payment completion notification 5708 is stored in the temporary area of RAM, in step 9410, the sales history list and the sales history list address are updated, and in step 9411, the LCD is displayed. , "Payment completed" is displayed. Then, in step 9412, it is determined from the free space of the temporary area whether or not the data update process is necessary, and if the free space of the temporary area is equal to or more than the set value AM (AM&gt; 0), "Settlement" is performed as it is. If the value is less than the set value AM, a data update process is generated and the process proceeds to the data update process.

[1268] Further, FIGS. 126 to 127 show the processing flow of the merchant process in the processing of payment.

[1269] In the merchant process, the process of "payment" is initiated by receiving a credit inquiry request 5702 from a credit card payment terminal. The merchant process first decrypts the received authorization request with the service provider's private key in step 9500, and in step 9501 performs a merchant process validity check to verify the validity of the authorization request. ..

[1270] If the merchant process validity check is passed, the merchant process determines in step 9502 whether or not it belongs to the process group from the value of the service director process ID in the merchant process management information, and processes. If it belongs to a group (service director process ID 0), step 9515 sends a decrypted credit inquiry request to the service director process and does not belong to the process group (service director process ID 0). For the director process ID = 0), in step 9503, the decrypted credit inquiry request is sent to the service manager process.

[1271] If the merchant process validity check fails, the merchant process determines that the received message is not valid, and in step 9514, performs merchant process session error handling and "payment" processing. finish.

[1272] The service director process, or the merchant process that sent the authorization request to the service manager process, waits in step 9504 to receive an authorization response 5840 from the service director process. Upon receiving the authorization response 5840 from the service director process, the merchant process seals the authorization response 5840 to the merchant in step 9505 and sends the authorization response 5704 to the credit settlement terminal in step 9506. ..

[1273] In step 9507, the merchant process that has sent the authorization inquiry response 5704 to the credit card payment terminal waits for the payment request 5705 to be received from the credit card payment terminal. Upon receiving the payment request 5705 from the credit card payment terminal, the merchant process decrypts the received payment request 5705 with the service provider's private key in step 9508, and performs the merchant process validity check in step 9509. Verify the validity of payment request 5705.

[1274] If the Merchant Process Validity Check Passes, the Merchant Process sends a decrypted payment request 5705 to the Service Director Process in step 9510 and fails the Merchant Process Validity Check. Determines that the received message is not valid, and in step 9516, performs merchant process session error processing and ends the "settlement" process.

[1275] The merchant process that has sent the payment request to the service director process waits in step 9511 to receive the payment completion notification 5937 from the service director process. Upon receiving the payment completion notification 5937 from the service director process, the merchant process seals the payment completion notification 5937 to the merchant in step 9512 and sends the payment completion notification 5708 to the credit card payment terminal in step 9513.

[1276] The merchant process that has sent the payment completion notification 5708 to the credit card payment terminal waits for the receipt 5709 to be received from the credit card payment terminal in step 9600. Upon receiving receipt 5709 from the credit card payment terminal, the merchant process decrypts the received receipt 5709 with the service provider's private key in step 9601 and performs a merchant process validity check in step 9602. Verify the validity of receipt 5709.

[1277] If the merchant process validity check is passed, the merchant process sends the decrypted receipt 5709 to the service director process in step 9603 and on the merchant information server in step 9604. The sales history list and the sales history list address are updated, and the "payment" process is completed.

[1278] If the Merchant Process Validity Check fails, the Merchant Process determines that the received message is not valid, and in step 9605, performs Merchant Process Session Error processing and processes "Payment". finish.

[1279] FIGS. 128 to 129 show the processing flow of the personal credit terminal in the processing of "payment". The "payment" process is initiated by the personal credit terminal generating a payment process when the user performs a payment operation.

[1280] The personal credit terminal first generates a payment offer 5700 based on the credit card, payment amount, and payment option specified by the user in the payment operation in step 9700, and the payment offer generated in step 9701. Is transmitted to the credit card payment terminal by infrared communication.

[1281] The personal credit terminal that has sent the payment offer to the credit payment terminal waits for the payment offer response 5701 to be received in steps 9702 and 9713. In step 9702, the receipt of the payment offer response is determined, and in step 9713, the timeout is determined.

[1282] In the timeout determination of step 9713, if the payment offer response is not received for the timeout time TPOR (TPOR&gt; 0) or more, the personal credit terminal times out, and in step 9714, the payment offer response is sent to the LCD. Displays a timeout error and ends the "payment" process.

[1283] Upon receiving the payment offer response, the personal credit terminal checks the service provider's digital signature on the service provider phone number of the payment offer response in step 9703 and passes this signature check. In that case, the process proceeds to step 9704, and if the payment fails, it is determined that the payment offer response is not valid, and in step 9715, the payment offer response error is displayed on the LCD and the "payment" process is completed. To do.

[1284] In step 9704, the personal credit terminal determines from the value of the transaction number of the payment offer response whether or not the payment offer sent to the credit settlement terminal is the content that the merchant can handle. If the transaction number in the payment offer response is non-zero, the payment offer is what the merchant can handle and the personal credit terminal proceeds to step 9705. If the transaction number of the payment offer response is zero, the payment offer is not handled by the merchant, and the personal credit terminal displays the payment offer response error on the LCD in step 9716 and "payments". Ends the processing of.

[1285] In step 9705, the personal credit terminal collates the payment amount of the payment offer with the billing amount of the payment offer response, and if the payment amount and the billing amount are equal, the process proceeds to step 9708 and the payment amount. However, if it is larger than the billed amount, in step 9706, the screen for confirming the payment amount shown in FIG. 44 (i) is displayed on the LCD, and in step 9707 and step 9717, the confirmation operation by the user is awaited. When the confirmation operation is performed by the user, the personal credit terminal proceeds to step 9708. In step 9707, the personal credit terminal determines the confirmation operation by the user, and in step 9717, determines the timeout.

[1286] In the time-out determination of step 9717, if the confirmation operation is not performed for the timeout time TUAO (TUAO&gt; 0) or more, the personal credit terminal times out, and in step 9718, the confirmation operation is displayed on the LCD. Display a timeout error and end the "payment" process.

[1287] The personal credit terminal displays "Payment processing in progress" on the LCD in step 9708, and then in step 9709, generates a payment request 5703 from the payment offer and the payment offer response, and steps. In 9710, it is determined from the terminal status whether or not the session is established. If the session is established, the generated payment request is sent to the user process in step 9712. If the session is not established, step 9712 is used. At 9711, the session establishment process is performed to establish a session with the service providing system, and then the process proceeds to step 9712.

[1288] In the session establishment process of step 9711, the personal credit terminal calls the service provider telephone number of the payment offer response to connect to the service provider system in the merchant's home service area. In other words, when the personal credit terminal has already established a session with the service providing system at the time of processing the "payment", the personal credit terminal performs the "payment" processing with the service providing system and newly In addition, when establishing a session with the service providing system, "payment" processing is performed with the service providing system of the service area where the merchant is located.

[1289] The personal credit terminal that has sent the payment request waits for receipt 5710 from the user process in steps 9800 and 9807. In step 9800, the receipt of the receipt 5710 is determined, and in step 9807, the timeout is determined.

[1290] In the timeout determination of step 9807, if the receipt 5710 is not received during the timeout time TSPR (TSPR&gt; 0) or more, the personal credit terminal times out and the user timeout error handling is performed in step 9808. And end the "payment" process.

[1291] When the receipt 5710 is received, the personal credit terminal decrypts the receipt 5710 with the user's private key in step 9801, performs a user validity check in step 9802, and receives the receipt 5710. Verify the effectiveness of.

[1292] If the user validity check is passed, the personal credit terminal goes to step 9803, and if the user validity check fails, the personal credit terminal goes to step 9809 for the user session. Performs error processing and ends the "payment" process.

[1293] The personal credit terminal stores the decrypted receipt 5710 in the temporary area of RAM in step 9803, and updates the usage history list and the usage history list address in step 9804. In step 9805, display the receipt on the LCD. Then, in step 9806, it is determined from the free space of the temporary area whether or not the data update process is necessary, and if the free space of the temporary area is equal to or more than the set value AU (AU&gt; 0), "Settlement" is performed as it is. If the value is less than the set value AU, a data update process is generated and the process proceeds to the data update process.

[1294] Further, FIG. 130 shows a processing flow of a user process in the processing of payment.

[1295] In the user process, the process of "payment" is initiated by receiving a payment request 5703 from a personal credit terminal. The user process first decrypts the received payment request with the service provider's private key in step 9900, and performs a user process validity check in step 9901 to verify the validity of the payment request.

[1296] If the user process validity check is passed, the user process determines in step 9902 whether or not it belongs to the process group from the value of the service director process ID of the user process management information, and processes. If it belongs to a group (service director process ID 0), step 9909 sends a decrypted payment request to the service director process and does not belong to the process group (service director). At process ID = 0), step 9903 sends the decrypted payment request to the service manager process.

[1297] If the user process validity check fails, the user process determines that the received message is not valid, performs user process session error processing in step 9908, and processes "payment". finish.

[1298] The service director process, or the user process that sent the payment request to the service manager process, waits in step 9904 to receive receipt 6016 from the service manager process. Upon receiving the receipt 6016 from the service manager process, the user process seals the receipt 6016 to the user in step 9905, sends the receipt 5710 to the personal credit terminal in step 9906, and further In step 9907, the usage history list and the usage history list address on the user information server are updated to end the "payment" process.

[1299] Further, FIG. 131 (a) shows a processing flow of the payment system in the processing of payment. The processing of "payment" is started by receiving the payment request 5706 from the payment processing institution process of the service providing system.

[1300] The payment system first decrypts the received payment request 5706 with the private key of the payment processing institution in step 10000, checks the validity of the payment processing institution in step 10001, and validates the payment request 5706. Verify sex.

[1301] If the payment processing institution validity check is passed, the payment system sets the data of the subscriber information server, the member store information server, and the transaction information server in step 10002 based on the payment request 5706. Update and perform payment processing, in step 10003, generate payment completion notification 5707, and in step 10004, send the generated payment completion notification 5707 to the payment processing institution process to end the "payment" process.

[1302] If the payment processing institution validity check fails, the payment system determines that the received message is not a valid message, and in step 10005, performs the payment processing institution session error processing, and " End the "payment" process. In payment processing institution session error processing, the payment system sends a session error message to the management system of the payment system, and sends a session error message to the payment processing institution process of the service providing system to communicate with the payment processing institution. Disconnect the line.

[1303] Further, the settlement processing institution validity check is a process for verifying the validity of the message received from the settlement processing institution process of the service providing system, and as shown in FIG. 131 (b), the settlement processing institution effectiveness. In the check, four types of verification are performed. First, in step 10006, the digital signature of the service provider is verified, in step 10007, the service provider ID is verified, in step 10008, the validity period of the received message is verified, and further, in step 10009, the received message is verified. Verify the message issuance time. In the verification of the issue time in step 10009, the deviation between the issue time of the received information and the current time is verified, and if the deviation is equal to or greater than the time TTP (TTP&gt; 0), it is determined that the information is invalid. .. Therefore, only if the service provider's digital signature verification is passed, the service provider ID matches, the validity period verification is passed, and the issue time verification is passed, the payment processing institution validity check is passed. Judgment is made, and in other cases, it is judged that the failure has occurred.

[1304] Further, FIG. 132 (a) shows a processing flow of a settlement processing institution process in the processing of settlement. In the payment processing institution process, the processing of "payment" is initiated by receiving a payment request 5910 from the service director process.

[1305] The payment processing institution process first seals the payment request 5910 to the payment processing institution in step 10100, and sends the payment request 5706 to the payment system in step 10101.

[1306] In step 10102, the payment processing institution process that has sent the payment request 5706 to the payment system waits for the payment completion notification 5707 to be received from the payment system. Upon receiving the payment completion notification 5707 from the payment system, the payment processing agency process decrypts the received payment completion notification 5707 with the service provider's private key in step 10103, and the payment processing agency process is enabled in step 10104. Perform a sex check and verify the validity of the payment completion notification 5707.

[1307] If the payment processing institution process pass the validity check, the payment processing institution process sends a decrypted payment completion notification 5707 to the service director process in step 10105, and in step 10106, The payment history list and the payment history list address on the payment processing institution information server are updated, and the "payment" process is completed.

[1308] If the settlement processing institution process validity check fails, the settlement processing institution process determines that the received message is not valid, and in step 10107, performs the settlement processing institution process session error processing. Finish the "payment" process. The payment processor process session error handling erases the payment processor process by the service manager process and disconnects the payment system. At this time, the settlement processing institution process sends a session error message indicating that an invalid message has been received to the management system 407.

[1309] Further, the payment processing institution process validity check is a process for verifying the validity of the information received from the payment system, and as shown in FIG. 132 (b), the payment processing institution process validity check is 3 Perform type verification. First, in step 10108, the digital signature of the payment processing institution is verified, in step 10109, the payment processing institution ID is verified, and further, in step 10110, the issuance time of the received information is verified. In the verification of the issue time in step 10110, the deviation between the issue time of the received information and the current time is verified, and if the deviation is equal to or greater than the time TTPP (TTPP&gt; 0), it is determined that the information is invalid. .. Therefore, it is determined that the settlement processing institution process validity check is passed only when the settlement processing institution's digital signature verification is passed, the settlement processing institution ID matches, and the issuance time verification is passed, and in other cases. Determines to have failed.

[1310] Further, FIGS. 133 to 134 show a processing flow of the service director process in the processing of payment.

[1311] In the service director process, when a credit inquiry request 5820 and a payment request 5827 are received from the service manager process, or when a credit inquiry request 5820 is received from the merchant process, or from a user process. The "payment" process is started in the three cases when the payment request 5827 is received.

[1312] If a credit inquiry request 5820 is received from the merchant process, the service director process waits for the payment request 5827 to be received from the user process in step 10216 and then receives the payment request 5827 from the user process. , Proceed to step 10200.

[1313] If the payment request 5827 is received from the user process, the service director process waits for the authorization request 5820 to be received from the merchant process in step 10217, and then receives the authorization request 5820 from the merchant process. When the message is received, the process proceeds to step 10200.

[1314] If the service manager process receives the authorization request 5820 and the payment request 5827, the service director process continues to step 10200 and the validity of the authorization request 5820 and the payment request 5827. Check. In the validity check of the credit inquiry request and payment request in step 10200, the service director process processes the data of the payment offer and payment offer response part of the credit inquiry request and the payment offer and payment offer response part of the payment request. The verification was performed and the validity period of the payment offer and payment offer response was verified, and the validity check of the credit inquiry request and payment request was passed only when the data matching matched and passed the validity period verification. In other cases, it is determined to be a fail.

[1315] If the authorization check of the authorization request and the payment request fails, the service director process performs the service director process session error processing in step 10212 and ends the processing of "payment". .. The service director process session error handling clears the service director process and the user and merchant processes in the same process group as the service director process by the service manager process. At this time, the service director process sends a session error message indicating that an invalid message has been received to the management system 407.

[1316] If the authorization request and payment request validation pass, the service director process first refers to the merchant's customer table in step 10201 for the customer corresponding to the payment request's user ID. Identify the number, then in step 10202 access the information on the user information server corresponding to the user to generate the authorization inquiry response 5840, and in step 10203 send the generated authorization inquiry response 5840 to the merchant process. Then, in step 10204, the service provision history of the credit inquiry is added to the service provision history list 4303 to update the service provision history list 4303.

[1317] In generating the authorization response 5840 in step 10202, the service director process does not set the user personal data 5834 if there is a problem with the user's credit status. Also, if there is no previous transaction by the personal remote credit payment service between the user and the merchant, the customer number corresponding to the user ID cannot be specified, so the customer number 5836 is not set in this case either.

[1318] The service director process that updated the service provision history list in step 10204 waits for the payment request 5850 to be received from the merchant process in steps 10205 and 10213. In step 10205, the reception of the settlement request 5850 is determined, and in step 10213, the timeout is determined.

[1319] In the timeout determination in step 10213, if the settlement request 5850 is not received for the timeout time TCR (TCR&gt; 0) or longer, the service director process times out, and in step 10214, the service director process timeout. -Perform error processing and end the "payment" processing. The service director process timeout error handling clears the service director process and the user and merchant processes in the same process group as the service director process by the service manager process. At this time, the service director process sends a timeout error message indicating that the timeout has occurred to the management system 407.

[1320] If a payment request 5850 is received from the merchant process, the service director process checks the validity of the payment request 5850 in step 10206. In step 10206, in the payment request validity check, the service director process matches the data of the payment offer and payment offer response part of payment request 5850 with the payment offer and payment offer response part of the payment request, and the payment request. When the reference number of 5850 and the reference number of the credit inquiry response are matched and the validity period of payment request 5850 is verified, the data matching matches, the reference numbers match, and the validity period verification is passed. Only, it is judged that the validity check of the payment request is passed, and in other cases, it is judged as a fail.

[1321] If the validity check of the payment request fails, the service director process performs the service director process session error processing in step 10215, and ends the processing of "payment".

[1322] If the payment request validity check is passed, the service director process refers to the payment processing institution table 4304 in step 10207 to select the payment processing institution requesting the payment processing, and step 10208. Then, a member process request is sent to the service manager process to request the payment processing institution process corresponding to the selected payment processing institution as a member process of the same process group, and the payment processing institution requested in step 10209. Wait for the process to become a member process.

[1323] When the requested payment processing institution process becomes a member process, the service director process, in step 10210, sets the information on the user information server corresponding to the user and the information on the merchant information server corresponding to the merchant. The payment request 5910 is generated by accessing the information on the payment processing institution information server corresponding to the payment processing institution, and the generated payment request 5910 is transmitted to the payment processing institution process in step 10211.

[1324] The service director process that has sent the payment request 5910 waits in step 10300 and step 10311 to receive the payment completion notification 5927 from the payment processing institution process. In step 10300, the reception of the settlement completion notification 5927 is determined, and in step 10311, the timeout is determined.

[1325] In the timeout determination in step 10311, if the payment completion notification 5927 is not received for the timeout time TTPCC (TTPCC&gt; 0) or longer, the service director process times out, and in step 10312, the service director process. Performs timeout error processing and ends the "payment" process.

[1326] Upon receiving the payment completion notification 5927 from the payment processing institution process, the service director process determines in step 10301 whether or not there is a customer number corresponding to the user, and if so, if there is a customer number. If there is no customer number in step 10303, step 10302 generates a customer number that uniquely identifies the user to the merchant, registers it in the merchant's customer table, and then proceeds to step 10303.

[1327] The service director process generates a payment completion notification 5937 to the merchant from the payment completion notification 5927 and the payment request 5850 in step 10303, and transfers the generated payment completion notification 5937 to the merchant process in step 10304. Send.

[1328] The service director process that has sent the payment completion notification 5937 waits for receipt 6008 from the merchant process in steps 10305 and 10313. In step 10305, the receipt of the receipt 6008 is determined, and in step 10313, the timeout is determined.

[1329] In the timeout determination of step 10313, if the receipt 6008 is not received for the timeout time TMR (TMR&gt; 0) or longer, the service director process times out, and in step 10314, the service director process timeout. -Perform error processing and end the "payment" processing.

[1330] If a receipt 6008 is received from the merchant process, the service director process generates a receipt 6016 from the receipt 6008 and the payment completion notification 5927 to the user in step 10306 and generated in step 10307. The receipt 6016 is sent to the user process, and in step 10308, the service provision history list 4303 for credit payment is added to the service provision history list 4303 to update the service provision history list 4303.

[1331] The service director process that has updated the service provision history list 4303 waits for the user process to complete the "payment" process in step 10309, and when the user process completes the "payment" process, step 10310. Then, the process deletion request of the service director process itself is sent to the service manager process, and the processing of "payment" is completed. By sending the process erase request in step 10310, the service director process is erased by the service manager process.

[1332] Next, the processing flow in the "cancellation" process will be described.

[1333] FIG. 135 shows a processing flow of a credit card payment terminal in the processing of cancellation. The process of "cancellation" is started by the credit card payment terminal 300 generating a cancellation process when the merchant performs the cancel operation 901.

[1334] The credit settlement terminal first displays "sales cancellation processing in progress" on the LCD in step 10400, and in step 10401, generates a cancellation request 6100 from the settlement completion notification 5937 of the transaction to be canceled, and steps 10402. Then, from the terminal status, it is determined whether or not the session is established, and if the session is established, the generated cancellation request is sent to the merchant process in step 10404. If the session is not established, step 10403 is sent. Performs the session establishment process in, establishes a session with the service providing system, and then proceeds to step 10404.

[1335] The credit card payment terminal that has sent the cancellation request waits in step 10405 and step 10412 to receive the cancellation completion notification 6104 from the merchant process. In step 10405, the reception of the cancellation completion notification 6104 is determined, and in step 10412, the timeout is determined.

[1336] In the timeout determination in step 10412, if the cancellation completion notification 6104 is not received for the timeout time TSPCC (TSPCC&gt; 0) or longer, the credit settlement terminal times out, and in step 10413, the merchant timeout error processing. To end the "cancel" process.

[1337] When the cancellation completion notification 6104 is received, the credit card payment terminal decrypts the received cancellation completion notification 6104 with the merchant's private key in step 10406, and performs the merchant validity check in step 10407. Verify the validity of the received message.

[1338] If the merchant validity check is passed, the credit card payment terminal proceeds to step 10408, and if the merchant validity check fails, the credit card payment terminal is in step 10414 to handle the merchant session error. To end the "cancel" process.

[1339] The credit card payment terminal stores the decrypted cancellation completion notification 6104 in the temporary area of the RAM in step 10408, and updates the sales history list and the sales history list address in step 10409. At step 10410, the LCD indicates the completion of the cancellation process. Then, in step 10411, it is determined from the free space of the temporary area whether or not the data update process is necessary, and if the free space of the temporary area is equal to or more than the set value AM (AM&gt; 0), "Cancel" is used as it is. If the value is less than the set value AM, a data update process is generated and the process proceeds to the data update process.

[1340] Also, FIG. 136 shows the processing flow of the merchant process in the processing of "cancellation".

[1341] In the merchant process, the process of "cancellation" is initiated by receiving a cancellation request 6100 from the credit card payment terminal. The merchant process first decrypts the received cancellation request with the service provider's private key in step 10500, and performs a merchant process validity check in step 10501 to verify the validity of the cancellation request.

[1342] If the merchant process validity check is passed, the merchant process determines in step 10502 whether or not it belongs to the process group from the value of the service director process ID in the merchant process management information, and processes. If it belongs to a group (service director process ID 0), in step 10509, a cancel request that decrypts the code is sent to the service director process, and if it does not belong to the process group (service director). At process ID = 0), step 10503 sends a decrypted cancellation request to the service manager process.

[1343] If the Merchant Process Validity Check fails, the Merchant Process determines that the received message is not valid, and in step 10508, performs Merchant Process Session Error handling and cancels. finish.

[1344] The merchant process that has sent the cancellation request 6205 to the service director process or the service manager process waits in step 10504 to receive the cancellation completion notification 6241 from the service director process.

Upon receiving the cancellation completion notification 6241 from the service director process, the merchant process seals the cancellation completion notification 6241 to the merchant in step 10505 and sends the cancellation completion notification 6104 to the credit settlement terminal in step 10506. The transmission is performed, and in step 10507, the sales history list and the sales history list address on the merchant information server are updated to end the cancel process.

[1346] Further, FIG. 137 shows a processing flow of the personal credit terminal in the processing of cancellation. The "cancel" process is initiated by the personal credit terminal generating a cancel process when the user performs the cancel operation 904.

[1347] The personal credit terminal first displays "Payment cancellation processing in progress" on the LCD in step 10600, and then generates a cancellation request 6101 from the receipt 6016 of the transaction to be canceled in step 10601. Then, in step 10602, it is determined from the terminal status whether or not the session is established, and if the session is established, the generated cancellation request 6101 is sent to the user process in step 10604, and the session is not established. In step 10603, the session establishment process is performed to establish a session with the service providing system, and then the process proceeds to step 10604.

[1348] The personal credit terminal that has sent the cancellation request 6101 waits in step 10605 and step 10612 to receive the cancellation processing receipt 6105 from the user process. In step 10605, the receipt of the cancellation processing receipt 6105 is determined, and in step 10612, the timeout is determined.

[1349] In the timeout determination in step 10612, if the cancellation processing receipt 6105 is not received during the timeout time TSPCR (TSPCR&gt; 0) or longer, the personal credit terminal times out and the user timeout occurs in step 10613. Performs error processing and ends the "cancel" process.

[1350] When the cancellation processing receipt 6105 is received, the personal credit terminal decrypts the encryption of the cancellation processing receipt 6105 with the user's private key in step 10606, and performs the user validity check in step 10607. , Verify the validity of Cancellation Receipt 6105.

[1351] If the user validity check is passed, the personal credit terminal goes to step 10608, and if the user validity check fails, the personal credit terminal goes to step 10614 for the user session. Performs error processing and ends the "cancel" process.

[1352] The personal credit terminal stores the decrypted cancellation processing receipt 6105 in the temporary area of RAM in step 10608, and updates the usage history list and the usage history list address in step 10609. Then, in step 10610, the cancellation processing receipt is displayed on the LCD. Then, in step 10611, it is determined from the free space of the temporary area whether or not the data update process is necessary, and if the free space of the temporary area is equal to or more than the set value AU (AU&gt; 0), "Cancel" is used as it is. If the value is less than the set value AU, a data update process is generated and the process proceeds to the data update process.

[1353] Further, FIG. 138 shows a processing flow of the user process in the processing of cancellation.

[1354] In the user process, the process of "cancellation" is initiated by receiving a cancellation request 6101 from the personal credit terminal. The user process first decrypts the received cancellation request 6101 with the service provider's private key in step 10700, and performs a user process validity check in step 10701 to verify the validity of the cancellation request 6101. ..

[1355] If the user process validity check is passed, the user process determines in step 10702 from the value of the service director process ID of the user process management information whether or not it belongs to the process group, and processes. If it belongs to a group (service director process ID 0), in step 10709, a cancel request 6101 that decrypts the code is sent to the service director process, and if it does not belong to the process group (service director process ID 0). In step 10703, the director process ID = 0) sends the decrypted cancellation request 6101 to the service manager process.

[1356] If the user process validity check fails, the user process determines that the received message is not valid, and in step 10708, performs user process session error processing and "cancels" processing. finish.

[1357] The user process that has sent the cancellation request 6213 to the service director process or the service manager process waits in step 10704 to receive a cancellation receipt 6250 from the service director process. Upon receiving the cancellation receipt 6250 from the service director process, the user process seals the cancellation receipt 6250 to the user in step 10705 and personally credits the cancellation receipt 6105 in step 10706. It is sent to the terminal, and in step 10707, the usage history list and the usage history list address on the user information server are updated, and the "cancel" process is completed.

[1358] Further, FIG. 139 shows a processing flow of the payment system in the processing of cancellation. The "cancellation" process is started by receiving a cancellation request 6102 from the payment processing agency process of the service providing system.

[1359] First, in step 10800, the payment system decrypts the code of the received cancellation request 6102 with the private key of the payment processing institution, and in step 10801, the payment processing institution validity check is performed, and the cancellation request 6102 is valid. Verify sex.

[1360] If the payment processing institution validity check is passed, the payment system sets the data of the subscriber information server, the member store information server, and the transaction information server in step 10802 based on the cancellation request 6102. Update and cancel the credit card payment process, generate a cancellation completion notification 6103 in step 10803, and send the generated cancellation completion notification 6103 in step 10804 to the payment processing institution process to "cancel". End the process.

[1361] If the payment processing institution validity check fails, the payment system determines that the received message is not a valid message, and in step 10805, performs the payment processing institution session error processing and "cancels". "Ends the process.

[1362] Further, FIG. 140 shows the processing flow of the settlement processing institution process in the processing of cancellation. In the settlement processing agency process, the process of "cancellation" is initiated by receiving a cancellation request 6221 from the service director process.

[1363] The payment processing institution process first seals the cancellation request 6221 to the payment processing institution in step 10900 and sends the cancellation request 6102 to the payment system in step 10901.

[1364] In step 10902, the payment processing institution process that has sent the cancellation request 6102 to the payment system waits for the cancellation completion notification 6103 to be received from the payment system. Upon receiving the cancellation completion notification 6103 from the payment system, the payment processing agency process decrypts the received cancellation completion notification 6103 with the service provider's private key in step 10903, and the payment processing agency process is enabled in step 10904. Perform a sex check and verify the validity of the cancellation completion notification 6103.

[1365] If the settlement processing institution process pass the validity check, the settlement processing institution process sends a decrypted cancellation completion notification 6103 to the service director process in step 10905, and in step 10906, Updates the payment history list and the payment history list address on the payment processing institution information server, and ends the "cancel" process.

[1366] If the settlement processing institution process validity check fails, the settlement processing institution process determines that the received message is not valid, and in step 10907, performs the settlement processing institution process session error processing. End the "cancel" process.

[1367] Further, FIG. 141 shows a processing flow of the service director process in the processing of cancellation.

[1368] The service director process receives a cancellation request 6205 and a cancellation request 6213 from the service manager process, or a cancellation request 6205 from the merchant process, or a cancellation request 6213 from the user process. Is received, the "cancel" process is started in the three cases.

[1369] If a cancellation request 6205 is received from the merchant process, the service director process waits for the cancellation request 6213 to be received from the user process in step 11016 and receives the cancellation request 6213 from the user process. Proceed to step 11000.

[1370] Further, when the cancellation request 6213 is received from the user process, the service director process waits for the cancellation request 6205 to be received from the merchant process in step 11017, and receives the cancellation request 6205 from the merchant process. Then, the process proceeds to step 11000.

[1371] When the cancellation request 6205 and the cancellation request 6213 are received from the service manager process, the service director process proceeds to step 11000 as it is and checks the validity of the cancellation request 6205 and the cancellation request 6213. In the validity check of cancellation request 6205 and cancellation request 6213 in step 11000, the service director process matches the payment completion notification 5937 of cancellation request 6205 with the data on the merchant information server and the receipt of cancellation request 6213 6016. Matching the data with the data on the user information server, matching the payment number of the payment completion notification 5937 of the cancellation request 6205 with the payment number of the receipt 6016 of the cancellation request 6213, and the validity period of the cancellation request 6205 and the cancellation request 6213. Only when the data verification of the payment completion notification 5937 and the receipt 6016 match, the payment number matches, and the verification of the validity period is passed, the validity check of the cancellation request and the payment request is performed. It is determined that the data has passed, and in other cases, it is determined to be a fail.

[1372] If the validity check of the cancellation request and the payment request fails, the service director process performs the service director process session error processing in step 11013 and ends the "cancellation" processing.

[1373] If the cancellation request and payment request validity check are passed, the service director process sends a member process request to the service manager process in step 1101, and the member process of the same process group. As a result, the payment processing institution process corresponding to the payment processing institution that performed the credit settlement processing of the transaction to be canceled is requested, and in step 11002, the requested payment processing institution process is waited to become a member process.

When the requested payment processing institution process becomes a member process, the service director process accesses the information on the payment processing institution information server corresponding to the payment processing institution in step 11003 and generates a cancellation request 6221. Then, in step 11004, the generated cancellation request 6221 is sent to the settlement processing institution process.

[1375] The service director process that has sent the cancellation request 6221 waits in step 11005 and step 11014 to receive the cancellation completion notification 6232 from the payment processing institution process. In step 11005, the reception of the cancellation completion notification 6232 is determined, and in step 11014, the timeout is determined.

[1376] In the timeout determination in step 11014, if the cancellation completion notification 6232 is not received for the timeout time TTPCC (TTPCC&gt; 0) or longer, the service director process times out, and in step 11015, the service director process. Performs timeout error processing and ends the "cancel" process.

[1377] When the cancellation completion notification 6232 is received from the payment processing institution process, the service director process generates a cancellation completion notification 6241 to the merchant from the cancellation completion notification 6232 and the cancellation request 6205 in step 11006, and steps. In 11007, the cancellation request 6213 and the cancellation completion notification 6232 generate a cancellation processing receipt 6250 for the user, and in step 11008, the generated cancellation completion notification 6241 is sent to the merchant process, and in step 11009, it is generated. The canceled processing receipt 6250 is sent to the user process, and in step 11010, the service provision history of credit settlement cancellation is added to the service provision history list 4303 to update the service provision history list 4303.

[1378] In step 11011, the service director process that has updated the service provision history list 4303 waits for the merchant process and the user process to complete the cancel process, and the merchant process and the user process , When the process of "cancel" is completed, in step 11012, the process deletion request of the service director process itself is sent to the service manager process, and the process of "cancel" is completed. By sending the process erase request in step 11012, the service director process is erased by the service manager process.

[1379] Next, the processing flow in the processing of the "customer service call" will be described. FIG. 142 shows the processing flow of the credit card payment terminal in the processing of the customer service call. The processing of the "customer service call" is started by the credit card payment terminal 300 generating the customer service call process when the merchant performs the customer service call operation.

[1380] The credit settlement terminal first displays "connection processing in progress" on the LCD in step 11100, generates a customer service call request 6300 in step 11101, and establishes a session from the terminal status in step 11102. It is determined whether or not it is in the state, and if it is in the session established state, the generated customer service call request 6300 is sent to the merchant process in step 11104, and if it is not in the session established state, the session establishment process is performed in step 11103. After establishing a session with the service delivery system, proceed to step 11104.

[1381] The credit card settlement terminal that has sent the customer service call request 6300 waits in step 11105 and step 11113 to receive the customer service call answer 6302 from the merchant process. In step 11105, the reception of the customer service call answer 6302 is determined, and in step 11113, the timeout is determined.

[1382] In the timeout determination in step 11113, if the customer service call answer 6302 is not received for the timeout time TCSCR (TCSCR&gt; 0) or more, the credit settlement terminal times out and the merchant timeout error occurs in step 11114. Performs processing and ends processing of "customer service call".

[1383] When the customer service call answer 6302 is received, the credit settlement terminal decrypts the received customer service call answer 6302 with the merchant's private key in step 11106, and checks the merchant validity in step 11107. Perform and verify the validity of the received message.

[1384] If the merchant validity check is passed, the credit card payment terminal proceeds to step 11108, and if the merchant validity check fails, the credit card payment terminal is in step 11115 to handle the merchant session error. To end the processing of the "customer service call".

[1385] The credit settlement terminal determines in step 11108 whether the answer message of the customer service call answer is callable or not, and if the call is possible, in step 11109, "calling" is displayed on the LCD. Display and wait for the call answer 6304 to be received from the merchant process in step 11110, and if the call is not possible, in step 11116 display an error message on the LCD indicating that the user could not be accessed. Then, the processing of the "customer service call" is terminated.

Upon receiving the call answer 6304 from the merchant process, the credit settlement terminal decrypts the received call answer 6304 with the merchant's private key in step 11111 and in a call on the LCD in step 11112. Is displayed and the voice call state is entered. At this time, if the voice data encryption key 6439 is set in the call answer 6304, the credit settlement terminal sets the voice data encryption key 6439 in the voice data encryption key register (CRYPT) 22611 to input the voice data. Make a voice call with encryption.

[1387] FIG. 143 also shows the processing flow of the merchant process in the processing of the customer service call.

[1388] In the merchant process, processing of a "customer service call" is initiated by receiving a customer service call request 6300 from a credit card payment terminal. The merchant process first decrypts the received customer service call request 6300 with the service provider's private key in step 11200, performs a merchant process validity check in step 11201, and validates the customer service call request 6300. Verify sex.

[1389] If the merchant process validity check is passed, the merchant process determines in step 11202 whether or not it belongs to the process group from the value of the service director process ID in the merchant process management information, and processes. If it belongs to a group (service director process ID 0), step 11212 sends a decrypted customer service call request 6300 to the service director process and does not belong to the process group (service director process ID 0). In step 11203, the service director process ID = 0) sends the decrypted customer service call request 6300 to the service manager process.

[1390] If you fail to merchant process validity check, the merchant process, it is determined that the received message is not valid, in step 11211, the merchant process set performs Deployment error processing, "customer service call" Ends the processing of.

[1391] The merchant process that has sent the customer service call request 6406 to the service director process or the service manager process waits to receive the customer service call answer 6426 from the service director process in step 11204.

Upon receiving the customer service call answer 6426 from the service director process, the merchant process seals the customer service call answer 6426 to the merchant in step 11205 and the customer service call answer 6302 in step 11206. Send to the credit payment terminal.

[1393] Then, in step 11207, the answer message of the customer service call answer determines whether the call is possible or not, and if the call is possible, in step 11208, the service director process calls the call answer 6440. It waits for reception, and if the call is not possible, the process of "customer service call" is terminated as it is.

Upon receiving the call answer 6440 from the service director process, the merchant process seals the call answer 6440 to the merchant in step 11209 and sends the call answer 6304 to the credit settlement terminal in step 11210. Then, the process shifts to a voice call state in which digital voice data communication is performed.

[1395] Further, FIG. 144 shows a processing flow of the personal credit terminal in the processing of the customer service call. The processing of the "customer service call" is initiated by the personal credit terminal generating the customer service call process upon receiving the customer service call 6301 from the service providing system.

The personal credit terminal first decrypts the received customer service call 6301 with the user's private key in step 11300, performs a user validity check in step 11301, and validates the customer service call 6301. Verify sex.

[1397] If the user validity check is passed, the personal credit terminal outputs a ringtone from the speaker in step 11302, displays an incoming customer service call on the LCD, and in step 11303, the user. Wait for the call operation.

[1398] If the user validity check fails, the personal credit terminal performs user session error processing in step 11307 and ends the processing of the "customer service call".

[1399] When the user performs a call operation, the personal credit terminal generates an incoming call answering 6303 in step 11304, sends the generated incoming call answering 6303 in step 11305 to the user process, and further in step 11306. , "In a call" is displayed on the LCD to shift to the voice call state.

[1400] When the voice data is encrypted to make a voice call, the personal credit terminal generates the voice data encryption key 6432 to generate the incoming call answering 6303 when the incoming call answering 6303 is generated in step 11304. The voice data encryption key 6432 is set in the voice data encryption key register (CRYPT) 21613 to encrypt and decrypt the voice data.

[1401] Further, FIG. 145 shows a processing flow of a user process in processing a customer service call.

[1402] In the user process, the processing of the "customer service call" is initiated by receiving the customer service call 6417 from the service director process. The user process first seals the received customer service call 6417 to the user in step 11400, and then determines from the user status whether or not the session is established in step 11401, and the session is in the established state. If so, the customer service call 6301 is sent to the personal credit terminal in step 11403, and if the session is not established, the session establishment process is performed in step 11402 to establish a session with the personal credit terminal. From, proceed to step 11403.

[1403] The user process that sent the customer service call 6301 waits to receive an incoming call answering 6303 from the personal credit terminal in step 11404, and when it receives an incoming call answering 6303, in step 11405, the service provider's private. The key decrypts the received incoming call answering 6303 encryption, and in step 11406, the decrypted incoming call answering is transmitted to the service director process to shift to a voice call state in which digital voice data communication is performed.

[1404] Further, FIG. 146 shows a processing flow of the service director process in the processing of the customer service call.

[1405] In the service director process, when the customer service call request 6406 is received from the service manager process, or when the customer service call request 6406 is received from the merchant process, the processing of the "customer service call" is performed. Start.

The service director process first refers to the merchant's customer table in step 11500 to identify the user ID that corresponds to customer number 6401 in the customer service call request, and then in step 11501 the service director process. A member process request is sent to the manager process to request the user process corresponding to the user making the customer service call as a member process of the same process group, and in steps 11502 and 11512, the requested user process is Wait for it to become a member process. In step 11502, it is determined whether or not the requested user process has become a member process, and in step 11512, a timeout is determined.

[1407] In the timeout determination in step 11512, if the requested user process does not become a member process for a timeout period of TUPMP (TUPMP&gt; 0) or longer, the service director process times out and in step 11513, response message 6422. Generates a customer service call answer 6426 indicating that the call is not possible and sends the generated customer service call answer 6426 to the merchant process in step 11514, and in step 11515 the merchant process processes the customer service call. Wait for it to finish. When the merchant process finishes processing the "customer service call", the service director process sends a process deletion request for the service director process itself to the service manager process in step 11516 to process the "customer service call". To finish. By sending the process erase request in step 11516, the service director process is erased by the service manager process.

[1408] When the requested user process becomes a member process, the service director process refers to the user's access control information 24005 in step 11503 to determine whether or not the user can be accessed.

[1409] If the user is accessible at the determination of step 11503, the service director process generates a customer service call 6417 in step 11504 and sends the generated customer service call 6417 to the user process in step 11505. Further, in step 11506, the answer message 6422 generates a customer service call answer 6426 indicating that the call is available, and in step 11507 it sends the generated customer service call answer 6426 to the merchant process.

[1410] If the user cannot be accessed by the determination in step 11503, the service director process proceeds to step 11513 and performs the processes from step 11513 to step 11516.

[1411] The service director process that has sent the customer service call answer 6426 waits for the incoming answer 6433 to be received from the user process in steps 11508 and 11517. In step 11508, the reception of the incoming call response 6433 is determined, and in step 11517, the timeout is determined.

[1412] In the timeout determination in step 11515, if the incoming response 6433 is not received for the timeout time TARU (TARU&gt; 0) or longer, the service director process times out, and in step 11518, the service director process timeout. -Perform error processing and end the processing of "customer service call".

[1413] If an incoming call answer 6433 is received from the user process, the service director process generates a call answer 6440 from the incoming call answer 6433 in step 11509 and merchants the generated call answer 6440 in step 11510. Send to the process, and in step 11511, add the service provision history of the customer service call to the service provision history list 4303, update the service provision history list 4303, and enter the voice call state for digital voice data communication. Transition.

[1414] Next, the processing flow in the processing of the "inquiry call" will be described.

[1415] FIG. 147 shows a processing flow of a personal credit terminal in processing an inquiry call. The processing of the "inquiry call" is started by the personal credit terminal 100 generating an inquiry call process when the user performs an inquiry call operation.

[1416] The personal credit terminal first displays "connection processing in progress" on the LCD in step 11600, generates an inquiry call request 6306 in step 11601, and establishes a session from the terminal status in step 11602. It is determined whether or not it is in the state, and if it is in the session establishment state, the generated inquiry call request 6306 is sent to the user process in step 11604, and if it is not in the session establishment state, the session establishment process is performed in step 11603. After establishing a session with the service providing system, proceed to step 11604.

[1417] The personal credit terminal that has sent the inquiry call request 6306 waits in step 11605 and step 11613 to receive the inquiry call answer 6308 from the user process. In step 11605, the reception of the inquiry call answer 6308 is determined, and in step 11613, the timeout is determined.

[1418] In the timeout determination in step 11613, if the inquiry call answer 6308 is not received for the timeout time TICR (TICR&gt; 0) or longer, the personal credit terminal times out and the user timeout error occurs in step 11614. Performs processing and ends the processing of "inquiry call".

[1419] When the inquiry call answer 6308 is received, the personal credit terminal decrypts the received inquiry call answer 6308 with the user's private key in step 11606, and performs a user validity check in step 11607. , Verify the validity of the received message.

[1420] If the user validity check is passed, the personal credit terminal goes to step 11608, and if the user validity check fails, the personal credit terminal goes to step 11615 for the user session. Performs error processing and ends the processing of "inquiry call".

[1421] The personal credit terminal determines in step 11608 whether the answer message of the inquiry call answer is a call possible or not, and if the call is possible, in step 11609, "calling" is displayed on the LCD. Display and wait for the user process to receive the call answer 6310 in step 11610, and if the call is not possible, in step 11616 display an error message on the LCD indicating that the merchant could not be accessed. Then, the processing of the "inquiry call" is terminated.

Upon receiving the call answer 6310 from the user process, the personal credit terminal decrypts the received call answer 6310 with the user's private key in step 11611 and tells the LCD in step 11612 that "in a call". Is displayed and the voice call state is entered. At this time, if the voice data encryption key 6537 is set in the call answer 6310, the personal credit terminal sets the voice data encryption key 6537 in the voice data encryption key register (CRYPT) 21613 and voice data. Encrypt and make a voice call.

[1423] Further, FIG. 148 shows a processing flow of the user process in the processing of the inquiry call.

[1424] In the user process, the processing of the "inquiry call" is initiated by receiving the inquiry call request 6306 from the personal credit terminal. The user process first decrypts the received inquiry call request 6306 with the service provider's private key in step 11700, and performs a user process validity check in step 11701 to verify the validity of the inquiry call request 6306. Verify.

[1425] If the user process validity check is passed, the user process determines in step 11702 from the value of the service director process ID of the user process management information whether or not it belongs to the process group, and processes. If it belongs to a group (service director process ID 0), step 11712 sends the decrypted query call request 6306 to the service director process and does not belong to the process group (service). -For the director process ID = 0), the inquiry call request 6306 whose encryption has been decrypted is sent to the service manager process in step 11703.

[1426] If the user process validity check fails, the user process determines that the received message is not valid, performs user process session error processing in step 11711, and processes the "inquiry call". To finish.

[1427] The user process that has sent the inquiry call request 6506 to the service director process or the service manager process waits for the inquiry call answer 6524 to be received from the service director process in step 11704.

Upon receiving the inquiry call answer 6524 from the service director process, the user process seals the inquiry call answer 6524 to the user in step 11705 and sends the inquiry call answer 6308 to the personal credit terminal in step 11706. Send to. Then, in step 11707, it is determined whether the answer message of the inquiry call answer is call possible or not, and if the call is possible, in step 11708, the call answer 6538 is received from the service director process. If it is not possible to wait or make a call, the process of "inquiry call" is terminated as it is.

Upon receiving the call answer 6538 from the service director process, the user process seals the call answer 6538 to the user in step 11709 and sends the call answer 6310 to the personal credit terminal in step 11710. Then, the process shifts to a voice call state in which digital voice data communication is performed.

[1430] Further, FIG. 149 shows a processing flow of the credit card payment terminal in the processing of the inquiry call. The processing of the "inquiry call" is started by the credit card settlement terminal generating the inquiry call process when the inquiry call 6307 is received from the service providing system.

[1431] The credit card payment terminal first decrypts the received inquiry call 6307 with the merchant's private key in step 11800, and in step 11801, checks the merchant validity and verifies the validity of the inquiry call 6307. To do.

[1432] If the merchant validity check is passed, the credit card payment terminal outputs a ringtone from the speaker in step 11802, displays the incoming inquiry call on the LCD, and in step 11803, the merchant's call. Wait for the operation.

[1433] If the merchant validity check fails, the credit card payment terminal performs the merchant session error processing and ends the processing of the "inquiry call" in step 11807.

[1434] When the merchant performs a call operation, the credit settlement terminal generates an incoming call answering 6309 in step 11804, sends the generated incoming call answering 6309 in step 11805 to the merchant process, and further, in step 11806, "In a call" is displayed on the LCD to shift to the voice call state.

[1435] When making a voice call by encrypting voice data, when generating the incoming call answering 6309 in step 11804, the credit settlement terminal generates the voice data encryption key 6530 and sets it to the incoming call answering 6309. Then, the generated voice data encryption key 6530 is set in the voice data encryption key register (CRYPT) 22611 to encrypt and decrypt the voice data.

[1436] FIG. 150 also shows the processing flow of the merchant process in the processing of the inquiry call.

[1437] In the merchant process, the processing of the "inquiry call" is initiated by receiving the inquiry call 6515 from the service director process. The merchant process first seals the incoming inquiry call 6515 received in step 11900 to the merchant, and then in step 11901 determines from the merchant status whether the session is in the established state or not, and in the case of the session established state. In step 11903, the inquiry call 6307 is sent to the credit card payment terminal, and if the session is not established, the session establishment process is performed in step 11902 to establish a session with the credit card payment terminal, and then step 11903. Proceed to.

[1438] The merchant process that sent the inquiry call 6307 waits to receive the incoming call answering 6309 from the credit card payment terminal in step 11904, and when it receives the incoming call answering 6309, in step 11905, with the service provider's private key. , The received incoming call answer 6309 is decrypted, and in step 11906, the decrypted incoming call answer is transmitted to the service director process to shift to the voice call state in which digital voice data communication is performed.

[1439] Further, FIG. 151 shows a processing flow of the service director process in the processing of the inquiry call.

[1440] The service director process starts processing the "inquiry call" when it receives the inquiry call request 6506 from the service manager process or when it receives the inquiry call request 6506 from the user process.

[1441] The service director process first sends a member process request to the service manager process in step 12000 to request the merchant process corresponding to the merchant making the query call as a member process of the same process group. Then, in step 12001 and step 12010, wait for the requested merchant process to become a member process. In step 12001, it is determined whether or not the requested merchant process has become a member process, and in step 12010, a timeout is determined.

[1442] In the timeout determination in step 12010, if the requested merchant process does not become a member process for a timeout period of TMPMP (TMPMP&gt; 0) or longer, the service director process times out and in step 12011, response message 6422. Generates a customer service call answer 6426 indicating that the call is not possible, sends the generated inquiry call answer 6524 to the user process in step 11512, and the user process finishes processing the "inquiry call call" in step 12513. Wait to do. When the user process finishes processing the "inquiry call", the service director process sends a process clear request for the service director process itself to the service manager process in step 12014 to finish processing the "inquiry call". To do. By sending the process clearing request in step 12014, the service director process is cleared by the service manager process.

[1443] If the requested merchant process becomes a member process, the service director process generates a query call 6515 in step 12002, sends the generated query call 6515 to the merchant process in step 12003, and further In step 12004, the answer message 6422 generates an inquiry call answer 6524 indicating that the call is possible, and in step 12005, the generated inquiry call answer 6524 is sent to the user process.

[1444] The service director process that sent the inquiry call answer 6524 waits for the incoming call answer 6531 to be received from the merchant process in step 12006 and step 12015. In step 12006, the reception of the incoming call response 6531 is determined, and in step 12015, the timeout is determined.

[1445] In the timeout determination in step 12015, if the incoming response 6531 is not received for the timeout time TARM (TARM&gt; 0) or longer, the service director process times out, and in step 12016, the service director process timeout. -Perform error processing and end the processing of "inquiry call".

[1446] When an incoming call answer 6531 is received from the merchant process, the service director process generates a call answer 6538 from the incoming call answer 6531 in step 12007 and the generated call answer 6538 in step 12008 to the user. Send to the process, and in step 12009, add the service provision history of the inquiry call to the service provision history list 4303, update the service provision history list 4303, and shift to the voice call state for digital voice data communication. To do.

[1447] Next, an operation when the user uses the personal remote credit payment service in the user's home service area or a service area other than the home service area will be described.

[1448] FIG. 152 (a) shows an operation when a user performs a "payment" process or a "cancel" process in a merchant having the same home service area and a home service area.

[1449] In this case, the personal credit terminal 100 and the credit payment terminal 300 communicate with the service providing system 102 in the home service area (service area 1 12100) to process "payment" or "cancel". "Is performed.

[1450] In the service providing system 102, the service manager process 23800 generates the user process 23802, the merchant process 23803, the service director process 23801, and the payment processing institution process 23804 on the service server of the service providing system 102. Then, the generated service director process 23801, the user process 23802, the merchant process 23803, and the payment processing institution process 23804 cooperate to perform "payment" processing or "cancellation" processing.

[1451] Further, FIG. 152 (b) shows an operation when the user performs "payment" processing or "cancellation" processing in the merchant's home service area and the merchant whose home service area is different. ing.

[1452] In this case, the personal credit terminal 100 and the credit payment terminal 300 communicate with the service providing system 102 of the merchant's home service area (service area 1 12100) to process "payment" or perform "payment". Performs "cancel" processing.

[1453] In the service providing system 102, the service manager process 23800 performs the mobile user process 12105, the merchant process 23803, the service director process 23801, and the payment processing institution process 23804 on the service server of the service providing system 102. On the other hand, in the service providing system 12102 of the user's home service area (service area 2 12101), the service manager process 12103 generates and generates the home user process 12104 on the service server of the service providing system 12102. The service director process 23801, the home user process 12104, the mobile user process 12105, the merchant process 23803, and the payment processing institution process 23804 cooperate to perform "payment" processing or "cancellation" processing. Do it.

[1454] The home user process 12104 sends a message to the service manager process 12103 requesting the creation of the corresponding home user process when the service manager process 23800 spawns the mobile user process 12105. If the home user process 12104 could not be spawned (eg, the user process corresponding to the user had already been spawned), the mobile user process 12105 would not be spawned.

[1455] Further, FIG. 153 (a) shows an operation when the user and the merchant perform a cancel process in the respective home service areas when the home service areas of the user and the merchant are different. ..

[1456] In this case, the personal credit terminal 100 communicates with the service providing system 12202 of the user's home service area (service area 2 12201), and the credit payment terminal 300 is the merchant's home service area (service area 1 12200). ) Communicates with the service providing system 102 to perform "cancellation" processing.

[1457] In the service providing system 12202, the service manager process 12203 generates a user process 23802 on the service server of the service providing system 12202, while in the service providing system 102, the service manager process 23800 provides the service. On the service server of the system 102, the merchant process 23803, the service director process 23801, and the payment processing institution process 23804 are generated, and the generated service director process 23801, the user process 23802, the merchant process 23803, and the payment are made. In cooperation with the processing institution process 23804, "cancel" processing is performed.

Cancellation request 6213 sent from user process 23802 to service manager process 12203 is sent by service manager process 12203 to service manager process 23800 and from merchant process 23803 to service manager process 23800. A process group is created by the service director process 23801, the user process 23802, the merchant process 23803, and the settlement processing institution process 23804, which is matched against the cancellation request 6205.

[1459] Further, FIG. 153 (b) shows an operation when the user performs a cancel process from a place other than the user or the merchant's home service area when the user and the merchant's home service area are different. Shown.

[1460] In this case, the personal credit terminal 100 communicates with the service providing system 12206 of the nearest service area (service area 2 12204), and the credit payment terminal 300 is the merchant's home service area (service area 1 12200). Communicates with the service providing system 102 of the above and performs "cancellation" processing.

[1461] In the service providing system 12206, the service manager process 12208 generates a mobile user process 12211 on the service server of the service providing system 12206, while providing the service in the user's home service area (service area 3 12205). In system 12207, service manager process 12209 spawns a home user process 12210 on the service server of service delivery system 12207, and in service delivery system 102, service manager process 23800 is a service of service delivery system 102. On the server, the merchant process 23803, the service director process 23801, and the payment processing institution process 23804 are generated, and the generated service director process 23801, the home user process 12210, the mobile user process 12211, and the merchant process 23803 are generated. And the settlement processing institution process 23804 cooperate with each other to perform "cancellation" processing.

[1462] When the service manager process 12208 generates the mobile user process 12211, the home user process 12210 sends a message to the service manager process 12209 requesting the creation of the home user process corresponding to the user. If the home user process 12210 cannot be spawned (eg, the user process corresponding to the user has already been spawned), the mobile user process 12211 will not be spawned.

Cancellation request 6213 sent from mobile user process 12211 to service manager process 12208 is sent by service manager process 12208 to service manager process 23800 and from merchant process 23803 to service manager process 23800. A process group is generated by the service director process 23801, the mobile user process 12211, the merchant process 23803, and the payment processing institution process 23804, which is matched with the cancellation request 6205.

[1464] Further, FIG. 154 (a) shows an operation when processing a customer service call or processing an inquiry call between a user and a merchant having the same home service area. ..

[1465] In this case, the personal credit terminal 100 and the credit payment terminal 300 communicate with the service providing system 102 in the home service area (service area 1 12300) to process a "customer service call" or process a "customer service call". Process "inquiry call".

[1466] In the service providing system 102, the service manager process 2900 generates the user process 23802, the merchant process 23803, and the service director process 2901 on the service server of the service providing system 102, and the generated service director. Process 2901, user process 23802, and merchant process 23803 cooperate to process "customer service call" or "inquiry call".

[1467] Further, FIG. 154 (b) shows an operation when the merchant processes a customer service call with a user having a different home service area. In this case, the personal credit terminal 100 communicates with the service providing system 12302 of the user's home service area (service area 2 12301), and the credit payment terminal 300 is the service of the merchant's home service area (service area 1 12300). Communicates with the providing system 102 to process a "customer service call".

[1468] In the service providing system 102, the service manager process 23800 generates a merchant process 23803 and a service director process 23801 on the service server of the service providing system 102, while in the service providing system 12302, the service is generated. The manager process 12303 generates the user process 23802 on the service server of the service providing system 12302, and the generated service director process 23801, the user process 23802, and the merchant process 23803 cooperate with each other to perform a customer service call. "Is performed.

[1469] In the user process 23802 of the service providing system 12302 in the user's home service area, the service manager process 23800 that receives the member process request from the service director process 23801 responds to the user with respect to the service manager process 12303. Generated by sending a message requesting the creation of a user process.

[1470] Further, FIG. 155 (a) shows an operation when the user processes an "inquiry call" from the user's home service area to a merchant whose home service area is different.

[1471] In this case, the personal credit terminal 100 communicates with the service providing system 12402 of the user's home service area (service area 2 12401), and the credit payment terminal 300 is the merchant's home service area (service area 1 12400). ) Communicates with the service providing system 102 to process the "inquiry call".

[1472] In the service providing system 12402, the service manager process 12403 generates a user process 23802 on the service server of the service providing system 12402, while in the service providing system 102, the service manager process 23800 provides the service. On the service server of system 102, the merchant process 23803 and the service director process 23801 are generated, and the generated service director process 23801, the user process 23802, and the merchant process 23803 cooperate with each other to make an "inquiry call". Is processed.

Inquiry call request 6506 sent from user process 23802 to service manager process 12203 is sent by service manager process 12203 to service manager process 23800 to service director process 23801, user process 23802, and merchant. A process group is created by process 23803.

[1474] Further, FIG. 155 (b) shows an operation when a user processes an "inquiry call" from a service area other than the home service area of the user or the merchant to a merchant having a different home service area. Shown.

[1475] In this case, the personal credit terminal 100 communicates with the service providing system 12406 in the nearest service area (service area 2 12404), and the credit payment terminal 300 is the merchant's home service area (service area 1 12400). Communicates with the service providing system 102 of the above and processes an "inquiry call".

[1476] In the service providing system 12406, the service manager process 12408 generates a mobile user process 12411 on the service server of the service providing system 12406, while providing the service in the user's home service area (service area 3 12405). In system 12407, service manager process 12409 spawns a home user process 12410 on the service server of service delivery system 12407, and in service delivery system 102, service manager process 23800 is a service of service delivery system 102. On the server, the merchant process 23803 and the service director process 23801 are generated, and the generated service director process 23801, the home user process 12410, the mobile user process 12411, and the merchant process 23803 cooperate with each other to obtain "" Inquiry call "is processed.

[1477] The home user process 12410 sends a message to the service manager process 12409 requesting the creation of the corresponding home user process when the service manager process 12408 spawns the mobile user process 12411. If the home user process 12410 cannot be spawned (eg, the user process corresponding to the user has already been spawned), the mobile user process 12411 will not be spawned.

Inquiry call request 6506 sent from mobile user process 12411 to service manager process 12408 is sent by service manager process 12408 to service manager process 23800 to service director process 23801 and mobile user process 12411. , A process group is created by the merchant process 23803.

[1479] As described above, the personal remote credit payment service is provided by operating the personal credit terminal 100, the credit payment device 101, the service providing system 102, and the payment system 103. The user can receive the same personal remote credit payment service in any area where the personal remote credit payment service is provided.

[1480] In the personal credit terminal 100, instead of the ROM 1501 and the EEPROM 1503, a ferroelectric non-volatile memory is used as a memory device for storing a program executed by the CPU 1500 and a public key of a service provider. You may. Like EEPROM and flash memory, strong dielectric non-volatile memory can hold data without a battery while being writable, and has a faster read / write speed than EEPROM and flash memory. It is a memory device with the characteristics of low power consumption.

[1481] When a ferroelectric non-volatile memory is used instead of the ROM 1501 and the EEPROM 1503, for example, by the same processing as the data update processing, the program of the personal credit terminal 100 is significantly upgraded or regularly. There is an advantage that the public key of a service provider can be updated in a relatively short time and without significantly impairing the life of the battery.

[1482] Further, a ferroelectric non-volatile memory may be used as the RAM 1502 for storing the data processed by the CPU 1500 and the data processed by the CPU 1500. In this case, even if the battery runs out, the data is retained, so there is no need to perform data backup processing, and there is no need for a power supply to retain RAM data, so the power consumption of the personal credit terminal is suppressed. There is an advantage that it can be done.

[1483] In the above description, the personal credit terminal 100 and the credit payment device 101 constituting the personal remote credit payment system are used to realize their respective functions in the personal remote credit payment service. It has the best hardware configuration, but features include a computer with wireless phone communication (or phone communication), infrared communication, display, keyboard (or pen input device), microphone, and speaker. It can also be configured.

[1484] In this case, among the internal hardware of the personal credit terminal 100 or the credit payment device 101, the hardware that the computer does not have the functionally compatible hardware (eg, data codec, cryptographic processing processor). , Control logic part, etc.), the function is converted into a software program, and it is converted into a software program that runs on the OS (Operating System) of the personal computer together with the program stored in ROM1501 (22501). Store the software program in a location that can be run from your computer (for example, a hard disk).

[Effect of the Invention] As is clear from the above description, in the personal electronic payment system of the present invention, each of the payment means, the billing means, and the payment means (or service providing means) has a plurality of communication means. Since communication between the possession, payment means, billing means, and payment means (or service providing means) is performed using different communication means, it is possible to prevent fraudulent billing and leakage of personal information by the billing means. In addition, information necessary for payment can be exchanged quickly by communication means, so that sales efficiency can be improved.

[1486] Further, a wireless communication means using light such as infrared light is used between the payment means and the billing means, and a radio wireless communication means is used between the payment means and the payment means (or a service providing means). As a result, it is possible to take a system form suitable for the usage environment.

[1487] Further, the billing means sends a payment request message to the payment means, the payment means sends a payment offer message to the billing means, and the billing means and the payment means include information obtained from these received messages. A payment request or payment request message is generated and sent to the payment means (or service provider), and the payment means (or service provider) collates these request messages to make a fraudulent claim or payment of the billing means. It is possible to prevent the payment of means from being deceived. In addition, payment can be received without the billing means knowing the identification number of the payment means or the telephone number of the owner of the payment means.

[1488] Further, since one payment method can select a payment method from a plurality of payment methods, it is not necessary to carry many credit cards.

[1489] Further, by appropriately transferring the data held by the payment means and the billing means to the storage means of the payment means (or service providing means), the data can be backed up, and the payment means and the billing means can be backed up. It is possible to reduce the size.

[1490] Further, by updating the data held by the payment means and the billing means, the consistency between the data stored in the payment means and the data stored in the payment means (or service providing means) can be improved. It can be maintained and the reliability of the system is improved. Further, by accumulating recent data in the payment means and the billing means and updating the data, the access time of the payment means and the billing means can be shortened.

[1491] Further, in the update process, falsification of data accumulated in the payment means or the billing means can be found, and fraud can be prevented.

[1492] In addition, in this system, cancellation of payment can be easily executed. In addition, the person in charge of the billing means can contact the owner of the payment means that made the payment without knowing the telephone number. Similarly, the owner of the payment instrument can also contact the person in charge of the billing instrument without giving the telephone number. Therefore, it is possible to carry out smooth business transactions while protecting the privacy of the owner of the payment means.

BRIEF DESCRIPTION OF THE DRAWINGS [Fig. 1] Block configuration diagram of a personal electronic payment system according to the first and second embodiments of the present invention, [Fig. 2] Fig. 2 according to the first and second embodiments of the present invention. Overview of personal credit terminals, [Fig. 3] Overview of credit payment terminals in the first and second embodiments of the present invention, [Fig. 4] Services in the first and second embodiments of the present invention. Block configuration diagram of the provided system, [Fig. 5] Block configuration diagram of the payment system according to the first and second embodiments of the present invention, [Fig. 6] Processing of "payment" according to the first embodiment of the present invention. Flow diagram, [Fig. 7] Schematic diagrams (a) to (h) of the screen displayed on the LCD of the personal credit terminal during the processing of "payment" in the first embodiment of the present invention. 8] Schematic diagrams (a) to (g) of the screen displayed on the LCD of the credit payment terminal during the processing of "payment" in the first embodiment of the present invention, [Fig. 9] "Cancellation" processing flow diagram in the first and second embodiments, [Fig. 10] Displayed on the LCD of the personal credit terminal during the "cancellation" processing in the first and second embodiments of the present invention. Schematic diagrams (a) to (e) of the screens to be displayed, [Fig. 11] Screens displayed on the LCD of the credit settlement terminal during the "cancellation" process in the first and second embodiments of the present invention. Diagrams (a) to (g), (Fig. 12) (a) Processing flow diagram of "customer service call" in the first embodiment of the present invention, (b) First embodiment of the present invention. The processing flow diagram of the "inquiry call" in the embodiment, FIG. 13 is a screen displayed on the LCD of the personal credit terminal during the processing of the "customer service call" in the first and second embodiments of the present invention. The schematic diagram (a), the schematic diagram (b) of the screen displayed on the LCD of the personal credit terminal during the processing of the customer service call and the processing of the inquiry call, and the inquiry call. Diagrams (c) to (i) of the screen displayed on the LCD of the personal credit terminal during the process of "FIG. 14", [Fig. 14] In the first and second embodiments of the present invention.Schematic diagrams (a) to (e) and (g) of the screen displayed on the LCD of the credit settlement terminal when processing the "customer service call", and the processing of the "customer service call" and the "inquiry call" Schematic diagram (f) of the screen displayed on the LCD of the credit settlement terminal during the processing of, and the schematic diagram (h) of the screen displayed on the LCD of the credit settlement terminal during the processing of the "inquiry call". ), [Fig. 15] (a) Block configuration diagram of the personal credit terminal according to the first and second embodiments of the present invention, (b) Personal credit according to the first and second embodiments of the present invention. Block configuration diagram of infrared communication module of terminal, FIG. 16 is a schematic diagram of a RAM map of a personal credit terminal according to the first embodiment of the present invention, FIG. 17 is a schematic diagram of a RAM map of the first embodiment of the present invention. Schematic diagram of the data stored in the service data area of the personal credit terminal, FIG. 18 (a) Configuration diagram of the internal register of the personal credit terminal according to the first embodiment of the present invention, (b) Bitfield configuration diagram of INT register of personal credit terminal according to the first embodiment of the present invention, (c) Bitfield configuration diagram of variable interrupt on RAM of personal credit terminal according to the first embodiment of the present invention. , FIG. 19 is a processing flow diagram performed by the CPU of the personal credit terminal according to the first embodiment of the present invention, [Fig. 20] (a) Flow of processing of a digital signature according to the first embodiment of the present invention. FIG., (B) explanatory diagram of the flow of digital signature processing in the first embodiment of the present invention, [Fig. 21] (a) flow diagram of message sealing processing in the first embodiment of the present invention, (b) Flow explanatory diagram of message sealing process according to the first embodiment of the present invention, FIG. 22 (a) Decoding process of sealed message according to the first embodiment of the present invention. Flow diagram, (b) Flow explanatory diagram of decoding processing of sealed message in the first embodiment of the present invention, [Fig. 23] (a) Digita in the first embodiment of the present invention.The flow diagram of the signature verification process, (b) the flow explanatory diagram of the digital signature verification process in the first embodiment of the present invention, [Fig. 24] (a) the credit in the first embodiment of the present invention. Block configuration diagram of payment terminal, (b) Block configuration diagram of infrared light receiving / emitting module of credit payment terminal according to the first embodiment of the present invention, [Fig. 25] Credit payment terminal according to the first embodiment of the present invention. FIG. 26 is a schematic diagram of the data stored in the service data area of the credit settlement terminal according to the first embodiment of the present invention, FIG. 27 (a) is a schematic diagram of the data stored in the service data area of the credit settlement terminal. The configuration diagram of the internal register of the credit settlement terminal according to the first embodiment, (b) the bit field configuration diagram of the INT register of the credit settlement terminal according to the first embodiment of the present invention, (c) the first embodiment of the present invention. Bit field configuration diagram of variable interrupt on RAM of credit payment terminal in the embodiment, FIG. 28 is a flow diagram of processing performed by the CPU of the credit payment terminal in the first embodiment of the present invention, FIG. 29. A schematic diagram of data stored for one user in the user information server of the service providing system according to the first embodiment of the present invention, FIG. 30. The service providing system according to the first embodiment of the present invention. A schematic diagram of data stored for one merchant in the merchant information server of the present invention, [Fig. 31] One payment process in the payment processing institution information server of the service providing system according to the first embodiment of the present invention. Schematic diagram of the data stored for the institution, FIG. 32. FIG. 32. Schematic diagram of the data stored in the service director information server of the service providing system according to the first embodiment of the present invention. a) Flow diagram of remote access processing according to the first embodiment of the present invention, (b) Flow diagram of data update processing according to the first embodiment of the present invention, FIG. 34 (a) First embodiment of the present invention. A schematic diagram of the data structure of the remote access request according to the first embodiment, (b) the data structure of the remote access data according to the first embodiment of the present invention.Schematic diagram of the structure, (c) Schematic diagram of the data structure of the data update request in the first embodiment of the present invention, (d) Data structure of the data update request response in the first embodiment of the present invention. (E) A schematic diagram of the data structure of the uploaded data in the first embodiment of the present invention, (f) A schematic diagram of the data structure of the update data in the first embodiment of the present invention. , [Fig. 35] (a) Schematic diagram of the data structure of the outage instruction in the first embodiment of the present invention, [Fig. 36] (a) Data of the payment offer in the first embodiment of the present invention. Schematic diagram of the structure, (b) Schematic diagram of the data structure of the payment offer response in the first embodiment of the present invention, (c) The data structure of the credit inquiry request in the first embodiment of the present invention. Schematic diagram, (d) Schematic diagram of the data structure of the payment request in the first embodiment of the present invention, (e) Schematic diagram of the data structure of the credit inquiry response in the first embodiment of the present invention. , (F) A schematic diagram of the data structure of the payment request transmitted from the credit payment terminal to the service providing system in the first embodiment of the present invention, [Fig. 37] (a) the first embodiment of the present invention. A schematic diagram of the data structure of the payment request transmitted from the service providing system in the form to the payment system, (b) Data of the payment completion notification transmitted from the payment system in the first embodiment of the present invention to the service providing system. Schematic diagram of the structure, (c) Schematic diagram of the data structure of the payment completion notification transmitted from the service providing system in the first embodiment of the present invention to the credit settlement terminal, [Fig. 38] (a) The present invention. A schematic diagram of the data structure of the receipt transmitted from the credit settlement terminal to the service providing system in the first embodiment of the present invention, (b) the personal credit terminal from the service providing system in the first embodiment of the present invention. Diagram of the data structure of the receipt transmitted to, [Fig. 39] (a) Model of the data structure of the cancellation request transmitted from the credit settlement terminal in the first embodiment of the present invention to the service providing system. Figure, (b) Par in the first embodiment of the present invention.Schematic diagram of the cancellation request data structure transmitted from the sonal credit terminal to the service providing system, (c) The cancellation request data structure transmitted from the service providing system to the payment system according to the first embodiment of the present invention. Schematic diagram of the data structure of the cancellation request transmitted from the service providing system to the payment system according to the embodiment of the above, (d) transmitted from the payment system according to the first embodiment of the present invention to the service providing system. A schematic diagram of the data structure of the cancellation completion notification, (e) a schematic diagram of the data structure of the cancellation completion notification transmitted from the service providing system according to the first embodiment of the present invention to the credit settlement terminal, (f). Schematic diagram of the data structure of the cancellation processing receipt according to the first embodiment of the present invention, FIG. 40 (a) Schematic diagram of the data structure of the customer service call request according to the first embodiment of the present invention. , (B) Schematic diagram of the data structure of the customer service call according to the first embodiment of the present invention, (c) Schematic diagram of the data structure of the customer service call request response according to the first embodiment of the present invention. , (D) A schematic diagram of the data structure of the incoming call response during the customer service call according to the first embodiment of the present invention, (e) The call during the customer service call according to the first embodiment of the present invention. Schematic diagram of the data structure of the response, FIG. 41 (a) Schematic diagram of the data structure of the inquiry call request in the first embodiment of the present invention, (b) Schematic diagram of the data structure of the inquiry call request in the first embodiment of the present invention. Schematic diagram of the data structure of the inquiry call, (c) Schematic diagram of the data structure of the inquiry call request response in the first embodiment of the present invention, (d) Inquiry call in the first embodiment of the present invention. (E) A schematic diagram of the data structure of the incoming call response in the case of an incoming call, (e) A schematic diagram of the data structure of the call response during the inquiry call in the first embodiment of the present invention, [Fig. 42] Block configuration diagram, FIG. 43 is a processing flow diagram of "payment" in the second embodiment of the present invention, and [Fig. 44] is displayed on the LCD of a personal credit terminal during the processing of the "payment".Schematic diagrams (a) to (h) of the screen to be displayed, (a) (a) Processing flow diagram of "customer service call" in the second embodiment of the present invention, (b) second aspect of the present invention. The processing flow diagram of the "inquiry call" in the embodiment of [Fig. 46].Configuration diagram of the internal register of the personal credit terminal according to the second embodiment of the present invention, FIG. 47 (a) Bitfield configuration diagram of the INT register of the personal credit terminal according to the second embodiment of the present invention. , (B) Bitfield configuration diagram of variable interrupt on RAM of personal credit terminal according to the second embodiment of the present invention, FIG. 48. RAM of personal credit terminal according to the second embodiment of the present invention. Schematic diagram of the map, [Fig. 49] Schematic diagram of data stored in the service data area of the personal credit terminal according to the second embodiment of the present invention, [Fig. 50] (a) Second embodiment of the present invention. The process list of the CPU of the personal credit terminal in the embodiment of the above, (b) the explanatory diagram for explaining the update of the process list by the process management process of the personal credit terminal in the second embodiment of the present invention. FIG. 51 is a conceptual diagram of the processing flow performed by the CPU of the personal credit terminal according to the second embodiment of the present invention, and FIG. 52 (a) shows the personal credit terminal and credit according to the second embodiment of the present invention. Conceptual diagram of processing flow at reset performed by CPU of payment terminal, (b) Conceptual diagram of processing flow at power-on performed by CPU of personal credit terminal and credit payment terminal in the second embodiment of the present invention, (c) ) A conceptual diagram of the processing flow at power-off performed by the CPU of the personal credit terminal and the credit settlement terminal in the second embodiment of the present invention, [Fig. 53] The personal credit terminal in the second embodiment of the present invention. Conceptual diagram of processing flow during steady operation performed by the CPU of the above, [Fig. 54] Conceptual diagram of processing flow during processing of "payment" performed by the CPU of the personal credit terminal in the second embodiment of the present invention, [Fig. 55] (a) Block configuration diagram of the credit payment terminal according to the second embodiment of the present invention, (b) Block configuration diagram of the infrared light receiving / emitting module of the credit payment terminal according to the second embodiment of the present invention, FIG. 56. ] The second embodiment of the present inventionConfiguration diagram of the internal register of the credit settlement terminal in the embodiment, FIG. 57 (a) Bitfield configuration diagram of the INT register of the credit settlement terminal in the second embodiment of the present invention, (b) Second aspect of the present invention. Bitfield configuration diagram of variable interrupt on RAM of credit payment terminal in the embodiment, FIG. 58 is a schematic diagram of the RAM map of the credit payment terminal in the second embodiment of the present invention, FIG. 59. A schematic diagram of data stored in the service data area of the credit payment terminal according to the second embodiment of the present invention, FIG. 60 (a) List of CPU processes of the credit payment terminal according to the second embodiment of the present invention. Figure, (b) Explanatory drawing for explaining the update of the process list by the process management process of the credit settlement terminal in the second embodiment of the present invention, [Fig. 61] Credit in the second embodiment of the present invention. Conceptual diagram of processing flow performed by the CPU of the payment terminal, [Fig. 62] Conceptual diagram of the normal processing flow performed by the CPU of the credit payment terminal in the second embodiment of the present invention, [Fig. 63] Second embodiment of the present invention. Conceptual diagram of processing flow at the time of processing of "payment" performed by the CPU of the credit settlement terminal in the embodiment, FIG. 64 (a) Flow diagram of processing of digital signature in the second embodiment of the present invention, (b). ) Flow diagram of digital signature processing in the second embodiment of the present invention, [Fig. 65] (a) Flow diagram of message encapsulation processing in the second embodiment of the present invention, (b) The present invention. Flow explanatory diagram of message sealing process according to the second embodiment of the invention, FIG. 66 (a) Flow diagram of message decryption process according to the second embodiment of the present invention, (Fig. 66). b) Flow of decryption processing of sealed message in the second embodiment of the present invention, FIG. 67 (a) Flow of verification processing of digital signature in the second embodiment of the present invention. Fig., (B) Flow explanatory diagram of digital signature verification processing according to the second embodiment of the present invention, [Fig. 68] Processing archer of the service providing system according to the second embodiment of the present invention.Explanatory diagram of texture, [Fig. 69] List of processes of the service providing system according to the second embodiment of the present invention, [Fig. 70] List of processes of the service providing system according to the second embodiment of the present invention (FIG. 70) (Continued), [Fig. 71] Schematic diagram of data stored for one user in the user information server of the service providing system according to the second embodiment of the present invention, [Fig. 72] Second embodiment of the present invention. A schematic diagram of data stored for one merchant in the merchant information server of the service providing system according to the second embodiment of the present invention. FIG. 73. Payment processing organization of the service providing system according to the second embodiment of the present invention. Schematic diagram of data stored in one payment processing institution in the information server, [Fig. 74] Data stored in the service director information server of the service providing system according to the second embodiment of the present invention. Equation, FIG. 75 (a) Schematic diagram of user process management information generated for one user process in the service providing system according to the second embodiment of the present invention, (b) The present invention. In the service providing system according to the second embodiment, a schematic diagram of the merchant process management information generated for one merchant process, (c) in the service providing system according to the second embodiment of the present invention, one. Schematic diagram of payment processing institution process management information generated for one payment processing institution process, (d) Generated for one service director process in the service providing system according to the second embodiment of the present invention. (E) Schematic diagram of process group management information generated for one process group in the service providing system according to the second embodiment of the present invention, (f) A schematic diagram of the message list generated in the service providing system according to the second embodiment of the present invention, [Fig. 76] From the personal credit terminal to the service providing system according to the second embodiment of the present invention. Flow diagram of session establishment process when connecting, [FIG. 77 is a flow diagram of a session establishment process when connecting to a personal credit terminal from the service providing system according to the second embodiment of the present invention, and FIG. 78 is a flow diagram of a session establishment process according to the second embodiment of the present invention. (A) Data structure diagram of authentication test A, (b) Data structure diagram of authentication test A response, (c) Authentication test B response when connecting to a personal credit terminal from (D) The data structure of the authentication test C in the session establishment process when the service providing system in the second embodiment of the present invention connects to the personal credit terminal. e) Schematic diagram of the data structure of the authentication test C response, (f) Schematic diagram of the data structure of the authentication test D response, [Fig. 79] Service provision system from the credit settlement terminal according to the second embodiment of the present invention. Flow diagram of session establishment process when connecting to, [Fig. 80] Flow diagram of session establishment process when connecting to a credit settlement terminal from the service providing system according to the second embodiment of the present invention, [Fig. 81] (A) A schematic diagram of the data structure of the authentication test A and (b) the data structure of the response of the authentication test A in the session establishment process when the service providing system in the second embodiment of the invention connects to the credit payment terminal. Schematic diagram, (c) Authentication test B Response data structure schematic diagram, (d) Authentication test of session establishment process when connecting from the service providing system in the second embodiment of the present invention to the credit payment terminal A schematic diagram of the data structure of C, (e) a schematic diagram of the data structure of the authentication test C response, (f) a schematic diagram of the data structure of the authentication test D response, [Fig. 82] The second embodiment of the present invention. (A) Remote access processing flow diagram, (b) Data update processing flow diagram, (c) Forced data update processing flow diagram, (d) Data backup processing Flow Diagram, FIG. 83: Personal credit terminal and user processor according to a second embodiment of the present invention.(A) Schematic diagram of the data structure of the remote access request, (b) Schematic diagram of the data structure of the remote access data, (c) Schematic diagram of the data structure of the data update request, (d) A schematic diagram of the data structure of the data update response, (e) a schematic diagram of the data structure of the uploaded data, (f) a schematic diagram of the data structure of the update data, [Fig. 84] The second embodiment of the present invention. (A) A schematic diagram of the data structure of the function stop command, (b) A schematic diagram of the data structure of the data update command, which is exchanged between the personal credit terminal and the user process in (A) Remote access processing flow diagram, (b) Data update processing flow diagram, (c) Forced data update processing flow diagram, [Fig. 86] of the present invention by the credit settlement terminal and the merchant process in the embodiment. (A) Schematic diagram of the data structure of the remote access request, (b) Schematic diagram of the data structure of the remote access data, (c) Data update exchanged between the credit settlement terminal and the merchant process in the second embodiment. A schematic diagram of the data structure of the request, (d) a schematic diagram of the data structure of the data update response, (e) a schematic diagram of the data structure of the uploaded data, (f) a schematic diagram of the data structure of the update data, [ FIG. 87: (a) a schematic diagram of the data structure of a function stop command and (b) a schematic diagram of the data structure of a data update command exchanged between the credit settlement terminal and the merchant process in the second embodiment of the present invention. , [Fig. 88] Explanation of message exchange procedure of "settlement" processing in the second embodiment of the present invention, [Fig. 89] (a) Data structure of payment offer in the second embodiment of the present invention. Schematic diagram, (b) Schematic diagram of the data structure of the payment offer response in the second embodiment of the present invention, (c) Schematic diagram of the data structure of the credit inquiry request in the second embodiment of the present invention. Figure, (d) a schematic diagram of the data structure of the payment request in the second embodiment of the present invention, (e) the data structure of the credit inquiry response in the second embodiment of the present invention.Schematic diagram of the structure, (f) Schematic diagram of the data structure of the payment request transmitted from the credit settlement terminal to the service providing system in the second embodiment of the present invention, [Fig. 90] (a) The schematic diagram of the present invention. A schematic diagram of the data structure of the payment request transmitted from the service providing system in the second embodiment to the payment system, (b) transmitted from the payment system in the second embodiment of the present invention to the service providing system. Schematic diagram of the data structure of the payment completion notification, (c) Schematic diagram of the data structure of the payment completion notification transmitted from the service providing system in the second embodiment of the present invention to the credit settlement terminal, [Fig. 91]. (a) A schematic diagram of the data structure of the receipt transmitted from the credit settlement terminal to the service providing system in the second embodiment of the present invention, (b) the service providing system in the second embodiment of the present invention. Schematic diagram of the data structure of the receipt sent from to the personal credit terminal, [Fig. 92] Message exchange procedure explanatory diagram of the "cancellation" process in the second embodiment of the present invention, [Fig. 93] (Fig. 93). a) A schematic diagram of the data structure of the cancellation request transmitted from the credit settlement terminal in the second embodiment of the present invention to the service providing system, (b) the personal credit terminal in the second embodiment of the present invention. Schematic diagram of the data structure of the cancellation request transmitted from the service providing system to the service providing system, (c) Schematic diagram of the data structure of the cancellation request transmitted from the service providing system to the payment system according to the second embodiment of the present invention. , (D) A schematic diagram of the data structure of the cancellation completion notification sent from the payment system to the service providing system in the second embodiment of the present invention, (e) providing the service in the second embodiment of the present invention. Schematic diagram of the data structure of the cancellation completion notification sent from the system to the credit settlement terminal, (f) Schematic diagram of the data structure of the cancellation processing receipt according to the second embodiment of the present invention, [Fig. 94] ( a) Message exchange procedure explanatory diagram of processing of "customer service call" in the second embodiment of the present invention, (b) the second embodiment of the present invention.Message exchange procedure explanatory diagram of processing of "inquiry call" in the state, [Fig. 95] (a) Schematic diagram of the data structure of the customer service call request in the second embodiment of the present invention, (b) The present invention. Schematic diagram of the data structure of the customer service call according to the second embodiment, (c) Schematic diagram of the data structure of the customer service call response according to the second embodiment of the present invention, (d) The first embodiment of the present invention. Schematic diagram of the data structure of the incoming call response during the customer service call according to the second embodiment, (e) Schematic diagram of the data structure of the call response during the customer service call according to the second embodiment of the present invention. , FIG. 96 (a) Schematic diagram of the data structure of the inquiry call request in the second embodiment of the present invention, (b) Schematic diagram of the data structure of the inquiry call in the second embodiment of the present invention. Figure, (c) Schematic diagram of the data structure of the inquiry call response according to the second embodiment of the present invention, (d) The data structure of the incoming call response during the inquiry call according to the second embodiment of the present invention. Schematic diagram, (e) Schematic diagram of the data structure of the call response during an inquiry call in the second embodiment of the present invention, FIG. 97. Service manager process in the second embodiment of the present invention. Main processing flow of FIG. 1, [Fig. 98] Main processing flow of the service manager process according to the second embodiment of the present invention FIG. 2, [Fig. 99] Service according to the second embodiment of the present invention. Flow diagram of process generation processing by the manager process, FIG. 100 is a main processing flow diagram of a user process according to the second embodiment of the present invention, and FIG. 101 is a flow diagram of a merchant process according to the second embodiment of the present invention. Main processing flow diagram, FIG. 102 is a main processing flow diagram of the settlement processing institution process according to the second embodiment of the present invention, FIG. 103 is from a personal credit terminal according to the second embodiment of the present invention. Flow diagram of session establishment processing by a personal credit terminal when connecting to a service providing system, FIG. 104: Personal credit in the second embodiment of the present invention.Flow diagram of session establishment process by user process when connecting from JIT terminal to service providing system, [Fig. 105] Credit payment terminal when connecting from credit payment terminal to service providing system according to the second embodiment of the present invention. FIG. 106 is a flow diagram of a session establishment process according to the above, FIG. 106 is a flow diagram of a session establishment process by a merchant process when connecting to a service providing system from a credit settlement terminal in the second embodiment of the present invention, FIG. 107. FIG. 108 is a flow chart of a session establishment process by a user process when connecting to a personal credit terminal from the service providing system according to the second embodiment of the present invention. FIG. 108: Personal from the service providing system according to the second embodiment of the present invention. -Flow diagram of session establishment processing by the personal credit terminal when connecting to the credit terminal, [Fig. 109] According to the merchant process when connecting to the credit payment terminal from the service providing system according to the second embodiment of the present invention. Flow diagram of session establishment process, FIG. 110 is a flow diagram of session establishment process by the credit settlement terminal when connecting to the credit settlement terminal from the service providing system according to the second embodiment of the present invention, FIG. 111 (a). ) Flow diagram of remote access processing by the personal credit terminal in the second embodiment of the present invention, (b) Flow diagram of user validity check by the personal credit terminal in the second embodiment of the present invention, [ FIG. 112: (a) Flow diagram of remote access processing by the user process in the second embodiment of the present invention, (b) Flow diagram of the user process validity check by the user process in the second embodiment of the present invention. (Fig. 113) (a) Flow diagram of remote access processing by the credit payment terminal in the second embodiment of the present invention, (b) Merchant effectiveness by the credit payment terminal in the second embodiment of the present invention. Check flow diagram, [Fig. 114] (a) Second fruit of the present inventionFlow diagram of remote access processing by the merchant process in the embodiment, (b) Flow diagram of merchant process effectiveness check by the merchant process in the second embodiment of the present invention, [Fig. 115] Second embodiment of the present invention. FIG. 116 is a flow chart of data update processing by a personal credit terminal in the embodiment of the present invention, FIG. 116 is a flow chart of data update processing by a user process in the second embodiment of the present invention, and [Fig. 117] is a second embodiment of the present invention. FIG. 118 is a flow chart of data update processing by a credit settlement terminal in the embodiment of the present invention, FIG. 118 is a flow chart of data update processing by a merchant process in the second embodiment of the present invention, and FIG. 119 is a second embodiment of the present invention. Flow diagram of forced data update processing by a personal credit terminal in the embodiment, FIG. 120 is a flow diagram of forced data update processing by a user process in the second embodiment of the present invention, FIG. 121. Flow diagram of forced data update processing by credit settlement terminal in the second embodiment of the present invention, [Fig. 122] Flow diagram of forced data update processing by the merchant process in the second embodiment of the present invention, FIG. 123. Flow diagram of data backup processing by personal credit terminal according to the second embodiment of the present invention, FIG. 124. Flow of processing of "payment" by credit settlement terminal according to the second embodiment of the present invention. FIG. 125: Flow of processing of payment by the credit settlement terminal in the second embodiment of the present invention FIG. 2, FIG. 126: Processing of payment by the merchant process in the second embodiment of the present invention. Flow FIG. 1, [Fig. 127] Flow of processing of "payment" by the merchant process in the second embodiment of the present invention FIG. 2, [Fig. 128] By the personal credit terminal in the second embodiment of the present invention. Payment processing flow FIG. 1, [Fig. 129] Payment by a personal credit terminal according to the second embodiment of the present invention.FIG. 2, [Fig. 130] Flow diagram of processing of "payment" by the user process in the second embodiment of the present invention, [Fig. 131] (a) Second embodiment of the present invention. Flow chart of processing of "payment" by the payment system in the above, (b) Flow diagram of the validity check of the payment processing institution by the payment system in the second embodiment of the present invention, [Fig. 132] (a) No. 1 of the present invention. Flow diagram of processing of "payment" by the settlement processing institution process in the second embodiment, (b) Flow diagram of the settlement processing institution process effectiveness check by the settlement processing institution process in the second embodiment of the present invention, [ FIG. 133: Flow of processing of payment by the service director process in the second embodiment of the present invention FIG. 1, [Fig. 134] Payment by the service director process in the second embodiment of the present invention. FIG. 2, FIG. 135 is a flow diagram of processing of cancellation by the credit settlement terminal in the second embodiment of the present invention, FIG. 136 is a merchant process in the second embodiment of the present invention. FIG. 137 is a flow chart of "cancellation" processing according to the above, FIG. 137 is a flow chart of "cancellation" processing by a personal credit terminal in the second embodiment of the present invention, and [Fig. 138] is a second embodiment of the present invention. Flow diagram of "cancellation" processing by the user process in the embodiment, [Fig. 139] Flow diagram of "cancellation" processing by the payment system in the second embodiment of the present invention, [Fig. 140] Second aspect of the present invention. Flow diagram of processing of "cancellation" by the settlement processing institution process in the embodiment, FIG. 141. Flow diagram of processing of "cancellation" by the service director process in the second embodiment of the present invention, FIG. 142. Flow diagram of processing of "customer service call" by the credit settlement terminal in the second embodiment of the present invention, FIG. 143. Processing of "customer service call" by the merchant process in the second embodiment of the present invention. Flow Diagram, FIG. 144. Personal credit in the second embodiment of the present invention.Flow diagram of processing of "customer service call" by terminal, [Fig. 145] Flow diagram of processing of "customer service call" by user process in the second embodiment of the present invention, [Fig. 146] Second embodiment of the present invention. Flow diagram of processing of "customer service call" by the service director process in the second embodiment of the present invention, FIG. 147. Flow diagram of processing of "inquiry call" by the personal credit terminal in the second embodiment of the present invention. FIG. 148 is a flow diagram of processing of an inquiry call by a user process in the second embodiment of the present invention, and FIG. 149 is a flow diagram of an inquiry call by a credit settlement terminal in the second embodiment of the present invention. Process flow diagram, FIG. 150 is a flow diagram of processing of an inquiry call by a merchant process according to the second embodiment of the present invention, FIG. 151 is a service director process according to the second embodiment of the present invention. FIG. 152 (a) The home service area of the user and the merchant in the second embodiment of the present invention is the same, and the user makes a payment in the home service area. Operation explanatory diagram in the case of performing the processing of, or the processing of "cancellation", (b) The home service area of the user and the merchant in the second embodiment of the present invention is different, and the user is in the home service area of the merchant. , Operation explanatory diagram when performing "payment" processing or "cancellation" processing, [Fig. 153] (a) The home service area of the user and the merchant in the second embodiment of the present invention is different, and the user However, in the user's home service area, the operation explanatory diagram when the "cancellation" process is performed, (b) the home service area of the user and the merchant in the second embodiment of the present invention is different, and the user is the user or Operational diagram when performing "cancel" processing in a service area other than the merchant's home service area, [Fig. 154] (a) With the user in the second embodiment of the present invention.Operation explanatory diagram when the home service area of the merchant is the same and the user and the merchant process the "customer service call" or the "inquiry call" in the home service area, (b) No. 1 of the present invention. The operation explanatory diagram when the home service area of the user and the merchant in the second embodiment is different and the merchant processes the "customer service call" to the user, [Fig. 155] (a) The second embodiment of the present invention. The operation explanatory diagram when the home service area of the user and the merchant in the embodiment is different and the user processes the "inquiry call" from the user's home service area, (b) in the second embodiment of the present invention. It is operation | movement explanatory diagram when the home service area of a user and a merchant is different, and a user performs "inquiry call" processing from a service area other than the home service area of a user or a merchant.

[Code description] 100 Personal credit terminal 101 Credit payment device 102 Service provision system 103, 4202 Payment system 104 Base station 108 Digital public network 200 Infrared communication port 201 Antenna 202 Receiver speaker 203, 302 LCD204, 304 Mode switch 205 Call Switch 206 Exit Switch 207, 306 Function Switch 208, 307 Tenkey Switch 209, 309 Power Switch 210 Microphone 211, 308 Execution Switch 212 Headset Jack 300 Credit Payment Terminal 301 Infrared Light Emitting Module 303 Handset 305 Hook Switch 310 Serial Cable 311 Cash Register 312 Credit payment switch 313 RS-232C cable 400 Service server 401 Server director Information server 402 User information server 403 Merchant information server 404 Payment processing agency information server 405, 408, 504, 507 ATM-LAN switch 406, 505 ATM exchange 407, 506 Management system 500 Transaction processing server 501 Subscriber information server 502 Merchant information server 503 Transaction information server 1507 Infrared communication module 1500, 2400, 22500 CPU1501, 2401, 22501 ROM1502, 2402, 22502 RAM1503, 2404, 22504 EEPROM1504, 2405, 22505 LCD Controller 1505, 2406, 22506 Cryptographic processor 1506, 2407, 22507 Data codec 1508, 2410, 22510 Control logic unit 1509, 2411, 22511 Key operation Control unit 1510, 2412, 22512 Speaker 1511, 2413, 22513 Voice processing unit 1512, 2414 , 22514 Voice codec 1513, 2415, 22515 Channel codec 1514 Modulator 1515 Demoder 1517 RF 1518 Battery capacity detector 1560, 2408, 22508 Series-parallel conversion circuit 1561, 2456, 22556 Modulation / demodulation circuit 1800, 21600 Frame counter 1801, 21601 Start frame counter 1802, 2700, 21602, 22600 Clock counter 1803, 2701, 21603, 22601 Update time register 1804, 2702, 21604, 22602 Interrupt register 1805, 2703, 21605, 22603 ID register 1806, 2704, 21606 , 22604 Channel Codex Control Registers 1807, 2705, 21607, 22605 Voice Transmission Buffer 1808, 2706, 21608, 22606 Voice Reception Buffer 1809, 2707, 21609, 22607 Data Transmission Buffer 1810, 2708, 21610, 22608 Data Reception Buffer 1811, 2709, 21611, 22609 Voice processing unit control register 1812, 2710, 21612, 22610 Key operation control register 21613, 22611 Voice data encryption key register 2403, 22503 Hard disk 2409, 2455, 22503, 22555 Serial port 2416, 22516 Digital communication adapter 2417, 22517 RS-232C interface 4200 Credit card 4201 Credit payment terminal 4203 Public network