Internet-based automatic publishing system

Description Submit all comments and votes

BACKGROUND OF THE INVENTION

The present invention relates to hypertext networks such as the World Wide Web, and in particular to remote management of published hypertext pages.

With the exponential growth of the World Wide Web, a distributed system of linked hypertext pages, many nontechnical businesses and persons will want to be authors on the World Wide Web. Typically, the process of publishing on the World Wide Web is for the author to arrange for space on an Internet service provider (ISP) machine which the author then configures to contain the appropriate directory structure necessary for the pages to be published and transfers the pages to be published to the ISP's machine and tests that the pages operate as expected on the ISP's machine. This complex process has left prospective nontechnical publishers with two choices: either educate themselves on the complexities of setting up a web structure or pay someone more knowledgeable to set up the structure and upload the pages.

Therefore, what is needed is a simple system for publishing web pages usable by nontechnical authors.

SUMMARY OF THE INVENTION

The present invention provides a simple method and apparatus for posting hypertext documents to a hypertext server so as to make the hypertext documents accessible to users of the hypertext document system while securing against unauthorized modification of the posted hypertext documents. In one embodiment of such a system according to the present invention, the hypertext documents form a portion of the World Wide Web and a process for posting hypertext documents begins with an author authoring the hypertext pages on a client computer, sending an add request to a server computer, causing the generation of a unique identifier for the author of the hypertext document, obtaining a charge authorization from the author, and sending a database entry request from the client to the server comprising the unique identifier, the charge authorization and the hypertext files comprising the document. At the server, the validity of the charge authorization is verified, and if the charge authorization is valid, the hypertext pages are stored in association with the unique identifier and the client is provided with a password needed to effect future modifications of the hypertext pages so published.

A further understanding of the nature and advantages of the inventions herein may be realized by reference to the remaining portions of the specification and the attached drawings.

BRIEF DESCRIPTION OF THE DRAWINGS

FIG. 1 is a high-level block diagram of a hypertext publishing system according to a present invention.

FIG. 2 is a block diagram showing an authoring system and a hypertext server in greater detail.

FIG. 3 is a flow chart illustrating the process and data flow associated with adding a new collection of hypertext pages to a hypertext server according to the present invention.

FIG. 4 is a block diagram of a process of updating the hypertext pages on the hypertext server.

FIG. 5 is a flow chart and data diagram illustrating the process of providing location virtualized hypertext pages.

FIG. 6 is a screen capture of a hypertext page displayed in a browser according to the present invention.

FIG. 7 is a flow chart illustrating a process using a database server interfaced to a hypertext transport protocol server and client.

DESCRIPTION OF THE PREFERRED EMBODIMENT

FIG. 1 is a high-level block diagram showing the various broad hardware components of a directory and publishing system 10 according to the present invention. As shown, system 10 comprises an author computer 12 connected through an author ISP 14 via Internet 16 to a central server 18. The connections are typically TCP/IP (Transmission Control Protocol/Internet Protocol) connections, but other connections and protocols are also possible. For example, the connection between author computer 12 and author ISP 14 might be a SLIP/PPP (Serial Link IP/Point-to-Point Protocol) connection. Author computer 12 is used by an author of a web site to generate the pages for that web site. As used herein, the term "web site" refers to one or more pages following a theme chosen by the author, be it a business, personal, political or other theme or collection of related themes. Where the web site comprises more than one page, the pages are typically linked by reference. Often, a web site is designed with an introductory page ("home page") with the other pages being linked to the home page in a tree structure with the home page being the root of the tree structure. When viewed in this manner, a reader generally starts at the home page and navigates around to the other pages in the web site using the links provided on the home page. As is typical on the World Wide Web, the pages of the author's web site may well include links to pages which are in some way relevant to the author's theme, but which are not controlled, authored or edited by the author of the web site. The particular theme of the web site is dependent on the author's intent in setting up the web site and is limited only by the author's imagination. Where the author is a business, the theme of the web site is typically the offerings and capabilities of the business which authored the web site.

In order for the author to make available the pages of the web site to users of the Internet, the author transfers the pages of the web site from author computer 12 to central server 18 by the mechanism described in greater detail below.

