JP2015122033A - Information processing device, processing method thereof and program - Google Patents

Abstract

PROBLEM TO BE SOLVED: To provide a mechanism for preventing data that cannot be browsed from being browsed by an unauthorized user in the case that a file is uploaded.SOLUTION: An information processing device for managing data and storing authority over the data includes file generation means for using the data to generate a first file browsable by a user and a second file in which the data is subjected to browse limitation according to a file generation request from a client terminal, first transmission means for transmitting the first file generated by the file generation means to the client terminal, and registration means for registering the second file so that the first file can be browsed by a user having browse limitation in the case that the first file transmitted by the first transmission means is uploaded.

Description

  The present invention relates to an information processing apparatus that manages a form, a processing method thereof, and a program.

  In recent years, management of corporate data using an external service such as a cloud has been performed.

Although this data is browsed through a browser, there are data that can be browsed and data that cannot be browsed depending on the registered data, so it can be controlled by the authority of the logged-in user. Has been done. For example, data that cannot be browsed is masked and displayed with “*” depending on the browsing authority of the browsing user.
In addition, the browsing data is output as a form (for example, form overlay output).
This output is converted to PDF, for example, and downloaded to the client terminal that requested the form generation, and is ready for use by the user.

  Further, as described in Patent Document 1, there is a technique for performing a masking process on a downloaded form and transmitting the masked form to a user terminal that has requested it.

JP 2011-227536 A

  However, in the conventional mechanism, since browsing of data is controlled by the user's reference authority, when a user with data reference authority requests to generate a form, the form is not normally masked. A file is generated, and the file is downloaded to the terminal of the user who requested the generation. When a user who does not have a reference authority requests to generate a form, a form file in which data of a portion that cannot be referred to is masked is generated, and the file is downloaded to the terminal of the user who requested the generation.

For this reason, files that are not masked are saved on the terminal of a user with reference authority, so if the user uploads a file to the server in order to manage this file by mistake, the data is not masked. There is a problem that a user without reference authority can browse.
Note that the server that manages the data and the server that manages the file are the same service and have a mechanism for centrally managing the data.

  Accordingly, an object of the present invention is to provide a mechanism for preventing data that cannot be browsed by an unauthorized user when a file is uploaded.

  An information processing apparatus for managing data and storing authority for data for achieving the object of the present invention, wherein the user can browse the data using the data according to a file generation request from a client terminal. 1 file, a file generation means for generating a second file whose data is restricted to be browsed, a first transmission means for transmitting the first file generated by the file generation means to a client terminal, And a registration unit for registering the second file so that a user with browsing restrictions can browse when the first file transmitted by the first transmission unit is uploaded. .

  According to the present invention, when a file is uploaded, it is possible to prevent data that cannot be browsed from being browsed.

1 is a system configuration diagram illustrating an example of a configuration of an information processing system 2 is a block diagram illustrating a hardware configuration example of an information processing apparatus applicable to a server 101 and client terminals 102 and 103. FIG. It is a functional block diagram of the server 101 and the client terminal 102 It is a flowchart regarding the whole process in this system. It is a flowchart regarding a form creation process. It is a flowchart regarding a form download process It is a flowchart regarding a form upload process It is an image figure which shows an example of the screen containing company data. It is a figure which shows the form production | generation button which instruct | indicates form creation It is an image figure showing an example of a download form list screen It is an image figure which shows the example of a display of the downloaded form. It is an image figure which shows an example of an upload screen. It is a figure which shows an example of a user table. It is a figure which shows an example of a form table. It is a figure which shows the item to mask

Hereinafter, embodiments of the present invention will be described in detail with reference to the drawings.
FIG. 1 is a system configuration diagram showing an example of the configuration of an information processing system including client terminals 102 and 103 and a server 101 according to the present invention.

  The server 101 is a server that manages various data (data and files), and has a mechanism that assumes a cloud environment. The server 101 is a server that manages data and stores authority for the data.

  For this reason, the network 100 will be described as a network composed of a LAN or a WAN. In addition, although a cloud environment is assumed, an environment on an intranet in a company may be used.

  The client terminals 102 and 103 store a browser and access the server 101 from the browser via the network 100. Log in to the server 101 to receive and display a Web screen that displays data managed by the server 101 from the server 101. At the time of login, authentication is performed using the user ID and password, and data managed by the server is controlled according to the authority associated with the user ID.

