JP2001195309A - Security management system and program recording medium therefor - Google Patents

Abstract

PROBLEM TO BE SOLVED: To take the countermeasure of not providing information more than needed even for a proper terminal corresponding to the card and to surely prevent the leakage of important information inside a data storage medium due to loss, robbery and malice, etc., by not writing a master DB to be an origin as it is but preparing and writing a mobile DB composed of only a record group segmented from the master DB. SOLUTION: A server device 1 makes a DB card 3 and portable terminal equipment 2 capable of accessing it correspond altogether other than the write of a data file to the card, then prepares the mobile DB composed of only the record group segmented from the master DB and writes it to the card. The portable terminal equipment 2 permits access to the mobile DB at the time of a proper card by the correspondence of the terminal and the card.

Description

DETAILED DESCRIPTION OF THE INVENTION

[0001]

[0001] 1. Field of the Invention [0002] The present invention relates to a security management method in which security measures are taken when a portable terminal device accesses a portable data storage medium, and a program recording medium therefor.

[0002]

2. Description of the Related Art In recent years, portable storage media such as compact disks and memory cards have been increasing in capacity and miniaturization, and by storing a large amount of databases in the portable storage media, various databases can be freely carried. It is becoming possible to do it. Here, when the salesperson brings the portable terminal device and performs daily sales activities, the portable terminal device has a small capacity of its built-in memory, and therefore, a part or all of the database for various business processes is used. It is stored in a portable storage medium. here,
The sales representative can attach the portable storage medium to the terminal body, access the stored contents on the go, display and output it,
The data is updated. In this case, as a security measure when the portable data storage medium is accessed by the portable terminal device, the input password is used to authenticate a valid terminal user.

[0003]

[0006] By the way, even in a portable terminal device originally intended as a personal dedicated machine, in addition to regular employees,
Temporary employees, part-time workers, and part-time workers are also increasingly using them. In addition, there is a risk that a portable storage medium or the portable terminal device itself may be lost or stolen in a place where the portable terminal device is to be carried out for use. Therefore, if sensitive and important corporate information or personal information is stored in the portable storage medium or the internal memory of the terminal, the important information may be leaked to others due to loss, theft, or malice. It was extremely expensive. That is, in the related art, since the mobile terminal device is mainly used on the go, the operation environment such as simplicity and speed of operation is more important than the strict security management that complicates the input operation. As a result, security measures for temporary storage and security measures against loss or theft of portable storage media and portable terminal devices,
The security measures against malice by parts are not enough. Anyone can easily access the data in the portable terminal or the storage medium from any personal computer by knowing the user password or by accidental hit of the password. The risk that important information could be leaked to others was extremely high. In addition, providing the mobile terminal device itself with a mechanism for arbitrarily taking security measures according to the user setting is, on the contrary, the third terminal.
This involves the danger that the setting part can be easily changed by the user, and the mechanism itself becomes a factor that impairs the security. An object of the present invention is to write a data file on a data storage medium and to cope with the data storage medium and a portable terminal device capable of accessing the data storage medium, in order to ensure security management for a portable data storage medium. The server device can collectively attach the media to the media by creating and writing a mobile data file consisting of only the records cut out from the master database instead of writing the original master database as it is. Measures to prevent unnecessary information from being provided to authorized terminals, and to ensure that leakage of important information in data storage media due to loss, theft, or malicious intent is prevented. It is.

[0004] The means of the present invention are as follows. According to a first aspect of the present invention, there is provided a portable terminal device, and a server device for writing and distributing a data file to a portable data storage medium used by the portable terminal device. A mobile data creation unit for creating a mobile data file from the master data file, and a mobile data creation unit for creating a mobile data file from the cut record group. Writing means for writing the mobile data file created by the creating means, wherein the portable terminal device determines whether the data storage medium set therein is a valid medium associated with the terminal. If the determination means determines that the medium is compatible with the terminal, the data Those comprising an access control means for granting access to mobile data files in the storage medium. The present invention may be as follows. (1) The mobile data creation means, when extracting a record group used in the mobile terminal device from the master data file, uses a record extraction condition set in advance according to the processing content on the mobile terminal device side. Reference is made and a record group that meets this record extraction condition is cut out. (2) When the mobile data creation unit creates a mobile data file by cutting out a record group used in the mobile terminal device from a master data file, the mobile data creation unit is preset in accordance with the processing contents on the mobile terminal device side. A mobile data file having a record configuration including only fields that match the conditions of the extraction target field is created with reference to the extracted extraction target field. (3) The mobile data creation means obtains identification information set in a data storage medium to be written when a record group used in the mobile terminal device is cut out from a master data file, The master data file is determined based on the master data file, and a cut-out condition for cutting out a record group from the master data file is determined, and a record group is cut out from the determined master data file according to the cut-out condition. (4) The server device that writes and distributes the mobile data file to the data storage medium used by the mobile terminal device is configured such that application software for processing the mobile data file stores the mobile data file in the data storage medium in association with the mobile data file. A determination means for determining whether the application data is stored is provided. If the determination means determines that the application software is not stored, application software for processing the application data in association with the mobile data file is provided. Write in the data storage medium. (5) When the application software is stored in the data storage medium in association with the mobile data file, the application determination means determines whether the application software is the latest one, and the latest application is determined by the determination means. An application updating means for rewriting the application software stored in association with the mobile data file in the data storage medium to the latest application software when it is determined that the software is not software is provided. Therefore, in the first aspect of the present invention, in order to ensure security management for the portable data storage medium, in addition to writing the data file to the data storage medium, the data storage medium and the data storage medium can be accessed. The server device can collectively associate with the mobile terminal device, and instead of writing the original master database as it is, create and write a mobile data file consisting of only a group of records cut out from the master database. By doing so, it is possible to take measures to prevent providing unnecessary information to legitimate terminals compatible with the medium, and to ensure that important information in the data storage medium is leaked due to loss, theft, malicious intent, etc. Can be prevented.

[0005]

DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS An embodiment of the present invention will be described below with reference to FIGS. FIG. 1 is a block diagram showing the overall configuration of the security management system according to this embodiment. This security management system
For example, a server device 1 installed on the company side in a company organization, a mobile type client terminal (portable terminal device) 2 brought by each sales representative, and the server device 1 may be used by being set on the mobile terminal device 2. And a portable storage medium 3. The application software / database stored and managed by the server device 1 is externally provided to the portable terminal device 2 via a portable storage medium 3 which is portable. When writing and distributing to the terminal device, the server device 1 sets information for associating the terminal with the storage medium, and takes various security measures, so that the application software / database or the like in the storage medium 3 can be stored. Is reliably prevented from being illegally copied by a third party or information is leaked.

[0006] Each salesperson performs business activities while accessing the application software / database in the portable storage medium 3 on the go, and at the end of the business day, the portable storage medium 3 is accessed from the terminal body. And extract
When this is set in the card reader / writer 4 of the server device 1, the server device 1 collects the business records in the storage medium 3 via the card reader / writer 4. Then, the server device 1 and the plurality of mobile terminal devices 2
Can be detachably connected via the serial cable 5.

The portable storage medium 3 stores application software for various business processes, a database, and the like, and is constituted by, for example, a compact flash card. Hereinafter, the portable storage medium 3 is referred to as a mobile database card (DB card). Where
“#A”, “#B”, “#C”,
‥‥ indicates that the card is a terminal-compatible card associated with the mobile terminal device 2 indicated by the terminal names “A”, “B”, “C”, and ‥‥. In this embodiment, there is a terminal group compatible card, which will be described later, in addition to a terminal compatible card. However, in the example of FIG. 1, only a terminal compatible card is shown. The card reader / writer 4 can simultaneously set a plurality of DB cards 3 and has a plurality of card insertion ports. Then, the server device 1 sends the application software / database file (AP software / DB file) to the portable terminal device 2 via the DB card 3.
Distribute. In other words, the server device 1 writes the DB software in the DB card 3, that is, the distribution target AP software / D
The B file is called and given to the card reader / writer 4, and the AP software / DB file is written to one or more DB cards 3 set therein.

FIG. 2 shows, for example, a business group “Sales 1
Section, "Sales Section 2", "Project A", "Project B", and the relationship between the terminal group corresponding to the @ and the DB card 3 corresponding to the terminal group, and the correspondence between the terminal and the user. It shows the relationship. That is, in the figure, the DB cards 3 indicated by “# A1”, “# A2”, and “# A3” have terminal names “A1”, “A2”,
"A3" is a storage medium corresponding to the terminal group A to which each portable terminal device 2 belongs. Similarly, "# B1", "#B
2 "カ ー ド, each terminal name is" B "
1 ”,“ B2 ”, and ‥‥ are storage media corresponding to the terminal group B to which each of the mobile terminal devices 2 belongs, and each DB card 3 in the same group is commonly used by each of the mobile terminal devices 2 in the group. It can be used.

[0009] Further, the number of users who have authority to use a certain portable terminal is not limited to one, and a plurality of users can share and use one portable terminal device.
In addition, a certain user has authority to use a plurality of mobile terminal devices. For example, terminal group A
, The correspondence between the mobile terminal device indicated by the terminal name “A1” and the users “UA1” to “UA4” is defined, and the mobile terminal device indicated by the terminal name “A2” and the user “UA1” .. "UA3" are defined, indicating that there is a usage relationship only between them. In this case, authentication information (password) is set in each DB card corresponding to a terminal that can be shared and used by a plurality of users, corresponding to each user that can be shared.

FIG. 3 is a diagram conceptually showing a multiple security management mechanism which is a feature of this embodiment. This multiple security management is based on the fact that the
This shows security processing when accessing the B card or when the DB card 3 is accessed by an arbitrary terminal device. This multiple security is roughly classified into four security layers. That is, this multiple security management mechanism includes a first security layer (DB card security), a second security layer (password authentication), a third security layer (soft security), and a fourth security layer (database multiple encryption). ).

The first security layer (DB card security) is used when the portable terminal device 2 accesses an arbitrary DB card or when the DB card 3 is accessed by an arbitrary terminal device. This is a check process of collating the first identification information (hard identification number described later) stored therein and determining whether or not access to the card itself is possible based on the collation result. This check process is started when the power of the terminal is turned on, by activating basic software stored in the card.

Here, the "hardware identification number" is written in advance in the portable terminal device 2 or the DB card 3 in order to associate the portable terminal device 2 with the DB card 3. In other words, when the server device 1 sets in advance the contents to be written in the mobile terminal device 2 or the DB card 3 in a table, the “hard identification number” is set to one of the mobile terminal devices 2 belonging to the same group. The server device 1 is generated according to the unique terminal identification information (serial number) read from one of the terminals, and is stored in each portable terminal device 2 corresponding to the group and in each DB card 3 used in those terminals. And a hardware identification number. Therefore,
In each portable terminal device 2 and each DB card 3 belonging to the same group, the same hardware identification number is written as common access restriction information.

Second security layer (password authentication)
Is a check process for collating whether the operator is a valid operator based on the input user authentication information (password) when access to the card itself is permitted as a result of the above DB card security check. In this case, an encrypted password is used for collation. That is, the encrypted password is obtained by encrypting the input password by a predetermined method, and is written in each DB card 3 corresponding to the terminal as user-specific authentication information. In this case, if there are a plurality of users who have been given access authority to the terminal, the encryption password is written for each user.

In the second security layer, when a user password is entered when the DB card 3 is used and an incorrect password is entered repeatedly and repeatedly several times, the repetition is repeated. When it is determined that the number of times of input has reached a preset limit value (a set number of times of inactive viewer described later), the search viewer (initial screen display such as a display prompting for password input) is disabled thereafter. By doing so, a security process of not accepting a password input is also performed.

The third security layer (soft security) is used when the portable terminal device 2 accesses an arbitrary DB card or when the DB card 3 is accessed by an arbitrary terminal device. This is a check process of collating stored second identification information (software identification numbers to be described later) and determining whether or not access to a database (mobile DB) in the card is possible based on the collation result. This “software identification number” is written in advance in the portable terminal device 2 or the DB card 3 in order to associate the database in the DB card 3 with the portable terminal device 2 that can use the database. In other words, when the server device 1 sets in advance the contents to be written in the portable terminal device 2 or the DB card 3 in a table, the “software identification number” is one of the portable terminal devices 2 belonging to the same group. The server device 1 is generated according to the unique terminal identification information (serial number) read from one terminal, its group name, and a predetermined master DB name. The software identification number is written in each DB card 3 associated with the terminal.

