JP2007316775A - Address control system - Google Patents

Abstract

<P>PROBLEM TO BE SOLVED: To automate an application and registration of a resident card data to control surely and efficiently an address of each customer. <P>SOLUTION: An application server 14 extracts the customer of an object for the application, base on a prescribed extraction condition (S101), selects a public government office server 19 of an applied side for the resident card data (S102), and then prepares a resident card application data for applying the resident card data (S103). Then, a prescribed commission necessary for the application of the resident card data is transferred to a designated bank account (S104), a transfer number obtained in the transfer is added thereafter to the resident card application data, and transmits the resident card application data to the public government office server 19 (S105). The public government office server 19 processes the resident card application data (S106), and transmits a reply data for the application. The application server 14 receiving the reply data accesses a resident card database 12, using a customer identification code included in the reply data, and updates an attribute history database and the resident card database (S107, S108). <P>COPYRIGHT: (C)2008,JPO&INPIT

Description

  The present invention relates to an address management system, and more particularly to an address management system that manages addresses using resident card data.

  Financial institutions that provide personal loans manage customer information in a database. When sending important documents to customers, such as notice of overdue, each branch office uses the address information in the database. Sending process is done individually. However, if the customer has changed the address, even if the document is sent to the address registered in the database, the document may be returned due to unknown address, and the customer may not be able to receive the document. In such cases, efforts will be made to contact the customer by telephone or other means, but if contact cannot be made, a request will be made to the government office for a copy of the customer's resident's card and the current address of the customer being confirmed. It has been broken.