The server 101 has a database and manages various data. Further, the form and data are combined to generate a form (for example, PDF data). In addition, this form can be transmitted to the client terminals 102 and 103 to meet each other. Furthermore, files can be received and registered in response to upload requests from the client terminals 102 and 103. In addition to the files, various data can be registered from the client terminals 102 and 103 of the user and the administrator.
Needless to say, various devices for communicating on the Internet are provided between the client terminals 102 and 103 and the server 101.

  The server 101 operates as a Web application server and also operates as a server that manages a database. Further, the Web application server and the database server can operate as separate cases. Further, a plurality of Web application servers may be provided as a redundant configuration.

Next, the hardware configuration of the information processing apparatus applicable to the server 101 and the client terminals 102 and 103 shown in FIG. 1 will be described with reference to FIG.
2 will be described as the server 101.

  In FIG. 2, reference numeral 201 denotes a CPU that comprehensively controls each device and controller connected to the system bus 204. Further, the ROM 202 or the external memory 211 is necessary to realize a BIOS (Basic Input / Output System) or an operating system program (hereinafter referred to as an OS), which is a control program of the CPU 201, or a function executed by each server or each PC. Various programs to be described later are stored.

  In the present embodiment, for example, Web applications, data, and forms (stored) are stored and managed. Note that the Web application manages sessions in order to control login from the client terminals 102 and 103. In order to manage the authority of the login user, the user table (FIG. 13) is stored and managed.

  A RAM 203 functions as a main memory, work area, and the like for the CPU 201. The CPU 201 implements various operations by loading a program or the like necessary for execution of processing from the ROM 202 or the external memory 211 into the RAM 203 and executing the loaded program.

  An input controller 205 controls input from a keyboard (KB) 209 or a pointing device such as a mouse (not shown). A video controller 206 controls display on a display device such as a CRT display (CRT) 210. In FIG. 2, although described as CRT 210, the display device is not limited to the CRT, but may be another display device such as a liquid crystal display. These are used by the administrator as needed.

  A memory controller 207 is connected to the hard disk (HD), flexible disk (FD), or PCMCIA card slot for storing a boot program, various applications, font data, user files, editing files, various data, etc. via an adapter. The access to the external memory 211 such as a compact flash (registered trademark) memory is controlled.

  A communication I / F controller 208 is connected to and communicates with an external device via a network (for example, 500 shown in FIG. 1), and executes communication control processing in the network. For example, communication using TCP / IP is possible.

  Note that the CPU 201 enables display on the CRT 210 by executing outline font rasterization processing on a display information area in the RAM 203, for example. In addition, the CPU 201 enables a user instruction with a mouse cursor (not shown) on the CRT 210.

  Various programs to be described later for realizing the present invention are recorded in the external memory 211 and executed by the CPU 201 by being loaded into the RAM 203 as necessary. Furthermore, definition files and various information tables used when executing the program are also stored in the external memory 211, and a detailed description thereof will be described later.

Next, the function of the server 101 of the present invention will be described using the functional block diagram of FIG. Each function is executed by each CPU.
Detailed processing of each function will be described with reference to the flowcharts of FIGS.

FIG. 3 is a block diagram showing a schematic configuration as functions of the server 101 and the client terminal 102 according to the embodiment of the present invention.
Detailed processing by each functional unit will be described later with reference to FIGS.

  The client terminal 102 has functional units of a file generation instruction unit 300, a download unit 301, an upload unit 302, and a display control unit 303. The server 101 also includes functional units of a file generation unit 304, a first transmission unit 305, a registration unit 306, a storage control unit 307, a second transmission unit 308, a management unit 309, a determination unit 310, and a message transmission unit 311. Have.

The file generation instruction unit 300 is a functional unit that executes a file generation instruction request to the server 101 in response to pressing of a form creation button for data (for example, company data) displayed on the client terminal 102.
The download unit 301 is a functional unit that downloads a file generated by the server 101 in accordance with user designation.

  The upload unit 302 is a functional unit that uploads a file in order to associate a file stored in the external memory of the client terminal 102 with predetermined data (for example, negotiation data) of the server 101.

  The display control unit 303 is a functional unit that controls display of a file downloaded by the client terminal 102 or receives data of the server 101 as a Web screen and controls display of the received screen.

The file generation unit 304 generates a first file that can be browsed by the user and a second file whose data is restricted by browsing using data stored and managed in accordance with a file generation request from the client terminal. Part.
The first transmission unit 305 is a functional unit that transmits the first file generated by the file generation unit 304 to the client terminal.

