JP6819734B2 - Information processing equipment and terminals used - Google Patents

Description

The present invention relates to an information processing device and a terminal used.

The system disclosed in Patent Document 1 receives a request for a document together with unique user identification information from a plurality of users having a computer having a display device or a printer. Next, the copyright server authenticates the requests from a plurality of users. The copyright server then commands the document server to act on the correct authentication of each request. In response, the document server creates a uniquely encoded, compressed, and encrypted document for each authenticated request, and authenticates the document to each authenticated request user over the network. Transfer to the corresponding display or print agent for each requesting user. The document is uniquely encoded for each of the plurality of users. Finally, each agent decrypts and decompresses the document, making the document available only in response to the correct private key provided to the agent by the authenticated requesting user.

Japanese Unexamined Patent Publication No. 7-239828

When a user specifies a document and the user to whom the document is sent, there are a number of systems that make the document available to the destination user by registering the document in the user's account.

However, considering the management of documents that require confidentiality such as in-house documents, it may not be sufficient to take measures against leakage simply by specifying the user to whom the document is sent. For example, if the destination user uses the document using a terminal that is not thoroughly managed for security, there is a high possibility that the document will be leaked from that terminal.

An object of the present invention is to reduce the possibility of document leakage as compared with a method in which the document can be used by any terminal designated as the destination of the document.

The configuration of Reference Example 1 is a selection means for allowing a user who sends a document to select a destination user, a destination terminal, and an authority for the document set for a combination of the destination user and the destination terminal. The document, the destination information indicating the destination user and the destination terminal selected by the selection means, and the information indicating the authority are outside the information processing apparatus and the destination terminal. An information processing device including a processing device for transmitting the document, and a transmission means for transmitting the document.

The configuration of Reference Example 2 further includes a candidate acquisition means for acquiring candidate information indicating a candidate for the destination terminal from the processing device, and the selection means is the transmission destination from among the candidates indicated by the candidate information. The information processing device according to Reference Example 1, which allows the user to select a terminal.

The configuration of Reference Example 3 further includes candidate / condition acquisition means for acquiring candidate information indicating a candidate for the destination terminal and information on narrowing conditions for the destination terminal from the processing device, and the selection thereof. The means is the information processing apparatus according to Reference Example 1, in which when a new candidate is added from a candidate other than the candidate indicated by the candidate information, only a candidate satisfying the narrowing down condition is selected and added.

The configuration of Reference Example 4 further includes a detection means for detecting a terminal existing in the vicinity of the own device, and the selection means displays the terminal detected by the detection means as a candidate in a mode different from other candidates. , The information processing apparatus according to any one of Reference Examples 1 to 3 for selecting the destination terminal from each of the displayed candidates.

The configuration of Reference Example 5 further includes a neighborhood terminal information acquisition means for acquiring information on a terminal existing in the vicinity of the processing device from the processing device, and the selection means is the information acquired by the neighborhood terminal information acquisition means. In the information processing apparatus according to any one of Reference Examples 1 to 4, the terminal indicated by is displayed as a candidate in a mode different from that of other candidates, and the destination terminal is specified from each of the displayed candidates. is there.

The configuration of the reference example 6, the selection means, from the transmission source user, the destination user, the destination terminal, and the selection of the authority accepts the same screen, according to Reference Example 1 It is an information processing device.

The invention according to claim 1 comprises a receiving means for receiving a document, destination information indicating a destination user and a destination terminal of the document, a storage means for storing the received document, and a own machine. When the pair of the authentication means for authenticating the user who uses the above and the user authenticated by the own machine and the authentication means corresponds to the pair of the destination user and the destination terminal indicated by the received destination information, The destination user indicated by the destination information received by a pair of a first control means that stores the document in the storage means and controls the display of the document, and a user authenticated by the own machine and the authentication means. If the document does not correspond to the set of the destination terminal, the document is displayed, but after the display is completed, the document used for the display is controlled to be discarded without being saved in the storage means. It is a user terminal having a control means.

The invention according to claim 2 uses a receiving means for receiving a document, destination information indicating a destination user and a destination terminal of the document, a storage means for storing the received document, and a own machine. If the pair of the authentication means for authenticating the user and the user authenticated by the own machine and the authentication means corresponds to the pair of the destination user and the destination terminal indicated by the received destination information, the document. When there is an unusable response from the processing device to the control means for controlling the display, the means for transmitting the usage request of the document stored in the storage means to the processing device, and the usage request. A user terminal having a means for deleting the document from the storage means.

According to Reference Example 1 , the possibility of document leakage can be reduced as compared with the method in which the document can be used by any terminal designated as the destination of the document.

According to Reference Example 2 , it is possible to prevent a terminal not assumed by the processing device from being designated as the destination terminal.

According to Reference Example 3 , even when a terminal not assumed by the processing device is designated as the destination terminal, it is possible to prevent a terminal that does not satisfy the narrowing conditions of the processing device from being designated as the destination terminal. it can.

According to Reference Example 4 , nearby terminals that can be grasped by the user who operates the information processing device can be included in the candidates for the destination terminal.

According to Reference Example 5 , terminals in the vicinity of the processing device can be included in the candidates for the destination terminal.

According to Reference Example 6 , the selection of the destination user, the destination terminal, and the authority can be accepted on the same screen.

According to the invention of claim 1 , it is possible to prevent the document from being stored in a user terminal other than the designated destination terminal.

According to the invention of claim 2 , even if the document is saved in the user terminal other than the designated destination terminal, it is possible to prevent the document from being deleted.

It is a figure which shows the example of the structure of the document management system. It is a figure for demonstrating the outline of distribution and browsing of a document using a document management system. It is a figure which illustrates the data content of metadata. It is a figure which illustrates the data content managed by the user ID server. It is a figure which illustrates the data content managed by a DID server. It is a figure which illustrates the data content which a processing apparatus management server manages. It is a figure which illustrates the structure of the processing apparatus and the data content which a processing apparatus has. It is a figure explaining the flow of document distribution and browsing in a document management system. It is a figure which shows the example of the input screen of attribute data. It is a figure which shows the example of the option setting screen. It is a figure which shows the example of the list screen. It is a figure which shows the example of the system configuration which provided the organization management system. It is a figure which shows the example of the process flow at the time of the user performing the metadata acquisition and browsing of a document using the processing device which is not registered by the user. It is a figure which shows the example of the process flow at the time of registering a document in a document management system by a user using the processing device which has not been registered. It is a figure which shows the example of the data content of DID. It is a figure which illustrates the flow of the status check processing of the processing apparatus executed by the processing apparatus management server. It is a figure which shows another example of the flow of the status check processing of the processing apparatus executed by the processing apparatus management server. It is a figure which illustrates the processing flow of the processing apparatus when a vulnerability is found in the encryption software. It is a figure which shows the example of setting of the group of a processing apparatus. It is a figure which shows various information which a processing apparatus holds for transfer management. It is a figure which shows the example of the transfer setting information of a certain processing apparatus. It is a figure which illustrates the processing procedure of the processing apparatus corresponding to the away apparatus. It is a figure which illustrates the processing procedure of the processing apparatus corresponding to a home apparatus.

FIG. 1 shows a schematic configuration of one embodiment of a document management system.

In the case of a paper document, the person holding the document can freely copy it or give it to another person. In addition, the person who obtained the document can read the document. In this way, paper documents have an extremely high risk of information leakage.

On the other hand, the document management system of the present embodiment aims to provide an environment in which electronic documents can be used securely and reduce the risk of document information leakage. Here, the document is content data that can be distributed as one unit (for example, one file), and the type of data is not particularly limited. For example, the concept of documents includes text data, document data created by word processor software, spreadsheet data created by table calculation software, CAD (Computer Aided Design) data, image data, video data, audio data, and multimedia. It includes data, page data displayed on a web browser, and other data that can be created, edited, viewed, and printed out on a PC.

This document management system includes a plurality of local systems 100 and a management system 200 that manages the local systems (particularly, management of a processing system described later). The management system 200 can communicate with each local system 100 via a wide area network 10 such as the Internet.

The local system 100 includes one or more creation terminals 102, one or more browsing terminals 104, and a processing device 110 connected to the local network 108. The local network 108 is a private network (for example, configured as a LAN) provided in an organization such as a company, and is protected from the wide area network 10 by a firewall or the like. Basically, one processing device 110 is installed in the local system 100. When the private network in the organization is large, each network segment constituting the private network may be a local system 100, and one processing device 110 may be installed in each of the individual local systems 100. .. For example, the network segment in the living room of each department of a certain company becomes the local system 100 of that department, and one processing device 110 is installed in that segment. In this example, a local system 100 having a processing device 110 as a core is formed for each company or each department of each company, and each of these processing devices 110 is managed from a central management system 200.

The creation terminal 102 is a terminal used for creating a document, and examples thereof include a desktop or notebook personal computer, a workstation, a tablet terminal, a smartphone, a multifunction device, a scanner, a facsimile machine, and a digital camera. is there. An application for creating and editing a document is installed in the creation terminal 102. In addition, software for requesting the document management system to distribute the created document is installed in the creation terminal 102. As a form of this software, implementation as a device driver for exchanging information with the processing device 110 described later, implementation by a Web application, and the like can be considered.

The processing device 110 converts the document created by the creation terminal 102 into a protected document (hereinafter, also referred to as an "eDoc file") which is a form used in a secure environment provided by the document management system of the present embodiment. Perform protection processing. The protection process can be said to be a process of encoding the original document into an eDoc, and in this sense, the processing device 110 is a kind of encoder. In this protection process, the document is converted into, for example, data in a special format designed for the system of the present embodiment, and encrypted in a form that can be decrypted only by the user specified as the delivery destination of the document. .. Either format conversion or encryption may be performed first.

Further, the processing device 110 creates metadata for the protected document, and registers the created metadata in the management system 200, which is a higher-level system. The metadata includes bibliographic information of the protected document, destination information, key information used by each destination to decrypt the protected document, and the like. The metadata contains multiple items, and data is added / edited / updated by the corresponding device or user according to the function provided by this service.

As an example, a part of these items is specified by the user who has instructed the document management system to register the document, and another part is created by the processing device 110. In addition, the management system 200 or the viewing terminal 104 may set the values of some items in the metadata. In addition, the processing device 110 transmits the generated protected document (eDoc file) to the viewing terminal 104 of the distribution destination specified by the user.

A protected document, that is, an eDoc file, is an encrypted original document converted into a dedicated format, and is also called the main body of the eDoc. The corresponding metadata is required to make the eDoc file viewable. The eDoc file and metadata together make up a fully protected document that can be viewed. In this way, the set of the eDoc file and the corresponding metadata is referred to as "eDoc" below.

The processing device 110 may have a built-in wireless LAN access point function. In this case, the viewing terminal 104 can communicate with the processing device 110 via a wireless LAN.

The viewing terminal 104 is a terminal used for viewing a protected document (eDoc file). "Browsing" here means using a protected document in a manner corresponding to the information content represented by the document. For example, when the protected document has a document such as word processing data or drawings as information content, browsing is reading or viewing the document displayed by the browsing terminal 104. When the information content represented by the protected document is voice, browsing means that the user listens to the voice played by the browsing terminal 104. The viewing terminal 104 is configured by installing a viewer application for viewing a protected document on a general-purpose computer such as a desktop or notebook personal computer, a workstation, a tablet terminal, or a smartphone. Further, a reading-only terminal such as an electronic book terminal having a function equivalent to that of the viewer application may be used as the reading terminal 104. The viewer application has a function of decrypting an encrypted protected document using the information of metadata and a function of decoding data represented in a dedicated format of the protected document into readable data. A computer that does not have a viewer application corresponding to the document management system of this embodiment cannot decode data in a dedicated format into readable data.

The viewing terminal 104 may have a function of decoding and decoding a protected document and displaying the document, and a function of accepting processing (editing) of the displayed document from the user. The processed document has different contents from the original protected document, but the edited document can be sent from the viewing terminal 104 to the processing device 110 and registered in the document management system (that is, encoded into the protected document). You may do so. In this way, one terminal may have the functions of both the creating terminal 102 and the viewing terminal 104. In addition, the authority granted to the viewer (access authority information in the metadata described later) is set in the eDoc, and the content of the authority includes restrictions on writing to the eDoc, restrictions on the redistribution destination, and the like. It may be. In the case of an eDoc in which such restrictions are specified in the access authority information, the browsing terminal 104 accepts processing (editing) operations from the viewer only within the range of the writing restrictions, and the new eDoc after processing. The specification of the redistribution destination of is accepted only within the limit of the redistribution destination.

Further, in the present embodiment, as an example, an authentication device 130 carried by the user is used as a tool for authenticating the user who uses the document management system of the present embodiment. The authentication device 130 is a device such as an IC card that incorporates identification information unique to a user carrying the device and executes data processing for user authentication in response to a request from an external device. The authentication device 130 may be a mobile terminal such as a smartphone having a function equivalent to that of an IC card for personal authentication. The viewing terminal 104 and the creating terminal 102 have a function of communicating with the authentication device 130 using a wireless communication protocol such as NFC (Near Field Communication). The viewing terminal 104 and the creating terminal 102 exchange information for user authentication with the authentication device 130 according to a predetermined protocol, and authenticate the user carrying the authentication device 130. Alternatively, the actual user authentication is executed by the server side of the document management system of the present embodiment such as the processing device 110 or the management system 200, and the viewing terminal 104 or the creating terminal 102 transfers data between the server side and the authentication device 130. It may be a method of mediating. Further, the viewing terminal 104 and the creating terminal 102 may have the function of the authentication device 130 built-in.

