JP2006031683A - 機能拡張装置および機能拡張方法ならびに機能拡張プログラムを記録した記録媒体 - Google Patents

Abstract

【課題】 ＵＲＬパス部を柔軟に解釈して多様な文字列処理をすることを可能にすべく、既存のＷＷＷサーバに取り付け可能な機能拡張装置および機能拡張方法ならびに前記機能を備えた機能拡張プログラムを記録した記録媒体を提供する。
【解決手段】 従来のＷＷＷサーバに、意図的にエラーを発生させるエラー誘発手段や文字列処理手段等を備えた機能拡張装置を備えることにより、任意の図形文字をＵＲＬパス部に含むことが可能になる。
【効果】 ＵＲＬに漢字等を含むことを可能にすることにより、ＵＲＬの告知手段としての価値を大幅に向上させることができる。
【選択図】 図１

Description

この発明は、既存の情報処理手段の機能を拡張する装置、方法ならびにこの方法を備えたプログラムに関し、特にＷＷＷサーバにおけるＵＲＬの解釈を柔軟に行うことによりＵＲＬの表現力や利用価値を高めることに関する。

インターネットにおけるＷＷＷ（ｗｏｒｌｄ−ｗｉｄｅ ｗｅｂ）サービス（「Ｗｅｂ（ウェブ）サービス」とも言う。）の利用形態の例を図２に示す。ＷＷＷサーバ（２１０）とＷＷＷクライアント（２０２）とは通常、（２０４）または（２０８）に示すような小規模なまたは広域のネットワークを経由して接続される。両者の間には、両者間の見かけ上の通信速度の改善等を目的としたＷＷＷ中継処理手段（２０６）が介在する場合がある。ＷＷＷサーバ（２１０）の一般的な構成と関連データを図６に示す。

ＷＷＷサービスを実施する際にＷＷＷサーバ（２１０）およびＷＷＷクライアント（２０２）の両者は、インターネットにおける通信サービスの標準等を定めたＲＦＣ（ｒｅｑｕｅｓｔ ｆｏｒｃｏｍｍｅｎｔｓ）なる文書集においてＨＴＴＰ（ｈｙｐｅｒ ｔｅｘｔ ｔｒａｎｓｆｅｒ ｐｒｏｔｏｃｏｌ）として定められた通信規約に従ってサービスを実施する。

図３Ａは、ＷＷＷサーバ（２１０）とＷＷＷクライアント（２０２）との間でやり取りされる通信処理を簡単に示したものである。基本的には、
（１）ＷＷＷクライアント（２０２）がＷＷＷサーバ（２１０）に対してＨＴＴＰリクエスト（ＨＴＴＰに基づく資源アクセス要求）を出し、
（２）ＷＷＷサーバ（２１０）がその応答（ＨＴＴＰレスポンス）として所定の資源をＷＷＷクライアント（２０２）に返す；
というものである。ＷＷＷクライアントがアクセスを所望するＷＷＷサーバ上の資源等を表す方法として図４に示すＵＲＬ（ｕｎｉｆｏｒｍ ｒｅｓｏｕｒｃｅ ｌｏｃａｔｏｒｓ）が用いられる。ＵＲＬもまたＲＦＣの１つとして定められた規約である。

図３Ｂは、ＷＷＷクライアント（２０２）がＷＷＷサーバ（２１０）に対してＨＴＭＬ（ｈｙｐｅｒ ｔｅｘｔ ｍａｒｋｕｐ ｌａｎｇｕａｇｅ）ファイルをアクセスしている様子を示したものである。上述したように
（１）ＷＷＷクライアント（２０２）はＷＷＷサーバ（２１０）に対してＨＴＴＰに従いファイル名「ｉｎｄｅｘ．ｈｔｍｌ」をＵＲＬパス部（図４Ａ参照）に含んで送信要求を行い、
（２）ＷＷＷサーバ（２１０）がその応答としてｉｎｄｅｘ．ｈｔｍｌをＷＷＷクライアント（２０２）に送信している。
なおＨＴＴＰでは、ファイルの送信要求以外にもプログラムの実行要求や動作確認等が指定可能である。

上記の手順に従ってファイルをアクセスする様子を図５に示すブラウザ（ＷＷＷクライアントの機能を実現するプログラムの呼称の１つ。「Ｗｅｂブラウザ」とも言う。）の画面インターフェース例を使って説明すると、次のようになる。

（１）ブラウザの画面インターフェースのＵＲＬ入力表示欄（５０２）に図４Ａに示すような文字列（これが「ＵＲＬ」である。なお、これは一例に過ぎない。）をブラウザのキーボードインターフェース等により入力してアクセス実行キー（図示せず）を押すことによりＷＷＷクライアント（２０２）は、ＵＲＬホスト部（図４Ａ参照）で指定したＷＷＷサーバ（２１０）へＵＲＬ等（必要に応じてブラウザの種別等の補助情報を付加する場合がある。）をＨＴＴＰリクエストとして送信する。この例ではＵＲＬパス部（図４Ａ参照）はアクセス対象とするファイル名を含む。

（２）前記ＨＴＴＰリクエストを受けてＷＷＷサーバ（２１０）は、ＵＲＬその他の情報を適宜処理する。ＵＲＬパス部は直接的または間接的にアクセス対象となるファイルの所在を示している（図１９参照）。
ＷＷＷサーバ（２１０）はＵＲＬパス部の内容に従って
ＷＷＷサーバ（２１０）内のファイルアクセス部（６１６）を用いて
ＷＷＷサーバ（２１０）内のファイル保持部（６２０）から所定のファイルを読み出す。
ファイル保持部（６２０）の内部構造は図８のようになっており、ファイルが記憶されている。なお、この図においては
ａｃｃｅｓｓ．ｃｇｉ、
ｉｎｄｅｘ．ｈｔｍｌ、
ｓａｌｅｓ．ｈｔｍｌ、
ｔａｋａｏｋａ．ｔｘｔ、
ｔａｎａｋａ．ｔｘｔ、
ｔｅｃｈ．ｈｔｍｌ、
の６のファイルが例として示されている。必要に応じて他のファイルが配置されたり消去される等の処理が行われる。

（３）読み出しに成功したならばＷＷＷサーバ（２１０）は、その結果（ファイル内容）をＨＴＴＰレスポンスとしてＨＴＴＰリクエストを発したアクセス元のＷＷＷクライアント（２０２）へ送信する。ＨＴＴＰレスポンスにはアクセスの成否等を示すステータスコード等を含む。なお、読み出しに成功しなかった場合は、ＷＷＷサーバ（２１０）は、読み出しのエラーを示すステータスコード等をＨＴＴＰレスポンスとする。

（４）ＷＷＷサーバ（２１０）における読み出しが成功した場合にはＷＷＷクライアント（２０２）は、その内容をファイルの形式に応じて受信データ表示欄（５０４）に表示する。

図９に示すのは「○×商会」（仮名。○×商会に対応するドメイン名は「ｏｘ．ｃｏｍ」とする。）のホームページの例である。

トップページの画面（９０２）は、（９０２）に示すようにブラウザのＵＲＬ入力表示欄（５０２）に対して
ｈｔｔｐ：／／ｗｗｗ．ｏｘ．ｃｏｍ／ｉｎｄｅｘ．ｈｔｍｌ
と入力してアクセスを実施した結果、ＷＷＷサーバ（２１０）のファイル保持部（６２０）内に存在するファイル「ｉｎｄｅｘ．ｈｔｍｌ」（図８参照）がＨＴＭＬの表示規約に則ってブラウザの受信データ表示欄（５０４）に表示されている様子である。

トップページに対応しているファイル
ｉｎｄｅｘ．ｈｔｍｌ
の中には○×商会の営業部と技術部の両ページへのリンク情報が記述されている。
営業部のページへのリンク部分（９０４）をマウスでクリックする等した場合は営業部のページ画面（９０８）が、
技術部のページへのリンク部分（９０６）をマウスでクリックする等した場合は技術部のページ画面（９１０）がそれぞれ表示される。
上記２のページのＵＲＬはそれぞれ
ｈｔｔｐ：／／ｗｗｗ．ｏｘ．ｃｏｍ／ｓａｌｅｓ．ｈｔｍｌ、
ｈｔｔｐ：／／ｗｗｗ．ｏｘ．ｃｏｍ／ｔｅｃｈ．ｈｔｍｌ
である。

以上が従来技術によるＷＷＷサービスの実施の形態の一例である。○×商会は、一応は、自己が望む内容のホームページを設営できているのかもしれない。

しかしながら、ＨＴＴＰやＵＲＬの規約に準拠したこれまでのＵＲＬ（このようなＵＲＬを以降、「ＴｒＵＲＬ」（Ｔｒａｄｉｔｉｏｎａｌ ＵＲＬ）と言う。）ではＵＲＬパス部に漢字等の全角文字を含むことができなかった。
そのため、本当は○×商会が図９のＵＲＬ入力表示欄（９０１）に示す表現方法に代えて図１０のＵＲＬ入力表示欄（１００１）、（１００７）、（１００９）に示すような漢字、ひらがら、カタカナを含むＵＲＬ（このようなＵＲＬを以降、「ＫＵＲＬ」（Ｋａｎｊｉ ＵＲＬ）と言う。）を用いたくてもできなかった（またはできないと考えられていた）。

少なくとも資料１（出典は後述）の雑誌の記事は、
「ブラウザに表示させるＵＲＬに日本語を使うことはできません。」
としている。当該雑誌の次号以降で訂正等がなされていないことを考え併せれば、これがインターネット関連業界の標準的認識と考えてほぼ良いであろう。すべてのブラウザがＨＴＴＰの規約どおり実装されていればこの記述は妥当である。ところが実際の状況はやや異なる。

発明者が実験した範囲では、ＨＴＴＰには反するかもしれないものの、開発者またはバージョンが異なる２以上のブラウザにおいて、ＵＲＬ入力表示欄（５０２）に漢字等を入力することは可能である。ただし、それ（漢字等を含んだＫＵＲＬ）をＷＷＷサーバに伝達する際の処理方法は異なっている。

このため、通信するＷＷＷクライアント（２０２）とＷＷＷサーバ（２１０）の双方が同一の漢字コード体系を用いているケースや下記のような対処を行ったケースでは、ＫＵＲＬがあたかも正常に使えているように処理することが可能である。

すなわち、（他の方法もあるかもしれないがここで説明するのは、）利用されうる漢字コード体系の別をＰ、ＨＴＴＰに基づくエンコード処理の有無やエンコード処理後の文字列の相違の別をＱとする時、Ｐ×Ｑ＝Ｒ通りの表記によるファイルをディレクトリ領域（図８Ａ参照）に設定する；という対処方法である。仮にＰ＝３、Ｑ＝２とした場合、１のＵＲＬに対して６のファイルを用意することになる。

ただし前記の方法には欠点がある。ＷＷＷサーバが動作しているコンピュータにおけるＯＳ（オペレーティングシステム）の種類によっては、特定の漢字コード体系における特定の文字を含む場合は、対応するファイルを設定できない可能性がある。それは−−漢字等の全角文字は多くの場合２バイト（１６ビット）が１文字に対応する。前記の方法では、外見上は漢字等を用いたファイル名が設定できているように見えながら、実は、２の１バイト文字（ここで「１バイト文字」は７ビットまたは８ビットの空間を持つ文字コード集合。例えばＡＳＣＩＩコード。）をただ連ねただけで（それ以外の配慮をせずに）１の全角文字を疑似的に実現している場合がある。このような漢字処理方法においては、当該ＯＳがファイル名には用いないとしている１バイト文字（例えばあるＯＳにおいては「／」（スラッシュ））を含むような全角文字は正しく取り扱うことができないおそれがある。

仮に上記のような現象が発生する可能性が低いとしてこれを許容するとしても、１のＵＲＬに対して６のファイルを用意するのにはファイルの設置や管理に手間が掛かる。それに、もしもＫＵＲＬの処理方式の異なるブラウザの数が増えてＱ＝５となった場合には、Ｐ＝３のままとして、１のＫＵＲＬに対して１５ものファイルを用意しなければならない。ＰやＱは将来の増加の可能性があるので、このような場当たり的な対処方法は運用面で大変手間の掛かる方法であると言える。しかも、上述したような不完全性を備えている。

ＴｒＵＲＬには漢字等の全角文字以外にも表記上の制限がある。
まず、ＴｒＵＲＬで使用可能な文字コード集合は最大でも７ビットの文字コード集合であるＡＳＣＩＩコードだけである。
上述した全角文字を含め、２バイト以上の領域を用いる日本語、韓国語、中国語等用の多バイトのコード体系は使えない。ヨーロッパを中心に用いられている「ＩＳＯ ８８５９−１」なるコード体系をはじめとする８ビット（１バイト）の文字コード集合も使えない。

ＴｒＵＲＬには更に制限がある。
ＡＳＣＩＩ文字コード集合のうち利用者側の意志で自由に使えない文字（コード）が複数存在する。具体的には、
（１）「非図形文字」である文字群（１１０２）、
（２）「Ｕｎｓａｆｅ」である文字群（１１０４）
（３）「Ｒｅｓｅｒｖｅｄ」である文字群（１１０６）
がある。正確な意味はＵＲＬに関するＲＦＣを参照されたい。以下では例を用いて説明する。