The registering unit 306 is a functional unit that registers the second file so that a user with viewing restrictions can view when the first file transmitted by the first transmitting unit is uploaded.
The storage control unit 307 is a functional unit that stores dummy link information corresponding to the first file when the first file is uploaded.

The second transmission unit 308 is a functional unit that transmits the first file or the second file to the client terminal that has requested the first file or the second file according to the user authority when there is a request for dummy link information. .
The management unit 309 is a functional unit that manages management information in which the identification information of the first file is associated with the identification information of the second file.

  The determination unit 310 has a function of determining whether or not there is a second file corresponding to the first file according to the identification information and management information of the first file when the first file is uploaded. Part.

  The storage control unit 307 is a functional unit that stores the first file and the second file in association with dummy link information when the determination unit 310 determines that there is a second file.

  The message transmission unit 311 is a functional unit that transmits a message indicating that a file whose browsing is restricted is registered in the client terminal when the determination unit 310 determines that there is a second file.

  It is assumed that the first file is a file that is not restricted by the user's authority, and the second file is a file that is restricted by the authority of another user.

Next, a detailed description of the processing in this embodiment will be described using the flowcharts of FIGS. Note that the steps of the flowchart are executed by the CPU of each device.
FIG. 4 is a flowchart showing the overall processing of this embodiment.
First, the entire process will be described with reference to the flowchart of FIG.

In step S 401, the client terminals 102 and 103 (hereinafter abbreviated as “client terminal 102”) are accessed by the server 101, receive the login screen, and display the login screen on the browser of the client terminal 102.
Then, the user ID and password received by the user's operation are transmitted to the server, authentication is performed using the user table of FIG. 13 stored in the server 101, and login is performed when the authentication is successful. As a result, the session between the server 101 and the client terminal 102 is maintained, and various types of data are transmitted and received.

  In step S402, a screen of data desired by the user is displayed from the server 101 based on various operations of the user. For example, a screen including the company data in FIG. 8 is displayed. This is displayed via the browser.

At this time, if it is determined that the user has the reference authority according to the authority of the logged-in user (FIG. 13), a screen (800 in FIG. 8) that is not masked is generated by the server 101 and transmitted to the client terminal 102. . And it displays with a browser. If it is determined that the user does not have the reference authority, the screen (810 in FIG. 8) in which the data of the corresponding item is masked with a replacement character such as “*” with reference to the mask item in FIG. It is generated by the server 101 and transmitted to the client terminal 102. And it displays with a browser.
The mask is not limited to this as long as it is not a replacement character and the data cannot be recognized by the user.

  Reference numerals 801 to 803 denote unmasked states, and 804 to 806 denote masked states. Further, whether the item is a masking item is determined by the item of FIG. 15 and displayed.

In step S403, the press of the form generation button 901 in FIG. 9 is accepted, and a form generation instruction is requested to the server 101. Here, it is assumed that the form ID and form type of the form to be created are included in the request. In the present embodiment, description will be made using a form ID. Assume that the server 101 stores and manages the form ID and the displayed data (display data in FIG. 8) in association with each other.
In step S407, the server 101 receives the request and creates a form of the displayed data. A flow chart for creating a form will be described with reference to FIG.

  In step S404, the form generated in step S407 is displayed in FIG. A form (file) is displayed according to the designation in FIG. A display example of the form is shown in FIG. Note that the processing of the server 101 for display control by the client terminal 102 is step S408. The process of step S408 will be described with reference to FIG.

  In step S405, after the step S404, the downloaded and displayed form is stored in the external memory 211 of the client terminal 102. This is a process of, for example, downloading and saving a PDF file locally. The PDF file stored here may be a form file that is masked according to the user's authority, or a form file that is not masked.

  In step S406, the file saved in step S405 is uploaded to the server 101 in accordance with a user operation. For uploading, the upload screen as shown in FIG. 12 is displayed, the button for file attachment 1201 is pressed, a file stored locally is specified and executed, and the form is uploaded to the server 101.

  In step S409, the form (file) is received and registered in the external memory 211. The processing of the form uploading server 101 will be described with reference to FIG.

  Next, the form creation processing of the server 101 will be described using the flowchart of FIG.

  In step S501, data to be formed is acquired based on the form ID for which a form creation request has been made. Further, it is determined whether or not the item corresponding to the data includes an “encryption” type item. Specifically, it is determined whether there is an item to be encrypted in the items of FIG.

  If it is a form that includes data of an item to be encrypted, the process proceeds to step S502. If it is a form that does not include data of an item to be encrypted, the process proceeds to step S513.

  In the present embodiment, as shown in FIG. 15, a flag for identifying whether to encrypt each item is stored, but a flag for identifying the presence or absence of an item to be encrypted for each form. May be stored.