The management system 200 manages the processing devices 110 in each local system 100. Further, the management system 200 manages the metadata of the protected document generated by each of the processing devices 110, and provides the metadata to the viewing terminal 104 as requested. The management system 200 is composed of one computer or a plurality of computers capable of communicating with each other, and has the functions of a user ID server 210, a DID server 220, a metadata server 230, and a processing device management server 240.

The user ID server 210 is a server that manages information of each user who uses the document management system. The user who uses the document management system has two layers. One is a contractor who has signed a contract for using the document management system with the operator of this system, and the other is to actually use the system to register and browse documents under the contract. It is a general user. For example, it is assumed that the company is a contractor, the processing device 110 is installed in the local network 108 of the company, and the employees of the company often use the document management system as a general user via the processing device 110. Will be done. The user ID server 210 holds and manages information about each of the contractor and the general user.

The DID server 220 manages the DID (document ID), which is the identification information (ID) of the protected document. It is the processing device 110 that created the protected document that actually assigns the DID to the protected document, but the DID server 220 grants the processing device 110 the authority to issue the DID and the issuing frame (number of issues). , The issuing authority and the report of the DID actually issued by the processing device 110 in the issuing frame are received and recorded. As a result, the DID server 220 suppresses the occurrence of an invalid DID and makes it possible to detect a document having an invalid DID.

The metadata server 230 holds and manages the metadata of the protected document (eDoc file) generated by the processing device 110. When the user requests the metadata of the protected document via the browsing terminal 104, the metadata server 230 provides the metadata to the browsing terminal 104 if the user is a legitimate person. Note that a user (viewer) requesting metadata is a "legitimate person" for the metadata server 230, which means that the combination of the user and the browsing terminal 104 used when the user issues the request is , The delivery destination user and the delivery destination shown in the delivery destination information (details will be described later) in the metadata held by the metadata server 230 corresponding to the DID of the eDoc file (this is included in the request). This is the case corresponding to the combination of the viewing terminals 104.

The processing device management server 240 is a server that manages the status of each processing device 110.

The mechanism of the present embodiment will be schematically described with reference to FIG.

(0) The management system 200 (DID server 220) grants the processing device 110 in the local system 100 the right to issue a DID (document ID) and the issuance frame (number of documents) associated therewith in advance. .. The right to issue a DID is not unlimited, but is limited to the management system 200 issuance limit. That is, the processing device 110 can assign a DID based on the issuance right granted at the same time as long as the number of documents is up to the number indicated by the issuance limit given by the management system 200. When the issue limit is used up, the processing device 110 receives a new issue right and issue limit from the management system 200.

(1) When the user wants to register (that is, distribute) a document in the document management system of the present embodiment, he / she instructs the creation terminal 102 to register the document (for example, instructs “registration” on the menu of the application). Upon receiving this instruction, the creation terminal 102 requests user authentication. This authentication may be performed by inputting the user ID and password, or may be performed by the user bringing the authentication device 130 close to the card reader unit of the creation terminal 102. The user authentication may be performed by the creation terminal 102 or by the processing device 110 to which the document is registered. Then, the user selects a document to be registered in the document management system from the documents stored in the creation terminal 102 and instructs the registration.

When the creation terminal 102 (more specifically, the registration processing program installed in the creation terminal 102) receives a document registration instruction from the user, the item (for example, the document) that the user should specify in the attribute data for the document. Accepts the input of the delivery destination). Here, as the delivery destination, the designation of the combination of the user and the browsing terminal 104 may be accepted. In this case, when the combination of the user and the viewing terminal 104 used by the user to view the document matches the combination specified as the distribution destination, the user can view the document.

The creation terminal 102 uses the document data of the attribute data such as the delivery destination input by the user and the other attribute items (for example, registrant information, creation date and time, etc.) generated by the creation terminal 102 itself. Is transmitted to the processing device 110 together with. The creation terminal 102 may have a driver that converts documents in various formats created by various applications into a unified format that can be handled by the viewing terminal 104. For example, in the case of data showing a static document image such as word processing data, spreadsheet, and CAD data, the driver converts the data into a document expressed in a page description language, similar to a printer driver. Further, for example, when the original data is audio data, the driver converts the audio data into data (document) in a specific audio data format supported by the document management system (particularly the viewing terminal 104) of the present embodiment. ..

(2) The processing device 110 generates a protected document (eDoc file) by performing a protection process on the document to be registered received from the creation terminal 102. In this generation, the received document is encoded into the dedicated format of the document management system of the present embodiment, and the encoded data is encrypted by using the generated encryption key to generate an eDoc file. The order of encoding and encryption may be reversed. Further, the processing device 110 assigns a unique DID to the eDoc. The DID contains information certifying that it is based on the issuing authority received from the management system 200 (issue authority key described later) and information certifying that it is assigned by the processing device 110 itself (issue described later). Proof key) is included. A detailed example of the DID data structure will be described later. The generated DID is incorporated into the eDoc file (for example, as one of the properties of the file).

Further, the processing device 110 generates metadata corresponding to the generated eDoc file. In this metadata, the attribute data received from the creation terminal 102 together with the document and the values of the attribute items (for example, DID, ID of the processing device itself, encoding date / time, encryption key information) generated by the processing device 110 itself are included. included. The encryption key information included in the metadata is information indicating a key for decrypting the eDoc file. When a common key method is used for encryption, the encryption key information is information indicating the common key. However, if the common key itself is included in the metadata in plain text, there is a risk that it will be misused by eavesdropping or interception, so the common key encrypted with the public key of the delivery destination user is incorporated into the metadata as encryption key information. ..

In addition, the processing device 110 saves the generated eDoc file and metadata in the built-in database.

(3) The processing device 110 transmits the generated metadata to the management system 200 and registers it. The management system 200 (metadata server 230) stores the received metadata.

(4) The processing device 110 distributes the generated eDoc file to the viewing terminal 104 designated as the distribution destination. This distribution may be a push type or a pull type, or both of them (for example, the viewing terminal 104 which is push-delivered at the time of creating the eDoc and is not received at that time receives the pull-type distribution). This distribution is performed via the local network 108 within the local system 100.

(5) Since the eDoc file received by the viewing terminal 104 is protected by encryption or the like, it cannot be viewed as it is. When the user wants to browse the eDoc file on the browsing terminal 104, he / she brings his / her authentication device 130 close to the card reader unit of the browsing terminal 104 to receive user authentication, and then browses the eDoc on the screen of the browsing terminal 104. To instruct. Upon receiving this instruction, the browsing terminal 104 accesses the management system 200 and requests the metadata of the eDoc. This request includes the DID of the eDoc.

(6) The management system 200 (metadata server 230) transmits the latest metadata of the eDoc requested from the browsing terminal 104 to the browsing terminal 104.

(7) When the browsing terminal 104 receives the requested metadata from the management system 200, the browsing terminal 104 and the user (authentication device) currently using the browsing terminal 104 are added to the distribution destination information included in the metadata. Determine if a combination with (certified at 130) is included. If it is not included, the user does not have the authority to view the eDoc on the viewing terminal 104, so the viewing terminal 104 does not open the eDoc file and displays an error message indicating that he / she does not have the viewing authority. If included, the user has the authority to view the eDoc file on the viewing terminal 104. In this case, the browsing terminal 104 decrypts the eDoc file using the encryption key information included in the metadata and displays it on the screen (that is, outputs it in a manner corresponding to the information content of the eDoc file).

You can set an expiration date for the metadata. The expiration date is obtained by adding, for example, the specified validity period or the validity period specified by the distributor or the like to the date and time when the metadata is transmitted. After the expiration date of the metadata has expired, the browsing terminal 104 cannot open (decrypt and display) the corresponding eDoc file unless the metadata is acquired again from the management system 200. If the browsing terminal 104 can communicate with the processing device 110 or the management system 200, the browsing terminal 104 acquires the latest metadata of the eDoc file instructed to the browsing target at the time of the instruction from the processing device 110 or the management system 200. Browsing is determined based on this latest metadata.

After the metadata is registered in the first management system 200, the delivery destination information and access authority information contained in the metadata are the distributor, or the person who has the authority to change the distribution destination (for example, has the authority to edit the data). It may be changed by the person who does it. Even if the user is designated as the delivery destination when the eDoc is created and registered, if the user is removed from the delivery destination due to a subsequent change, the browsing terminal 104 uses the latest metadata acquired from the management system 200. This is detected by the delivery destination information included in, and the eDoc file is not displayed.

Next, an example of the data content of the eDoc metadata 300 will be described with reference to FIG.

Among the items included in the metadata 300, first, "DID" is a document ID assigned by the processing device 110 that generated the eDoc. The "document name" is the name or title of the eDoc.

The "distributor ID" is a person who distributes the eDoc, that is, a person who performs a document registration operation from the creation terminal 102 to the processing device 110 and distributes the document via the processing device 110 (hereinafter, referred to as a distributor). User ID of.

The "encoding date and time" is the date and time when the document from the creation terminal 102 is encoded (protected) and the eDoc is created. The "processing device ID" is identification information of the processing device that has executed the protection processing. "Encryption information" is information related to encryption at the time of generation of the eDoc, and is the name of the encryption software used for encryption, the version of the encryption software, and the key for decrypting (decrypting) the encryption. Contains key information that represents. The key information is, for example, a key for decryption encrypted with the public key of each distribution destination user. "Keyword information" is a list of keywords extracted from the eDoc (or original data). This keyword information is used, for example, when searching for eDoc.

"Distribution destination information" is information representing a user and a viewing terminal designated by the distributor as the distribution destination of the eDoc. In the example of FIG. 3, the delivery destination information includes the user ID of the user and the ID (identification information) of the browsing terminal 104 that the user should use for browsing for each user of the delivery destination. When a plurality of browsing terminals 104 that can be used by the user to browse the eDoc are specified, a pair of the user ID of the user and the IDs of the plurality of browsing terminals 104 is incorporated into the delivery destination information.

As another example, when the delivery destination user adopts a method in which the eDoc can be browsed by using any of the browsing terminals 104 designated as the delivery destination, the delivery destination information includes the delivery destination user. A list of IDs of the above and a list of IDs of the viewing terminal 104 of the distribution destination are included. For example, as a candidate for the viewing terminal 104 of the distribution destination, a shared terminal of the department, a terminal provided in the living room or the conference room of the department, or the like may be assumed. It is not decided who the users in the organization will use the shared terminals and the built-in terminals such as the living room (also a kind of shared terminals), but at least the distributor knows what kind of terminal it is. It is also known that it is unlikely that it will be taken out of the organization without permission, so it is a suitable destination for confidential documents. When using eDoc on a shared terminal whose identity is known in this way, it is also possible to consider a usage pattern in which the delivery destination user may use any of the browsing terminals 104 designated as the delivery destination. Be done.

The "access authority information" is information representing the usage authority for the eDoc given to the distribution destination user by the distributor.

The "offline validity period" is information indicating the length of the validity period of the metadata. That is, even when the browsing terminal 104 is in a state where the management system 200 cannot be accessed (offline state), there is metadata acquired and cached at the time of the previous browsing of the eDoc, and the metadata is obtained from the acquisition date and time of the metadata. If it is within the "offline validity period", the browsing terminal 104 decrypts and displays the eDoc using the encryption key information in the metadata. On the other hand, if the user is in the offline state and the offline valid period of the cached metadata for the eDoc instructed to browse has already expired, the browsing terminal 104 does not decode the eDoc and therefore does not display it. While the browsing terminal 104 is accessible to the management system 200 (that is, in an online state), when the user instructs to browse the eDoc, the reading terminal 104 displays the latest metadata of the eDoc in the management system 200 (particularly, the metadata server 230). ) And use it.

The "original data information" is information indicating whether or not the original data before the eDoc is generated (encoded) is saved, and if it is saved, information indicating the storage location of the original data (for example, URL: Uniform Resource Locator). The original data here is, for example, a document sent from the creation terminal 102 to the processing device 110 (before protection processing is applied), or application data (for example, the document is page description language data) that is the basis of the document. In the case, the data of the word processing software before conversion to the data), or both of them.

The "document acquisition date and time" is the date and time when the viewing terminal 104 acquires the file (that is, the eDoc file) of the main body data of the eDoc. The "metadata acquisition date and time" is the date and time when the browsing terminal 104 acquires the latest metadata currently cached in the eDoc from the management system 200. The document acquisition date and time and the metadata acquisition date and time are not included in the metadata held in the management system 200, and the viewing terminal 104 adds the metadata acquired from the management system 200 for management by the own machine. ..

Further, among the metadata items shown in FIG. 3, the DID, the encoding date and time, the processing device ID, the encryption information, and the keyword information are information generated by the processing device 110. Further, the document name, the distributor ID, the distribution destination information, the access authority information, the offline validity period, and the original data information are derived from the document and attribute data sent from the creation terminal 102 to the processing device 110.