（１）の「非図形文字」とは紙に印刷できない特殊な文字（キャラクタ）のことである。この用法で言うところの「図形」とは「ａ」や「＝」などの表示可能な文字のことであり、算数や数学で慣用するところの円や三角形等の「図形」とは意味合いが異なるので注意されたい。
非図形文字の一例としては、ベル音（Ｃ言語の１６進数表現で「０ｘ０７」というコードが割り当てられているもの。）を発生される等の制御キャラクタ（機能キャラクタとも呼ばれる。）がある。これらは特定の機能を示す「文字」であるが、それらは「ａ」という文字とは違い印刷して表記することはできないので、「ＵＲ」を成す文字列としてそのまま「表記する」ということはできない。対策としてＲＦＣでは、所定の方法によりエンコードして表記する手段を提供している。前記「ベル音」であれば「％０７」と表記することになっている。

（２）の「『Ｕｎｓａｆｅ』である」とは、利用形態によって期待したように使える場合もあるし期待したように使えない場合もある；という意味である。利用するＷＷＷサーバ（またはブラウザ）に設定された動作条件によって振る舞いが変化する可能性のあるもの；と言い替えても良い。よって、用いないのが望ましいか、用いる際には注意が必要となろう。
一例として「⁻」を挙げることができる。「⁻ｔｏｍ」なる表現は、あるＷＷＷサーバにおいては利用者「ｔｏｍ」が所有するディレクトリを意味し、別のＷＷＷサーバにおいては単に長さ４バイトの文字列を意味する場合がある。

（３）の「『Ｒｅｓｅｒｖｅｄ」である」とは「予約済みの」という意味である。特定の意味に用いるものとして規約上予約されたものである。
具体的には、ＵＲＬホスト部とＵＲＬパス部とを分離したり（ディレクトリ等の）階層構造を表現するための「／」を例として挙げることができる。
ＵＲＬパス部における「ｄｉｒ１／ｄｉｒ２／ｆｉｌｅ」という表記は、「ｄｉｒ１」なる構造（ディレクトリ）の下位にある「ｄｉｒ２」なるディレクトリの下位にある「ｆｉｌｅ」なるファイルを示している。同様に「３／４」という表記は、「３」なるディレクトリの下位にある「４」なるファイルを示している。

ＴｒＵＲＬにおけるこれらの表記上の制限のため、ＴｒＵＲＬを意志表示手段と考えた場合、意志表示手段としてのその表現能力は低いと言わざるを得ない。例えば英語の文章を普段用いているように表記することができないからである。日本語等も同様である。

例えば図１２Ａに示す英文の疑問文風のＵＲＬは、ＲＦＣの規約上は図１２Ｂに示すＵＲＬと意味や処理結果は変わらない。つまり、ＵＲＬとしては図１２Ａは図１２Ｂと等価であり、図１２Ａにおける「？」は英文の疑問符として価値すなわち文字または符号としての価値を持っていない。

また、図１２Ｃのようにごくふつうの英文表記「Ｈｏｗ ｍｕｃｈ？」をそのままＵＲＬパス部に含ませることもできないもしくは望ましくない。なぜなら、「Ｈｏｗ」と「ｍｕｃｈ」との間にある空白文字（１６進数表現で０ｘ２０）と末尾の「？」はいずれも「Ｕｎｓａｆｅ」な文字であるからである。これは大変不自由なことである。とりわけＵＲＬの表示を広告手段と考えた場合、表現能力の自由度の低さは障害となる。

「非図形文字」である文字群（１１０２）、
「Ｕｎｓａｆｅ」である文字群（１１０４）または
「Ｒｅｓｅｒｖｅｄ」である文字群（１１０６）や、
ヨーロッパ特有の文字や漢字等の全角文字を含む８ビットまたは１６ビット（またはそれ以上）の文字コード集合の利用について少しでも制限が解除されたＵＲＬ（このようなＵＲＬを以降、「ＦｘＵＲＬ」（Ｆｌｅｘｉｂｌｅ ＵＲＬ）と言う。ＦｘＵＲＬは前記ＫＵＲＬを含む概念である。）があれば表現能力の自由度は向上するので好ましい。

そこでこの発明は、ＷＷＷクライアントからＷＷＷサーバに伝達されたＵＲＬの中のＵＲＬパス部を柔軟に解釈して多様な文字列処理をすることを可能にすべく、既存のＷＷＷサーバに取り付け可能な機能拡張装置および機能拡張方法ならびに前記機能を備えた機能拡張プログラムを記録した記録媒体を提供することを目的とする。

請求項１の機能拡張装置は、意図的にエラーの発生を誘うエラー誘発手段を用いてＵＲＬに関する処理を既存のＷＷＷサーバから既存のＷＷＷサーバ以外の処理手段である文字列処理手段（この文字列処理手段はこの発明により新規に用意する手段である。）へと移している。その際、既存のＷＷＷサーバが情報処理した結果として記憶された記憶手段の情報を利用している。

これにより、既存のＷＷＷサーバでは実現が困難であったＵＲＬパス部の柔軟な解釈が可能となる。この発明の一実施形態による機能拡張手段等を備えたＷＷＷサーバの処理の流れを図１に示す。

前記文字列処理手段における情報処理内容を限定する事由は無く、ＵＲＬ中のＵＲＬパス部に該当する部分の文字列（図４Ａ参照）を利用した多様な情報処理が可能である。ＵＲＬの表現能力の自由度が高くなり告知手段としての価値が高まる等の効果があるため、既存のＷＷＷサーバに請求項１の機能拡張装置を備えたもの（以下、このようなＷＷＷサーバを「ＦｘＵＲＬ対応ＷＷＷサーバ」と言う。）の産業上の利用価値は大幅に向上する。

請求項２の機能拡張装置は、どのようなＵＲＬパス部の到来に対してエラーを誘発するのか（あるいは逆に誘発しないのか）やどのような時間帯にエラーを誘発するのか等の、エラーを誘発するための条件を変更する条件変更手段を備えている。

これにより、状況に応じて既存のＷＷＷサーバ処理手段と新規に設ける文字列処理手段とを目的に応じて切替利用したり、特定のＵＲＬホスト部を持つＵＲＬは常に既存のＷＷＷサーバ処理手段により処理する等の条件を設定したり変更したりすることが可能となる。また、機能の異なる文字列処理手段を複数多種準備してこれらを切替利用したり連係させて利用する等も可能となり、より多様な情報処理が実現でき便利である。

機能の異なる文字列処理手段を複数多種準備する際、共通部分の一本化や文字列処理手段自体の構造の簡素化は望ましい。このようにできれば、文字列処理手段の将来における機能拡張や維持管理が容易になる。

請求項３の機能拡張装置は、機能拡張装置を構成するどの要素も（ただし請求項２の条件変更手段を除く。）既存ＷＷＷサーバ処理手段の固定的部位を何ら変更することなく備える。ここで「固定的部位」とは、いったん使い始めたら
（１）変更することが容易ではない部位または
（２）通常は変更しないで利用する部位
のいずれかを言う。ＷＷＷサーバを構成するプログラム群で言えば、ＷＷＷサービスを実現しているプログラム自身（あるＷＷＷサーバプログラムパッケージの場合は「ｈｔｔｐｄ」という名前のバイナリファイルである。ソフトウェアのバイナリファイルではなく同等の機能を持ったハードウェアロジックである場合もこれに該当する。）がこれに該当する。
これに対して非「固定的部位」とは、例えば、ＷＷＷサーバの初期化処理部（６０８）が参照する初期化情報保持部（６１４）（あるＷＷＷサーバプログラムパッケージの場合は「ｈｔｔｐｄ．ｃｏｎｆ」という名前のテキストファイルである。ソフトウェアのテキストファイルではなくオン・オフ等が可能なスイッチ類や適用量を容易に変化させられるボリューム類もこれに該当する。）や、ＷＷＷサーバがＨＴＴＰレスポンス（図３参照）として送信するファイル保持部（６２０）の中のファイルを挙げることができる。

つまり請求項３の機能拡張装置は、既存のＷＷＷサーバの中心的部位をなんら変更する必要が無いため、容易にまたはコストをそれほど掛けずに適用できる。このため、一般にソースコードの入手が困難な商用のＷＷＷサーバにも適用することができる。仮にソースコードの入手が困難でない場合でもソースコードを修正して再コンパイルする等の必要がないので速やかに適用することができる。また、仮にソースコードのコンパイルが不要なインタプリタ型の言語で「ｈｔｔｐｄ」同等物が作られていた場合でも、ソースコードの修正に伴う万が一の機能劣化を回避することができる等のメリットがある。

請求項４の機能拡張装置は、処理対象となるＵＲＬがＷＷＷクライアント（典型的にはブラウザ）におけるＵＲＬ入力表示欄（５０２）に入力された文字列に対応していることを第１の特徴としている。この発明ではこの文字列を「クライアント側入力文字列」と言う。

ここで「クライアント入力文字列」ではなく「クライアント側入力文字列」となっているのは、ＷＷＷサーバ（２１０）とＷＷＷクライアント（２０２）との間にＷＷＷ中継処理手段（２０６）が介在する場合があるからである。

ＷＷＷ中継処理手段（２０６）が介在した場合、ＷＷＷサーバ（２１０）とＨＴＴＰにて通信するのは直接的にはＷＷＷ中継処理手段（２０６）であるが、ＷＷＷ中継処理手段（２０６）は通常ＷＷＷクライアント（２０２）の要請に基づいてＷＷＷサーバ（２１０）との通信を実施している。

ＷＷＷサーバ（２１０）が処理対象とするＵＲＬがＷＷＷクライアント（２０２）から直接送信されてきた場合もＷＷＷ中継処理手段（２０６）を経由して送信されてきた場合も、どちらもＷＷＷクライアントからのデータであると見做すという意味を込めて「クライアント『側』入力文字列」としたのである。

第２の特徴として請求項４の機能拡張装置は、ＷＷＷクライアント（２０２）のＵＲＬ入力表示欄（５０２）に入力した時の表示通りの文字列（このＷＷＷクライアント側で入力された文字列を、以下「文字列１」とする。）をＷＷＷサーバ（２１０）で再現するとしている。（ＷＷＷサーバ側で再現された文字列を、以下「文字列２」とする。）たとえネットワーク（２０８）中においてどのような表記形式で伝送されようとも文字列１と見た目上（つまり印刷した際に）同一の文字列をＷＷＷサーバにて獲得する獲得手段を備えるとしている。

これにより、ＷＷＷクライアント（２０２）のＵＲＬ入力表示欄（５０２）に漢字等の全角文字や前記「Ｕｎｓａｆｅ」な文字を含む文字列がＵＲＬとしてブラウザのＵＲＬ入力表示欄（５０２）に入力された場合、すなわち、前記ＦｘＵＲＬがブラウザのＵＲＬ入力表示欄（５０２）に入力された場合でも、
（１）両ＷＷＷ処理手段（（２０２）と（２１０）のこと。）が採用する漢字コード体系の相違、
（２）２以上のＷＷＷクライアント（２０２）間のエンコード処理方法の相違、または
（３）ＷＷＷクライアント（２０２）におけるエンコード実施の有無の相違
によらず、前記文字列処理手段はＷＷＷサーバが備える記憶手段の情報を利用しつつＷＷＷクライアント（２０２）のＵＲＬ入力表示欄（５０２）に入力した時の表示通りの文字列１を文字列２として得ることができる。

ただし、ＵＲＬ入力表示欄（５０２）に（エンコードしないままの）「＃」そのものを含む
ｈｔｔｐ：／／ｗｗｗ．ｏｘ．ｃｏｍ／ｉｎｄｅｘ．ｈｔｍｌ＃ｓａｌｅｓ
というような文字列を入力した場合、その「＃」以降の文字列（「＃ｓａｌｅｓ」）は通常はＷＷＷサーバ側（ＷＷＷサーバまたはＷＷＷ中継処理手段）には伝達されないため、その「＃」以降の文字列をＷＷＷサーバで再現することはできない、つまり文字列１と文字列２が同一にはならない；としている。「＃」以降の文字列がＷＷＷサーバ側には伝達されるのであれば、文字列１と文字列２は同一にすることができる。

前記ＦｘＵＲＬ（またはそのサブセットであるＫＵＲＬ）がブラウザのＵＲＬ入力表示欄（５０２）に入力できることにより、図１０の（１００１）、（１００７）、（１００９）に示すような漢字等を含むＫＵＲＬを用いることが可能となり、ＵＲＬの表現手段としての価値は飛躍的に向上する。また図１２Ｃのように、前記「『Ｒｅｓｅｒｖｅｄ』である文字群（１１０６）」の文字を含むごくふつうの英文表記もＦｘＵＲＬのＵＲＬパス部に置くことが可能となる。両者の混合、すなわち、ＦｘＵＲＬのＵＲＬパス部に「Ｒｅｓｅｒｖｅｄ」である文字群（１１０６）の文字と漢字等の文字の両方を含む文字列を置くことも可能である。