In step S <b> 502, a message indicating that the form includes data to be encrypted is transmitted to the client terminal 102, and the message is displayed on the client terminal 102. When a message is displayed and an OK button is pressed on the screen of the client terminal 102, the process proceeds to step S503.
In step S503, the authority of the logged-in user who has executed the form generation instruction is acquired.
Specifically, reference authority corresponding to the user ID of the logged-in user is acquired by referring to the user table in FIG.

  In step S504, it is determined whether or not the user authority is a reference authority. If the user has reference authority, the process proceeds to step S505. If the user does not have reference authority, the process proceeds to step S510.

  In the present embodiment, description is made with or without reference authority. However, the reference authority may have a level (1 to 3 or the like), and items to be encrypted may be determined according to the level of reference authority. In that case, the encryption level corresponding to the reference authority is set for each item of FIG.

In step 505, a file displaying encrypted data (data to be masked) and a message to generate a file with masked data are transmitted to the client terminal 102. When the client terminal receives the message, it displays the message.
When a message is displayed and the OK button is pressed on the screen of the client terminal 102, the process proceeds to step S506.
In step S506, the data displayed on the client terminal 102 is acquired and combined with a prestored form to create a form.

Specifically, the data is combined with the form, and a form (PDF file) that is not masked is generated (generation of the first file that is not restricted according to the user authority). Also, the data of the item with encryption is converted into a predetermined character string, for example, “*”, and the form is combined with the form to generate a masked form (PDF file) (authorization of other users) Generation of a second file that is restricted according to The file name is “mask_xxx” for the masked form.
That is, it is an example of a file generation process for generating a first file that can be browsed by the user using the data in accordance with a file generation request from the client terminal and generating a second file for restricting browsing.

  Note that the form creation data and the form combining technique are realized using a known form overlay technique, and the description of the form overlay is omitted.

In step S507, as attribute information such as the property of the form generated in step S506, a code is generated to associate the masked form with the unmasked form (form displayed on the client terminal 102) as a set. Write.
For example, “20130911630AAAA10”, which is an unmasked form code, is written in the form corresponding to 1102 in FIG. Write.

In step S508, the two created forms are stored in the external memory 211 of the server 101. Then, a dummy URL not designating the saved form is created, and the dummy URL is registered in the dummy URL 1406 of FIG. 14 as link information for file download. The file name of the created file is registered in the file name 1401.
In step S509, information such as the code written in step S507 is registered in the form table of FIG.
Specifically, in the case of the form saved in step S508, it is saved as 1410 (non-masked form) and 1411 (masked form) in FIG.

  In FIG. 14, a file name 1401, a code 1402, a set ID 1403, encrypted data display presence / absence 1404, and a save destination URL 1405 are stored. This save destination URL is a URL directly associated with the file.

Note that AAAA1 is stored as the set ID, for example, to indicate that 1410 and 1411 are sets. In the presence / absence of display of encrypted data, “0” indicates that encrypted data is displayed, and “1” indicates that masked display is performed.
That is, FIG. 14 shows an example of managing the management information in which the identification information of the first file is associated with the identification information of the second file.

In step S <b> 510, since the user has no reference authority, a message to generate a file with masked data is transmitted to the client terminal 102. When the client terminal receives the message, it displays the message.
When a message is displayed and an OK button is pressed on the screen of the client terminal 102, the process proceeds to step S511.
In step S511, the data displayed on the client terminal 102 is acquired and combined with a prestored form to create a masked form.

  Specifically, the data of the item with encryption is converted into a predetermined character string, for example, “*”, and the form is combined with the form to generate a masked form (PDF).