Next, the data contents of the information managed by each server 210-250 of the management system 200 will be illustrated.

First, an example of the data content managed by the user ID server 210 will be described with reference to FIG. The contractor data 212 of each contractor and the user data 214 of each general user are registered in the user ID server 210.

The contractor data 212 includes a contractor ID, contract content information, and a user list. The contractor ID is identification information of a contractor (for example, an organization or a department within the organization) who has contracted with the operator of the document management system. The user list is a list of user IDs of general users (for example, members belonging to the organization that is the contractor) who use this document management system according to the contract of the contractor.

The general user data 214 includes the user ID, password, user ID key information, public key certificate, default processing device ID, default browsing terminal list, and affiliation information of the general user. The user ID key information is the authentication information of the user used by the authentication device 130 of the user. A public key certificate is a digital certificate that certifies the user's public key. The default processing device ID is the ID of the processing device 110 in which the user is registered. Normally, the user is registered in the processing device 110 placed in the office to which the user belongs, and the processing device 110 becomes the default processing device for the user. The default browsing terminal list is a list of IDs of one or more browsing terminals mainly used by the user. The browsing terminal included in this list is a candidate for the distribution destination terminal when the eDoc is distributed to the user. The affiliation information is information that identifies the organization to which the user belongs, the department, and the like, and is, for example, the contractor ID of the organization or department.

Next, with reference to FIG. 5, an example of the data content managed by the DID server 220 is shown.

As shown in FIG. 5, the DID server 220 provides information on each item of the issue frame, grant destination processing device, key grant date / time, key end date / time, and issued DID list for each issue authority key issued to the processing device. Holds.

The issue authority key is key information (for example, a randomly generated character string) that is given to the processing device 110 by the DID server 220 and certifies the issue authority of the DID. By including the issue authority key given by the DID server 220 in the DID issued by the processing device 110, the processing device 110 proves that the DID was issued under the proper issue authority.

The issuance limit is the maximum number of DID issuance (the maximum number of documents to which DID can be assigned) given to the processing device 110 together with the issuance authority key. When the issue authority key and the issue frame pair are assigned by the DID server 220, the processing device 110 can assign a unique DID to each of the eDocs up to the maximum number indicated by the issue limit.

The grant destination processing device indicates the ID of the grant destination processing device 110 of the issue authority key (and the issue frame). The key grant date and time is the date and time when the issue authority key is granted to the processing device 110. The key end date and time is the date and time when the processing device 110 of the grant destination has finished using the issue authority key. That is, it is the date and time when the processing device 110 finishes assigning the DID to the upper limit number of eDocs indicated by the issuing frame assigned together with the issuing authority key. If the processing device 110 employs a mechanism for requesting the next issue authority key and issue limit from the DID server 220 after the issue limit is used up, the key termination of a certain issue authority key (called the first key) is adopted. Instead of explicitly recording the date and time, the key grant date and time of the issue authority key to which the processing device 110 is assigned next to the issue authority key may be used as the key end date and time of the first key. The issued DID list is a list of DIDs issued by the grantee processing device 110 using the issue authority key and the issue date. The processing device 110 of the grant destination notifies the DID server 220 of the DID each time the DID is issued using the issue authority key, and the DID server 220 includes the notified DID and the issue date in the DID. Add to the issued DID list corresponding to the issue authority key.

The metadata server 230 stores the metadata of each eDoc sent from each processing device 110. The data content of the metadata to be stored is the same as that illustrated in FIG. However, among the metadata items illustrated in FIG. 3, items used only by the browsing terminal 104 (document acquisition date and time, metadata acquisition date and time, etc.) are not managed by the metadata server 230.

Next, the data managed by the processing device management server 240 will be described with reference to FIG. The processing device management server 240 stores the status history 242 of the processing device 110 for each processing device 110 to be managed. The status history includes information on the status 244 of the processing device 110 at the time of creation and individual update (creation / update date and time) in association with the ID of the processing device 110.

Status 244 at each point in time includes installation location, contractor ID, administrator name, administrator contact information, registered user list, software information 246, hardware information 248, free disk space, and security certificate information. Is done. The installation location is information indicating the installation location of the processing device 110, and includes information such as an address, a building name, and the number of floors. The contractor ID is the ID of the contractor who is using the processing device 110. The administrator name is the name of the administrator of the processing device 110. The administrator is a user who manages the processing device 110 in a department or the like where the processing device 110 is installed. Administrator contacts are information (eg, email addresses) of the administrator's contacts. The registered user list is a list of user IDs of users registered in the processing device 110 (in other words, a user whose processing device 110 is a "default processing device").

The software information 246 includes an encoding software name, an encoding software version, an encryption software name, an encryption software version, and a name and version of other software installed in the processing device 110. Here, the encoding software is software that converts (encodes) the document input from the creation terminal 102 into a dedicated format of the document management system. Encryption software is software that encrypts a document (for example, one converted into a dedicated format).

The hardware information 248 includes items such as encoding circuit information, encoding circuit FW version, and manufacturer name of the processing device 110. The encoding circuit information is information indicating the model of the hardware circuit used for the encoding process. The encoding circuit FW version is the firmware (FW) version of the encoding circuit.

The free disk space is the free space of the secondary storage device such as a hard disk or a solid state disk of the processing device 110 at that time.

The security certificate information is information that identifies each security certificate currently installed in the processing device 110 (for example, a subject (subject) identifier of the certificate, an issuer (issuer) identifier, an issue date and time). Etc.).

Although not shown for the sake of complexity, the status 244 includes a type of font (list of font names) installed in the processing device 110, an address for network communication (for example, an IP address), and the like. Device ID of the secondary storage device (hard disk drive, etc.), information indicating the customization contents for connecting the processing device 110 to the processing of the core system of the installation organization, and the encryption key (communication path encryption) used by the processing device 110. The installation date and time of (for signing, etc.) is included.

Next, the database group held by the processing device 110 will be described with reference to FIG. 7. As shown, the processing device 110 includes a management information storage unit 112, a user DB 114, and a document DB 116.

The management information 112a is stored in the management information storage unit 112. The management information 112a includes items such as higher-level device address information, security certificate, encryption key, encoding software name, encoding software version, encryption software name, and encryption software version. The higher-level device address information is information on each communication address (for example, IP address, URL, etc.) of the higher-level device that manages the processing device 110. The management system 200 and each server 210-240 in the management system 200, or the in-house management system 150 described later and each server 152-156 in the management system 150 are examples of higher-level devices. The security certificate is a digital certificate used by the processing device 110 when performing secure communication based on a public key infrastructure with other devices on the network. The processing device 110 holds a security certificate of each higher-level device with which it often communicates. Further, the security certificate of each user who uses the creation terminal 102 or the viewing terminal 104 may be held. The encryption key is used for the purpose of encryption and decryption when the processing device 110 communicates with other devices on the network, digital signature by the processing device 110 (or generation of similar certification information), and the like. It is a pair of a private key and a public key given to the processing device 110 in the public key infrastructure, for example. The encoding software and the encryption software are software for encoding (conversion to a dedicated format) and encryption installed in the processing device 110, respectively.

The user DB 114 stores user information 114a of each user registered in the processing device 110 (in other words, a user who uses this processing device 110 as a "default processing device"). The user information 114a of each registered user includes items such as a user ID, a password, user ID key information, public key information, and a default viewing terminal list. These items have been described in the description of the data possessed by the user ID server 210 (see FIG. 4).

The eDoc file generated by the processing device 110 and the metadata corresponding to the eDoc file are stored in the document DB 116. Since the eDoc file and the metadata include the DID information, they can be associated with each other. Further, the original data (received from the creation terminal 102) before being encoded in the eDoc may be registered in the document DB 116 in association with the DID of the eDoc.

The creating terminal 102 and the browsing terminal 104 are used for each user who uses the terminal, such as user authentication information (user ID, password, etc.), default processing device ID, default processing device address information, and higher-level device (for example,). It stores the address information of the management system 200 and the in-house management system 150) described later, the security certificate of the processing device and the higher-level device, the encryption key used for communication path encryption, and the like.
<System processing flow>

When the processing device 110 is installed on the local network 108, the maintenance worker who maintains the processing device 110 can refer to the processing device 110 with information on users who use the processing device 110 and can be used by those users. The information of the creating terminal 102 and the browsing terminal 104 having sex is registered. The registered user information is also transferred to the user ID server 210 (or the local user ID server 152 described later), which is a higher-level device, and registered. If the number of users who use the processing device 110 increases or decreases after installation, the maintenance worker newly registers the increased user information for the processing device 110 or reduces the number of users. Perform work such as deleting the registration of information. Such additions and deletions are also notified to higher-level devices such as the user ID server 210, and the information held by the higher-level devices is updated accordingly. Further, the maintenance worker installs software (for example, in the form of a device driver of the processing device 110) that performs a process of requesting the processing device 110 to register and distribute the document to each of the creating terminals 102. Further, the maintenance worker registers information (for example, device name, communication address, wireless access setting) and the like for communicating with the processing device 110 in each browsing terminal 104.

Next, with reference to FIG. 8, a flow of processing when a document is registered and distributed via the document management system of the present embodiment will be described.

(1) -1: When the user (distributor) instructs the creation terminal 102 to register the document, the creation terminal 102 inputs the login authentication information (for example, the user ID and password, or the authentication device 130). Display the desired screen. When the distributor inputs the authentication information in response to the request, the creation terminal 102 transmits the authentication information to the processing device 110 via the local network 108.

(1) -2: The processing device 110 that has received the login authentication information performs user authentication using the information. Here, it is assumed that the user authentication is successful (confirmed that the user is correct). In the illustrated example, login authentication is performed using the login ID and password, but if the creation terminal 102 supports communication with the authentication device 130, login authentication may be performed using the authentication device 130.

(2) -1: When the login authentication is successful, the user selects a document to be registered in the document management system (and wants to be distributed to other users) from the documents stored in the creation terminal 102, and sends the document to the processing device 110. Instruct to register. Then, software (for example, a device driver) that serves as an interface with the processing device 110 is started, receives input of attribute data about the document from the user, and transmits the received attribute data and the data of the document to the processing device 110.

FIG. 9 shows an example of the attribute data input screen 400. This input screen 400 includes a delivery destination user selection menu 402, a delivery destination user list field 404, a delivery destination terminal selection menu 406, a delivery destination terminal list field 408, an access authority setting field 410, an offline validity period menu 412, and an option setting call. Includes button 414.

The delivery destination user selection menu 402 is a pull-down menu that lists the choices of the delivery destination user of the document. The user as an option is a user registered in the processing device 110, and a list of IDs and user names of those users as options may be obtained from the processing device 110. Alternatively, the creation terminal 102 acquires a list of users from the local user ID server 152 (see FIG. 12), which will be described later, which manages the information of the users of the document management system belonging to the organization, and the distributor can use other users in the organization. The user registered in the processing device 110 may be selected as the delivery destination. In this case, in the distribution destination user selection menu 402, each user is displayed in a display form that can be distinguished by the processing device 110 registered. For example, the user may be displayed in a different color or font for each processing device 110 in which the user is registered. Alternatively, the menu may have a hierarchical structure, the processing device 110 may be selected first, a list of users registered in the processing device 110 may be called, and a distribution destination user may be selected from the list. In the delivery destination user list column 404, a list of delivery destination users selected by the user is displayed. When the distributor selects the distribution destination user in the distribution destination user selection menu 402 and presses the "Add" button on the right side, the user ID or user name of the distribution destination user is added to the distribution destination user list column 404. Also, when the distributor selects a distribution destination user in the distribution destination user list field 404 and presses the "Delete" button on the right side, the distribution destination user is deleted from the distribution destination user list field 404 (that is, it is no longer a distribution destination). ).

The distribution destination terminal selection menu 406 is a pull-down menu that lists the options of the viewing terminal (viewer) 104 to which the document is distributed. The browsing terminal 104 as an option is registered in the processing device 110, and a list of IDs and terminal names of the browsing terminals 104 as options may be obtained from the processing device 110. Alternatively, the processing device 110 itself, the local user ID server 152 (see FIG. 12, details will be described later), and the like have a list of browsing terminals 104 in the organization registered in the document management system, and the creating terminal 102 is the creation terminal 102. The list may be presented to the distributor so that the viewing terminal 104 of the user registered in another processing device 110 in the organization can be selected as the distribution destination. As in the case of the distribution destination user list column 404, the distribution destination user list column 404 displays a list of the distribution destination viewing terminals 104 selected by the distributor in the distribution destination terminal selection menu 406.

It should be noted that the viewing terminal 104 of the distribution destination corresponding to the user may be specified for each distribution destination user. For this purpose, the creation terminal 102 is set to, for example, the default user from the processing device 110 (or the local user ID server 152 or the user ID server 210) each time the distribution destination user is selected in the distribution destination user list field 404. The list of browsing terminals may be acquired, and the list may be set in the distribution destination terminal selection menu 406. If the distributor does not explicitly select the distribution destination viewing terminal 104 for the distribution destination user, a specific one (for example, the top of the list) in the user's default viewing terminal list is automatically distributed. It is selected as the browsing terminal 104.