資料２（出典は後述）の新聞の記事によれば、
「英語でＵＲＬというアドレスを入力してホームページを探すのは日本人には骨が折れる」というある人物の発言が紹介されていたり
「インターネットの窓口にもＵＲＬの日本語変換ソフト（中略）がほしいという声は少なくない」
という認識が示されていたりする。これがインターネット関連業界またはパソコン利用者の標準的認識と考えてほぼ良いであろう。上述したように、請求項４の機能拡張装置はこれに十分応えることができると発明者は考えている。

なお、請求項４の機能拡張装置を作る際には、この機能拡張装置内部で用いる漢字コード体系を処理の早い段階で統一することが望ましい。より複雑な処理をこの機能拡張装置の後段で実施する際に漢字コード体系の相違を意識せずに処理を進められることはメリットになる。

請求項５の機能拡張装置は、処理対象のＵＲＬがブラウザのＵＲＬ入力表示欄（５０２）以外から与えられる文字列に由来していることを第１の特徴としている。第２の特徴については請求項４の機能拡張装置と同様である。以下、第１の特徴についてもう少し詳しく説明する。

一般的なＷＷＷサービスの実施の形態においては、ＷＷＷクライアント（２０２）はブラウザというプログラムを備えたパソコンであることが多い。ブラウザの画面インターフェースの概要は図５に示すようなものである。ブラウザのＵＲＬ入力表示欄（５０２）からＷＷＷサーバにおいて処理対象となるＵＲＬ−−それはＴｒＵＲＬかもしれないしＦｘＵＲＬかもしれない−−が与えられるのである。つまり、ＷＷＷサーバにおいて処理対象となるＵＲＬの入力または選択は、人間がキーボードを用いてキー入力する場合でもいくつかの項目の中からマウスを用いて選択する場合等でも、手動で行われる。ある者は商用ブラウザが備える良好なＧＵＩ（グラフィカルユーザインターフェース）によりこれを行うであろうし、別のある者はＧＵＩではなくＣＵＩ（キャラクタユーザインターフェース）を備えたブラウザによりこれを行うであろう。画面の体裁はともかく、ＷＷＷクライアントとして特化されたプログラム（すなわち「ブラウザ」）を利用することであろう。

請求項５の機能拡張装置はそうではなく、
（１）手動でＵＲＬを入力するもののブラウザほど良好な（または専用の）ＧＵＩやＣＵＩを持たないプログラムまたは
（２）所望のＵＲＬを自動で生成して自動でＷＷＷサーバへと送信するプログラム等
が利用されることを想定している。

前者の例として「ｔｅｌｎｅｔ」と称するプログラムを挙げることができる。後者の例は、たとえばＨＴＴＰを処理することができる自作プログラムを挙げることができる。後者のプログラムは人手を介することなく処理が進められるため、自動的かつ大量の処理を一括でまたは適宜分散させて処理するのに好適である。同時に、そのようなプログラムにはＧＵＩはもとより原始的なユーザインターフェースさえ持たせる必要が無いためソースコード（または実行ファイル）の規模は小さくなり、高性能でないパソコンでも好適な処理速度が得られるだろう。なお、自動的な処理を行うための条件設定に際しては人手を介する場合もあろう。

このような特徴をもった上記（１）または（２）記載のプログラムを用いることにより生成されたＵＲＬをＷＷＷサーバにおいて処理対象とするのが請求項４の機能拡張装置である。従って、ＷＷＷサーバにおいて処理対象となるＵＲＬは必ずしも人手を介したものである必要は無いので、自動的かつ大量の処理を一括でまたは適宜分散させて処理するのに好適である。

しかも、ＵＲＬとなる文字列をブラウザにおけるＵＲＬ入力表示欄（５０２）から与える必要がないため、ＵＲＬ入力表示欄（５０２）からは入力できないまたは入力が困難な文字列でもＷＷＷサーバにおいて処理対象となるＵＲＬとすることができる。これにより、例えば入力困難な漢字や記号類を用いたより多様な表記の文字列−−それがＦｘＵＲＬであ−−をＵＲＬをして用いることができ、便利である。

請求項６の機能拡張装置は、
（１）ＵＲＬパス部に漢字、ひらがなまたはカタカナが含まれており、かつ、
（２）ＣＧＩプログラム等へのパラメータ伝達を指示するとＲＦＣにて定義された文字列（現バージョンのＲＦＣにおいては「？」）をＲＦＣの定義通りに用いる用途では含まないこと；
を特徴としている。逆に言えば、漢字等を含むＵＲＬパス部においてＣＧＩプログラム等へのパラメータ伝達のために「？」が使われている場合、すなわち、ＵＲＬパス部がＲＦＣに記載されているＵＲＬの通常の表示様式に準拠した文字列である場合、そのＵＲＬが処理可能であることはこの発明の範囲ではない；ということである。一例を挙げれば、ＵＲＬパス部が「？イロハ」あるいは「ｉｎｄｅｘ．ｃｇｉ？イロハ」なる文字列である場合ＵＲＬについてそのＵＲＬが処理可能であることはこの請求項における発明の範囲ではない。

もう少し具体的に説明する。
図１３Ａまたは図１３Ｃに示すＵＲＬが処理できるようになることはこの発明の範囲であるが、図１３Ｂに示すＵＲＬが処理できるようになることはこの発明の範囲ではない。
なぜなら、現在市場で主流となっているブラウザを用いて発明者が実験した範囲では、既存のＷＷＷサーバが通常備えているＣＧＩ処理手段のパラメータとして図１３Ｂに示すＵＲＬのＵＲＬパス部を処理可能なようにブラウザが適切にエンコードすることになっているからである。
（ただし、前記図１３Ｂに示す漢字を含むＵＲＬを一見「適切に」処理するような実装はＲＦＣの規約に違反しているかもしれないし、発明者が実験した範囲でたまたまうまく動作しただけかもしれない。）
よって図１３Ｂに示すＵＲＬが処理可能になることは新規性が無い。それに、既存のＷＷＷサーバが図１３Ｂに示すＵＲＬを処理するに際しては請求項１に記載したような意図的にエラーを誘発するようなエラー誘発手段を用いていない−−すなわち、正常処理の範疇として情報処理される−−ため、この意味からも図１３Ｂに示すＵＲＬが処理可能になることはこの発明の範囲ではない。

ＵＲＬを情報表現手段（たとえば広告媒体などの告知媒体）として捉えた場合、次の理由により図１３Ａに対して図１３Ｂは劣っていると言って良いであろう。ＵＲＬを読む側が基礎的な英語力を有していると仮定する場合、図１３Ａについては、ＵＲＬホスト部とＵＲＬパス部の部分に着目して「Ｍｙ ｎａｍｅ ｉｓ 林毅」、すなわち、「私の名前は林毅です」という意味を想像（意味に解釈）することができよう。図１３Ｂもそのように想像・解釈できなくはないかもしれないが、ＵＲＬパス部の先頭にある「？」は余計である。通常の文章表現においてこのような「？」を用いることは無いし、個人や法人等の名前自体に「？」が含まれることも無いであろう。

図１３Ｃに示す例は、「あなたの名前は林毅ですか？」という意味を想像（意味に解釈）することができよう。図１３Ｂとは違い（ＵＲＬパス部の末尾にある）「？」は余計ではない。文の疑問符としての役割を果たしていると解することができるからである。

なお図１３Ｂの表記は、「？」の前に存在すべきＣＧＩプログラムのファイル名等が省略されたものである。これを省略せずに表記すれば、たとえば、図１３Ｂ２のようになる。図１３Ｂ２のＵＲＬは告知媒体としての価値は大幅に低下していると言って良いであろう。

請求項７の機能拡張装置は、ＵＲＬパス部が日本語、英語、フランス語のような国または地域で使われている言語における語句（単語）を含んでいることを特徴としている。このことは自動的に、句または文を含むことを意味する（図１４のＡ、Ｂ、Ｃ、ＤおよびＦを参照）。エスペラント語のような人工言語を排除しない。

ブラウザにおけるＵＲＬ入力表示欄（５０２）からまたはその他の手段により、
（１）ＩＳ０ ８８５９−１文字コード集合中の非ＡＳＣＩＩ文字コードの文字や
（２）いわゆる外字（既存の漢字コード体系において標準的なコードが割り当てられておらず、利用者が個々にコードを割り当てている文字のこと。）として扱っている文字もしくは
（３）それらを混合した文字列
をＵＲＬとして入力または指定等できるのであれば、これを用いることにより一層多様な表現が可能となる。図１４Ｈはフランス語の旬が含まれている（１）の例、図１４Ｉは「高」の旧字体が含まれている（２）の例である。この説明では「ＩＳ０ ８８５９−１」を取り上げたが、「ＩＳ０ ８８５９−２」「ＩＳ０ １０６４６」やその他の文字コード集合についても同様に考えることができる。

請求項７の機能拡張装置はまた、特定の学術分野（例えば数学）において用いられる式などの表現形態を含んだり、コンピュータ言語の命令等を含むことを特徴とする場合がある。図１４Ｇは数式（ｘの２次方程式）を含むＵＲＬの例である。図１４Ｅはコンピュータ言語の一種であるＣ言語を含むＵＲＬの例である。

これにより、多様な言語の文や式などを含む多様な表現力を備えたＵＲＬを用いることができるので、表現力豊なＵＲＬの利用が可能になる。ＵＲＬの情報表現手段としての利用価値は一層向上し、営業活動等への利用に好適である。消費者の購買意欲をそそるようなワクワクするような表現をＵＲＬに用いることも可能であろう；と発明者は考える。

請求項７を突き詰めて考えれば、任意の表現手段を採りうることが可能だと分かる。言語系としては点字や手話、あるいはジェスチャーやボディランゲージであっても良いかもしれない。
ただし、手話やジェスチャーのような動作をブラウザのＵＲＬ入力表示欄（５０２）に表現しようとすれば「アニメーションＧＩＦ」（画像データを用いた連続表示したスライドのようなもの）を用いれば可能かもしれないが表現内容が時間とともに変化してしまう等の理由から実装（実現）は難しい。しかし、点字ならばＵＲＬ入力表示欄（５０２）の実装方法を工夫することにより入力や表示が可能であろう。
このような考えを推し進めれば、任意の画像データをＵＲＬ入力表示欄（５０２）にて取り扱うことが可能であるとの推察が付く。上述した理由から以下では静止画に限って話しを進める。

これを実現するためには、ＵＲＬ入力表示欄（５０２）を既存のブラウザにおいて実装されているような＜所定の文字列の表示、入力、編集が可能な領域＞と捉えるのではなく、＜任意の画像データの表示、入力、編集が可能な領域＞と捉え直せば良い。
具体的には、現在のような＜１行のみのテキストエディタ＞ではなく＜横長の長方形領域を編集範囲とする画像エディタ＞として新たな仕様でＵＲＬ入力表示欄を実装し直せば良い。もちろん通常の画像エディタと同様、文字列の表示、入力、編集も可能とするのである。
なおこの「新たな」「ＵＲＬ入力表示欄」（以下、これを「画像対応型ＵＲＬ入力表示欄」と言う。）は、外見上は従来のＵＲＬ入力表示欄と同一にすることもできるので、図５に示すＵＲＬ入力表示欄（５０２）は画像対応型ＵＲＬ入力表示欄であると見做すこともできる。

ここまで考えを発展させると、上述のようにＵＲＬパス部に画像データ等を含むＵＲＬ（以下、このようなＵＲＬをビジュアルＵＲＬ、略して「ＶＵＲＬ」と言う。）はＲＦＣで定義されたＵＲＬの範疇を越えてしまうように思える。しかしながら、例えば、点字や画像データをＲＦＣで定義されているＭＩＭＥ（ｍｕｌｔｉｐｕｒｐｏｓｅ ｉｎｔｅｒｎｅｔ ｍａｉｌ ｅｘｔｅｎｓｉｏｎｓ）という規格のＢＡＳＥ６４形式にてエンコードするという規約をＶＵＲＬをやり取りする双方が合意すれば、点字や画像データをＵＲＬパス名部に表現することが可能となる。

この場合、
（１）ＷＷＷクライアントにおけるＵＲＬ入力表示欄における表現物（表現物１）と表現物１を受信したＷＷＷサーバにおけるデコード後の表現物（表現物２）については点字や画像データという形式で情報が表現される一方、
（２）ＷＷＷクライアントとＷＷＷサーバとの間にあるネットワーク中ではＢＡＳＥ６４形式の文字列として表現されたもの（表現物３）とする；
というような実施形態を想定することができる。ＶＵＲＬの例を図１４Ｊに示す。ＵＲＬパス部には人の顔に似せた小さなアイコンのような画像が置かれている。

このような機能拡張も、この発明の請求項１に記載されているような「ＷＷＷサーバがＵＲＬを処理するに際して意図的にエラーを誘発するエラー誘発手段」や「少なくともＵＲＬパス部を利用して処理を行う文字列処理手段」等を備えるこの発明の機能拡張装置を用いることにより、ＷＷＷサーバ側については比較的容易に対応が可能である。
なお、ＷＷＷクライアント（ブラウザ）側については、「プラグイン」と呼ばれている良く使われている機能拡張手段により対応が可能である。