In step S512, the generated form is registered in the form table of FIG. In this case, it is possible to identify that the file name is “mask_xxx” and is masked. In step S512, since there is no unmasked form to be set in the form table in FIG. 14, the code and the dummy URL are not written. Further, no value is stored in the code 1402 and the set ID 1403 in FIG.
In step S512, the URL of the saved form is registered in the save destination URL 1405.
In step S513, the data displayed on the client terminal 102 is acquired and combined with a previously stored form to create a form.
Specifically, since the form has no items to be encrypted, the data is combined with the form to generate an unmasked form (ordinary form PDF).

  In step S514, the generated form is saved in the external memory 211, and the URL of the saved form is registered in the save destination URL 1405 in FIG. Similarly to step S508 and step S512, the file name 1401 is registered in the form table of FIG. It should be noted that “0” is registered in the encrypted data display presence / absence 1404 because it is not encrypted, but it may be a NULL value because it is a normal generated file. The dummy URL also has a NULL value.

Next, a form download process will be described with reference to the flowchart of FIG.
First, 1001 or 1002 is designated on the download form list screen of FIG. 10 displayed in step S404, and a download request is sent to the server 101.
That is, on the client terminal 102, a screen in which the URL of the file of the form table in FIG. 14 is embedded is transmitted to the client terminal 102 and displayed. The link information 1001 and 1002 is a dummy URL.
In the case of a form without a dummy URL, the save destination URL is link information.

  In step S601, the client terminal 102 receives a request (download request) for the URL specified by the user. Then, it is determined whether the received request URL is a dummy URL. Specifically, a match with the dummy URL in FIG. 14 is determined. If it is determined that the URL is a dummy URL, the process proceeds to step S602. If it is determined that the URL is not a dummy URL, the process proceeds to step S606.

In step S602, it is determined with reference to the flag 1301 in FIG. 13 whether or not the user who has logged in and downloaded the masked form even if the user who executed the request has reference authority.
In step S603, the reference authority of the user who logged in and executed the request is referred to the reference authority in FIG.
In step S604, if the reference authority is “YES”, the process proceeds to step S605. If the reference authority is “NO”, the process proceeds to step S606.

In step S605, in order to obtain an unmasked form, a file corresponding to the dummy URL and whose encrypted data display presence / absence 1404 is “0” is specified. In this case, there are 1410 records. Then, the URL of the storage destination URL 1405 is acquired. The file stored in the external memory 211 is acquired using the acquired storage destination URL instead of the request dummy URL.
Then, this file is transmitted to the client terminal 102. In other words, this is an example of transmission processing for transmitting the generated first file to the client terminal.
As a result, the PDF file form is displayed on the client terminal 102, and the process proceeds to step S405.

  In step S606, it is determined whether a masked form exists. Specifically, in order to obtain a form with a mask, it is determined whether there is a file whose encrypted data display presence / absence 1404 is “1” corresponding to the dummy URL. If there is a masked form, the process proceeds to step S607, and if there is no masked form, the process proceeds to step S608.

  The process proceeds to step S607 when there are 1411 records. Further, when the processing is moved to step S608, the record 1411 is deleted and does not exist.

  In step S607, in order to obtain a form with a mask, a file saved in the external memory 211 is obtained using the save destination URL 1411 instead of the dummy URL. Then, this file is transmitted to the client terminal 102.

  That is, even if a download request for an unmasked file is executed from the client terminal 102, the masked file is downloaded to the client terminal 102 according to the reference authority because it is a dummy URL.

  In step S608, since there is no masked form, a message indicating that it cannot be referred to is transmitted to the client terminal 102. The client terminal 102 receives the message and displays it.

  In step S609, since the request for the specified URL (download request) is not a dummy URL, a file is acquired from the external memory 211 using the requested URL. Then, the acquired file is transmitted to the client terminal 102. The client terminal 102 displays the received file (form).

  Next, a form upload process will be described with reference to the flowchart of FIG.

When the client terminal 102 accepts designation of the file attachment 1201 in FIG. 12, designates a file (form) stored locally in the client terminal 102, and issues an upload execution instruction, the process proceeds to step S <b> 701.
A file stored in a file server may be used in addition to a local file.
The upload instruction is for uploading to an arbitrary storage location by the user. That is, the download destination and the upload destination in FIG. 6 may be different management areas.