The access authority setting field 410 is a field for setting the access authority (use authority) of the delivery destination user for the document. In the illustrated example, check boxes for four authority items of view, process (edit), print, and copy are shown, and the distributor checks the check boxes of the items allowed to the distribution destination user for the document. ..

The offline validity period menu 412 is a pull-down menu indicating options for the length of the offline validity period to be set for the document. The distributor selects the period to be set for the document registered and distributed in the system this time from among several stages of the offline validity period shown in the offline validity period menu 412.

When the option setting call button 414 is pressed, the creation terminal 102 displays the option setting screen 420 illustrated in FIG. The option setting screen 420 includes a processing device designation field 422 and an original data setting field 424. The processing device designation field 422 includes a pull-down menu showing options for the processing device 110 to which the document is sent. This menu includes a list of processing devices 110 that can be selected from the creation terminal 102. The processing device 110 included in this list is first the processing device 110 (basically one, but there may be a plurality of them) in the local system 100 to which the creation terminal 102 belongs. Also, the processing device 110 of another local system 100 in the same organization may be included in the list. In the original data setting field 424, a pull-down menu for accepting the selection of whether to save the original data that is the source of the eDoc in the processing device 110 is displayed.

The attribute data sent from the creation terminal 102 to the processing device 110 in step (2) -1 includes the delivery destination information (user list and viewing terminal list), access authority information, and the like, which are set by the setting screen. Information such as offline validity period and original data information is included.

Returning to the description of FIG.

(2) -2: The processing device 110 receives a document (referred to as a target document) and attribute data from the creation terminal 102.

(3) -1: If the processing device 110 has not received the DID issuance authority and the issuance limit (or has used up the received issuance limit), the processing device 110 has a new issuance authority to the DID server 220 of the management system 200. And request a quota. If there is a remaining issuance limit received, the process proceeds to step (4) described later without making this request.

(3) -2: The DID server 220 transmits a new issuing authority and an issuing frame to the processing device 110 in response to a request from the processing device 110.

(4) The processing device 110 issues a DID using the issuing authority granted by the DID server 220, and assigns the DID to the eDoc (generated in the next step) generated from the target document.

(5) -1: The processing device 110 generates an encryption key for encrypting the target document by using, for example, a random number. The processing device 110 also converts the target document into an eDoc file. That is, an eDoc file is generated by encoding the target document into a dedicated format of the document management system and encrypting the encoding result with the encryption key generated earlier. The generated eDoc file contains the information of the DID generated earlier.

(5) -2: The processing device 110 generates the generated metadata of the eDoc. That is, metadata is generated by adding the DID generated earlier, the date and time of encoding, the ID of the processing device 110, the encryption information, and the like to the attribute data received from the creation terminal 102 (see FIG. 3). Here, the encryption information includes key information obtained by encrypting the encryption key used for encryption with the public key of the distribution destination user for each of the distribution destination users.

(5) -3: When receiving an instruction to save the original data from the creation terminal 102, the processing device 110 saves the document (or the application data on which the document is based) received from the creation terminal 102. To do.

(6) -1: The processing device 110 uploads the DID generated earlier to the DID server 220. The DID server 220 stores the DID uploaded from the processing device 110.

(6) -2: The processing device 110 uploads the metadata generated earlier to the metadata server 230. The metadata server 230 stores the metadata uploaded from the processing device 110.

(7) The processing device 110 transmits a distribution preparation completion notification for the eDoc to each viewing terminal 104 to which the generated eDoc is distributed. This notification includes information on the DID and eDoc document names generated earlier. In addition, this notification may include a thumbnail image of a representative page of eDoc (a predetermined page such as a first page).

By the way, a user (called a viewer) who uses the browsing terminal 104 receives user authentication by bringing his / her authentication device 130 close to the card reader unit of the browsing terminal 104. The browsing terminal 104 displays a list screen that displays a list of eDocs distributed to itself. FIG. 11 shows an example of the list screen 500. The list screen 500 of this example includes a notification mark 502, a document name 504 of the eDoc, and a viewability mark 506 for each eDoc. The notification mark 502 is a mark for notifying the viewer of the status of the eDoc. The eDoc status represented by the notification mark 502 includes "new arrival" (a state in which the document has not been opened after the document is delivered from the processing device 110. It is indicated by a "☆" in the figure) and "normal" (unmarked in the figure). ), "Expired" (the access validity period has expired. In the figure, it is indicated by "!"). Regarding the "expired" state, even if the eDoc file is stored in the browsing terminal 104, it cannot be browsed until the latest metadata about the eDoc is obtained from the processing device 110 or the management system 200. For the eDoc in the "normal" state, metadata whose access validity period has not expired is stored (cached) in the browsing terminal 104, so that the browsing terminal 104 temporarily refers to the processing device 110 and the management system 200. It can be viewed even if it is offline. The readability mark 506 indicates that the combination of the browsing terminal 104 and the user (authenticated by the authentication device 130) of the browsing terminal 104 indicates the delivery destination of the eDoc shown in the metadata of the eDoc cached in the browsing terminal 104. Indicates whether or not the combination of the user and the browsing terminal 104 is matched. If they match, the eDoc can be viewed (marked with "○" in the figure), and if they do not match, the eDoc cannot be viewed (marked with "x" in the figure). Further, for the eDoc that has received the distribution preparation completion notification but has not yet received the eDoc file and the metadata, the viewing terminal 104 does not have the information of the criterion for determining whether or not the combination of the distribution destinations is matched, so that the eDoc file and the metadata are viewed. The approval / disapproval mark 506 is a “-” mark indicating that it is undecided. In the illustrated example, the three eDocs from the top are new arrivals, and the eDoc main body (file and metadata) has not been acquired yet, so that the viewability mark 506 is a mark indicating undecided.

On the list screen (FIG. 11), the viewer selects the eDoc he / she wants to browse by, for example, a touch operation, and gives a browsing instruction. Here, it is assumed that a new eDoc (notification mark 502 is marked with "☆") is selected as a browsing target.

(8) Return to the description of FIG. Since the browsing terminal 104 does not hold the selected eDoc file and metadata to be browsed, it needs to be acquired from the processing device 110. Therefore, the browsing terminal 104 is connected to the processing device 110 on the local network 108 to which the browsing terminal 104 is connected by itself with the user ID key which is the authentication information acquired from the browsing device 130. It is transmitted to the processing device 110 on the network 108. The processing device 110 verifies whether the user ID key certifies the user registered in itself (user authentication). Here, it is assumed that the user authentication is successful. If the user ID key received from the browsing terminal 104 does not correspond to any user registered in the processing device 110, the processing device 110 uses the user ID key as a higher-level device (user ID server 210) related to user authentication. Alternatively, it may be sent to the local user ID server 152) to request user authentication.

(9) -1: In addition, the browsing terminal 104 sends a distribution request including the DID of the eDoc to be browsed selected by the viewer to the processing device 110 in response to the success of the user authentication in the processing device 110.

(9) -2: The processing device 110 returns the eDoc file and metadata corresponding to the DID included in the distribution request from the browsing terminal 104 to the browsing terminal 104.

(10) The viewing terminal 104 receives and stores (caches) the eDoc file and metadata sent from the processing device 110.

(11) The viewing terminal 104 has a distribution destination user and a distribution destination whose combination that matches the combination of itself and the viewer who is currently using it is shown in the distribution destination information (see FIG. 3) in the metadata. Determine if it is in a combination of terminals. If it is determined that there is no such file, the viewer cannot view the eDoc file on the viewing terminal 104. In this case, the browsing terminal 104 displays an error message indicating that browsing is not possible. In this case, the viewing terminal 104 may delete the saved eDoc file (and the corresponding metadata). On the other hand, when it is determined that the combination of the browsing terminal 104 and the viewer currently in use is in the distributor information in the metadata, the browsing terminal 104 browses the eDoc to the viewer. Allow. In this case, the browsing terminal 104 takes out the key corresponding to the viewer from the encrypted keys corresponding to each delivery destination user included in the encrypted information in the metadata, and uses the key as the viewer's secret. Decryption with a key (which is held by, for example, the authentication device 130) restores the decryption key required to decrypt the eDoc file.

(12) The viewing terminal 104 reproduces a document that can be viewed by decoding the eDoc file using the restored decryption key, and outputs the document (for example, screen display). Further, the browsing terminal 104 controls whether or not to accept an operation instruction for the document from the viewer according to the access authority information included in the metadata. The viewing terminal 104 basically does not save the decrypted document in a file. That is, after the end of browsing, the eDoc file and the metadata are saved in the non-volatile storage device of the browsing terminal 104, but the document of the decoding result is not saved.

Next, another example of the document management system of the present embodiment will be described with reference to FIG. In the example shown in FIG. 12, a plurality of local systems 100 exist in an in-house network which is a private network of an organization such as a company. The organization management system 150 is provided in the organization network. The organization management system 150 manages the processing in the organization and the information necessary for the processing in the document management system. That is, the management system 200 is operated by the service provider of the document management system and manages information and processing about a plurality of organizations that use the document management system, whereas the internal management system 150 manages the information and processing among the information and processing. The part related to the organization is managed under the control of the management system 200.

The organizational management system 150 has a local user ID server 152, a local DID server 154, and a local metadata server 156.

The local user ID server 152 manages information on users registered in the document management system among the members of the organization. The information of each user held by the local user ID server 152 is the same as the general user information held by the user ID server 210 shown in FIG. When a user who acquires and uses the processing device 110 (that is, a user whose processing device 110 is the "default processing device") is registered with respect to the processing device 110, the processing device 110 uses the registered user information. To the local user ID server 152 in the organization. The local user ID server 152 stores the received user information and sends it to the user ID server 210 of the central management system 200 via the wide area network 10. The user ID server 210 stores the received user information. Further, when the information of the user registered in the processing device 110 is changed, the administrator or the like changes the information of the user to the processing device 110. The processing device 110 transmits information on the changed contents of the user information (including, for example, the user ID, the item name of the changed information item, and the changed value of the item) to the local user ID server 152. The local user ID server 152 changes the information of the user stored by itself according to the received change. Further, the local user ID server 152 sends the received change content information to the central user ID server 210, and the user ID server 210 changes the user information held by the user ID server 210 according to the sent information. ..

The local DID server 154 receives and stores the DID issued by the processing device 110 in each local system 100 belonging to the organization network of the organization. The information held by the local DID server 154 is the same as the information held by the DID server 220 shown in FIG. Further, the local DID server 154 sends the DID information received from the processing device 110 to the central DID server 220, and the DID server 220 stores the information. Further, the local DID server 154 is given the DID issuance authority and the issuance frame from the central DID server 220, and within the range of the issuance frame, the DID is given to each processing device 110 under control based on the issuance authority. Issuance authority and issuance quota are granted.

The local metadata server 156 receives and stores the metadata of the eDoc generated by the processing device 110 in each local system 100 belonging to the organization network of the organization. The information held by the local metadata server 156 is the same as the information held by the metadata server 230. Further, the local metadata server 156 sends the metadata received from the processing device 110 to the central metadata server 230, and the metadata server 230 stores the metadata.

In the system of FIG. 12, the processing device 110 is a document registration (and delivery) request from a user who is not registered with himself but is registered with another processing device 110 in the same organization, or an eDoc file or meta. When a request such as a data acquisition request is received, the request is responded to through the internal management system 150.

As one example, a viewer registered in the processing device # 1 in the first local system 100 in the first department in the organization network can use the eDoc registered and distributed in the processing device # 1. Consider the case where the data is saved in the browsing terminal 104 of one's own, and then the eDoc is browsed by moving to a second department under the control of the processing device # 2. At this point, it is assumed that the metadata of the eDoc stored in the browsing terminal 104 is out of date (that is, the access validity period has expired). In this case, when the viewer performs an operation of opening the eDoc on the browsing terminal 104, the process shown in FIG. 13 is performed.

First, the browsing terminal 104 searches for the processing device 110 from the local network 108 of the second local system 100 to which it is currently connected. This finds processing device # 2. Since this processing device # 2 is a device different from the processing device # 1 that delivered the eDoc, it does not have the eDoc file or metadata.

(1) The browsing terminal 104 reads the user ID key (authentication information) from the viewer's authentication device 130.

(2) The browsing terminal 104 has a user ID acquired from the authentication device 130 for the processing device # 2 for user authentication for acquiring the latest metadata of the eDoc instructed to be browsed. Send the key.

(3) The viewing terminal 104 requests the processing device # 2 for the metadata of the eDoc. This request includes the DID of the eDoc.

(4) -1: Processing device # 2 checks whether the user ID key received from the browsing terminal 104 belongs to the user registered in itself (user authentication). In this example, since the viewer is registered in the processing device # 1 and not in the processing device # 2, the processing device # 2 is set to the preset address of the local user ID server 152. Then sends an authentication request including the user ID key. Further, the processing device # 2 sends the DID included in the metadata request from the browsing terminal 104 to the preset local DID server 154 to request authentication.

(4) -2: The local user ID server 152 verifies whether the user ID key received from the processing device # 2 belongs to the user registered in itself (user authentication). Since the viewer who owns the user ID key is registered in the processing device # 1, the user is also registered in the local user ID server 152, which is a higher-level device. Therefore, this user authentication succeeds. The local user ID server 152 returns a response indicating that the authentication was successful to the processing device # 2.