On the other hand, in recent years, the introduction of the Basic Resident Register Network (hereinafter referred to as “Juki Net”) has led to the introduction of IT in administrative systems. This allows a person who requests a copy of a resident's card to proceed from a nearby public office without having to go to the municipal office of the municipality in order to receive a copy of the resident's card. It has become. There is also a system for automatically issuing a certificate such as a copy of a resident's card (for example, see Patent Document 1). This type of system retrieves the resident card data of the person to be billed from the resident card book database, and prints and issues the resident card data in a predetermined format.
JP 2003-108694 A

  When a financial institution requests a copy of a resident's card, after extracting the customers to be billed for each branch, it communicates by post with each municipal office. When requested, not only does it take a lot of time and effort, but there is also a possibility that the mailing address may be wrong, leading to leakage of personal information. Another problem is that if the customer has changed his / her address many times, he / she has to request the same customer's resident card many times.

  On the other hand, according to the Juki Net, it is possible to request a copy of the customer's resident's card at any municipal office, but if the customer has never registered at the requested address Even if it is Juki Net, it is not possible to provide a copy of the resident card. In such a case, it is necessary to request a new copy of the resident's card at another address that the customer may have reported, so it is assumed that the Juki Net was built before reaching the current address. However, it will not change the time and effort.

  Therefore, an object of the present invention is to provide an address management system that can automate billing and registration of resident's card data and manage a customer's address reliably and efficiently.

  An object of the present invention is to provide an attribute history database for managing a history of attribute information including at least a customer's address, a resident card database for managing a history of customer resident card data, a government office server and a network holding resident card data A billing server that can be connected to the billing server, wherein the billing server creates the customer's resident card billing data using information in the attribute history database or the resident card database, and the attribute history database and the resident card. A resident's card claim data creation unit that includes a customer identification code used for management of the vote database in the resident card request data, and transmission / reception that transmits the resident card request data to the government server and receives response data from the government server And an address management system.

  In the present invention, it is preferable that the billing server specifies customer information in the attribute history database or the resident card database using the customer identification code included in the response data from the government office server. According to this, it becomes extremely easy to associate the received resident card data with the corresponding customer information in the database.

  In the present invention, the billing server further includes a transfer processing unit that performs a transfer process of a predetermined fee necessary for the request on the Internet prior to the request for the resident card data, It is preferable that a predetermined identification number necessary for confirming payment of the fee is included in the resident's card request data on the government office server side. According to this, payment of a fee required at the time of requesting resident's card data can be automatically performed in association with a series of request processing. In this case, it is preferable that the predetermined identification number is a transfer number received when the fee is transferred. When the transfer number is used, the transfer status can be confirmed on the government office server side without preparing other special data.

  In this invention, it is preferable that the said transmission / reception part transmits the electronic certificate issued from the certification authority with the said resident card claim data. According to this, the reliability of the resident card claim data can be ensured.

  According to the present invention, it is possible to provide an address management system capable of automating billing and registration of resident's card data and managing a customer's address reliably and efficiently.

  Hereinafter, preferred embodiments of the present invention will be described in detail with reference to the accompanying drawings.

  FIG. 1 is a schematic diagram showing a configuration of an address management system 10 according to a preferred embodiment of the present invention.

  As shown in FIG. 1, the address management system 10 includes an attribute history database 11 that manages the history of customer attribute information, a resident card database 12 that manages the history of customer resident card data, and information on government offices nationwide. A registered government office database 13, a billing server 14 for billing resident card data based on information in the attribute history database 11, resident card database 12, and government office database 13, and an operator terminal 15 connected to the billing server 14. I have. The billing server 14 is connected to the bank system 17, the certificate authority 18, and the government office server 19 via the Internet 16. The bank system 17 is a so-called Internet banking system that performs banking operations on the Internet. The certificate authority 18 is a third party on the Internet that issues an electronic certificate and proves that the communication partner is the principal (here, the financial institution X). The government office server 19 (19A to 19C) is a server that manages resident card data, and is configured in units of municipalities. These are connected to each other via the Juki network 20.

  FIG. 2 is a schematic diagram showing the configuration of the attribute history database 11.

  As shown in FIG. 2, a history of customer attribute information from the time of new registration to the present is registered in the attribute history database 11. Customer attribute information is managed on a per-customer basis using a “customer identification code”. The attribute information is mainly “registration date”, “customer identification code”, “name”, “birth date”. , “Sex”, “address”, “phone number”, “working information”, and the like. The attribute history database 11 also stores image data of basic contracts related to financing (hereinafter simply referred to as “contracts”). A copy of the resident's card and a family register tag are included in this contract. Contains a power of attorney that may be required if someone other than the person claims. In addition, attribute information is not limited to these, What kind of other information regarding a customer may be sufficient. In addition, when the name is changed due to marriage or the like, or when the address or telephone number is changed due to moving, the contents of the change are registered together with the date of change mainly by the declaration of the customer. Note that the information registered in the attribute history database 11 is based on the self-report of the customer in principle. For example, the address does not necessarily match the address registered in the resident card.

  FIG. 3 is a schematic diagram showing the configuration of the resident card database 12.

  As shown in FIG. 3, the contents of the resident's card data of the customer acquired from the time of new registration to the present are registered in the resident card database 12. In addition, when the resident's card is requested but the final place of residence cannot be confirmed by the removal of the vote, the fact is registered in the resident card database 12. Resident card data is managed on a customer-by-customer basis using a “customer identification code”. Resident card data mainly includes “billing date”, “name”, “address”, “scheduled address” However, the present invention is not limited to these. Resident card data is only requested when it is necessary, such as when the residence is unknown, so the resident certificate data for all customers does not necessarily exist. Sometimes not.

  FIG. 4 is a schematic diagram illustrating an example of the configuration of the government office database 13.

  As shown in FIG. 4, the government office database 13 has jurisdiction over “prefecture name” 41, “city name” 42, “address code” 43 allocated to municipalities nationwide, and each municipality. The address information (“office server address”) 44 of the government office server 19 and “official office request data” 45 required at the time of requesting a resident's card at each government office are registered.

  FIG. 5 is a block diagram functionally showing the configuration of the billing server 14.

  As shown in FIG. 5, the billing server 14 stores information on the customer extraction unit 51 that extracts customers for which resident card data is to be charged based on predetermined extraction conditions, and the attribute history database 11 and the resident card database 12. A resident's card claim data creation unit 52 that creates customer resident's card claim data, and a transfer processing unit that performs a transfer process of a predetermined fee necessary for the resident card data request on the Internet prior to requesting the resident card data. 53, a transmission / reception unit 54 for transmitting resident's card request data and the like to the government office server 19 and receiving response data from the government server 19, a determination unit 55 for processing the response data and making various determinations, and a response And a recording unit 56 that records data contents in the attribute history database 11 and the resident card database 12. The determination unit 55 determines whether or not the address of the answer data is different from the address of the resident's card claim data, and determines whether or not the answer data has a planned transfer address. Judgment processing is performed. Note that the illustrated units do not have to be physically separate components, and may be functions achieved by a computer executing a program.

  In the above-described document sending operation to the customer, the latest address (current address) of the customer recorded in the attribute history database 11 is used. However, if the current address needs to be confirmed for some reason, A charge is made. “Residence card data” is electronic data corresponding to a “copy of a resident card” issued in writing at a public office window. In the present invention, the “resident's card” is a concept including not only a resident's card registered at a government office but also other documents registered at a government office such as a family register tag. Hereinafter, the procedure for requesting resident card data will be described in detail with reference to the flowchart of FIG.

  When billing resident's card data, the billing server 14 first extracts a customer to be billed based on a predetermined extraction condition (S101). As an extraction condition, for example, a case where a certain period of time has passed since the date when the whereabouts of the customer was found out can be cited. If the customer's location is unknown, such as when a mailing document is returned with an unknown address, the fact is registered in the attribute history database 11, and the billing server 14 monitors the deadline based on that information. The person to be billed is extracted. In addition, when a certain period has elapsed from the date of billing of the latest resident card data (Y-th billing in FIG. 3) registered in the resident card database 12, the billing result of the resident card data may be used as an extraction condition. Furthermore, the customer's current address can be used as an extraction condition. For example, for a customer whose resident card data that was previously billed indicates a move-out schedule and whose address is “Chiyoda-ku, Tokyo”, the case where a certain period has passed since the last billing date of the resident card data It is also possible to extract as In addition, when this system is used for customer receivables management, a receivable management server (not shown) is prepared separately from the billing server 14, and the receivable management server monitors the customer receivable status, and the arrears have passed for a certain period of time. It is also possible to extract the customer who has been billed or whose billing balance exceeds a certain amount as the subject of resident card billing and request the billing server 14 to start the billing process for the resident card data.

  Next, the billing server 14 selects the government office server 19 to be billed for the resident card data (S102). The government office database 13 is used for selecting the government office server 19, and the government office server address is determined based on the customer's current address shown in the attribute history database 11.

  Next, the billing server 14 creates resident card billing data for billing the resident card data (S103). The resident card request data is electronic data corresponding to the “invoice for a copy of the resident card” submitted in writing at the government office window. As shown in FIG. 7, the resident card request data has a predetermined format requested by the government office server 19. “Billing data No.” 71, “Transfer number” 72, “Name” 73, “Birth date” 74, “Address” 75, “Office request data” 76, “Request format (single slip / history)” "77", "customer identification code" 78, and the like are included. “Office request data” 76 is data requested from the government office server at the time of requesting resident's card data, and specifically, is image data of a contract regarding the request for resident's card data. However, depending on the billing destination, it may not be necessary, so in that case it is blank. In the resident card claim data, a data area (user area) that can be freely used by the user is secured, and the “customer identification code” 78 is recorded in such an area. The “transfer number” 72 is replenished after the transfer process described later is completed.

  Next, the billing server 14 accesses the bank system 17 prior to billing for the resident card data, and transfers a predetermined fee required for billing the resident card data to the designated bank account (S104). At this time, the billing server 14 receives a notification of the transfer number from the bank system 17, but the transfer number is added to the resident's card billing data and used for confirming the transfer status described later.

  Next, the billing server 14 transmits resident card billing data (S105). The resident card claim data is transmitted to the government office server 19 having jurisdiction (for example, the government office server 19A) together with the electronic certificate issued by the certificate authority 18.

  Next, the government office server 19 that has received the resident card claim data processes the resident card claim data (S106), and transmits response data for the request.

  FIG. 8 is a flowchart showing a processing procedure by the government office server 19.

  As shown in FIG. 8, the government office server 19 first refers to the certificate authority 18 for the electronic certificate included in the resident's card claim data, and confirms the validity of the electronic certificate and whether it is the financial institution X. (S201). When the electronic certificate is valid and the financial institution of the billing source matches the financial institution of the electronic certificate (S202Y), the government office server 19 uses the “transfer number” 72 indicated in the resident's card claim data as a fee. The transfer status is confirmed (S203). When the transfer of the predetermined fee can be confirmed (S204Y), the government office server 19 confirms the presence or absence of the government office request data only when the government office request data is requested (S205Y, S206). When the government office request data is not required (S205N) or when the government office request data is attached (S207Y), the government office server 19 searches for the customer's resident card. The vote data is created (S208Y, 209).

  On the other hand, when the electronic certificate is not valid, or when the financial institution of the electronic certificate is different from the financial institution that requested the bill (S202N), payment of a predetermined fee cannot be confirmed (S204N), and necessary government office request data Is not attached (S207N), the government office server 19 creates each error code as answer data (S212, S213, S214). If there is no corresponding resident card, the government office server 19 creates response data indicating that (S208N, S215).

  After that, the government office server 19 adds the “customer identification code” 78 included in the resident card billing data to the reply data, and then sends the reply data to the billing server 14 (S210, S211).

  The billing server 14 that has received the response data updates the database based on the content of the response data (S107, S108).

  FIG. 9 is a flowchart showing a processing procedure when resident card data is received as answer data.

  As shown in FIG. 9, the billing server 14 accesses the resident card database 12 using the customer identification code included in the answer data (S301), and records the answer data in the resident card database 12 (S302). Next, the billing server 14 confirms the contents of the answer data (S303), and if the answer data is resident card data and does not indicate a vote (S304Y, S305N), the customer identification code is used. The attribute history database 11 is accessed (S306), and the address of the resident card data is compared with the current address of the attribute history database 11 (S307). If the two do not match (S308N), a change confirmation screen for requesting permission to change the address in the attribute history database 11 is displayed on the display of the operator terminal 15 (S309). As shown in FIG. 10, the change confirmation screen includes “current address of attribute history database” 81, “address of resident card data” 82, “change” button 83, and “cancel” button 84, and “change” button 83 Is clicked (S310), the billing server 14 replaces the current address in the attribute history database 11 with the address of the resident card data, and records the current address so far as a past address (S311).

  On the other hand, when the answer data indicates a removal slip (S304Y, S305Y, S312Y), the billing server 14 creates new resident's card claim data based on the move-to address indicated in the answer data, and moves to The resident's card data is reclaimed to the government office server 19 (for example, the government office server 19B) having jurisdiction over the address (S313). The re-billing procedure is substantially the same as that shown in step S103 and subsequent steps in FIG.

  As described above, according to the present embodiment, the billing server 14 extracts customers to be billed under a certain condition, and then selects a government office server 19 as a billing destination. The resident card request data is sent to the branch office, so it is possible to carry out a batch copy of the resident card, which was conventionally done individually at each branch, and greatly reduce the work burden at each branch. it can. In addition, it is possible to automate the process of requesting a copy of a resident's card that was manually mailed to each branch, greatly reducing the time it takes to obtain a copy of a resident's card after it is requested. . In addition, it is possible to avoid mistakes in enclosing and sending mistakes when issuing a resident's card at the government office, and input mistakes when digitizing the contents of a copy of the resident's card issued in writing, thereby leaking customer information. It can also be prevented. Therefore, billing and registration of resident card data can be automated, and customer addresses can be managed reliably and efficiently.

  Further, according to the present embodiment, when the payment confirmation is obtained by including the transfer number in the resident certificate request data, the resident certificate data is distributed online from the government office server 19, so when the resident certificate data is requested. Payment of necessary fees can be performed automatically in conjunction with a series of billing processes. In particular, when the transfer number is used as a predetermined identification number necessary for confirming payment of the fee, the transfer status can be confirmed on the government office server side without preparing other special data.

  Further, according to the present embodiment, the electronic certificate is further included in the resident's card claim data, the electronic certificate is valid, the financial institution of the requesting source matches the financial institution of the electronic certification, and payment confirmation is obtained. In such a case, since the resident card data is distributed online from the government office server 19, illegal billing of the resident card data can be reliably prevented.

  In addition, according to the present embodiment, the customer identification code is transmitted including the customer identification code in the resident card request data, and the customer server 19 side returns this customer identification code in the response data. Can be used to uniquely identify the contents of the attribute history database and resident card database, and address registration, confirmation, updating, etc. can be easily performed.

  The present invention is not limited to the above embodiments, and various modifications can be made without departing from the spirit of the present invention, and these are also included in the scope of the present invention. Needless to say.

  For example, in the above embodiment, the case where the customer identification code is included in the resident card claim data has been described. However, the present invention is not limited to such a case, and the customer identification code is not included in the resident card claim data. It is also possible to do so. In this case, after retrieving the customer identification code from “name”, “address” and “birth date” of the answer data, the attribute information of the customer can be specified.

  In the above embodiment, when the resident's card claim data does not include government request data such as a contract, the government office server 19 immediately transmits an error code as response data. In addition, the government office server 19 may send a notification of necessity of the government office request data to the billing server 14. In this case, the billing server 14 that has received the necessary notification of the office request data returns the office request data to the office server 19 within a certain period, whereby the subsequent processing by the office server 19 is advanced and response data is transmitted. . Further, the billing server 14 that has received the necessary notification of the government office request data may automatically update the content of the “office office request data” 45 included in the resident card database 12. In this way, since the registration of the government office request data is always in the latest state, it is possible to reliably prevent inadequate transmission of the government office request data in the subsequent processing.

  In the above embodiment, the image data of the contract regarding the resident's card request is given as an example of the government office request data required at the time of requesting the resident's card data. However, the customer balance data indicating the borrowing status to the financial institution. It may be. This makes it easier to prove the purpose of requesting resident card data.

  In the above embodiment, as shown in steps S307 to S311 of FIG. 9 and FIG. 10, the received address of the resident's card data is compared with the current address of the attribute history database. A change confirmation screen is displayed on the terminal 15, and the attribute history database is rewritten when there is a change instruction on the change confirmation screen, but steps S309 to S310 are omitted, and the address of the resident card data and the attribute history database If the current address does not match, the attribute history database may be automatically updated using the address of the resident card data.