なお、ＶＵＲＬの画像データ部分をＢＡＳＥ６４でエンコードした場合、画像データは
「ａ」〜「ｚ」、
「Ａ」〜「Ｚ」、
「０」、「１」〜「９」、
「＋」、「／」、「＝」
の合計６５種類の文字の組合せで表現されることになるが、ＦｘＵＲＬならば文字「／」を始め６５すべての文字について何ら制約を受けずにＵＲＬパス部に記述可能である。

ＶＵＲＬによれば点字（正確には、点字風の画像データ。）や絵文字を含む任意の画像データを情報表現手段としてＵＲＬ中に用いることができるため、例えば、
（１）通常の日本語や英語等による表記を理解できない人々、
（２）点字や絵文字の方が速読できる（またはなじみが深い）人々、
（３）絵文字を用いた簡便な意志伝達を希望する人々
などにとっては有意義なものとなろう。点字を含むＶＵＲＬは身障者の人々がインターネットを活用する際の一助となるかもしれない。ただし、平面的に印刷された点字ではなく凹凸のある真の点字の入力や読み取りに際しては別途専用の装置等が必要になる。

なお、ＶＵＲＬの表記内容を読み取ることは容易であろうが、ＶＵＲＬが紙などの印刷媒体に表示されているような場合は（文字列と違って）読み取った表記内容と同一のものをＵＲＬ入力表示欄に入力することは多くの場合困難であろう。この場合、例えば、
（１）ＶＵＲＬを印刷した近傍にそのＶＵＲＬに対応する２次元コードを添え、その２次元コードを２次元コードリーダを用いて機械的に入力する；
（２）ＶＵＲＬがカードに印刷されているならば、カードに磁気ストライプ等を設けてその中にエンコードしたＶＵＲＬを記録し、磁気カードリーダ等を用いて機械的に入力する；
などの方法のより対処可能となる場合もあろう。

更に、ＵＲＬ入力表示欄（５０２）に入力される文字列を図形情報と捉えることにより、用いる文字フォントの違い（例：明朝体とゴシック体）により実際に意味するＵＲＬの解釈を変えるという実装を行うことも可能である。この場合、
（１）従来の文字列（テキスト）としての情報にフォントの種別についての情報を付帯させてＷＷＷサーバに伝達するか、または、
（２）入力されたＵＲＬをそのまま画像データとして捉えて上述の方法でＷＷＷサーバに伝達する
等の方法が想定可能である。

請求項７の機能拡張装置はまた、ＵＲＬパス部に暗号化されたデータを含むこともできる。データを暗号化してこれを文字列として出力した場合、その文字列は通常にＡＳＣＩＩ文字コード集合の図形文字を用いることになるが、ＦｘＵＲＬにはＴｒＵＲＬのような「Ｕｎｓａｆｅ」または「Ｒｅｓｅｒｖｅｄ」となっている文字種は無いので、特別なエンコード処理をすること無く暗号化されたデータをＵＲＬパス部に置くことができる。図１４Ｋに例を示す。「ｅｎｃｒｙｐｔｅｄ／」以降に示すのは、あるデータを（コンピュータ業界において）「ＤＥＳ」と呼ばれている暗号方式により暗号化した文字列である。これはあくまでも一例であり、暗号化方式は任意である。

請求項８の機能拡張装置は、ＵＲＬパス部に検索を指示する文字列が含まれていることを特徴とする。「検索を指示する文字列」には大きく分けて２種類ある。記号を利用するものと自然言語によるものである。

第１の記号を用いた検索指示では、コンピュータ業界において「正規表現」や「ワイルドカード」と呼ばれる表現方法を用いる。これらを用いれば、図１５のＡ、Ｂ、Ｃ、ＤおよびＥのようなＵＲＬが利用可能となる。

図１５Ｂはワイルドカードを用いた例である。ＷＷＷサーバはファイル保持部（６２０）のディレクトリ領域（図８Ａ参照）を検索して、「ａ」で始まり「ｚ．ｈｔｍｌ」で終わるファイル名（例：「ａｂｃｄｚ．ｈｔｍｌ」、「ａあいうｚ．ｈｔｍｌ」、「ａ＋−＝ｚ．ｈｔｍｌ」）を持つファイルを探し出す。
図１５Ａもワイルドカードを用いた例であり、「ａ」で始まり「ｚ．ｈｔｍｌ」で終わる８文字のファイル名（例：「ａｂｚ．ｈｔｍｌ」、「ａ−ｚ．ｈｔｍｌ」、「ａ．ｚ．ｈｔｍｌ」）を持つファイルを探し出す。該当するファイルが２以上ある場合は、
（１）最初のファイルを検索結果としたり
（２）検索結果を順にすべて処理する
等のルールを別途定めて実施することになろう。また、上記の例において全角を文字を含むファイル名を検索の対象にすべきか否か等については別途ルールが必要であろう。

図１５Ｃは正規表現を用いた例である。ファイル名が数字のみから成るファイルを探し出すよう指示している；と解釈できる例である。

図１５Ｄは、ＷＷＷサーバ処理手段の外部にあるデータベース（この例では当該データベースの識別子は「ｎａｍｅｓ．ｊｐ」としている。日本の人名データベースの意に解釈されたい。）から名前の最初が「田中」である人物を探し出すよう指示している；と解釈できる例である。

同様に図１５Ｅは、データベース「ｎａｍｅｓ．ｊｐ」から名前の末尾が「子」である人物を探し出すよう指示している；と解釈できる例である。

実際の運用に際しては、どのような表記（文字列）がどのような意味を持つのかについて、事前に定義したり動的に決定したりするなど、ＷＷＷクライアント（２０２）側とＷＷＷサーバ（２１０）側とで一定のルールに合意する必要がある。

第２の自然言語を用いた検索指示について説明する。

図１５Ｅ２は、図１５Ｅと等価な意味をワイルドカードを使うのではなく自然言語を用いて表現した例である。日本語以外で記述しても良い。また、図１５Ｆ（またはデータベース識別子を省略して図１５Ｆ２）のように質問文を含むこともできる。このようなＦｘＵＲＬをＷＷＷクライアント（２０２）側で用いてＷＷＷサーバ（２１０）側にて処理しようとすれば、
（１）ＵＲＬパス部の部分を言語処理して意味を獲得する言語処理手段を別途備えるか、または、
（２）ＷＷＷサーバ（２１０）側で解釈可能な構文のパターンを予め定めておき、ＷＷＷクライアント（２０２）側ではそのパターンに従って文を組み立ててＵＲＬパス部に含む；等の処理が必要になろう。後者の方法は、書式がきっちりと定まっているという意味においてコンピュータ言語のプログラミングの要領に似ている。

以上に述べたように、
（１）複数のファイルを一度の要求で獲得可能な検索式を成す文字列をＵＲＬに含んだり、
（２）自然言語の質問文を成す文字列をＵＲＬに含むこと
等が可能となり、便利である。この技術を用いることにより、インターネットにおける新しいタイプの検索サービスを提供することが可能となろう。

請求項９の機能拡張装置は、下記に示す２つの対照的な手段のうちの少なくとも一方を備えることを特徴とする。

その第１の手段である「特別文字列普通解釈手段」により、ＨＴＴＰの規約により特別な意味が与えられている「？」や「／」等の「Ｕｎｓａｆｅ」である文字群（１１０４）や「Ｒｅｓｅｒｖｅｄ」である文字群（１１０６）の文字についてその文字本来の用途に用いることが可能となる。

これにより、「４分の３」という分数をＵＲＬパス部に表記できる（図１６Ａ参照）。
通常ならば図１６Ａは、＜「ａｎｓｗｅｒ＝３」という名称のディレクトリの下にある「４＝０．７５」という名称のファイルを指示するもの＞と解釈すべきＵＲＬである。なぜなら、ＵＲＬの様式を定めたＲＦＣにより「／」は階層構造の境界を示すとされているからである。
ＴｒＵＲＬではこのような解釈になるが、ＦｘＵＲＬでは必ずしもこのように解釈しなくてもよい。このように請求項９の機能拡張装置は、「／」を階層構造の境界を示す記号以外の意味に用いることを可能にする。「／」以外も同様である。

このように「特別文字列普通解釈手段」により、より自然な表現の文をＵＲＬパス部に含むことが可能となる等のメリットが得られる。

その第２の手段である「普通文字列特別解釈手段」は、上記「特別文字列普通解釈手段」とは逆に、何らかの文字列を階層構造の境界を示すものとして解釈することを可能にする。例えば、図１６ＢのＫＵＲＬには階層構造の境界を示すものは無い。これを、「の中の」または「の」を「／」と等価であると解釈することにより、図１６Ｂ２のＫＵＲＬに置換することができる。両ＫＵＲＬの下線部に注目されたい。

これにより、ファイル保持部（６２０）におけるアクセスすべきファイルの所在が確定し、目的のファイルを読み出すことができるようになる。

図１６Ｂ２のＫＵＲＬは漢字等を用いた日本語の文となっているが、この例における図１６Ｂ２から図１６Ｂ３への変換処理については、ＵＲＬパス部の内容を言語的意味を理解して処理するのではなく、単なる置換処理で十分である。（ただし、「の中の」から「／」への置換処理を「の」から「／」への置換処理に先行して実施する程度の工夫は必要である。）このため、（文法解釈等を伴う言語処理を行う場合を考えれば）この変換処理に要する作業量はそう多くはない。

ＴｒＵＲＬでは「の」をこのような意味で用いるという用法はないし、漢字等も使うことができないため、図１６Ｂ３のように表記せざるを得なかった。図１６Ｂに示すような表記方法（つまりＫＵＲＬもしくはこれを包含するＦｘＵＲＬ）が普及すれば、コンピュータ利用の「参入障壁」を数段下げることができる可能性があり、ＷＷＷサービスの利用者の増大等が期待できる。併せてインターネットのサービス全体の利用者増も期待できる。

なお、階層構造の境界を示すものとして解釈させる「何らかの文字列」はローマ字表記の日本語の句でもよいし、ローマ字表記の英語の句でもよいし、その他記号列等でもよい。図１６Ｂ４に示すのはローマ字表記の英文である。この場合、まず「△ｏｆ△」（ここで「△」はＡＳＣＩＩ文字コード集合における空白文字。Ｃ言語の１６進数表記で０ｘ２０。いわゆる半角スペースを示す。図面においても同様。）を「／」に置換した後、更に左右の語の並びを入れ替えることにより図１６Ｂ３を得ることができる。更に英和翻訳等を行えば図１６Ｂ２を得ることもできる。

上記の説明ではＲＦＣにより「階層構造の境界を示すもの」と定義付けられた事項とそれに対応する文字列を取り上げたが、これ以外の事項についても同様である。

このように「普通文字列特別解釈手段」により、より自然な表現の文をＵＲＬパス部に含むことが可能となる等のメリットが得られる。

以上のように、請求項１を頂点とするこの発明は、応用範囲が極めて広い。これは、前記文字列処理手段における情報処理の内容を特段制限する事由が無いことによる点が大きく寄与している。特に請求項３の発明によれば既存のＷＷＷサーバの固定的部位は何ら変更する必要がないためこの機能拡張装置の利用は容易であり、これがこの発明の価値を高めることになろう。

この発明による機能拡張装置を利用するためには、対象となる装置が
（１）例外事象発生時の処理手段を呼び出す仕組みと
（２）その処理手段として所望のものを設定可能
という２の条件を満たしていれば良い。たとえば「ＣＰＵ」は「ＷＷＷサーバ」ではないが、ＣＰＵはこれらの条件を満たしているものが多い。

このことを熟考すれば、請求項１が機能拡張の対象としている装置をＷＷＷサーバにのみ限定していることについて疑問が生じて来る。「この限定を取り払うとどういうことになるのか？」発明者は自問自答した。

コンピュータのファイル等のデータを「資源」と捉えるならば、ＵＲＬはインターネットにおける資源の同定用文字列と言える。実際、「ＵＲＬ」の正式名称である「Ｕｎｉｆｏｒｍ Ｒｅｓｏｕｒｃｅ Ｌｏｃａｔｏｒｓ」がそれを示している。そして、資源の所在を指し示す文字列を「アドレッシング用文字列」と呼び直してみると、
（１）ＵＲＬと並んでインターネットにおいて頻繁に利用されている文字列である「電子メールアドレス」や
（２）ＵＲＬと電子メールアドレスに共通の要素である「ドメイン名」
等も「アドレッシング用文字列」と言って良いだろう。

ここまで考えを進めるとこの発明は、アドレッシング用文字列を処理するサーバ全般に適用できそうだとの推測が付く。具体的には、
（１）電子メールの配送等を行うための手段である電子メールサーバや、
（２）ドメイン名からＩＰアドレスを得るための（またはその逆の用途のための）手段であるＤＮＳ（Ｄｏｍａｉｎ ｎａｍｅ ｓｙｓｔｅｍ）サーバにも適用できそうなことが推測できる。ＦＴＰ（ｆｉｌｅｔｒａｎｓｆｅｒ ｐｒｏｔｏｃｏｌ）サーバにも適用できるであろう。すなわち、電子メールサーバ（「ｓｅｎｄｍａｉｌ」という名称のプログラムが有名である。）を例に採れば、次のような請求項を設けることが可能である。

