JP2000020444A

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

Info

Publication number: JP2000020444A
Application number: JP10195108A
Authority: JP
Inventors: Takeshi Hayashi; 毅林
Original assignee: BARIAFURII KK
Current assignee: BARIAFURII KK
Priority date: 1998-06-26
Filing date: 1998-06-26
Publication date: 2000-01-21
Also published as: WO2000000897A1; EP1143340A1; EP1143340A4

Abstract

(57)【要約】【課題】 HTTPやURLの規約に準拠したこれまでのURLで
はURLパス部に漢字等の全角文字を含むことができなか
った。ASCII文字についても利用上の制約があった。そ
のため、漢字、ひらがら、カタカナ、記号等を含むURL
を用いたくてもできなかったもしくは困難であった。多
大な工数を掛けずにこれを実現することを課題とする。
当該技術のWWWサーバ以外への広範囲な応用についても
併せて課題とする。【効果】 URLに漢字等を含むことを可能にすることに
より。URLの告知手段としての価値を大幅に向上させる
ことができる。インターネット利用者の増大等も見込む
ことができ、産業の発展に寄与する。【解決手段】従来のWWWサーバに、意図的にエラーを
発生させるエラー誘発手段や文字列処理手段等を備えた
機能拡張装置を備えることにより、任意の図形文字をUR
Lパス部に含むことが可能になる。

Description

【発明の詳細な説明】

【０００１】

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

【０００２】

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

【０００３】WWWサービスを実施する際にWWWサーバ（２
１０）およびWWWクライアント（２０２）の両者は、イ
ンターネットにおける通信サービスの標準等を定めたRF
C (request for comments)なる文書集においてHTTP (hy
per text transfer protocol)として定められた通信規
約に従ってサービスを実施する。

【０００４】図３Ａは、WWWサーバ（２１０）とWWWクラ
イアント（２０２）との間でやり取りされる通信処理を
簡単に示したものである。基本的には、(1)WWWクライア
ント（２０２）がWWWサーバ（２１０）に対してHTTPリ
クエスト（HTTPに基づく資源アクセス要求）を出し、
(2)WWWサーバ（２１０）がその応答（HTTPレスポンス）
として所定の資源をWWWクライアント（２０２）に返
す；というものである。WWWクライアントがアクセスを
所望するWWWサーバ上の資源等を表す方法として図４に
示すURL (uniform resource locators)が用いられる。U
RLもまたRFCの１つとして定められた規約である。

【０００５】図３Ｂは、WWWクライアント（２０２）がW
WWサーバ（２１０）に対してHTML (hyper text markup
language)ファイルをアクセスしている様子を示したも
のである。上述したように(1)WWWクライアント（２０
２）はWWWサーバ（２１０）に対してHTTPに従いファイ
ル名「index.html」をURLパス部（図４Ａ参照）に含ん
で送信要求を行い、(2)WWWサーバ（２１０）がその応答
としてindex.htmlをWWWクライアント（２０２）に送信
している。なおHTTPでは、ファイルの送信要求以外にも
プログラムの実行要求や動作確認等が指定可能である。

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

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

【０００８】(2)前記HTTPリクエストを受けてWWWサーバ
（２１０）は、URLその他の情報を適宜処理する。URLパ
ス部は直接的または間接的にアクセス対象となるファイ
ルの所在を示している（図１９参照）。WWWサーバ（２
１０）はURLパス部の内容に従ってWWWサーバ（２１０）
内のファイルアクセス部（６１６）を用いてWWWサーバ
（２１０）内のファイル保持部（６２０）から所定のフ
ァイルを読み出す。ファイル保持部（６２０）の内部構
造は図８のようになっており、ファイルが記憶されてい
る。なお、この図においてはaccess.cgi、index.html、
sales.html、takaoka.txt、tanaka.txt、tech.html、の
６のファイルが例として示されている。必要に応じて他
のファイルが配置されたり消去される等の処理が行われ
る。

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

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

【００１１】図９に示すのは「○×商会」（仮名。○×
商会に対応するドメイン名は「ox.com」とする。）のホ
ームページの例である。

