EP0981789A1 - Procede et appareil de publication de documents dans un environnement protege - Google Patents

Procede et appareil de publication de documents dans un environnement protege

Info

Publication number
EP0981789A1
EP0981789A1 EP99911382A EP99911382A EP0981789A1 EP 0981789 A1 EP0981789 A1 EP 0981789A1 EP 99911382 A EP99911382 A EP 99911382A EP 99911382 A EP99911382 A EP 99911382A EP 0981789 A1 EP0981789 A1 EP 0981789A1
Authority
EP
European Patent Office
Prior art keywords
server
data
database
user
document
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Withdrawn
Application number
EP99911382A
Other languages
German (de)
English (en)
Inventor
William J. Adams
Michael A. Libes
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
2way Corp
Original Assignee
2way Corp
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by 2way Corp filed Critical 2way Corp
Publication of EP0981789A1 publication Critical patent/EP0981789A1/fr
Withdrawn legal-status Critical Current

Links

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F21/00—Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F21/50—Monitoring users, programs or devices to maintain the integrity of platforms, e.g. of processors, firmware or operating systems
    • G06F21/51—Monitoring users, programs or devices to maintain the integrity of platforms, e.g. of processors, firmware or operating systems at application loading time, e.g. accepting, rejecting, starting or inhibiting executable software based on integrity or source reliability
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F21/00—Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F21/60—Protecting data
    • G06F21/62—Protecting access to data via a platform, e.g. using keys or access control rules
    • G06F21/6218—Protecting access to data via a platform, e.g. using keys or access control rules to a system of files or objects, e.g. local or distributed file system or database
    • G06F21/6272—Protecting access to data via a platform, e.g. using keys or access control rules to a system of files or objects, e.g. local or distributed file system or database by registering files or documents with a third party
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F2221/00—Indexing scheme relating to security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F2221/21—Indexing scheme relating to G06F21/00 and subgroups addressing additional information or applications relating to security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F2221/2115—Third party