Further, the local DID server 154 checks whether the DID to be verified sent from the browsing terminal 104 is a legitimate DID, that is, whether it is a DID stored by itself. In this example, the DID of the eDoc is issued by the processing device # 1 and is also stored in the local DID server 154, which is a higher-level device related to the DID of the processing device # 1. Therefore, the DID is authenticated as legitimate. The local DID server 154 returns a response to the processing device # 2 to authenticate that the DID is valid.

(5) -1: Since the user authentication and the DID authentication are successful, the processing device # 2 continues the process for responding to the metadata request from the viewing terminal 104. That is, the processing device # 2 sends the metadata request including the DID to the preset address of the local metadata server 156.

(5) -2: When the local metadata server 156 receives a metadata request from the processing device # 2, the local metadata server 156 returns the metadata corresponding to the DID included in the request to the processing device # 2. When the eDoc metadata is changed by the distributor in the processing device 110, the change is immediately reflected in the local metadata server 156. Therefore, the metadata returned to the processing device # 2 at this time is to be viewed. This is the latest version of the eDoc metadata.

(6) Processing device # 2 transmits the metadata received from the local metadata server 156 to the browsing terminal 104.

(7) The viewing terminal 104 receives the metadata from the processing device # 2 and stores (caches) the metadata.

(8) The browsing terminal 104 refers to the distribution destination information of the latest received metadata, and checks the authority of the combination of the browsing terminal 104 and the viewer. That is, if there is a combination that matches the combination of the viewing terminal 104 itself and the viewer in the combination of the distribution destination user and the distribution destination terminal shown in the distribution destination information (see FIG. 3), it is determined that the viewing authority is granted. If not, it is judged that there is no viewing authority. If it is determined that there is no viewing authority, the viewing terminal 104 displays an error. When it is determined that the user has viewing authority, the viewing terminal 104 extracts the encrypted key corresponding to each delivery destination user included in the encrypted information in the metadata and the key corresponding to the viewer. Is decrypted with the viewer's private key (which is held by, for example, the authentication device 130) to restore the decryption key required for decrypting the eDoc file.

(9) Then, the viewing terminal 104 reproduces a document that can be viewed by decoding the eDoc file using the restored decryption key, and outputs the document (for example, screen display). Then, whether or not to accept the operation instruction for the document from the viewer is controlled according to the access authority information included in the metadata.

Next, referring to FIG. 14, a user registered in the processing device # 1 in the first local system 100 sends a document to the document management system in the second department under the control of the processing device # 2. Consider the processing flow when registering. It is assumed that the user (document distributor) is not registered in the processing device # 2.

(1) When the user instructs his / her own creation terminal 102 to register a document, the creation terminal 102 displays a screen requesting input of login authentication information. When the distributor inputs the authentication information (for example, the user ID and the password) in response to the request, the creation terminal 102 transmits the authentication information to the processing device 110 via the local network 108.

(2) The processing device # 2 determines whether the authentication information received from the creation terminal 102 belongs to the user registered in itself. In this case, the distributor is not registered in the processing device # 2. In this case, the processing device # 2 sends the authentication information to the upper local user ID server 152 and requests the authentication.

(3) The local user ID server 152 determines whether or not the received authentication information belongs to a user registered in itself (user authentication). In this example, since the distributor is a user registered in the processing device # 1, it is also registered in the local user ID server 152, and this user authentication succeeds. The local user ID server 152 returns information indicating that the user authentication was successful to the processing device # 2.

(4) Upon receiving a response from the local user ID server 152 to the effect that the authentication is successful, the processing device # 2 responds to the creation terminal 102 that the user authentication is successful.

(5) When the user authentication is successful, the creation terminal 102 sends the document selected by the user as the registration target and the attribute data input by the user to the processing device # 2.

(6) Processing device # 2 receives the document and attribute data from the creation terminal 102.

(7) -1: When the processing device # 2 has used up the DID issuance authority and the issuance limit, the processing device # 2 requests the local DID server 154 for a new issuance authority and the issuance limit. If there is a remaining issue slot received, the process proceeds to step (8) described later without making this request.

(7) -2: The local DID server 154 grants new issuance authority and issuance frame to the processing device # 2 in response to the request from the processing device # 2. When the issuance quota granted by the central DID server 220 is used up, the local DID server 154 requests the DID server 220 for a new issuance authority and issuance quota, and the issuance authority and issuance granted accordingly. The frame is used to grant the processing device # 2 the DID issuance right and the issuance frame.

(8) The processing device # 2 issues a DID using the granted issuing authority, and assigns the DID to the eDoc (generated in the next step) generated from the target document.

(9) -1: Processing device # 2 generates an encryption key for encrypting the target document, encodes the target document into the dedicated format of this system, and encrypts the encoding result with the encryption key generated earlier. Generates an eDoc file by doing so.

(9) -2: The processing device # 2 generates eDoc metadata by adding items such as the DID and the date and time of encoding generated earlier to the attribute data received from the creation terminal 102.

(10) Processing device # 2 uploads the generated DID to the local DID server 154 and the generated metadata to the local metadata server 156. The local DID server 154 adds the DID uploaded from the processing device # 2 to the issued DID list (see FIG. 5) corresponding to the issue authority key contained therein, and uploads the DID to the central DID server 220. .. The DID server 220 adds the DID uploaded from the local DID server 154 to the issued DID list (see FIG. 5) corresponding to the issue authority key. Further, the local metadata server 156 stores the metadata uploaded from the processing device # 2 and uploads it to the central metadata server 230. The metadata server 230 stores the metadata uploaded from the local metadata server 156.

The processing device # 2 distributes the generated eDoc to the distribution destination specified by the distributor. This process is the same as steps (7) to (12) of FIG.

(11) Further, the processing device # 2 transmits the generated eDoc file and the metadata to the creation terminal 102. The processing device # 2 may save the eDoc file and the metadata, or may delete the eDoc file and the metadata without saving the eDoc file and the metadata. When deleting without saving, those eDoc files and metadata are saved only in the default processing device # 1 in the processing device 110 group in the organization by the step (13) described later. Become. Whether or not the processing device 110, which is not the default processing device of the distributor, saves the eDoc file and the metadata registered / distributed by the distributor may be set in the processing device 110.

(12) The creation terminal 102 saves the eDoc file and the metadata received from the processing device 110 for later transfer to the processing device # 1, which is the default processing device of the distributor.

(13) When the distributor returns to the first department to which the creator terminal 102 belongs, the creator terminal 102 is a process that is the default processing device of the distributor on the first local network 108. Find device # 1. When the processing device # 1 is found, the creation terminal 102 registers the eDoc file and the metadata saved in the above step (12) in the processing device # 1. As a result, when the distributor wants to change the content of the metadata (for example, the distribution destination), he / she may access the default processing device # 1 and perform the change operation.

In the document management system of the present embodiment described above, only the processing device 110 and the viewing terminal 104 of the distribution destination have the main body information (that is, the eDoc file) of the document instructed to be distributed from the creation terminal 102 to the processing device 110. , Not available on other networks or devices. Therefore, the risk of leakage of the eDoc file is minimized. In particular, if the distribution destination of the eDoc file is limited to the browsing terminal 104 on the local network 108 that generated the eDoc, the eDoc will not go out from the local network 108 at all.

On the other hand, the eDoc metadata is registered in the central management system 200 and the in-house management system 150 for each organization, and even if the browsing terminal 104 moves to various places, the wide area network 10 or the organization's private network can be used. It is available through. When the browsing terminal 104 receives an eDoc browsing instruction from the user, the browsing terminal 104 acquires the latest metadata of the eDoc from the in-house management system 150 or the central management system 200, and the delivery destination information included in the latest metadata. Based on, it is determined whether or not the user may be permitted to view the eDoc. Even if the user is specified as the delivery destination at the time of registration / delivery of the eDoc, if the user is out of the delivery destination due to a subsequent change of the delivery destination, browsing is not permitted.

In the examples of FIGS. 13 and 14, processing device # 1 and processing device # 2 are both installed in the same organization, and it is assumed that the delivery destination user also belongs to that organization. User authentication was performed by the local user ID server 152 of the organization. On the other hand, when the viewer belongs to an organization different from the processing device # 2, neither the processing device # 2 nor the local user ID server 152 above it can authenticate the distributor. In this case, a higher-level user ID server 210 may authenticate the user of the distributor.

In the examples of FIGS. 13 and 14, another processing device # 2 mediates the communication between the browsing terminal 104 of the user registered in the processing device # 1 and the local user ID server 152 or the local metadata server 156. .. However, this is just one example. Instead, for example, the processing device # 2 responds to the browsing terminal 104 that it cannot be authenticated if the user is not registered in the processing device # 2 from the user's authentication information sent from the browsing terminal 104. You just have to do. In this case, the browsing terminal 104 requests the local user ID server 152 to authenticate using the address information of the host device registered in the own machine, and if the authentication is successful, the browsing terminal 104 is required to access the local metadata server 156. Get the metadata.

The example of FIG. 13 is an example in which the user moves to the local system 100 under the control of the processing device 110 other than the default processing device of the user in the organization to which the user belongs to browse the document. there were. However, users may be able to view documents delivered from their default processor outside of their own organization. In this case, the user's browsing terminal 104 is authenticated by the user ID server 210 in the central management system 200, and acquires the metadata of the document to be browsed from the metadata server 230.
<Example of DID>

Next, with reference to FIG. 15, the configuration of the DID 600 used for the identification information of the eDoc in the document management system will be described.

As shown in the figure, the DID 600 includes an issue authority key 602, processing device unique information 604, an issue date 606, an issue proof key 608, and an issue number 610. The number of digits of the illustrated DID 600 and its constituent elements 602 to 610 is merely an example.

The issue authority key 602 is key information that identifies the issue authority given to the processing device 110 by the DID server 220. When the DID server 220 receives a request for issuance authority and issuance frame from the processing device 110, the DID server 220 generates an issuance authority key 602, and the issuance authority key 602 is used together with the numerical value of the issuance frame (for example, 100 documents). Send to. In the case of a system configuration in which the local DID server 154 is interposed between the DID server 220 and the processing device 110, the DID server 220 sets the issue authority key and the issue frame to the local DID server 154, for example. Grant multiple sets at once. This grant may be regarded as the DID server 220 requesting the local DID server 154 to grant the plurality of sets of issue authority keys and issue slots to the processing device 110. When the local DID server 154 requests the issuing authority from the processing device 110 under its control, the local DID server 154 may grant the given issuing authority key and the unassigned one in the issuing frame to the processing device 110. ..

The processing device-specific information 604 is information unique to the processing device 110 that issued the DID. That is, the processing device 110 that issued the DID 600 can be uniquely identified by examining the processing device-specific information 604 in the DID 600. The processing device specific information 604 is held by the processing device 110.

The issue date 606 is a character string indicating the date when the DID was issued. The issue date of the DID is also the date when the eDoc to which the DID is assigned is generated (encoded).

The issuance certification key 608 is key information certifying that the processing device 110 (specified by the processing device unique information 604) has issued the DID using the issuing authority indicated by the issuing authority key 602. The issuance certification key 608 is a value obtained by, for example, encrypting the issuance authority key 602 with the private key of the processing device 110. In this case, if the value obtained by decrypting the issue certification key 608 with the public key of the processing device 110 matches the issuing authority key 602, the DID 600 uses the issuing authority key 602 to use the processing device 110. It is proved that it was issued by. Further, the value obtained by encrypting the value of the portion of the DID 600 excluding the issue authority key 602 (or the hash value of a predetermined number of digits generated from the value) with the private key of the processing device 110 may be used as the issue certification key 608. .. In this case, the value obtained by decrypting the issue certification key 608 with the public key of the processing device 110 does not contradict the value of the portion excluding the issue certification key 608 of the DID 600 (for example, the decryption result matches the hash value of that value). , The DID 600 is issued by the processing device 110 based on the issuance authority key 602, and it is proved that the part other than the issuance certification key 608 of the DID 600 has not been tampered with.

The issue number 610 is a serial number indicating the number of the DID 600 issued by the processing device 110 using the issue authority key 602. The maximum value that the issue number 610 of the DID 600 generated by using a certain issue authority key 602 can be is the value of the issue frame (number of documents) given by the DID server 220 (or the local DID server 154) together with the issue authority key 602. Is.
<Change delivery destination after registration>

By the way, after registering the eDoc in the document management system, the distributor (or another person who has been given the authority to change the distribution destination) deletes or adds the distribution destination, and gives the access authority to the eDoc to those distribution destinations. You may want to fix it. In such a case, the distributor accesses, for example, the default processing device 110 by using the creation terminal 102 or the viewing terminal 104 (hereinafter collectively referred to as the user terminal), specifies the DID of the target eDoc, and specifies the distribution destination (hereinafter referred to as the user terminal). Or, instruct to execute the editing process of access authority).