【００１２】トップページの画面（９０２）は、（９０
２）に示すようにブラウザのURL入力表示欄（５０２）
に対して http://www.ox.com/index.html と入力してアクセスを実施した結果、WWWサーバ（２１
０）のファイル保持部（６２０）内に存在するファイル
「index.html」（図８参照）がHTMLの表示規約に則って
ブラウザの受信データ表示欄（５０４）に表示されてい
る様子である。

【００１３】トップページに対応しているファイル index.html の中には○×商会の営業部と技術部の両ページへのリン
ク情報が記述されている。営業部のページへのリンク部
分（９０４）をマウスでクリックする等した場合は営業
部のページ画面（９０８）が、技術部のページへのリン
ク部分（９０６）をマウスでクリックする等した場合は
技術部のページ画面（９１０）がそれぞれ表示される。
上記２のページのURLはそれぞれ http://www.ox.com/sales.html、 http://www.ox.com/tech.html である。

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

【００１５】

【発明が解決しようとする課題】しかしながら、HTTPや
URLの規約に準拠したこれまでのURL（このようなURLを
以降、「TrURL」（Traditional URL）と言う。）ではUR
Lパス部に漢字等の全角文字を含むことができなかっ
た。そのため、本当は○×商会が図９のURL入力表示欄
（９０１）に示す表現方法に代えて図１０のURL入力表
示欄（１００１）、（１００７）、（１００９）に示す
ような漢字、ひらがら、カタカナを含むURL（このよう
なURLを以降、「KURL」（Kanji URL）と言う。）を用い
たくてもできなかった（またはできないと考えられてい
た）。

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

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

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

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

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

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

【００２２】TrURLには漢字等の全角文字以外にも表記
上の制限がある。まず、TrURLで使用可能な文字コード
集合は最大でも７ビットの文字コード集合であるASCII
コードだけである。上述した全角文字を含め、２バイト
以上の領域を用いる日本語、韓国語、中国語等用の多バ
イトのコード体系は使えない。ヨーロッパを中心に用い
られている「ISO 8859-1」なるコード体系をはじめとす
る８ビット（１バイト）の文字コード集合も使えない。

【００２３】TrURLには更に制限がある。ASCII文字コー
ド集合のうち利用者側の意志で自由に使えない文字（コ
ード）が複数存在する。具体的には、 (1)「非図形文字」である文字群（１１０２）、 (2)「Unsafe」である文字群（１１０４） (3)「Reserved」である文字群（１１０６）がある。正確な意味はURLに関するRFCを参照されたい。
以下では例を用いて説明する。

【００２４】(1)の「非図形文字」とは紙に印刷できな
い特殊な文字（キャラクタ）のことである。この用法で
言うところの「図形」とは「a」や「=」などの表示可能
な文字のことであり、算数や数学で慣用するところの円
や三角形等の「図形」とは意味合いが異なるので注意さ
れたい。非図形文字の一例としては、ベル音（C言語の1
6進数表現で「0x07」というコードが割り当てられてい
るもの。）を発生される等の制御キャラクタ（機能キャ
ラクタとも呼ばれる。）がある。これらは特定の機能を
示す「文字」であるが、それらは「a」という文字とは
違い印刷して表記することはできないので、「URL」を
成す文字列としてそのまま「表記する」ということはで
きない。対策としてRFCでは、所定の方法によりエンコ
ードして表記する手段を提供している。前記「ベル音」
であれば「%07」と表記することになっている。

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

【００２６】(3)の「『Reserved』である」とは「予約
済みの」という意味である。特定の意味に用いるものと
して規約上予約されたものである。具体的には、URLホ
スト部とURLパス部とを分離したり（ディレクトリ等
の）階層構造を表現するための「/」を例として挙げる
ことができる。URLパス部における「dir1/dir2/file」
という表記は、「dir1」なる構造（ディレクトリ）の下
位にある「dir2」なるディレクトリの下位にある「fil
e」なるファイルを示している。同様に「3/4」という表
記は、「3」なるディレクトリの下位にある「4」なるフ
ァイルを示している。

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

【００２８】例えば図１２Ａに示す英文の疑問文風のUR
Lは、RFCの規約上は図１２Ｂに示すURLと意味や処理結
果は変わらない。つまり、URLとしては図１２Ａは図１
２Ｂと等価であり、図１２Ａにおける「?」は英文の疑
問符として価値すなわち文字または符号としての価値を
持っていない。