One of the disadvantages of an open system such as internet 16 is that unauthorized persons might attempt to impersonate the author and cause the uploading of unauthorized pages onto central server 18. To prevent such an occurrence, the initial upload of pages from author computer 12 to central server 18 is accompanied by a credit authorization from the author. The credit authorization is verified by central server 18 through a credit server 20. In one embodiment, credit server 20 is a conventional credit card authorization server which is commonly used to process credit card authorization requests. In a preferred embodiment, credit card server 20 is coupled to a financial services network (not shown) which performs the authorization.

Also shown in FIG. 1 is two reader computers 24 and a reader ISP 26. Reader computer 24 would be used by a reader to access the authored web site after it is stored on central server 18. As should be apparent, since the interconnection between reader computer 24 and ISP 26 is a TCP/IP connection, a single computer can serve as both author computer 12 and reader computer 24. However, what a reader sees at author computer 12 and reader computer 24 might be different if the web pages are configured to provide different presentations to computers hooked through different ISP computers. This aspect of the present invention is described in further detail in the text accompanying FIG. 5.

FIG. 2 shows components of author computer 12 and central server 18 in further detail. Author I/O 30 is a conventional I/O system which allows viewing and editing of computer files. Author I/O 30 is coupled to a web browser 32 to allow HTML (Hypertext Markup Language) files to be viewed and manipulated. The HTML files viewed with web browser 32 are obtained from a web file depository 34 at central server 18 via Internet 16, as is well known in the art of navigating the World Wide Web. Author I/O 30 also provides editing commands to an HTML authoring system 36, whose output is a collection of HTML files 40. Along with local variables 42 stored within author computer 12, a site launcher client 44 interacts with a Simple Web Update Protocol (SWUP) module 46 (explained in more detail below) at central server 18 to upload the HTML files 40 into web file depository 34 while securing the files against unauthorized modification. In addition to the HTML files, site launcher client 44 provides local variables to central server 18 which are stored into an e-Card database 48. Although central server 18 is shown as one machine in FIG. 1 and web file depository 34 and e-Card database 48 are shown on one server it should be apparent from this disclosure that multiple servers can be used and elements can be stored on separate servers.

In operation, the author uses author computer 12 to create and package the HTML files 40 comprising the web site as well as entering local variables 42. Local variables include the author's business or personal name, the unique ID associated with the web site, and possibly an encrypted credit card number and a modification password. A list of other local variables is shown in Appendix A. Local variables 42 contain sufficient information to pas from site launcher client 44 to SWUP module 46 in order to correctly verify authorization and correctly locate the destination for the uploaded web files and database information. The database information is illustrated by the schema shown in Appendix B.

A more detailed description of the upload process will now be described. FIG. 3 is a flow chart and data flow diagram illustrating the process of uploading of a set of HTML pages making up an author's web site. The steps in FIG. 3 are numbered from S1 to S11 and are executed in numerically increasing order except where indicated.

At step S1, the author creates the web pages which form the web site and enters necessary company data (company name, E-mail address, etc.). At step S2, client 44 sends an e-Card Add Request to server 18. The e-Card Add Request is an HTTP/SWUP conversation (steps S2, S3, S4) which might proceed as shown in Appendix C.

The unique ID (C.sub.-- ID field) is generated based on the company name supplied by the client. In a preferred embodiment, the unique ID is a short sequence of characters related to the company name, possibly including additional characters or digits to ensure that the generated unique ID is unique with respect to all previous generated unique ID's. Of course, any other scheme for assigning unique ID's could be used (e.g., random numbers, sequential numbers, assigned numbers based on time of entry). In the example shown in Appendix C, a "1" is used in the unique ID because the ID "OQV" is presumably already in use.

At step S5, client 44 receives the unique ID and stores it as a local variable. Client 44 then requests a credit card number from the author (step S6), and encrypts the credit card number (step S7). In a preferred embodiment, public key encryption is used, wherein client 44 requests and receives from server 18 a public key for the encryption session. Client 44 uses the received public key to encrypt the credit card number.

Once a credit card number is encrypted, client 44 creates an e-Card Create Request in the form of a multi-part message, such as shown by the example in Appendix D, and uploads the request to server 18 (step S8). Because the e-Card Create Request includes the credit card number of the author and thus serves as a charge authorization, impostors are less likely to upload unauthorized pages since they will have to pay for the posting and storage of such pages.