[0016] The fourth security layer (database multiple encryption) allows a third party to access the DB card even if the DB card is lost or stolen. And security measures for preventing the database in the DB card from being decrypted by multiple encryption. Here, when writing and distributing the database to the DB card 3, the server apparatus 1 does not write the master database associated with the distribution destination group to the card as it is, but instead writes the master database from the master database to the business contents of the group. In accordance with this, only the necessary data contents are cut out, and a database (mobile DB) corresponding to the group consisting of the cut out data is created. At this time, file management information of the created mobile DB, that is, of each file, FAT (File / Allocation / Tabl) indicating storage location
e) is scrambled (encrypted). The FAT scrambling process is performed using an encryption key (scramble key) arbitrarily generated for the scrambling process, and the scrambling process may be performed in any manner. Further, when writing the mobile DB in the DB card 3, the server device 1 individually encrypts each record of the mobile DB for each record and each field by using a record encryption key arbitrarily generated. . Thus, the mobile DB is multiply encrypted and written in the DB card.

FIG. 4A shows a setting table 11 provided on the server device 1 side. The setting table 11 indicates that the server device 1 has the DB card 3 or the portable terminal device 2
In this embodiment, the server device 1 collectively writes the data to the DB card 3 instead of having the mobile terminal device 2 write the data. I have to. Setting table 1
Reference numeral 1 denotes a configuration having various setting areas for each terminal group such as the groups “Sales 1 Section”, “Sales 2 Section”, “Project A”, “Project B”, and ‥‥. The content set in the setting area for each group is written in each portable terminal device 2 and each DB card 3 corresponding to the group. FIG. 4A shows “Sales Section 1”, “Sales Section 2”, and “Sales Section 1” as terminal groups.
Is shown as an example. First, in addition to the “group name” in the setting area corresponding to each group, the above “hard identification number”, the total “set number” of terminals belonging to the same group, the “terminal name (1), Name (2), @ ", and the total number of users who have the authority to use the terminal in the same group are set respectively.

Further, the "viewer non-operation set number (N)" set for each group is such that the search viewer is deactivated after the password is repeatedly input incorrectly several times. Therefore, the number of times is set arbitrarily for each group. Further, “user name (1)”, “password”, “user name (2)”, and ‥‥ are set in association with each user who has use authority. In addition, the above-described “scramble key (S
K) and a “record encryption key (RK)” are set.

Also, in association with each database to be written, its “mobile BD name (1)”, “master DB name”, “record extraction condition”, “extraction target field”, “mobile BD name (2) ) "‥‥ is set. The “master DB name” is, as shown in FIG.
Among the plurality of master DB files 12 stored and managed on the server device side, the master DB file 12 designates a master DB required according to the business content of the group and the like.
The “record extraction condition” and “extraction target field” are conditions for mobile BD creation used when creating a group-compatible mobile BD by modifying and changing the master DB according to the business content of the group. Is defined. That is, the “record extraction condition” indicates an extraction condition for extracting a desired record group from this master DB, and the “extraction target field” is used to change the extracted record group to a record configuration including only desired fields. The field extraction condition is shown. By setting the “record extraction condition” and “extraction target field” for each master BD, a unique mobile BD that matches the business content of the group and the processing content of each mobile terminal is created.

[Customized A] in association with “Mobile DB name (1)”, “Mobile DB name (2)”
P (1) "," customized AP (2) "}. This “customized AP” is application software for processing the above-mentioned mobile BD,
The display form of the basic AP 13 (see FIG. 4C) corresponding to the master DB is modified and changed according to the mobile BD. The “corresponding customized AP” includes the “software identification number”, “update date”, “corresponding mobile DB” described above.
Name "is set. In this case, the “software identification number” is commonly set for each “customized AP” in the same group, but the “update date” differs depending on the date when the basic AP is modified and changed. Note that only the AP name may be set in the “customized AP” setting area. In this case, the customization A
P itself is stored in a separate file, and the setting table 11
Alternatively, the application software itself may be called according to the corresponding customized AP name.

On the other hand, in the setting table 11, "basic software" is set in an area different from the group corresponding setting area as a common writing target to be written in each DB card common to each group. Here, “basic software” includes “search viewer”, “FAT scramble / descrambling algorithm”, “encryption / decryption algorithm”,
The configuration includes the “operation control management file”.
“Basic software” is basic software for controlling the execution of basic operations of the mobile terminal device, and “search viewer” is software for displaying an initial screen (login input screen) according to the operation of the basic software. . The “operation control management file” is a file in which basic management information for controlling the operation of the DB-compatible customization AP is stored. This "operation control management file" is usually written in the card, but in this embodiment, if the password is incorrectly repeated several times in succession, the search viewer is disabled thereafter. Therefore, the “operation control management file” is deleted, and when the search viewer is started, the mobile terminal device displays the login input screen on condition that the “operation control management file” exists in the DB card. Is displayed.

FIG. 5 shows the contents written to each DB card 3 by the server device. That is, the DB card includes “hard identification number”, “FAT (scrambled)”, “basic software”, “search viewer”, “F
"AT scramble / de-scramble algorithm", "encryption / decryption algorithm", "operation control management file", and "viewer non-operation set number" are written. "FAT
"(Scrambled)" is management information for managing each mobile DB in the DB card, and is written as it is after the scrambled content. Further, “user name (1)”, “encrypted password + time variable key”, “user name (2)”} are written for each user who can use the DB card, and “ Record encryption key (RK) "is written. Also,
"Mobile DB name (1)" and its actual data "DB
(Encrypted) "," mobile DB name (2) "}, and further," customized AP (1) "," software identification number "," update date ",
"Supported mobile DB name", "Customized AP (2)"
‥‥ is written.