【００２９】また、図１２Ｃのようにごくふつうの英文
表記「How much?」をそのままURLパス部に含ませること
もできないもしくは望ましくない。なぜなら、「How」
と「much」との間にある空白文字（16進数表現で0x20）
と末尾の「?」はいずれも「Unsafe」な文字であるから
である。これは大変不自由なことである。とりわけURL
の表示を広告手段と考えた場合、表現能力の自由度の低
さは障害となる。

【００３０】「非図形文字」である文字群（１１０
２）、「Unsafe」である文字群（１１０４）または「Re
served」である文字群（１１０６）や、ヨーロッパ特有
の文字や漢字等の全角文字を含む８ビットまたは１６ビ
ット（またはそれ以上）の文字コード集合の利用につい
て少しでも制限が解除されたURL（このようなURLを以
降、「FxURL」（Flexible URL）と言う。FxURLは前記KU
RLを含む概念である。）があれば表現能力の自由度は向
上するので好ましい。

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

【００３２】

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

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

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

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

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

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

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

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

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

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

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

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

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

【００４５】これにより、WWWクライアント（２０２）
のURL入力表示欄（５０２）に漢字等の全角文字や前記
「Unsafe」な文字を含む文字列がURLとしてブラウザのU
RL入力表示欄（５０２）に入力された場合、すなわち、
前記FxURLがブラウザのURL入力表示欄（５０２）に入力
された場合でも、(1)両WWW処理手段（（２０２）と（２
１０）のこと。）が採用する漢字コード体系の相違、
(2)２以上のWWWクライアント（２０２）間のエンコード
処理方法の相違、または(3)WWWクライアント（２０２）
におけるエンコード実施の有無の相違によらず、前記文
字列処理手段はWWWサーバが備える記憶手段の情報を利
用しつつWWWクライアント（２０２）のURL入力表示欄
（５０２）に入力した時の表示通りの文字列１を文字列
２として得ることができる。

【００４６】ただし、URL入力表示欄（５０２）に（エ
ンコードしないままの）「#」そのものを含む http://www.ox.com/index.html#sales というような文字列を入力した場合、その「#」以降の
文字列（「#sales」）は通常はWWWサーバ側（WWWサーバ
またはWWW中継処理手段）には伝達されないため、その
「#」以降の文字列をWWWサーバで再現することはできな
い、つまり文字列１と文字列２が同一にはならない；と
している。「#」以降の文字列がWWWサーバ側には伝達さ
れるのであれば、文字列１と文字列２は同一にすること
ができる。

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

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

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

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

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

【００５２】請求項５の機能拡張装置はそうではなく、
(1)手動でURLを入力するもののブラウザほど良好な（ま
たは専用の）GUIやCUIを持たないプログラムまたは(2)
所望のURLを自動で生成して自動でWWWサーバへと送信す
るプログラム等が利用されることを想定している。

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

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

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

【００５６】請求項６の機能拡張装置は、(1)URLパス部
に漢字、ひらがなまたはカタカナが含まれており、か
つ、(2)CGIプログラム等へのパラメータ伝達を指示する
とRFCにて定義された文字列（現バージョンのRFCにおい
ては「?」）をRFCの定義通りに用いる用途では含まない
こと；を特徴としている。逆に言えば、漢字等を含むUR
Lパス部においてCGIプログラム等へのパラメータ伝達の
ために「?」が使われている場合、すなわち、URLパス部
がRFCに記載されているURLの通常の表示様式に準拠した
文字列である場合、そのURLが処理可能であることはこ
の発明の範囲ではない；ということである。一例を挙げ
れば、URLパス部が「?イロハ」あるいは「index.cgi?イ
ロハ」なる文字列である場合URLについてそのURLが処理
可能であることはこの請求項における発明の範囲ではな
い。

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

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

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

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

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

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

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

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

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

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

