EP0981789A1

EP0981789A1 - Method and apparatus for publishing documents in a protected environment

Info

Publication number: EP0981789A1
Application number: EP99911382A
Authority: EP
Inventors: William J. Adams; Michael A. Libes
Original assignee: 2way Corp
Current assignee: 2way Corp
Priority date: 1998-03-13
Filing date: 1999-03-12
Publication date: 2000-03-01
Also published as: CN1266509A; AU3003399A; CA2289784A1; WO1999046665A1; JP2001525971A

Abstract

Methods and apparatus for enabling a client to publish documents on a secure information server without directly accessing the information server are disclosed. According to one aspect of the present invention, 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. In response to the publish command, the server machine retrieves the data from the database. In one embodiment, the server machine includes a destination server and an output server.

Description

Method and Apparatus for Publishing Documents in a Protected Environment

BACKGROUND OF THE INVENTION 1. Field of Invention

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.

2. Description of the Related Art

As the use of networked computing systems increases, the security of information servers such as servers on the World Wide Web, is becoming more important. For systems in which an information server is not secure, substantially any user may place data on the information server. Therefore, for information servers which are not secure, there is effectively no way to verify whether data stored on the information server has been corrupted.

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. When 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. Although the security of an information server may be breached in different ways, "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.

In order to preserve the integrity of data on an information server, firewalls are often used to protect the information server from unauthorized access. A firewall, as will be appreciated by those skilled in the art, is often a software program which is arranged to filter data to identify data which is suitable for placement on an information server. Alternatively, a firewall may also be a series of network routers that effectively screens access to an information server.

-1- When information servers are protected by firewalls, users or clients that may access data on the information servers have certain access rights to the information servers. By way of example, a particular user may be allowed to view and modify some files on an information server, while the user is may allowed only to view other files. Typically, even with a firewall, a system administrator will maintain control over user-based activity on the information server. In other words, the system administrator will manage the data on the information server to effectively ensure that the integrity of data on the information server is preserved.

A system administrator generally verifies that each file which is to be placed on a secure information server represents a minimal risk to the overall integrity of the information server. Accordingly, when a user creates a file that is intended to be placed on the information server, the user typically sends the file to the system administrator for verification. Figure 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. As will be described below with respect to Figure 2, if computer system 106 is secure or otherwise protected, then before object 104 may be stored on computer system 106, the validity of object 104 must generally be determined. Alternatively, if computer system 106 is not secure, then user 102 may simply place object 104 on computer system 106.

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. When computer system 106 is secure, and user 102 wishes to publish a file on a web server 108 associated with computer system 106, the file is typically scrutinized to ascertain whether it is publishable. Figure 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. Typically, 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.

After the file is sent to the web master, in step 206, 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. In general, 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.

In 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.

Having a web master verify that a user that a file is publishable is often time consuming, as the web master must study each file that is intended to be published on the web server that the web master is administering. However, without having the web master verify that a file is publishable before publishing the file to the web server, the potential for a file which compromises the integrity of the web server to be stored on the web server increases. Hence, there is typically a trade-off between the security of a web server and the amount of time and resources required to provide security for the web server. As security is important, time and resources are generally allocated to assure the security of the web server, thereby slowing down the overall publishing process.

Therefore, what is desired is a method and an apparatus for efficiently allowing files to be published to a web server without compromising the integrity of the web server. That is, what is desired is a method and an apparatus for efficiently and securely publishing files on a secure web server.

SUMMARY OF THE INVENTION The present invention relates to methods and apparatus for enabling a client to publish documents on a secure information server without directly accessing the information server. According to one aspect of the present invention, 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. In response to the publish command, the server machine retrieves the data from the database.

According to another aspect of the present invention, 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. In accordance with still another aspect of the present invention, 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.

According to yet another aspect of the present invention, 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.

These and other advantages of the present invention will become apparent upon reading the following detailed descriptions and studying the various figures of the drawings.

BRIEF DESCRIPTION OF THE DRAWINGS The invention may best be understood by reference to the following description taken in conjunction with the accompanying drawings in which: 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.

-6- DETAILED DESCRIPTION OF THE EMBODIMENTS The security of information servers such as web browsers is crucial to preserve the integrity of data that is stored on the servers. When the security of a server is breached, as for example by a hacker, the integrity of data stored on the server becomes questionable. Firewalls are often used to protect information servers. In addition, system administrators screen data that is to be placed on a secure server to reduce the risk of allowing inaccurate or damaging data from being placed on the server. Since a system administrator must generally study each piece of data that is potentially to be stored on a secure server, the process of storing data on a secure server often proves to be tedious and time-consuming.

