CA2198793C

CA2198793C - Method of processing plural types of transactions using card

Info

Publication number: CA2198793C
Application number: CA002198793A
Authority: CA
Inventors: Akira Kumomura
Original assignee: Hitachi Ltd
Current assignee: Hitachi Ltd
Priority date: 1996-03-04
Filing date: 1997-02-28
Publication date: 2002-05-28
Anticipated expiration: 2017-02-28
Also published as: GB9704388D0; GB2310944B; CA2198793A1; US5963926A; GB2310944A; JPH09237305A

Abstract

The present invention is directed to a method, apparatus and computer program for processing plural types of transactions by a transaction processor connected to plural companies of different industries via a network. Use of the invention enables the efficient performance of a variety of transactions related to insurance utilizing one or plural cards. In the invention the insurance card of a transactor is input, and a transaction screen including transaction keys related to preset transactions proper to the transactor is displayed. A transaction key showing a desired transaction is selected on the displayed screen and another card or other plural cards required for the desired transaction are input sequentially. The personal identification numbers of the cards are entered, and transactions, such as loan, inquiry, payment of insurance, contract, voidance/cancellation of a contract or payment of a premium can be executed.

Description

METHOD OF PROCESSING PLURAL TYPES OF TRANSACTIONS USING CARD
The present invention relates to a method, apparatus and computer program, for processing plural types of trans-actions using cards. More particularly, the present invention relates to a method, apparatus and computer program for processing a variety of transactions using one or plural cards in an efficient manner by a transaction processor connected to plural institutions of different industries such as an insurance company, a bank, a credit card issuance company, a loan office and other financial institutions via a network.
A system for utilizing an automatic transaction processor such as an automatic teller machine (ATM) and performing a variety of transactions with a transactor is well known. Such a system as described on pages 57 to 71 of the Financial Journal published in Dec. 1995 is well known. This system utilizes a transaction card owned by a transactor such as a debit card issued by a bank via an ATM to receive regular services of a bank such as withdrawal, deposit and transfer provided by ATM as other transactors.
A system for freely performing a variety of transactions among companies of different industries is also well known. Such a system is described in "Creating Electronic Commerce By The Internet" by T. Kimura, et al., Nikkei Multimedia, July 1995, pp. 139-154. In this system, attribute/transaction information held in a common server is managed individually and a user can access the transaction information freely.

- 219~7g~
Further, a system utilizing electronic money for payments is well known. Such a system is described in "MODEX
Will Expand the MONDEX System in Britain After Two Years" by Y. Ochi, Financial Journal, Jan. 1996. This system is used to pay money by sending or receiving electronic money which is an electronic symbol of money and is stored in an IC chip embedded in a conventional plastic card.
These conventional methods have the following problems:
If an insurance transaction such as loan and inquiry is performed utilizing an ATM operated by an insurance company, only one card issued by the insurance company is used for the transaction with the insurance company. However, if the contract of new insurance via an ATM in cooperation with a bank and a credit card issuance company, a loan based upon the contract of an insurance and a bank account and inquiry of an insurance, a bank account or a credit card are performed, transaction processing is required to be executed individually using each card. Such processing is not very efficient.
Personal identification numbers are required for each card for every industry. If personal identification numbers for each card are different then each of these different personal identification numbers are required to be entered in order to perform required processing. For the user such a requirement is inconvenient.
There is also a problem that the types and arrangement of transaction keys on the transaction screen of an ATM are fixed for all customers and transactions. Thus, an 2~9~ ~ J~

- undesired transaction key is displayed in a main location of the screen and a transaction desired by a transactor cannot be necessarily performed efficiently.

An object of the present invention is to provide a method, apparatus and computer program for processing plural types of transactions using cards wherein plural cards of different industries can be utilized at one transaction terminal and a variety of insurance transactions can be efficiently performed.
Another object of the present invention is to provide a method, apparatus and computer program for processing plural types of transactions using cards wherein if plural cards are used, only the entry of the personal identification numbers of an insurance card and a bank card for payment is required and as a result, operations for entry can be reduced.
Yet another object of the present invention is to provide a method, apparatus and computer program for processing plural types of transactions using cards wherein a transaction screen is adapted to the contents of the transactions of a transactor from the past to the present and his/her future schedule of transactions and a transaction efficient to a transactor can be performed.
Still yet another, object of the present invention is to provide a method, apparatus and computer program for processing plural types of transactions using cards wherein the transaction information of companies of different industries 2 '~ L- ~

can be stored in a common server or in a chip of each IC card and as a result, an area for storing information and retrieval time can be reduced.
According to the present invention, a variety of transactions with an institution such as an insurance company using one or plural cards are performed via a transaction processor such as personal computers inside/outside a shop, an ATM and a portable terminal.
First, one insurance card of a transactor is inserted. A transactor in this case means an insurant who joins the insurance of an insurance company or a depositor with an account in a bank and a person who actually operates a transaction processor. A transaction screen consisting of transaction keys related to preset transactions appropriate for a particular transactor is displayed. The position, type, shape and color of keys on this transaction screen can be changed or added according to the transaction contents of the transactor. A transaction key related to a transaction selected on the displayed transaction screen is pressed. As the types of transactions, loan, receipt of insurance and others are provided, other cards such as a bank card, a credit card and another insurance card required for the transaction are received. No other cards may be required depending upon the transaction and plural cards may be required.
Next, the personal identification numbers of the first inserted insurance card are entered. In case withdrawal occurs in the transaction of an insurance such as if money is withdrawn via a bank card for the payment of insurance, the 219~7~