【００６７】ここまで考えを発展させると、上述のよう
にURLパス部に画像データ等を含むURL（以下、このよう
なURLをビジュアルURL、略して「VURL」と言う。）はRF
Cで定義されたURLの範疇を越えてしまうように思える。
しかしながら、例えば、点字や画像データをRFCで定義
されているMIME (multipurpose internet mail extensi
ons)という規格のBASE64形式にてエンコードするという
規約をVURLをやり取りする双方が合意すれば、点字や画
像データをURLパス名部に表現することが可能となる。

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

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

【００７０】なお、VURLの画像データ部分をBASE64でエ
ンコードした場合、画像データは「a」〜「z」、「A」
〜「Z」、「0」、「1」〜「9」、「+」、「/」、「=」
の合計65種類の文字の組合せで表現されることになる
が、FxURLならば文字「/」を始め65すべての文字につい
て何ら制約を受けずにURLパス部に記述可能である。

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

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

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

【００７４】請求項７の機能拡張装置はまた、URLパス
部に暗号化されたデータを含むこともできる。データを
暗号化してこれを文字列として出力した場合、その文字
列は通常にASCII文字コード集合の図形文字を用いるこ
とになるが、FxURLにはTrURLのような「Unsafe」または
「Reserved」となっている文字種は無いので、特別なエ
ンコード処理をすること無く暗号化されたデータをURL
パス部に置くことができる。図１４Ｋに例を示す。「en
crypted/」以降に示すのは、あるデータを（コンピュー
タ業界において）「DES」と呼ばれている暗号方式によ
り暗号化した文字列である。これはあくまでも一例であ
り、暗号化方式は任意である。

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

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

【００７７】図１５Ｂはワイルドカードを用いた例であ
る。WWWサーバはファイル保持部（６２０）のディレク
トリ領域（図８Ａ参照）を検索して、「a」で始まり
「z.html」で終わるファイル名（例：「abcdz.html」、
「aあいうz.html」、「a+-=z.html」）を持つファイル
を探し出す。図１５Ａもワイルドカードを用いた例であ
り、「a」で始まり「z.html」で終わる８文字のファイ
ル名（例：「abz.html」、「a-z.html」、「a.z.htm
l」）を持つファイルを探し出す。該当するファイルが
２以上ある場合は、(1)最初のファイルを検索結果とし
たり(2)検索結果を順にすべて処理する等のルールを別
途定めて実施することになろう。また、上記の例におい
て全角を文字を含むファイル名を検索の対象にすべきか
否か等については別途ルールが必要であろう。

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

【００７９】図１５Ｄは、WWWサーバ処理手段の外部に
あるデータベース（この例では当該データベースの識別
子は「names.jp」としている。日本の人名データベース
の意に解釈されたい。）から名前の最初が「田中」であ
る人物を探し出すよう指示している；と解釈できる例で
ある。

【００８０】同様に図１５Ｅは、データベース「names.
jp」から名前の末尾が「子」である人物を探し出すよう
指示している；と解釈できる例である。

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

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

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

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

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

【００８６】その第１の手段である「特別文字列普通解
釈手段」により、HTTPの規約により特別な意味が与えら
れている「?」や「/」等の「Unsafe」である文字群（１
１０４）や「Reserved」である文字群（１１０６）の文
字についてその文字本来の用途に用いることが可能とな
る。

【００８７】これにより、「4分の3」という分数をURL
パス部に表記できる（図１６Ａ参照）。通常ならば図１
６Ａは、＜「answer=3」という名称のディレクトリの下
にある「4=0.75」という名称のファイルを指示するもの
＞と解釈すべきURLである。なぜなら、URLの様式を定め
たRFCにより「/」は階層構造の境界を示すとされている
からである。TrURLではこのような解釈になるが、FxURL
では必ずしもこのように解釈しなくてもよい。このよう
に請求項９の機能拡張装置は、「/」を階層構造の境界
を示す記号以外の意味に用いることを可能にする。
「/」以外も同様である。

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

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

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

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

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

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

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

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

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

【００９７】この発明による機能拡張装置を利用するた
めには、対象となる装置が(1)例外事象発生時の処理手
段を呼び出す仕組みと(2)その処理手段として所望のも
のを設定可能という２の条件を満たしていれば良い。た
とえば「CPU」は「WWWサーバ」ではないが、CPUはこれ
らの条件を満たしているものが多い。

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