The processing device 110 that receives this instruction indicates that the user who issued the instruction by user authentication is the correct distributor or the like of the target eDoc (a general term for the distributor and other persons who have been given the authority to change the distribution destination). If confirmed, the delivery destination and access authority edit screen are provided to the user terminal. The edit screen may be the same as the input screen 400 shown in FIG. The distributor, etc. adds or deletes the distribution destination user and the viewing terminal, and changes the access authority content on the edit screen. When the distributor or the like makes a necessary change on the edit screen and then performs an operation to confirm the change, the processing device 110 reflects the change in the stored metadata of the eDoc and the change. Notify the upper local metadata server 156 and the metadata server 230 of the changed contents. The local metadata server 156 and the metadata server 230 reflect the notified changes in the stored metadata of the eDoc. For example, even if the user is designated as the delivery destination at the time of delivery, if the user is deleted from the delivery destination due to a subsequent change, the eDoc cannot be viewed. Further, when the delivery destination information in the metadata of the eDoc is changed in this way, the processing device 110 is included in the delivery destination information before the change, but is included in the delivery destination information after the change. An instruction to delete the eDoc file (and the corresponding metadata) may be sent to the browsing terminal 104 of the delivery destination.

In the above example, the processing device 110 has received an instruction to change the delivery destination or access authority of the eDoc, but instead of or in addition to this, the higher-level device, that is, the management system 200 (metadata server 230) or the management within the organization. System 150 (local metadata server 156) may receive the change instruction. In this case, the host device transmits new metadata changed in response to the change instruction to the processing device 110 (and the local metadata server 156 of the organization to which the processing device 110 belongs) that generated the eDoc. Then, it is made to replace the existing metadata in the processing device 110.
<Status management of processing equipment>

Next, control based on the status management of the processing device 110 will be described.

The processing device 110 periodically notifies the management system 200 of its status. In the management system 200, the processing device management server 240 adds the received status to the status history 242 for the processing device 110 in association with the date and time of the reception. Further, the processing device management server 240 checks the received status, and controls whether or not the service can be provided to the user of the processing device 110 according to the result of the check.

The status periodically transmitted by the processing device 110 to the processing device management server 240 includes the same items as the status 244 of the processing device illustrated in FIG. 6 (however, the status 244 is not changed by the processing device 110. The installation location, encoding circuit information, processing device manufacturer name, etc. do not have to be sent regularly).

The processing device management server 240 executes, for example, the process illustrated in FIG. 16 based on the status sent from the processing device 110.

First, when the processing device management server 240 receives the status from the processing device 110 (S100), the processing device management server 240 collates the value of the inspection target item in the status with the reference of each item (S102). The items to be inspected include the name and version of the encryption software, the name and version of the encoding software, the security certificate installed in the processing device 110, and the encryption key installed in the processing device 110 (for example, the private key and the public key). Pair. Information (used for communication path encryption, signing purposes, etc.) (for example, key identification information, installation date and time, etc.), encoding circuit name and firmware (FW) version, installed font type, disk (2) Free space of (next storage) is included. In addition, as an example of the criteria for each item, the encryption software, encoding software, and firmware must be the latest version (or a certain version or later), and the free disk space must be above a predetermined threshold. There is no blacklisted certificate among the installed security certificates, the specified period has not passed since the date when the encryption key of the processing device 110 was installed, and the specified (that is, in advance) There is a certain type of font installed.

For example, the encryption key used by the processing device 110 for communication path encryption, signature, etc. is preferably changed to a new key on a regular basis in order to maintain its security. Therefore, after a predetermined period has elapsed from the installation date and time. Judges that it does not meet the criteria and disables the service provision (or issues a warning that it will not be possible) and prompts the exchange for a new key.

Next, the processing device management server 240 determines whether or not any of the status inspection target items received from the processing device 110 does not meet the criteria of the item (S104), and if not, receives the status this time. The processing of the processing device 110 is completed. When there is an item that does not satisfy the criteria in S104, the processing device management server 240 notifies the processing device 110 that the service is not possible (S106). Upon receiving this notification, the processing device 110 stops the document registration (delivery) service for the document management system of the present embodiment. That is, the document registration (delivery) request from the creation terminal 102 is not accepted, and a message indicating that the service is stopped is returned.

Such control reduces the possibility that the processing apparatus 110 will generate an eDoc of quality that does not meet the criteria. For example, according to this control, the service of the processing device 110 is stopped before the old encryption software generates an eDoc having insufficient encryption strength. In addition, the service is stopped before a situation occurs in which an error occurs in the eDoc generation process due to a small amount of free disk space or the firmware is old and a document is leaked due to the error. Further, the service is stopped before the image quality of the eDoc deteriorates due to the processing device 110 having no predetermined font replacing the font in the document with another font and encoding the font. Since the firmware of the encoding circuit is old, the image size of the document supported by the latest firmware is not supported, and the situation that the image size of the eDoc is limited is less likely to occur.

It should be noted that the status inspection target items may be classified into items that affect the security of eDoc and items that do not, and the processing device 110 may stop the service only when the former item does not meet the criteria. .. If the latter item does not meet the criteria, a warning is sent to the processing device 110 and its administrator to urge them to resolve the problem with that item. In response to this warning, the administrator of the processing device 110 repairs the processing device 110 for items that can be dealt with by himself / herself, and dispatches maintenance workers for items that require the intervention of specialized maintenance workers. Ask the operator. Further, even if it is found that a specific item among the inspection target items does not meet the standard, the processing device management server 240 automatically arranges to dispatch a maintenance worker to the processing device 110. Good.

A modified example of the process of FIG. 16 will be described with reference to FIG.

In the procedure of FIG. 17, the level classification of emergency items and other items is introduced into the inspection target items of the status of the processing device 110. The urgent item is an item that has a great influence on the security quality of the eDoc generated by the processing device 110 and the security of the document management system. If the eDoc generated by the processing device 110 whose item does not meet the standard is not sufficiently secure, or when the processing device 110 whose item does not meet the standard continues to operate, the processing device 110 of the document management system It may become a security hole (vulnerability). Examples of targets of such urgent items include cases where a vulnerability is found in the version of the encryption software, the security certificate installed in the processing device 110, and the encryption key installed in the processing device 110. ..

One way to avoid the problem of the urgent item not meeting the standard is to stop the processing device 110 whose urgent item does not meet the standard and dispatch a maintenance worker to correct or repair the urgent item. Is. However, there is an inconvenience that the user cannot use the processing device 110 until the modification is completed.

Therefore, in the procedure of FIG. 17, when the processing device management server 240 finds an item that does not satisfy the criteria in S104, it determines whether or not the item is an urgent item (S110). Then, in the case of an urgent item, the setting information for correcting the defect of the urgent item is remotely installed from the processing device management server 240 to the processing device 110 via the wide area network 10 (S112). Examples of setting information for fixing the defect of the urgent item are the latest version of encryption software, the latest version of the security certificate in which the vulnerability to the security certificate in which the vulnerability was found has been resolved, and the vulnerability of the processing device 110. There is a new key pair that replaces the private / public key pair whose gender has been found.

For example, in the case of a new key pair, the processing device management server 240 prepares a phrase for generating the new key pair, generates a key pair using the phrase, and processes the generated key pair in a secure manner. It is transmitted to the device 110 for remote installation.

As a result, the setting information for the urgent items that do not meet the criteria in the processing device 110 is updated to those that meet the criteria. Further, in response to this update, the value of the urgent item in the status of the processing device 110 is updated.

If the determination result of S110 is No (does not correspond to an urgent item), the processing device management server 240 sends a warning to the processing device 110 or the administrator indicating an item that does not meet the criteria, and the processing device 110 thereof. Arrange for the dispatch of maintenance workers to correct the items (S114). For items that are not urgent items, even if the processing device 110 continues to operate as it is, a serious security problem is unlikely to occur. Therefore, the processing device 110 is not stopped and a maintenance worker is dispatched to deal with the items. Since the processing device management server 240 does not have to be remotely installed for items other than the urgent items, it is possible to avoid an increase in the load on the processing device management server 240.

In the example of FIG. 17, the setting information about the urgent item is installed from the processing device management server 240 to the processing device 110 from the top down, and the setting information is installed in the processing device 110 accordingly, and the status of the processing device 110 The value of the urgent item is updated. On the other hand, for status items other than emergency items, the individual processing device 110 sets or changes the value, for example, by a maintenance worker, and the setting information corresponding to the item (for example, the latest version of the encryption software). Version) is installed. The setting or change of the status item value made in the processing device 110 in this way is notified to the higher-level processing device management server 240, and the processing device management server 240 responds to the notification and has its own processing device 110. Change the value of the corresponding item in the status.
<DID verification>

The management system 200 notifies the DID issued by the processing device 110, sends a metadata request (this request includes the DID) from the viewing terminal 104, or requests the user or the like to verify the DID. When received from, verify whether the DID is correct.

In this case, the DID server 220 verifies the following points with respect to the target DID 600 (see FIG. 15).

(A) There is no contradiction between the issue authority key 602 in the DID 600 and the processing device specific information 604.

The issue authority key 602 of the DID server 220 is recorded in the information (see FIG. 5) recorded by the DID server 220 as an issue authority key to which the processing device 110 indicated by the processing device unique information 604 is assigned. Find out if it is. If it is not recorded, the issue authority key 602 has never been issued to the processing device 110 indicated by the processing device unique information 604, and the two are inconsistent. In this case, the DID 600 is an invalid DID.

(B) The issue authority key 602 in the DID 600 and the issue date 606 do not contradict each other.

The DID server 220 records the key grant date and time and the key end date and time in association with the issue authority key (see FIG. 5). If the issue date 606 in the DID 600 deviates from the period from the key grant date and time recorded in association with the issue authority key 602 in the DID 600 to the key end date and time, the issue authority key 602 and the issue date and date 606 is inconsistent. In this case, the DID 600 is an invalid DID.

(C) There is no contradiction between the issuance authority key 602, the processing device unique information 604, and the issuance certification key 608 in the DID 600.

The DID server 220 decrypts the issuance certification key 608 with the public key of the processing device 110 indicated by the processing device unique information 604, and the issuance certification key indicated by the decoding result matches the issuance certification key 608 in the DID 600. Determine if. If they do not match, there is a contradiction between the three, and the DID 600 is known to be fraudulent.

(D) The issue number 610 in the DID 600 is consistent with the issue frame corresponding to the issue authority key 602.

The DID server 220 records the issuing frame assigned to the processing device 110 together with the issuing authority key 602 (see FIG. 5). If the issue number 610 in the DID 600 is larger than the issue limit recorded corresponding to the issue authority key 602, the DID is invalid.

(E) The issue number 610 in the DID 600 is consistent with the issue number of the issued DID including the same issue authority key as the issue authority key 602 of the DID 600. This standard is used to verify whether or not the newly issued DID is inconsistent with the already issued one when the processing device 110 notifies the newly issued DID.

The DID server 220 records information on the DID issued using the issue authority key and the issue date and time in association with the issue authority key (issued DID list in FIG. 5). The DID server 220 checks whether or not any of the issued DIDs having the same issue authority key as the issue authority key 602 of the DID 600 to be verified has the same issue number as the issue number 610 in the DID 600. If there is such a thing, the DID 600 is determined to be illegal.

(F) The combination of the issue date 606 and the issue number 610 in the DID 600 is consistent with the combination of the issue date and the issue number of the issued DID including the same issue authority key 602 as the issue authority key 602 of the DID 600. thing.

In the DID server 220, the combination of the issue date 606 and the issue number 610 of the DID 600 to be verified includes the issue date and the issue number of each issued DID including the same issue authority key as the issue authority key 602 of the DID 600. Whether or not there is a contradiction with the combination of, that is, whether or not there is something whose context is reversed. For example, when an issued DID having a smaller issue number is found even though the issue date is later than that of the DID 600, the DID 600 and the issued DID are inconsistent, that is, the context is reversed. When such a contradiction is found, it is determined that only the DID 600 to be verified or both this and the issued DID are invalid.

When the DID server 220 determines that a certain DID is invalid by verification according to the above criteria, the DID server 220 notifies the administrator of the processing device 110 related to the illegal DID by e-mail or the like. .. The warning notification includes a message notifying that a DID disguised as issued by the processing device 110 has been found. The administrator takes measures to strengthen security by the notification. The administrator of the processing device 110 and its contact information may be obtained from the information (see FIG. 6) of the processing device management server 240. The processing device 110 related to the invalid DID to which the warning notification is sent is the processing device 110 indicated by the processing device unique information 604 included in the DID. Further, the processing device 110 that has been given the same issue authority key as the issue authority key included in the invalid DID in the past may be the destination of the warning notification.
<Processing when a vulnerability is found in the eDoc encryption>

Next, the processing when a vulnerability is found in the encryption software used for encryption when the eDoc file is generated will be described. When the operator of the document management system learns that a vulnerability has been found in a specific version of the encryption software used by any of the processing devices 110, the management system 200 is vulnerable to each processing device 110. Send a notification. The vulnerability notification includes information on the software name and version of the encryption software in which the vulnerability was found. When the in-house management system 150 exists, the vulnerability notification is passed from the management system 200 to the in-house management system 150, and the in-house management system 150 transmits the vulnerability notification to each processing device 110 under its control. .. In response to this notification, the processing device 110 executes the process illustrated in FIG.