personal identification numbers of a card related to the withdrawal are entered.
The contract of new insurance, the receipt of insurance, loan, inquiry, the payment of insurance and the cancellation of insurance are performed. Particularly, in the case of loans, a loan is performed based upon the total loanable limit sum of the received one or plural cards. In the case of inquiry, attribute information and transaction information of received cards are merged and the same information such as attribute information held by plural companies is displayed on the screen without redundancy. In the case of the repayment of insurance, it is selected whether paid insurance is deposited in the bank account of a transactor or not and if the transactor has no account in a bank though a deposit is selected, an account for him/her is opened automatically.
Further, in the contract of new insurance, if a transactor signs or seals when he/she applies for a bank card or a credit card, a new contract can be made by entering a requirement in an application on the screen and answering a notice in case the sum of money equivalent to initial insurance is deposited in his/her bank account. If the balance of a transactor's bank account is less than insurance and insurance cannot be paid, the transactor is automatically joined in bank card loan or the credit of a credit card. If a transactor presses a transaction key showing the cancellation of his/her insurance, transaction keys for displaying total insurance and repayment and transaction keys for recommending 21987g3 the transactor to switch to another insurance are displayed on the screen.
The present invention will be more apparent from the following detailed description, when taken in conjunction with the accompanying drawings, in which:
Fig. 1 is a block diagram illustrating a system according to the present invention;
Fig. 2 illustrates a processing flowchart showing an embodiment for a loan according to the present invention;
Figs. 3A-3D illustrate the construction of an insurance card, an attribute information record, an electronic money record and a transaction information table;
Figs. 4A-4C illustrate transaction screens for an aged person and a newly married couple and an attribute file;
Fig. 5 illustrates a personal identification numbers table managed by a server;
Figs. 6A-6D illust~ate respective transaction tables of an insurance company, a bank and a credit card issuance company and a loan upper limit file;
Figs. 7A and 7B illustrate a processing flowchart illustrating an embodiment for inquiry and an inquiry screen according to the present invention;
Figs. 8A-8C illustrate respective transaction tables of an insurance company and a bank and a property/debit table;
Fig. 9 illustrates a processing flowchart illustrating an embodiment for paying insurance according to the present invention;
Figs. lOA and loR illustrate a screen for paying 21!1~7~3 -insurance in a transactor's bank account and an opened account deposit file;
Fig. 11 illustrates a processing flowchart illustrating an embodiment for a new contract according to the present invention;
Figs. 12A, 12B and 12C illustrate a general transaction screen, a new contract screen and a contract conclusion/policy issuance screen;
Fig. 13 illustrates a processing flowchart showing an embodiment related to the voidance of an insurance contract according to the present invention;
Figs. 14A-14E illustrate respective transaction tables of an insurance company and a bank, a balance comparison table and an opened account record;
Fig. 15 illustrates a screen for selecting a method of paying insurance;
Fig. 16 illustrates a processing flowchart showing an embodiment related to the cancellation of an insurance contract according to the present invention; and Figs 17A-17C illustrate a transaction screen including a transaction key "CANCELLATION", another insurance switching guidance screen and a total insurance/cancelled repayment guidance screen.

Embodiments according to the present invention will be described below referring to the drawings.

21Y87~3 Fig. 1 illustrates the constitution of a system according to the present invention. A server 4 connected to an attribute/transaction database (DB) 1 for insurance companies, an attribute/transaction DB 2 for banks and an S attribute/transaction DB 3 for credit card issuance companies and a plurality of client servers 6, 6' are connected via a network 5. The server 4 in this case means a computer in a common center managed by insurance companies, banks and credit card issuance companies. A display 10, a keypad entry apparatus 11, a card input apparatus 12 and an external storage apparatus consisting of a loan balance storage 13 and an inquiry contents storage 14 are connected to the client server 6. This display 10 is provided with a touchpanel usually used in an ATM and can also function as the key entry apparatus 11.
Each client server 6, 6' constitutes a terminal which a customer who is a transactor uses and constitutes an insurance transaction network under control by the server 4.
Only two servers are shown in Fig. 1, however, in practice multiple servers are connected. Since an insurance transaction network can be constituted using well-known technology such as well-known electronic commerce (EC), a detailed description thereof is omitted here. For example, a personal computer can be used as the client server 6 and the client server contains a general control apparatus 9 including a CPU, internal memory 8 and a communication con~rol apparatus 7 for controlling the communication of information via a network.
The display 10 is a unit for displaying information visibly such as a CRT display unit or a liquid crystal display ?, .~r and displays a transaction screen on which a customer who is a transactor transacts.
The keypad entry apparatus 11 is used to enter information for selecting the contents of a transaction and entering the desired sum of a loan and a desired inquiry item in addition to entering personal identification numbers and for example, a mouse, a joystick or a keypad can be used as the keypad entry apparatus. A loan upper limit sum table described later for setting the upper limit sum of a loan to a customer is stored in the loan balance storage 13. The inquiry contents storage 14 is a storage for storing a variety of information relating to a received card.
The general control apparatus 9 controls the overall client server 6 by a program input beforehand to enable operation. The control for displaying transaction keys related to transactions proper to a transactor on the display 10, the control for inputting plural cards via the card input apparatus 12 and the control for entering the personal identification numbers of the first input card via the keypad entry apparatus 11 are executed by this general control apparatus 9. Such processing can be executed by a software product installed beforehand.
Next, the processing flow for a loan in this embodiment will be described referring to Figs. 2 to 6.
Fig. 2 illustrates a processing flowchart for inputting the contents of a transaction to a client server 6, performing required processing and displaying the result of processing on the client server 6.