Specifically, the server 101 manages each business negotiation, and the file downloaded in FIG. 6 may be separately attached to the business negotiation as related information.
That is, a file to be associated with the negotiation is generated from the company information managed by the server 101 and temporarily stored in the client terminal 102. Then, the user designates an opportunity (upload destination) to which this file is to be attached, and uploads the file.
Therefore, the file is uploaded, but the file saved in FIG. 6 is not attached to the upload destination.

  In step S <b> 701, a file is received from the client terminal 102. Then, it is determined whether or not a code has been written by referring to predetermined attribute information of the received file. If it is determined that the code has been written, the process proceeds to step S702. If it is determined that the code has not been written, the process proceeds to step S708.

  In step S <b> 702, a message indicating that the form (file) includes encrypted data (data that needs to be masked) is transmitted to the client terminal 102. The client terminal 102 receives the message and displays it. When a message is displayed and an OK button is pressed on the screen of the client terminal 102, the process proceeds to step S703.

In step S703, it is determined from the form table in FIG. 14 and the code referenced in step S701 whether there is a masked form to be paired. If there is a record having the referenced code in the form table, the process proceeds to step S704. If there is no record having the referenced code, the process proceeds to step S706.
That is, an example of determination processing for determining whether or not there is a second file corresponding to the first file according to the identification information and management information of the first file when the first file is uploaded It is.

In step S704, since the form table in FIG. 14 contains the masked form generated in FIG. 5, a message to register the masked form (file) together is transmitted to the client terminal 102. The client terminal 102 receives the message and displays it. When a message is displayed and an OK button is pressed on the screen of the client terminal 102, the process proceeds to step S705.
That is, it is an example of processing for transmitting a message to the effect that a file whose browsing is restricted is registered in the client terminal when it is determined in step S703 that there is a second file.

In step S705, the received form and the form specified in step S703 are acquired, and the two forms are stored in the server 101. At this time, a new record is added to the form table of FIG. 14, and the file name and dummy URL of the saved form are registered. A dummy URL is newly generated and registered.
That is, when the first file is uploaded, this is an example of a storage control process for storing dummy link information corresponding to the first file.
Moreover, it is an example of a process of storing the first file and the second file in association with dummy link information when it is determined in step S703 that there is a second file.
In addition, when the first file is uploaded, this is an example of a registration process for registering a second file that is restricted to be browsed so as to be viewable by a user who is restricted.
Needless to say, the file names are managed so that they can be registered even if they are duplicated.

  In the present embodiment, the same form but the actual file is stored redundantly. However, there may be a single actual file and management information for managing the file may be stored. For example, the association destination (business negotiation information or the like) is realized by storing it in the form table of FIG.

  In step S706, since the form table in FIG. 14 does not contain the masked form generated in FIG. 5, a message indicating that there is no masked form (file) is transmitted to the client terminal 102. The client terminal 102 receives the message and displays it. When a message is displayed and the OK button is pressed on the screen of the client terminal 102, the process proceeds to step S707.

  In step S <b> 707, the received form (file) is stored in the storage destination of the server 101. Then, a new record is added to the form table of FIG. 14, and a file name and a dummy URL are registered. As the dummy URL, a new dummy URL is generated.

  In step S708, since the form (file) has no code written therein, it is normally stored in the server 101. Then, a new record is added to the form table of FIG. 14, and a file name and a save destination URL are registered.