「既存電子メールサーバが電子メールのアドレスを処理するに際して意図的にエラーを誘発するエラー誘発手段と、前記既存電子メールサーバが記憶手段に記憶させたデータのうち少なくとも電子メールアドレスのユーザＩＤ部を利用して処理を行う文字列処理手段と、前記エラー誘発によりエラーが発生した時に前記既存電子メールサーバから前記文字列処理手段へと処理を分岐させる分岐手段とから成る機能拡張装置。」

更に考えを推し進めれば、この発明は、インターネット以外の領域にも適用できそうなことが推測できる。例えば、電話通信網における電話番号に基づく回線交換システムにも適用可能であろう。

このように考えるうちに、これらの適用可能な用途をすべて個別に列記して請求項として記述する方法では限界があると発明者は考えた。そこでこの発明の本質を抽出し、新たな請求項とした。それが請求項１０と請求項１１である。

請求項１２の発明は、請求項１の発明を方法の発明としてクレームしたものである。すなわち、ＷＷＷサーバ（これはコンピュータ装置を用いたプログラムと解釈してもよいし所定の機能を果たす専用ハードウェアと解釈しても良い。）がＵＲＬを処理するに際して次の３の手段により機能拡張するという発明である。

第一は意図的にエラーを誘発するエラー誘発設定ステップを備えること。
第二はＷＷＷサーバが記憶部に保持したデータのうち少なくともＵＲＬパス部を利用して処理を行う文字列処理ステップを備えること。
第三は上記のエラー誘発設定ステップが原因となってエラーが発生した時にＷＷＷサーバ内部のルーチンから新たに設ける文字列処理ルーチンへと処理を分岐させる分岐処理ステップを備えること。

請求項１３の発明は、請求項１の発明を媒体の発明としてクレームしたものである。すなわち、請求項１２の発明の範疇にあるＷＷＷサーバのうちコンピュータのプログラムとして提供される「機能拡張プログラム」を記録した記録媒体である。

容易に想像可能であろうが、請求項１以外の機能拡張装置の発明についてもこれに対応する方法の発明と媒体の発明が存在する。

発明者が更に考えを推し進めたところ、エラー誘発手段は必ずしも機能拡張装置の構成要素として含まれる必要はないであろうとの知見を得たため、請求項１４としてこの発明を記述した。また、請求項１４における「既存情報処理手段」をＷＷＷサーバに限定した場合の発明を請求項１５として記述した。

この発明において「文字列」とは、文字が１以上連続したものを言う。ここで「文字」とはコンピュータ上で表現できる任意の文字を言う。別の言葉で言えば、何らかの文字コード集合（コード体系）において文字コードが一意に定まっているものである。

「文字コード集合」とは、対応するコードが一意に定められている文字の集まりもしくはその集まりに対して付けられた名称を言う。

「全角文字」とは、日本語等の文章表記用としてＪＩＳで定められた漢字、ひらがな、カタカナ等を含む文字コード集合として「ＪＩＳ Ｘ ０２０８」として定められた文字群の各文字を言う。１文字を１バイト以内（７ビットまたは８ビット）で表す文字を通称「半角文字」と呼んでいるのに対して１文字を２バイト（１６ビット）で表現するため「全角文字」と呼ばれているようである。１文字を２バイト以上で表す通称「補助漢字」（ＪＩＳ Ｘ ０２１２）や、中国、韓国、台湾で用いられている漢字等で１文字を２バイト以上で表すものを含む概念である。

文字の「集合」としては全部または大部分が同一であっても対応するコードが異なる場合がある。全角文字のうち「ＪＩＳ Ｘ ０２０８」について言えば、「ＪＩＳ」、「ＥＵＣ」、「シフトＪＩＳ」（いずれも通称または俗称。）の３種が場面に応じて用いられている。このような場合、「３種の漢字コード（漢字コード体系）が存在する」などと言う。国際標準化機構が定めた「ユニコード」（ＩＳＯ １０６４６）の漢字等の部分も一部重複する。

「文字列処理」とは、文字列を用いた情報処理のことを言う。文字列を複数の文字列に分解したり、日本語を成す文字列を英語に翻訳したり、何らかのルールに基づいてある文字列を別の文字列に置換したり、文字列の文字数のカウントするなどを例として挙げることができる。ＵＲＬに関連して言えば、ＵＲＬをＵＲＬホスト部とＵＲＬパス部とその他の部分とに分解するのは文字列処理の一例である。

この発明において「プログラムを記録した記録媒体」とは、
フレキシブルディスク、
ＣＤ−ＲＯＭ、
光磁気ディスク、
ハードディスク、
メモリカード、
ＩＣカード、
ＲＯＭ、
パンチカード、
テープ
等を含む概念である。また、コンピュータによって直接実行可能なプログラムを記録した記録媒体だけでなく、いったん他の記録媒体（ハードディスク等）にインストールすることによって実行可能となるようなプログラムを記録した記録媒体や、暗号化されたまたは圧縮されたプログラムを記録した記録媒体も含む概念である。

「ＣＧＩ処理手段」または「ＣＧＩプログラム」とは、ＷＷＷサーバ処理手段からＣＧＩ（ｃｏｍｍｏｎｇａｔｅｗａｙ ｉｎｔｅｒｆａｃｅ）なる機構により呼び出される情報処理手段のことである。とりわけ「ＣＧＩプログラム」と言った場合は、その情報処理手段がプログラムとして実装されていること示す。単に「ＣＧＩ」と言う場合もある。

「トップページ」とは、通常、ホームページの中で最初に表示されるページである（図９参照）。本来「ホームページ」とは、今日で言うホームページ（以前は「Ｗｅｂサイト」等と称していた。）の入口のページを指していたが、誤用が広がって定着したものである。ホームページには複数の文書ファイルや画像データ、あるいはＣＧＩプログラムが関連しており、それぞれのファイルは独自のアドレス（ＵＲＬ）を持つ。一般に「ホームページのアドレス（もしくはＵＲＬ）」と言った場合には「トップページ」のＵＲＬを指している。

「ＷＷＷサーバ」とは、ＷＷＷサービスのサーバ側の機能（図３参照）を提供するプログラムである。そのようなプログラムが機能するに際して必要なファイル等（図６参照）も含む概念である。そのようなプログラム（および前記必要なファイル等）がワークステーションやパソコン等のコンピュータにインストールされた装置（図１７参照）を含む概念である。ＷＷＷサーバの機能がソフトウェアまたはハードウェアとして内蔵された専用の装置も含む概念である。とりわけ、上記プログラムや装置が動作中のものをこう呼ぶ。また、ＷＷＷサーバ処理装置上で動作するプログラムに着目している場合は「ＷＷＷサーバプログラム」と言う。この発明による機能拡張を致したことによりＦｘＵＲＬの処理が可能となったＷＷＷサーバを含む概念であるが、特にこの機能拡張したＷＷＷサーバを示したい場合は「ＦｘＵＲＬ対応ＷＷＷサーバ」と言う。

「ＷＷＷクライアント」とは、ＷＷＷサービスのクライアント側の機能を提供するプログラムである。そのようなプログラムが機能するに際して必要なファイル等も含む概念である。そのようなプログラム（および前記必要なファイル等）がワークステーションやパソコン等のコンピュータにインストールされた装置を含む概念である。ＷＷＷクライアントの機能がソフトウェアまたはハードウェアとして内蔵された専用の装置も含む概念である。とりわけ、上記プログラムや装置が動作中のものをこう呼ぶ。また、ＷＷＷクライアントの画面インターフェース（図５参照）に着目している場合は「ブラウザ」と言う。

「ネットワーク」とは、広域の公開ネットワークであるインターネット、組織内のネットワークであるイントラネットならびに比較的小規模なネットワークであるＬＡＮ（ｌｏｃａｌａｒｅａ ｎｅｔｗｏｒｋ）を含む概念である。通信規約にＴＣＰ／ＩＰ（ＲＦＣで定められているインターネット用の通信規約）を用いないネットワークを含むことを妨げない。

「ディレクトリ」とは、ファイルシステム（ファイルを管理する手段またはファイルを格納した媒体のこと。）においてファイルのインデックス情報が格納された特殊な情報領域である。ＯＳによってはこの情報領域がファイルの一種として実装されている場合がある。

「ファイル」とは、データファイルとプログラムファイルと特殊ファイルの総称である。ここでデータファイルとは、テキスト（文字列、文書）情報や画像データ、音声データ等のデータを格納したファイルである。プログラムファイルは「プログラム」または「実行ファイル」とも呼ばれ、コンピュータ上で実行可能であるファイルである。特殊ファイルの代表例は前記ディレクトリである。ディレクトリ以外には、ＯＳによっては、画面やキーボードをファイルとして扱うものもある。なお、単に「ファイル」と言った場合、狭義にはデータファイルとプログラムファイルを、更に狭義にはデータファイルのみを指す。意味が不明確になりそうな場面やファイルの内容を限定したい場合は、「データファイル」、「プログラムファイル」または「ディレクトリ」と表記する。

この発明において「ＯＳ」とは、ＯＳの核である「カーネル」と呼ばれる部分に加え、「ライブラリ」と呼ばれるカーネルの周辺モジュール、「シェル」等と呼ばれる対ユーザ対話機能提供モジュールにエディタや文字列処理プログラム等のカーネルに付随するツール等と称されるファイルを含む概念である。

この発明における「資料１」の出典は、「日経コミュニケーション」（日経ＢＰ社発行）の１９９８年４月２０日号の第１１１ページである。

この発明における「資料２」の出典は、１９９８年４月１５日付け「日経産業新聞」第６面である。

図２にこの発明によるＦｘＵＲＬ対応ＷＷＷサーバを用いたＷＷＷサービスの一実施形態（実施形態１）を示す。

ＬＡＮ（２０４）に接続されたＷＷＷクライアント（２０２）はＷＷＷ中継処理手段（２０６）とインターネット（２０８）を介してＷＷＷサーバ（２１０）と通信可能な状態にある。インターネット（２０８）に接続されたＷＷＷクライアント（２０２）はインターネット（２０８）を介してＷＷＷサーバ（２１０）と通信可能な状態にある。

ＷＷＷサーバ（２１０）には既存のＷＷＷサーバとＦｘＵＲＬ対応ＷＷＷサーバとがある。機能拡張した部分以外は共通なので、機能拡張した部分以外は特に分けずに記述する。必要に応じて「既存の」または「ＦｘＵＲＬ対応」なる形容詞を前置する。よって、図２に示すＷＷＷサーバ（２１０）は、既存のＷＷＷサーバである場合とＦｘＵＲＬ対応ＷＷＷサーバである場合とがある。ただし、図２の中の少なくとも１のＷＷＷサーバ（２１０）はＦｘＵＲＬ対応ＷＷＷサーバである。

ＷＷＷサーバ（２１０）の構成要素および関連データの関係を示すブロック図６と図７に示す。図６は既存のＷＷＷサーバのものである。図７はＦｘＵＲＬ対応ＷＷＷサーバのものである。

ＷＷＷサーバは、自分自身の初期設定を行うために初期化処理部（６０８）を実行したのち、ＷＷＷクライアントからのＨＴＴＰリクエスト待ちの状態となる。この時各処理部と全体の制御を行うのが制御部（６１０）である。初期設定に際しては初期化情報保持部（６１４）に与えられた動作条件等を読み込み、そのデータを必要に応じて変数情報保持部（６１８）に格納する。この結果変数情報保持部（６１８）には、ＨＴＴＰレスポンスとしてＷＷＷクライアントに送信すべきファイル（図３Ｂ、図８参照）等を格納したファイル保持部（６２０）の所在等が格納される。

データ受信部（６０２）はＷＷＷクライアントからのＨＴＴＰリクエスト（図３Ａ参照）を文字列として取り込むためのものである。取り込んだＵＲＬ等の文字列データを必要に応じて変数情報保持部（６１８）に格納する。

制御部（１６０８）はＵＲＬおよび関連情報のデータをＵＲＬ解釈部（６０６）に渡す。ＵＲＬ解釈部（６０６）はＵＲＬパス部を取り出す等の目的で、図１８に示すＵＲＬ分解手段（１８０４）により受け取ったデータのうちＵＲＬ（１８０２）を
ＵＲＬプロトコル部（１８０６）、
ＵＲＬホスト部（１８０８）、
ＵＲＬポート部（１８１０）、
ＵＲＬパス部（１８１２）
とに分解する（図４参照）。

時としてＵＲＬパス部（１８１２）が省略されているＵＲＬがある。また、多くの場合ＵＲＬポート部（１８１０）は省略されているが、この場合はＨＴＴＰの規約に沿ってポート番号８０が仮定される。多くの場合ＵＲＬプロトコル部（１８０６）は「ｈｔｔｐ」であるが、場合によっては「ｈｔｔｐｓ」となる。これはセキュリティを強化したＨＴＴＰである。ＵＲＬプロトコル部（１８０６）が「ｆｔｐ」や「ｗａｉｓ」等となる場合があるが、この実施の形態ではこれらの扱いは言及しない。

なお、ブラウザのＵＲＬ入力表示欄（５０２）においてＵＲＬを入力する際にＵＲＬホスト部以降を入力した場合に「ｈｔｔｐ：／／」等の文字列を自動的に前置するブラウザがある。このような前置が行われた場合、この発明においては、当該文字列はブラウザの利用者が入力したものであると見做すことを妨げないものとする。