21g8/i'~3 An insurance card of a transactor is input via the card input apparatus 12 in a step 21 in Fig. 2. The input insurance card is shown in Fig. 3A. As shown in Fig. 3A, an insurance card 31 is inserted into an ATM in the direction 32 to be input. In the upper part of the card, a linear magnetic stripe 33 extends horizontally for storing an attribute information record shown in Fig. 3B is embedded and immediately under the magnetic stripe, an IC chip 34 for storing an electronic money record shown in Fig. 3C is provided on the left side and an IC chip 35 for storing a transaction information table shown in Fig. 3D is provided on the right side. The particular constitution of the card, that is, the arrangement of the IC chips 34 and 35 and the arrangement of contact with a card reader/writer can be realized by a well-known method. Therefore, the description thereof is omitted.
In the above attribute information record shown in Fig. 3B, the information of the owner of a card such as his/her name, address and date of birth, job and telephone number is stored. In the electronic money record shown in Fig. 3C, the amount of electronic money to be stored in the IC
chip 34 is stored. The format for storing electronic money is arbitrary, however, for example, each unit of money such as ten thousand yen and a thousand yen and the amount are stored.
The transaction information table shown in Fig. 3D is attribute information related to a transactor and the type of transaction related to the owner of an insurance card, the contents or the history is stored in a table format. When the insurance card of a transactor is input, a transaction screen 2 1 ~ ~ ' 3 - consisting of transaction keys related to preset transactions proper to the transactor is displayed in a step 22.
This transaction screen wili be described below referring to Figs. 4A-4C. First, an attribute file shown in Fig. 4C based upon an input insurance card is obtained from the attribute/transaction DB 1 for insurance companies shown in Fig. 1 via the server 4 and the network 5. In this file of a customer, the transaction characteristics of the customer such as marital status 46 and a main transaction 47 are set. A
transaction screen in view of such characteristics of a customer is displayed on the display means 10. Fig. 4A shows such an example. A'transaction screen 41 shows a screen for Mr.
Tanaka who is an aged person in a customers' file and as his main transaction is relatëd to a pension, the frame and characters of a transaction key 42 is displayed larger than those of a transaction key 43 to highlight the transaction key 42. If a transaction is to be promoted particularly in a month, it may be displayed large in the lower part of the screen as a transaction key 44. Fig. 4B shows a screen dedicated to Mr. &
Mrs. Yamada who are a newly married couple. As Mr. & Mrs.
Yamada have need for a loan, loan is displayed with it highlighted as a transaction key 45.
Next, the information of a transaction key related to a transaction selected by a transactor via the keypad entry apparatus 11 is entered on the transaction screen displayed on the display 10 via the general control apparatus 9 in a step 23. Next, one or plural other cards required for the transaction are input via the card input apparatus 12 ~ 1 9 8 ~ ~ ~

sequentially in a step 24 and the respective personal identification numbers are entered via the keypad entry apparatus 11 in a step 25. Another card required-for the transaction is a card which companies join or a card by which 5 bidirectional transaction processing is enabled in this system.
It should be displayed on the screen in a step 24 which card is to be input so as to inform a transactor.
Personal identification numbers are managed by the server 4 shown in Fig. 1 and are stored in a personal 10 identification numbers table shown in Fig. 5. In this personal identification numbers table, the identification number of each card and respective personal identification numbers such as insurance card information 51, bank card information 52 and credit card information 53 are stored. In this embodiment, in 15 the case of Mr. Tanaka who has a loan, the personal identification numbers "3111" of his bank card are also entered in addition to the personal identification numbers "2111" of his insurance card. This time an example related to the loan is given, however, in the case of a transaction which is not 20 related to withdrawal such as inquiry, only the personal identification numbers of a first input card need only to be entered once. As the personal identification numbers of the insurance card, the bank card and the credit card of Mr. Yamada are all set to "5555", his personal identification numbers 25 "5555" have only to be entered once in any transaction. Though it is not desirable in view of security that the same personal identification numbers are used, this system is managed as described above because it is not efficient to enter the same - 21987g3 personal identification numbers several times. Of course, this system may be constituted so that the same personal identification numbers are entered several times.
After personal identification numbers are entered, the desired sum of the loan is entered via the keypad entry apparatus 11 in a step 26. When the desired sum is entered, the order of companies by which a transactor is loaned can be determined. For example, if the desired sum of the loan is one million yen and the interest of the loan is low in the order of an insurance company, a bank and a credit card issuance company, five hundred thousand yen equivalent to the upper limit of a loan may be loaned by an insurance company and five hundred thousand yen within the upper limit of a loan may be loaned by a bank. In this embodiment, the case that the sum equivalent to the upper limit of a loan is loaned will be described. After a desired sum of loan is entered, the upper limit of a loan is totalized in a step 27 and electronic money equivalent to the desired sum of loan is transferred to the insurance card 31.
This flow will be described referring to Figs.
6A-6D. First, an insurance company transaction table shown in Fig. 6A is sent from the attribute/transaction DB 1 for insurance companies to the server 4, a bank transaction table shown in Fig. 6B is sent from the attribute/transaction DB 2 for banks to the server 4, a credit card issuance company transaction table shown in Fig. 6C is sent from the attribute/transaction DB 3 for credit card issuance companies to the server 4, the loan upper limit file shown in Fig. 6D of a transactor is generated, the upper limit sums of loan 61, 62 ~ 1 9 8 ~ 9 ?~