【００９９】コンピュータのファイル等のデータを「資
源」と捉えるならば、URLはインターネットにおける資
源の同定用文字列と言える。実際、「URL」の正式名称
である「Uniform Resource Locators」がそれを示して
いる。そして、資源の所在を指し示す文字列を「アドレ
ッシング用文字列」と呼び直してみると、(1)URLと並ん
でインターネットにおいて頻繁に利用されている文字列
である「電子メールアドレス」や(2)URLと電子メールア
ドレスに共通の要素である「ドメイン名」等も「アドレ
ッシング用文字列」と言って良いだろう。

【０１００】ここまで考えを進めるとこの発明は、アド
レッシング用文字列を処理するサーバ全般に適用できそ
うだとの推測が付く。具体的には、(1)電子メールの配
送等を行うための手段である電子メールサーバや、(2)
ドメイン名からIPアドレスを得るための（またはその逆
の用途のための）手段であるDNS (Domain name system)
サーバにも適用できそうなことが推測できる。FTP (fil
e transfer protocol)サーバにも適用できるであろう。
すなわち、電子メールサーバ（「sendmail」という名称
のプログラムが有名である。）を例に採れば、次のよう
な請求項を設けることが可能である。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

【０１１５】「CGI処理手段」または「CGIプログラム」
とは、WWWサーバ処理手段からCGI (common gateway int
erface)なる機構により呼び出される情報処理手段のこ
とである。とりわけ「CGIプログラム」と言った場合
は、その情報処理手段がプログラムとして実装されてい
ること示す。単に「CGI」と言う場合もある。

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

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

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

【０１１９】「ネットワーク」とは、広域の公開ネット
ワークであるインターネット、組織内のネットワークで
あるイントラネットならびに比較的小規模なネットワー
クであるLAN (local area network)を含む概念である。
通信規約にTCP/IP（RFCで定められているインターネッ
ト用の通信規約）を用いないネットワークを含むことを
妨げない。

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

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

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

【０１２３】この発明における「資料１」の出典は、
「日経コミュニケーション」（日経BP社発行）の1998年
4月20日号の第111ページである。

【０１２４】この発明における「資料２」の出典は、19
98年4月15日付け「日経産業新聞」第６面である。

【０１２５】

【発明の実施の形態】（実施形態１）図２にこの発明に
よるFxURL対応WWWサーバを用いたWWWサービスの一実施
形態を示す。

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

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

【０１２８】WWWサーバ（２１０）の構成要素および関
連データの関係を示すブロック図６と図７に示す。図６
は既存のWWWサーバのものである。図７はFxURL対応WWW
サーバのものである。

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

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

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

【０１３２】時としてURLパス部（１８１２）が省略さ
れているURLがある。また、多くの場合URLポート部（１
８１０）は省略されているが、この場合はHTTPの規約に
沿ってポート番号80が仮定される。多くの場合URLプロ
トコル部（１８０６）は「http」であるが、場合によっ
ては「https」となる。これはセキュリティを強化したH
TTPである。URLプロトコル部（１８０６）が「ftp」や
「wais」等となる場合があるが、この実施の形態ではこ
れらの扱いは言及しない。

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

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

【０１３５】特定のファイルにアクセスする際にWWWサ
ーバは、初期化処理部（６０８）により指定されて変数
情報保持部に保持されている「ドキュメントルート」な
る変数（以降「DocumentRoot」と表記する。）と階層構
造の境界を示す文字「/」とをURLパス部に前置し、実際
にアクセスするファイルの所在を決定する。この様子を
図１９に示す。

【０１３６】また、「スクリプトエイリアス」なる変数
（以降「ScriptAlias」と表記する。）が変数情報保持
部に保持されていれば、CGIプログラムの所在の決定に
際してScriptAliasの設定内容に沿った文字列の置換が
行なって実際にアクセスするファイルの所在を決定す
る。

【０１３７】また、「ディレクトリインデックス」なる
変数（以降「DirectoryIndex」と表記する。）が変数情
報保持部に保持されていれば、ファイル名の自動補完を
行う。この実施の形態においては index.html となっている。

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