When the processing device 110 receives a vulnerability notification (S200) from a higher-level device (management system 200 or internal management system 150), the processing device 110 encrypts the vulnerability using the version of the encryption software in which the vulnerability indicated by the notification is found. Identify the converted file (S202). The document DB 116 of the processing device 110 stores each eDoc file generated by the processing device 110 and its metadata, and the name of the encryption software used to generate each eDoc from the metadata of each eDoc file. You can see the version (see the metadata structure example shown in Figure 3). In S202, the processing device 110 identifies an eDoc in which the combination of the encryption software name and the version included in the metadata matches the combination shown in the vulnerability notification.

Next, the processing device 110 re-encrypts each of the specified eDoc files with the version of the current encryption software installed in its own machine (S204). In this example, it is assumed that the encryption software of the processing device 110 has been appropriately upgraded, and that no vulnerabilities have been found in the version of the current encryption software of the processing device 110. In general, it is considered that vulnerabilities are often found in the version of the encryption software used by the processing device 110 in the past. In the unlikely event that the version of the encryption software that is the target of the vulnerability notification is the encryption software of the current version of the processing device 110, the processing device 110 downloads the latest version of the encryption software from a higher-level device or the like. Re-encrypt using the latest version. If a vulnerability is found in the latest version of the encryption software currently in use, the host device has a newer version of the encryption software in which the vulnerability has been eliminated, or the information of the distributor of the software is displayed. It can be assumed that it has. In the re-encryption, for example, the target eDoc file is decrypted using the decryption key information recorded in the metadata corresponding to the eDoc file, and the decryption result is newly generated using the encryption key. Encrypt using a non-vulnerable version of encryption software. It is assumed that the metadata stored in the processing device 110 includes the decryption key information in a state of being encrypted with, for example, the public key of the processing device 110 (similarly, the metadata to be sent to the higher-level device). May include the decryption key encrypted with the public key of the higher device).

The processing device 110 updates the metadata of the eDoc file in response to the re-encryption (S206). That is, the encoding date and time and encryption information (encryption software name, version information and key information) in the metadata (see FIG. 3) are re-encrypted and dated, the encryption software name and version used for re-encryption, and It is rewritten to the information of the decryption key for decrypting the encryption. Then, the processing device 110 saves the updated metadata (for example, saves it as the latest metadata for the eDoc file) and uploads it to the higher-level device. The host device saves the uploaded updated metadata.

After that, the processing device 110 executes a process for delivering the eDoc file obtained by the re-encryption to each viewing terminal 104 of the delivery destination indicated in the delivery destination information of the metadata (S208). That is, for example, a distribution preparation completion notification is sent to each viewing terminal 104 of the distribution destination (see step (7) in FIG. 8). In addition to the DID and the document name, this notification may include information indicating that the eDoc to be distributed is an updated version of the already distributed eDoc. When the viewing terminal 104 that has received the distribution preparation completion notification instructs the viewing target of the eDoc that has received the distribution preparation completion notification by re-encryption on the list screen 500 (see FIG. 11) of the viewing terminal 104. The browsing terminal 104 overwrites the eDoc file acquired from the processing device 110 and the eDoc file before re-encryption in the own machine in response to the instruction. Further, the browsing terminal 104 saves the updated metadata received together with the eDoc file as the latest metadata of the eDoc. As a result, the eDoc file encrypted by the vulnerable encryption software and the corresponding metadata disappear from the viewing terminal 104, and the eDoc file and the metadata re-encrypted by the encryption software in which the vulnerability has not been found. Is replaced by.

The processing device 110 may explicitly send a deletion notification including the DID of the eDoc to each viewing terminal 104 of the distribution destination when or before sending the re-encrypted viewing preparation completion notification of the eDoc. .. In this case, each browsing terminal 104 deletes the existing eDoc file (the one before re-encryption) having the DID according to the instruction. At this time, the existing metadata may also be deleted.
<Another example of specifying the delivery destination terminal>

In the examples described so far, the distribution destination user and the viewing terminal 104 that can be selected by the distributor on the UI screen of the creation terminal 102 (input screen 400 in FIG. 9) are registered in the processing device 110 in the same local system 100. User and browsing terminal 104, or user and browsing terminal 104 registered in the organizational management system 150 of the same organization (in this case, user and browsing terminal 104 registered in another processing device 110 are also designated as distribution destinations. It was possible).

However, there are cases where a user in the organization wants the guest to temporarily view a document such as a conference memo created in a conference with a person (guest) outside the organization. In such a case, it is a complicated task to register the guest or the guest's mobile terminal in the processing device 110 or its higher-level device, or to cancel the registration after the browsing is completed.

Therefore, in the present embodiment, the eDoc can be delivered to the viewing terminal 104 that can be determined to be the guest terminal under certain restrictions.

For example, the terminal of the user in the vicinity of the creation terminal 102 is regarded as a guest terminal, and the guest terminal is added to the options of the distribution destination terminal selection menu 406. Alternatively, the user's terminal in the vicinity of the processing device 110 is regarded as a guest terminal, and the guest terminal is added to the options of the delivery destination terminal selection menu 406. It is considered that the creation terminal 102 and the processing device 110 are often installed in a room of an organization building (for example, a department room or a conference room), and a person who is near the creation terminal 102 or the processing device 110 is a conference. It is assumed that the person is entering the room with appropriate permission for such reasons.

For example, the processing device 110 or the creating terminal 102 searches for a partner terminal capable of communicating using short-range wireless communication such as Bluetooth Low Energy (registered trademark), and finds the partner terminal or the partner terminal among those partner terminals from its own device. A terminal whose distance (some of the short-range wireless communications can determine the communication distance between the own device and the other party) is equal to or less than a predetermined threshold is determined as a guest terminal in the vicinity of the own device. Then, in the distribution destination terminal selection menu 406, the terminal name of the guest terminal detected by the processing device 110 or the creation terminal 102 is displayed as an option in a display mode different from the pre-registered browsing terminal 104 in the organization. Will be done. The distributor can select the guest terminal as the distribution destination.

Here, the processing device 110 or the creating terminal 102 may select not all the terminals in the vicinity of the own machine but only the terminals in the vicinity that satisfy a predetermined condition as guest terminals as the delivery destination options. For example, the condition is that the version of the viewer application or other specific software installed in the terminal is a certain version or higher, or that it is not included in the predetermined list of rejected terminals. Conceivable.

It is generally considered that the user carrying the guest terminal is not registered in the processing device 110, the local user ID server 152, or the like. Therefore, when the eDoc file or metadata is requested from the guest terminal designated as the document delivery destination, the processing device 110 may deliver the data without user authentication. Further, in the metadata of the eDoc delivered to the guest terminal, a deletion instruction to delete the eDoc file and the metadata from the guest terminal when the deletion condition is satisfied is incorporated. The deletion condition is, for example, when the screen display of the eDoc is finished, or when a predetermined permission period has elapsed from the time of distribution. When the deletion condition is satisfied, the guest terminal deletes the eDoc file and the metadata from the own terminal. As a result, the risk of eDoc leakage from the guest terminal is reduced.
<Countermeasures for requests from terminals other than the delivery destination terminal>

The example described so far is a push-type distribution form in which the processing device 110 distributes the eDoc (or the corresponding distribution preparation completion notification) to the viewing terminal 104 designated as the distribution destination by the distributor. It was.

However, as another example, a list of eDocs held by the processing device 110 is provided to the browsing terminal 104 in response to a request from the browsing terminal 104, and a browsing target selected by the user is distributed to the browsing terminal 104. A pull-type delivery form is also conceivable. In the case of the pull-type distribution form, it is conceivable that the distribution destination user accesses the processing device 110 from the viewing terminal 104 that is not designated as the distribution destination and requests the eDoc. There are the following methods as measures to be taken by the processing device 110 when such a request is made.

(Method 1) When the processing device 110 receives an eDoc distribution request from the browsing terminal 104, the browsing terminal 104 is the browsing terminal whose delivery destination information is the latest metadata of the eDoc. Judge whether it corresponds to. Then, if it is determined that it does not apply, neither the eDoc file (main body) nor the metadata is transmitted to the viewing terminal 104. If it is determined that the data is applicable, it is further determined whether or not the user who made the distribution request (or the combination of the user and the viewing terminal 104) is included in the distribution destination information of the metadata, and includes the user. If it is, it may be delivered, and if it is not included, it may not be delivered.

As described above, in the method 1, the eDoc (main body file and metadata) is not delivered to the browsing terminal 104 that does not correspond to the delivery destination specified by the distributor.

(Method 2) In this method, the processing device 110 even if the browsing terminal 104 that has sent the eDoc delivery request does not correspond to the browsing terminal 104 of the delivery destination specified in the delivery destination information of the metadata of the eDoc. When the user who issued the request (that is, the user who is using the browsing terminal 104) is included as the delivery destination in the delivery destination information, the main body file and metadata of the eDoc are transmitted. However, in this case, the processing device 110 incorporates flag information indicating that it cannot be saved in the eDoc file and the metadata to be transmitted. The browsing terminal 104 displays the eDoc file and the metadata containing the flag information that cannot be saved, but does not accept the save instruction from the user, and when the user's browsing is completed, they are discarded without being saved.

In addition, instead of the method of not saving the eDoc file and the metadata transmitted to the browsing terminal 104 that is not designated as the distribution destination in the browsing terminal 104, it is conceivable to allow the saving once. However, in this case, when the browsing terminal 104 subsequently tries to open the eDoc file again, the browsing terminal 104 requests the processing device 110 or the like for the latest metadata of the eDoc (this is a request for permission to browse). However, in response to the request, the processing device 110 determines whether the combination of the browsing terminal 104 and the requested user is included in the distribution destination information of the metadata, and if not, the browsing terminal 104. Send an instruction to delete the eDoc. The browsing terminal 104 deletes the stored eDoc file and the corresponding metadata in response to the instruction. Note that the processing device 110 may simply respond to the latest metadata instead of explicitly sending the eDoc deletion instruction to the browsing terminal 104 that requested the latest metadata. In this case, the browsing terminal 104 determines whether the latest metadata received includes the combination of the own device and the current user, and if not, does not open the eDoc and saves it. You may delete the existing eDoc file.

In the example of FIG. 18 described above, the eDoc file after re-encryption inherits the DID of the eDoc file before re-encryption, but the e-Doc file after re-encryption is different from the eDoc file before re-encryption. DID may be given. In this case, the processing device 110 sends an explicit deletion instruction including the DID of the eDoc file before re-encryption to each viewing terminal 104 of the distribution destination, so that the vulnerable pre-encryption is performed. Prevent the eDoc file from remaining on the viewing terminal 104. In addition, the association information indicating that the eDoc file after re-encryption and the eDoc file before re-encryption correspond to the same document is the metadata corresponding to the eDoc file after re-encryption, or Recording is performed in the processing device 110 (or in the upper DID server 220 or the local DID server 154). When recording in the metadata corresponding to the re-encrypted eDoc, for example, the DID of the eDoc before re-encryption may be included in the metadata as an item of, for example, "DID before update".

In the above example, the eDoc file is not distributed to terminals other than the browsing terminal 104 that can connect to the local network 108 to which the processing device 110 in which the eDoc file is registered is connected. However, in a special case where security is considered to be ensured, the eDoc file may be distributed from the processing device 110 to a browsing terminal 104 connected to another network. Such an example will be described below.

In this example, the processing devices 110 are grouped, and the distribution of the eDoc held by a certain processing device 110 is also permitted to the viewing terminal 104 connected to another processing device 110 belonging to the same group. The group is defined according to the contractor's request. For example, the processing devices 110 corresponding to the same contractor may be grouped together, or the processing devices 110 installed at the same base (factory or office) or department of the contractor company may be grouped. A group is defined. Further, when a plurality of contractors collaborate, the processing devices 110 installed in the departments in which the contractors collaborate may be grouped together.

FIG. 19 illustrates a group set up for two contractors, company X and company Y. In this example, Company X is first set to Group A consisting of all the processing devices 110 installed in Company X. In addition, groups B consisting of processing devices 110 installed at the head office in X and groups C1, C2 and D consisting of processing devices 110 installed in the technical department, factory department and sales department are set. Groups B, C1, C2 and D are included in Group A. Further, the group D of the sales department includes a group D1 composed of the processing device 110 installed at the Tokyo sales office and a group D2 composed of the processing device 110 installed at the Kansai sales office. These groups A, B, C1, C2, D, D1 and D2 are groups provided according to the organizational structure of Company X, and are assumed to exist almost permanently. A group that is expected to exist permanently is called a fixed group. On the other hand, within X, groups G1 and G2 are set up for temporary projects created ad hoc. For example, group G1 includes processing equipment 110 installed in a department participating in the corresponding project team. Groups that are premised on being temporary, such as groups G1 and G2, are called variable groups.

Similarly, Company Y is referred to as Group A consisting of all processing devices 110 installed in Company Y, and Groups B, C, and D consisting of processing devices 110 installed in the sales department, accounting department, and audit department, respectively. Four fixed groups are set. Groups B, C and D are included in Group A.