In step S9, server 18 verifies the e-Card data. As part of the verification process, server 18 checks the validity of the credit card number and checks to insure that the unique ID is still available. Normally, a unique ID supplied in response to an Add Request would still be unique when received as part of an e-Card Create Request, but it is possible for a client to send an e-Card Add Request and then never follow up with an e-Card Create Request. After a predetermined amount of time, the unique ID is released for lack of response and can be used by another author. Another situation where the unique ID would be rejected at step S9 is where the sender of the e-Card Create Request does not actually have the authority to use the unique ID. Yet another situation where the unique ID check may fail is where an author inadvertently sends an e-card create request more than once. After the initial e-Card Create Request, an author should instead use an update request to modify the author's web pages.

If the e-Card data is verified, server 18 moves the files to web file depository 34, updates e-Card database 48 and sends a password to client (step S10) using a SWUP message. At step S11, the password is recorded in local variables 42 and the author is notified of the result, i.e., the successful posting of the web pages to server 18. If the e-Card data is not verified, a SWUP error message is sent to client 44 and the author is notified of the error.

SWUP Messages

In several steps described above, SWUP messages are transferred between server 18 and client 44. SWUP is a protocol novel to the present invention which extends the capabilities of HTTP by providing a mechanism to exchange a wide variety of data types over a protocol designed for the limited transfer of HTML documents between an HTTP server and an HTTP client. A SWUP client (such as client 44) sends messages to a SWUP server such as those messages listed in Table 1, while a SWUP server (such as server 18) sends messages to a SWUP client such as those messages listed in Table 2, typically in response to a message from a SWUP client.

TABLE 1 ______________________________________ SWUP Client Messages Message Parameters Description ______________________________________ GMRV version Get minimum required version GMLT version Get path to the CGI script used for uploading multi-part files GSUB version Get path to the CGI script used for submitting e-Card records GHBS version Get home base for author's pages GCAT version Get list of categories GCRD ID, password Get the current e-Card for the ID GKBL version Get file upload limit in kilobytes (KB) GPFM Version Get pricing formula GPRC KB Get the price of an upload of size KB GTIN Get the time between updates GKEY data Get the encryption key GHST version Get the host name ______________________________________

Several of the SWUP client messages have the client version number as their only parameter. For those messages, the version number is not used in filling the request directly, but is used by the server to detect when the client software version is a version which supports or does not support particular features. The response from the server might be dependent on the client version and/or the server version. The details of the SWUP client messages are as follows:

GMRV--the client uses this message to determine the minimum required version, i.e., the oldest version the server is willing to support. The server responds with a $SWUPGMRV message (see below for details of server messages) and possibly a $SWUPTERMINATE message.

GMLT--the client uses this message to determine the script to specify to an HTTP server when sending a multi-part dataset to be uploaded. The server responds with a $SWUPGMLT message indicating the script.

GSUB--the client uses this message to determine the script version to specify to an HTTP server when sending a e-Card record. The server responds with a $SWUPGSUB message indicating the script.

GHBS--the client uses this message to determine the home base for the author's Web pages. The server responds with a $SWUPGHBS message indicating the home base which will be used for the author's Web pages. Usually, the home base is not needed for authoring the Web pages if they have only relative references, but an author might want to make an absolute reference in a link or in HTML text.

GCAT--the client uses this message to obtain a list of categories. The categories pertain to subjects under which the author's e-Card record is to be found. The server responds with a $SWUPGCAT message containing the category list, with one message per category item.

GCRD--the client uses this message to obtain the e-Card record for the ID specified in the message. The server responds with a $SWUPSCRD message containing the e-Card record, with one message per e-Card data element. While anyone can submit a GCRD record for an ID, only the author can change the e-Card data. An author changes e-Card data by submitting a multi-part dataset (including password) using the script retrieved using the GSUB message.

GKBL--the client uses this message to determine the file upload limit in kilobytes (KB). The server responds with a $SWUPGKBL message indicating the file upload limit. The total size of an upload package accepted by the server must be less than or equal to the file upload limit.

GPRC--the client uses this message to determine the price for uploading a given size upload. The parameter for the message indicates how big the upload will be. The server responds with a $SWUPGPRC message indicating the price for an upload of the specified size.

GPFM--the client uses this message to determine the pricing formula in effect. The server responds with a $SWUPGPFM message as illustrated by the example in Appendix C, which is explained in further detail below.