Definitions

  • the present invention relates generally to storing data on information servers. More particularly, the present invention relates to publishing documents on a protected information servers both securely and efficiently.
  • the security of an information server is essential to ensure the integrity of any data stored on the information server, such that when a user accesses the data, the user may effectively be assured that the data is accurate.
  • the security of an information server is breached, the integrity of data stored on the information server becomes questionable. As a result, any user who accesses the data risks accessing corrupt data.
  • "hackers" e.g., unauthorized individuals who access with data stored on secure information servers, represent a specific danger to the integrity of data stored on publicly visible computing resources such as web browsers.
  • firewalls are often used to protect the information server from unauthorized access.
  • a firewall is often a software program which is arranged to filter data to identify data which is suitable for placement on an information server.
  • a firewall may also be a series of network routers that effectively screens access to an information server.
  • FIG. 1 is a representation the overall interaction between a user and a computer system, or machine, when the user wishes to access the computer system to store something on the computer system.
  • a user 102 is networked to a computer system 106, e.g., an information server. Typically, user 102 is linked to computer system 106 via an intranet, as will be appreciated by those skilled in the art.
  • User 102 prepares an object 104, e.g., a document or a file, which is intended to be stored on computer system 106.
  • object 104 e.g., a document or a file
  • object 104 may be stored on computer system 106
  • the validity of object 104 must generally be determined.
  • user 102 may simply place object 104 on computer system 106.
  • user 102 In general, in order to protect the integrity of computer system 106, user 102 is not allowed to place objects, e.g., publish documents, unless user 102 is an authorized user. That is, user 102 must be verified to have rights of access to computer system 106 before being allowed to place an object on computer system 106. Verifying the access rights of user 102 serves to protect computer system 106 from unauthorized access and, hence, potential damage that may be caused when unauthorized users are allowed to store and manipulate objects on computer system 106.
  • the file is typically scrutinized to ascertain whether it is publishable.
  • FIG. 2 is a process flow diagram which illustrates a conventional process for publishing a file on a web server.
  • a process 202 of publishing a file begins at step 204 in which a user sends the file that is to be published to a system administrator, e.g. , a web master.
  • the file is sent over a network connection such as an intranet connection.
  • the web master generally has special privileges which enable the web master to access the web server to manipulate files with respect to the web server.
  • the web master verifies whether the file is publishable.
  • the web master typically tests the file on a test server or within a testing are on the web server.
  • Testing the file is publishable may include determining whether the user is an authorized user. Verification may also include determining the type of information contained in the file. By way of example, a determination may be made as to whether the file contains information relating to an application that may erase other files on a web server.
  • the verification of whether a file is publishable may encompass a variety of different authentication processes. However, substantially all verification processes typically include verifying whether the user that sent the file to the web master is an authorized user.
  • step 208 a determination is made by the web master regarding whether the file is publishable. If the determination is that the file is not publishable, then process flow moves from step 208 to step 210 in which the file is not published on the web server, and notification is sent to the user to indicate that the file is not published. Alternatively, if it is determined in step 208 that the file is publishable, then the implication is that publishing the file would provide minimal risk to the web server. Accordingly, the file is then published on the web server in step 212, and the overall process of publishing a file on a web server is completed.
  • a method for publishing data created by a user onto a server machine includes sending the data from the user to a database that is communicably coupled to both the user and the server machine and storing the data on the database.
  • the database sends an identifier that identifies the storage location of the data on the database to the user, and the user sends the identifier, and not the data, in a publish command to the server machine.
  • the publish command is arranged to cause the server machine to access the data stored on the database.
  • the server machine retrieves the data from the database.
  • a method for processing a request from a client to delete a file from an output server associated with a server machine includes sending an identifier that identifies the database location of data that corresponds to the file from the database to the client, and sending a security key that is arranged to identify a destination server from the database mechanism to the user.
  • a delete command is also sent from the user to the destination server associated with the server machine. The delete command is generally sent with the identifier from the user to the destination server.
  • a method for enabling a client to publish a document on an output server associated with a server mechanism wherein the client does not directly access the output server includes storing the document on a database in a first format, and obtaining an identifier from the database that is arranged to identify the location of the document on the database.
  • the client also sends a publish command, which includes the identifier, to a destination server associated with the server mechanism.
  • a method for publishing a client-created document on an output server associated with a server mechanism includes receiving a publish command from the client on a destination server associated with the server mechanism.
  • the publish command includes an identifier arranged to identify a location on a database mechanism at which the document is stored in a first format, as well as a security key arranged to identify the destination server.
  • the method also includes determining when the security key substantially matches a destination server key associated with the destination server, and loading the document from the database mechanism onto the destination server when the security key substantially matches the destination server key. Finally, the document is transferred from the destination server to the output server.
  • Figure 1 is a diagrammatic representation of a conventional interaction between a user and a server.
  • Figure 2 is a process flow diagram which illustrates a conventional process for publishing a file on a web server.
  • Figure 3 is a diagrammatic representation of a general flow of data between a user, a database, and a server machine in accordance with an embodiment of the present invention.
  • Figure 4 is a diagrammatic representation of the interaction between a user, a data base, and a server machine of Figure 3 in accordance with a first embodiment of the present invention.
  • Figure 5 is a diagrammatic representation of data flow paths between a user, a database, and multiple server machines in accordance with a second embodiment of the present invention.
  • Figure 6 is a diagrammatic representation of data flow paths between a user, a server machine, and a database contained on the server machine in accordance with a second embodiment of the present invention.
  • Figure 7 is a process flow diagram which illustrates the steps associated with publishing a document on a web server in accordance with the first embodiment of the present invention.
  • Figure 8 is a process flow diagram which illustrates the steps associated with deleting a published document from a web server in accordance with the first embodiment of the present invention.
  • Figure 9 illustrates a typical, general-purpose computer system suitable for implementing the present invention.
  • the security of the server may be preserved.
  • the user may save documents to a secure database which a secure information server, e.g., a secure web server located behind a firewall, may effectively contact to obtain documents for publishing.
  • a secure information server e.g., a secure web server located behind a firewall
  • the user may publish a document on the web server without directly accessing the web server or sending the document to a web master.
  • Figure 3 is a diagrammatic representation of an information flow path between a user, a database, and a server machine in accordance with an embodiment of the present invention.
  • a user 302 creates a document 304 to be published.
  • User 302 then writes document 304 onto a secure database 306 which is in communication with both user 302 and a server machine 308.
  • user 302 may be in coupled to database 306 and server machine 308 over an intranet.
  • a web browser, or a web server, application 310 is resident on server machine 308. Methods used to store document 304, or substantially any other information, on database 506 are well known to those skilled in the art.
  • document 304 is stored on database 304 in a data structure, e.g., a data structure created in the C programming language.
  • document 304 may be stored on database 304 in a variety of other formats including, but not limited to, an extended mark-up language (XML) format.
  • XML extended mark-up language
  • machine 308 loads document 304 from database 306 and, ultimately, onto web browser 310.
  • machine 308 or, more specifically, web browser 310 is not directly written to by user 302. Instead, machine 308 obtains document 304 from database 306 for publishing.
  • document 304 may be translated, e.g., from a data structure in the C programming language to a hyper text mark-up language (html) format, such that the translated version of document 304 may be published on web browser 310.
  • html hyper text mark-up language
  • FIG. 4 is a diagrammatic representation of the interaction between user 302, data base 306, and a server machine 308 in accordance with an embodiment of the present invention.
  • User 302 is running an application which has access to database 306, as well as access to a destination server 414.
  • processes associated with such an application execute on both user 302 or, more specifically, a computer system associated with user 302, and destination server 414. That is, the application is resident on both user 302 and destination server 414, and has access to database 306.
  • processes may enable user 302 to write document 304 onto database 306, and allow destination server 414 to access database 306.
  • Database 306 includes a security key 416 that is arranged to uniquely identify destination server 414.
  • security key 416 when only a single destination server is present on a server machine, security key 416 effectively uniquely identifies the server machine.
  • Security key 416 may be a string of characters, such as a relatively long string of text, although it should be appreciated that security key 416 may take generally take on substantially any suitable format.
  • security key 416 is typically static, e.g., security key 416 is created only once when the application which uses security key 416 is initially executed, security key 416 may also be dynamic, or created each time it is needed.
  • Security key 416 is typically stored within a data structure in database 306, as will be understood by those skilled in the art.
  • Security key 416 is stored on database 306, and is passed internally between user 302 and database 306. In other words, security key 416 is a hidden value as security key 416 is not visible to user 302. As such, security key 416 may not be readily obtained and is, hence, relatively secure.
  • database 306 returns a unique identifier (UID) and a machine number to user 302, along with security key 416.
  • the UID is arranged to identify a location within database 306 at which document 304 is stored.
  • each document stored on database 306 has a UID, which, in one embodiment, may be a numerical address.
  • the machine number is arranged to identify the machine, e.g., machine 308, on which destination server 414 is resident.
  • user 302 When user 302 wishes to publish document 304 on web browser 310, user writes document 304 to database 306, then sends a publish command to destination server 414 requesting that document 304 be published on web browser 310, as will be described in more detail below with reference to Figure 7.
  • user 302 communicates with destination server 414 on machine 308, although user 302 does not send document 304 to destination server 414. Instead, user 302 sends the UID that identifies the location of document 304 on database 306 to destination server 414, which then effectively obtains document 304 from database 306.
  • user 302 also sends security key 416 to destination server 414, which uses security key 416 to verify that document 304 is likely to be " safe" for publication on web browser 310.
  • FIG. 5 is a diagrammatic representation of data flow paths between a user, a database, and multiple server machines in accordance with another embodiment of the present invention.
  • a user 502 has access to a database 506 such that user 502 may create a document 504 and store document 504 onto database 506.
  • database 506 may be accessed by multiple, e.g., three, server machines 508a-c. While database 506 has been shown as being accessible to three server machines 508a-c, it should be appreciated that the number of server machines which may access
  • database 506 may generally be widely varied.
  • the number of server machines linked to database 506 may be up to approximately eight or nine server machines.
  • each server machine 508a-c has been shown as including a single web browser 510a-c, respectively, the number of web browsers 510a-c on each server machine 508a-c may also be widely varied.
  • Database 506 may generally be associated with up to approximately ten total web servers, although the number may vary widely.
  • Each server machine 508a-c has an associated destination server 514a-c, respectively, which is arranged to access database 506.
  • Destination servers 514a-c are further arranged to communicate with user 502 such that user 502 may send requests, e.g., a request to publish a document or a request to delete a document, to destination servers 514a-c.
  • Database 506 includes security keys 516a-c that correspond to destination servers 514a- c. That is, security key 516a is arranged to uniquely identify destination server 514a, while security key 516b is arranged to uniquely identify destination server 514b, and security key 516c is arranged to uniquely identify destination server 514c.
  • database 506 when user 502 saves document 504 onto database 506, database 506 generally returns a UID associated with document 504 to user 502, along with security keys 516a-c.
  • user 502 may send a publish command to the corresponding destination server, e.g., one of destination servers 514a-c, along with the appropriate security key 516a-c. For example, to publish document 504 on web browser 510b, user 502 may send the UID corresponding to document 504 and the machine number corresponding to server machine 508b, along with security key 516b, to destination server 514b.
  • a user, a database, and a destination server may generally be located on three separate, or unique, machines. However, it should be appreciated that a user, a database, and a destination server may also share machines, or computational resources.
  • a user, a database, and a destination server may be housed on a single machine.
  • a user may be resident on a client machine, while a database and a destination server may be housed on a shared server machine.
  • Figure 6 illustrates a user, a server machine, and a database housed on
  • a user 602 is arranged to create a document 604, and to write document 604 onto a database 606 which is resident on a server machine 608.
  • An application which is running on user 602, as well as on a destination server 614 that is resident on server machine 608, allows user 602 and destination server 614 to access database 606.
  • database 606 may return a UID corresponding to the location of document 604 on database 606, a security key 616 arranged to identify destination server 614, and a machine number corresponding to server machine 608 to user 602.
  • database 606 and destination server 614, as well as web browser 610, are resident on server machine 608, it may not be necessary for database 606 to provide user 602 with a machine number.
  • a system in which database 606 and destination server 614 are resident on server machine 608 may be more efficient than a system in which a database and a destination server are housed on different machines, as for example the system shown in Figure 4.
  • the access time associated with accessing database 606 from destination server 614 may be reduced.
  • Such a configuration for server machine 608 may be suitable for use within a localized network which includes only a single destination server 614.
  • the use of database 606 and destination server 614 housed on server machine 608 may result in significant cost savings.
  • a process 700 of publishing a document begins at step 702 in which the user saves, or writes, the document to be published onto a database. Specifically, the user saves the document onto the database associated with the publishing application.
  • the process of saving the document or, more generally, data onto the database may be accomplished using any suitable method, as will be understood by those skilled
  • the document may generally be saved onto the database in a variety of different formats which include, but are not limited to, a C programming language data structure and an XML format.
  • the user obtains a UID for the document from the database in step 704.
  • the UID effectively identifies the location within the database at which the document is stored and, in one embodiment, is essentially a serial number associated with the document.
  • process flow moves to step 706 where a machine number and a security key for the destination server are obtained from the database.
  • the machine number is generally part of an overall address associated with the destination server.
  • the machine number is obtained as a part of an overall Universal Resource Locator (URL) that typically also includes a port identifier and a path.
  • the security key may be a string of characters, or substantially any other identifier which uniquely identifies an associated destination server, and is stored only in the database.
  • each destination server associated with the database will have a unique security key which is accessible only to the user. In another embodiment, however, each machine, rather than each destination server, may have a unique security key.
  • a publish command is sent to the destination server in step 708 after the user obtains the machine number and the security key. Since the document to be published is saved on the database, the publish command is sent to the destination server without sending the document, or the data contained within the document. Specifically, in one embodiment, the publish command is sent substantially only with the UID and the security key. The UID is sent to enable the destination server to locate the document on the database, while the security key is sent to allow the destination server to verify that the publish command is legitimate, e.g., that the user is an authorized user.
  • the publish command may generally take on a variety of different formats. By way of example, the publish command may take the following format: publish ⁇ UID> ⁇ security key> where the publish command is arranged to cause the document identified by the UTD if the security key is found to be valid, as will be described below.
  • the destination server retrieves its key, i.e., the destination server key, from the database in step 710.
  • the destination server key which is stored on the database, is arranged to uniquely identify the destination server.
  • the destination server may be a character string.
  • the destination server key is stored in a data structure on the database, and may only be accessed by the destination server.
  • the destination server compares the destination server key to the security key in order to determine whether the destination server key and the security key are the same. That is, a determination is made as to whether the security key is legitimate and, hence, whether the publish command came from a legitimate user.
  • step 712 determines whether the destination server key is the same as the security key. If the determination in step 712 is that the destination server key is not the same as the security key, then the implication is that the user does not possess the authorization to publish documents onto the web browser associated with the destination server. That is, the implication is that the security key is not valid, or otherwise not legitimate. Accordingly, process flow moves from step 712 to step 714 where a failure error is returned to the user to indicate that the publish command was unsuccessful.
  • step 712 determines whether the destination server key and the security key match. If the determination in step 712 is that the destination server key and the security key match, then the implication is that the document identified by the UID may be published. As such, process flow moves from step 712 to step 716 in which the document identified by the UID is loaded from the database onto the destination server.
  • the document may be loaded into a predetermined location, such as a particular directory, that is associated with the destination server.
  • the document is translated into a suitable output format in step 718.
  • the document is typically stored on the database in a format that is different from its intended output format.
  • a document may be stored on the database as a C programming language data structure.
  • the output, e.g., display, format is generally a format such as a html format, an XML format, a PDF format, or a Java language format, although it should be appreciated that the output format may generally be widely varied.
  • step 718 After the document is translated into a suitable output format in step 718, then in step 718, then in step 718, then in step 718
  • step 720 the translated document is outputted onto the web browser.
  • pre-publish and post-publish commands are substantially the same as the processing of a publish command.
  • a pre-publish command e.g., a create command
  • a post-publish command may be used after a document has been published, in order to provide additional "pages" on the web server that are related to a published document.
  • a process 800 of deleting a document begins at step 802 in which a user obtains a UID for the document from the database. As previously described, the UID identifies the location within the database at which the document is stored.
  • step 804 the machine number and the security key corresponding to the appropriate destination server are obtained by the user.
  • the machine number may be included as part or an overall URL.
  • step 806 the user sends a delete command to the appropriate destination server, e.g., the destination server identified by the machine number. By sending the UID with the delete command, it is unnecessary to send the actual document that is to be deleted to the destination server.
  • the destination server retrieves its key from the database in step 808 in response to the delete command. Then, in step 810, a determination is made as to whether the destination server key and the security key match. In other words, the validity of the security key is ascertained. If the determination in step 810 is that the security key does not match the destination server key, then the security key is
  • step 810 a failure error is returned to the user to indicate that the delete command has been unsuccessful.
  • step 810 determines whether the destination server key and the security key match. If the determination in step 810 is that the destination server key and the security key match, then process flow proceeds to step 814 in which the document identified by the UID is loaded onto the destination server.
  • the document is loaded, in the described embodiment, because the document contains information relating to the location on the web browser at which the translated version of the document resides. More generally, the document identified by the UID includes information that is pertinent to the location and format of the corresponding relevant files on the web browser.
  • the files resident on the web browser that are relevant to the document identified by the UID are deleted from the web browser in step 816.
  • Methods generally used to delete files from a web browser are well- known in the art.
  • Figure 9 illustrates a typical, general-purpose computer system suitable for implementing the present invention.
  • a computer system 930 may be one representation of a user, such as user 302 of Figure 4.
  • Computer system 930 includes any number of processors 932, which are also referred to as central processing units, or CPUs.
  • CPUs 932 are coupled to memory devices which include, but are not limited to, a first primary storage device 934 that is typically a random access memory, or RAM, and a second primary storage device 936 that is typically a read only memory, or ROM.
  • Both primary storage devices 934 and 936 may include any suitable
  • a secondary storage medium 938 which is typically a mass memory device, is also coupled bi-directionally to CPUs 932 and provides additional data storage capacity.
  • Mass memory device 938 is a computer-readable medium that may be used to store programs including computer code, data, and the like.
  • mass memory device 938 is a storage medium such as a hard disk, a tape, or a CD-ROM, which is generally slower than primary storage devices 934 and 936.
  • Mass memory storage device 938 may include a secure database. It will be appreciated that the information retained within mass memory device 938, may, in appropriate cases, be incorporated in standard fashion as part of RAM 936 as virtual memory.
  • CPUs 932 are also coupled to one or more input/output devices 940 that may include, but are not limited to, devices such as video monitors, track balls, mice, keyboards, microphones, touch-sensitive displays, transducer card readers, magnetic or paper tape readers, tablets, styluses, voice or handwriting recognizers, or other well-known input devices such as, of course, other computers.
  • CPUs 932 optionally may be coupled to a computer or telecommunications network, e.g., an internet network or an intranet network, using a network connection as shown generally at 912. With such a network connection, it is contemplated that the CPUs 932 might receive information from a server machine, or might output information to the server machine in the course of performing the above-described method steps.
  • Such information which is often represented as a sequence of instructions to be executed using CPUs 932, may be received from and outputted to the network, for example, in the form of a computer data signal embodied in a carrier wave.
  • the above-described devices and materials will be familiar to those of skill in the computer hardware and software arts.
  • publishing a document on a web browser has effectively been described in terms of saving the document on the web browser.
  • publishing a document may generally include any suitable action such as, but not limited to, displaying the document and storing the document in a manner that allows the document to be readily accessed.
  • the present invention may support substantially any suitable command without departing from the spirit or the scope of the present invention.
  • security keys have been described as being static, security keys may also be dynamic.
  • an application may be arranged to produce a security key when a document is written to a database. The security key may then be used when a destination server is called to publish the document. Once the document is published, the security key may be destroyed.
  • security keys may also be arranged to identify a server machine, in lieu of a destination server. The use of security keys which identify a server machine may be useful when only a single destination server is present on a server machine.
  • the steps associated with publishing a document may be reordered, and steps may be added of deleted, without departing from the spirit or the scope of the present invention.
  • a UID may be obtained after a machine number and a security key are obtained.
  • validity checks may be inserted throughout the process, e.g., a step associated with a determination of whether a document is successfully loaded onto the destination server may be included. It should be appreciated that the steps associated with deleting a published document may also be varied as well.
  • the present invention has been described in terms of allowing documents to be published on web browsers or web servers, the present invention may generally be applied to substantially any system in which the security of an information server may be an issue without departing from the spirit or the scope of the present invention.
  • the present invention may be implemented for use in preventing unauthorized data from being stored on a database that may be accessed by multiple applications.

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Security & Cryptography (AREA)
  • Theoretical Computer Science (AREA)
  • Software Systems (AREA)
  • General Engineering & Computer Science (AREA)
  • Computer Hardware Design (AREA)
  • Physics & Mathematics (AREA)
  • General Physics & Mathematics (AREA)
  • General Health & Medical Sciences (AREA)
  • Bioethics (AREA)
  • Health & Medical Sciences (AREA)
  • Databases & Information Systems (AREA)
  • Storage Device Security (AREA)
  • Information Transfer Between Computers (AREA)