このようにして獲得したＵＲＬパス部の文字列は、ファイル保持部（６２０）にアクセスする際の情報となる。ここで「アクセス」するとは、多くの場合、
（１）特定のデータファイルの内容を読み出すことを求めるものであるか、
（２）特定のプログラムファイルを実行することを求めるものであるか
である。

特定のファイルにアクセスする際にＷＷＷサーバは、初期化処理部（６０８）により指定されて変数情報保持部に保持されている「ドキュメントルート」なる変数（以降「ＤｏｃｕｍｅｎｔＲｏｏｔ」と表記する。）と階層構造の境界を示す文字「／」とをＵＲＬパス部に前置し、実際にアクセスするファイルの所在を決定する。この様子を図１９に示す。

また、「スクリプトエイリアス」なる変数（以降「ＳｃｒｉｐｔＡｌｉａｓ」と表記する。）が変数情報保持部に保持されていれば、ＣＧＩプログラムの所在の決定に際してＳｃｒｉｐｔＡｌｉａｓの設定内容に沿った文字列の置換が行なって実際にアクセスするファイルの所在を決定する。

また、「ディレクトリインデックス」なる変数（以降「ＤｉｒｅｃｔｏｒｙＩｎｄｅｘ」と表記する。）が変数情報保持部に保持されていれば、ファイル名の自動補完を行う。この実施の形態においては
ｉｎｄｅｘ．ｈｔｍｌ
となっている。

ＵＲＬパス部の文字列が階層構造の境界を示す文字「／」で終わっている場合、ＤｉｒｅｃｔｏｒｙＩｎｄｅｘが設定されていない場合は実際にアクセスするファイルはディレクトリであると判断して当該ディレクトリの内容、すなわち、図８Ａに示すようなインデックス領域の情報自体を表示する。一方ＤｉｒｅｃｔｏｒｙＩｎｄｅｘが設定されていた場合は、変数情報保持部に保持されているファイル名を前記「／」に後置し、それを実際にアクセスするファイルの所在（これを「フルパス」と言う。（１９１０）、（１９１４）参照。）とする。

ＤｉｒｅｃｔｏｒｙＩｎｄｅｘに関する上記仕組みがあり、また、多くのＷＷＷサーバではこの設定がなされているため、通常、図１９に示すように、
ｈｔｔｐ：／／ｗｗｗ．ａｎｙ−ｄｏｍａｉｎ．ｏｒ．ｊｐ／
なるＵＲＬは
ｈｔｔｐ：／／ｗｗｗ．ａｎｙ−ｄｏｍａｉｎ．ｏｒ．ｊｐ／ｉｎｄｅｘ．ｈｔｍｌ
と同値となっている。

実際にアクセスするファイル名となる文字列（（１９１０）、（１９１４）参照。）を得たらＷＷＷサーバの制御部（６１０）は、これを変数情報保持部（６１８）に格納するほか、ファイルアクセス部（６１６）に介して目的のファイルへのアクセスを試みる。ファイルアクセス部（６１６）はファイル保持部（６２０）のインデックス領域（図８Ａ参照）にアクセスして目的のファイルが格納されている格納場所（ｐｏｓ１１、ｐｏｓ１２等）を得て、目的のファイルへのアクセスを試みる（図８Ｂ参照）。

目的のファイルがテキストデータが画像データ等のデータファイルであればこれを読み出す。目的のファイルがＣＧＩプログラムであれば（実行許可等があれば）これを実行する。

以上により得られたファイルの中身やプログラムの実行結果を、ヘッダと呼ばれる所定のデータとともにＨＴＴＰレスポンスとしてデータ送信部（６０４）を介してＷＷＷクライアントに送信する。

なお、目的のファイルへのアクセスが失敗した場合はエラーとなる。この場合は、エラー処理部（６１０）にてエラーメッセージを生成し、ヘッダとともにＨＴＴＰレスポンスとしてデータ送信部（６０４）を介してＷＷＷクライアントに送信する。多くの場合ブラウザの受信データ表示欄（５０４）には、「目的のファイルにはアクセスできません」等の主旨のエラーメッセージが表示されることになる。

以上が既存のＷＷＷサーバにおける処理の概要である。

以下では、ＦｘＵＲＬ対応ＷＷＷサーバの、この実施の形態において特徴的な事項を説明する。ＷＷＷサーバの内部構成や関連データ領域等については図７を、ＦｘＵＲＬ対応ＷＷＷサーバの処理の流れについては図１をそれぞれ参照されたい。この実施の形態のＦｘＵＲＬ対応ＷＷＷサーバでは、ＷＷＷサーバの固定的部位は何ら変更しない。

説明のおおよその流れは次のとおりである：
（１）機能拡張部の準備。
（２）エラーを誘発するデータの設定。
（３）エラー発生時の分岐に関する設定。
（４）機能拡張部等を備えたＷＷＷサーバの起動とＨＴＴＰリクエストに対する処理。

まず、機能拡張部（７０２）となる文字列処理手段を準備する。

ＵＲＬパス部を用いるものならどのような処理を行うものでも良いが、例えば、
ＵＲＬパス部の文字列をキーとして外部のデータベースを検索し、当該キーに対応するＵＲＬを成す文字列を値として得て、その値を所定のステータスコードとともにＷＷＷクライアントに送信することによりＵＲＬの転送処理をさせるような文字列処理手段；
を挙げることができる。以上で機能拡張部（７０２）の準備は終わる。機能拡張部（７０２）は、既存のＷＷＷサーバの固定的部位とも非固定的部位とも関係の無く、新規に設けるものである。

次にエラーを誘発するデータの設定を行う。

意図的にエラーを誘発するためのデータをファイル保持部（６２０）内のエラー誘発情報保持部（７０６）に設定する。具体的には、ファイル保持部（６２０）へのすべてのアクセスがすべてエラーとなるように設定する。この設定は、ＷＷＷサーバが実行時に参照するアクセスコントロールファイルなるファイル（このファイルはファイル保持部（６２０）に格納される。）を用いることにより実現できる。同様の設定は初期化情報保持部（６１４）を用いて可能であるが、この実施の形態においてはファイル保持部（６２０）に格納されるタイプのアクセスコントロールファイルをを利用する。図７のファイル保持部（６２０）はエラー誘発情報保持部（７０６）を含んだ状態を示している。

次に、エラー発生時の分岐に関する設定を行う。

前記エラー誘発情報保持部（７０６）に起因してエラーが発生した際の分岐先に関する情報を初期化情報保持部（６１４）内の分岐先情報保持部（７０４）に設定する。具体的には、前記機能拡張部（７０２）が前記分岐先となるように設定する。この設定は、ＷＷＷサーバが起動時に参照するコンフィグレーションファイルなるファイル（このファイルはファイル保持部（６２０）とは別の領域に格納される。）を用いることにより実現できる。図７の初期化情報保持部（６１４）は分岐先情報保持部（７０４）を含んだ状態を示している。

以上で準備は完了なので、次に、機能拡張部等を備えたＷＷＷサーバ（つまりＦｘＵＲＬ対応ＷＷＷサーバ）の起動を行う。

なお、この実施の形態においては条件変更部（７０８）を備えているので、必要に応じて条件変更部（７０８）を用いてエラー誘発情報保持部（７０６）や分岐先情報保持部（７０４）の内容を変えることができる。

ＷＷＷサーバを起動すると、図１に示すように、初期化処理が行われる。ＷＷＷサーバは自らの動作に必要な変数を変数情報保持部（６１８）に格納する等の処理をしたのち（ステップ（Ｓ１））、上記で設定したエラー発生時の分岐先情報を分岐先情報保持部（７０４）から取り出して変数情報保持部（６１８）に格納する（ステップ（Ｓ２））。

以降は、ＷＷＷクライアントからのＨＴＴＰリクエストを待つ状態に入る（ステップ（Ｓ３））。

実際にＷＷＷクライアントからのＨＴＴＰリクエストがあるとこのＦｘＵＲＬ対応ＷＷＷサーバは、ＷＷＷクライアントから得た情報をデータ受信部部（６０２）を介して受信し、ＵＲＬ解釈部（６０６）を用いてＵＲＬパス部等を取得し（ステップ（Ｓ４））、ＵＲＬパス部等を変数情報保持部（６１８）に格納し、変数情報保持部（６１８）に格納されたＤｏｃｕｍｅｎｔＲｏｏｔ等の情報（１９０２）等を用いてアクセス対象とするファイルを決定する（ステップ（Ｓ５））。

このようにして実際にアクセスするファイル（（１９１４）参照）が決まったらファイルアクセス部（６１６）を介してファイル保持部（６２０）にある目的のファイルへのアクセスを試みる（ステップ（Ｓ６））。しかしこのアクセスは、意図的に設定された前記エラー誘発情報保持部の内容が原因となって常に（あるいは条件変更部（７０８）を用いて変更された条件に応じて）エラーとなる（ステップ（Ｓ７））。

このためＷＷＷサーバの制御部（６１０）は制御をエラー処理部（６１２）へと移す。

するとエラー処理部（６１２）は、ステップ（Ｓ２）において設定されたエラー発生時の分岐先情報を変数情報保持部（６１８）の中の分岐先情報保持部（７０４）から取り出して、指定された分岐先へと分岐させる（ステップ（Ｓ９））。

これにより制御は機能拡張部（７０２）となっている前記文字列処理手段に移り、所望の文字列処理が実施される（ステップ（Ｓ１０））。

前記文字列処理手段の処理結果をこのＨＴＴＰリクエスト元のＷＷＷクライアントに対しＨＴＴＰレスポンスとしてデータ送信部（６０４）を介して送信すれば（ステップ（Ｓ１１））このＨＴＴＰリクエストに対する処理は終わる。

こうしてステップ（Ｓ３）に戻り、次のＨＴＴＰリクエストを待つことになる。

この実施の形態では文字列処理手段の例としてＵＲＬ転送を挙げたが、これは一例である。例えば、ＵＲＬパス部に日本語の文を書いてもらい、これを英訳し、その結果をブラウザの受信データ表示欄（５０４）、ＵＲＬ入力表示欄（５０２）、または「ステータス行」などと呼ばれているブラウザの下部領域（図示せず）に表示する；という文字列処理手段を実装することも可能である。

あるいは、ＵＲＬパス部の文字列を電子メールの宛先と（短い）本文と見做してその宛先に送信する；という文字列処理手段を実装することも可能である。

意図的にエラーを誘発する他の例として次の例を挙げることができる。なお以下では、ほぼ、この実施の形態（実施形態２）に特有な事項のみ記述する。全体の処理の流れ等は実施形態１の記述を参照されたい。

本来はａ．ｈｔｍｌからｚ．ｈｔｍｌまでの２６のファイルをＤｏｃｕｍｅｎｔＲｏｏｔ下に格納して
ｈｔｔｐ：／／ｗｗｗ．ｏｘ．ｃｏｍ／ａ．ｈｔｍｌ、
ｈｔｔｐ：／／ｗｗｗ．ｏｘ．ｃｏｍ／ｐ．ｈｔｍｌ、
ｈｔｔｐ：／／ｗｗｗ．ｏｘ．ｃｏｍ／ｚ．ｈｔｍｌ
なるＨＴＴＰリクエストに対して正常に
ａ．ｈｔｍｌ、
ｐ．ｈｔｍｌ、
ｚ．ｈｔｍｌ、
の内容を送信すべきところを、
ａ．ｈｔｍｌ〜ｃ．ｈｔｍｌ
の３のファイルを除く２３のファイル（ｄ．ｈｔｍｌ〜ｚ．ｈｔｍｌ）を意図的にＤｏｃｕｍｅｎｔＲｏｏｔ下以外のディレクトリ（例えば／ｈｔｔｐｄ／ｄｏｃ２）に格納する；という意図的なエラー誘発手段を採ることもできる。

このようにした場合、
ｄ．ｈｔｍｌ〜ｚ．ｈｔｍｌ
へのアクセスは一旦エラーとなる。この結果、この処理はエラー処理部を介して機能拡張部へと制御が移る。

これにより、例えば、
ｄ．ｈｔｍｌ〜ｚ．ｈｔｍｌ
については変数情報保持部（６１８）に格納されているＵＲＬホスト部やブラウザの種別を表す変数等を用いて、アクセス元のＷＷＷクライアントが属するドメイン名やブラウザの種別やバージョンの相違に応じて好適なドキュメントを返す；等の処理を文字列処理手段として実装することが可能である。一旦はエラーとなったこの処理は、最終的には正常終了としてＷＷＷクライアントへ必要なデータを送信することができる。

以下では、ほぼ、この実施の形態（実施形態３）に特有な事項のみ記述する。全体の処理の流れ等は実施形態１の記述を参照されたい。