GTIM--the client uses this message to determine the frequency of server updates. The server responds with a $SWUPGTIM message indicating how often updates occur (expressed as a number of hours). A typical update frequency might be every three hours. The update frequency is used to determine when changes uploaded to the server will take effect and be visible to a browser browsing the changed pages.

GKEY--the client uses this message as part of a public key exchange for use in encrpyting data such as the author's credit card number or authorization data block. The server interprets the parameter of the GKEY message as the public key of the client. The server responds with a $SWUPGKEY message containing the public key of the server, possibly encrypted using the public key provided by the client. The key may be unique, depending upon the data sent and the method of key generation. Depending upon the key management protocol, the key may be a public key or a symmetric key.

GHST--the client uses this message to determine the server's host name. The server responds with a $SWUPGHST message indicating the host name. This allows for a negotiation for placement of a website, which need not be on the same server as the SWUP server.

In addition to the above commands, the client will send e-Card records as POST messages to the e-Card submission CGI script. Files are uploaded as MIME messages according to RFC 1867 (which is incorporated herein by reference for all purposes), as illustrated by Appendix C and D.

TABLE 2 ______________________________________ SWUP Server Messages Message Parameters Description ______________________________________ $SWUPGMRV minimum required Response to client version message $SWUPGMLT path to script " $SWUPGSUB path to script " $SWUPGHBS home base URL " $SWUPGCAT category list " element $SWUPSCRD e-Card data element " $SWUPGKBL maximum upload size " $SWUPGPRC upload price " $SWUPGPFM pricing formula " $SWUPGTIM time between updates " $SWUPGKEY server's public key " $SWUPGHST server host name " $SWUPSCID e-Card id Returning e-Card ID $SWUPAECD e-Card successfully added $SWUPUECD e-Card successfully updated $SWUPSPAS password $SWUPSOLD old e-Card data elements $SWUPEIID Invalid ID Code error $SWUPEBUT Inappropriate Language error $SWUPEEML Invalid E-mail Address error $SWUPEDUP Duplicate e-Card error $SWUPEPWD Invalid password error $SWUPEMIS Missing Required Fields error $SWUPENID No e-Card ID error $SWUPUNSF Unsafe Character in Filename error $SWUPTERMINATE Client-server session terminated $SWUPSUCCESS Success $SWUPUPLOAD Upload successful (and files stored) ______________________________________

Each of the server messages might actually be identified in the transmission process by a numerical code for efficient communications, much like an FTP (file transfer protocol) server might respond with numerical codes. Table 3 lists the numerical codes for the above server messages.

TABLE 3 ______________________________________ Server Message Codes Message Code ______________________________________ $SWUPGMRV 200 $SWUPGHBS 201 $SWUPGPRC 202 $SWUPGKBL 203 $SWUPGTIM 204 $SWUPGMLT 205 $SWUPGSUB 206 $SWUPGKEY 207 $SWUPGCAT 208 $SWUPGPFM 210 $SWUPGHST 209 $SWUPSCID 300 $SWUPAECD 301 $SWUPUECD 302 $SWUPSPAS 303 $SWUPSCRD 304 $SWUPSOLD 305 $SWUPEIID 400 $SWUPEBUT 401 $SWUPEEML 402 $SWUPEDUP 403 $SWUPEPWD 404 $SWUPEMIS 405 $SWUPENID 406 $SWUPUNSF 407 $SWUPTERMINATE 666 $SWUPSUCCESS 250 $SWUPUPLOAD 251 ______________________________________

The details of the server messages are as follows:

$SWUPGMRV--return the minimum required version in response to a GMRV message. If the client reports a version number lower than the minimum required version, the server also sends the $SWUPTERMINATE message.

$SWUPGHBS--return the home base for uploads in response to a GHBS message. The home base is used by the client to construct a URL (Universal Resource Locator). An example home base is http://www.linkstar.com/page. Note that the home base can differ from the actual path on the server used to store the web pages.

$SWUPGPRC--return the price of the upload in response to a GPRC message. The price is a function of the size of the upload in kilobytes. The size is sent by the client as part of the GPRC message.