FIG. 6 shows the contents written in the built-in memory of each portable terminal device 2. This internal memory includes
As shown, a flash ROM and a RAM (temporary storage memory) are provided. The ROM and RAM are configured to have a minimum necessary memory capacity in consideration of security measures. That is, in this embodiment, as described above, the application, the database,
The storage location of the basic software and the like is not distributed between the mobile terminal device 2 and the DB card 3, but the basic software is written in the DB card 3 in addition to the application and the database. Risks can be eliminated. Here, the above-described “hardware identification number”, “software identification number”, and “scramble key (SK)” are fixedly stored in the flash ROM in the terminal by the writing operation of the server device 1. The RAM, which is a temporary storage memory, has a “key / data input area”, a “FAT read area”, a “record area”, and an “other work area”. Note that the "record area" is the minimum necessary data, that is, in order not to leave data in the terminal,
The configuration is such that data for one record is temporarily stored as the current data currently being processed. Although not shown,
In the internal memory of each portable terminal device 2, a serial number unique to the terminal in which it is manufactured is also fixedly stored.

FIG. 7 is a block diagram showing the overall configuration of the server device 1 and the portable terminal device 2. Here, basically the same components as the server device 1 and the mobile terminal device 2 are assigned the same reference numerals and the description is also used, but the components of the server device 1 and the mobile terminal device 2 are identified. To do so, the components of the server device 1 are denoted by “A” in the figure,
Hereinafter, only the configuration of the mobile terminal device 2 will be described, and description of the server device 1 will be omitted. The CPU 21 is a central processing unit that controls the overall operation of the portable terminal device 2 according to an operating system and various application software in the storage device 22. Storage device 22
Has a recording medium 23 storing a database, character fonts, and the like in addition to an operating system and various application software, and includes a magnetic, optical, semiconductor memory, and the like, and a drive system thereof. The recording medium 23 is a fixed medium such as a hard disk or a portable medium such as a CD-ROM, a floppy desk, a RAM card, and a magnetic card which can be removably mounted. The programs and data in the recording medium 23 are loaded into a RAM (for example, a static RAM) 24 under the control of the CPU 21 as necessary,
The data in 24 is saved in the recording medium 23. Furthermore,
The recording medium may be provided on an external device such as a server, and the CPU 21 may directly access and use the program / data in the recording medium via a transmission medium. The CPU 21 can also take in some or all of the data stored in the recording medium 23 from another device via a transmission medium, and newly register or additionally register the data in the recording medium 23. In other words, a cable transmission line such as a communication line or a cable or a radio wave, a microwave,
The program / data transmitted via a wireless transmission path such as infrared rays can be received by the transmission control unit 25 and installed in the recording medium 23. Further, the program / data may be stored and managed on the external device side such as a server, and the CPU 21 may directly access and use the program / data on the external device side via a transmission medium. On the other hand, a transmission control unit 25, an input unit 26, and a display unit 27, which are input / output peripheral devices, are connected to the CPU 21 via a bus line, and the CPU 21 controls the operation according to an input / output program. The input unit 26 is an operation unit that constitutes a pointing device such as a keyboard, a touch panel, a mouse, and a touch input pen, and inputs character string data and various commands.

Next, the operation of the security management system in this embodiment will be described with reference to the flowcharts shown in FIGS. 8 to 11 and FIGS. Here, the program for realizing each function described in these flowcharts is stored in the form of a readable program code in the recording medium 23 (23A), and the CPU 21 (21A) stores the program code in this form. Execute the operations according to the order. Further, the CPU 21 (2
1A) can also sequentially execute the operation according to the above-described program code transmitted via the transmission medium. That is, an operation unique to this embodiment can be executed using a program / data externally supplied via a transmission medium in addition to a recording medium.

FIGS. 8 and 9 are flowcharts showing the operation when the server device 1 makes various settings for the setting table 11. First, processing for setting and registering basic group information is performed (steps A1 to A1).
0). Here, the operator is ready for input,
A "group name" for one group to be set this time is input and designated (step A1), and a terminal "set number" and a user "number of users" in the group are input (step A2). Then, the specified number of mobile terminal devices 2 and
After the DB card 3 associated with the terminal is set in the server device 1 (step A3), "terminal names" corresponding to the set number are input (step A4).

Then, the server device 1 selects and designates any one of the terminals in the same group, and reads out the "serial number" (step A5). A "hard identification number" is generated based on the "number" (step A6), and the "hard identification number" is written in each of the set number of portable terminal devices 2 and the DB card 3 (step A7). When setting the table, writing to the portable terminal device / DB card is performed when the “hard identification number” is generated, when the “soft identification number” described later is generated, and when the “scramble key (S
K) ”is performed only at the time of generation. In the next step A8, the generated "hardware identification number" is registered in the setting table 11 in addition to the "group name", "set number", "terminal name", and "number of users" input as described above. Processing is performed. Then, when the operator inputs an arbitrary value as the number of times of inoperable viewers due to a password mismatch (step A9), the input "number of times of inactive viewers" is registered in the setting table 11 (step A10).

When the setting and registration of the group basic information is completed in this way, the process proceeds to a process of setting and registering passwords for the number of users of the group (steps A11 to A1).
5). First, the operator inputs a user name (step A1) and a password corresponding to the user (step A12), and the input user name and password are registered in the setting table 11 (step A13). As a result, when the user registration for one user is completed, it is checked whether the user registration for the number of users has been completed (step A14), and the above operation is repeated until the setting for all users is completed.

Then, when the user registration is completed,
The process proceeds to the process of setting and registering “scramble key (SK)” and “record encryption key (RK)” (step A15).
~ A17). First, a "scramble key (SK)" is generated (step A15), and a "record encryption key (RK)" is generated (step A16). As described above, the “scramble key (SK)” is an encryption key used when scrambling the FAT of the mobile DB, and the “record encryption key (RK)”
Is an encryption key used to encrypt the database for each record and field. The key generation method in this case is arbitrary, and may be randomly generated each time. Then, the generated “scramble key (SK)” and “record encryption key (RK)” are registered in the setting table 11 (step A).
17) The generated “scramble key (SK)” is written into each mobile terminal device 2 for the set number (Step A18).

Next, the process proceeds to the process of setting and registering the database and the application software corresponding thereto (steps A20 to A34 in FIG. 9). First, the operator
When the "mobile DB name" to be written on the B card and the "master DB name" from which the "mobile DB name" is created are designated and input (steps A20 and A21), the "mobile DB name" is entered.
At the same time, the “master DB name” is registered corresponding to the setting table 11 (step A22). Then, the record configuration of the file in the designated master DB is displayed as a guide (step A23). That is, assuming that each record of the master DB is composed of eight fields “A” and “B” to “H” as shown in FIG. 12A, each item name of this one record Are displayed in that order.