意図的にエラーを誘発する他の例として、ＤｏｃｕｍｅｎｔＲｏｏｔ下に何らファイルを置かない；とする方法もある。このようにした場合、
（１）ＵＲＬパス部が「ｓａｌｅｓ．ｈｔｍｌ」というようなＴｒＵＲＬである文字列の場合も、
（２）ＵＲＬパス部が「営業のご案内．ｈｔｍｌ」というようなＦｘＵＲＬである文字列の場合も、
（３）ＵＲＬパス部が「営業案内．ｈｔｍｌ」というようなＦｘＵＲＬである文字列の場合も、
すべて
Ｆｉｌｅ Ｎｏｔ Ｆｏｕｎｄ
のようなエラーとなる。ＤｏｃｕｍｅｎｔＲｏｏｔ下に何らファイルが無いので当然である。既存のＷＷＷサーバの場合であれば、このようなＷＷＷサーバはＷＷＷクライアントに対してファイルを提供するという機能を果たさないが、ＦｘＵＲＬ対応ＷＷＷサーバは違う。制御は一旦エラー処理部（６１２）に移ったのち、更に、機能拡張部（７０２）に移る。

これにより、ＷＷＷクライアントからのファイルアクセスを伴うすべてのＨＴＴＰリクエストに対して統一した処理を行うことができ、便利である。上記の例で言えば、ＵＲＬパス部が
「ｓａｌｅｓ．ｈｔｍｌ」、
「営業のご案内．ｈｔｍｌ」または
「営業案内．ｈｔｍｌ」
のいずれであっても同一のファイルをＨＴＴＰレスポンスとして送信するなど、異なるＵＲＬの同一視等の文字列処理が容易に実現できる。

また、副次的な効果として、１のディレクトリに収容可能なファイルの数の制限を事実上撤廃することができる。

従来であれば、大量のファイル（ディレクトリを含む。）や収容したくてもＯＳのファイルシステムの仕様その他に起因する制限により１のディレクトリに収容可能なファイルを格納するのは、たとえそれが可能であった場合でも管理面で困難であった。多くのインターネットのプロバイダは会員のためにホームページ用のディレクトリを用意するが、会員数の増大に伴いその管理も大変になっていることであろう。１のコンピュータでは収容しきれないため複数のコンピュータを用いるプロバイダもある。そうすると管理はますます困難でコストの掛かるものとなる。

ところがこの実施の形態によればＷＷＷクライアント側（のＵＲＬパス部）で指定された階層構造に縛られずにファイルアクセスを伴うすべてのＨＴＴＰリクエストに対して外部の大型データベースから必要な情報を得るようなＷＷＷサーバを構築できるので、たとえば、一千万人分のホームページを統一して管理することも比較的容易に実現できる。これは、仮想的に１のディレクトリに一千万人分のホームページを置くことができることを意味している。必要であれば一千万を越える人数分のホームページを置くこともできる。事実上、収容可能なファイルの数の制限を撤廃していると言って良いであろう。

念のため従来技術との違いを補足する。上述のような処理を実現する場合、従来でも図１３Ｂのような形式（つまり実質的には図１３Ｂ２と同じ形式）であるならば実現できるかもしれないが、本発明の場合、図１３Ａのような形式で実現できる。

補足として、この実施の形態の変形として次のような形態を挙げることができる。すなわち、ＨＴＴＰリクエストのうち、ＵＲＬがＴｒＵＲＬであるものについては特別な文字列処理は不要であるとして従来どおりＤｏｃｕｍｅｎｔＲｏｏｔ以下にファイルを格納してもよい。このようにすれば、ＵＲＬがＴｒＵＲＬであるＨＴＴＰリクエストについてはＷＷＷサーバ内の本来の処理部によりすばやく処理する一方、ＵＲＬが漢字等を含むＦｘＵＲＬであるＨＴＴＰリクエストについては機能拡張部にてワイルドカードの解釈を行う等のＵＲＬの機能を高めるような処理を行うことが可能となる。

なお、条件設定部（７０８）を用いてファイル保持部（６２０）中のエラー誘発情報保持部（７０６）の内容を時間帯によって変更すれば、時間帯によってＷＷＷサーバの振る舞い（エラーを誘発する条件等）をを変更することが可能である。

図７に示した各部を備えた処理手段をＣＰＵ（１７０６）を用いた装置のハードウェア構成の一例を図１７に示す。なお、図７に示した各部分の全部または一部はＣＰＵを用いずにハードウェアロジックにより構成してもよい。

図１７において、ＣＰＵ（１７０６）には、
ネットワークインターフェース（１７０２）、
メモリ（１７０８）、
ディスプレイ（１７１０）、
キーボード（１７１２）、
ＣＤ−ＲＯＭドライブ（１７１６）、
ハードディスク（１７１８）
が接続されている。

ハードディスク（１７１８）には、ＯＳ（１７２０）、ＷＷＷサーバ装置に必須のプログラムであるｈｔｔｐｄプログラム（１７２２）、ｈｔｔｐｄプログラムが動作中に各種設定情報や変数等が格納されるｈｔｔｐｄプログラム用ワークエリア（１７２４）、ｈｔｔｐｄプログラムがＷＷＷクライアントからのＨＴＴＰリクエストに応じて随時提供する情報等を格納した公開用ファイル（１７２６）が記憶されている。これらがＷＷＷサーバの基本的要素である。

ハードディスク（１７１８）にはまた、この発明を用いたＷＷＷサーバにだけ存在する機能拡張プログラム（１７２８）と機能拡張プログラム用ワークエリア（１７３０）も記憶されている。これがＷＷＷサーバの拡張的要素である。

ＷＷＷサーバの基本的要素のうちＷＷＷサーバに特有の要素はｈｔｔｐｄプログラム（１７２２）とｈｔｔｐｄプログラム用ワークエリア（１７２４）と公開用ファイル（１７２６）であるが、これらのうちｈｔｔｐｄプログラム（１７２２）は通常、修正に際してはソースコードのコンパイルを伴う固定的部位である。ソースコードをコンパイルするには、コンパイラ自体の入手の他にソースコードの入手やハードディスク内への展開、コンパイル作業、（再）インストール作業など、大変工数の掛かる作業となる場合がある。

請求項１記載のエラー発生手段、文字列処理手段、分岐手段のうち、すくなくとも１の手段はｈｔｔｐｄプログラム（１７２２）を何ら変更することなく備えることが可能であれば請求項３を満たす。もしもこの発明を商用ＷＷＷサーバに適用可能であり、かつ、その商用ＷＷＷサーバのソースコードが提供されないのであれば、それは請求項３を満たすことになる。ソースコードの公開が一般的である「フリーソフト」と呼ばれる類のプログラムであっても、そのプログラムのソースコードを再コンパイルすること無しにこの発明が適用可能であるならば、それは請求項３を満たすことになる。

ハードディスク（１７１８）に記憶されている各要素は、
（１）ＣＤ−ＲＯＭドライブ（１７１６）を介してＣＤ−ＲＯＭ（１７１４）によりインストールされたか、
（２）ネットワークインターフェース（１７０２）を介してネットワーク（１７０４）上にあるＷＷＷサーバまたはＦＴＰサーバ（いずれも図示せず）からインストールされたものである。

ＷＷＷサーバのデータ受信部（１６０２）はネットワークインターフェース（１７０２）とＯＳ（１７２０）を介してＷＷＷクライアントから送られて来るＨＴＴＰリクエストを受信する。

ＷＷＷサーバのデータ送信部（１６０４）はＯＳ（１７２０）とネットワークインターフェース（１７０２）を介してＨＴＴＰリクエストに対する応答となるデータ（ＨＴＴＰレスポンス）をＷＷＷクライアントに対して送信する。

ＷＷＷサーバのＵＲＬ解釈部（６０６）は、ＵＲＬを分解する際にＣＰＵにて演算を実行する他、ＵＲＬ分解処理の結果得られるＵＲＬパス部の文字列のデータをハードディスク（１７１８）内のｈｔｔｐｄプログラム用ワークエリア（１７２４）における変数としてまたはメモリ（１７０８）内におけるデータとして記憶または一時記憶させる。

ＷＷＷサーバの初期化処理部（６０８）が参照する初期化情報保持部（６１４）はｈｔｔｐｄプログラム（１７２２）の初期化ファイル（別称：コンフィグレーションファイル）として実現される。このファイルはハードディスク（１７１８）内のｈｔｔｐｄプログラム用ワークエリア（１７２４）に記憶される。

初期化ファイルの修正に際しては、このＷＷＷサーバについての権限ある操作者（図示せず）がＯＳ（１７２０）の一部として備えられているエディタ（テキストファイル編集プログラム）等を用いて初期化ファイルの内容をディスプレイ（１７１０）に表示させつつキーボード（１７１２）を用いてキー入力を行って当該ファイルの内容の書き換えを行うことができる。

なお、ディスプレイ（１７１０）やキーボード（１７１２）を用いずに、ネットワークインターフェース（１７０２）を介してネットワーク（１７０４）に接続されている他のコンピュータからファイル転送等の手段によっても初期化ファイルの内容の書き換えは可能である。

ＷＷＷクライアントからのＨＴＴＰリクエストに応じて送信するＨＴＭＬファイル（テキストファイル）やＧＩＦファイル（画像データ）等のファイルはＤｏｃｕｍｅｎｔＲｏｏｔ下に置かれ、ＣＧＩプログラムは通常ＳｃｒｉｐｔＡｌｉａｓ下またはＤｏｃｕｍｅｎｔＲｏｏｔ下に置かれる。これらはいずれも、図７においてはファイル保持部（６２０）に、図１７においては公開用ファイル（１７２６）に含まれる。ＣＧＩプログラムの一部または全部は（１７２６）の外に置かれる場合もある。

ＷＷＷサーバが通常の動作に必要な要素の説明は以上のとおりである。

加えてこの発明を実施するＷＷＷサーバのある実施の形態では、意図的にエラーを誘発するためのエラー誘発情報保持部（７０６）がファイル保持部（６２０）の一部としてファイルの形で挿入されている。このファイルはアクセスコントロールファイル等と呼ばれている。図１７でいえば、公開用ファイル（１７２６）の一部として記憶されていることになる。

この発明を実施するＷＷＷサーバの別の実施の形態では、エラー誘発情報保持部（７０６）は初期化情報保持部（６１４）に挿入されている。この場合、図１７でいえば、ｈｔｔｐｄプログラム用ワークエリア（１７２４）に記憶されていることになる。

加えてこの発明を実施するＷＷＷサーバでは、エラー発生時の分岐先を決定するための情報を分岐先情報保持部（７０４）を備えるが、この情報の素となるデータ片は初期化情報保持部（６１４）に挿入されていることとし、初期化処理部（６０８）の処理により変数情報保持部（６１８）に記憶されることとする。この場合分岐先情報の素となるデータ片は初期化ファイル中に存在するので、図１７でいえばｈｔｔｐｄプログラム用ワークエリア（１７２４）に記憶されていることになる。

もっとも、請求項３を満たさなくてもよいのであれば、ｈｔｔｐｄプログラム（１７２２）のソースコードを修正してｈｔｔｐｄプログラム（１７２２）の内部に分岐先情報保持部（１６１４）に保持すべきデータを置くこともできるし、後述する機能拡張プログラム（１７２８）で実現可能な機能をｈｔｔｐｄプログラム（１７２２）内に取り込むこともできる。

加えてこの発明を実施するＷＷＷサーバでは、ＷＷＷサーバの機能を拡張するための機能拡張部（６１２）を備える。機能拡張部（６１２）は、機能拡張プログラム（１７２８）と機能拡張プログラム用ワークエリア（１７３０）としてハードディスク（１７１８）内に記憶されている。

加えてこの発明を実施するＷＷＷサーバのうち請求項２を満たすものは、分岐先情報保持部（７０４）の内容を変更するための手段として条件変更部（７０８）を備える。条件変更部（７０８）は前記アクセスコントロールファイルまたは同等機能を提供するファイル等における分岐先情報保持部（７０４）またはこれに相当する箇所を修正するためのものである。

上記実施形態ではＣＤ−ＲＯＭ ドライブ（１７１６）、ディスプレイ（１７１０）およびキーボード（１７１２）を用いたが、ハードディスク（１７１８）内へのファイルのインストール、ハードディスク（１７１８）内のファイルの書き換え等の作業、ｈｔｔｐｄプログラム（１７２２）やＷＷＷサーバ全体の監視・管理等のすべての作業をネットワークインターフェース（１７０２）を介してネットワーク（１７０４）に接続可能な他のコンピュータ（図示せず）から遠隔処理（リモート処理）するのであれば、ＣＤ−ＲＯＭ ドライブ（１７１６）、ディスプレイ（１７１０）およびキーボード（１７１２）は備える必要はない。

発明の効果

これまでに説明から明らかなように、ＷＷＷサーバにおけるＵＲＬの解釈を柔軟に行うことによりＵＲＬの表現力や利用価値を大幅に高めることができる。同時に、インターネットのサービスを利用する際の障壁を下げる効果もある。これらの相乗効果により現在のインターネット利用者にも将来のインターネット利用者にもメリットをもたらすサービスが提供可能である。また、ＷＷＷサーバ以外にも応用可能であるため多分野に渡り効果を得ることができる。