【０１３９】DirectoryIndexに関する上記仕組みがあ
り、また、多くのWWWサーバではこの設定がなされてい
るため、通常、図１９に示すように、 http://www.any-domain.or.jp/ なるURLは http://www.any-domain.or.jp/index.html と同値となっている。

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

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

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

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

【０１４４】以上が既存のWWWサーバにおける処理の概
要である。

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

【０１４６】説明のおおよその流れは次のとおりであ
る： (1)機能拡張部の準備。 (2)エラーを誘発するデータの設定。 (3)エラー発生時の分岐に関する設定。 (4)機能拡張部等を備えたWWWサーバの起動とHTTPリクエ
ストに対する処理。

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

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

【０１４９】次にエラーを誘発するデータの設定を行
う。

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

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

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

【０１５３】以上で準備は完了なので、次に、機能拡張
部等を備えたWWWサーバ（つまりFxURL対応WWWサーバ）
の起動を行う。

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

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

【０１５６】以降は、WWWクライアントからのHTTPリク
エストを待つ状態に入る（ステップ（Ｓ３））。

【０１５７】実際にWWWクライアントからのHTTPリクエ
ストがあるとこのFxURL対応WWWサーバは、WWWクライア
ントから得た情報をデータ受信部部（６０２）を介して
受信し、URL解釈部（６０６）を用いてURLパス部等を取
得し（ステップ（Ｓ４））、URLパス部等を変数情報保
持部（６１８）に格納し、変数情報保持部（６１８）に
格納されたDocumentRoot等の情報（１９０２）等を用い
てアクセス対象とするファイルを決定する（ステップ
（Ｓ５））。

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

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

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

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

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

【０１６３】こうしてステップ（Ｓ３）に戻り、次のHT
TPリクエストを待つことになる。

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

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

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

【０１６７】本来はa.htmlからz.htmlまでの２６のファ
イルをDocumentRoot下に格納して http://www.ox.com/a.html、 http://www.ox.com/p.html、 http://www.ox.com/z.html なるHTTPリクエストに対して正常に a.html、 p.html、 z.html、の内容を送信すべきところを、 a.html〜c.html の３のファイルを除く２３のファイル（d.html〜z.htm
l）を意図的にDocumentRoot下以外のディレクトリ（例
えば/httpd/doc2）に格納する；という意図的なエラー
誘発手段を採ることもできる。

【０１６８】このようにした場合、 d.html〜z.html へのアクセスは一旦エラーとなる。この結果、この処理
はエラー処理部を介して機能拡張部へと制御が移る。

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

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

【０１７１】意図的にエラーを誘発する他の例として、
DocumentRoot下に何らファイルを置かない；とする方法
もある。このようにした場合、(1)URLパス部が「sales.
html」というようなTrURLである文字列の場合も、(2)UR
Lパス部が「営業のご案内.html」というようなFxURLで
ある文字列の場合も、(3)URLパス部が「営業案内.htm
l」というようなFxURLである文字列の場合も、すべて File Not Found のようなエラーとなる。DocumentRoot下に何らファイル
が無いので当然である。既存のWWWサーバの場合であれ
ば、このようなWWWサーバはWWWクライアントに対してフ
ァイルを提供するという機能を果たさないが、FxURL対
応WWWサーバは違う。制御は一旦エラー処理部（６１
２）に移ったのち、更に、機能拡張部（７０２）に移
る。

【０１７２】これにより、WWWクライアントからのファ
イルアクセスを伴うすべてのHTTPリクエストに対して統
一した処理を行うことができ、便利である。上記の例で
言えば、URLパス部が「sales.html」、「営業のご案内.
html」または「営業案内.html」のいずれであっても同
一のファイルをHTTPレスポンスとして送信するなど、異
なるURLの同一視等の文字列処理が容易に実現できる。

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

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

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

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

【０１７７】補足として、この実施の形態の変形として
次のような形態を挙げることができる。すなわち、HTTP
リクエストのうち、URLがTrURLであるものについては特
別な文字列処理は不要であるとして従来どおりDocument
Root以下にファイルを格納してもよい。このようにすれ
ば、URLがTrURLであるHTTPリクエストについてはWWWサ
ーバ内の本来の処理部によりすばやく処理する一方、UR
Lが漢字等を含むFxURLであるHTTPリクエストについては
機能拡張部にてワイルドカードの解釈を行う等のURLの
機能を高めるような処理を行うことが可能となる。

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

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