and 63 of the transactor in respective tables are totalized and the total sum is displayed on the display means 10 via the client server 6. If the sum is within the desired sum of the loan formerly entered, the sum of the loan is transferred to the electronic money record 34 of the insurance card shown in Fig. 3A via the card input apparatus 12. The sum of the loan may be stored in the loan balance storage 13 shown in Fig. 1 as the balance of a loan via the card input means 12.
As described above, when plural cards are inserted into an automatic transaction processor connected to an insurance company, transactions with plural companies can be processed once.
Next, an inquiry transaction will be described referring to Figs. 1, 2, 4, 7A-7B and 8A-8C.
As shown in Fig. 7A, the insurance card of a transactor and his/her card-required for inquiry are input sequentially via the card input apparatus 12 in a step 71. In this embodiment, an inquiry with respect to the property and debt of a transactor in an insurance company and a bank can be made at one time. Therefore, a bank card is input sequentially after an insurance card. Next, a transaction screen is displayed in a step 72 as in the step 22 in Fig. 2.
A transaction key "INQUIRY" on this displayed transaction screen is entered via the keypad entry apparatus 11 or pressed on the touchpanel of the display 10 in a step 73. "INQUIRY" on this transaction screen as the one shown in Fig. 4B is selected causing the display of inquiry screen 700 illustrated in Eig. 7s. The inquiry screen 700 includes PROPERTY 701, DEBT 702 and PROPERTY/DEBIT 703 keys.

21~8~3 If "PROPERTY/DEBT" key 703 of the inquiry screen 700 is entered or pressed in a step 74, the same method as in the step 73 is performed causing the display of PROPERTY/DEBT information.
The same also occurs if any of the other keys, PROPERTY 701, or DEBT 702 are entered or pressed. As this transaction screen is like the format of the first transaction screen, the description is omitted here. Next, only the personal identification numbers of the first input insurance card of two input cards are entered via the keypad entry apparatus 11 in a step 75. It is because in the case of a transaction not related to withdrawal, payment or a transfer such as inquiry, the enhancement of the-operability of a transactor is regarded as more important rather than the enhancement of security by entering personal identification numbers corresponding to all cards that only personal identification numbers of a first inserted card are entered and the input of those of a next inserted card is omitted. As withdrawal or others is/are not performed using the card the personal identification numbers of which are not entered, a close check of personal ~0 identification numbers to determine if the owner of the card is a transactor or not is not re~uired.
Total insurance 81 which is a property item and the sum of a loan to a contractor 82 which is a debt item in an insurance company transaction table shown in Fig. 8A, the balance of a deposit 83 which is a property item and the balance of card loan 84 which is a debt item in a bank transaction table shown in Fig. 8B are respectively extracted to generate a property/debt table shown in Fig. 8C in a step - 2198~
76. At this time, repeated "No.", "Name" and other items not related to "Property/Debt" in Figs. 8A and 8B are used in the generated table though not displayed. As "No." and "Name" are the information of a transactor, they are not required to be displayed on the screen in this case and as "Transaction number" and "Account number" are only secondary information in relation to "Property/Debt", these are also not required to be displayed in this case. In response to the pressing or entering of the keys in the inquiry window 700 portions of the generated PROPERTY/DEBT table illustrated in Fig. 8C are displayed in step 77. Thus, for example, if the PROPERTY key 701 is pressed or entered all of the Property Items and the corresponding Sum of Property Items of the PROPERTY/DEBT table illustrated in Fig. 8C are displayed. However, if the card being processed is an insurance card then when the PROPERTY
key 701 is pressed or entered only the Total insurance property item and its corresponding Sum of Property Item and the Total property and its corresponding Sum of Property Item are displayed. If the DEBT key 701 is pressed or entered all of the Debt Items and corresponding Sum of Debt items of the PROPERTY/DEBT table illustrated in Fig. 8C are displayed. If the PROPERTY/DEBT key 703 is pressed or entered the entire PROPERTY/DEBT table illustrated in Fig. 8C is displayed. When the contents of inquiry of (property/debt) are to be stored, the contents of inquiry can be stored in the inquiry contents storage 14 shown in Fig. 1.
Next, the payment of insurance will be described referring to Figs. 1, 2, 6, 9 and 10.