In step S709, the information of the registered record is updated according to the registration in step S705 or step S706.
Specifically, for the code, the code acquired from the attribute information of the received form is registered in the code 1402, and when there is a paired form, the code of the form is registered in the code 1402. Further, when registering a paired form, a new set ID is generated and registered in the set ID 1403 of the received form and the record of the paired form.

  Further, “0” is registered in the encrypted data display presence / absence 1404 in the received record (non-masked form) record, and “1” is displayed in the encrypted data display presence / absence 1404 of the paired form record. Register.

  The form registered in FIG. 7 is data that cannot be viewed because the masked form (file) is downloaded and displayed even if a user without reference authority tries to download the unmasked form by the process of FIG. Can be prevented from being browsed.

  As described above, according to the present embodiment, when a file is uploaded, it is possible to prevent browsing of data that cannot be browsed originally.

  In particular, even if it is possible to control the display of data on the Web screen, it is possible to browse more appropriately in a mechanism in which a user with viewing authority creates a form (file generation) and cannot control the viewing when the file is uploaded. Can be controlled.

  Although one embodiment has been described above, the present invention can take an embodiment as, for example, a system, apparatus, method, program, or recording medium, and specifically includes a plurality of devices. The present invention may be applied to a system including a single device.

  Further, the program according to the present invention is a program that allows a computer to execute the processing methods of the flowcharts shown in FIGS. 4 to 7, and the storage medium according to the present invention is a program that allows the computer to execute the processing methods of FIGS. Is remembered. Note that the program in the present invention may be a program for each processing method of each apparatus shown in FIGS.

  As described above, a recording medium that records a program that implements the functions of the above-described embodiments is supplied to a system or apparatus, and a computer (or CPU or MPU) of the system or apparatus stores the program stored in the recording medium. It goes without saying that the object of the present invention can also be achieved by executing the reading.

  In this case, the program itself read from the recording medium realizes the novel function of the present invention, and the recording medium storing the program constitutes the present invention.

  As a recording medium for supplying the program, for example, a flexible disk, hard disk, optical disk, magneto-optical disk, CD-ROM, CD-R, DVD-ROM, magnetic tape, nonvolatile memory card, ROM, EEPROM, silicon A disk, solid state drive, or the like can be used.

  Further, by executing the program read by the computer, not only the functions of the above-described embodiments are realized, but also an OS (operating system) operating on the computer based on an instruction of the program is actually It goes without saying that a case where the function of the above-described embodiment is realized by performing part or all of the processing and the processing is included.

  Furthermore, after the program read from the recording medium is written to the memory provided in the function expansion board inserted into the computer or the function expansion unit connected to the computer, the function expansion board is based on the instructions of the program code. It goes without saying that the case where the CPU or the like provided in the function expansion unit performs part or all of the actual processing and the functions of the above-described embodiments are realized by the processing.

  Further, the present invention may be applied to a system composed of a plurality of devices or an apparatus composed of a single device. Needless to say, the present invention can be applied to a case where the present invention is achieved by supplying a program to a system or apparatus. In this case, by reading a recording medium storing a program for achieving the present invention into the system or apparatus, the system or apparatus can enjoy the effects of the present invention.

Furthermore, by downloading and reading a program for achieving the present invention from a server, database, etc. on a network using a communication program, the system or apparatus can enjoy the effects of the present invention.
In addition, all the structures which combined each embodiment mentioned above and its modification are also included in this invention.

100 Network 101 Server 102 Client Terminal 103 Client Terminal

Claims (8)

An information processing apparatus for managing data and storing authority for data,
In accordance with a file generation request from a client terminal, using the data, a first file that can be browsed by a user, and a file generation unit that generates a second file in which the data is browse-restricted;
First transmission means for transmitting the first file generated by the file generation means to the client terminal;
Registration means for registering the second file so that a user with viewing restrictions can view when the first file transmitted by the first transmitting means is uploaded. Information processing apparatus. The information processing apparatus according to claim 1, further comprising storage control means for storing dummy link information corresponding to the first file when the first file is uploaded. A second transmission means for transmitting the first file or the second file to the client terminal that has requested the first file or the second file in accordance with a user authority when there is a request for the dummy link information; The information processing apparatus according to claim 2. Management means for managing management information in which the identification information of the first file is associated with the identification information of the second file;
Determining means for determining whether or not there is a second file corresponding to the first file according to the identification information and management information of the first file when the first file is uploaded; ,
The storage control unit stores the first file and the second file in association with the dummy link information when the determination unit determines that there is a second file. The information processing apparatus according to claim 2 or 3. The message transmission means for transmitting a message to the effect that a file whose browsing is restricted is registered in the client terminal when the determination means determines that there is a second file. 5. The information processing apparatus according to 4.   The first file is a file that is not restricted according to a user's authority, and the second file is a file that is restricted according to the authority of another user. 6. The information processing apparatus according to any one of 5 above. A processing method of an information processing apparatus for managing data and storing authority for data,
In accordance with the file generation request from the client terminal, the information processing apparatus uses the data to generate a first file that can be browsed by the user, and a file generation step that generates a second file in which the data is restricted from browsing;
A first transmission step of transmitting the first file generated in the file generation step to the client terminal;
When the first file transmitted in the first transmission step is uploaded, a registration step of registering the second file is performed so that the user with browsing restrictions can view the file. Processing method. A program for an information processing apparatus that manages data and stores authority to the data,
The information processing apparatus;
In accordance with a file generation request from a client terminal, using the data, a first file that can be browsed by a user, and a file generation unit that generates a second file in which the data is browse-restricted;
First transmission means for transmitting the first file generated by the file generation means to the client terminal;
When the first file transmitted by the first transmission unit is uploaded, the first file is made to function as a registration unit for registering the second file so that a user with browsing restrictions can view the file. Program to do.

Images