【０１８０】図１７において、CPU（１７０６）には、
ネットワークインターフェース（１７０２）、メモリ
（１７０８）、ディスプレイ（１７１０）、キーボード
（１７１２）、CD-ROMドライブ（１７１６）、ハードデ
ィスク（１７１８）が接続されている。

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

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

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

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

【０１８５】ハードディスク（１７１８）に記憶されて
いる各要素は、(1)CD-ROMドライブ（１７１６）を介し
てCD-ROM（１７１４）によりインストールされたか、
(2)ネットワークインターフェース（１７０２）を介し
てネットワーク（１７０４）上にあるWWWサーバまたは
ＦＴＰサーバ（いずれも図示せず）からインストールさ
れたものである。

【０１８６】WWWサーバのデータ受信部（１６０２）は
ネットワークインターフェース（１７０２）とOS（１７
２０）を介してWWWクライアントから送られて来るHTTP
リクエストを受信する。

【０１８７】WWWサーバのデータ送信部（１６０４）はO
S（１７２０）とネットワークインターフェース（１７
０２）を介してHTTPリクエストに対する応答となるデー
タ（HTTPレスポンス）をWWWクライアントに対して送信
する。

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

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

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

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

【０１９２】WWWクライアントからのHTTPリクエストに
応じて送信するHTMLファイル（テキストファイル）やGI
Fファイル（画像データ）等のファイルはDocumentRoot
下に置かれ、CGIプログラムは通常ScriptAlias下または
DocumentRoot下に置かれる。これらはいずれも、図７に
おいてはファイル保持部（６２０）に、図１７において
は公開用ファイル（１７２６）に含まれる。CGIプログ
ラムの一部または全部は（１７２６）の外に置かれる場
合もある。

【０１９３】WWWサーバが通常の動作に必要な要素の説
明は以上のとおりである。

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

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

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

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

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

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

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

【０２０１】

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

【図面の簡単な説明】

【図１】この発明の一実施形態による機能拡張手段等を
備えたWWWサーバの処理の流れを示す図である。

【図２】WWWサービスの一般的な利用形態を示す図であ
る。

【図３】WWWサービスにおけるクライアントとサーバ間
でのやり取りを単純化した図である。

【図４】URLの構成要素を説明した図である。

【図５】ブラウザの画面インターフェースを単純化した
図である。

【図６】既存のWWWサーバの構成要素と関連データを示
すブロック図である。

【図７】この発明の一実施形態による機能拡張手段等を
備えたWWWサーバの構成要素を示すブロック図である。

【図８】ファイルシステムにおけるインデックス領域と
ファイル領域との関連を示した図である。

【図９】○×商会のホームページのURL（URLは通常のTr
URLである。）と内容を示す図である。

【図１０】○×商会のホームページのURL（URLは漢字等
を含んだKURLである。）と内容を示す図である。

【図１１】URLの表記における各ASCII文字について利用
の適不適を示す図である。

【図１２】末尾に記号「?」を含むURLの例を示す図であ
る。

【図１３】URL中の記号「?」の有無とURLの表現能力と
の関係を示すための図である。

【図１４】この発明により可能になるURL表現の例を利
用可能な文字種の豊富さに力点を置いて示した図であ
る。

【図１５】この発明により可能になるURL表現の例を検
索機能に力点を置いて示した図である。

【図１６】この発明により可能になるURL表現の例を日
常の文章表現が可能な点に力点を置いて示した図であ
る。

【図１７】この発明の一実施形態による機能拡張手段等
を備えたWWWサーバ処理装置の構成要素を示す図であ
る。

【図１８】与えられたURLをURLパス部など４つの部分に
分解するURL分解手段の機能を示す図である。

【図１９】WWWサーバの初期設定ファイルの内容とWWWク
ライアントから得たURLパス部とがどのように作用して
実際のアクセス対象ファイルを決定するのかを示す図で
ある。

【符号の説明】

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

Claims

【特許請求の範囲】

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