JPH11502346A - オンラインサービスの作成および保守用のコンピュータシステムおよびコンピュータ実行プロセス - Google Patents

Abstract

(57)【要約】 本発明のオンラインサービス許可用のクライアント／サーバシステムは、オンラインサービスを成すサーバ装置上に記憶された情報に対する操作を許可するためにサーバ装置にアクセスするクライアント装置を含む。オンラインサービスを許可するためサーバ装置上の情報に対して実行される操作の許可の要求がクライアント装置上で少なくとも１つのメッセージに翻訳され、これがサーバ装置に転送される。サーバ装置はクライアント装置から少なくとも１つのメッセージを受け、受信された少なくとも１つのメッセージ中に識別される許可操作を実施してオンラインサービスを許可する。このサーバ装置上の情報は、ブラウザなど、情報を変更する事なく情報にアクセスするために使用される他のクライアントシステムに対してクライアント装置によってアクセス可能に成される。一般に、クライアント装置がサーバ装置から応答メッセージを受けた時、クライアント装置はこの応答メッセージを使用して、サーバによる許可操作の実行に関する情報を表示する。クライアントとサーバはＴＣＰ／ＩＰ接続を通してＨＴＴＰプロトコールを使用して相互に通信する事ができる。これらの装置は相異なるファイルネームスペースを有し、クライアントによって使用されるＩＤとサーバ上で使用されるＩＤとのマッピングを保持し実行する事をサーバに要求する。サーバはＨＴＴＰメッセージを処理するためのサーバプログラムと、許可操作を処理するためのサーバ拡張プログラムとを有する。このサーバ拡張プログラムは共通ゲートウエーインタフェースを通して呼出される。実行される許可操作は、サーバ上のドキュメントおよびスクリプトなどの情報およびサービス、ドキュメントおよびスクリプトに関するメタ情報の記憶、作成または変更を含む事ができる。またサービスおよびドキュメントのリスト処理を実行する操作も可能である。

Description