In the illustrated example, Company X and Company Y are collaborating, and due to the special audit project related to the collaboration, the processing equipment 110 belonging to the departments related to the collaboration of Company X and Company Y are changed to two companies. Group G-Y-X-1, which is a straddling variable group, is set.

By the way, in this example, as shown in FIG. 20, each processing device 110 holds the belonging group information 112b and the transfer setting information 112c in addition to the management information 112a.

The affiliation group information 112b is information indicating the group to which the processing device 110 belongs. In one example, the group information to which the processing device 110 belongs is a list of group IDs to which the processing device 110 belongs. The group ID is identification information that uniquely identifies the group worldwide. The worldwide uniqueness of the group ID is realized, for example, by using a format that includes a globally unique contractor ID (for example, the contractor ID is merged with the serial number of the group within the contractor). do it.

In addition to the group corresponding to the department in which the processing device 110 is installed, the group ID of the upper group including the group is also included. For example, in the example of FIG. 19, the group information of the processing device 110 installed in the department also involved in the special audit project in the Tokyo sales office is group D1, D, A and GYX-1. Includes the group IDs of the four groups.

The transfer setting information 112c is setting information regarding a transfer method when the eDoc held by the processing device 110 is transferred in response to a request from another processing device 110. In this example, when a transfer request comes from another processing device 110 to its own eDoc, the processing device 110 is the requesting source if the processing device 110 of the requesting source belongs to the same group as itself. The eDoc is responded to. Here, as described above, the processing device 110 may belong to a plurality of groups, and the transfer setting information 112c is provided so that the transfer method and conditions can be different for each group to which the processing device 110 belongs. ing.

FIG. 21 shows an example of the transfer setting information 112c. The illustrated example is the transfer setting information 112c set in the processing device 110 installed in the department involved in the special audit project in the Tokyo sales office of company X in the group configuration example of FIG. The processing device 110 belongs to four groups, groups D1, D, A, and GYX-1, and each of the four groups is referred to as "◎", "○", and "△". One of the three levels is set.

The level "⊚" is a method of immediately transferring the requested eDoc to the requesting source by the default transfer protocol. This level applies to a close group of processing devices 110 that are mutually reliable. There are various transfer protocols such as FTP, TFTP, FTPS, WebDAV, rsync, and SCP, and the default transfer protocol may be any of them. You may also use these protocols with modifications (eg, higher levels of encryption) for added security.

Level "○" confirms the status of the communication connection with the requester, and selects a transfer protocol (for example, the strongest) from the transfer protocols available to both you and the requester according to a predetermined standard. It is a method of transferring using a transfer protocol). This level of method is equivalent to that used in general data transfer.

The level "Δ" is only when the request is made by a person who has a specific high authority over the eDoc (for example, the owner, that is, the user who has registered the eDoc in the processing device 110). This is a method of transferring the requested eDoc. The protocol used for the transfer is determined by negotiation with the processing device 110 of the request source, as in the case of the level “◯”. This level "Δ" is assumed to be applied to a group or the like including a processing device 110 having low security reliability.

Further, each level may be associated with the cache period of the eDoc in the processing device 110 at the transfer destination. The higher the level, the longer the cache period. A high level of a group means that the reliability between the processing devices 110 belonging to the group is high. In the above example, the levels are higher in the order of “⊚”, “◯”, and “Δ”.

The processing device 110 transfers the requested eDoc to the requesting source together with information on the cache period corresponding to the level determined for the requesting source. The processing device 110 of the request source caches the transferred eDoc during the cache period, and when the request of the eDoc is received during that period, the requesting processing device 110 responds by using the cached eDoc.

The transfer setting information illustrated in FIG. 21 has two columns, "match" and "special setting". “Match” is a column indicating the level applied to the belonging group that matches between the processing device 110 holding the eDoc of the transfer request target and the processing device 110 of the transfer request source. "Special settings" are columns for master key settings used for purposes such as business audits and management. The "special setting" allows, for example, the eDoc to be transferred from the processing device 110 belonging to all fixed groups to the device of the auditor or administrator. The fact that the request source is a device such as an auditor is proved by transmitting special authentication information indicating that the device is, for example, an auditor or the like to the processing device 110 of the request destination.

The affiliation group information 112b and the transfer setting information 112c described above are set for each processing device 110 by, for example, the administrator of each processing device 110 or the service person of the company that provides the service of this system.

The belonging group information 112b and the transfer setting information 112c held by the processing device 110 are sent to the processing device management server 240 shown in FIG. 6 as items of the status 244 of the status history 242 corresponding to the processing device ID of the processing device 110. Registered as.

Hereinafter, a user registered in a certain processing device 110 (referred to as "home device") is at another base outside the local network to which the home device is connected, and the processing device 110 ("away device") at that base is located. The process of acquiring the eDoc in the home device via (referred to as) will be described. The ID of the home device is registered in the user ID server 210 as the default processing device ID of the user (see FIG. 4). The user usually connects to the local network 108 to which the home device is connected and receives the distribution of the eDoc registered in the home device. Here, when the user goes to another place, the flow when receiving the distribution of eDoc from the home device via the away device connected to the local network 108 of that place will be described.

The processing procedure of the away device is illustrated with reference to FIG. In this procedure, the away device receives input of the DID of the eDoc to be acquired from the viewing terminal 104 of the user (a user who is not registered in the away device) (S10). Here, before this step, the away device may authenticate the accessing user by using the higher-level user ID server 210. Further, the browsing terminal 104 of the user acquires a list of eDocs set as the distribution destination by the user from the metadata server 230 or the home device after the user authentication, and presents the list to the user. You may accept the selection of the acquisition target.

Next, the away device acquires the latest metadata corresponding to the DID input in S10 from the metadata server 230 (S12), and the user is included in the distribution destination information (see FIG. 3) of the metadata. Is confirmed (S14, S16). If the user is not included in the distribution destination information, the away device sends error information indicating that distribution is not permitted to the viewing terminal 104 (S17). The browsing terminal 104 displays on the screen that delivery is not possible according to the error information.

When it is confirmed in S16 that the user is the delivery destination of the eDoc, it is checked whether or not the file of the eDoc exists in the cache of the away device (S18). If the eDoc has already been acquired from the home device and still remains in the cache, the determination result in S18 is Yes. In this case, the away device responds to the viewing terminal 104 with the eDoc in its cache (S20).
If the determination result in S18 is No, the away device identifies the home device having the eDoc from the metadata (S22). The processing device corresponding to the processing device ID included in the metadata (see FIG. 3) is the home device. The away device acquires the address information of the home device from the management system 200, accesses the home device using the address information, and sends a transfer request for the eDoc (S24). This transfer request includes the DID of the eDoc and the group information to which the away device belongs.

The away device then determines whether or not the eDoc has been provided by the home device in response to the transfer request (S26). As will be described later, when the away device does not belong to the same group as the home device, the home device does not transmit the eDoc to the away device, so that the determination result in S26 is No. In this case, the away device sends error information indicating that distribution is not permitted to the viewing terminal 104 (S17). The browsing terminal 104 displays on the screen that delivery is not possible according to the error information.

When the determination result in S26 is Yes, the away device responds to the viewing terminal 104 of the requesting user with the eDoc transmitted from the home device (S28). Further, the away device caches the eDoc in its own storage device (S29). Here, when the cache period is specified for the eDoc transmitted from the home device, the away device deletes the eDoc from the cache when the cache period elapses from the time when the eDoc is acquired. The cache period is determined independently of the validity period of the eDoc on the viewing terminal 104. If the cache period is not specified, the old eDoc is discarded according to a normal cache algorithm such as Least Recently Used.

An example of the processing procedure of the home device when the transfer request of the eDoc is received from the away device will be described with reference to FIG. 23. When the home device receives the transfer request from the away device (S30), the home device compares the belonging group information (of the away device) in the transfer request with the belonging group information of the home device itself, and matches between the two (S30). It is determined whether or not there is a group ID (common) (S32). If there is no common group ID, the home device responds to the away device that the requested eDoc cannot be transferred (S38). In this case, since the away device does not belong to the same group as the home device, the transfer is not permitted because the device is reliable or unknown from the home device.

When the determination result of S32 is Yes, the home device identifies the highest level of the group ID that matches between them (S34), and uses the transfer method corresponding to the specified level to the away device. Transfer the eDoc (S36). When the cache period is set at the specified level, the information indicating the cache period is transferred to the away device in association with the eDoc. When the highest level specified in S34 is the above-mentioned level "Δ", the home device corresponds to a person (for example, the owner) whose user ID of the transfer request source has a specific high authority for the eDoc. It may be determined whether or not, and if applicable, the eDoc may be transferred by proceeding to S36, and if not applicable, the transfer may be disallowed by proceeding to S38.

The tunneling protocol is incorporated in the processing device 110 that needs to pass through the firewall for the transfer of the eDoc. The tunneling protocol to be incorporated may be any of L2F, PPTP, L2TP, GRE, IPsec and the like. It is also possible to incorporate a plurality of them and select and use a common one with the transfer partner.

Further, the stability of the transfer is set by setting the upper limit of the data amount of the eDoc that allows automatic transfer by the above processing procedure according to the type of the transfer protocol used for the eDoc transfer and the presence / absence and / or type of the tunneling protocol. May be improved. If the upper limit is exceeded, the eDoc may be divided into parts below the upper limit and transferred.

In the above example, the group information 112b to which the processing device 110 belongs includes the ID of the group to which the processing device 110 directly belongs, as well as the ID of a wider group including the group. Although it is assumed that the IDs of all the groups to which 110 belongs hierarchically are included, the form of such belonging group information 112b is only an example. Instead of the processing device 110 having the belonging group information 112b, the processing device 110 may hold the belonging group information 112b on a server provided on the network accessible from the processing device 110, and the processing device 110 may refer to it. Further, the processing device 110 has only the ID of the group to which it directly belongs, and the information on the hierarchical relationship between the groups may refer to the server on the network.

As illustrated above, by grouping the processing devices 110 according to the wishes of the contractor and permitting the transfer of eDoc between the processing devices 110 in the same group, the user has the processing device 110 in which he / she is registered. Even when you are in a place other than your place (for example, your office), you will have more chances to get the main body of the eDoc addressed to you.

The embodiments of the present invention have been described above. Creating terminal 102, browsing terminal 104, processing device 110, local user ID server 152, local DID server 154, local metadata server 156, user ID server 210, DID server 220, metadata server 230, processing device management illustrated above. Each device such as the server 240 is realized by causing a computer to execute the above-mentioned program representing the function of each device. Here, the computer, for example, as hardware, a microprocessor such as a CPU, a memory (primary storage) such as a random access memory (RAM) and a read-only memory (ROM), a flash memory, an SSD (solid state drive), and an HDD. A controller that controls a fixed storage device such as (hard disk drive), various I / O (input / output) interfaces, a network interface that controls connection to a network such as a local area network, etc., for example, via a bus or the like. It has a circuit configuration connected by. A program in which the processing contents of each of these functions are described is saved in a fixed storage device such as a flash memory via a network or the like, and is installed in a computer. By reading the program stored in the fixed storage device into RAM and executing it by a microprocessor such as a CPU, the functional module group illustrated above is realized.

10 Wide area network, 100 local system, 102 creation terminal, 104 browsing terminal, 108 local network, 110 processing device, 112 management information storage, 112a management information, 114a user information, 130 authentication device, 150 in-house management system, 152 local User ID server, 154 local DID server, 156 local metadata server, 200 management system, 210 user ID server, 212 contractor data, 214 general user data, 220 DID server, 230 metadata server, 240 processing device management server, 242 Status history, 244 status, 246 software information, 248 hardware information, 300 metadata, 400 input screen, 402 delivery destination user selection menu, 404 delivery destination user list field, 406 delivery destination terminal selection menu, 408 delivery destination terminal list Field, 410 Access authority setting field, 412 Offline validity period menu, 414 Option setting call button, 420 Option setting screen, 422 Processing device specification field, 424 Original data setting field, 500 List screen, 502 Notification mark, 504 Document name, 506 Browsability mark, 602 issuance authority key, 604 processing device unique information, 606 issue date, 608 issue certification key, 610 issue number.

Claims (2)

A receiving means for receiving a document and destination information indicating a destination user and a destination terminal of the document.
A storage means for storing the received document and
An authentication method that authenticates users who use your device,
When the set of the user authenticated by the own machine and the authentication means corresponds to the set of the destination user and the destination terminal indicated by the received destination information, the document is stored in the storage means and the document is stored. The first control means that controls the display of the document,
If the set of users authenticated by the own machine and the authentication means does not correspond to the set of the destination user and the destination terminal indicated by the received destination information, the document is displayed, but the display is displayed. After the end, the second control means for controlling the document used for the display to be discarded without being saved in the storage means, and
User terminal with. A receiving means for receiving a document and destination information indicating a destination user and a destination terminal of the document.
A storage means for storing the received document and
An authentication method that authenticates users who use your device,
When the set of the user authenticated by the own machine and the authentication means corresponds to the set of the destination user and the destination terminal indicated by the received destination information, the control means for controlling the display of the document. ,
A means for transmitting a usage request for the document stored in the storage means to the processing device, and
A means for deleting the document from the storage means when the processing device responds to the usage request as unavailable.
User terminal with.