Abstract

La présente invention concerne des procédés et un appareil permettant à un client de publier des documents sur un serveur d'informations sécurisé sans accéder directement au serveur d'informations. Dans un premier aspect de l'invention, un procédé de publication de données crées par un utilisateur sur une machine serveur consiste à transmettre ces données de l'utilisateur à une base de données couplée de manière communicative, à la fois à l'utilisateur et à la machine serveur, puis à mémoriser ces données sur la base de données en question. Cette base de données transmet un identificateur qui identifie l'emplacement de mémoire des données dans la base de données de l'utilisateur, l'utilisateur transmettant l'identificateur et non pas les données, dans une commande de publication à la machine serveur. La commande de publication est conçue pour amener la machine serveur à accéder aux données mémorisées dans la base de données. En réaction à la demande de publication, la machine serveur extrait ces données de la base de données. Dans un mode de réalisation, la machine serveur comprend un serveur de destination et un serveur de sortie.
EP99911382A 1998-03-13 1999-03-12 Procede et appareil de publication de documents dans un environnement protege Withdrawn EP0981789A1 (fr)

Applications Claiming Priority (3)

Application Number Priority Date Filing Date Title
US7785498P 1998-03-13 1998-03-13
US77854P 1998-03-13
PCT/US1999/005524 WO1999046665A1 (fr) 1998-03-13 1999-03-12 Procede et appareil de publication de documents dans un environnement protege