【発明の詳細な説明】 オンラインサービスの作成および保守用のコンピュータシステム およびコンピュータ実行プロセス 発明の分野 本発明は電子文書その他の情報およびコンピュータプログラムを許可するため のコンピュータシステムに関するものである。さらに詳しくは、本発明はクライ アント／サーバ情報システムにおいてオンラインサービスを作成し開発および／ あるいは修正するためのコンピュータシステムに関するものである。 発明の背景 オンライン情報システムは代表的には、他のコンピュータシステム（クライア ント）が情報にアクセスできるようにこの情報を使用可能にするコンピュータシ ステム（サーバ）を含む。サーバは、１セットの個別オンラインサービスとして 構成されうる情報に対するアクセスを管理する。サーバとクライアントは、通信 プロトコールに一致しコンピュータネットワークなどの通信チャンネルまたはダ イヤル呼出接続を通して伝送されるメッセージによって相互通信する。 オンラインサービスの代表的な用途は、特に文書閲覧、電子取引、ディレクト リ・ルックアップ、オンライン分類広告、リファレンス・サービス、電子掲示板 、文書探索、電子出版、文書のキーワード検索、製品の技術的支援、およびオン ラインサービスのディレクトリを含む。これらのサービスは情報を有償または無 償で提供し、また公衆アクセス可能としまたはプライベートコンピュータシステ ムとする事ができる。 サーバによって管理される情報源はサーバシステム上のまたは外部コンピュー タシステム上のファイル、データベースおよび適用業務である。サーバの提供す る情報は単にサーバ上に記憶する事ができ、または他のフォーマットから手動的 にまたは自動的に変換する事ができ、またはクライアントの要求に応答してサー バ上でコンピュータ処理する事ができ、またはサーバまたはその他のマシン上で データまたは適用業務から誘導する事ができ、またはこれらの技術の組合わせに よって誘導する事ができる。 オンラインサービスのユーザは、このオンラインサービスによって管理される 情報にアクセスするためクライアントシステム上のプログラムを使用する。ユー ザの可能な機能はサーバによって管理される情報の閲覧、探索、ダウンロード、 印刷およびファイリングである。またユーザはオンラインサービスによって提供 されたサービスまたは商品の値ぶみし、購入し、賃借しまたは予約する事ができ る。 例えばカタログ販売のオンラインサービスは下記のように実施される。ユーザ がクライアントシステム上でクライアントプログラムを走らせ、公知のまたはデ ィレクトリ上に発見されるサービスネームを使用してカタログ販売サービスに対 する接続を要求する。この要求がサーバによって受信されて、サーバは導入文書 を返送してＩＤとパスワードをたづねる。クライアントプログラムがこの文書を 表示し、ユーザは前のビジットにおいてサービスによって指定されたＩＤとパス ワードとを書込み、次にユーザ情報がサーバに転送される。サーバはＩＤとパス ワードとを許可データベースと対照して検査し、メニュー文書を返送し、このメ ニュー文書がユーザに提示される。ユーザがメニュー品目を選択するたびに、こ の選択がサーバに送られ、サーバはカタログデータベースから検索された品目明 細または価格を含む情報の新しい適当なページをもって答える。ユーザは一連の メニュー品目を選択する事により、所望の品目に移動して、その品目のオーダを 要求する。サーバはオーダ要求を受け、ユーザが出荷および請求書作成に関する 情報を書込むフォーマットを返送する。ユーザの応答がサーバに返送され、サー バはそのオーダ情報をオーダデータベースの中に入れる。 オンラインサービスは、多数のコンピュータまたはサイトが相互接続されたグ ローバル・インターネットを通して作動するワールドワイド・ウエブ（ＷＷＷ） 上で使用可能である。同様のサービスは、ローカルエリアネットワークＬＡＮな どのインターネットに接続されていないプライベートネットワーク上で有効であ る。ＷＷＷおよび類似のプライベートアーキテクチャは相互接続される文書対象 の「ウエブ」を成し、これらの文書対象がＷＷＷ上でグローバル・インターネッ トの各サイト上に配置される。またＷＷＷは、T.Berners-Lee，R.Cailliau，A.L uotonen，H．F．Nielsen and A.Secret、”The World-Wide Web ”，Cmmunicati ons of the ACM, 37(8)，pp76 - 82，August 1994 および Berners-Lee，T ほか による”World wide Web：The Information Universe”，Electronic Newworkin g Research ，Applications and Policy, Vol.1，No.2，Meckler，Westport，Con n.,Spring 1992 に記載されている。 オンラインサービス中の文書の型としてドキュメントとスクリプトがある。Ｗ ＷＷ上に公表されるドキュメントは、Hyper Text Markup Language Specificati on - 2.0，by T.Berners-Lee and D.Connolly，RFC 1866，proposed standard， November 1995 および”World Wide Web & HTML.”by Douglas C．McArthur，in Dr Dobbs Journal, December 1994，pp.18-20,22,24,26 and 86 に記載のハイ パーテキスト・マークアップ言語（ＨＴＭＬ）で記入される。また多くの会社が ＨＴＭＬに対するそれ自体のエンハンスメントを開発している。そのまま記憶さ れたＨＴＭＬドキュメントは一般的にスタティックであって、その内容はサービ ス・デブロッパーがそのドキュメントを変更しない限り変化しない。 ＨＴＭＬはハイパーテキスト・ドキュメントを書くために使用される言語であ る。その正式の定義は、特定のドキュメント型定義（ＤＴＤ）に一致する標準一 般化マークアップ言語（ＳＧＭＬ）である。ＨＴＭＬドキュメントはマークアッ プ要素のハイラーキセットを有し、このセットにおいては大部分の要素がスター トタグと、これに続く内容と、これに続くエンドタグとを有する。これらのタグ はかぎかっこの中に包囲され（’＜’および’＞’）、ドキュメントの構成法、 およびドキュメントの表示法、並びにハイパーテキストリンクのあて先およびラ ベルを示す。タイトル、ヘッダー、肉太およびイタリックなどのテキスト属性、 リスト、パラグラフ境界、他のドキュメントまたは同一ドキュメントの他の部分 に対するリンク、インライングラフ画像およびその他多くのフィーチャなどのマ ークアップのタグが使用される。 一例として、下記にＨＴＭＬの数行を示す： このサンプルドキュメントは、"HREF=."など、他のドキュメントに対する「リ ンク」を含むのでハイパーテキストドキュメントである。このリンクのフォーマ ットは下記のように記載される。またハイパーテキストドキュメントは同一ドキ ュメントの他の部分に対するリンクを有する事ができる。リンクを有するドキュ メントは一般的にインターネット上に任意の箇所に配置する事ができる。ユーザ がウエブブラウザと呼ばれるクライアントプログラム（下記に説明）を使用して ドキュメントを閲覧する場合、リンクはハイライト・ワードまたはフレーズで表 示される。例えば、ウエブブラウザを使用してサンプルドキュメントはユーザの スクリーン上に下記のように表示される： ウエブブラウザにおいては、例えばハイライト区域上でマウスをクリックする 事によってリンクを選択する事ができる。リンクの選択は対応のドキュメントを 表示させる。このようにしてハイライトテキスト"Vemeer Technologies，Inc." 上のクリックはそのホームページを表示する。 ウエブ中の他の種類のドキュメント対象はスクリプトである。スクリプトは、 ウエブブラウザに戻されるＨＴＭＬを作成するためにウエブサーバ（下記に説明 ）と呼ばれるサーバプログラムによって走らされるファイル中に記憶された実行 可能プログラムまたはコマンドセットである。代表的なスクリプト動作は、ファ イルまたはデータベースから情報を得るためにライブラリ・ルーチンまたはその 他のアプリケーションを走らせる動作、または選択されたハイパーテキストリン クに対応するドキュメントの検索を含む。例えばエンドユーザがウエブブラウザ 中の特定のハイパーテキストリンクを使用する時、またはＨＴＭＬ型要求を実行 依頼する時にスクリプトをウエブサーバ上で走らせる事ができる。スクリプトは 通常、サービスデブロッパーによって、ベーシック言語、Ｐｒａｃｔｉｃａｌ Ｅｘｔｒａｃｔｉｏｎ ａｎｄ Ｒｅｐｏｒｔ言語（Ｐｅｒｌ）またはＴｏｏｌ Ｃｏｎｔｒｏｌ言語またはＵｎｉｘ作動システムシェル言語の１つなどの翻訳 言語で書かれるが、またスクリプトは「Ｃ」プログラミング言語などのプログラ ミング言語で書かれ、次に実行可能プログラムにコンパイルする事ができる。Ｔ ｃｌプログラミングは Tcl and the Tk Toolkit, by John K．Ousterhout，Addi son-Wesley，Reading，MA,USA，1994 にさらに詳細に記載されている。Ｐｅｒｌ は Programming in Perl. by Larry Wall and Randal L．Schwarts，O′ Reilly & Associates，Inc.，Sebastopol，CA，USA，1992にさらに詳細に記載さ れている。 ウエブ中の各ドキュメント対象はＵｎｉｖｅｒｓａｌ Ｒｅｓｏｕｒｃｅ Ｉ ｄｅｎｔｉｆｉｅｒ（ＵＲＩ）と呼ばれる識別子を有する。これらの識別子は、 T.Bemers-Lee,"Universal Resource Identifier in WWW; A Unifying Syntax fo r the Expression of Names and Addresses of Objects on the Network as use d in the World-Wide Web " RFC 1630，CERN，June 1994 および T.Bemers-Lee. L.Mainter，and M.McCahill,"Uniform Resource Locators(URL),"RFC 1738，CER N，Xerox Parc．University of Minnesota，December 1994 にさらに詳細に記載 されている。ＵＲＩは、前述のＨＴＭＬドキュメントのリンクにおけると同様に 、インターネット上の任意の対象をネームまたはアドレスによって参照させる事 ができる。下記の２つの型のＵＲＩが存在する。すなわち、Universal Resource Name（URN）および Uniform Resource Locator(URL)。ＵＲＮは与えられたネー ムスペース中のネームによって対象を参照する。インターネット・コミュニティ ーはいまだＵＲＮシンタックスを定義していない。ＵＲＬはネットワークプロト コールを使用してアクセスアルゴリズムを定義する事によって対象を参照する。 ＵＲＬの一例は"http://www:vermeer.comm" である。ＵＲＬはシンタックス "sc heme://host:port/path?search" を有し、ここに、 またＵＲＬはＷＷＷそのものではなくプライベートコンピュータシステムにおい てウエブサーバおよびウエブブラウザによって使用される。 ドキュメントをネットワークユーザに対して使用可能にしようとするサイトは 「ウエブサイト」と呼ばれ、ドキュメントにアクセスさせる「ウエブサーバ」プ ログラムを走らせなければならない。ウエブサーバは、ネットワーク上のコンピ ュータをＷＷＷの残部またはプライベートウエブに対して使用可能とするネット ワーク上のコンピュータプログラムである。ドキュメントはしばしばＨＴＭＬ言 語におけるハイパーテキストドキュメントであるが、画像、オーディオおよびビ デオ情報などの他の型のドキュメント対象でもありうる。ウエブサーバによって 管理される情報は、サーバ上に記憶されたハイパーテキストドキュメントまたは ハイパーテキストドキュメントまたはウエブサーバ上のスクリプトによって動的 に生成されるハイパーテキストドキュメントを含む。Conseil Europeen pour la Recerche Nucleaire（CERN，the European Laboratory for Particle Phisics ）サーバまたは National Center for Supercomputing Applications（NCSA）サ ーバなどの二、三のウエブサーバソフトウェアパッケージが存在する。ウエブサ ーバは、Ｕｎｉｘオペレーティングシステムを走らせる Sun Sparc 11 ワークス テーションおよびマイクロソフトＭＳ−ＤＯＳオペレーティングシステムおよび マイクロソフトウインドウズ・オペレーティングシステムを走らせるインテルペ ンティアム・プロセッサを有するパーソナル・コンピュータを含めて、各種のプ ラットフォーム上に実現されてきた。 またウエブサーバは Common Gateway Interface（CGI）と呼ばれる外部プログ ラムを走らせるための標準型インタフェースを有する。このＣＧＩはHow to Set Up And Maintain A Web Site. by Lincoln D.Stein．Addison-Wesley August 1 995 に詳細に記載されている。ゲートウエイは、入力される情報要求を処理し、 適当なドキュメントを返送し、またはドキュメントを動的に生成するプログラム である。例えば、ゲートウエイは問い合わせを受け、ＳＱＬデータベース中に応 答を探索し、サーバがクライアントに結果を伝送できるように応答をＨＴＭＬ語 に翻訳する事ができよう。ゲートウエイプログラムは「Ｃ」言語で、またはＰｅ ｒｌまたはＴｃｌまたはＵｎｉｘオペレーティングシステムシェル言語の１つで 記載する事ができる。ＣＧＩ規格はスクリプトまたはアプリケーションが入力と パラメータを受ける仕方を規定し、また任意の出力がフォーマット化されサーバ に返送される仕方を規定している。 一般的に言って、安全上の理由からウエブサーバ装置はファイルへのアクセス を制限する事ができる。ウエブサーバ上のファイルに対するすべてのアクセスに ついて、サーバ装置上で走るウエブサーバプログラムは通常のファイルシステム を超えた階層の安全性と、サーバ装置上のオペレーティングシステムのログイン 安全手順とを与える事ができる。ウエブサーバプログラムは、（１）オペレーテ ィングシステムがユーザのアカウントで有する正規のユーザネームおよびパスワ ードとは完全に別個のネームとパスワードをオプションとしてユーザに要求し、 （２）オペレーティングシステムの任意のユーザグループ定義とは別個の安全目 的のユーザグループ定義を与え、（３）（オプションとしてパスワードを有する ）特定のユーザまたはユーザグループのみがドキュメント対象にアクセスする事 を許されまたは特定のネットワークアドレスのクライアントにのみ、またはこれ らの規則の組合わせにのみアクセスが許されような各ドキュメント対象に対する アクセス制御、（４）可能なＨＴＴＰ法の特定のサブセットを通してのみドキュ メント対象へのアクセスを許可し、（５）ある種のドキュメント対象をＨＴＬＭ ドキュメント対象とマークし、他のドキュメント対象をＨＴＬＭドキュメントを 生成する実行可能なスクリプトとしてマークし、また他のドキュメントを画像な どの他の型の対象としてマークするなどの追加的安全規則を追加する事ができる 。このようにして、あるネットワークファイルシステムを通してのオンラインサ ービスドキュメント対象へのアクセスは、ウエブサーバプログラムの安全フィー チ ャに一致せず、従ってウエブサーバによって与えられた安全性の外部にあるドキ ュメントにアクセスさせられる。またウエブサーバプログラムは代表的にはクラ イアントに知られたドキュメント対象ネームをサーバファイルシステム上のファ イルネームにマップする。このようなマッピングは任意的に複雑であり、ウエブ サーバ上のドキュメントに直接にアクセスしようとする作成者またはプログラム はこのネームマッピングを理解する必要があろう。 ネットワーク上のウエブサイトにおいて利用可能のドキュメントにアクセスし ようとするユーザ（ウエブサーバによって使用される装置以外の装置を使用する ユーザ）は「ウエブブラウザ」と呼ばれるクライアントプログラムを走らせなけ ればならない。ウエブブラウザ・プログラムにより、ユーザはウエブサーバから ドキュメントを検索し表示する事ができる。一般的なウエブブラウザ・プログラ ムの一例は、カリフォルニア、マウンティング・ビューのＮｅｔＳｃａｐｅ Ｃ ｏｍｍｕｎｉｃａｔｉｏｎｓ Ｃｏｒｐ．から市販されるナビゲータ・ブラウザ 、Supercomputing applications（NCSA）のＮａｔｉｏｎａｌ Ｃｅｎｔｅｒか ら市販されるモザイク・ブラウザ、テキサス、オースチンのMicroelectronics a nd Computer Technology Corp.から市販されるウインウエブ・ブラウザおよびワ シントン、レッドモンドのマイクロソフト・コーポレーションから市販されるイ ンターネット・エクスプローラである。マイクロソフトＭＳ−ＤＯＳオペレーテ ィングシステムおよびマイクロソフトウインドウズ環境を走らせるインテルペン ティアム・プロセッサを有するパーソナル・コンピュータおよびアップル・マッ キントシュ パーソナル・コンピュータを含めて多数のプラットフォームに対す るブラウザが存在する。 ウエブサーバとウエブブラウザは、ハイパーテキスト伝送プロトコール（ＨＴ ＴＰ）メッセージプロトコールおよびインターネットの基礎的な伝送制御プロト コール／インターネットプロトコール（ＴＣＰ／ＩＰ）を使用して通信する。 ＨＴＴＰは、Hypertext Transfer Protocol - HTTP/1.0, by T.Berners-Lee，R. T.Fielding，H.Frystyk Nielsen，Internet Draft document，October 14,1995 に記載され、現在標準化過程にある。ＨＴＴＰにおいては、ウエブブラウザがウ エブサーバに対して接続を成し、ＨＴＴＰ問い合わせメッセージをサーバに送る 。ＨＴＴＰ問い合わせメッセージに対する応答として、ウエブサーバが許可をチ ェックし、問い合わされた動作を実行し、この問い合わされた動作から生じるＨ ＴＬＭドキュメントを含むＨＴＴＰ応答メッセージ、またはエラーメッセージを 返送する。返送されたＨＴＭＬドキュメントは単にウエブサーバ上に記憶される ファイルとし、またはこれはＨＴＴＰ問い合わせメッセージに応答して呼び出さ れるスクリプトを使用して動的に作成する事ができる。例えば、１つのドキュメ ントを検索するため、１つのウエブブラウザがＨＴＴＰ要求メッセージを指示さ れたウエブサーバに送り、そのＵＲＬによってドキュメントを要求する。次にウ エブサーバがそのドキュメントを検索し、このドキュメントをウエブブラウザに 対するＨＴＴＰ応答メッセージの中で返送する。そのドキュメントがハイパーテ キストリンクを有するなら、ユーザは再び新規ドキュメントを検索し表示する事 を要求するためにリンクを選択する事ができる。他の例として、ユーザがデータ ベース探索を要求するフォームに書込んで、ウエブブラウザが探索されるデータ ベースのネームおよび探索パラメータと探索スクリプトのＵＲＬを含むＨＴＴＰ 要求メッセージをウエブサーバに転送する。ウエブサーバはプログラムまたはス クリプトを呼出し、探索パラメータを通す。プログラムがパラメータを調査し、 おそらくは問い合わせをデータベースインタフェースに送る事によって問い合わ せに応答しようとする。プログラムが問い合わせの結果を受ける時、このプログ ラムはＨＴＭＬドキュメントを構成し、このドキュメントがウエブサーバに返送 され、次にウエブサーバはこのドキュメントをＨＴＴＰ応答メッセージの中でウ エブブラウザに送る。 ＨＴＴＰ中の要求メッセージは、サーバによって実施されるべき動作の型を示 す「方法ネーム」と、ウエブサーバ上のターゲット対象（ドキュメントまたはス クリプト）を示すＵＲＬと、その他の制御情報とを含む。応答メッセージはステ ータス・ライン、サーバ情報および可能なデータ内容を含む。Multipurpose Int ernet Mail Extensions（MIME）はネットワーク上に通されるメッセージ内容を 記述する標準的方法である。ＨＴＴＰ要求および応答メッセージはメッセージの フォーマットを示すためＭＩＭＥヘッダ・ラインを使用する。ＭＩＭＥについて は、MIME(Multipurpose Internet Mail Extensions): Mechanisms for Specifyi ng and Dscribing the Format of Internet Message Bodies, Internet RFC 134 1，June 1992 に詳細に記載されている。 ＨＴＴＰプロトコールの現行バージョンにおいて定義された要求法はGET，POS T，PUT，HEAD，DELETE，LINK および UNLINK を含む。HEAD，DELETE，LINKおよ び UNLINK はそれほど一般に使用されず、前記のＨＴＴＰ／１．０ドラフト・ス ペシフィケーションに詳細に記載されている。ＧＥＴはサーバが与えられたＵＲ Ｌによって示される対象を検索しこれをクライアントに返送する事を要求する。 ＵＲＬが１つのドキュメントを示した時、サーバはそのドキュメントを返送する 事によって応答する。ＵＲＬが実行可能スクリプトを示した時、サーバはそのス クリプトを実行し、スクリプトの実行によって生産されたデータを返送する。ウ エブブラウザプログラムはＧＥＴ法を使用して、ＨＴＭＬドキュメントを検索す るための要求メッセージをウエブサーバに送り、次にウエブブラウザはこれらの ドキュメントをクライアントコンピュータのスクリーン上に表示する。 ＨＴＴＰ仕様によれば、ＰＵＴ法は要求中に含まれる対象を与えられたＵＲＬ によって示されるサーバ上の位置に記憶しなければならないと規定している。し かし多くの現行のサーバ装置はこの規定に従わず、単にすべてのＰＵＴ要求を単 一のＰＵＴスクリプトを通して処理し、このスクリプトは一般に不定であって、 サービス作成者によって作成されなければならない。ウエブブラウザは一般にＰ ＵＴ法を使用しない。 ＰＯＳＴ法はデータを、一般にユーザの入力パラメータをＨＴＭＬフォームか らサーバに送る。またＰＯＳＴ要求はサーバ上で走らされるスクリプトのＵＲＬ を含む。サーバがスクリプトを走らせて、要求中に与えられたパラメータを通し 、またスクリプトがクライアントに応答して返送されるべきＨＴＭＬ出力を生成 する。クライアントプログラムが現行ＨＴＴＰプロトコールを使用して任意デー タをウエブサーバに転送するため、クライアントプログラムはＰＵＴ法またはＰ ＯＳＴ法のいずれかを使用しなければならない。ウエブサーバに対するこのよう なデータ転送を実施するにはこれら２つの方法しか存在しないからである。一般 にウエブブラウザは、処理されるべきフォームに関連したデータの転送のための みにＰＯＳＴ法のみを使用する。 コンピュータネットワークにおいてＨＴＴＰプロトコールを使用するウエブサ ーバとウエブブラウザとの通信組合わせを本明細書においてウエブ・アーキテク チャと呼ぶ。プライベートＬＡＮまたはインターネットにおいて使用されるよう なウエブ・アーキテクチャについて説明したので、ウエブアーキテクチャにおい て使用される代表的なオンラインサービスについて下記に説明する。ウエブ・ア ーキテクチャにおいて使用されるオンラインサービスは、ウエブサーバ装置上を 走るウエブサーバプログラムと、ウエブサーバ装置上に記憶されるオンラインサ ービスを特徴づける１セットのサービスファイルとを含む。サービスファイルは 、ＨＴＭＬドキュメント、ＨＴＭＬドキュメントを動的に生産するための実行可 能スクリプトまたはプログラム、およびその他のスクリプトおよびプログラムに よって参照され更新されるその他のサービス情報ファイルを含む。ＨＴＭＬドキ ュメントおよびスクリプトプログラムを含めて、特定のオンラインサービスを構 成する実際データおよびスクリプトは一般にサーバ上に、各サービス用の別個の 区 域に記憶される。サービスのネーム、作成者のネーム、リビジョン・ヒストリー 、サービスに関するコメントおよび作成者情報を含めて、サービスに関する一般 的情報も記憶される。オンラインサービスのエンドユーザは、オンラインサービ スに対して要求を送りまたオンラインサービスから応答を受けるためにクライア ント装置上のウエブブラウザ・プログラムを使用する。オンラインサービスのエ ンドユーザによよって成されるサービスファイルへのすべてのアクセスはウエブ サーバプログラムによって管理され制御される。例えば、オンラインサービスは １つのドキュメントとしてのコーポレイト・ホーム・ページと、記憶カタログの 探索用フォームとしての第２ドキュメントへのリンクとから成る。探索フォーム は「サブミット」ボタンを有し、このボタンがスクリプトをウエブサーバ上で走 らせ、価格つきの製品明細リストを生成し、このリストがウエブブラウザに対し てＨＴＭＬドキュメントとして返送される。各ＨＴＭＬドキュメントは命令され た項目を収集し表示する第２スクリプトに対するリンクを有する事ができる。ま たサービスは許可されたユーザとそのパスワードのリストなどの構成情報を有す る。 第１図はクライアント装置上のオンラインサービスのエンドユーザから見たオ ンラインサービスの各使用段階を示す。エンドユーザは段階１０においてウエブ ブラウザを開始し、段階１２においてプログラムが初ドキュメントのＵＲＬを設 定する。初ドキュメントＵＲＬは構成ファイルから特定する事ができ、またはウ エブブラウザの中にプログラミングする事ができ、またはユーザによって入力す る事ができる。ウエブブラウザは段階１４においてウエブサーバにＨＴＴＰＧＥ Ｔ要求を送り、所望ドキュメントのＵＲＬを与える。次に段階１６においてウエ ブブラウザはウエブサーバからの応答を待つ。段階１８においてウエブブラウザ は応答をテストして、この応答がエラーメッセージを示すかいなかを決定する。 ウエブサーバからの応答メッセージがエラーを示すなら、例えば要求されたドキ ュメントが発見されなければ、段階１２においてウエブブラウザはそのエラ ーをエンドユーザに報告する。さもなければ、ウエブサーバからの応答メッセー ジが要求されたドキュメントを含み、ウエブブラウザが段階２０において、その ドキュメントをＨＴＭＬ言語規約に従ってフォーマット化し表示する。いずれの 場合にも次にウエブブラウザはユーザから次のコマンドの入るのを待つ（段階２ ４）。例えばユーザは、ドキュメントに対するハイパーテキストリンクを選択す る事により、またはさきに閲覧したドキュメントのリストからドキュメントを要 求する事により、または他のなんらかの手段によってユーザによって得られたド キュメントのＵＲＬをタイプ入力する事によって新ドキュメントを閲覧する事を 要求する。段階２６において、ウエブブラウザはユーザのコマンドをテストして ユーザが新ドキュメントを要求しているかいなかを決定する。ユーザが新ドキュ メントを要求しているのであれば、前述の段階１４の処理へ戻る。ユーザが新ド キュメントを要求していなければ、段階３０においてウエブブラウザはコマンド をテストしてそのコマンドがプログラムを出る要求であるかいなかを決定する。 もしそうであれば、処理が停止する。さもなければ、そのコマンドはローカルコ マンドであって、これは段階２８において、ＨＴＴＰ要求を出す事なくウエブブ ラウザによって処理される。エンドユーザは、ドキュメントのスクロールコマン ドまたはドキュメント中に特殊のテキストストリングを探索するコマンドなどの ローカル・ビューイング・コマンドを使用する事ができる。ウエブブラウザがロ ーカルコマンドを処理した後に、ウエブブラウザは再び前述の段階２４のように 次のユーザコマンドを待つ。 第２図はウエブサーバプログラムから見たオンラインサービスの操作を示す。 サーバが開始された時、サーバが連続的に走り、段階４０においてクライアント ウエブブラウザプログラムからネットワーク接続を通してコマンドを受けるのを 待つ。段階４４においてサーバは受けたコマンドをテストして、それがＧＥＴ要 求であるかいなかを決定する。それがＧＥＴ要求であれば、段階５２においてサ ーバが要求中に含まれたＵＲＬを調査し、ＵＲＬがサーバ上に記憶されたＨＴＭ Ｌドキュメントを示すかいなかを決定する。ＵＲＬがドキュメントを指すなら、 段階５８においてそのドキュメントがＨＴＴＰ応答を通してウエブブラウザに返 送される。さもなければＵＲＬがサーバ上に記憶されたスクリプトを示し、段階 ５６においてウエブブラウザがこのスクリプトを走らせてＨＴＭＬドキュメント を生産し、このドキュメントが前述のように段階５８においてウエブブラウザに 返送される。段階４４のテストにおいてそのコマンドのＧＥＴ要求でない事が決 定されれば、段階４８においてサーバがそのコマンドをテストしてＰＯＳＴ要求 であるかいなかを決定する。もしそうであれば、サーバが段階５４において、ス クリプトのＵＲＬとスクリプトのパラメータとを含むパラメータをＰＯＳＴ要求 から検索する。次にサーバは段階５６において、示されたスクリプトを走らせて ＨＴＭＬドキュメントを生成し、このドキュメントが前述のように段階５８にお いてウエブブラウザに返送される。ＨＴＭＬがウエブブラウザに返送された後に 、段階４０において処理が継続する。もし段階４８においてコマンドがＰＯＳＴ 要求ではないと決定されれば、段階５０においてサーバがエラーメッセージをＨ ＴＭＬドキュメントとしてフォーマット化してウエブブラウザに戻す。段階４０ において処理が継続し、サーバが再び次の要求を待ち、プロセスが繰り返される 。 前述のようなオンラインサービスはハイデマンドの中にある。不幸にして、現 在ではオンラインサービスの開発作業は常に広範なプログラミング技術と非常に 専門化された知識とを必要とする。必要時間が少なくなりエラー傾向が低下しま た非プログラマーによっても実行できるようにオンラインサービス構築プロセス を簡単化するツールがきわめて必要とされている。二、三の場合、サービス用デ ータ内容をその固有フォーマットからサーバによって必要とされるフォーマット に変換する事を支援するソフトウェアツールが存在するが、これらのツールはデ ータファイルの変換のみを目的としている。 例えば、ＷＷＷ用のオンラインサービスを構築するためには、サービス作成者 は下記タスクの組合わせを実行する。すなわち、オンラインサービス中に含まれ たハイパーテキスト用の新規ＨＴＭＬドキュメントの作成、オンラインサービス 中に含まれる新規スクリプトの作成、ウエブサーバ装置から現存のＨＴＭＬドキ ュメントの検索および変更、ウエブサーバ装置から現存のスクリプトの検索およ び変更、ウエブサーバ装置上のＨＴＭＬドキュメントまたはスクリプトを記憶し ウエブサーバプログラムがこれにアクセスできるようにする。 ウエブ上にオンラインサービスのドキュメントおよびスクリプトを構築し前述 のタスクを実施するための数種のアプローチが業界公知である。第１アプローチ は、サービス作成者がウエブサーバ装置と同一装置においてテキストまたはＨＴ ＭＬエディタープログラムを走らせ、この装置上に記憶されるオンラインドキュ メントおよびスクリプトを作成しまたは変更する。 この第１アプローチに伴う問題点は、サービス作成者がウエブサーバ装置にお いて、または少なくともウエブサーバ装置に直接に接続された端末において作業 しなければならない事である。サービス作成者がサーバ装置から物理的に離れた 場所にいる可能性があるので、これは必ずしも実際的でない。またサーバ装置上 の資源の性質からこれらの資源を多数のユーザが分有する可能性があるのでサー バ装置が高度の安全性を必要とする事がしばしばである。このような場合、サー バ装置へのアクセスはシステム管理者に限定され、サービス作成者は安全上の理 由からサーバ装置にアクセスする事ができない。例えば、ウエブサーバによって 使用されるファイルに対するアクセスはウエブサーバのみを通して実行可能であ る。 第２のアプローチにはネットワーク接続またはモデムラインを通してサーバ装 置への接続を成すためにサービス作成者がクライアント装置上に端末エミュレー ションプログラムを走らせる。この端末エミュレーションプログラムの故に、ユ ーザはサーバ装置上で直接作業するかのようにこのサーバ装置にプログラムを走 らせる事ができ、このような構造により、ユーザはサーバ上にテキストまたはＨ ＴＭＬエディタ・プログラムを走らせて前述のようにオンラインサービス・ドキ ュメントおよびスクリプトを作成しまたは変更する事ができる。 この第２アプローチは、サーバ装置およびクライアント装置がいずれも端末エ ミュレーションとネットワーク全体の遠隔プログラム実行のために追加プログラ ムを走らせなければならないという問題点を有する。これはいずれの装置におい ても複雑さを増大し、またサービス作成者が非専門家には理解されない簡単なユ ーザインターフェースを有する端末エミュレーションプログラムに習熟する事を 必要とする。またこのアプローチは他種の装置からサーバ装置へのルートを生じ るものであり、これは安全上の理由から望ましくない。従って第１のアプローチ と同様に、サービス作成者は安全上の理由からサーバ装置にアクセスする事がで きず、またはサーバ装置にファイルを書き込む許可が得られない。 第３アプローチにおいて、サービス作成者はまずサーバ装置からクライアント 装置に現存のサービスドキュメントまたはスクリプトを手動でまたはネットワー クファイル転送プログラムを通して転送する。次に作成者はクライアント装置の 上にテキストまたはＨＴＭＬエディタプログラムを走らせて、この装置上のドキ ュメントを作成しまたは変更し、次に出来上がったドキュメントをサーバ装置に 対して手動的に、またはファイル転送プロトコール（ｆｔｐ）またはケルミット 、モデム経由通信のために端末エミュレーションプログラムと共に使用されるフ ァイル転送法などのネットワークファィル転送プログラムを介して転送する。 この第３アプローチはサーバからクライアントにドキュメントを転送し、また 編集の終了後にドキュメントをサーバに逆転送する別個の段階を必要とするので 面倒である。またこのアプローチは他のアプローチと同様の安全性の問題を有す る。 これらの３アプローチはいずれも、ドキュメントについてウエブサーバによっ て使用されたファイルネームが必ずしもドキュメントの実際ファイルネームと同 一でないという問題点を有する。オンラインサービスの作成者は、ウエブサーバ に使用されるＵＲＬに対するファイルネームのマッピングを学ぶ必要がある。 またウエブサーバからファイルを回収する事のできるクライアントブラウザプ ログラムと、回収されたファイルを編集する事のできるクライアントＨＴＭＬエ ディタとから成り、ＮｅＸＴコンピュータについて使用されるTim Berners-Lee によって書かれたＷＷＷアプリケーションが存在する。このプログラムは編集さ れたファイルをウエブサーバに保存する事ができず、またその他サーバ上におい て情報を操作する事ができない。それどころかこのアプローチはファイル転送プ ログラムが編集されたドキュメントをウエブサーバに返送する必要があるので前 記の第３アプローチに類似している。またこのアプローチは、このようにして編 集されたドキュメントの型がＨＴＭＬドキュメントに限定され、この種のドキュ メントがサーバによって処理できないので、ウエブに対するオンラインサービス を許可する完全な解決法ではない。 発明の概要 本発明の全体的目的は、許可プロセスにおいて必要とされる操作をサーバに遠 隔実施させるクライアントシステムを使用して、オンラインサービスを作成し保 持する事のできるウエブサーバを使用したクライアント／サーバシステムを提供 するにある。 ＨＴＴＰを使用してウエブサーバ上にオンラインサービスを作成し保持するよ うにクライアントシステムを構成する際の問題点の１つは、ＣＥＲＮおよびＮＣ ＳＡサーバなどの既存のウエブサーバがＨＴＴＰ ＰＵＴおよびＰＯＳＴ法に対 する支援を有するけれども、これら既存のサーバはＰＵＴ法またはＰＯＳＴ法を 操作するためにサーバ上にスクリプトを開発し設置する必要のある事である。 他の問題点は、許可プロセス中にクライアントからサーバに情報を転送するた めの通信プロトコールの選択にある。ＨＴＴＰ以外のプロトコールが使用された 場合にはそれ以外の問題が生じる。例えば他のネットワークサービスを追加する 必要があり、安全上の抜け穴を生じ複雑性を増大する。 ＨＴＴＰプロトコールを通してオンラインサービスを作成し保持するクライア ントシステムを構成する際の他の問題点はオンラインサービス用の２種以上の成 分ドキュメント対象をウエブサーバの上に記憶する事にある。これらのドキュメ ント対象はＨＴＭＬドキュメント、および要求次第にＨＴＭＬドキュメントを動 的に作成するスクリプトである。許可プログラムがＨＴＴＰプロトコールを使用 してサーバからスクリプトを回収しようとしても、一般にオンラインサービスの 操作中にドキュメントの検索とスクリプトのアクセスのために一般に使用される ＨＴＴＰ ＧＥＴ法を使用する事ができない。その理由は、ＨＴＴＰ ＧＥＴ法 がスクリプトのアクセスに使用された時、スクリプトを実行させて、スクリプト の実行によって生成されたＨＴＭＬドキュメントを返送するからである。 この環境においてオンラインサービスを作成し保持するためのクライアントシ ステムを提供する際のもう１つの問題点は、クライアントプログラムが一般にサ ーバ上のオンラインサービスのドキュメント対象のファイルネームを含むファイ ルネームスペースをサーバ上に有しない事である。このようなファイルネームス ペースの重複は一般にネットワークファイル・システムを使用する事を必要とす る。サーバ上のすべてのオンラインサービスの作成者を含むネットワークファイ ルシステムの生成は一般に非実用的である。またこのようなシステムはあまりに 複雑で容易に設定する事ができず、システム間においてあまりに近い相互作用を 必要とするので、インターネットなどの大型の異質公衆ネットワークにおいては 実施不能である。多くの場合にクライアント許可システムはネットワークファイ ルシステムの設定のためにサーバにアクセスする事ができないであろう。 ウエブサーバプログラムに関するもう１つの問題点は、これらのプログラムは 一般に主としてドキュメントの内容のみに関連したブラウザ専用ドキュメントま たは読み出し専用プログラムを作成するするように設計されている事である。オ ンラインサービスの作成および保守に使用される他のドキュメント特性は与えら れずまた一般にアクセス不能である。さらにこのような情報はしばしばオペレー ティングシステムおよびサーバプログラムに依存する。 本発明は、クライアントシステムがオンラインサービスの生成と保持を支援す る操作集合をサーバシステムによって遠隔実行させるようにした機構を提供する 事によってこれらの問題点を解決する。サーバがＨＴＴＰサーバプログラムであ る場合、これらの操作は、共通ゲートウエー・インタフェース（ＣＧ１）を通し てサーバプログラムによって呼び出されるサーバ拡張プログラムによって実行す る事ができる。あるいはまたこれらの操作は直接にサーバプログラムの中に含ま れる事ができる。クライアントが所望の操作の指示とこの操作のための適当なデ ータ内容とを含むメッセージをサーバに対して送る時にこれらの操作がクライア ントシステムによって引き起こされる。サーバがＨＴＴＰプログラムである場合 、クライアントとサーバとの間の通信はＨＴＴＰに基づく。実行された操作の結 果またはエラーメッセージがサーバからクライアントシステムに返送される。ウ エブ・クライアント／サーバ実施態様において、サーバ拡張プログラムによって 実行された操作から生じる結果またはエラーが。サーバプログラムによって、ま たはサーバ拡張プログラムによってＨＴＭＬ応答メッセージにフォーマット化さ れる。 オンラインサービスの作成と保持を支援する操作は少なくともドキュメント対 象の読み出しと書き込みの両方を含む。さらに、クライアント・アプリケーショ ン・プログラム用のグラフィカルユーザインタフェースを支援するために読み出 し操作と書き込み操作に組合せてその他の操作を実施する事ができる。また例え ばユーザがサービスのドキュメント対象をリスト処理しまたはサーバ上の各種サ ービスをリスト処理する事のできるようにする操作を備える事ができる。１つの サービスおよびそのドキュメント対象に関するメタ情報を作成し変更しまたは保 持する操作も備えられる。ドキュメントまたはサービスを作成する操作も備えら れる。一般に本発明においては、ウエブサーバにおいてオンラインサービス用の 情報を作成しまた変更するような操作を先行技術の場合よりも簡単に実施する事 ができる。 サーバサイドにおいてこのような操作の一部の実行を容易にするた め、ドキュメント対象そのものの情報以上にメタ情報セットを含む情報をサーバ に提供する事ができる。この種の情報はサービスレベルのメタ情報を含み、例え ばサーバ拡張プログラムバージョン、作成時間、および電話番号アドレスなどウ エブ中の多くのドキュメントに共通なマクロ変数値を含む事ができる。ドキュメ ントレベルのメタ情報は作成者、作成期日および最後の変更期日、他のドキュメ ントに対するリンクなどを含む。この情報は特にクライアント許可アプリケーシ ョンプログラムにおいてドキュメント対象の型を示しまたはサービス中のドキュ メント対象を相互関連させる方法を示すためにグラフィカルユーザインタフェー スにおいて使用するのに有効である。クライアントからのデータ内容とサーバお よびオペレーティングシステムの環境の知識を与えられたサーバ拡張プログラム はクライアント許可システムによって要求された操作を実行するためにサーバま たはオペレーティングシステムの特殊操作を実行する。 クライアントサイドにおけるこれらの操作は、サーバとのすべての通信トラン ザクションを処理するクライアント通信アプリケーション・プログラミング・イ ンタフェース（ＡＰＩ）を備える事によって実行される。このＡＰＩはクライア ント・アプリケーション・プログラムによって呼び出される入口点を有し、この 入口点が作成操作と保持操作をエンドユーザに実行させる。このＡＰＩは、クラ イアント許可アプリケーションプログラムが呼び出す事のできる各操作の入口点 を含んでいる。クライアント許可プログラムは要求された操作の結果が受けられ た時に、ＡＰＩによって呼び出される手順を設定する。ＡＰＩがサーバ上で要求 された操作を実行するのに必要なサーバとのトランザクションを処理している間 、クライアント・アプリケーション・プログラムは操作を中止し、または他のタ スクを実行する事ができる。 従って本発明の１つのアスペクトは、クライアント装置を使用してサーバ装置 上でのオンラインサービスを許可するクライアント／サーバシステムである。ク ライアント装置は、オンラインサービスを含む情報に対して許可操作を実行する 許可ツールを有する。このツールは、サーバ装置上の情報を許可するため、この サーバ装置上の情報に対して実施されるべき許可操作の要求を生成する。これら の要求が少なくとも１つのメッセージに翻訳されてサーバ装置に対して転送され る。サーバ装置は許可ツールを使用して許可された情報を記憶する。またサーバ 装置はクライアント装置からメッセージを受けて、受けたメッセージ中に識別さ れる操作の許可を実行してサーバ装置上の情報を許可する。サーバ装置上のこの 情報は、情報を変更する事なく情報にアクセスするために使用される他のクライ アントシステム、例えばブラウザに対してアクセス可能と成される。一般に許可 クライアント装置がサーバ装置から応答メッセージを受ける時、クライアント装 置はこの応答メッセージを使用して、サーバによる許可オペレーションの実行に 関する情報を表示する。 本発明の他のアスペクトは、サーバシステムと通信する許可ツールを有するク ライアントシステムにある。本発明のさらに他のアスペクトは、クライアント許 可ツールと通信するように構成されたサーバシステムにある。クライアントシス テムとサーバシステムとの組合わせによって実行されるプロセス、および個別に クライアントシステムとサーバシステムによって実施されるプロセスも本発明の アスペクトである。当業者が図示の実施例から本発明のこれらのアスペクトの他 の実施態様を誘導する事ができ、また本発明はこの実施態様に限定されない事を 了解されたい。本発明のこれらの１つまたは複数のアスペクトおよび本発明の実 施態様の１つまたは複数のフィーチャの種々の組合わせも本発明のアスペクトで ある。 本発明の１つの実施態様において、クライアント装置は、このクライアント装 置とサーバ装置との間のＴＣＰ／ＩＰ接続を開始する事によってメッセージを転 送する。データを有するＨＴＴＰ要求メッセージが構成され、この場合、データ 内容はトランザクションの型を識別する情報、トランザクションのパラメータ値 およびトランザクションを実行するためにサーバ上に呼出されるプロセスを含む 。このＨＴＴＰ要求メッセージがサーバに転送され、サーバはこのメッセージを 処理して許可操作を実行する。またクライアント装置はサーバ装置からのＨＴＴ Ｐ応答メッセージの受信を検出する事ができる。このような応答メッセージは、 許可操作の実行によって生成されたデータを搬送するデータ内容を有する。クラ イアント装置はユーザに対して許可操作に関する情報を表示する事ができる。Ｈ ＴＴＰ応答メッセージはＴＨＭＬなどのマークアップ言語のデータ内容を含む事 ができる。このような場合、サーバから要求された情報を得るためデータ内容が 解析される。 クライアント／サーバ・コンピュータシステムによって実行される許可操作は 一般にサーバ装置上で情報を生成しまたは変更しまたは記憶する。例えばサーバ 上でデータファイルの内容を変更する事ができる。これらのデータファイルは例 えばオンラインサービスのドキュメントまたはスクリプトなどのドキュメント対 象とする事ができる。またこれらのデータファイルはその他の媒体データとする 事ができる。またデータファイルはオンラインサービスに関するメタ情報とする 事ができる。アクセス制御情報などのファイル情報も変更する事ができる。同様 にドキュメント対象またはサービス全体を生成する事ができる。また既存サービ スまたは１つのサービスのドキュメント対象のリスト処理などの他の操作を実施 する事もできる。 このクライアント／サーバコンピュータシステムにおいて、実行できる許可操 作はオンラインサービスを許可する基本操作の集合としてユーザまたはアプリケ ーションプログラムに対して与えられまたは使用可能に成される。使用される基 本的操作はサーバ上のドキュメント対象の保存である。この集合により、各基本 操作がユーザまたはアプリケーションプログラムによって個別に選択可能となる 。このような集合はアプリケーション・プログラミング・インタフェースまたは ＡＰＩと呼ぶ事ができる。 通信がＨＴＴＰプロトコールを使用してＴＣＰ／ＩＰ接続を通して実施される 本発明のクライアント・サーバコンピュータシステムの他の実施態様においては 、サーバ装置がＨＴＴＰ要求メッセージを受けるＨＴＴＰサーバを走らせる。メ ッセージがサーバコンピュータ上の情報に対して実行される許可操作の要求を含 む事をサーバ装置が検出した場合、サーバ装置は共通ゲートウエーを介して許可 操作を実行するプロセスを実施する。要求された許可操作の実行の結果、ＨＴＭ Ｌドキュメントが受信される。要求された許可操作の結果として、このＨＴＭＬ ドキュメントがクライアントコンピュータに対してＨＴＴＰ応答メッセージの中 で伝送される。 クライアントコンピュータはＨＴＴＰ要求メッセージを送信した後に、代表的 にはサーバ装置からのＨＴＴＰ応答メッセージの到着を検出するプロセスを実行 する。このプロセスの実行によるサーバ装置からの応答メッセージの到着の検出 に対応して、クライアント装置における許可操作の完成のための他のプロセスが 呼出される。このようなメカニズムはＨＴＴＰ通信に限定されない実施態様にお いても使用する事ができる。このメカニズムは、サーバ装置からの応答メッセー ジの到着を検出する第１プロセスと、サーバ装置からの応答メッセージの到着の 検出に対応して実施されるクライアント装置における許可操作の完成のための第 ２プロセスとを含む。サーバ装置から応答メッセージを受けるまで、クライアン ト装置はサーバ装置上で実施される許可操作の結果に依存しない操作を実施し続 ける事ができる。 本発明の実施態様によって解決される特殊の問題点は、クライアント装置のオ ペレーティングシステムがサーバ装置上のファイルのネームを含まずまたはマッ プしないファイルネームスペースを有する場合である。これは代表的にはインタ ーネットおよびＷＷＷなどの異質ネットワークにおける場合である。このような 環境においては、サーバ装置は、クライアント装置によってサーバ上の実際ファ イルネームの中に加えられたファイルネームをマップする。この環境はオンライ ンサービスの作成をある程度プラットフォーム独立性とする。本発明の実施態様 において、サーバ装置上でサーバプログラムにより共通ゲートウエーインタフェ ースを介してサーバ拡張プログラムを実行する事により許可操作が実施され、こ れは追加的なプラットフォームおよびサーバの独立性を与える。またはこれらの 操作を直接に実行するようにサーバプログラムそのものを構成する事ができる。 このシステムの１つの利点は、ウエブにサーバ拡張プログラムを設置した後に 、本発明によってクライアントシステムを使用する事ができるように現行ウエブ ブラウザを変更する必要がない事である。１つの実施態様において、このような 利点は、作成ツールからの要求を処理するために、ウエブブラウザによって使用 されていないＨＴＴＰ法、ＰＵＴ法を利用する事によって達成される。この実施 態様によれば、作成ツールシステムの変更はユーザに対して透明に実施され、ユ ーザは単に情報を観察しまたはオンラインサービスを使用する。他の実施態様に おいては、この利点は、ＨＴＴＰ ＰＯＳＴ法を使用し、特に作成のためにＵＲ Ｌターゲットを使用する事によって達成される。このＵＲＬは、サービスがウエ ブブラウザに対して使用可能に成された後に不能化される事ができる。 このシステムの他の利点は、許可活動を処理するためにＣＧＩメカニズムを介 してサーバ拡張プログラムを使用する事により、標準型ＨＴＴＰサーバを変更な しで使用できる事にある。 先行技術のアプローチに対するこのシステムのさらに他の利点は、オンライン サービス作成者が単一のクライアントプログラムを使用してサーバ上の現行のオ ンラインサービスからスクリプトまたはドキュメントを検索するためのインタフ ェースを成し、オンラインサービスのためにスクリプトまたはドキュメントを編 集しまたは生成し、得られたスクリプトまたはドキュメントをサーバ上の許可の ための既知の許可位置に保存できる事にある。 このシステムのもう１つの利点は、オンラインサービスの作成者が、オンライ ンサービスホストとしのウエブサーバとＨＴＴＰプロトコールを介して通信する 事ができる限り、任意のクライアント装置からのオンラインサービスドキュメン ト、スクリプトおよびサービスまたはドキュメント対象のメタ情報を作成し、変 更しまたは記憶できる事にある。クライアント装置とサーバ装置は、異質ネット ワークにおいて相異なるオペレーティングシステムを走らせる相異なるアーキテ クチャを有する種々の型のプロセッサを有する事ができる。 このシステムのさらに他の利点は、クライアントシステムが、ウエブサーバに 話しかけるウエブブラウザによって使用されるものと同一の型のネットワーク接 続および同一のプロトコール（ＨＴＴＰ）を使用してウエブサーバプログラムと 通信する事にある。これは本発明の遠隔編集ファシリティが、オンラインサービ スと通信するウエブブラウザを支援する事のできる任意のクライアントから作動 する事を意味する。またこれは、本発明による遠隔編集は、ウエブブラウザがウ エブサーバと通信するために必要なもの以外の追加的ネットワーク接続プログラ ムを必要としない事を意味する。 このシステムのさらに他の利点は許可ツールがＨＴＴＰプロトコールおよびウ エブサーバのソフトウェアによって与えられる基本的認証手順を使用する事であ る。サービス装置上のファイルに対するアクセスは、妥当性検査されたユーザネ ームとパスワードとを有するサービス作成者に限定される。従ってＷＷＷ上のオ ンラインサービスにすでに使用されているＨＴＴＰプロトコールを使用する事に より、許可プロセス中においてある程度の安全性が与えられる。 このシステムの他の利点は、ＷＷＷ上のオンラインサービスを成す少なくとも ２つの型のドキュメント対象、すなわちＨＴＭＬドキュメントおよびＨＴＭＬド キュメントを生成するスクリプトプログラムとを遠隔検索し編集しまた保存する ためにこの許可プロセスを使用できる事である。またこのシステムは、ウエブド キュメントの全部または一部について、画像、ビデオ、オーディオまたはその他 の媒体データなどの前記以外の型のドキュメント対象を検索し記憶するために使 用する事ができる。 また本発明の方法を使用するオンラインサービスドキュメント対象の遠隔許可 は、クライアント装置がネットワークファイルシステムを通して遠隔制御して遠 隔サーバ装置上のファイルを読取りまた書き込む事ができるなど、先行技術のア プローチに対して二、三の利点を有する。その１つの利点は、このシステムはウ エブサーバプログラムを通してのみオンラインサービスドキュメント対象へのア クセスを許し、従ってサーバプログラムによって実施され追加的安全規則に一致 する事である。第２の利点は、このシステムがウエブサーバ装置の現存ＨＴＴＰ プロトコール機構を使用するので、このサーバ装置は、クライアント装置から遠 隔ファイルシステムまでのネットワークファイルシステムまたは分有アクセスを 実現するための追加的ソフトウェアまたはサーバプログラムを走らせる必要がな い事である。追加的ソフトウェアは複雑性を増大しまたさらに安全上の抜け穴の 可能性を生じるので、これは１つの利点を成す。第３の利点はこのシステムがウ エブサーバプログラムを通してのみオンラインサービスドキュメント対象へのア クセスを許し、従ってＵＲＬとウエブサーバプログラムのファイルネームとの間 のドキュメント対象ネームマッピング規定に一致する事である。このシステムの 他の利点は、クライアントプログラムもサービス作成者もファイルネームマッピ ングを理解する必要がなく、ＵＲＬを使用さえすればよい事である。 図面の簡単な説明 付図において、 第１図はウエブ上のオンラインサービスの操作中のウエブブラウザ上の動作の 先行技術のシーケンスを示すフローチャート 第２図はウエブ上のオンラインサービスの操作中のウエブブラウザ上の動作の 先行技術のシーケンスを示すフローチャート、 第３図は本発明によりオンラインサービスを生成し保持するシステムのアーキ テクチャを示すブロックダイヤグラム 第４図は本発明においてウエブ情報を記憶する態様のブロックダイヤグラム 第５Ａ図−第５Ｅ図はオンラインサービスのために保持される情報用のファイ ルネームおよびディレクトリネームの例を含む階層ファイルシステムを示し、 第６Ａ図はオンラインサービス例において使用されるＨＴＭＬドキュメント例 、 第６Ｂ図はオンラインサービス例において使用されるドキュメント・メタ情報 例、 第６Ｃ図はオンラインサービス例において使用されるサービスまたはウエブメ タ情報ファイル例、 第７図はトランザクション中にクライアント通信インタフェースによって実施 されるタスクのフローチャート、 第８図はトランザクション中にサーバ装置によって実施されるタスクのフロー チャート、 第９図は本発明の実施態様におけるＨＴＴＰ要求メッセージ例、また 第１０図は本発明の実施態様における応答ＨＴＴＰメッセージである。 詳細な説明 本発明の実施態様の１例を下記に付図について説明するがこれはその１例を示 すにすぎない。これらの図において類似の参照数字は類似の構造を示す。 第３図はオンラインサービスを生成し保持するコンピュータシステムのブロッ クダイヤグラムである。このシステムは通信チャンネル８３を通してサーバ装置 ８４に接続されたクライアント装置８０を含み、この通信チャンネルを通してク ライアントが要求１０８を送り、また応答１１０を受ける。クライアント装置は クライアント通信インタフェース・モジュール８２を有し、このモジュールは、 クライアント装置において実行されるクライアント許可アプリケーション・モジ ュール８１からの要求に対応して要求１０８を生成する。これらの要求はクライ アント装置において実行されるクライアント通信アプリケーション・プログラミ ング・インタフェース（ＡＰＩ）８５を通して実施される。サーバ装置８４はサ ーバプログラム８６を実行しこのプログラム８６はクライアント装置８０に対し て応答１１０を送る。サーバプログラム８６は対応のサーバ拡張プログラム８８ を有し、このプログラム８８はサーバ装置によって実行された時に要求１０８を 処理し、またサーバプログラム８６によって返送される応答１１０を生成する。 サーバ拡張プログラム８８は対応の要求１０８に応答してオンラインサービス９ ０および１００にアクセスするために使用する事ができる。これらのサービスは クライアント・アプリケーション・モジュール８１を使用して生成保持されて、 適当なドキュメント９２、１０２とプログラム９４、１０４を生成する。一般的 に言ってクライアント装置上で実行されるオペレーティングシステムはファイル ネームスペースを有し、このスペースは場合によってはサーバ装置上のファイル ネームを含まずまたはマップしない。 クライアント・アプリケーション・モジュール８１は、コンピュータスクリー ンまたはディスプレー（図示されず）を介してエンドユーザに対するグラフィカ ルユーザインタフェースを成す。グラフィカルユーザインタフェースは、ドキュ メントセットとこれらのドキュメント間のリンクとを閲覧するためのインタフェ ースと、ドキュメントの編集用の編集インタフェースとを含む。このグラフィカ ルユーザインタフェースは、ウインド、メニュー、ダイヤログボックスおよび押 しボタンなどの標準的技術を使用し、これらはキーボードまたは位置決め装置を 通してアクセスされる。このインタフェースを使用して、ユーザは与えられたサ ービス中のまたはサービス全体の中の任意のドキュメントを要求し、生成し、変 更しまたは削除する事ができる。 グラフィカルユーザインタフェースから、ユーザはウエブのアウトラインビュ ー、ウエブのリンクマップビューおよびウエブのドキュメント・サマリビューを 要求する事ができる。アウトラインビューはアウトラインの最上レベルのホーム ・ページドキュメントからスタートし、またホーム・ページドキュメントに対す る従属としてホーム・ページにリンクされたドキュメントを表示する。一般に与 えられたドキュメントは、アウトライン中の与えられたドキュメントに対する従 属として表示される他のドキュメントに対して、これらの他のドキュメントがア ウトラインビューのほかの場所に表示されていないかぎり、リンクされている。 リンクマップビューは開始ドキュメント、開始ドキュメントがリンクするすべて のドキュメントおよび開始ドキュメントにリンクしたすべてのドキュメントを示 す。各ドキュメントは図形アイコンとして表示され、２つのドキュメント間の各 リンクは一方のドキュメントからリンクのターゲット・ドキュメントまでの矢印 として表示される。またリンクマップビューは開始ドキュメントから２または２ 以上のリンクを有するドキュメントを表示する事ができる。ウエブのドキュメン ト・サマリビューはウエブ中のすべてのドキュメント対象のリストを表示し、ド キュメント型、制作者、タイトルまたは生成期日などの種々の特性によってユー ザにリストを選別させる。 またユーザは、サービスのネーム、作成者の情報、期日および時間スタンプ、 ユーザのネームおよびパスワード、ドキュメントまたはドキュメントセットに関 するアクセス制御情報、ドキュメントに含まれる画像またはテキストファイル、 画像マップ情報、タスクリストに関する情報および実行可能のＣＧＩプログラム またはスクリプトなど、サービスと共に保存される補助情報またはメタ情報に対 する変更を要求する事ができる。本発明においてはこの情報はオンラインサービ スの一部として提供される。この情報は下記に第４図の説明に関連して詳細に説 明する。 サーバとの通信を要求するユーザの各要求に対して、クライアント・アプリケ ーション・モジュールはクライアント通信インタフェース・モジュール中の入口 点の１つに対して呼出しを成す。これらの入口点は集合的にクライアント通信Ａ ＰＩとして知られている。このＡＰＩは第７図と第８図の説明に関連して下記に 詳細に説明する。 本発明の実施態様において、クライアント装置８０はインテル８０４８６また はこれよりすぐれたプロセッサを有しマイクロソフト・ウインドウズ３．１オペ レーティングシステムを走らせるＰＣである。前述のように、クライアント・ア プリケーション・モジュール８１は、ＨＴＭＬエディタ、テキストエディタ、ス クリプトエディタなど、各種ドキュメントエディタのいずれかを含む事ができる 。クライアント・アプリケーション・モジュールの正確な形状およびエディタの 機能はユーザの必要と望みに従う。しかしこのようなクライアント・アプリケー ション・モジュールは前述のようにＨＴＴＰ要求メッセージを生成する事により ウエブサーバ上のドキュメント対象の検索と保存を可能とする。現存のウエブブ ラウザはこの機能を果たす保存機能と編集能力を生じるように変更する事ができ よう。さらにＨＴＭＬまたはその他の編集ツールも、下記に説明するように適当 ＨＴＴＰを生成する事によりサーバ上のファイルを検索し保存するように変更さ れれば、本発明に関連して使用する事ができよう。カナダ、オンタリオ、トロン トのＳｏｆｔＱｕａｄ．Ｉｎｃ．から市販されるＨｏＴＭｅｔａＬおよびＭｉｃ ｒｏｓｏｆｔ Ｖｉｓｕａｌ Ｂａｓｉｃなどのドキュメントエディタまたはプ ログラムエディタなどの多数のＨＴＭＬエディタを使用してドキュメントを生成 する事ができるが、本発明はこれらの例に限定されない。例えば、クライアント 装置８０は代表的には14,400ボーまたはこれより早いモデムを使用してインター ネットサービス・プロバイダへのダイヤル呼出し接続を有する事ができる。クラ イアント装置は例えばマイクロソフト・ウインド用のTrumpet Wisock 2.0b アプ リケーションを使用する事ができ、これはＳＬＩＰ接続を有するＴＣＰ／ＩＰス タックを提供するように成されたＷｉｎｓｏｃｋ １．１である。この構造にお いて、クライアント装置はインターネットに対して接続され、それ自体のインタ ーネットアドレスを有する。 この実施態様において、サーバ装置８４は、インテルペンティアム・プロセッ サまたはこれ以上のプロセッサを有しＢＳＤｉ Ｕｎｉｘオペレーティングシス テムを走らせるＧａｔｅｗａｙ ２０００パーソナル・コンピュータである。ウ エブサーバプログラム８６はＵｎｉｘオペレーティングシステムに対して構成さ れた CERN Hypertext Transfer Protocol Daemon（HTTPD）サーバである。また サーバ装置８４は、14,00 ボーまたはこれより早いモデムを使用し、ＢＳＤｉＵ ｎｉｘオペレーティングシステムに伴なうＴＣＰ／ＩＰおよびＳＬＩＰソフトウ ェアを使用してインターネットサービス・プロバイダに対してダイヤル呼出し接 続を有する。ウエブサーバプログラムはオペレーティングシステム以外にオンラ インサービスのドキュメントおよびスクリプトにアクセスを生じる唯一のプログ ラムである。このウエブサーバプログラムはサーバ装置８４のオペレーティング システムとは別個に、ユーザグループ、ユーザネーム、パスワードおよびファイ ルネームを定義する事ができる。この構成により、クライアント装置とサーバ装 置はＴＣＰ／ＩＰ接続を設定し、インターネットにそってメッセージを交換する 事ができる。 この実施態様は一例にすぎない事を了解されたい。各種のコンピュータとオペ レーティングシステムがインターネットを通してＨＴＴＰを使用して通信するた めの適当なサーバおよびクライアントソフトウェアを有する。クライアント装置 とサーバ装置は構内通信網（ＬＡＮ）、広域ネットワーク（ＷＡＮ）によって接 続する事ができ、または同一装置とする事ができるが、共通通信チャンネルを通 して相互に通信する相異なるプロセスを有する。さらに本発明を実施するため、 市販のコンピュータではなく、特殊目的コンピュータシステムを使用する事がで きる。一般に通信はＴＣＰ／ＩＰ接続を通して実施されるが、他のデータ転送プ ロトコールおよびメッセージプロトコールを含めて他のネットワーク通信プロト コールを使用する事ができる。ＨＴＴＰ、ＦＴＰ、テルネットなど、ＴＣＰ／Ｉ Ｐ接続を通して通信するための種々のメッセージプロトコールを使用する事がで きる。しかし一般的に言って、サーバとクライアントはそれぞれのオペレーティ ングシステムのファイルネームスペースを通してファイルを分有しない。すなわ ち、クライアントのファイルネームスペースはサーバ上のファイルのネームを含 まずまたはマップしない。言い替えれば、２つのファイルネームスペース中のフ ァイル対が同一ファイルに対応する事はない。インターネットおよびＷＷＷに接 続されたクライアント装置とサーバ装置の設定に関して、”Setting up Shop on the Internet，”by Jef Frentzen et al、および関連の論文、Windows Source s, February 1995，pp.42，64-67，70，73-74，77-80，106，108，111，113-114 ，117-120，122，125，128，134-136，138-140 and 143 および How to Set Up and Maintain a Web Site，by Lincoln D．Stein，Addison - Wesley，August 1 995 にさらに詳細に説明されている。 この特願において「ウエブ」とも呼ばれるオンラインサービスはサーバ装置上 に保存された１セットのドキュメント対象および関連情報を含む。ウエブ中のド キュメントはそのウエブに共通な二、三のアクセス制御特性を分有する。ウエブ そのものがＵＲＬを有し、またウエブ中の各ドキュメントがウエブＵＲＬと共に 開始するＵＲＬを有する。本発明の１実施態様におけるウエブ情報の組織を第４ 図に図示する。この実施態様は階層ファイルシステムを使用する。 第４図について述べれば、各ウエブまたはサービスは、このウエブのすべての ドキュメント対象および関連情報の保存されるサーバ上の場所４００を有する。 図示の実施態様において、サーバは階層ファイルシステムを有し、またウエブ位 置はこのファイルシステムにおいて「内容ディレクトリ」と呼ばれるディレクト リである。ウエブに関連するすべてのドキュメントおよび情報はこのディレクト リに基づくファイル階層の中に保存される。 またサーバ上の他の場所（図示されていない）は、ウエブのために使用される ＨＴＴＰ型サーバ、ＨＴＴＰサーバに関連したポート数、およびサーバの構成情 報の位置を保存するために使用される。１つの実施態様において、これらの情報 はファイルシステムの予定義されたサブディレクトリおよびファイルなどとして 、ファイルシステム中のグローバル既知の場所に保存される。 またウエブを構成するＨＴＭＬドキュメント、画像ファイルおよびその他の内 容ファイルがサーバ上の場所４０４の中に個別に保存される。この内容はウエブ ブラウザを使用してウエブ端末ユーザにアクセス可能である。同様に、このよう な内容ファイルはファイルシステム中の他のサブディレクトリ４１４の場所４１ ２に保存される。これは例えば相異なる型の内容ファイルの個別ファイルとして 有効である。 メタ情報または情報に関する情報も保存される。第１にドキュメントメタ情報 、または特定ウエブドキュメント対象に関する情報、例えばドキュメントのタイ ト ル、ドキュメントの作成者、ドキュメントの作成された期日および時間、および ドキュメントが最後に変更された期日および時間がサーバ上の他の場所４０６に 保存される。またドキュメントメタ情報はドキュメントから他のドキュメント対 象へのハイパーテキストリンクのリストを含む事ができる。この実施態様におい ては、ドキュメントを含むディレクトリの別個のサブディレクトリが備えられる 。このサブディレクトリの中に、各内容ファイルのメタ情報を含むファイル４０ ８が対応の内容ファイルのファイルネームを使用して保存される。追加ウエブ内 容のサブディレクトリ、例えばサブディレクトリ４１４の中において、追加サブ ディレクトリ４１６が対応の内容ファイル４１２のメタ情報ファイル４１８を含 む事ができる。 第２に、ウエブメタ情報またはウエブ全体に関する情報、例えばウエブの作成 期日および時間、ウエブを作成するために使用されたサーバ拡張プログラムのバ ージョンおよびＨＴＴＰサーバプログラムのバージョンがサーバ上の場所４１０ に保存される。またウエブメタ情報は、ウエブ中に表われる会社のネームまたは アドレスなど、ウエブ全体に使用される二、三の共通パラメータの値を含む事が できる。またオプションの設定を表示するパラメータ値、例えばこのウエブがケ ース感知性ＵＲＬを使用するかいなかを表示するパラメータ値がウエブメタ情報 の中に保存される。 またウエブロッキングメカニズムに関する情報が構成サブディレクトリ４０２ またはその他公知のウエブ場所、例えば４２８の中に保存される。この情報は、 システムが同時的に複数の作成者のウエブ情報アクセスまたは変更を正確に処理 できるようにロッキングシステムを実現するために使用される。各ウエブサーバ に関するウエブサーバ特殊アクセス制御情報、例えばユーザのリストおよびユー ザのパスワード、ユーザグループの定義、ウエブまたはウエブの特定部分にアク セスする事のできるユーザおよびグループのリストが含まれる事ができる。また このアクセス制御情報はディレクトリ４０２または他の既知の場所に保存する事 ができる。 またウエブは前記以外の情報を含む事ができる。例えばウエブ作成者をウエブ の作成および保持中に案内するため、未完成タスクリスト４２０を使用する事が できる。また与えられたドキュメントがどのドキュメントに依存するかの情報を 与えるため、そのウエブのドキュメント依存データベース４２２を保存する事が できる。このデータベースは、１つのドキュメントの変更が第２ドキュメントま たは第２ドキュメントのメタ情報を更新させる時期を決定するために使用される 。またエンドユーザがウエブブラウザによってアクセス不能の私的内容区域４２ ４を備える事ができる。これは数種のドキュメントによってウエブの中に含まれ るが直接にアクセスすべきでない内容のために使用される。ウエブ中のすべての ドキュメントのテキスト検索に使用するため、ウエブ中に含まれすべてのテキス トドキュメントのテキストインデックス４２６を備える事ができる。本発明のサ ーバ拡張を実現するＣＧＩプログラムおよびスクリプト区域が割当てられなけれ ばならない。同様に、作成者によって作成される特注ＣＧＩプログラムおよびス クリプトの区域を備えなければならない。 第５Ａ図乃至第５Ｅ図は、サーバ装置がSun Solaris 2.4 オペレーティングシ ステムを走らせる Sun SparcStation 20 であり、サーバプログラムが NCSA HT TPサーバ、バージョン１．３Ｒである実施態様においてウエブに関して保存され た情報例を示す。これらの図は特定サブディレクトリ中に発見されるドキュメン トリストを示し、ウエブ例に関する情報を保存するファイルをリストアップする 。またこれらの図は各ファイルを前記のウエブ情報のいずれかのクラスに属する ものとして識別する。この実施例において、ウエブは本発明のクライアント／サ ーバ許可システムによって作成された「コーポレイト・プレゼンス」ウエブであ る。ウエブの場所または内容ディレクトリは"./content/"であって、ここに "."は階層ファイルシステム中の任意開始点を示す。各サービスはこの「内容」 ディレクトリのサブディレクトリとして組織する事ができる。「内容」ディレク トリ中のデフォルト・サービスを第４図および第５Ａ図乃至第５Ｅ図に示す。 サーバ装置上の「コーポレイト・プレゼンス」ウエブの中に保存された一部の ファイルのフォーマットを第６Ａ図乃至第６Ｃ図について説明する。これらのフ ァイルはサーバプログラムおよびサーバ拡張プログラムによって使用されるエッ センス・データ構造を有する。 ドキュメント内容ファイルは、例えばＨＴＭＬ ２．０言語の標準規則に従っ てＨＴＭＬとして保存されている。画像内容ファイルは、ＧＩＦ ８７、ＧＩＦ ８９ＡおよびＪＰＥＧ画像フォーマットを含む標準型画像フォーマットのいずれ かで保存される。第６Ａ図はＨＴＭＬ言語で"content/pr01.htmk" と名付られる ドキュメント内容ファイルの１つのフォーマットを示す。 ドキュメントメタ情報ファイルを第６Ｂ図に示す。一般に、ドキュメントメタ 情報ファイルは複数対のテキストストリングを保存し、ここに各対が１つの属性 のネームのテキストストリングおよび属性値を与えるテキストストリングとを含 む。各対は１行のテキストファイルとして保存され、各行が属性ネームと、次に 分離文字としてのコロン（”：”）と、次に属性値とを含む。第６Ｂ図は"conte nt/metainfo/pr01.htm" と名付られるドキュメントメタ情報ファイルのフォーマ ットを示し、これは第６Ａ図のドキュメント内容に関連するさらに他の情報を保 存する。ドキュメントメタ情報の一例として、"vti_title" と名付られる属性が 値 "SR|Zephyr Press Release 1" を有し、これはこのドキュメントのタイトル が "Zephyr Press Release 1" である事を示す。属性値の最初の記号”|”の前 のオプション文字はこの値のフォーマットに関する追加情報を示す。例えば’Ｓ ’で始まる属性値はテキストストリングを示し、’Ｔ’は時間値を示し、また’ Ｉ’は整数値を示す。 属性 "vti_cachedbasedtm" はいずれかのキャッシュド属性値に対する最後の 変更の期日と時間、この場合には"19 Nov 1995 10:47:2 EST" を与える。属性"v ti_cachedtitle" はドキュメントタイトル、この場合、"Zephyr Press Release 1" を与える。属性"vti_cachedtitledtm" は"vti_cachedtitle" 属性値に対する 最後の変更の期日および時間、この場合、"19 Nov 1995 10:47:50 EST"を与える 。属性 "vti_cachedlinkinfo" はこのドキュメントがリンクしているドキュメン トのリストを与え、この場合、第１リンクは "images/logo.gif′へのリンクで ある。属性 "vti_cachedlinkinfodtm" は "vti_cachedlinkinfo" 値に対する最 後の変更の期日および時間、この場合 "19 Nov 1995 10;47:42 EST" を与える。 属性 vtyi_extenderversion" はサーバ拡張プログラムのバージョンナンバー、 この場合"1.0.3.3"を与える。属性 "vti_timelastmodified" はドキュメントが 最後に変更された時間、この場合 "19 Nov 1995 10:47:33 EST" を与える。属性 "vti_timecreated" はドキュメントが作成された時間、この場合 "19 Nov 1995 10:47:33 EST" を与える。属性 vto_author" はドキュメントを作成した作成者 の名前、この場合 "username" を与える。属性 "vti_modifiedby" はドキュメン トを最後に変更した作成者の名前、この場合 username" を与える。 ウエブメタ情報ファイルを第６Ｃ図に示す。一般に、ウエブメタ情報ファイル は複数対のテキストストリングを記憶し、各対が属性のネームのテキストストリ ングと、属性値を示すテキストストリングとを含む。属性ネーム値対はドキュメ ントメタ情報ファイルの場合のように記憶される。第６Ｃ図は、第６Ａ図の実施 例に対応する ”content′_vti_pvt/service.cnf′と名付られたウエブメタ情 報ファイルのフォーマットを示す。このウエブに対するウエブメタ情報の一例と して、"vti_timecreated" と名付られた属性は値 "TR|19 Nov 1995 10:46:41 ES T"を有し、このウエブが１９９５年１１月１９日の１０：４６ ＡＭ ＥＳＴに 作成された事を示す。 下記において、この実施例のウエブメタ情報と共に記憶された他の属性を示す 。 属性 vti_httpdversion”はウエブサーバプログラムのバージョン、この場合 "NCSA/1.3" を与える。属性 "vti_extenderversion" はサーバ拡張プログラムの バージョン、この場合 "1.0.3.3" を与える。属性 "vti_timecreated"はこのウ エブの作成された日時、この場合 "19 Nov 1995 10:46:41 EST" を与える。属性 "vti_welcomenames" はサーバに対するデフォルト・ウエルカム・ファイルネー ム、この場合 "index.html" を与える。属性 "vti_casesensitiveurls" は、Ｕ ＲＬがこのサーバに対してケース感性であるかいなかを示し、この場合値はイエ スを示す”１”である。属性 "vti_restartmanual" はサーバがその構成ファイ ルを再読できるように、ユーザがウエブの作成後に手動的にサーバを再始動しな ければならないかいなかを示す。この場合、値は”０”であって、手動的再始動 が必要ない事を意味する。属性 "vti_autorecalc"は、ドキュメント対象がサー バに対して保存された後にサーバ拡張プログラムが自動的にドキュメント依存関 係を再計算しなければならないかいなかを示す。この場合、値”１”は自動的再 計算が可能化されている事を示す。属性 vti_longfilenames"はサーバオペレー ティングシステムが長いファイルネームを使用するかいなかを示し、この場合、 値は”１”であって、長いファイルネームが使用される事を意味する。属性 "vt i_htmlextensions" は、ドキュメントファイルがＨＴＭＬである事を示すファイ ル拡張リストを示し、この場合、リストは３拡張、".html"、".htm" および ".h tm" から成る。属性 "vti_textextensions" はドキュメントファイルがテキスト である事を示すファイル拡張リストを示し、この場合リストは拡張 ".txt"から 成る。属性 "companyemail" は会社電子メールのアドレスのマクロ変数、この場 合、"info＠zephyr.com" を与える。属性 "companylongname" は会社ネームの長 い形のマクロ変数、この場合、"ZephyrAutowerks" を与える。属性 "companysho rtname" は会社ネームの短い形のマクロ変数、この場合、"Zephyr" を与え る。属性 "companyphone" は会社電話番号のマクロ変数、この場合、"517-890-1 000" を与える。属性 "companywebmaster" はウエブスター会社の電子メールア ドレス、この場合 "Webmaster＠zephyr.com" を与える。属性 "companyaddress" は会社アドレスのマクロ変数、この場合 "123 Pisuton Drive，Midland，M1 48 640" を与える。属性 "companyfax" は会社ファックス番号、この場合 "517-890 -1001" を与える。前述の構造であるので、本発明はクライアントシステムによ り、サーバプログラムとの通信によってウエブのドキュメント対象および関連の メタ情報に対して遠隔操作する事ができる。この通信と許可操作例の性能とを第 ７図および第８図について説明する。 クライアント装置上のクライアントアプリケーションモデル８１とサーバ装置 上のサーバプログラム８６との間の通信は、これら両方の装置がそれぞれのイン ターネットサービスプロバダまたは同等の通信を生じる他のシステムに接続され た時に生じる事ができる。例えば、クライアント装置とサーバ装置は同一装置と する事ができ、または相異なる装置とする事ができ、いずれの場合にもクライア ント通信インタフェースモジュールとサーバプログラムとの間の通信パスを生じ るためＴＣＰ／ＩＰスタックプログラムが使用される。サーバ装置とクライアン ト装置との間の通信はクライアントがサーバに対してＨＴＴＰ要求１０８を送り 、次にサーバがクライアントに対してＨＴＴＰ応答メッセージ１１０をもって応 答する形をとる。これを実施するため、クライアント通信インタフェースモジュ ール８２がサーバプログラム８６に対してＴＣＰ／ＩＰ接続を設定し、この接続 を通してＨＴＴＰ要求メッセージ１０８を送る。サーバプログラム８６がＨＴＴ Ｐ要求メッセージ１０８を受け、指示された処理を実施し、同一接続を通してＨ ＴＴＰ応答メッセージ１１０をもって応答する。 この実施態様においては、特定のＨＴＴＰ要求メッセージ（ＰＯＳＴメッセー ジなど）がサーバプログラム８６によって受けられると、サーバプログラムはサ ーバ拡張プログラム８８を例えばＣ++プログラミング言語で実行する。ＦＴＰな どの他の言語も使用できる事を了解されたい。このような検索と記憶のために相 異なるプロトコールと相異なるメッセージとを使用する事ができよう。例えば検 索のためにＦＴＰを使用し記憶のためにＨＴＴＰを使用し、またはその逆とする 事ができよう。一般的に言って、本発明のこの実施態様においては、ドキュメン トとスクリプトの両方の検索と記憶を処理するため、同一型のメッセージが使用 される。本発明は特定のメッセージ型に限定されない。サーバ拡張プログラムは 、サーバ装置のサービスデータ区域９０、１００において対象の検索記憶要求を 処理する。一般にこれらのサービスデータ区域の中に記憶される２つの型の対象 がある。すなわちＨＴＭＬ言語のドキュメント９２、１０２およびＨＴＭＬドキ ュメントを生成するスクリプトプログラム９４、１０４。 本発明のこの実施例において、クライアントからサーバへのすべての通信はク ライアント通信インタフェースモジュールＡＰＩ ８２の各入口点の１つを通し て実施される。下記の表Ｉは許可ツールにおいて最も有用なＡＰＩにおける手順 リストを示す。 クライアント通信インタフェースモジュールは、クライアント通信ＡＰＩを集 合的に構成する各手順を実施する。各手順はクライアントとサーバの間の１つま たは複数のトランザクションを開始し、この場合、トランザクションはクライア ントからサーバへのＨＴＴＰ要求と、これに続くサーバからクライアントに返送 されるＨＴＴＰ応答メッセージとから成る。 与えられたＡＰＩ呼出しに対してトランザクションを開始する前に、クライア ント通信インタフェースモジュール８２は、このＡＰＩ呼出し対するすべてのト ランザクションの完了が手順に対する呼出しをトリガするような手順を設定する 。この手順はＡＰＩ呼出しの完了に関連する任意のタスクを実施する。通常これ らのタスクの１つは、ユーザにグラフィカルユーザインタフェースを通してユー ザ要求が処理された事を指示するにある。 各クライアント／サーバトランザクションは同一の一般的モデルに従う。下記 の表ＩＩは先行ＡＰＩ呼出しによって使用されるトランザクション型のリストで ある。また各トランザクションに対して、クライアント通信インタフェース８２ は第７図に図示のように後続のタスクを実施する。 まず、段階５００においてクライアント通信インタフェースモジュール８２が クライアントとサーバとの間のＴＣＰ／ＩＰ接続を開始する。ＨＴＴＰプロトコ ールのメッセージがこの通信を介して送信され受信される。本発明の好ましい実 施態様においては、各トランザクションに対して別個のＴＣＰ／ＩＰ接続が設定 される。次に段階５０２において、クライアント通信インタフェース８２がＨＴ ＴＰプロトコールＰＯＳＴ要求メッセージを構成し、この場合、メッセージのデ ータ内容はトランザクションの型を識別する情報と、このトランザクション型に 特有のパラメータ値またはデータを搬送する。メッセージフォーマットはＨＴＴ Ｐメッセージであって、この場合、トランザクションに必要なデータはキー、値 対を使用して符号化されたＦｏｒｍｓ ＵＲＬである。キー、値対に続いてＰＵ Ｔ ＤＯＣＵＭＥＮＴトランザクションのデータ内容がある。第９図はＨＴＴＰ ＰＯＳＴ要求、この場合、ＰＵＴ ＤＯＣＵＭＥＮＴトランザクションに対す るＰＯＳＴ要求のフォーマットの一例を示す。このメッセージは８行のヘッダ行 と、これに続くブランク行と、ＵＲＬフォームで符号化されたパラメータ値と、 ブランク行と、ＨＴＭＬドキュメント内容とから成る。オプションとして、ＨＴ ＴＰプロトコールＰＯＳＴメッセージのデータ内容を暗号化する事ができる。 ＰＯＳＴメッセージと共に転送されたＵＲＬは要求を実施するためにサーバ装 置上に呼出されるプログラムを識別する。次にクライアント通信インタフェース ８２が１つのメカニズムを設定し（段階５０４）、このメカニズムにより、ＨＴ ＴＰ応答メッセージの到着が、クライアントシステムにおける対応のトランザク ションの完了を処理する手順の呼出しをトリガする。 これらの予備的設定タスクの完了後に、ＨＴＴＰプロトコールのＰＯＳＴ要求 メッセージを送る事により（段階５０６）サーバとのトランザクションが開始さ れる。クライアント通信インタフェースモジュールが対応のＨＴＴＰプロトコー ル応答メッセージを受けるまでは、クライアントコンピュータはトランザクショ ンの結果には依存しない他のタスクを実施し続ける。場合によってクライアント は段階５０８においてサーバからＨＴＴＰ応答メッセージを受ける。このＨＴＴ Ｐ応答メッセージはクライアントの要求に対応する状態情報またはデータを含む 事ができ、またはクライアント要求が満たされなかった場合にエラー表示を含む 事ができる。第１０図はＨＴＴＰ応答メッセージ、この場合にはＰＵＴ＿ＤＯＣ ＵＭＥＮＴトランザクションのＰＯＳＴ要求に対する応答のフォーマット例であ る。このメッセージは４行のＨＴＴＰヘッダ行、次のブランク行、次のドキュメ ントに関する返送された状態情報およびメタ情報から成る。ドキュメントメタ情 報はＨＴＭＬフォーマットの属性ネーム値対から成る。応答が受信された後に、 クライアント通信インタフェースモジュールがこのトランザクションのＴＣＰ／ ＩＰ接続の終了を要求し、次に対応のトランザクションの完了のために設定され たメカニズムを呼出す（段階５１０）。 もしトランザクションが許可クライアントからの確認を要求するならば、クラ イアントがユーザネームとパスワードを送る事によってトランザクションを確認 しなければならない事を指示するエラーメッセージをＨＴＴＰプロトコール応答 メッセージが含む事以外は、トランザクションタスクは前記と同様に実施される 。この確認プロセスはＨＴＴＰプロトコールの一部を成す。クライアントプログ ラムはユーザからユーザネームとパスワードとを要求し、前記のタスクが他のＴ ＣＰ／ＩＰ接続によって繰り返され、この場合、ＨＴＴＰ ＰＯＳＴメッセージ はオリジナルパラメータのほかに、ユーザネームとパスワードとを搬送する。 サーバ装置の動作を第８図について説明する。公知の技術により、ＨＴＴＰサ ーバプログラムはクライアント装置からＴＣＰ／ＩＰ接続試みを聞き取る（段階 ５１２）。接続の試みに対応して、サーバプログラムは接続を設定するために必 要なタスクを実行する。この接続を通してＨＴＴＰプロトコールＰＯＳＴメッセ ージが受信された時（段階５１４）、段階５１６においてサーバプログラムが要 求されたプログラムを呼出し、ＣＧＩ標準型メカニズムによってパラメータ情報 を通す。本発明の方法においては、サーバによって呼出されるプログラムは「サ ーバ拡張」プログラム８８である。サーバ拡張プログラムは１つまたは複数のプ ログラムとして実施される事を了解されたい。 サーバ拡張プログラムが呼出された時、このプログラムはＣＧＩプロトコール に従って通されたＨＴＴＰプロトコール要求メッセージのパラメータおよびデー タ内容を読取る。サーバ拡張プログラムはメッセージを解析し、このトランザク ションによって指示されたタスクを実行する（段階５１８）。 タスクがうまく実行されると、サーバ拡張プログラムは、トランザクションが 成功的に実行された事を表示するＨＴＭＬドキュメントフォーマットの状態メッ セージを構成する（段階５２０）。またメッセージは、このトランザクションの ためにクライアントに返送されなければならない関連のデータを含む。トランザ クションタスクがうまく実行されなかった場合、サーバ拡張プログラムはＨＴＭ Ｌフォーマットのエラーメッセージを構成する（段階５２０）。いずれの場合に も、得られたメッセージはＣＧＩ標準型技術によってサーバに返送され、サーバ 拡張プログラムが終了する。 サーバプログラムがサーバ拡張プログラムから状態メッセージまたはエラーメ ッセージを受けた時、サーバプログラムは段階５２２において、サーバ拡張プロ グラムによって生産されたＨＴＭＬドキュメントを含むＨＴＴＰプロトコール応 答メッセージを構成し、これをＴＣＰ／ＩＰ接続を通してクライアント通信イン タフェースモジュールに送信する。次にサーバは段階５２４においてＴＣＰ／Ｉ Ｐ接続の終了を要求する。 前記のメカニズムにおいては、二、三のバリエーションが可能である。１つの バリエーションにおいては、ＴＣＰ／ＩＰ接続が複数のトランザクションに開放 されて、通信オーバヘッドを低減させ性能を増進する。他のバリエーションにお いては、サーバ拡張プロセスの一回の呼出しが複数のトランザクションを処理す る。 クライアント通信ＡＰＩの各手順は前記の一般的説明に従う。二、三のトラン ザクション型、すなわち トランザクション型によって実行されるサーバ拡張タスクについて下記に説明す る。 クライアント許可ツールが、サーバ装置からドキュメントと対応のドキュメン トメータ情報を検索するために、ＧｅｔＤｏｃｕｍｅｎｔ ＡＰＩ手順を呼出す 。この手順がサーバからドキュメントと対応のメタ情報を検索するためにＧＥＴ ＤＯＣＵＭＥＮＴトランザクションを開始する。 サーバ上のサーバ拡張プログラムがＧＥＴ ＤＯＣＵＭＥＮＴトランザクショ ンを受ける時、下記の段階が実施される。まず指示されたドキュメントがサーバ 装置上で検索される。次にこのドキュメントのドキュメントメタ情報が検索され る。 検索されたドキュメントおよびドキュメントメタ情報に関する状態メッセージ またはエラーメッセージを含むＨＴＭＬドキュメントが構成される。このドキュ メントがサーバプログラムに対する応答として返送され、このサーバプログラム はこのドキュメントを前述のようにしてクライアント通信インタフェースモジュ ールに転送する。 クライアントアプリケーションプログラムは変更ドキュメントをサーバ装置に 対して保存するためにＰｕｔＤｏｃｕｍｅｎｔ ＡＰＩ手順を呼出す。この手順 は変更ドキュメントをサーバに保存するためにＧＥＴ ＤＯＣＵＭＥＮＴトラン ザクションを開始する。トランザクションのために生成された要求メッセージは サーバ上の場所（ＵＲＬ）の表示と変更ドキュメントの内容とを含む。 サーバ上のサーバ拡張プログラムがＧＥＴ ＤＯＣＵＭＥＮＴトランザクショ ンを受けた時、プログラムは下記のタスクを実行する。まず、トランザクション 要求がパラメータ値とデータ内容との中に解析される。データ内容がサーバ装置 上の指示されたドキュメント場所に記憶される。トランザクションと共に伝送さ れたデータはＨＴＭＬドキュメントの新内容であり、あるいは、画像、スクリプ ト、ビデオまたはオーディオなどの他の型のドキュメント対象の場合、このドキ ュメント対象の新内容である。次に保存されたドキュメントに関連するドキュメ ントメタ情報ファイルが配置される。１つの実施態様において、ドキュメントメ タ情報はドキュメントディレクトリの"metainfo" サブディレクトリの中に、保 存されたドキュメントと同一ネームで記憶される。 ドキュメントメタ情報は下記のようにして更新される。"vti_timelastmodifie d" 属性の値が現在時間に変更されて、ドキュメントが最後に変更された時間を 表示する。"vti_modifiedby" 属性の値が、ドキュメントをサーバ装置に保存す る事を要求した作成者のユーザネームに変更される。"vti_cachedlinkinfo" 属 性の値は、現在ドキュメントまたは現在ドキュメントに含まれまたは現在ドキュ メントにリンクされた画像の現在リストとなるように変更され、このリストがド キュメントの新バージョンにおけるリンクの追加または削除を反映するようにす る。"vti_cachedlinkinfo" 属性の値が最後に更新された時間を表示するために 、"vti_cachedlinkinfodtm" 属性の値が現在時間に変更される。"vti_title" お よび "vti_cachedtitle"属性の値が現行ドキュメントタイトルに変更される。"v ti_cachedtitledtm"属性が現在時間に変更されて、"vti_cachedtitle"属性の値 が最後に更新された時間を表示する。"vti_cachedbasedtm" 属性が現在日時に 変更され、この属性値のいずれかに対する最も新しい変更日時を示す。"vti_ext enderversion" 属性がサーバ拡張プログラムのバージョン数に変更される。"vti _timecreated" 属性および"vti_author" 属性は、ドキュメントの生成に関する 情報を与えるので変更されない。新属性キー値対はトランザクションから受けた 新属性情報に対してドキュメントメタ情報の中に追加されまたは更新される。 メタ情報が更新された後に、ウエブ中のすべてのドキュメントのドキュメント 依存性データベースとテキストインデックスとが保存されたドキュメントの変化 を反映するように更新される。また未完成タスクのタスクリストも、保存された ドキュメントに対する変化の結果として生成された新タスクを反映するように更 新される。次に、状態メッセージまたはドキュメントメタ情報またはエラーメッ セージを含むＨＴＭＬドキュメントが構成されて、サーバプログラムに対する応 答として返送される。サーバプログラムは前述のようにクライアント通信インタ フェースモジュールに対する応答を送る。 クライアント許可ツールがサーバ装置の上に新規ウエブを生成するために Cre ateService API を呼出す。必要ならば、この手順は、クライアント作成者プロ グラムとサーバ拡張プログラムとの互換性をチェックするために、server_versi on トランザクションを開始して、サーバ拡張プログラムのバージョン数を検索 する。次にこの手順はサーバに対して新ウエブを生成するため CREATE_SERVICE トランザクションを開始する。 サーバ上のサーバ拡張プログラムが CREATE_SERVICE トランザクションを受け た時、プログラムは下記のタスクを実施する。新ウエブの内容ディレクトリと、 内容ディレクトリ中のドキュメントに関連するドキュメントメタ情報ファイルを 記憶するための内容ディレクトリの "metainfo" サブディレクトリとを共に作成 する。新ウエブのウエブメタ情報を記憶するファイルを生成し、このファイル中 の "vti_timecreated" 属性値を現在時間に設定して、ウエブの生成された時間 を表示する。"vti_extenderversion" 属性をサーバ拡張プログラムのバージョン 数に設定する。"companyphone" などの会社情報のマクロ変数定義を与える属性 を、作成クライアントによって図面ユーザインタフェースを通して特定された初 期値に設定する。他の属性を、与えられたサーバ装置とＨＴＴＰサーバプログラ ムに適した初期値に設定する。これらの属性の意味は前述した。また新規ウエブ に関するウエブサーバ固有アクセス制御情報を、ウエブサーバの型に固有のサー バ拡張プログラムの内部ルーチンを介して作成する。サーバアクセス制御情報が 各サーバについて相異なる仕方で記憶されているのであるから、これらの内部ル ーチンはサーバ固有である。 次にこのウエブに関連する新規の実行可能ディレクトリのウエブサーバ構成情 報におけるマッピングを作成する。これはウエブサーバの型に特有のサーバ拡張 プログラムの内部ルーチンを通して実施される。なぜかならば、サーバ構成情報 は相異なるサーバの中に相異なる仕方で記憶されているからである。これらのマ ッピングによって、サーバは特定セットのＵＲＬ（このウエブのＵＲＬの共通プ レフィックスを有するＵＲＬセット）をサーバ装置上のウエブ内容ファイル（ウ エブ内容ディレクトリ）の物理的場所にマップするように指向される。例えば、 ＮＣＳＡサーバ上にウエブを生成する際に、サーバ拡張はＮＣＳＡ固有内部ルー チンを使用して、下記の表ＩＩＩに列挙された行をＮＣＳＡサーバ構成ファイル "srm.conf" に追加する。これらの行は、サーバ装置上の４ディレクトリが共通 ＣＧＩプログラムまたはスクリプトとしてマークされる事を示し、さらにこれら のプログラムまたはスクリプトにアクセスする際に使用されるＵＲＬを定義する 。 次に、ウエブのプライベート内容の最初から空の区域、新ウエブの最初から空 のテキストインデックス、新ウエブの最初から空のドキュメント依存データベー スおよび新ウエブ用の未完成タスクの最初から空のタスクリストがすべて作成さ れる。次にこのサーバに関連するすべてのウエブのリストを記憶するファイルに 対して新ウエブのネームを与える。 本発明のサーバ拡張を実現するＣＧＩプログラムおよびスクリプトの区域が作 成され、この区域の中に必要なＣＧＩプログラムおよびスクリプトがコピーされ る。同様に作成者によって作成される特注ＣＧＩプログラムおよびスクリプトの 区域が作成される． 次にこの操作を完了するため、ウエブ中の各ファイルへのファイルシステムア クセス許可が設定される。次に操作の完了時に、新規に作成されるウエブのウエ ブメタ情報を含む状態メッセージまたはエラーメッセージを含むＨＴＭＬドキュ メントが構成される。このドキュメントがサーバプログラムに対する応答として 返送され、サーバプログラムが前述のようにこのプログラムをクライアント通信 インタフェースモジュールに送る。 クライアント許可ツールは、サーバ装置上のすべてのウエブのリストを検索す るため、ListServices API 手順を呼出す。必要ならば、この手順は、クライア ント許可プログラムとサーバ拡張プログラムとの互換性をチェックする目的で、 サーバ拡張プログラムのバージョン数を検索するために SERVER_VERSION トラン ザクションを開始する。次にこの手順はサーバ装置上のすべてのウエブのリスト を検索するために LIST_SERVICES トランザクションを開始する。 サーバ上のサーバ拡張プログラムが LIST_SERVICES トランザクションを受け た時、このプログラムは次のタスクを実施する。このサーバに関連するすべての ウエブのリストを記憶するファイルを読出してリストを得る。次にウエブリスト を有する状態メッセージまたはエラーメッセージを含むＨＴＭＬドキュメントが 構成される。各ウエブネームについてリスト項目としてＨＴＭＬリストフォーマ ットを使用する事ができる。構成されたＨＴＭＬドキュメントがサーバプログラ ムに対する応答として返送され、このサーバプログラムが前述のようにこのドキ ュメントをクライアント通信インタフェースモジュールに送る。 クライアント許可ツールは ListDocuments API 手順を読出して、サーバ装置 上の与えられたウエブ中のすべてのドキュメントのリストを検索しまた各ドキュ メントについてそのドキュメントと他のドキュメントとのリンクリストを検索す る。この手順は LIST_DOCUMENTS トランザクションを開始して、サーバ装置上の 与えられたウエブ中のすべてのドキュメントのリストを検索しまた各ドキュメン トについてこのドキュメントから他のドキュメントへのリンクリストを検索する 。 サーバ上のサーバ拡張プログラムが LIST_DOCUMENTS トランザクションを受け た時、プログラムは下記のタスクを実行する。ウエブの内容ディレクトリから始 めて、再帰的ツリー・トラバーサル・アルゴリズムを使用してこのウエブのファ イル・ハイラーキ中の各ドキュメントを識別する。これらのドキュメントはＨＴ ＭＬドキュメント、テキストドキュメントまたは画像とする事ができる。画像な どの非ＨＴＭＬドキュメントについては、このドキュメントのネームを含むドキ ュメント記録をフォーマット化する。 識別された各ドキュメントについて、下記段階が実施される。第１に、前述の ようにこのドキュメントに関連したドキュメントメタ情報ファイルを位置づける 。このドキュメントと他のドキュメントとのリンクリストを得るため、このファ イルを読出す。属性 "vti_cachedlinkinfo" を使用してリンクリストを得る。こ のリンクリストが得られずまたはアウト・オブ・デートである場合、ＨＴＭＬド キュメントを解析する事によりリンクリストを計算する事ができる。次にこのド キュメントのネームおよび含まれたドキュメントまたは他のドキュメントとのリ ンクリストを含むドキュメント記録がフォーマット化される。 次にすべての状態記録と共に状態メッセージを含みまたはエラーメッセージを 含むＨＴＭＬドキュメントを構成する。このドキュメントがサーバプログラムに 対する応答として返送され、サーバプログラムはこれを前述のようにクライアン ト通信インタフェースモジュールに送る。 サーバ装置上に記憶されたウエブに関するメタ情報を変更するため、クライア ント許可ツールが SetServie Metainfo API 手順を呼出す。この手順は、サーバ 装置上に記憶されたウエブに関するメタ情報を変更するため、SET_SERVICE_META INFO トランザクションを開始する。 このようなトランザクション要求に対応して、サーバ拡張プログラムはこのウ エブに関連するウエブメタ情報ファイルを位置づける。１つの実施態様において 、ウエブメタ情報はウエブ内容ディレクトリのプライベート構成サブディレクト リの中の "service.cnf" ファイルの中に記憶される。ウエブメタ情報ファイル の内容が、SET_SERVICE_METAINFO トランザクション要求の中に含まれる新属性 キー値対を反映するように変更される。ウエブメタ情報を含む状態メッセージま たはエラーメッセージを含むＨＴＭＬドキュメントが構成される。このドキュメ ントがサーバプログラムに対する応答として返送され、サーバプログラムがこれ を前述のようにクライアント通信インタフェースモジュールに送る。 クライアント許可ツールは、サーバ装置中に記憶されたドキュメントに関する メタ情報を変更するため、SetDocument Metainfo API を呼出す。この手順は、 サーバ装置上に記憶されたドキュメントに関するメタ情報を変更するようにSET_ SERVICE_METAINFO トランザクションを開始する。 このようなトランザクション要求に応答して、サーバ拡張プログラムは前述の ように保存されるドキュメントに関連するドキュメントメタ情報を位置づける。 ドキュメントメタ情報ファイルの内容が、SET_SERVICE_METAINFO トランザクシ ョン要求の中に含まれる新属性キー値対を反映するように変更される。ウエブメ タ情報を含む状態メッセージまたはエラーメッセージを含むＨＴＭＬドキュメン トが構成される。このドキュメントがサーバプログラムに対する応答として返送 され、サーバプログラムがこれを前述のようにクライアント通信インタフェース モジュールに送る。 クライアント許可ツールによって成される数回の呼出し対応して、クライアン ト通信インタフェースモジュールは、サーバ装置上において通信するサーバプロ グラムのバージョンを識別するため、SERVER_VERSION トランザクションを開始 する。このようなトランザクション要求に対応して、サーバ拡張は第６Ｃ図に図 示のようなサーババージョン情報を位置づける。次にサーババージョン情報を有 する状態メッセージまたはエラーメッセージを含むＨＴＭＬメッセージが構成さ れる。このドキュメントがサーバプログラムに対する応答として返送され、サー バプログラムがこれを前述のようにしてクライアント通信インタフェースモジュ ールに送る。 オンラインサービスを許可し、作成し、保持するため、これらの機能およびそ の他の機能を備える事ができる。前記の説明はクライアント／サーバ許可環境に おいて有益と思われる操作例を示したものであって、他の操作および変形も可能 である事を了解されたい。 本発明の利点の１つは、ウエブのクライアントサーバ許可操作を特定のサーバ 装置のハードウェアまたはオペレーティングシステムソフトウェアとは独立に成 しまたＨＴＴＰサーバプログラムの実施とは独立に成す事にある。サーバプラッ トフォームおよびサーバプログラムに対するこのような独立性は主として下記の ４技術を使用する事によって達成される。第１の技術は、数種の相異なるプラッ トフォーム上にコンパイルする事のできる移植性ソフトウェアを書くために標準 型技術を使用できる事。第２に、先行技術の標準型ＴＣＰ／ＩＰプロトコール接 続を通して通信プロトコールとして標準型ＨＴＴＰプロトコールを使用する事に よりプラットフォームおよびサーバの独立通信が達成される。さらにＨＴＴＰサ ーバプログラムからサーバ拡張を呼出す手段としてまたサーバからサーバ拡張に パラメータ情報を通すための手段としてＣＧＩプロトコールを使用するので、追 加的サーバプログラム独立性が得られる。最後にＨＴＴＰプロトコールメッセー ジによって搬送されるデータ内容がプラットフォームまたはサーバ依存性情報を まったく含んでいない。従って、このシステムはサーバがＣＧＩスタンダードを 支援する限り、特注変更なしで通常のＨＴＴＰサーバプログラムによって実施し 使用する事ができる。 このシステムの他の利点は、クライアント許可ツールがサーバのネームスペー スをそれ自体のファイルネームスペースにマップする必要のない事である。この 配列は、多数のサーバ上の多数のオンラインサービスの多数作成者の存在する可 能性のあるインターネットなどの大型ネットワークにおいて特に有利である。こ の環境において、ドキュメントの遠隔作成操作が容易に成され、ネットワークフ ァイルシステムなどの複雑なファイルシステムの必要を除く。 このシステムの他の利点は、サーバ上にファイルを記憶する操作が、ウエブブ ラウザの使用に対して透明となる仕方で可能となる事にある。メッセージ処理を 制御するためにサーバ拡張プログラムを使用する事によりサーバを変更する必要 がなくなる。サーバは単にサーバ拡張プログラムを認識するように構成される。 あるいは、サーバ拡張プログラムの機能はウエブサーバそのものの中に埋込まれ てＣＧＩスクリプトを備える必要がない。 本発明は前記の説明のみに限定されるものでなく、その主旨の範囲内において 任意に変更実施できる。例えば、インターネットまたはワールドワイド・ウエブ 、あるいはインターナル・コーポレイト・ウエブなどのプライベートウエブ、あ るいはＨＴＴＰ通信プロトコールの使用に限定されない。例えば、ファイル伝送 プロトコール（ＦＴＰ）の中に「ｇｅｔ」および「ｐｕｔ」を使用してこのＦＴ Ｐを使用する事ができよう。ＴＣＰ／ＩＰ接続を通して通信されるメッセージを 使用する他のプロトコールも使用可能である。これらのプロトコールの混合を使 用して検索機能または記憶機能を実施する事ができる。また遠隔記憶機能のみが 使用されるようにサービス作成者がオンラインサービスのドキュメント対象の局 所コピーを保持する事も可能である。さらに、クライアントとサーバとの間のＴ ＣＰ／ＩＰ接続を通してプロトコールを使用してクライアントプログラムがサー バ上のドキュメントとプログラムを変更し記憶するシステムも本発明の主旨の範 囲内にある。クライアントとサーバはインターネットによって、またはプライベ ート局所または広域ネットワークによって、または同一装置上で接続される。ク ライアント許可ツールは、専用チャンネルまたはリンクを使用するなどしてサー バのみと通信できるように構成する事ができる。メッセージの処理はサーバに加 えられたサーバ拡張プログラムによって実施される必要はなく、サーバに対する 変更によっても実施する事ができる。これらの実施例およびその他の実施例は本 発明の主旨の範囲内にあり、下記のクレームによって定義される。