By preventing a user from essentially directly accessing a protected information server, while still enabling the user to publish a document on the server without interacting with a system administrator, the security of the server may be preserved. In one embodiment, 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. By allowing interaction between a user and a database, as well as a web server and a database, 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. By way of example, 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. Typically, document 304 is stored on database 304 in a data structure, e.g., a data structure created in the C programming language. Alternatively, 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. In order to publish document 304, machine 308 loads document 304 from database 306 and, ultimately, onto web browser 310. By having user 302 write document 304 to database 306, 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. As such, the security of machine 308 is less likely to be compromised, since only documents on a secure database, e.g., database 306, are allowed to be placed on server 308. Once obtained, 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.

The actual interaction, or data communication, between user 302, database 306, and machine 308 will be described with respect to Figure 4. Figure 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. In one embodiment, 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. For example, 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. In some embodiments, 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. Although 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. When user 302 stores document 304 onto database 306, 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. In general, 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.

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. Hence, 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. In the described embodiment, 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.

As shown, database 306 is associated with a single server machine 308. That is, in the described embodiment, documents may be obtained for publishing from database 306 only by machine 308. However, in some embodiments, multiple server machines may have access to a single database. Figure 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.

In the embodiment as shown, 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

-9- database 506 may generally be widely varied. By way of example, the number of server machines linked to database 506 may be up to approximately eight or nine server machines. Similarly, while 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. In the described embodiment, 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. Then, when document 504 is to be published on a particular web server 510a-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, as for example user 302, database 306, and destination server 414 of Figure 4, 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. In one embodiment, a user, a database, and a destination server may be housed on a single machine. In another embodiment, 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

-10- the server machine along with a destination server, in accordance with a second embodiment of the present invention. 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.

After document 604 is stored on 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. In the described embodiment, since 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. By allowing resources to be shared between database 606 and destination server 614, 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.

With reference to Figure 7, the steps associated with publishing a document onto a web browser, or web server, will be described in accordance with an embodiment of the present invention. When a user, e.g., a client or an author, intends to publish a document on a web browser, the user generally accesses a database associated with the publishing application which, as described above with respect to Figure 4, is resident with respect to both the user and a destination server to which the web browser is coupled. 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

-11- in the art. 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.

Once the document is saved, 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. After the UID is obtained by the user, 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. For example, in one embodiment, 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. As described above, in one embodiment, 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. As will be appreciated by those skilled in the art, 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.

-12- Upon receipt of the publish command, 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. Like the security key described above, the destination server may be a character string. Typically, the destination server key is stored in a data structure on the database, and may only be accessed by the destination server. In step 712, 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.

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.

Alternatively, 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. Once loaded, 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. By way of example, a document may be stored on the database as a C programming language data structure. However, 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.

After the document is translated into a suitable output format in step 718, then in step

720, the translated document is outputted onto the web browser. Finally, in step 722, the

-13- destination server forwards an indication that the publish command was successfully completed to the user, and the process of publishing a document onto a web browser is completed.

The processing of pre-publish and post-publish commands is substantially the same as the processing of a publish command. In one embodiment, a pre-publish command, e.g., a create command, is used the first time a document is to be published, and effectively serves to "hold" a location for the document on the web server. 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.

When a document on the web browser is to be deleted, as for example when the document is out-of-date or otherwise no longer valid, the document is generally only deleted from the web browser, but is not deleted from the database. Referring next to Figure 8, one process of deleting a document that is published on a web browser will be described in accordance with an embodiment of the present invention. 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.

In step 804, the machine number and the security key corresponding to the appropriate destination server are obtained by the user. As will be appreciated by those skilled in the art, the machine number may be included as part or an overall URL. After the UTD, machine number, and security key are obtained, in 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.

Once the delete command is sent 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

-14- considered to be invalid. When the security is invalid, process flow proceeds from step 810 to step 812 where a failure error is returned to the user to indicate that the delete command has been unsuccessful.

Alternatively, when 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.

After the document identified by the UID is loaded onto the destination server, and information pertaining to the relevant files on the web browser is obtained, then 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. When the deletion of the relevant files is completed, an indication that the delete command was successful is returned to the user in step 818, and the process of deleting a document is completed.