FIG. 1 is a schematic diagram showing a configuration of an address management system 10 according to a preferred embodiment of the present invention. FIG. 2 is a schematic diagram showing the configuration of the attribute history database 11. FIG. 3 is a schematic diagram showing the configuration of the resident card database 12. FIG. 4 is a schematic diagram showing the configuration of the government office database 13. FIG. 5 is a block diagram functionally showing the configuration of the billing server 14. FIG. 6 is a part of a flowchart showing in detail an example of a billing procedure for resident card data by the address management system 10. FIG. 7 is a diagram showing the configuration of the resident card claim data. FIG. 8 is a flowchart showing a processing procedure by the government office server 19. FIG. 9 is a flowchart showing a processing procedure when resident card data is received as answer data. FIG. 10 is a diagram illustrating a configuration of a change confirmation screen displayed on the display of the operator terminal 15.

Explanation of symbols

DESCRIPTION OF SYMBOLS 10 Address management system 11 Attribute history database 12 Resident card database 13 Government database 14 Billing server 15 Operator terminal 16 Internet 17 Banking system 18 Certification authority 19 Government server 19A-19C Government server 20 Juki net 41 "Prefectural name" data 42 ""Cityname" Data 43 "Address code"
44 "Office server address"
45 "Office request data"
51 Customer Extraction Unit 52 Resident Card Request Data Creation Unit 53 Transfer Processing Unit 54 Transmission / Reception Unit 55 Determination Unit 56 Recording Unit 71 “Billing Data No.” Data 72 “Transfer Number” Data 73 “Name” Data 74 “Birth Date” Data 75 “Address” data 76 “Office request data”
77 “Request format (single slip / history)” data 78 “Customer identification code”
80 Change Confirmation Screen 81 Current Address in Attribute History Database 82 Address in Resident Card Data 83 “Change” Button 84 “Cancel” Button

Claims (5)

An attribute history database that manages the history of attribute information including at least the customer's address;
Resident card database that manages the history of customer resident card data,
A government office server that holds resident's card data and a billing server that can be connected via a network,
The billing server
Using the information in the attribute history database or the resident card database, the resident card request data of the customer is created, and a customer identification code used for managing the attribute history database and the resident card database is included in the resident card request data Resident card claim data creation department,
An address management system comprising: a transmission / reception unit that transmits the resident card claim data to the government office server and receives response data from the government office server.   The said claim server specifies the customer information in the said attribute history database or the said resident's card database using the said customer identification code contained in the reply data from the said government office server, The claim 1 characterized by the above-mentioned. Address management system. The billing server further includes a transfer processing unit that performs a transfer process of a predetermined fee required for the bill on the Internet prior to billing the resident card data,
The address management system according to claim 1, wherein the resident card claim data creation unit includes a predetermined identification number required for payment confirmation on the government office server side in the resident card claim data.   The address management system according to claim 3, wherein the predetermined identification number is a transfer number received at the time of transfer of the fee. The address management system according to claim 3 or 4, wherein the transmission / reception unit transmits an electronic certificate issued by a certificate authority together with the resident card request data.

Images