Here, the operator confirms the guidance display of the record configuration and specifies and inputs "record extraction conditions" (step A24). That is, after specifying a desired field as a condition setting target field among the fields of the record configuration displayed for guidance, a "record extraction condition" for the specified field is specified and input.
For example, after specifying the item of the update date as a condition setting target field, a record updated on or after December 24, 1999 is specified as a “record extraction condition”. Next, a field to be a target of the record configuration is selected and designated (step A25). For example, a desired field is selected and designated as an "extraction target field" among the fields of the record configuration displayed for guidance. Then
The designated and input “record extraction condition” and “target field name” of the record configuration are registered in the setting table 11 corresponding to the mobile DB name (step A26). Then, it is checked whether or not all the mobile DBs to be written in the group have been designated (step A27), and the above operation is repeated until all the designations have been completed, thereby registering and registering the mobile DB (step A27). Steps A20 to A27).

When the mobile DB setting registration is completed, the “serial number” read as described above is read.
And a "software identification number" based on the "mobile DB name" specified first in the group and the input "group name" (step A2).
8) Write this "software identification number" to each of the set number of portable terminal devices 2 (step A29). next,
The process proceeds to a process of setting and registering the customized AP in association with each mobile DB name set and registered this time. That is,
When the operator designates one of the registered mobile DB names (step A30), the “master DB name” corresponding to the specified mobile DB name is read out, and the master AP corresponding to the master DB is identified. By modifying the basic AP to a display form for accessing and using the mobile DB, a desired customized AP is arbitrarily created (step A31).

For example, by designating which field is to be displayed at which position in accordance with the record structure of the mobile DB, or by modifying and changing the basic AP while arbitrarily designating the display size of each field, etc. Create a customized AP. Then, after writing the "software identification number", the current system date "update date", and the "corresponding mobile DB name" in the created customized AP (step A32), the customized AP is registered in the setting table 11 (step A32). Step A33). And
The above operation is repeated until all customization APs are created and registered (step A34) (step A30).
To A34).

Next, it is checked whether the setting registration for all groups has been completed (step A35), and the process returns to step A1 until the end of all groups is determined, and the above operation is repeated for each group. Thereby, the setting table 11
, Various contents shown in FIG. 4 are set and registered corresponding to each group. At this time, each time the setting registration for one group is completed, the next setting target group is designated, and the portable terminal device 2 and the DB card 3 corresponding to the group are set in the server device 1. By such a table setting, a “hard identification number”, a “soft identification number”, and a “scramble key (SK)” are respectively written in the portable terminal device 2, and the “hard identification number”,
A "software identification number" is written.

FIGS. 10 and 11 are flowcharts showing the operation in the case where the server device 1 writes the mobile DB, the corresponding customized AP and the like into the DB card 3 and distributes them. First, the operator sets one or more DB cards 3 to be distributed in the server device 1 (step B1). Then, one card is selected from the set DB cards, the “hard identification number” is read from the card (step B2), and the setting table 11 is searched based on the hard identification number. The corresponding group is specified (step B3). Then, the “basic software” as a common writing target to be written to each DB card commonly to each group is read from the setting table 11 and written to the DB card (step B4). In this case, the "basic software" includes the "search viewer", the "FAT scramble / descrambling algorithm", the "encryption / decryption algorithm", and the "operation control management file", and is written including these. . Next, the “viewer non-operation set number (N)” corresponding to the specified group is read from the setting table 11 and written into the DB card (step B5).

Further, the current system date and time are acquired and specified as a time variable key (step B6).
Then, the corresponding "password" is read from the first user among the users of the specific group (step B7), and the "password" is encrypted using the time variable as a key (step B8). The “time variable key” is added to the generated encrypted password and written into the DB card together with the corresponding user name (step B9). Then, it is checked whether or not all the users of the specific group have been specified (step B10), and the process returns to step B7 until all the users have been specified, and the above operation is repeated for each user. As a result, when the processing for all users is completed, the “record encryption key (RK)” of the specific group is read from the setting table 11 and written to the DB card (step B11).

Next, the process proceeds to the process of creating a mobile DB and writing it to the DB card. First, of the mobile DB names corresponding to the specific group registered in the setting table 11,
A master DB file corresponding to the master DB name associated with the first mobile DB name is read out (step B12). Then, a “record extraction condition” and an “extraction target field” corresponding to the master DB name are obtained, and the corresponding record is extracted by searching the master DB file 12 based on the “record extraction condition” (step B13). ). That is, FIG.
(B) shows a specific example in this case, and shows a master DB (FIG. 1).
2 (A)), by extracting each record group corresponding to the “record extraction condition”, only the record group necessary for the business content of the group and the processing content of the terminal are extracted.

The record configuration of each of the extracted record groups is changed based on the "field to be extracted" (step B14). FIG. 13C shows a specific example of this case. In the extracted record group, only the fields corresponding to the “field to be extracted” are cut out of the respective fields constituting the extracted record group, and only the cut out fields are extracted. Is changed to a record configuration consisting of next,
In step B15 in FIG. 11, each record field after the record configuration is changed as described above is encrypted based on the "record encryption key (RK)". In this case, every time each record field is encrypted, the value of the “record encryption key (RK)” is updated, so that the encryption is individually performed using different keys. Then, an encrypted record group is created as a mobile DB file and written in the DB card (step B16). When a mobile DB for one file is created in this way, it is checked whether another mobile DB name is set and registered corresponding to a specific group (step B17). If there is, the process returns to step B12, and the above operation is performed. repeat. Thus, a mobile DB file is created for each mobile DB name corresponding to a specific group and written in the DB card, and an FAT indicating the storage location of the file is created and written in the DB card.

Next, customization A for mobile DB
Move on to the process of writing P to the DB card. First, Master D
Based on the B name, the customized AP associated therewith is read from the setting table 11 (step B1).
8) It is checked whether the corresponding customized AP exists in the DB card (step B20). Since the customized AP is not present at first, the process proceeds to step B24, where the current customized AP in the setting table 11 is read to read the DB. Overwrite the card. Thereby, the latest customized AP (including “software identification number” and “update date”) is newly written in the DB card corresponding to the mobile DB.