In general, the present invention may be implemented on any suitable computer system. Figure 9 illustrates a typical, general-purpose computer system suitable for implementing the present invention. By way of example, 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.

ROM acts to transfer data and instructions uni-directionally to CPU 932, while RAM is used typically to transfer data and instructions in a bi-directional manner, as will be appreciated by those skilled in the art. Both primary storage devices 934 and 936 may include any suitable

-15- computer-readable media. 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. Typically, 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. Finally, 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.

Although only a few embodiments of the present invention have been described, it should be understood that the present invention may be embodied in many other specific forms without departing from the spirit or the scope of the invention. By way of example, although documents saved on a database have been described as being translated by a destination server once they are obtained, in some embodiments, the translation of documents may be unnecessary. When a document is stored on a database in a " final" format, or a format which is to be displayed on a web browser, the document may be loaded onto the destination server and substantially directly outputted to the web browser.

-16- Publishing a document on a web browser has effectively been described in terms of saving the document on the web browser. However, it should be appreciated that 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. Further, in addition to publish, delete, pre-publish, and post-publish commands, the present invention may support substantially any suitable command without departing from the spirit or the scope of the present invention.

While security keys have been described as being static, security keys may also be dynamic. By way of example, 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. In addition, 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.

In general, 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. By way of example, a UID may be obtained after a machine number and a security key are obtained. In addition, 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.

While 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. For instance, 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.

-17- Although the steps associated with publishing a document on a secure server have been described, it should be understood that the present invention may be applied to the publication of, or the storage of, substantially any suitable data. That is, the present invention is not limited to the publication and storage of documents, but, rather, may be applicable to the publication and the storage of any suitable information. Therefore, the present examples are to be considered as illustrative and not restrictive, and the invention is not to be limited to the details given herein, but may be modified within the scope of the appended claims.

-18-

Claims

1. A method for publishing data created by a user onto a server machine, the method comprising: sending the data from the user to a database mechanism, the database mechanism being in communication with the user, the database mechanism further being in communication with the server machine; storing the data on the database mechanism; sending an identifier from the database mechanism to the user, wherein the identifier is arranged to identify the location of the data stored on the database mechanism; sending a publish command from the user to the server machine, the user being in communication with the server machine, the publish command being arranged to cause the server machine to access the data stored on the database mechanism, wherein sending the publish command from the user to the server machine includes sending the identifier from the user to the server machine; and obtaining the data from the database mechanism, wherein the server machine obtains the data from the database mechanism.

2. A method as recited in claim 1 further including: sending a security key from the database mechanism to the user, wherein the security key is arranged to identify the server machine; and determining when the data is suitable for publishing on the server machine, wherein determining when the data is suitable for publishing on the server machine includes comparing the security key to a server key, the server key being associated with the server machine.

3. A method as recited in claim 2 wherein when it is determined that the data is suitable for publishing on the server machine, the method further includes publishing the data obtained from the database mechanism on the server machine.

4. A method as recited in claim 3 wherein publishing the data obtained from the database mechanism includes translating the data into a format suitable for publication on the server machine.

-19-

5. A method as recited in any one of the preceding claims wherein the server machine includes a destination server and a output server, the method further including: sending a security key from the database mechanism to the user, wherein the security key is arranged to identify the destination server; and determining when the data is suitable for publishing on the output server, wherein determining when the data is suitable for publishing on the output server includes comparing the security key to a server key, the server key being associated with the destination server.

6. A method as recited in claim 5 wherein when it is determined that the data is suitable for publishing on the output server, obtaining the data from the database mechanism includes loading the data from the database mechanism onto the destination server, and the method further includes: translating the data into a format suitable for publishing on the output server; and outputting the translated data to the output server.

7. A method for processing a request from a client to delete a file from an output server associated with a server machine, the file on the output server being associated with data stored by the client onto a database mechanism which is in communication with the server machine and the client, the method comprising: sending an identifier from the database mechanism to the client, wherein the identifier is arranged to identify the location of the data stored on the database mechanism; sending a security key from the database mechanism to the user, wherein the security key is arranged to identify a destination server associated with the server machine; and sending a delete command from the user to the destination server, the user being in communication with the destination server, the delete command being arranged to cause the destination server to access the data stored on the database mechanism, wherein sending the delete command from the user to the destination server includes sending the identifier from the user to the destination server.

A method as recited in claim 7 further including:

-20- determining when the security key substantially matches a server key, the server key being associated with the destination server; and deleting the file from the output server when the security key substantially matches the server key.