$SWUPGPFM--return the price formula in effect in response to a GPRC message. The price formula indicates the price for an upload (either a one time fee or a monthly or other periodic fee). In the example shown in Appendix C, the parameter of the $SWUPGPFM message is:

1.sup..about. 100.sup..about. 9.95.vertline.101.sup..about. 1024.sup..about. 19.95.vertline. 1024.sup..about. 10.00.

which is interpreted to mean that the cost of an upload of between 1 and 100 kilobytes is $9.95, the cost of an upload of between 101 and 1024 kilobytes is $19.95, and above 1024 kilobytes, each additional 1024 kilobytes is an additional $10.00. Of course, other pricing formulas could be used in place of the example pricing formula.

$SWUPGKBL--return the size of maximum upload permitted in response to a GKBL message.

$SWUPGTIM--return the time between updates in response to a GTIM message. This parameter is used because the databases available to readers might not be updated immediately, so the server tells the client how long to wait before the uploaded data is available.

$SWUPGMLT--return the multi-part upload script path in response to a GMLT message. The script handles file uploads as MIME messages according to RFC 1867. See the multi-part MIME Format Example shown in Appendix D.

$SWUPGSUB--return the submit-ecard script path in response to a GSUB message. The submit-ecard script handles e-Card submissions and updates. The format of an e-Card submission is shown in Appendix D.

$SWUPGKEY--return an encryption key in response to a GKEY message. The encryption key is usually a public key used by the client to encrypt a symmetric key. See Also: LinkStar Key Management Protocol, Applied Cryptography, BSAFE 3.0 User's Manual.

$SWUPGCAT--return an individual category list item. Several $SWUPGCAT messages are returned in response to a GCAT message.

$SWUPGHST--return the host name. This is the name of the host that the client will use for all future connections.

$SWUPSCID--return the author's ID. This e-Card ID uniquely identifies the author's e-Card. This message is sent as part of the e-Card Create Request.

$SWUPAECD--the server sends this message when an e-Card is successfully added. This message is sent as part of the e-Card submission process.

$SWUPUECD--the server sends this message when an e-Card is successfully updated. This message is sent as part of the e-Card submission process.

$SWUPSPAS--the server sends this message to indicate the author's password following an e-Card create request.

$SWUPSCRD--the server sends this message in response to a GCRD message. This message indicates the latest e-Card data for the ID given in the GCRD message.

$SWUPSOLD--the server sends this message to indicate old e-Card data.

$SWUPEIID, $SWUPEBUT, $SWUPEEML, $SWUPEDUP, $SWUPEPWD, $SWUPEMIS, $SWUPENID, $SWUPUNSF--the server sends these error messages in response to the occurrence of their respective errors.

$SWUPTERMINATE--the server sends this message to indicate that a SWUP session has been terminated. One reason to terminate a session is where the server determines that the client is of a version earlier than the server is willing to support.

$SWUPSUCCESS--the server sends this message to indicate that a SWUP message was received and parsed correctly.

$SWUPUPLOAD--the server sends this message to indicate that the new e-Card data or new web files were uploaded correctly and stored in either e-Card database 48 or web depository 34.

Referring now to FIG. 4, a process of updating an author's web files stored in web depository 34 or the author's e-Card record in e-Card database 48 is shown. The flow chart of FIG. 4 is numbered from S20 to S31 and is preformed in increasing numerical order unless otherwise indicated.

The process begins with the author initiating an update request (S20), typically after having edited their web pages. Since the authoritative copy of the author's web pages are those stored locally and can be edited prior to this process, but the authoritative copy of the author's e-Card record is stored in e-Card database 48, so the author does not edit their e-Card data at this time.

Client 44 sends an update request to server 18 to initiate the update process at the server (S21). Server 18 receives the update request and verifies the ID and password (S22). If they are not valid, server 18 returns an error message (S23) such as a $SWUPEIID, $SWUPEPWD, or $SWUPENID message. Otherwise, if the request is valid, server 18 looks up the e-Card data from e-Card database 48 (S24) and sends it to client 44 (S25) as a series of $SWUPSCRD messages.