Even if a customized AP exists in the DB card (step B19), the "update date" in the DB card and the current customized A
The P is compared with the “update date” of P, and if it is determined that the two do not match (step B20), that is, even if the current customized AP has been updated, the process proceeds to step B24, and the current customized AP is stored in the DB. By overwriting the card, it is rewritten to the latest customized AP. If the “update date” matches, the update is not performed because the customized AP in the DB card is the latest one. Then, it is determined whether another customized AP is set in the same group (step B2).
1) If there is, return to step B18, read the next customized AP, and repeat the same processing thereafter. When the writing of the customization AP is completed, the FAT indicating the storage location of each file in the mobile DB in the DB card is displayed.
Is scrambled using a "scramble key (SK)" (step B22).

When the writing process for one DB card is completed, it is determined whether there is another unwritten DB card (step B23). If another DB card has been set, the process proceeds to the step shown in FIG. Returning to B2, one of the unwritten DB cards is designated and the above operation is repeated. As a result, the content shown in FIG. 6 is written in each DB card set in the server device. The D in which the basic software, the user information, the mobile DB, the corresponding customized AP, etc. are written in this manner
The B card is distributed to the user for each group.

FIG. 13 is a flowchart of an operation started on the portable terminal device in response to power-on. First, when the power is turned on in a state where the DB card is set in the portable terminal device, the basic operation is started based on the basic software in the DB card (step C).
1). Then, the above-described DB card security processing of the first security layer is executed. That is, the “hardware identification number” is read from the DB card (step C).
2) Check with the “hardware identification number” in the terminal (step C3). As a result, if the two match (step C4), the terminal and the card have a proper correspondence, and the scrambled “FAT” in the DB card is used.
Is read into the terminal, and is set in the “FAT read area” in the RAM shown in FIG. 6 (step C).
5) Descramble the "FAT" using the "scramble key (SK)" in the terminal (step C6). Then, the search viewer is activated (step C7). If the terminal and the card do not have a proper correspondence, it is determined that the "hard identification number" does not match, so that a hard error is displayed (step C).
8) The power is forcibly turned off (step C9), and the process ends with an error.

FIG. 14 is a flowchart for explaining in detail the operation at the time of step C7 (search viewer activation) in FIG. First, in the above-described password authentication processing of the second security layer, security processing is performed as a preceding step. That is, the portable terminal device accesses the DB card when the search viewer is activated, and checks whether the "operation control management file" exists in the card (step D1). Here, as described above, if an incorrect password input is repeated several times consecutively, the "operation control management file" is deleted thereafter to disable the search viewer. . Therefore,
The presence or absence of the "operation control management file" is checked. If it does not exist, an inoperative message is displayed (step D11), and the power is forcibly turned off (step D11). Become.

On the other hand, if the "operation control management file" exists, a login input screen is displayed on the condition that the "operation control management file" exists, and a message prompting the user to input the user name and password is displayed (step D2). Here, when the operator inputs his / her own “user name” and “password” (step D3), the encrypted password corresponding to the “user name” in the DB card is read (step), and the encrypted password is stored in the “time variable”. Is used as a key (step D
5). Then, the input password is compared with the decrypted password (step D6). As a result, when it is determined that the two do not match (step D7), the number of mismatches is updated, and the updated value and the “number of times of non-operation of viewer (N)” set in advance for each group are used. Are compared and N is incorrectly entered continuously.
It is checked whether the repetition has been performed (step D8).
2) Accept the re-input. If it is determined that the password has been incorrectly repeated N times in a row (step D8), the "operation control management file" is deleted (step D9), and a non-operation message is displayed. Thereafter (step D10), the power is forcibly turned off (step D11), and the process ends in an error.

Before the erroneous input of the password is repeated N times in succession, if the passwords match and it is determined that the operator is a valid operator (step D7), first, the third security described above is performed. Layer soft security processing is performed. That is, since a menu screen of each customized AP written in the DB card is displayed in a list, if the operator selects and specifies a desired customized AP from the menu screen (step D12), the selected customized AP is displayed. The included "software identification number" is read from the DB card (step D13), and collated with the "software identification number" in its own terminal (step D14). As a result, when it is determined that the two do not match (step D15), an inoperative message is displayed (step D10), the power is forcibly turned off (step D11), and the process ends with an error. On the other hand, as a result of collating the “software identification number”, if the two match, the selected customization A
P is started, and the execution of the application process corresponding to it is started (step D16).

FIGS. 15 and 16 are flow charts for explaining in detail the operation at the time of step D16 (customized AP activation) in FIG. First, a processing menu is displayed (step E1). In this case, the menu screen displays "key search", "add", and "end" menu items. When a desired menu item is selected and designated (step E2), the selected item is checked (step E3). ,
E13) The process proceeds to a corresponding process.

Here, when the menu item “key search” is selected and a search key (for example, a product name or a customer name) is input (step E4), the “record encryption key” is input from the DB card. , And the retrieval key is encrypted with a “record encryption key (RK)” (step E5). Then, the mobile DB in the DB card is searched using the encrypted search key (step E6),
A record corresponding to the key is extracted. If there is no matching key (step E7), the display returns to the menu display screen (step E1), and the search key can be re-input. Now, as a result of the key search, if there is a matching key (step E7), the process proceeds to step E8, where a record corresponding to the search key is read from the mobile DB, and the “record area” in the RAM shown in FIG. Write to. Then, the record is decrypted with the "record encryption key (RK)" (step E9), the contents of the record are displayed and output (step E10), and the processing menu is displayed (step E11).

In this case, menu items "correct", "delete" and "end" are displayed on the menu screen, and a desired menu item is selected and designated from the menu items (step E).
12). Then, the selected item is checked (step E in FIG. 16).
20, E26) The processing shifts to the corresponding processing. That is,
When the menu item "correction" is selected (step E20), when correction data is input, a process of correcting the record content is performed accordingly (step E2).
1). Then, to indicate that the record has been corrected, a "correction flag" is set in the correction record (step E22), and the correction record is encrypted using a "record encryption key (RK)" (step E22). E2
3) Overwrite the encrypted record with the original record in the mobile DB (step E24). When the record correction is completed, the record is deleted from the terminal (step E25). That is, FIG.
Clear the "record area" in the RAM indicated by.
When the menu item "delete" is selected (step E26), the data part of the record is deleted, a "delete flag" is set in the record, and the original record in the mobile DB is overwritten. (Step E2
7). Then, the record is deleted from the terminal (step E25).