───────────────────────────────────────────────────── フロントページの続き (51)Int.Cl.⁶ 識別記号 ＦＩ Ｇ０６Ｆ 15/40 ３１０Ｃ (81)指定国 ＥＰ(ＡＴ，ＢＥ，ＣＨ，ＤＥ， ＤＫ，ＥＳ，ＦＩ，ＦＲ，ＧＢ，ＧＲ，ＩＥ，ＩＴ，Ｌ Ｕ，ＭＣ，ＮＬ，ＰＴ，ＳＥ)，ＪＰ (72)発明者 フォーガード，ランディー ジェー. アメリカ合衆国マサチューセッツ州、レキ シントン、フォットラー、アベニュー、22 (72)発明者 シユーラート，アンドリュ ジェー. アメリカ合衆国マサチューセッツ州、ケン ブリッジ、オールストン、ストリート、 267 (72)発明者 ステファニキ，テッド アメリカ合衆国マサチューセッツ州、ハー バード、リトルトン、カウンティー、ロー ド、283 (72)発明者 マウセリー，ロバート ジェー. アメリカ合衆国マサチューセッツ州、ウォ タータウン、ベルモント、ストリート、ナ ンバー31、550 【要約の続き】 に通信する事ができる。これらの装置は相異なるファイ ルネームスペースを有し、クライアントによって使用さ れるＩＤとサーバ上で使用されるＩＤとのマッピングを 保持し実行する事をサーバに要求する。サーバはＨＴＴ Ｐメッセージを処理するためのサーバプログラムと、許 可操作を処理するためのサーバ拡張プログラムとを有す る。このサーバ拡張プログラムは共通ゲートウエーイン タフェースを通して呼出される。実行される許可操作 は、サーバ上のドキュメントおよびスクリプトなどの情 報およびサービス、ドキュメントおよびスクリプトに関 するメタ情報の記憶、作成または変更を含む事ができ る。またサービスおよびドキュメントのリスト処理を実 行する操作も可能である。