Once an authoritative copy of the author's e-Card record is received, it is stored locally (S26) and the author edits the e-Card record (S27), if desired, and sends the edited e-Card record and the updated web files along with the author's ID and password (S28) to server 18. Server 18 processes the received updated pages and record (S29), and if it is acceptable, server 18 updates the e-Card database 48 and web file depository 34 (S30). Either way, server 18 informs the author of the result (S31) with a $SWUPUPLOAD message for successful uploads or an error message such as $SWUPEMIS. Several filtering errors might occur at this point. For example, server 18 might return an error message which indicates that the e-Card or a web page contains inappropriate language ($SWUPEBUT), contains an invalid e-mail address ($SWUPEEML), or contains a file reference to a file name with "unsafe" characters likely to cause problems ($SWUPUNSF).

The above description describes how a nontechnical author can create web pages and have them installed on a server where they are accessible to the public without the author having to be familiar with the workings of HTTP. Another benefit of a publishing system according to the present invention is that members of the public (readers) browsing such pages will see pages customized in a number of ways, to accommodate "publishing partners" and the reader. If a publishing partner wants to use the central e-Card database for its own use and the use of its customers, the partner can make an e-Card search engine appear to the user to be the search engine of the partner. One way of implementing this feature is for the partner to provide a link from its pages to the server in a way that identifies the partner. For example, the ABC Company (C.sub.-- ID=abcinc) might be a partner. On ABC's web site or other search engine, the URL pointing to the search engine might be:

http://www.linkstar.com/home/partners/abcinc

with the central server responding to such a URL with a customized search engine page. Such customization might be a simple as adding "Welcome to ABC, Inc.'s e-Card Directory" as a header/title.

In order to preserve the customization over multiple transfers, since HTTP URL requests and responses are stateless, the C.sub.-- ID of the partner is maintained in each subsequent URL. The referring page which referred the client to the partner search engine page can be captured by the server on the first referral and maintained from link to link over the stateless connection so that a "return to partner" button can be implemented. For example, if the reader followed the above link, a button to a subsequent link might have the following URL:

http://www.linkstar.com/home/partners/abcinc?.backslash.

ORIGIN=abcinc&ORIGIN.sub.-- REFERRER=http://www.abcinc . . .

(In the above line, and elsewhere in this specification, single strings of characters unbroken by line breaks or spaces are shown broken into multiple lines so as to fit on the page, but should be interpreted as single strings. In such cases, a line is terminated with a backslash (".backslash.") character. Neither the backslash nor the line break are part of the expression.)

Carrying the ORIGIN.sub.-- REFERRER value along with each URL allows each page to provide a link back to the partner's page without requiring the reader to navigate back through all the pages navigated or the server know in advance which referring page the reader comes from. Advertisements on any given page can also be customized based on the maintained state of the reader's URL's. If the ORIGIN field is identified as ABC, Inc.'s origin, then ABC might request that only its advertisements, or all advertisements but those of its competitors be shown.

Pages might also be customized based on the reader's ID, if the reader has an e-Card. How this is accomplished is illustrated by the flow chart/data flow diagram of FIG. 5. Using this process, a reader enters their ID, if the reader has an ID (S40) and requests a page of the reader's browser (S41). The browser sends an HTTP GET command containing the ID, the requested URL, the name of the reader's host and the referring link. The referring link is the URL of the page, if one was used, which pointed to the currently requested page. Once this information is received by server 18, the server looks up the ID (S42) in e-Card database 48, looks up the URL (S43) in web file depository 34 and customizes the retrieved page (S44) with customization data 50 before sending the page onto the client (S45) as an HTML file. The reader's browser then displays the returned page (S46).

FIG. 6 is a screen capture of a display showing a returned page.

In some cases, a database search might need to be done for retrieve information requested by a reader. In order to present this information in an understandable form, server 18 includes a capability of running database searches using the reader's browser as a front end. This process is shown in FIG. 7, wherein a client sends a query as HTTP FORM data (S70). Server 128 converts this FORM data into a Wide Area Information Search (WAIS) query (S71) and applies the WAIS query to a WAIS database server (S72). Server 18 processes the WAIS results to form an HTML result page (S73) and returns the HTML page so formed to the reader (S74). Other full text search engines, such as the Open Text search engine, might be used in place of the WAIS engine.

The above description is illustrative and not restrictive. Many variations of the invention will become apparent to those of skill in the art upon review of this disclosure. The scope of the invention should, therefore, be determined not with reference to the above description, but instead should be determined with reference to the appended claims along with their full scope of equivalents. ##SPC1##

* * * * *