On the other hand, if "addition" is selected on the processing menu screen in step E1 in FIG. 15, the process proceeds to step E14, and a new record input creation process is performed. And to indicate that it is a record addition,
The "addition flag" is set in the new record (step E15), the new record is encrypted using the "record encryption key (RK)" (step E16), and the encrypted record is added to the mobile DB. (Step E17). When the record addition is completed, the record is deleted from the terminal (see FIG. 1).
6 step E25). Note that when “end” is selected on the processing menu screen in step E1 in FIG. 16, “FAT” in the terminal is deleted (step E1).
8). That is, the contents of the “FAT read area” in the RAM shown in FIG. 6 are cleared. Then, the record in the terminal is deleted (step E25). In this way, on the mobile terminal device side, the file contents of the mobile DB stored in the DB card are updated as daily work is performed.

FIG. 17 shows a mobile DB in a DB card which has been changed in accordance with the execution of daily work in the server device.
9 is a flowchart showing an operation (collection operation) in the case of collecting data and updating the master DB in the server. First, when the operator sets a DB card to be collected in the server device (step F1), the “hard identification number” is read from the DB card (step F2), and the setting table 11 is referred to based on the “hard identification number”. Then, the corresponding group is specified (step F3). Then, the "scramble key (SK)" is read from the DB card, and the FAT in the DB card is descrambled using the "scramble key (SK)" (step F).
4). Further, the mobile DB is read from the DB card (step F5), and each record / field of this DB file is decrypted using the “record encryption key (RK)” (step F6). Also in this case, every time each record / field is decrypted, the value of the “record encryption key (RK)” is updated, so that decryption is performed using different keys.

Then, it is checked whether or not a changed record exists in the decrypted DB file based on the presence / absence of the "correction flag", "deletion flag" and "addition flag" (step F7). That is, if there is any record to which any “flag” is added, the master DB in the server device corresponding to the mobile DB is specified (step F8), and the change record read from the mobile DB is specified. Is performed to update the corresponding record in the master DB in accordance with the type of the "flag" added to it (steps F9 and F10). That is,
Correction processing for correcting the contents of the corresponding record, deletion processing for deleting the data part of the record, and addition processing for adding a new record are performed. Such a record update process of the master DB is performed on all the changed records in the mobile DB (steps F9 to F11). If another mobile DB exists in the DB card (step F1)
2), the above operation is repeated for the mobile DB (steps F5 to F12).

As described above, in this embodiment,
When the portable terminal device accesses the DB card, the "hard identification number" in the card and its "hard identification number"
Is determined based on the result of the comparison, and as a result, when access to the card is permitted, the “software identification number” stored in this card is Since the “software identification number” is collated and the access to the mobile DB in the card is determined based on the collation result, the mobile D is associated with the terminal and the medium.
It is possible to take a thorough countermeasure of multiple security that makes it impossible to access the card itself in addition to the access to B.

Thus, it is possible to reliably prevent the mobile DB in the DB card from being leaked to another person due to loss, theft, malice, and the like. Further, it is possible to realize security management that does not require a special operation for security management and does not impair operability. That is,
Since security management is automatically performed simply by inserting the DB card into the mobile terminal device, the user does not need to be conscious of security measures when using the DB card.
Secure security management can be realized without impairing usability. In this case, since the mobile DB including the important information is stored only in the DB card which can be separated from the mobile terminal, even if only the mobile terminal is lost or stolen, there is no problem in security at all, In addition, even if the DB card is lost or stolen, access to the card can only be performed by a legitimate terminal. Is impossible, and the security is extremely high.

Further, in addition to writing the data file on the DB card, the server device collectively associates the DB card with a portable terminal device capable of accessing the DB card, so that the setting operation can be performed efficiently. In addition to this, it is not necessary to provide a mechanism for taking measures to ensure security management for the DB card in the portable terminal device itself. Also, instead of writing the original master DB as it is, by creating and writing a mobile DB consisting only of a group of records cut out from the master DB, unnecessary information can be transmitted to a legitimate terminal corresponding to the card. You can take measures not to provide. Therefore, in the method of writing the original master DB as it is on the card, it is necessary to previously set access authority information for restricting the access for each record and each field in the master DB. By writing the mobile DB including only the record group cut out from, the setting of the access authority information becomes unnecessary at all. In other words, by taking physical security measures, rather than logical security measures such as setting access authority information, it is possible to ensure that important information on the card is not leaked due to loss, theft, malicious intent, etc. This is also advantageous in terms of capacity.

In this case, when a record group used in the portable terminal device is cut out from the master DB, the record extraction condition set in advance according to the processing contents on the portable terminal device side is referred to, and this record is referred to. A record group that matches the extraction condition can be cut out, and a mobile DB having a record configuration including only fields that match the conditions of the extraction target field can be created by referring to the extraction target field. By simply setting extraction target fields, a desired mobile DB can be easily created. Also,
When a record group used in the portable terminal device is cut out from the master DB, hardware identification information set in a DB card to be written is acquired, and a desired master DB is automatically determined based on the hardware identification information. It is possible to do.

If the customized AP for processing the mobile DB is not stored in the DB card in association with the mobile DB, the customized AP for processing the mobile DB in association with the mobile DB is stored. D
Write in B card, and customize AP is DB
Even if it is stored in the card, if it is not the latest one, it is rewritten to the latest customized AP.
P and can be stored in association with each other, and the latest customized AP can always be stored.

The "hard identification number" and "software identification number" may be generated based on any information. For example, the "hard identification number" may be replaced with the "manufacturer code" of the portable terminal device. + "Production number" or the like. When a plurality of mobile DBs are stored in the same DB card, the "software identification number" may be different for each mobile DB. The terminal group can be set so that one terminal belongs to a plurality of groups, in addition to simply dividing the plurality of terminals. Further, the record extraction conditions and the setting contents of the extraction target field may be arbitrarily changed as necessary. Further, when rewriting to the latest customized AP, it is determined whether the latest customized AP is the latest based on the update date. However, the determination may be performed based on the “version No.”.