9. A method as recited in claim 8 further including loading the data from the database mechanism onto the destination server when it is determined that the security key substantially matches the server key, wherein the data includes an indication of a location of the associated file on the output server;

10. 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, the method comprising: storing the document on a database mechanism, the database mechanism being in communication with the client, wherein the document is stored on the database in a first format; obtaining an identifier from the database mechanism, wherein the identifier is arranged to identify the location of the document on the database mechanism; and sending a publish command to a destination server associated with the server mechanism, the destination server being in communication with the output server, the database mechanism, and the client, wherein sending the publish command includes sending the identifier to the destination server.

11. A method as recited in claim 10 further including obtaining a security key from the database mechanism, wherein the security key is arranged to identify the destination server, and sending the publish command further includes sending the security key to the destination server.

12. A method as recited in one of claims 10 and 11 wherein sending the publish command to the destination server includes: determining when the security key is substantially the same as a destination server key, the destination server key being associated with the destination server; and publishing the document on the output server when the security key is substantially the same as the destination server key.

-21-

13. A method as recited in claim 12 further including: obtaining the document from the database mechanism; and translating the document into a second format, wherein publishing the document on the output server includes publishing the translated document on the output server.

14. A method for publishing a document on an output server associated with a server mechanism, the document being created by a client, wherein the client does not directly publish the document on the output server, the method comprising: receiving a publish command from the client on a destination server associated with the server mechanism, the destination server being in communication with the output server, the publish command including an identifier arranged to identify a location on a database mechanism at which the document is stored in a first format, the publish command further including a security key arranged to identify the destination server; determining when the security key substantially matches a destination server key, the destination server key being associated with the destination server; loading the document from the database mechanism onto the destination server when it is determined that the security key substantially matches the destination server key; and transferring the document from the destination server to the output server.

15. A method as recited in claim 14 further including translating the document from the first format into a second format after the document is loaded from the database mechanism onto the destination server.

16. A method as recited in one of claims 14 and 15 further including retrieving the destination server key from the database mechanism.

17. A method as recited in one of claims 14-16 wherein the database mechanism, the output server, and the destination server are located on the server mechanism.

18. A computer system arranged to publish data created by a client machine, the data being arranged to be published on a server machine, the computer system comprising:

-22- a database mechanism arranged to store the data; a first communications mechanism arranged to pass information between the client machine and the database mechanism, wherein the information includes the data; a second communications mechanism arranged to allow the client machine to send a publish command to a destination server, the destination server being associated with the server machine; a third communications mechanism arranged to allow the destination server to retrieve the data from the database mechanism in response to the command sent by the client machine; and an output server, the output server being associated with the server machine, wherein the output server is arranged to receive the retrieved data from the destination server.

19. A computer program product for publishing data created by a user onto a server machine, the computer program product comprising: computer code that sends the data from the user to a database mechanism, the database mechanism being in communication with the user, the database mechanism further being in communication with the server machine; computer code that stores the data on the database mechanism; computer code that sends an identifier from the database mechanism to the user, wherein the identifier is arranged to identify the location of the data stored on the database mechanism; computer code that sends a publish command from the user to the server machine, the user being in communication with the server machine, the publish command being arranged to cause the server machine to access the data stored on the database mechanism, wherein sending the publish command from the user to the server machine includes sending the identifier from the user to the server machine; computer code that obtains the data from the database mechanism, wherein the server machine obtains the data from the database mechanism; and a computer readable medium that stores the computer codes.

20. A computer program product according to claim 22 wherein the computer readable medium is a data signal embodied in a carrier wave.

-23-

21. A computer program product 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, the computer program product comprising: computer code that stores the document on a database mechanism, the database mechanism being in communication with the client, wherein the document is stored on the database in a first format; computer code that obtains an identifier from the database mechanism, wherein the identifier is arranged to identify the location of the document on the database mechanism; computer code that sends a publish command to a destination server associated with the server mechanism, the destination server being in communication with the output server, the database mechanism, and the client, wherein sending the publish command includes sending the identifier to the destination server; and a computer readable medium that stores the computer codes.

22. A computer program product according to claim 28 further including computer code that obtains a security key from the database mechanism, wherein the security key is arranged to identify the destination server, wherein the computer code that sends the publish command further includes: computer code that sends the security key to the destination server a computer code that determines when the security key is substantially the same as a destination server key, the destination server key being associated with the destination server; and computer code that publishes the document on the output server when the security key is substantially the same as the destination server key.

-24-