Claims (1)

1. 【特許請求の範囲】 １． クライアント装置を使用してサーバ装置上のオンラインサービスを許可 するためのクライアント／サーバシステムにおいて、 前記クライアント装置はオンラインサービスを含む情報に対して許可操作を実 行する許可ツールを有し、前記許可ツールは、 サーバ装置上の情報を許可するためサーバ装置上の情報に対して実行され るべき許可操作の要求を生成する手段と、 前記要求をサーバに転送される少なくとも１つのメッセージに翻訳してこ の少なくとも１つのメッセージをサーバに伝送するための手段とを含み、また 前記サーバ装置は前記許可ツールを用いて許可された情報を記憶し、 前記クライアントからの少なくとも１つのメッセージを受け、前記サーバ 装置上の情報を許可するように前記の受信された少なくとも１つのメッセージ中 において識別された許可操作を実行する手段を含む事を特徴とするクライアント ／サーバシステム。 ２． 前記クライアント装置の前記翻訳伝送手段は、 クライアント装置とサーバ装置との間にＴＣＰ／ＩＰ接続を開始する手段 と、 トランザクションの型と、前記トランザクションのパラメータ値と、前記 トランザクションを実施するためにサーバ上に呼出されるプロセスとを識別する 情報を含むデータ内容のデータを有するＨＴＴＰ要求メッセージを構成する手段 と、 前記ＨＴＴＰ要求メッセージをサーバに送る手段とを含む事を特徴とする 請求項１に記載のクライアント／サーバコンピュータシステム。 ３． 前記クライアント装置は、さらに 許可操作の実施によって生成されたデータを搬送するデータ内容を有する サーバ装置からのＨＴＴＰ応答の受信に応答して、ユーザに対して前記トランザ クションに関する情報を表示するように作動する手段を含む事を特徴とする請求 項２に記載のクライアント／サーバコンピュータシステム。 ４． 前記ＨＴＴＰ応答メッセージはマークアップ言語のデータ内容を含み、 また前記表示手段はサーバから要求された情報を得るようにデータ内容を解析す る手段を含む事を特徴とする請求項３に記載のクライアント／サーバコンピュー タシステム。 ５． 前記許可操作はサーバ上のデータファイルの内容を変更する操作を含む 事を特徴とする請求項１乃至４のいずれかに記載のクライアント／サーバコンピ ュータシステム。 ６． 前記許可操作はサーバ上のオンラインサービスに関するメタ情報を操作 する操作を含む事を特徴とする請求項１乃至５のいずれかに記載のクライアント ／サーバコンピュータシステム。 ７． 許可操作はサーバ上にドキュメント対象を生成する操作を含む事を特徴 とする請求項１乃至６のいずれかに記載のクライアント／サーバコンピュータシ ステム。 ８． クライアントコンピュータはサーバ上にドキュメント対象を保存する操 作を含めてオンラインサービスを許可する基本的操作の集合を有し、前記の各基 本的操作は前記の許可操作要求生成手段によって個別に選択可能である事を特徴 とする請求項１乃至７のいずれかに記載のクライアント／サーバコンピュータシ ステム。 ９． サーバコンピュータ上に、 ＨＴＴＰ要求メッセージを受ける手段と、 サーバコンピュータ上の情報に対して実施される許可操作の要求を検出す る手段と、 前記検出手段による検出に応答して、実施されるべき許可操作を共通ゲー トウエーインタフェースを介して呼出すように作動する手段と、 要求された許可操作の実施の結果としてＨＴＭＬドキュメントを受ける手 段と、 要求された許可操作の結果としてクライアントコンピュータに前記ＨＴＭ Ｌドキュメントを伝送する手段とを含む事を特徴とする請求項２乃至４のいずれ かに記載のクライアント／サーバコンピュータシステム。 １０． クライアント装置は、 サーバから応答メッセージを受ける手段と、 前記応答メッセージを使用してサーバによる許可操作の実施に関する情報 を表示する手段とを有する事を特徴とする請求項１乃至９のいずれかに記載のク ライアント／サーバコンピュータシステム。 １１． クライアントコンピュータ上に、さらに サーバ装置からのＨＴＴＰ応答メッセージの到着を検出するクライアント 装置上のプロセスを実行する手段と、 前記プロセスの実行によるサーバ装置からのＨＴＴＰ応答メッセージの到 着の検出に応答して、クライアント装置上の許可操作を終了するように作動する 手段とを含む事を特徴とする請求項２乃至４または９のいずれかに記載のクライ アント／サーバコンピュータシステム。 １２． クライアントコンピュータ上に、さらに サーバ装置からの応答メッセージの到着を検出する第１プロセスを実行し 、サーバ装置からの応答メッセージの到着の検出に対応してクライアント装置上 の対応の許可操作を終了させる第２プロセスを実行するための手段を含む事を特 徴とする請求項１乃至１１のいずれかに記載のクライアント／サーバコンピュー タ システム。 １３． クライアント装置上に、さらに サーバ装置にメッセージを送った後に、またサーバ装置からの応答メッセ ージの到着前に、サーバ装置上で実行された許可操作の結果に依存しない操作を 実行する手段を含む事を特徴とする請求項１２に記載のクライアント／サーバコ ンピュータシステム。 １４． クライアント装置のオペレーティングシステムは、サーバ装置上のフ ァイルネームを含まずまたはマップしないファイルネームスペースを有する事を 特徴とする請求項１乃至１３のいずれかに記載のクライアント／サーバコンピュ ータシステム。 １５． 前記の操作実行手段は、共通ゲートウエーインタフェースを介してサ ーバコンピュータ上でサーバプログラムによって実行されるサーバ拡張プログラ ムを含む事を特徴とする請求項１乃至１４のいずれかに記載のクライアント／サ ーバコンピュータシステム。 １６． サーバ装置はＨＴＴＰを介してクライアントと通信する手段と許可操 作を実行する手段とを含む事を特徴とする請求項１乃至１５のいずれかに記載の クライアント／サーバコンピュータシステム。