この発明の一実施形態による機能拡張手段等を備えたＷＷＷサーバの処理の流れを示す図である。 ＷＷＷサービスの一般的な利用形態を示す図である。 ＷＷＷサービスにおけるクライアントとサーバ間でのやり取りを単純化した図である。 ＵＲＬの構成要素を説明した図である。 ブラウザの画面インターフェースを単純化した図である。 既存のＷＷＷサーバの構成要素と関連データを示すブロック図である。 この発明の一実施形態による機能拡張手段等を備えたＷＷＷサーバの構成要素を示すブロック図である。 ファイルシステムにおけるインデックス領域とファイル領域との関連を示した図である。 ○×商会のホームページのＵＲＬ（ＵＲＬは通常のＴｒＵＲＬである。）と内容を示す図である。 ○×商会のホームページのＵＲＬ（ＵＲＬは漢字等を含んだＫＵＲＬである。）と内容を示す図である。 ＵＲＬの表記における各ＡＳＣＩＩ文字について利用の適不適を示す図である。 末尾に記号「？」を含むＵＲＬの例を示す図である。 ＵＲＬ中の記号「？」の有無とＵＲＬの表現能力との関係を示すための図である。 この発明により可能になるＵＲＬ表現の例を利用可能な文字種の豊富さに力点を置いて示した図である。 この発明により可能になるＵＲＬ表現の例を検索機能に力点を置いて示した図である。 この発明により可能になるＵＲＬ表現の例を日常の文章表現が可能な点に力点を置いて示した図である。 この発明の一実施形態による機能拡張手段等を備えたＷＷＷサーバ処理装置の構成要素を示す図である。 与えられたＵＲＬをＵＲＬパス部など４つの部分に分解するＵＲＬ分解手段の機能を示す図である。 ＷＷＷサーバの初期設定ファイルの内容とＷＷＷクライアントから得たＵＲＬパス部とがどのように作用して実際のアクセス対象ファイルを決定するのかを示す図である。

符号の説明

（Ｓ１）初期化処理ステップ（一般的な設定）
（Ｓ２）初期化処理ステップ（この発明に特有な事項）
（Ｓ３）ＨＴＴＰリクエスト受信判断ステップ
（Ｓ４）ＵＲＬパス部獲得ステップ
（Ｓ５）アクセス対象ファイル決定ステップ
（Ｓ６）アクセス対象ファイルへのアクセスステップ
（Ｓ７）エラー発生ステップ
（Ｓ８）エラー処理ステップ
（Ｓ９）文字列処理ステップへの分岐ステップ
（Ｓ１０）文字列処理ステップ
（Ｓ１１）ＨＴＴＰレスポンス送信ステップ
（２０２）ＷＷＷクライアント
（２０４）小規模ネットワーク（ＬＡＮ、イントラネット等）
（２０６）ＷＷＷ中継処理装置
（２０８）広域ネットワーク（インターネット等）
（２１０）ＷＷＷサーバ
（５０２）ブラウザのＵＲＬ入力表示欄
（５０４）ブラウザの受信データ表示欄
（６０２）ＷＷＷサーバのデータ受信部
（６０４）ＷＷＷサーバのデータ送信部
（６０６）ＷＷＷサーバのＵＲＬ解釈部
（６０８）ＷＷＷサーバの初期化処理部
（６１０）ＷＷＷサーバの制御部
（６１２）ＷＷＷサーバのエラー処理部
（６１４）ＷＷＷサーバの初期化情報保持部
（６１６）ＷＷＷサーバのファイルアクセス部
（６１８）ＷＷＷサーバの変数情報保持部
（６２０）ＷＷＷサーバのファイル保持部
（７０２）ＷＷＷサーバ用の機能拡張部（この発明による新規部分）
（７０４）ＷＷＷサーバ用の分岐先情報保持部（この発明による新規部分）
（７０６）ＷＷＷサーバ用のエラー誘発情報保持部（この発明による新規部分）
（７０８）ＷＷＷサーバ用の条件変更部（この発明による新規部分）
（９０１）○×商会のトップページ（ＵＲＬは従来のＴｒＵＲＬ）のＵＲＬ入力表示欄
（９０２）○×商会のトップページ（ＵＲＬは従来のＴｒＵＲＬ）
（９０４）○×商会のトップページ（ＵＲＬは従来のＴｒＵＲＬ）における営業部のページへのリンク部
（９０６）○×商会のトップページ（ＵＲＬは従来のＴｒＵＲＬ）における技術部のページへのリンク部
（９０７）○×商会の営業部のページ（ＵＲＬは従来のＴｒＵＲＬ）のＵＲＬ入力表示欄
（９０８）○×商会の営業部のページ（ＵＲＬは従来のＴｒＵＲＬ）
（９０９）○×商会の技術部のページ（ＵＲＬは従来のＴｒＵＲＬ）のＵＲＬ入力表示欄
（９１０）○×商会の技術部のページ（ＵＲＬは従来のＴｒＵＲＬ）
（１００１）○×商会のトップページ（ＵＲＬは漢字等を含むＫＵＲＬ）のＵＲＬ入力表示欄
（１００２）○×商会のトップページ（ＵＲＬは漢字等を含むＫＵＲＬ）
（１００４）○×商会のトップページ（ＵＲＬは漢字等を含むＫＵＲＬ）における営業部のページへのリンク部
（１００６）○×商会のトップページ（ＵＲＬは漢字等を含むＫＵＲＬ）における技術部のページへのリンク部
（１００７）○×商会の営業部のページ（ＵＲＬは漢字等を含むＫＵＲＬ）のＵＲＬ入力表示欄
（１００８）○×商会の営業部のページ（ＵＲＬは漢字等を含むＫＵＲＬ）
（１００９）○×商会の技術部のページ（ＵＲＬは漢字等を含むＫＵＲＬ）のＵＲＬ入力表示欄
（１０１０）○×商会の技術部のページ（ＵＲＬは漢字等を含むＫＵＲＬ）
（１１０２）非図形文字一覧
（１１０４）Ｕｎｓａｆｅな文字一覧
（１１０６）Ｒｅｓｅｒｖｅｄな文字一覧
（１１０８）制約無く使用可能な文字一覧
（１７０２）ＷＷＷサーバ処理装置のネットワークインターフェース
（１７０４）ネットワーク
（１７０６）ＷＷＷサーバ処理装置のＣＰＵ（中央演算処理装置）
（１７０８）ＷＷＷサーバ処理装置のメモリ
（１７１０）ＷＷＷサーバ処理装置のディスプレイ
（１７１２）ＷＷＷサーバ処理装置のキーボード
（１７１４）ＷＷＷサーバプログラムを記録したＣＤ−ＲＯＭ
（１７１６）ＷＷＷサーバ処理装置のＣＤ−ＲＯＭドライブ
（１７１８）ＷＷＷサーバ処理装置のハードディスク
（１７２０）ハードディスク内のＯＳ
（１７２２）ハードディスク内のｈｔｔｐｄプログラム
（１７２４）ハードディスク内のｈｔｔｐｄプログラム用ワークエリア
（１７２６）ハードディスク内の公開用ファイル
（１７２８）ハードディスク内の機能拡張プログラム
（１７３０）ハードディスク内の機能拡張プログラム用ワークエリア
（１８０２）分解前のＵＲＬ
（１８０４）ＵＲＬ分解手段
（１８０６）ＵＲＬ分解手段により分解されたＵＲＬプロトコル部
（１８０８）ＵＲＬ分解手段により分解されたＵＲＬホスト部
（１８１０）ＵＲＬ分解手段により分解されたＵＲＬポート部
（１８１２）ＵＲＬ分解手段により分解されたＵＲＬパス部
（１９０２）変数保持部のデータの一部（アクセス対象ファイル決定関連）
（１９０６）ＷＷＷクライアントからのＵＲＬパス部の文字列
（１９０８）アクセス対象決定手段
（１９１０）アクセス対象ファイルを指す文字列（フルパス）
（１９１２）ＵＲＬパス部（（１９０６）の例）
（１９１４）実際にアクセスするファイル（（１９１２）の例に対応）

Claims (15)

1. 既存ＷＷＷサーバがＵＲＬを処理するに際して意図的にエラーを誘発するエラー誘発手段と、前記既存ＷＷＷサーバが記憶手段に保持するデータのうち少なくともＵＲＬパス部を利用して処理を行う文字列処理手段と、前記エラー誘発手段によりエラーが発生した時に前記既存ＷＷＷサーバから前記文字列処理手段へと処理を分岐させる分岐手段とを備える機能拡張装置。
2. 既存ＷＷＷサーバがＵＲＬを処理するに際して意図的にエラーを誘発するエラー誘発手段と、前記既存ＷＷＷサーバが記憶手段に保持するデータのうち少なくともＵＲＬパス部を利用して処理を行う文字列処理手段と、前記エラー誘発手段によりエラーが発生した時に前記既存ＷＷＷサーバから前記文字列処理手段へと処理を分岐させる分岐手段とを備える機能拡張装置であって、前記エラー誘発手段により発生するエラーの程度またはタイミング等を変更するための条件変更手段を備える機能拡張装置。
3. 前記エラー誘発手段、前記文字列処理手段、ならびに前記分岐手段のうちの１または２以上の手段を、前記既存ＷＷＷサーバの固定的部位を何ら変更することなく備える請求項１または請求項２記載の機能拡張装置。
4. 前記ＵＲＬパス部を含むＵＲＬは、ＷＷＷクライアントのＵＲＬ入力表示欄で入力されたクライアント側入力文字列に由来し、前記文字列処理手段はＷＷＷサーバに対してどのような形式をもっても伝達されない箇所以外は前記クライアント側入力文字列が入力された形式の表記にて獲得する獲得手段を備える請求項１または請求項２記載の機能拡張装置。
5. 前記ＵＲＬパス部を含むＵＲＬは、ＷＷＷクライアントのＵＲＬ入力表示欄で入力する以外の方法で入力されたまたは設定されたクライアント側入力文字列に由来し、前記文字列処理手段はＷＷＷサーバに対してどのような形式をもっても伝達されない箇所以外は前記クライアント側入力文字列が入力された形式の表記にて獲得する獲得手段を備える請求項１または請求項２記載の機能拡張装置。
6. 前記ＵＲＬパス部は漢字、ひらがなまたはカタカナを含み、ＣＧＩプログラム等へのパラメータ伝達を指示するものであるとＲＦＣにより定義された文字列をその定義の通りに用いる用途では含まない請求項４または請求項５記載の機能拡張装置。
7. 前記ＵＲＬパス部は
   （１）日本語や他の国または地域の言語の語句を含むか、
   （２）特定の学術分野等で用いられている記号類を用いた表記を含むか、または、
   （３）コンピュータ言語の命令やデータを含むか
   のいずれかあるいはそれらの２以上の組合せである請求項４または請求項５記載の機能拡張装置。
8. 前記ＵＲＬパス部は検索を指示する文字列が含まれている請求項４または請求項５記載の機能拡張装置。
9. 前記文字列処理手段は、
   （１）ＲＦＣにより特別の意味が設定されている文字列のうちの少なくとも１についてこれを本来の文字そのままのデータとして処理する特別文字列普通解釈手段か、または、
   （２）予め定義されたまたは随時定義する文字列をＲＦＣにより特別の意味が設定されている文字列と同等に処理する普通文字列特別解釈手段
   のうちの少なくとも一方を備える請求項４または請求項５記載の機能拡張装置。
10. 既存情報処理手段が情報処理するに際して意図的にエラーを誘発するエラー誘発手段処理ステップと、前記既存情報処理手段における情報処理結果の一部または全部を利用して前記既存情報処理手段の外で処理を行う外部情報処理手段と、前記エラー誘発手段によりエラーが発生した時に前記既存情報処理手段から外部情報処理手段へと処理を分岐させる分岐手段とを備える機能拡張装置。
11. 前記エラー誘発手段により発生するエラーの程度またはタイミング等を変更するための条件変更手段を備えている請求項１０記載の機能拡張装置。
12. 既存ＷＷＷサーバがＵＲＬを処理するに際して意図的にエラーを誘発するエラー誘発設定ステップと、前記既存ＷＷＷサーバが記憶部に保持するデータのうち少なくともＵＲＬパス部を利用して処理を行う文字列処理ステップと、前記エラー誘発設定ステップによりエラーが発生した時に前記既存ＷＷＷサーバから前記文字列処理ステップへと処理を分岐させる分岐処理ステップとを備える機能拡張方法。
13. 既存ＷＷＷサーバがＵＲＬを処理するに際して意図的にエラーを誘発するエラー誘発設定ステップと、前記既存ＷＷＷサーバが記憶部に保持するデータのうち少なくともＵＲＬパス部を利用して処理を行う文字列処理ステップと、前記エラー誘発設定ステップによりエラーが発生した時に前記既存ＷＷＷサーバから前記文字列処理ステップへと処理を分岐させる分岐処理ステップとを備える機能拡張プログラムを記録した記録媒体。
14. 既存情報処理手段が情報処理するに際して前記既存情報処理手段における情報処理結果の一部または全部を利用して前記既存情報処理手段の外で処理を行う外部情報処理手段と、エラーが発生した時に前記既存情報処理手段から外部情報処理手段へと処理を分岐させる分岐手段とを備える機能拡張装置。
15. 既存ＷＷＷサーバがＵＲＬを処理するに際して前記既存ＷＷＷサーバが記憶手段に保持するデータの一部または全部を利用して処理を行う文字列処理手段と、エラーが発生した時に前記既存ＷＷＷサーバから前記文字列処理手段へと処理を分岐させる分岐手段とを備える機能拡張装置。

Images