In the above-described embodiment, a compact flash card is exemplified as a DB card as a portable storage medium. In addition, a PC card, smart media, CD (optical disk), MO (magneto-optical disk) , FD (floppy disk) or the like, and the shape is not limited to the card type, but may be any shape such as a cassette type or a stick type. Further, the portable terminal device may be an electronic organizer, a notebook computer, a PDA, a mobile phone, or the like.

[0059]

According to the present invention, in order to ensure security management for a portable data storage medium, in addition to writing a data file to the data storage medium, the data storage medium and a portable device capable of accessing the data storage medium can be accessed. The server device can perform the association with the terminal device in a lump, and, instead of writing the original master database as it is, creating and writing a mobile data file consisting of only a group of records cut out from the master database Therefore, it is possible to take measures to prevent the provision of unnecessary information even to legitimate terminals compatible with the medium, and to prevent leakage of important information in the data storage medium due to loss, theft, malicious intent, etc. can do.

[Brief description of the drawings]

FIG. 1 is a block diagram showing the overall configuration of a security management system.

FIG. 2 is a diagram for explaining a DB card 3 corresponding to a terminal group and a correspondence between a mobile terminal device and a user.

FIG. 3 is a diagram conceptually showing multiple security.

FIG. 4A is a diagram showing the configuration of a setting table 11 provided on the server device side and the setting contents thereof, and FIG.
FIG. 3 is a diagram showing a master DB file 12, and FIG.

FIG. 5 is a view showing contents written in each DB card 3;

FIG. 6 is a view showing contents written in a built-in memory of each portable terminal device 2.

FIG. 7 is a block diagram showing an overall configuration of a server device 1 and a mobile terminal device 2;

FIG. 8 is a flowchart showing an operation in a case where the server device 1 performs setting on the setting table 11;

FIG. 9 is a flowchart showing a setting operation following FIG. 8;

FIG. 10 is a diagram illustrating a case where the server apparatus 1 is configured to execute a master DB and a customization A.
9 is a flowchart showing an operation when P and the like are written in the DB card 3 and distributed.

FIG. 11 is a flowchart illustrating a distribution operation following FIG. 10;

12A is a diagram illustrating a master DB, FIG. 12B is a diagram illustrating records extracted from the master DB according to “record extraction conditions”, and FIG. 12C is a “field to be extracted” from each extracted record. FIG. 6 is a diagram showing a record configuration after a change made by the above.

FIG. 13 is a flowchart that is started by the portable terminal device 2 when power is turned on.

[FIG. 14] Step C7 in FIG. 13 (search viewer activation)
5 is a flowchart for explaining the operation at the time.

15 is a flowchart for explaining in detail the operation at the time of step D16 (starting of a customized AP corresponding to a DB) in FIG. 14;

FIG. 16 is a flowchart detailing the operation at the time of starting the customized AP, following FIG. 15;

FIG. 17 is a flowchart showing a collection operation in the case where the server device 1 collects a mobile DB in a DB card changed according to execution of daily work and updates a master DB in the server.

[Explanation of symbols]

 DESCRIPTION OF SYMBOLS 1 Server apparatus 2 Portable terminal device 3 DB card 11 Setting table 12 Master DB file 13 DB corresponding basic AP 21, 21A CPU 22, 22A Storage device 23, 23A Recording medium 25, 25A Transmission control unit 26, 26A Input unit 27, 27A Display

Claims (7)

[Claims] 1. A portable terminal device, and a server device for writing and distributing a data file to a portable data storage medium used by the portable terminal device, wherein the server device is used by the portable terminal device. A record group is cut out from a master data file, and a mobile data creation unit for creating a mobile data file from the cut record group is created by the mobile data creation unit on a data storage medium in which association with a portable terminal device is set. Writing means for writing the set mobile data file, wherein the portable terminal device determines whether the data storage medium set in the mobile data file is a valid medium associated with the terminal, If the means determines that the medium is compatible with the terminal, the data storage medium Security management system characterized by comprising an access control means for granting access to mobile data file. 2. The mobile data creation means according to claim 1, wherein when extracting a record group used in the portable terminal device from a master data file, the mobile data creating means extracts a record set in advance according to the processing contents on the portable terminal device side. 2. The security management system according to claim 1, wherein a record group that satisfies the record extraction condition is cut out by referring to the condition. 3. The mobile data creation means according to the contents of processing on the mobile terminal device side when creating a mobile data file by extracting a record group used by the mobile terminal device from a master data file. 3. The security according to claim 1, wherein a mobile data file having a record configuration including only fields that meet the conditions of the extraction target field is created by referring to a preset extraction target field. Management system. 4. The mobile data creation means acquires identification information set in a data storage medium to be written when a record group used in the mobile terminal device is cut out from a master data file. A master data file is determined based on the identification information, a cutout condition for cutting out a record group from this master data file is determined, and a record group is cut out from the determined master data file according to the cutout condition. 2. The security management system according to claim 1, wherein: 5. A server device for writing and distributing a mobile data file to a data storage medium used by a portable terminal device, wherein the application software for processing the mobile data file is associated with the mobile data file. A determination means for determining whether the application software is stored therein, and when the determination means determines that the application software is not stored, an application for processing the application data in association with the mobile data file 2. The security management system according to claim 1, wherein the software is written in a data storage medium. 6. When the application software is stored in the data storage medium in association with a mobile data file, the application determination means determines whether or not the application software is the latest one. Application updating means for rewriting the application software stored in association with the mobile data file in the data storage medium to the latest application software when it is determined that the application software is not the application software. The security management system according to claim 5, wherein 7. A portable terminal device, which is a recording medium having a program code readable by a computer and writes and distributes a data file to a portable data storage medium used by the portable terminal device. A group of records used in the master data file, a computer-readable program code for creating a mobile data file from the cut record group, and a data storage medium in which the association with the portable terminal device is set. A computer-readable program code for writing the mobile data file; and a computer for allowing the portable terminal device to determine whether the data storage medium set therein is a valid medium associated with the terminal. Possible programs Over de and, if it is the terminal compatible medium is determined, a recording medium having a data storage program code readable computer to allow access to mobile data files in the media.