Publications (1)

Publication Number Publication Date
EP0981789A1 true EP0981789A1 (fr) 2000-03-01

Family

ID=22140447

Family Applications (1)

Application Number Title Priority Date Filing Date
EP99911382A Withdrawn EP0981789A1 (fr) 1998-03-13 1999-03-12 Procede et appareil de publication de documents dans un environnement protege

Country Status (6)

Country Link
EP (1) EP0981789A1 (fr)
JP (1) JP2001525971A (fr)
CN (1) CN1266509A (fr)
AU (1) AU3003399A (fr)
CA (1) CA2289784A1 (fr)
WO (1) WO1999046665A1 (fr)

Families Citing this family (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US7681238B2 (en) * 2005-08-11 2010-03-16 Microsoft Corporation Remotely accessing protected files via streaming

Family Cites Families (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JPH0981445A (ja) * 1995-07-11 1997-03-28 Matsushita Electric Ind Co Ltd 情報管理装置
US5692047A (en) * 1995-12-08 1997-11-25 Sun Microsystems, Inc. System and method for executing verifiable programs with facility for using non-verifiable programs from trusted sources

Non-Patent Citations (1)

* Cited by examiner, † Cited by third party
Title
See references of WO9946665A1 *

Also Published As

Publication number Publication date
CN1266509A (zh) 2000-09-13
AU3003399A (en) 1999-09-27
CA2289784A1 (fr) 1999-09-16
WO1999046665A1 (fr) 1999-09-16
JP2001525971A (ja) 2001-12-11

Similar Documents

Publication Publication Date Title
JP2996937B2 (ja) サーバ
JP4738708B2 (ja) 証拠ベースのセキュリティポリシーマネージャ
EP1235143B1 (fr) Procédé et dispositif pour créer et maintenir des propriétés spécifiques de version dans un fichier
KR101024769B1 (ko) 잠금 설정 지연 방법, 원격 파일 사용 방법, 파일 요청 컴퓨터 시스템, 컴퓨터 판독 가능 기록 매체, 및, 코프로세싱 장치
US6282618B1 (en) Secure variable storage for internet applications
US8612993B2 (en) Identity persistence via executable scripts
US20060259960A1 (en) Server, method and program product for management of password policy information
US10509905B2 (en) Ransomware mitigation system
US20050120359A1 (en) Computer file system driver control method, program thereof, and program recording medium
US20080282354A1 (en) Access control based on program properties
EP3189464A1 (fr) Partage sécurisé de documents
KR20060050223A (ko) 데이터 저장소에 동적으로 생성된 연산들 검증 방법 및시스템
US20070192324A1 (en) Method and device for advanced cache management in a user agent
JP4500072B2 (ja) ネットワークストレージ装置における認証プログラム
US8234412B2 (en) Method and system for transmitting compacted text data
US20150213286A1 (en) Virtual file-based tamper resistant repository
EP0981789A1 (fr) Procede et appareil de publication de documents dans un environnement protege
CN111368231B (zh) 一种异构冗余架构网站的测试方法及装置
GB2561862A (en) Computer device and method for handling files
JP4342326B2 (ja) データベース制御装置
US8397295B1 (en) Method and apparatus for detecting a rootkit
JPH07295876A (ja) アクセス権管理装置
US8640244B2 (en) Declared origin policy
JP4371995B2 (ja) 共有ファイルのアクセス制御方法、システム、サーバ装置、及びプログラム
US7380246B2 (en) Method and system of accessing at least one target file in a computer system with an operating system with file locking implemented with byte-range locking

Legal Events

Date Code Title Description
PUAI Public reference made under article 153(3) epc to a published international application that has entered the european phase

Free format text: ORIGINAL CODE: 0009012

17P Request for examination filed

Effective date: 19991124

AK Designated contracting states

Kind code of ref document: A1

Designated state(s): AT BE CH CY DE DK ES FI FR GB GR IE IT LI LU MC NL PT SE

STAA Information on the status of an ep patent application or granted ep patent

Free format text: STATUS: THE APPLICATION IS DEEMED TO BE WITHDRAWN

18D Application deemed to be withdrawn

Effective date: 20021001