- _ ~l9~t~.~3 The input of the insurance card of a transactor and the display of a transaction screen are performed in steps 91 and 92 in Fig. 9 by the same method as in the steps 21 and 22 shown in Fig. 2. A transaction key "PAYMENT OF INSURANCE" is pressed on the transaction screen in a step 93 by the same method as in the step 73 in Fig. 7. Next, a bank card for depositing insurance is input via the card input apparatus 12 in a step 94. The card number may be entered via the keypad entry apparatus 11 in place of the card. Next, only the personal identification numbers of the first input insurance card are entered via the keypad entry apparatus 11 in a step 95. In the case of a deposit, the personal identification numbers of an account for the deposit are not required to be entered. This is because money is paid in the bank account differently from withdrawal and others.
Next, the sum of paid insurance sent from the insurance company transaction table shown in Fig. 6A via the network 5 is displayed on the transaction screen of the display 10 in a step 96. It is displayed as in a display key 102 in the 2~ screen 101 in Fig. 10A. Next, an account in which the paid insurance is deposited is selected in a step 97. In Fig. 10A, a fixed deposit (annual interest: 1.5%) 103 and installment savings (annual interest: 0.7%) 104 are selected. After the selection, the transactor is prompted to further enter the sums to be deposited in the respective accounts. Hereby, the sums to be deposited in the respective accounts can be set freely in view of the respective annual interests. In this embodiment, as shown in the items of the contents of a transaction 105 and the - 21Y~7v ~
-balance of a deposit 106 in Fig. lOB, eighteen million yen is specified so that it is deposited in a fixed deposit, two million yen is specified so that it is deposited in installment savings and the respective accounts for payment are automatically opened in a step 98. The number of the opened account may be given in the order of requests for opening an account sent to the server 4 shown in Fig. 1 and serial numbers may be given to an individual transactor to simplify management thereof.
Next, the contract of a new insurance will be described referring to Figs. 1, 3, 11 and 12.
- As shown in Fig. 11, first the current card is input via the card input means 12 in a step 111. In this embodiment, a credit card issued by a credit card issuance company is input. Next, when the credit card is input, a transaction key showing a new contract on a general transaction screen displayed on the display means 10 is selected via the keypad entry apparatus 11 or others in a step 112 and the transaction screen for a new contract is displayed on the display means 10.
In the uppermost location of the general transaction screen shown in Fig. 12A, a transaction key for a credit card issuance company is displayed because a credit card is input. When the transaction key showing application for a new contract 121 is selected on the general transaction screen shown in Fig. 12A, a new contract screen is displayed as shown in Fig. 12B. The information of a requirement which is entered in an application 122 on the screen is obtained in a step 113, the information of a requirement which is entered in a notice 123 under the 21~$ (~ ~

application is obtained in a step 114 and further, it is output as in a signature/seal history 124 in a step 115 whether the information of a signature or seal of-a transactor is st~red or not. A signature and a seal in this signature/seal history mean those for the input credit card.
Finally, a method of paying insurance is entered in a step 116 as shown in the payment of initial insurance 125. As payment by electronic money is selected in this case, an electronic money card is input afterward. When such a chain of processing is finished, the attribute/transaction DB for insurance companies shown in Fig. 1 is updated via the network 5 and the server 4 and the result of a new contract is output in a step 117. When a contract is made, words to the effect that the contract has beèn made are displayed on the display lO
as shown in 126 in Fig. 12C and the transactor is prompted to enter a method of receiving an insurance policy in a step 118.
If the transactor desires sending of an insurance card to which the information of the insurance policy is input, he/she presses a transaction key 127 showing sending of the insurance card so that the insurance card to the chip 35 for storing transaction information shown in Fig. 3A of which the information of the insurance policy is input is sent. If safe custody 128 is selected, the transactor's insurance policy is kept stored in the attribute/transaction Ds for insurance companies and output to the transactor if necessary.
Next, the voidance of an insurance contract will be described referring to Figs. 1, 13, 14 and 15.
Fig. 13 shows the flow of the payment of insurance by -an automatic transaction processor. First, the information of fifty thousand yen stored in the item of insurance per month 143 beforehand set by a transactor in an insurancè company transaction table shown in Fig. 14A is received in a step 131 and next, the information of forty thousand yen stored in the item of the balance of his/her ordinary deposit 144 in a bank transaction table shown in Fig. 14B when the insurance is withdrawn is received in a step 132. This is automatically performed at the timing of a due date beforehand input by the transactor. Next, the set insurance per month and the balance of the transactor!s bank account when the insurance is withdrawn are compared in a step 133 and if the balance is more than the insurance, the contract is continued unconditionally in a step 134.
If the balance is less than the insurance, a screen 151 including warning 152 for selecting a method of paying insurance shown in Fig. 15 is displayed on the display 10 shown in Fig. 1. A method of paying insurance is selected on the displayed screen in a step 135, if payment by electronic money is selected by pressing a transaction key 153 shown in Fig. 15, the transactorls insurance card is input via the card input apparatus 12 in a step 136 and the sum equivalent to "-lo,000 yen" stored in the item of the shortfall of the balance 145 in a balance comparison table shown in Fig. 14C is paid by electronic money in a step 137. If no method of payment is set, the transactor is automatically joined in bank card loan or the credit of a credit card issuance company. If the transactor is joined in the bank card loan, his/her account for card loan is 8 ~ ~ ~

opened in a step 138, the sum equivalent to the shortfall of the balance is supplied in a step 139 and the contract is continued. If the transactor is joined in tne credit of a credit card issuance company, his/her account for the credit card is opened in a step 140, the sum equivalent to the shortfall of the balance is supplied in a step 141 and the contract is continued.
When a transaction key 156 showing automatic entry preset by the server 4 shown in Fig. 1 is selected by a transactor, the automatic entry is itemized. The transactor can allocate the sum of a loan respectively to card loan and the credit of a credit card in view of each annual interest and can enter the respective allocated sums in the balance of card loan 146 shown in Fig. 14D and the balance of a credit card 147 shown in Fig. 14E by pressing both transaction keys 154 and 155. Further, if no method of payment is set in the step 135 and no payment is made, the contract is automatically voided in a step 142.
Finally, the cancellation of an insurance contract ~O will be described referring to Figs. 1, 16 and 17.
As shown in Fig. 16, first the insurance card of a transactor is input via the card input means 12 in a step 161.
Next, a transaction screen 171 including a transaction key ''CANCELLATIONIl 172 shown in Fig. 17A is displayed on the display means 10 in a step 162 and the transaction key "CANCELLATION" on this transaction screen is selected by entry via the keypad entry means 11 or others in a step 163. As a result, guidance transaction keys shown in Fig. 17B for switching to another insurance are displayed on the display means 10 in a step 164. If a transaction key 173 or a transaction key 174 shown in Fig. 17B is pressed, the information related to the pressed transaction key is 5 displayed. The size of the transaction keys for switching to another insurance is set beforehand so that it is larger than the size of the transaction key showing cancellation 175. When "CANCELLATION" is pressed at this time, total insurance 176, repayment 177 by cancellation and a transaction key 178 for 10 guiding transactors in paying the repayment in their bank account are displayed in a step 165 as a total insurance/canceled repayment guidance screen shown in Fig. 17C.
When this payment guidance transaction key 178 is selected, cancellation processing is executed in a step 166, however, 15 when a transaction key "RETURN TO PRECEDING SCREEN" 179 is selected, the insurance contact can be switched to another insurance on another insurance switching guidance screen shown in Fig. 17B.
In this embodiment, the case that a shortfall is paid 2(~ by electronic money is described, however, if a premium is paid, a method reverse to the case is used. That is, electronic money stored in a transactor's insurance card input by him/her is stored in the server 4 via the network 5.
Preferred embodiments related to a variety of 25 insurance transactions according to the present invention are described above, however, the embodiments particularly relating to payment can be applied to bank transactions and credit card transactions. The processing which is similar to the processing ~.~ r~
hr 1 ~ J

according to the present invention can be also performed using an ATM installed in a bank.
As described in detail above, accordin~ to the present invention, plural cards issued by different industries can be utilized by one transaction terminal and a method of processing plural types of transactions using a card which enables the efficient performance of a variety of insurance transactions can be provided.
While the present invention has been described in detail and pictorially in the accompanying drawings it is not limited to such details since many changes and modifications recognizable to those of ordinary skill in the art may be made to the invention without departing from the spirit and the scope thereof.

Claims

1. A method of processing a transaction with plural institutions via a transaction processor using plural transaction cards, said method comprising the steps of:
receiving a first transaction card of a transactor;
inputting and then checking identification numbers corresponding to said first transaction card;
displaying a screen which includes a plurality of transaction keys related to said first transaction card;
permitting said transactor to select a transaction key of a desired transaction;
receiving one or more other transaction cards further required for said desired transaction;
judging whether identification numbers corresponding to said one or more other transaction cards in accordance with said desired transaction selected in said permitting step are required to be entered; and executing transaction processing between one or more of said institutions based on the input of identification numbers of said first transaction card or the input of identification numbers of said one or more other transaction cards required to be entered.

2. A method according to Claim 1, further comprising the step of:
if transaction processing of said one or more other transaction cards is not related to withdrawal of cash, omitting input of personal identification numbers of said one or more other transaction cards when said transaction processing is executed.

3. A method according to Claim 2, further comprising the step of:
if transaction processing of said one or more other transaction cards is related to withdrawal of cash, inputting personal identification numbers of said one or more other transaction cards when said transaction processing is executed.

4. A method according to claim 3, further comprising the steps of:
storing attribute information related to said transactor in said transaction card; and changing a selective screen for transactions depending upon said attribute information.

5. A method according to Claim 3, wherein said transactions include loan transactions from plural financial institutions, and wherein said method.further comprises the steps of:
when loan processing is selected, calculating a total loanable sum of plural transaction cards;
displaying said total loanable sum;
prompting said transactor to enter a sum to be loaned; and executing loan transaction processing by allocating the entered sum to plural financial institutions.

6. A method according to Claim 1, wherein said transactions include inquiry transactions from plural financial institutions, and wherein said method further comprises the steps of:
when said inquiry transaction is selected, merging attribute information and transaction information of said transaction card;
totalizing said attribute information held by said plural financial institutions; and displaying said totalized attribute information.

7. A method according to Claim 1, wherein said transactions include a payment of insurance transactions, and wherein said method further comprises the steps of:
when transaction of payment of insurance is selected, determining whether said payment of insurance is to be deposited in a bank; and when said payment of insurance is to be deposited in said bank, automatically opening an account of said bank.

8. A method according to Claim 7, further comprising the steps of:
when said bank account is opened, receiving information of an application entered by said transactor; and if signature or a seal by said transactor of another bank card or a credit card has been stored, executing a transaction processing for a new insurance contract based upon said signature or seal and a balance of said account of said transaction.

9. A method according to Claim 1, wherein said transactions include payment of insurance transactions, and wherein said method further comprises the step of:
if a balance of a bank account of said transaction is short of a required payment, executing transaction processing for obtaining a bank card loan or a credit card issued by a credit card issuance company.

10. A method according to Claim 1, wherein said transactions include cancellation transactions for cancelling insurance, and wherein said method further comprises the step of:
when cancellation transaction is selected and information for cancelling insurance is entered by said transactor, executing transaction processing for transferring a total insurance or repayment to a bank account of said transactor.

11. A transaction system for performing a transaction with plural institutions using plural transaction cards, said transaction system comprising:
a server;
a database connected to said server, said database stores attribute information of transactions which can be conducted by transactors with said institutions;
a plurality of transaction processors for permitting a transactor to perform transactions with said institutions using one or plural transaction cards; and a network which interconnects said server with said transaction processors, wherein each transaction processor receives a transaction card of a first transactor, inputs and then checks identification numbers corresponding to said first transaction card based on attribute information retrieved from said database by said server, displays a screen which includes a plurality of transaction keys based on attribute information retrieved by said server, permits said transactor to select a transaction key of a desired transaction, receives one or more other transaction cards required for said desired transaction, judges whether identification numbers corresponding to said one or more other transaction cards in accordance with said desired transaction are required to be entered based upon attribute information retrieved by said server from said database and executes transaction processing between one or more of said institutions based on attribute information retrieved by said server from said database and the input of identification numbers of said transaction card or the input of identification numbers of said one or more other transaction cards required to be entered.

12. A transaction system according to Claim 11, wherein said transaction processor, if transaction processing of said one or more other transaction cards is not related to withdrawal of cash, omits input of personal identification numbers of said one or more other transaction cards when said transaction processing is executed.

13. A transaction system according to Claim 12, wherein said transaction processor, if transaction processing of said one or more other transaction cards is related to withdrawal of cash, inputs personal identification numbers of said one or more other transaction cards when said transaction processing is executed.

14. A transaction system according to claim 13, wherein said transaction processor stores attribute information related to said transactor in said transaction card, and changes a selective screen for transactions depending upon said attribute information.

15. A transaction system according to Claim 13, wherein said transactions include loan transactions from plural financial institutions, and wherein said transaction processor, when loan processing is selected, calculates a total loanable sum of plural transaction cards, displays said total loanable sum, prompts said transactor to enter a sum to be loaned, and executes loan transaction processing by allocating the entered sum of plural financial institutions.

16. A transaction system according to Claim 11, wherein said transactions include inquiry transactions from plural financial institutions, and wherein said transaction processor, when said inquiry transaction is selected, merges attribute information and transaction information of said transaction card, totals said attribute information held by said plural financial institutions, and displays said totalized attribute information.

17. A transaction system according to Claim 11, wherein said transactions include a payment of insurance transactions, and wherein said transaction processor, when transaction of payment of insurance is selected, determines whether said payment of insurance is to be deposited in a bank, and when said payment of insurance is to be deposited in said bank, automatically opens an account of said bank.

18. A transaction system according to Claim 17, wherein said transaction processor, when said bank account is opened, receives information of an application entered by said transactor, and if signature or a seal by said transactor of another bank card or a credit card has been stored in said database, executes a transaction processing for a new insurance contract based upon said signature or seal and a balance of said account of said transaction.

19. A transaction system according to Claim 11, wherein said transactions include payment of insurance transactions, and wherein said transaction processor, if a balance of a bank account of said transaction is short of a required payment, executes transaction processing for obtaining a bank card loan or a credit card issued by a credit card issuance company.

20. A transaction system according to Claim 11, wherein said transactions include cancellation transactions for cancelling insurance, and wherein said transaction processor, when cancellation transferring is selected and information for cancelling insurance is entered by said transactor, executes transaction processing for transferring a total insurance or repayment to a bank account of said transactor.

21. A computer program stored on a storage medium for execution in a transaction system to cause said transaction system to perform a transaction with plural institutions using plural transaction cards, said computer program when executed in said transaction system causes said transaction system to perform the steps of:
receiving a first transaction card of a transactor;
inputting and then checking identification numbers corresponding to said first transaction card;
displaying a screen which includes a plurality of transaction keys related to said first transaction card;
permitting said transactor to select a transaction key of a desired transaction;
receiving one or more other transaction cards required for said desired transaction;
judging whether identification numbers corresponding to said one or more other transaction cards in accordance with said desired transaction selected in said permitting step are required to be entered; and executing transaction processing between one or more of said institutions based on the input of identification numbers of said transaction card or the input of identification numbers of said one or more other transaction cards required to be entered.

22. A computer program according to Claim 21, wherein said computer program when executed further causes said transaction system to perform the step of:
if transaction processing of said one or more other transaction cards is not related to withdrawal of cash, omitting input of personal identification numbers of said one or more other transaction cards when said transaction processing is executed.

23. A computer program according to Claim 22, wherein said computer program when executed further causes said transaction system to perform the step of:
if transaction processing of said one or more other transaction cards is related to withdrawal of cash, inputting personal identification numbers of said one or more other transaction cards when said transaction processing is executed.

24. A computer program according to claim 23, wherein said computer program when executed further causes said transaction system to perform the steps of:
storing attribute information related to said transactor in said transaction card; and changing a selective screen for transactions depending upon said attribute information.

25. A computer program according to Claim 23, wherein said transactions include loan transactions from plural financial institutions, and wherein said computer program when executed further causes said transaction system to perform the steps of:
when loan processing is selected, calculating a total loanable sum of plural transaction cards;
displaying said total loanable sum;
prompting said transactor to enter a sum to be loaned; and executing loan transaction processing by allocating the entered sum to plural financial institutions.

26. A computer program according to Claim 21, wherein said transactions include inquiry transactions from plural financial institutions, and wherein said computer program when executed further causes said transaction system to perform the steps of:
when said inquiry transaction is selected, merging attribute information and transaction information of said transaction card;
totalizing said attribute information held by said plural financial institutions; and displaying said totalized attribute information.

27. A computer program according to Claim 21, wherein said transactions include a payment of insurance transactions, and wherein said computer program when executed further causes said transaction system to perform the steps of:
when transaction of payment of insurance is selected, determining whether said payment of insurance is to be deposited in a bank; and when said payment of insurance is to be deposited in said bank, automatically opening an account of said bank.

28. A method according to Claim 27, wherein said computer program when executed further causes said transaction system to perform the steps of:
when said bank account is opened, receiving information of an application entered by said transactor; and if signature or a seal by said transactor of another bank card or a credit card has been stored, executing a transaction processing for a new insurance contract based upon said signature or seal and a balance of said account of said transaction.

29. A computer program according to Claim 21, wherein said transactions include payment of insurance transactions, and wherein said computer program when executed further causes said transaction system to perform the step of:
if a balance of a bank account of said transaction is short of a required payment, executing transaction processing for obtaining a bank card loan or a credit card issued by a credit card issuance company.

30. A computer program according to Claim 21, wherein said transactions include cancellation transactions for cancelling insurance, and wherein said computer program when executed further causes said transaction system to perform the step of:
when cancellation transaction is selected and information for cancelling insurance is entered by said transactor, executing transaction processing for transferring a total insurance or repayment to a bank account of said transactor.

31. A computer program according to Claim 21, wherein said transaction system comprises:
a server connected to a database which stores attribute information;
a plurality of transaction processors each transaction processor executes transaction processing with said institutions using one or more transaction cards based on input from a transactor and attribute information retrieved by said server from said database; and a network which interconnects said server and said transaction processors.

32. A computer program according to claim 31 wherein said computer program is executed by said server.

33. A computer program according to Claim 31, wherein said computer program is executed in each of said transaction processors.

34. A transaction processor for use in a transaction system for performing a transaction with plural institutions using plural transaction cards, said transaction system includes a server, a database connected to said server, said database stores attribute information of transactions which can be conducted by transactors with said institutions, a plurality of said transaction processors and a network which interconnects said server with said transaction processors, said transaction processor comprising:
a display;
a card reader;
an input apparatus; and a controller which controls said display, card reader and input apparatus such that said transaction processor receives a first transaction card of a transactor, inputs and then checks identification numbers corresponding to said first transaction card based on attribute information retrieved from said database by said server, displays a screen which includes a plurality of transaction keys based on attribute information retrieved by said server, permits said transactor to select a transaction key of a desired transaction, receives one or more other transaction cards required for said desired transaction, judges whether identification numbers corresponding to said one or more other transaction cards in accordance with said desired transaction are required to be entered based upon attribute information retrieved by said server from said database and executes transaction processing between one or more of said institutions based on attribute information retrieved by said server from said database and the input of identification numbers of said first transaction card or the input of identification numbers of said one or more other transaction cards required to be entered.

35. A transaction processor according to Claim 34, wherein said controller, if transaction processing of said one or more other transaction cards is not related to withdrawal of cash, omits input of personal identification numbers of said one or more other transaction cards when said transaction processing is executed.

36. A transaction processor according to Claim 35, wherein said controller, if transaction processing of said one or more other transaction cards is related to withdrawal of cash, inputs personal identification numbers of said one or more other transaction cards when said transaction processing is executed.

37. A transaction processor according to Claim 36, wherein said controller stores attribute information related to said transactor in said transaction card, and changes a selective screen for transactions depending upon said attribute information.

38. A transaction processor according to Claim 36, wherein said transactions include loan transactions from plural financial institutions, and wherein said controller, when loan processing is selected, calculates a total loanable sum of plural transaction cards, displays said total loanable sum, prompts said transactor to enter a sum to be loaned, and executes loan transaction processing by allocating the entered sum to plural financial institutions.

39. A transaction processor according to Claim 34, wherein said transactions include inquiry transactions from plural financial institutions, and wherein said controller, when said inquiry transaction is selected, merges attribute information and transaction information of said transaction card, totals said attribute information held by said plural financial institutions, and displays said totalized attribute information.

40. A transaction processor according to Claim 34, wherein said transactions include a payment of insurance transactions, and wherein said controller, when transaction of payment of insurance is selected, determines whether said payment of insurance is to be deposited in a bank, and when said payment of insurance is to be deposited in said bank, automatically opens an account of said bank.

41. A transaction processor according to Claim 40, wherein said controller, when said bank account is opened, receives information of an application entered by said transactor, and if signature or a seal by said transactor of another bank card or a credit card has been stored in said database, executes a transaction processing for a new insurance contract based upon said signature or seal and a balance of said account of said transaction.

42. A transaction processor according to Claim 34, wherein said transactions include payment of insurance transactions, and wherein said controller, if a balance of a bank account of said transaction is short of a required payment, executes transaction processing for obtaining a bank card loan or a credit card issued by a credit card issuance company.

43. A transaction processor according to Claim 34, wherein said transactions include cancellation transactions for cancelling insurance, and wherein said controller, when cancellation transaction is selected and information for cancelling insurance is entered by said transactor, executes transaction processing for transferring a total insurance or repayment to a bank account of said transactor.

44. A method according to Claim 1, wherein each transaction card comprises:
a magnetic stripe for storing attribute information of transactions which can be conducted by said transactor with said institutions;

a first integrated circuit (IC) chip for storing a record of electronic money in possession of said transactor;
and a second IC chip which stores a record of transactions conducted by said transactor with said institutions.

45. A transaction system according to Claim 11, wherein each transaction card comprises:
a magnetic stripe for storing attribute information of transactions which can be conducted by said transactor with said institutions;
a first integrated circuit (IC) chip for storing a record of electronic money in possession of said transactor;
and a second IC chip which stores a record of transactions conducted by said transactor with said institutions.

46. A computer program according to Claim 21, wherein each transaction card comprises:
a magnetic stripe for storing attribute information of transactions which can be conducted by said transactor with said institutions;
a first integrated circuit (IC) chip for storing a record of electronic money in possession of said transactor;
and a second IC chip which stores a record of transactions conducted by said transactor with said institutions.

47. A transaction processor according to Claim 34, wherein each transaction card comprises:
a magnetic stripe for storing attribute information of transactions which can be conducted by said transactor with said institutions;
a first integrated circuit (IC) chip for storing a record of electronic money in possession of said transactor;
and a second IC chip which stores a record of transactions conducted by said transactor with said institutions.