(57)【要約】      （修正有）【課題】簡単な手段でインターネットサービスプロバイダを介することなく、ユーザが自分のマシンをウェブサーバ化、ブログサーバ化して、個人が所有する情報の公開を容易に行うことができるようにする。【解決手段】例えばJarファイルの構造において、META-INFフォルダ１には、マニフェストファイルが格納されており、起動されたときに最初にロードするclassファイル情報が記述されている。コンテンツフォルダ２には、テキストファイルや画像、音声ファイルなどが格納される。プログラムフォルダ３には、Javaのプログラムファイル群が格納され、ここに通信機能、加筆機能、記録機能などが格納される。そしてこれらを単一の文書としてカプセル化された文書構造とする。【選択図】図１
2007041702.tif 000002
【特許請求の範囲】
【請求項１】
表現実体となる１又は２以上のデジタル情報ファイルと、前記デジタル情報ファイルの構造及び表示状態を特定する表示情報ファイルと、コンピュータによって共に解釈、実行され、前記デジタル情報を参照せずに特有の機能を実行するための機能動作プログラムを含む動作プログラムファイルとを具備し、
ウェブブラウザの要求に応じて前記デジタル情報ファイル内のコンテンツをブラウザに送信するウェブサーバ機能を有するプログラムファイルが前記デジタル情報ファイルとともに単一の文書としてカプセル化されている
ことを特徴とするカプセル化文書構造。
【請求項２】
前記表示情報ファイルに基づいて特定される表示状態で前記１又は２以上のデジタル情報ファイルを前記コンピュータのディスプレイ上に表示させるデジタル情報表示プログラムが単一の文書としてカプセル化されている
ことを特徴とする請求項１に記載のカプセル化文書構造。
【請求項３】
前記表示情報ファイル内のコンテンツを編集するコンテンツ編集機能を有するプログラムファイルが単一の文書としてカプセル化されている
ことを特徴とする請求項１に記載のカプセル化文書構造。
【請求項４】
前記表示情報ファイル内のコンテンツの更新情報を送信する更新情報送信機能を有するプログラムファイルが単一の文書としてカプセル化されている
ことを特徴とする請求項３に記載のカプセル化文書構造。
【請求項５】
前記ウェブサーバ機能を有するプログラムファイルは、既に他のウェブサーバプログラムが起動している場合には、そのウェブサーバプログラムに前記ウェブサーバ機能を委託する
ことを特徴とする請求項１に記載のカプセル化文書構造。
【請求項６】
前記委託を受ける機能を含む前記ウェブサーバ機能を有するプログラムファイルが単一の文書としてカプセル化されている
ことを特徴とする請求項５に記載のカプセル化文書構造。
【請求項７】
保持しているコンテンツに関するメタ情報を公開するメタ情報公開機能を有するプログラムファイルが単一の文書としてカプセル化されている
ことを特徴とする請求項１に記載のカプセル化文書構造。
【請求項８】
マシン上で起動している文書のメタ情報を統合するメタ情報統合機能を有するプログラムファイルが単一の文書としてカプセル化されている
ことを特徴とする請求項７に記載のカプセル化文書構造。
【請求項９】
マニュフェストファイルを記述し、
前記マニュフェストファイル中のクラスファイルを指定し、
前記マニュフェストファイルとコンテンツと、前記クラスファイルとしてのウェブサーバ機能を有するプログラムファイルを単一の文書としてカプセル化する
ことを特徴とするウェブサーバ機能を有する文書の作成方法。
【請求項１０】
前記ウェブサーバ機能を有するプログラムファイルは、既に他のウェブサーバプログラムが起動している場合には、そのウェブサーバプログラムに前記ウェブサーバ機能を委託する
ことを特徴とする請求項９に記載のウェブサーバ機能を有する文書の作成方法。
【請求項１１】
前記委託を受ける機能を含む前記ウェブサーバ機能を有するプログラムファイルが単一の文書としてカプセル化されている
ことを特徴とする請求項１０に記載のウェブサーバ機能を有する文書の作成方法。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、例えば個人からの情報の発信に使用して好適なカプセル化文書構造及びウェブサーバ機能を有する文書の作成方法に関する。詳しくは、インターネットサービスプロバイダを介することなく、ユーザが自分のマシンをウェブサーバ化、ブログサーバ化して情報を公開することができるようにしたものである。
【背景技術】
【０００２】
カプセル化文書作成の手段として、本願出願人は先に文書のデータ構造、記憶媒体及び情報処理装置の発明を出願している（例えば、特許文献１、２参照。）。
【０００３】
また、ウェブサーバとしては、ＩＩＳ（Internet Information Service）やApache等が実用化されているものである（例えば、非特許文献１参照。）。
【０００４】
すなわち、任意の電子データとその処理に用いるプログラムをカプセル化する技術は公知である。また、ウェブサーバを用いて、個人が所有する情報を発信する技術も一般的に知られているものである。
【特許文献１】特開２００３−１５９４１号公報
【特許文献２】特開２００３−９９４２４号公報
【非特許文献１】http://www.atmarkit.co.jp/flinux/rensai/apache01/apache01.html
【発明の開示】
【発明が解決しようとする課題】
【０００５】
インターネット関連技術の発展により、誰もが自分の文書を簡単に公開できるようになってきている。特に最近ではブログ(ウェブログ)が、文書の投稿の簡便さから急速に普及してきている。これら、現在ウェブ上にあるコンテンは、インターネットサービスプロバイダが提供しているサービスを利用したものが多く、ユーザが自分のマシンをウェブサーバ化、ブログサーバ化して情報を公開するのは現状ではそれほど多くないと言える。
【０００６】
しかしながら、一ユーザが個人で自分のマシンをウェブサーバ化して情報を公開する環境は徐々に整ってきている。サービスとして、ブロードバンドサービス、定額の常時接続サービス、固定ＩＰアドレス配布サービスなどがあり、またユーザが個人で所有するマシンもハイスペック化してきており、インターネット上の一サーバとして十分成り立つ。このような環境下において、個人でウェブサーバなどを立てているユーザもいることはいるが、インターネットユーザの数の多さに対して、非常に少ないのが現状である。
【０００７】
その原因としては、料金などの問題やセキュリティ面での脅威も考えられるが、ウェブサーバを立てることの敷居の高さの問題も一因であると考える。例えば、現状においてはユーザがウェブサーバを立てるとなると、マイクロソフトが提供しているＩＩＳ（Internet Information Service）か、オープンソースのApacheを利用するのが一般的であると思われるが、どちらも一ユーザが設定するのは大変である（実際にはそれほど大変ではないが、一般ユーザは大変であるとの印象を抱いてしまっている）。
【０００８】
さらにブロードバンド化が進み、ＩＰｖ６が普及してすべての機器がネットワークにつながってグローバルアドレスを持つような環境が予想される。そのような環境においては、個人や個々の機器による情報発信がますます重要になっていくであろう。
【０００９】
そういった環境においては、現状のように、文書を公開するのにわざわざインターネットサービスプロバイダのサービスを利用するのではなく、自分のマシン上で公開するのも一つの手段になるのではないかと考えられる。例えばブログを例にとると、現在の形態では、インターネットサービスプロバイダなどがサービスの一つとしてブログができるスペースをユーザに対して提供しており、ユーザは簡単な登録のみで自分専用のブログを開設できるようになっている。
【００１０】
この場合にユーザは手軽に、ほとんどコストをかけずにブログを開設できるというメリットがある一方、インターネットサービスプロバイダによるサービスであるため、ユーザの都合で仕様の変更を行ったりすることはほとんどできず、また、サービス自体が突然終了してしまう可能性もある。画像の登録容量に制限があるなど、使い勝手が必ずしも良いとは言えない。したがって、簡単に自分で文書を公開する手段さえあれば、他者のサービスに頼る必要がなくなるのではないかと考えられる。
【００１１】
また、オフィスでの用途を考えた場合、現状では個人でウェブサーバを立てるようなことはせず、情報部門もしくは部門のＩＴ関連技術に強いユーザがウェブサーバを構築し、サーバやコンテンツの管理を行っている。このシステムの問題点は、ユーザ数が多くなればなるほど管理がしにくく管理者およびサーバなどの機器に負担がかかる点と、ユーザが自分の管理下でコンテンツの公開および更新がしにくい点にある。
【００１２】
これに対して、ユーザが個人でコンテンツを管理してくれれば、サーバを用意する必要もなければ、バックアップなどの手間もユーザ側に委ねることができる。また、ユーザそれぞれが簡単に文書を公開、更新できるようになれば社内での情報共有やコミュニケーションも円滑になることが予想される。
【００１３】
この発明はこのような問題点に鑑みて成されたものであって、本発明の目的は、簡単な手段でインターネットサービスプロバイダを介することなく、ユーザが自分のマシンをウェブサーバ化、ブログサーバ化して、個人が所有する情報の公開を容易に行うことができるようにするものである。
【課題を解決するための手段】
【００１４】
上記の課題を解決し、本発明の目的を達成するため、請求項１に記載された発明は、表現実体となる１又は２以上のデジタル情報ファイルと、デジタル情報ファイルの構造及び表示状態を特定する表示情報ファイルと、コンピュータによって共に解釈、実行され、デジタル情報を参照せずに特有の機能を実行するための機能動作プログラムを含む動作プログラムファイルとを具備し、ウェブブラウザの要求に応じてデジタル情報ファイル内のコンテンツをブラウザに送信するウェブサーバ機能を有するプログラムファイルがデジタル情報ファイルとともに単一の文書としてカプセル化されていることを特徴とするカプセル化文書構造である。
【００１５】
また、請求項２に記載のカプセル化文書構造においては、表示情報ファイルに基づいて特定される表示状態で１又は２以上のデジタル情報ファイルをコンピュータのディスプレイ上に表示させるデジタル情報表示プログラムが単一の文書としてカプセル化されていることを特徴とするものである。
【００１６】
請求項３に記載のカプセル化文書構造においては、表示情報ファイル内のコンテンツを編集するコンテンツ編集機能を有するプログラムファイルが単一の文書としてカプセル化されていることを特徴とするものである。
【００１７】
請求項４に記載のカプセル化文書構造においては、表示情報ファイル内のコンテンツの更新情報を送信する更新情報送信機能を有するプログラムファイルが単一の文書としてカプセル化されていることを特徴とするものである。
【００１８】
請求項５に記載のカプセル化文書構造においては、ウェブサーバ機能を有するプログラムファイルは、既に他のウェブサーバプログラムが起動している場合には、そのウェブサーバプログラムにウェブサーバ機能を委託することを特徴とするものである。
【００１９】
請求項６に記載のカプセル化文書構造においては、委託を受ける機能を含むウェブサーバ機能を有するプログラムファイルが単一の文書としてカプセル化されていることを特徴とするものである。
【００２０】
請求項７に記載のカプセル化文書構造においては、保持しているコンテンツに関するメタ情報を公開するメタ情報公開機能を有するプログラムファイルが単一の文書としてカプセル化されていることを特徴とするものである。
【００２１】
請求項８に記載のカプセル化文書構造においては、マシン上で起動している文書のメタ情報を統合するメタ情報統合機能を有するプログラムファイルが単一の文書としてカプセル化されていることを特徴とするものである。
【００２２】
さらに、本発明の目的を達成するため、請求項９に記載された発明は、マニュフェストファイルを記述し、マニュフェストファイル中のクラスファイルを指定し、マニュフェストファイルとコンテンツと、クラスファイルとしてのウェブサーバ機能を有するプログラムファイルを単一の文書としてカプセル化することを特徴とするウェブサーバ機能を有する文書の作成方法である。
【００２３】
また、請求項１０に記載のウェブサーバ機能を有する文書の作成方法においては、ウェブサーバ機能を有するプログラムファイルは、既に他のウェブサーバプログラムが起動している場合には、そのウェブサーバプログラムにウェブサーバ機能を委託することを特徴とするものである。
【００２４】
請求項１１に記載のウェブサーバ機能を有する文書の作成方法においては、委託を受ける機能を含むウェブサーバ機能を有するプログラムファイルが単一の文書としてカプセル化されていることを特徴とするものである。
【発明の効果】
【００２５】
本発明のカプセル化文書構造及びウェブサーバ機能を有する文書の作成方法によれば、簡単な手段でインターネットサービスプロバイダを介することなく、ユーザが自分のマシンをウェブサーバ化、ブログサーバ化して、個人が所有する情報の公開を容易に行うことができる。
【発明を実施するための最良の形態】
【００２６】
以下、図面を参照して本発明を説明するに、図１には、本発明によるカプセル化文書構造及びウェブサーバ機能を有する文書の作成方法を、Jar（Java ARchive）ファイルに適用した場合のファイルの構造を示す。
【００２７】
図１において、Jarファイルは、現在広く普及しているZIPファイル形式に基づくファイル形式で、複数のファイルを一つにまとめた書庫ファイルである。Jarファイルには、Javaのプログラムモジュールであるclassファイルおよびテキスト、画像、音声ファイルなどを含めることができる。
【００２８】
〔Jarファイルの構造〕
Jarファイルの構造は図１に示した通りである。図１において、META-INFフォルダ１には、マニフェストファイルが格納されており、起動されたときに最初にロードするclassファイル情報が記述されている。コンテンツフォルダ２には、テキストファイルや画像、音声ファイルなどが格納される。フォルダ自体はここではなくてもよいが、他のファイル群（プログラムファイルなど）と区別するためにここでは設けた。またフォルダ自体は複数あっても構わない。
【００２９】
プログラムフォルダ３には、Javaのプログラムファイル群が格納される。通常、Javaのプログラムはパッケージ名に応じた階層で管理される。すなわち、例えばパッケージ名をjp.co.ricoh.project とした場合、そのパッケージ内で作成されるclassファイルは、図２に示したような階層の位置になる。従って、プログラムフォルダ３の名前は、この場合はjpになる。
【００３０】
〔実行可能Jarファイル〕
実行可能Jarファイルとは、例えばWindows上でファイルを開くときにダブルクリックするように、ダブルクリックすることによってマニフェストファイルに記述されたclassファイルがロードされ、実行されるファイルである。Jarファイルは、Javaの実行環境のインストール時に、Jarファイル（拡張子jar）と関連付けられる。またコマンドラインで
java -jar sample.jar
とすることによって起動することもできる。
【００３１】
〔機能を有する文書の起動〕
機能を有する文書の起動までの流れを図３に示す。この流れは基本的には実行可能Jarファイルの起動と同じである。
【００３２】
ここで、機能を有する文書の構造は以下の通りである。
・マニフェストファイル（文書を起動する際に最初にロードするプログラム（classファイル）の名前が記述されている。）
・コンテンツ（ここでは、プログラムによってロード、表示されるコンテンツを指す。テキスト、画像、動画、音声ファイルなど。プログラムが解釈、処理できればフォーマットは問わない。）
【００３３】
・プログラム（コンテンツフォルダに含まれる文書（テキスト、画像など）をロード、表示するプログラムを格納する。文書を表示するだけでなく、文書に様々な機能を追加するプログラムもここに格納する。機能の例としては、例えば、通信機能、加筆機能、記録機能などがある。）
【００３４】
〔動作〕
ステップＳ１におけるダブルクリックもしくはコマンドラインからの命令によって、ステップＳ２でマニフェストファイルが取得され、ステップＳ３でメインクラスの情報が取得されると、ステップＳ４でメインクラスに記述されているclassファイルがロードされて、それぞれロードされたclassファイルが実行される。すなわち、ステップＳ５でウェブサーバプログラムが実行され、ステップＳ６でコンテンツ表示プログラムが十呼応され、ステップＳ７でその他の機能が実行される。これによって、コンテンツフォルダ内のテキストや画像が表示される。
【００３５】
このようにして、コンテンツが表示されるとともに、各種機能を実現するプログラムも同様にロードされ、使用準備が整う。これにより、例えばユーザのマウス操作に応じて、文中に下線を引くような機能が実現できる。
【００３６】
さらにウェブサーバ機能を有する文書について説明する。ここで、ウェブサーバ機能を有する文書とは、コンテンツにあたる部分にHTMLやJPEGなどのウェブブラウザで閲覧できるフォーマットを格納し、プログラムにあたる部分に、コンテンツを表示するプログラムと、ウェブブラウザからのアクセスに応じてコンテンツファイルをウェブブラウザに送信するウェブサーバプログラムとを格納したものである。
【００３７】
〔ウェブサーバプログラムの処理（一般）〕
ここでは、ウェブサーバプログラムの基本的な動作について述べる。まず、ウェブサーバプログラムはウェブブラウザからの要求に応じてテキストや画像を送信するのが基本機能である。ウェブブラウザからの要求とウェブサーバプログラムの応答の概要を以下に述べる。
【００３８】
ウェブブラウザとウェブサーバの関係は典型的なクライアント／サーバシステムであると言える。ウェブブラウザの要求に対してウェブサーバが応答するという形で処理がなされる。ウェブブラウザとウェブサーバプログラムとの通信はHTTP（Hyper Text Transfer Protocol）を用いて行われる。HTTPの仕様はRFC1945(HTTP/1.0)、RFC2068(HTTP/1.1)にて定められている（RFC: Request For Comments）。
【００３９】
ウェブブラウザとウェブサーバプログラム間の通信は、このHTTPというプロトコルを通じて、ウェブブラウザがHTML（Hyper Text Markup Language）ファイルをウェブサーバプログラムに対して要求し、ウェブサーバはその要求を解釈してHTMLファイルを送信することによって実現されている。ウェブブラウザは、受信したHTMLファイルのタグを解釈しコンテンツをレンダリングするなどの機能が必要であるが、ウェブサーバプログラムは、基本的にはウェブブラウザからのコマンドを解釈し、対応ファイルを送信するだけである。
【００４０】
〔ウェブブラウザからのファイルの要求（GETコマンド）〕
ウェブブラウザから要求されるコマンドはいくつかあるが、ここでは、もっとも基本的なGETコマンドについてのみ述べることにする。ウェブサーバプログラムの起動しているマシン名をウェブserverとすると、ウェブブラウザがウェブserver上のindex.htmlファイルにアクセスするには、
http://ウェブserver:6000/index.html
をopenすればよい（6000はポート番号）。
【００４１】
このときウェブブラウザは、ソケットを使って、マシンウェブserver上でポート6000を使用しているサーバとの間にコネクションをはり、
GET /index.html HTTP/1.0[CR LF(改行)]
のような命令をウェブサーバプログラムに対して送信する（行の末尾は開業コード）。また、GETコマンドの後には様々な付加情報が続くが、ここでは、触れない。
【００４２】
最後に空行(改行コード以外に文字を一切含まない行)を付加することによって、命令の最後であることをウェブサーバプログラムに通知する。因みにウェブブラウザがproxyサーバ経由でウェブserverにアクセスする場合には、GETコマンドは以下のようになり、proxyサーバが代理でウェブserverにアクセスする。
GET http://ウェブserver:6000/index.html HTTP/1.0[CR LF]
【００４３】
〔ＧＥＴコマンドの処理（ウェブサーバプログラム）〕
ウェブサーバプログラムはGETコマンドを受信したら、コマンドから要求されているファイルを特定し、対象ファイルを送信する。ファイルを送信するのに先立って、以下のヘッダ情報を送信する必要がある。
HTTP/1.0 200 OK[CR LF]
[CR LF]
【００４４】
なお、最初の行は、GET命令が正しく受理され、要求されたファイルを送信することを意味する。２行目は空行であり、ヘッダ情報の終了を意味する。これに続けて要求されたファイルを送信し、送信し終わったところでコネクションを張っていたソケットをクローズする。
【００４５】
また、要求されたファイルが存在しないなどの原因で、ウェブブラウザに何らかのエラー情報を返す場合には、以下のようなコマンドをHTTPの仕様に従って送信する。
HTTP/1.0 404 ファイル未検出[CR LF]
[CR LF]
<h2>要求されたファイルは見つかりませんでした。</h2>
なお、３行目はウェブブラウザに表示させるエラーメッセージである。
【００４６】
以上が、ウェブサーバプログラムの処理の流れである。HTTPには、他にも多くの取り決めがあるが、基本的には、ウェブブラウザがGETコマンドを発行することによってファイルを要求し、その要求をウェブサーバプログラムが解釈して、対象のファイルをウェブブラウザに対して送信することで成り立っている。
【００４７】
〔ウェブサーバプログラム（カプセル化文書内）の処理〕
さらに、文書内のウェブサーバプログラムの処理の流れについて、図４を参照して以下に述べる。基本的には先に述べたのと同様にウェブブラウザからの要求に応じて文書内のファイルをウェブブラウザに送信する。図４では、ウェブブラウザからの要求を受けた時点でスレッドを生成し、ウェブブラウザの要求に応じる動作について示した。
【００４８】
すなわち図４において、ステップＳ１１ではウェブブラウザからの要求が待ち受けられる。そして要求があるとステップＳ１２で処理スレッドが生成され、ステップＳ１３で要求情報が解析され、ステップＳ１４で要求ファイルが解析される。さらにステップＳ１５で要求されたファイルがあるか否か判断され、ある時（Ｙｅｓ）はステップＳ１６でヘッダ情報が送信され、ステップＳ１７でファイルが送信される。またステップＳ１５で要求されたファイルがない時（Ｎｏ）はステップＳ１８でエラーメッセージが送信される。
【００４９】
このようにして、一般的なウェブサーバプログラムにおいて、ウェブブラウザからのファイルの要求があった時の要求されたファイルの送信、及び要求されたファイルが無かった場合のエラーメッセージ送信の処理が行われる。
【００５０】
さらに、複数のウェブサーバ機能を有する文書を起動したときの処理について以下に説明する。まず、複数のウェブサーバ機能を有する文書を起動する場合について述べる。
【００５１】
〔複数のソケットの生成〕
ここで、複数のウェブサーバプログラムを起動するということは、複数のソケットを生成するということである。この場合に問題となるのは、同じポート番号で複数のソケットは生成できないということである。先に述べたように、ウェブサーバプログラムは、ＩＰアドレスとポート番号のセットでソケットを作成し、ウェブブラウザからの接続を待ち受ける。従ってウェブサーバプログラムを複数起動するには、ポート番号を変更して起動する必要がある。そうしなければ通常バインドエラーになってソケットを生成できない。
【００５２】
そこで、例えばすて図５に示すように、ソケットを生成する際にポート番号を変えてやることにより、複数のウェブサーバプログラムそれぞれがソケットを生成することが可能になる。すなわち図５においては、ステップＳ２１で起動が行われると、ステップＳ２２でソケットが生成される。そしてステップＳ２３でＯＫか否か判断され、ＯＫの時（Ｙｅｓ）はステップＳ２４で接続待ちとなる。
【００５３】
また、ステップＳ２３でＯＫでない時（Ｎｏ）はステップＳ２５でポート番号を変えてソケットが制裁され、さらにステップＳ２６でＯＫか否か判断され、ＯＫの時（Ｙｅｓ）はステップＳ２４で接続待ちとなる。さらにステップＳ２６でＯＫでない時（Ｎｏ）はステップＳ２５、Ｓ２６が繰り返し実行される。このようにして、複数のウェブサーバプログラムそれぞれがソケットを生成することが可能になる。
【００５４】
しかしながらこの方法の問題点としては、ウェブサーバプログラムに接続するウェブブラウザは、ポート番号を文書ごとに変更してアドレスを指定しなければならなくなるという点があげられる。ウェブサーバプログラムがどのポート番号でソケットを生成したかはウェブブラウザでは知ることはできないので、ポート番号は固定するのが望ましいのである。そこで、さらに複数の文書を起動した場合も一つのソケットで処理する方法について以下に説明する。
【００５５】
すなわち、複数のソケットを生成してしまう方法はあまり現実的ではないので、一つのマシンで複数のウェブサーバ機能を有する文書を起動しても、ソケットの生成は一つで済む方法について図６を参照して説明する。まず、この図６において、ステップＳ２１で起動が行われると、ステップＳ２２でソケットが生成される。そしてステップＳ２３でＯＫか否か判断され、ＯＫの時（Ｙｅｓ）はステップＳ２４で接続待ちとなる。ここまでの処理は図５の場合と同じである。
【００５６】
従ってこの場合に、マシン上で最初に起動するウェブサーバ機能を有する文書は、他にそのポートを使用している文書がないためにウェブサーバプログラムにおいてソケットを生成することができる。これに対して、マシン上において２番目以降に起動するウェブサーバ機能を有する文書は、作成しようとするソケットのポート番号がすでに最初の文書において使用されているために、ソケットを生成することができず、エラーを発生する。
【００５７】
そこで、このエラーを発生した場合の処理として、すでに起動しているウェブサーバプログラムに対して委託要求を発信する。この要求を受信したウェブサーバプログラムは、応答を返し、委託を受ける旨を要求してきたウェブサーバプログラムに対して通知する。このため上述のステップＳ２３でＯＫでない時（Ｎｏ）は、ステップＳ２７で最初に起動したウェブサーバプログラムに委託を行って、ステップＳ２８でこの処理は終了される。
【００５８】
このようにして、２番目以降に起動するウェブサーバ機能を有する文書は、すでに起動しているウェブサーバプログラムに対してウェブサーバ機能を委託することによって、一つのマシンで複数のウェブサーバ機能を有する文書を起動しても、ソケットの生成は一つで済ませることができる。さらに、委託を受けたウェブサーバプログラムでの処理は以下のように行われる。
【００５９】
〔委託を受けたウェブサーバプログラム〕
委託を受けたウェブサーバプログラムは、自文書内のコンテンツのみならず、委託を受けた文書(Jarファイル)の文書内コンテンツをウェブブラウザに対して送信する処理も受け持つ。委託を受けた際には、図７に示したような文書の一覧を示すHTML文書を生成する。図７は二つの文書から委託された場合を示している。図７中のdocument1などは、任意である。一意になる名前をつける。文書中からタイトルを抜き出して表示しても良いが、リンクは同じ文書を指し示すことがないようにする必要がある。
【００６０】
従って図７において、複数の文書が起動している場合には、例えば、ウェブブラウザでマシン名をmachineとすると
http://machine:8080/
をopenすることにより、起動している文書の一覧が記述されたHTML文書を表示する。
【００６１】
ここで、一覧のリンクは、例えば、
http://machine:8080/document1/index.html 
http://machine:8080/document2/index.html 
http://machine:8080/document3/index.html 
などとなり、閲覧したい文書をクリックすることにより、ユーザは異なる文書のコンテンツを閲覧することができる。
【００６２】
さらに、委託を受けているウェブサーバプログラムの処理としては、図８に示すようにユーザのクリックイベントにより、ウェブブラウザが
http://machine:8080/document3/index.html 
をopenするので、ウェブサーバプログラムは、コマンドとして、
GET /document3/index.html HTTP/1.1
を取得することができる。
【００６３】
すなわち図８において、ステップＳ３１ではウェブブラウザからの要求が待ち受けられる。そして要求があるとステップＳ３２で処理スレッドが生成され、ステップＳ３３で要求情報が解析される。ここまでは図４のステップＳ１１〜Ｓ１３と同じである。そこで、さらにステップＳ３４で自文書内のファイルか否か判断され、自文書内のファイルである時（Ｙｅｓ）はステップＳ３５で要求ファイルが解析される。
【００６４】
また、ステップＳ３６で要求されたファイルがあるか否か判断され、ある時（Ｙｅｓ）はステップＳ３７でヘッダ情報が送信され、ステップＳ３８でファイルが送信される。またステップＳ３６で要求されたファイルがない時（Ｎｏ）はステップＳ３９でエラーメッセージが送信される。このようにして、要求されたファイルが自文書内であった時の要求されたファイルの送信、及び要求されたファイルが無かった場合のエラーメッセージ送信の処理が行われる。以上の処理は、図４のステップＳ１５〜Ｓ１８と同じである。
【００６５】
これに対して、ステップＳ３４で要求されたファイルが自文書内でなかった時（Ｎｏ）は、ステップＳ４０で他文書にファイルの要求を行い、ステップＳ４１でファイルがＯＫか否か判断される。そしてファイルがＯＫの時（Ｙｅｓ）はステップＳ４２でファイルが受信され、ステップＳ３７でヘッダ情報が送信され、ステップＳ３８でファイルが送信される。またステップＳ４１で要求されたファイルＯＫでない時（Ｎｏ）はステップＳ４３でエラーメッセージが送信される。
【００６６】
このようにして、ステップＳ３４で要求されたファイルが自文書内でなかった時に、他文書からのファイルを受信して、要求されたファイルの送信、及び要求されたファイルが無かった場合のエラーメッセージ送信の処理が行われる。すなわち、上記コマンド中のdocument3により、どの文書の要求を受けているかが判断できるので、対応する文書（document3）にアクセスし、document3からindex.html を受け取って、それをウェブブラウザに送信することで、複数の文書のコンテンツ処理を一つのウェブサーバプログラムが請け負うことが可能になる。
【００６７】
つまり、委託を受けているウェブサーバプログラムは、GETコマンドを解析した結果、自文書内のコンテンツ要求であれば、図４に示した通常とほぼ同じ動作を行い、GETコマンドを解析した結果、他文書内のコンテンツであった場合には、その文書に対してコンテンツの要求を行い、ファイルをその文書から受信し、受信したファイルをウェブブラウザに対して送信する。さらに、委託しているウェブサーバプログラムの処理の流れについては図９に示す。
【００６８】
すなわち図９において、ステップＳ５１では他のプログラムからのコンテンツ要求が待ち受けられる。そして要求があるとステップＳ５２で処理スレッドが生成され、ステップＳ５３で要求情報が解析され、ステップＳ５４で要求ファイルが解析される。さらに、ステップＳ５５で要求されたファイルがあるか否か判断され、ある時（Ｙｅｓ）はステップＳ５６でファイルが送信される。またステップＳ５５で要求されたファイルがない時（Ｎｏ）はステップＳ５７でエラーメッセージが送信される。
【００６９】
このようにして、自分でソケットを生成できない場合は、他のウェブサーバプログラムからコンテンツ要求を受け付けることのできるソケットを生成し待ち受ける。そして、他のウェブサーバプログラムからコンテンツの要求があった場合に要求を解析し、要求に応じたファイルを取得して送信する。また、要求されたファイルが存在しない場合にはエラーメッセージを送信する。
【００７０】
さらに、委託を受けているウェブサーバ機能を有する文書が閉じた場合の処理を以下に説明する。すなわち、委託を受けているウェブサーバ機能を有する文書中のプログラムがクローズイベントを取得した場合は、ソケットをクローズするとともに他に起動している文書があればその文書に委託し、ソケットを作成させる。この様子を図１０に示す。なおこの場合には、先に述べたような起動文書の情報もあわせて送信して終了する。
【００７１】
また、ウェブサーバ機能を委託している文書が閉じたときの処理は以下に説明する。すなわち、ウェブサーバ機能を他の文書に委託している場合は、その委託先のプログラムに終了することを通知する。この様子を図１１に示す。ここで、終了情報を受けたウェブサーバ機能を委託されているサーバは、図７に示した文書リンク情報から該当する文書を削除し、リンクから外す。
【００７２】
従って、上述した本発明の実施形態において、簡単な手段でインターネットサービスプロバイダを介することなく、ユーザが自分のマシンをウェブサーバ化、ブログサーバ化して、個人が所有する情報の公開を容易に行うことができる。
【００７３】
さらに以下には、ウェブサーバ機能を有する文書の作成方法を説明する。ここでは最初に、マニフェストファイルの記述例を以下に示す。
Manifest-Version: 1.0
Main-Class: jp.co.ricoh.project.AppMain
Created-By: 1.3.1 (Sun Microsystems Inc.)
【００７４】
ここで２行目はmain関数のあるclassファイル名である。これを指定しておくことによって起動時に最初にロードされるclassファイルを決定することができる。３行目はJavaのバージョンおよびサプライヤである。また、マニフェストファイルと、コンテンツ、およびプログラムファイル群（classファイル群）をZIP化して一つにする。ファイル拡張子はjarとする。
【００７５】
ZIP化の方法を以下に示す。
ZIP化するファイルの読み込みおよびバイト配列への格納
↓
ファイル書き出しストリーム生成
↓
ZIPの書き出しストリームを生成してファイル書き出しストリームを渡す
↓
ZIPエントリを生成しZIPの書き出しストリームに登録
↓
ZIPの書き出しストリームに先のバイト配列を書き込み
↓
ZIPエントリのクローズ
↓
終了処理
【００７６】
この処理は一つのファイルをZIP化する際の基本的な処理の流れであるが、複数ファイルに渡っても基本的な処理は同じである。以上のようにして、マニフェストファイル、コンテンツ、ウェブサーバ機能を提供するプログラム群を一つの書庫ファイルとして扱うことができる。
【００７７】
さらに、JavaのSDK（Software DevelopementKit）をインストールしてある環境であれば、
jar cvfm sample.jar manifest.mf *.*
などとコマンドを打つことにより、容易にJarファイルの生成が可能である。つまり、Javaプログラミングで言えば、Runtimeの外部プログラム呼び出しの文字列に
jar cvfm sample.jar manifest.mf *.*
としてやることによってJarファイルの作成が可能である。
【００７８】
さらに、本発明における内部コンテンツの作成方法及び編集方法について説明する。すなわち、ウェブブラウザを使って編集できれば、文書さえ起動しておけば、ネットワークにつながっていればどこからでも作成、編集ができて便利である。ここでは一番基本的なPOST（Power On Self Test）コマンドを利用した編集方法について述べる。これまでは、GETコマンドでウェブサーバプログラムにファイルを送ってもらっていたが、編集するにはウェブサーバプログラムがPOSTコマンドの処理能力が必要である。ただし、実際にはGETでも投稿可である。
【００７９】
そこで、POSTコマンドの処理は、ＣＧＩ（Common Gateway Interface）が行う場合が多い。ＣＧＩはデータ処理用のプログラムで掲示板やカウンタの機能を提供していることが多い。Perl（Practical Extraction and Report Language）で記述されることが多いが、要はPOSTコマンドを処理できれば良いのでプログラム言語は何でも構わない。またスクリプトとして埋め込んでしまう方法もある。
【００８０】
POSTコマンドは主に記事を投稿する際にウェブブラウザが発行するコマンドである。つまり、サーバプログラムに対してデータを送信するためのコマンドである。POSTコマンドを利用したウェブサーバプログラムとウェブブラウザプログラムのデータのやり取りを以下に示す。
【００８１】
まず、ウェブブラウザがGETコマンドで編集用ページを取得する。ここでは、例えば文書中「作成」などと書いたリンクをクリックするとサーバプログラムが送信してくるHTMLである(実際にはログイン認証を経る)。このような取得を行うHTMLの例を以下に示す。
【００８２】
<html>
<head>
</head>
<body>
<form action = "http://machine:8080/programs/post" method = "post">
<p>
<textarea name="textarea" rows=5 cols=50></textarea><br>
<input type = "submit" value = "send"> <input type = "reset" value = "reset"><br>
</p>
</form>
</body>
</html>
【００８３】
従って、ウェブブラウザがこのHTMLを受信し、ユーザがテキストエリアに文字を入力し、[send］ボタンを押すことによって、ウェブサーバプログラムに対してテキストエリア内に記述された情報が渡される。ウェブサーバプログラムはそれを解釈することでコンテンツに反映することができる。
【００８４】
なお、直接HTMLを編集する方法もあるが、その場合はHTML編集プログラムを呼び出して編集する。例えばJavaであれば、外部プログラムを呼び出すプロセスを生成可能である。この際にどの外部プログラムを呼び出すかは、ユーザによる指定が必要である。
【００８５】
ただし、編集及びファイル新規作成時の問題点としては、Zipファイルにはヘッダファイルがあり、そのファイルにはZip化されているファイル名とサイズなどが記載されている。このファイルと実際のファイルの整合性が取れないと単に編集したものをそのまま詰め込むだけではエラーになってしまう。これに対応するには、編集後のファイルサイズを取得してヘッダファイルの書き換えを行うか、Jarファイル自体を作り直す必要がある。新しいファイルを挿入する場合も同様である。
【００８６】
〔ＲＳＳの生成〕
RSS（RDF Site Summary または Rich Site Summary）は、ウェブサイトの概要をメタデータとして簡潔に記述するXMLフォーマットである。最近は、ウェブサイトにおいて新しい情報をRSSとして提供するところが増えてきている。多くのブログでもこの機能を提供している。RSSリーダなるものがあり、各サイトやブログのRSSを登録しておくと、各サイトの記事の一覧を取得することができる。Jarファイル内のコンテンツに変更があった場合にRSSを書き出す。なお、RSSは簡単なスクリプトで自動生成することが可能である。
【００８７】
〔ＲＳＳの例〕
<?xml version="1.0" encoding="utf-8" ?>
<rdf:RDF 
xmlns="http://purl.org/rss/1.0/" xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#" xml:lang="ja">
<channel rdf:about="http://machine.ricoh.co.jp/rss.rdf">
<title>Ricohカメラ</title>
<link>http://machine.ricoh.co.jp</link>
<description>Ricoh製のカメラについての情報を提供しています。</description>
<items>
<rdf:Seq>
<rdf:lirdf:resource="http://machine.ricoh.co.jp/camera/"/>
<rdf:lirdf:resource="http://machine.ricoh.co.jp/docs/manual.html"/>
</rdf:Seq>
</items>
</channel>
<item rdf:about="http://machine.ricoh.co.jp/camera/">
<title>歴代カメラ</title>
<link>http://machine.ricoh.co.jp/camera/</link>
<description>歴代のカメラの一覧です。</description>
</item>
<item rdf:about="http://machine.ricoh.co.jp/docs/manual.html">
<title>各カメラのマニュアル類</title>
<link>http://machine.ricoh.co.jp/docs/manual.html</link>
<description>歴代の製品のマニュアルの一覧です。</description>
</item>
</rdf:RDF>
【００８８】
これによるRSS生成の主な流れは以下の通りである。
HTMLのソースを読み込み
↓
タイトルや日付、説明文などの必要な情報の取り込み
↓
RSSの構文にしたがって出力
【００８９】
上記例にあげた形式でRSSのXMLファイルを出力してやることにより、RSSリーダで更新情報を把握することが可能になる。ウェブサーバプログラムとしては、RSSを書き出す機能を追加するのみでよく、GETコマンドでこのファイルを要求してきたプログラムに対して、ファイルを送信すればよい。つまり、通常のGETコマンドの処理と全く同じである。
【００９０】
〔複数文書のＲＳＳの統合〕
一つのマシン上で複数の文書が起動している場合、複数のRSSファイルが存在する。この場合はそれぞれのRSSを統合した新しいRSSファイルを提供する。つまり、RSSリーダなどがそのひとつのRSSファイルを読み込むことにより、複数の文書の更新情報がわかるようにする。
【００９１】
〔方法〕
先に述べたように、複数文書が起動する際には、最初に起動した文書にあるウェブサーバプログラムが複数文書分のコンテンツを提供する。RSSファイルの提供も同様である。ウェブサーバ機能を委託している文書は、文書の更新が行われたことを検知すると、RSSを生成し、委託先のプログラムに対してRSSファイル自体あるいは内容を通知する。通知するファイルの内容は例えば以下の通りである（上記と同様）。
【００９２】
<?xml version="1.0" encoding="utf-8" ?>
<rdf:RDF 
xmlns="http://purl.org/rss/1.0/" xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#" xml:lang="ja">
<channel rdf:about="http://machine.ricoh.co.jp/rss.rdf">
<title>Ricoh複写機</title>
<link>http://machine.ricoh.co.jp</link>
<description>Ricoh製の複写機についての情報を提供しています。</description>
<items>
<rdf:Seq>
<rdf:lirdf:resource="http://machine.ricoh.co.jp/copier/"/>
</rdf:Seq>
</items>
</channel>
<item rdf:about="http://machine.ricoh.co.jp/copier/">
<title>歴代複写機</title>
<link>http://machine.ricoh.co.jp/copier/</link>
<description>歴代の複写機の一覧です。</description>
</item>
</rdf:RDF>
【００９３】
ファイルもしくは情報を受信すると、委託を受けているプログラムは、自身のRSSファイル（最初の例）とマージして以下のようなRSSファイルを生成する。
【００９４】
<?xml version="1.0" encoding="utf-8" ?>
<rdf:RDF 
xmlns="http://purl.org/rss/1.0/" xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"  xml:lang="ja">
<channel rdf:about="http://machine.ricoh.co.jp/rss.rdf">
<title>文書更新情報</title>
<link>http://machine.ricoh.co.jp</link>
<description>machine上の文書の情報を提供しています。</description>
<items>
<rdf:Seq>
<rdf:lirdf:resource="http://machine.ricoh.co.jp/document1/camera/"/>
<rdf:lirdf:resource="http://machine.ricoh.co.jp/document1/docs/manual.html"/>
<rdf:lirdf:resource="http://machine.ricoh.co.jp/document2/copier/"/>
</rdf:Seq>
</items>
</channel>
<item rdf:about="http://machine.ricoh.co.jp/document1/camera/">
<title>歴代カメラ</title>
<link>http://machine.ricoh.co.jp/document1/camera/</link>
<description>歴代のカメラの一覧です。</description>
</item>
<item rdf:about="http://machine.ricoh.co.jp/document1/docs/manual.html">
<title>各カメラのマニュアル類</title>
<link>http://machine.ricoh.co.jp/document1/docs/manual.html</link>
<description>歴代の製品のマニュアルの一覧です。</description>
</item>
<item rdf:about="http://machine.ricoh.co.jp/document2/copier/">
<title>歴代複写機</title>
<link>http://machine.ricoh.co.jp/document2/copier/</link>
<description>歴代の複写機の一覧です。</description>
</item>
</rdf:RDF>
【００９５】
生成されるファイルのポイントは、リソースの指定で
http://machine.ricoh.co.jp/camera/
だったものが、統合の結果
http://machine.ricoh.co.jp/document1/camera/
のようにマシン名の下に仮想的に階層を作って文書ごとにＵＲＬを変えるところである。
【００９６】
このようにして文書同士でコンテンツ名が同じ場合でも対応できるようにする。ウェブサーバプログラムの委譲のところで述べたように、GETコマンドでdocument1以下がわかるので、対応するファイルを要求元に返すことができる。また、上記document1などの仮想的な階層名と文書とのテーブルはサーバプログラムがRSS受信時に関係を保持しておけばよい。
【００９７】
〔更新の通知〕
上記は、更新時のRSSの生成であるが、RSSファイルを生成する変わりに、サーバなどの指定のマシンに通知したり、メールを送信したりすることも可能である。ただしメールを送信する場合は、ユーザにメールサーバなどの設定を促す必要が生じる。
メールサーバの設定項目（文書保持ユーザへの入力促し)
・SMTPサーバ（送信用）
・POPもしくはIMAP4などの受信用サーバ（なしでもよい）
・ユーザID、パスワード
・その他詳細設定
以上の項目をユーザに予め設定させておく。
【００９８】
以上の設定が済んでいれば、RSSファイル記述と同様に、テキストで更新された情報に関してメールで通知することができる。なお、以上の設定は、このウェブサーバ機能付文書の所有者が設定する。他の、この文書の編集情報をメールで送信してもらいたいユーザは、メールアドレスのみを登録する。これによりサーバプログラムは、登録されたメールアドレスに対して、更新内容を送信する。
【００９９】
こうして本発明のカプセル化文書構造によれば、表現実体となる１又は２以上のデジタル情報ファイルと、デジタル情報ファイルの構造及び表示状態を特定する表示情報ファイルと、コンピュータによって共に解釈、実行され、デジタル情報を参照せずに特有の機能を実行するための機能動作プログラムを含む動作プログラムファイルとを具備し、ウェブブラウザの要求に応じてデジタル情報ファイル内のコンテンツをブラウザに送信するウェブサーバ機能を有するプログラムファイルがデジタル情報ファイルとともに単一の文書としてカプセル化されることにより、簡単な手段でインターネットサービスプロバイダを介することなく、ユーザが自分のマシンをウェブサーバ化、ブログサーバ化して、個人が所有する情報の公開を容易に行うことができるものである。
【０１００】
また、本発明のウェブサーバ機能を有する文書の作成方法によれば、マニュフェストファイルを記述し、マニュフェストファイル中のクラスファイルを指定し、マニュフェストファイルとコンテンツと、クラスファイルとしてのウェブサーバ機能を有するプログラムファイルを単一の文書としてカプセル化することにより、簡単な手段でインターネットサービスプロバイダを介することなく、ユーザが自分のマシンをウェブサーバ化、ブログサーバ化して、個人が所有する情報の公開を容易に行うことのできる文書を作成することができるものである。
【０１０１】
なお本発明は、上述の説明した実施形態に限定されるものではなく、特許請求の範囲の記載を逸脱しない範囲において、種々の変形が可能とされるものである。
【図面の簡単な説明】
【０１０２】
【図１】本発明によるカプセル化文書構造及びウェブサーバ機能を有する文書の作成方法をJarファイルに適用した場合のファイルの構造を示す構成図である。
【図２】そのclassファイルの位置を示す構成図である。
【図３】その機能の説明のための文書起動のフローチャート図である。
【図４】ウェブサーバプログラムのフローチャート図である。
【図５】複数のウェブサーバプログラムの起動のフローチャート図である。
【図６】他のウェブサーバプログラムに機能を委託するフローチャート図である。
【図７】その説明のための起動文書の一覧を示す説明図である。
【図８】委託を受けているウェブサーバプログラムのフローチャート図である。
【図９】委託しているウェブサーバプログラムのフローチャート図である。
【図１０】その説明のための図である。
【図１１】その説明のための図である。
【符号の説明】
【０１０３】
１…META-INFフォルダ、２…コンテンツフォルダ、３…プログラムフォルダ
【図１】
2007041702.tif 000003
【図２】
2007041702.tif 000004
【図３】
2007041702.tif 000005
【図４】
2007041702.tif 000006
【図５】
2007041702.tif 000007
【図６】
2007041702.tif 000008
【図７】
2007041702.tif 000009
【図８】
2007041702.tif 000010
【図９】
2007041702.tif 000011
【図１０】
2007041702.tif 000012
【図１１】
2007041702.tif 000013
【手続補正書】
【提出日】平成18年7月26日(2006.7.26)
【手続補正１】
【補正対象書類名】特許請求の範囲
【補正対象項目名】全文
【補正方法】変更
【補正の内容】
【特許請求の範囲】
【請求項１】
ウェブブラウザの要求に応じて表現実体となる１又は２以上のデジタル情報ファイルをブラウザに送信するウェブサーバ機能を有するプログラムファイルが前記デジタル情報ファイルとともに単一の文書としてカプセル化されている
ことを特徴とするカプセル化文書構造。
【請求項２】
表現実体となる１又は２以上のデジタル情報ファイルと、前記デジタル情報ファイルの表示状態を特定する表示情報ファイルと、コンピュータによって解釈、実行され、所定の機能を実行するための機能動作プログラムを含む動作プログラムファイルとを具備し、
ウェブブラウザの要求に応じて前記デジタル情報ファイルをブラウザに送信するウェブサーバ機能を有するプログラムファイルが前記デジタル情報ファイルとともに単一の文書としてカプセル化されている
ことを特徴とするカプセル化文書構造。
【請求項３】
前記表示情報ファイルに基づいて特定される表示状態で前記１又は２以上のデジタル情報ファイルを前記コンピュータのディスプレイ上に表示させるデジタル情報表示プログラムが単一の文書としてカプセル化されている
ことを特徴とする請求項１または２のいずれかに記載のカプセル化文書構造。
【請求項４】
前記デジタル情報ファイルを編集するコンテンツ編集機能を有するプログラムファイルが単一の文書としてカプセル化されている
ことを特徴とする請求項１または２のいずれかに記載のカプセル化文書構造。
【請求項５】
前記デジタル情報ファイルの更新情報を送信する更新情報送信機能を有するプログラムファイルが単一の文書としてカプセル化されている
ことを特徴とする請求項４に記載のカプセル化文書構造。
【請求項６】
前記ウェブサーバ機能を有するプログラムファイルは、既に他のウェブサーバプログラムが起動している場合には、そのウェブサーバプログラムに前記ウェブサーバ機能を委託する
ことを特徴とする請求項１または２のいずれかに記載のカプセル化文書構造。
【請求項７】
前記委託を受ける機能を含む前記ウェブサーバ機能を有するプログラムファイルが単一の文書としてカプセル化されている
ことを特徴とする請求項６に記載のカプセル化文書構造。
【請求項８】
保持しているデジタル情報ファイルに関するメタ情報を公開するメタ情報公開機能を有するプログラムファイルが単一の文書としてカプセル化されている
ことを特徴とする請求項１または２のいずれかに記載のカプセル化文書構造。
【請求項９】
マシン上で起動している文書のメタ情報を統合するメタ情報統合機能を有するプログラムファイルが単一の文書としてカプセル化されている
ことを特徴とする請求項８に記載のカプセル化文書構造。
【請求項１０】
マニュフェストファイルを記述し、
前記マニュフェストファイル中のクラスファイルを指定し、
前記マニュフェストファイルとコンテンツと、前記クラスファイルとしてのウェブサーバ機能を有するプログラムファイルを単一の文書としてカプセル化する
ことを特徴とするウェブサーバ機能を有する文書の作成方法。
【請求項１１】
前記ウェブサーバ機能を有するプログラムファイルは、既に他のウェブサーバプログラムが起動している場合には、そのウェブサーバプログラムに前記ウェブサーバ機能を委託する
ことを特徴とする請求項１０に記載のウェブサーバ機能を有する文書の作成方法。
【請求項１２】
前記委託を受ける機能を含む前記ウェブサーバ機能を有するプログラムファイルが単一の文書としてカプセル化されている
ことを特徴とする請求項１１に記載のウェブサーバ機能を有する文書の作成方法。
【手続補正２】
【補正対象書類名】明細書
【補正対象項目名】全文
【補正方法】変更
【補正の内容】
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、例えば個人からの情報の発信に使用して好適なカプセル化文書構造及びウェブサーバ機能を有する文書の作成方法に関する。詳しくは、インターネットサービスプロバイダを介することなく、ユーザが自分のマシンをウェブサーバ化、ブログサーバ化して情報を公開することができるようにしたものである。
【背景技術】
【０００２】
カプセル化文書作成の手段として、本願出願人は先に文書のデータ構造、記憶媒体及び情報処理装置の発明を出願している（例えば、特許文献１、２参照。）。
【０００３】
また、ウェブサーバとしては、ＩＩＳ（Internet Information Service）やApache等が実用化されているものである（例えば、非特許文献１参照。）。
【０００４】
すなわち、任意の電子データとその処理に用いるプログラムをカプセル化する技術は公知である。また、ウェブサーバを用いて、個人が所有する情報を発信する技術も一般的に知られているものである。
【特許文献１】特開２００３−１５９４１号公報
【特許文献２】特開２００３−９９４２４号公報
【非特許文献１】http://www.atmarkit.co.jp/flinux/rensai/apache01/apache01.html
【発明の開示】
【発明が解決しようとする課題】
【０００５】
インターネット関連技術の発展により、誰もが自分の文書を簡単に公開できるようになってきている。特に最近ではブログ（ウェブログ）が、文書の投稿の簡便さから急速に普及してきている。これら、現在ウェブ上にあるコンテンは、インターネットサービスプロバイダが提供しているサービスを利用したものが多く、ユーザが自分のマシンをウェブサーバ化、ブログサーバ化して情報を公開するのは現状ではそれほど多くないと言える。
【０００６】
しかしながら、一ユーザが個人で自分のマシンをウェブサーバ化して情報を公開する環境は徐々に整ってきている。サービスとして、ブロードバンドサービス、定額の常時接続サービス、固定ＩＰアドレス配布サービスなどがあり、またユーザが個人で所有するマシンもハイスペック化してきており、インターネット上の一サーバとして十分成り立つ。このような環境下において、個人でウェブサーバなどを立てているユーザもいることはいるが、インターネットユーザの数の多さに対して、非常に少ないのが現状である。
【０００７】
その原因としては、料金などの問題やセキュリティ面での脅威も考えられるが、ウェブサーバを立てることの敷居の高さの問題も一因であると考える。例えば、現状においてはユーザがウェブサーバを立てるとなると、マイクロソフトが提供しているＩＩＳ（Internet Information Service）か、オープンソースのApacheを利用するのが一般的であると思われるが、どちらも一ユーザが設定するのは大変である（実際にはそれほど大変ではないが、一般ユーザは大変であるとの印象を抱いてしまっている）。
【０００８】
さらにブロードバンド化が進み、ＩＰｖ６が普及してすべての機器がネットワークにつながってグローバルアドレスを持つような環境が予想される。そのような環境においては、個人や個々の機器による情報発信がますます重要になっていくであろう。
【０００９】
そういった環境においては、現状のように、文書を公開するのにわざわざインターネットサービスプロバイダのサービスを利用するのではなく、自分のマシン上で公開するのも一つの手段になるのではないかと考えられる。例えばブログを例にとると、現在の形態では、インターネットサービスプロバイダなどがサービスの一つとしてブログができるスペースをユーザに対して提供しており、ユーザは簡単な登録のみで自分専用のブログを開設できるようになっている。
【００１０】
この場合にユーザは手軽に、ほとんどコストをかけずにブログを開設できるというメリットがある一方、インターネットサービスプロバイダによるサービスであるため、ユーザの都合で仕様の変更を行ったりすることはほとんどできず、また、サービス自体が突然終了してしまう可能性もある。画像の登録容量に制限があるなど、使い勝手が必ずしも良いとは言えない。したがって、簡単に自分で文書を公開する手段さえあれば、他者のサービスに頼る必要がなくなるのではないかと考えられる。
【００１１】
また、オフィスでの用途を考えた場合、現状では個人でウェブサーバを立てるようなことはせず、情報部門もしくは部門のＩＴ関連技術に強いユーザがウェブサーバを構築し、サーバやコンテンツの管理を行っている。このシステムの問題点は、ユーザ数が多くなればなるほど管理がしにくく管理者およびサーバなどの機器に負担がかかる点と、ユーザが自分の管理下でコンテンツの公開および更新がしにくい点にある。
【００１２】
これに対して、ユーザが個人でコンテンツを管理してくれれば、サーバを用意する必要もなければ、バックアップなどの手間もユーザ側に委ねることができる。また、ユーザそれぞれが簡単に文書を公開、更新できるようになれば社内での情報共有やコミュニケーションも円滑になることが予想される。
【００１３】
この発明はこのような問題点に鑑みて成されたものであって、本発明の目的は、簡単な手段でインターネットサービスプロバイダを介することなく、ユーザが自分のマシンをウェブサーバ化、ブログサーバ化して、個人が所有する情報の公開を容易に行うことができるようにするものである。
【課題を解決するための手段】
【００１４】
上記の課題を解決し、本発明の目的を達成するため、請求項１に記載された発明は、ウェブブラウザの要求に応じて表現実体となる１又は２以上のデジタル情報ファイルをブラウザに送信するウェブサーバ機能を有するプログラムファイルがデジタル情報ファイルとともに単一の文書としてカプセル化されていることを特徴とするカプセル化文書構造である。
【００１５】
本発明の目的を達成するため、請求項２に記載された発明は、表現実体となる１又は２以上のデジタル情報ファイルと、デジタル情報ファイルの表示状態を特定する表示情報ファイルと、コンピュータによって解釈、実行され、所定の機能を実行するための機能動作プログラムを含む動作プログラムファイルとを具備し、ウェブブラウザの要求に応じてデジタル情報ファイルをブラウザに送信するウェブサーバ機能を有するプログラムファイルがデジタル情報ファイルとともに単一の文書としてカプセル化されていることを特徴とするカプセル化文書構造である。
【００１６】
また、請求項３に記載のカプセル化文書構造においては、表示情報ファイルに基づいて特定される表示状態で１又は２以上のデジタル情報ファイルをコンピュータのディスプレイ上に表示させるデジタル情報表示プログラムが単一の文書としてカプセル化されていることを特徴とするものである。
【００１７】
請求項４に記載のカプセル化文書構造においては、デジタル情報ファイルを編集するコンテンツ編集機能を有するプログラムファイルが単一の文書としてカプセル化されていることを特徴とするものである。
【００１８】
請求項５に記載のカプセル化文書構造においては、デジタル情報ファイルの更新情報を送信する更新情報送信機能を有するプログラムファイルが単一の文書としてカプセル化されていることを特徴とするものである。
【００１９】
請求項６に記載のカプセル化文書構造においては、ウェブサーバ機能を有するプログラムファイルは、既に他のウェブサーバプログラムが起動している場合には、そのウェブサーバプログラムにウェブサーバ機能を委託することを特徴とするものである。
【００２０】
請求項７に記載のカプセル化文書構造においては、委託を受ける機能を含むウェブサーバ機能を有するプログラムファイルが単一の文書としてカプセル化されていることを特徴とするものである。
【００２１】
請求項８に記載のカプセル化文書構造においては、保持しているデジタル情報ファイルに関するメタ情報を公開するメタ情報公開機能を有するプログラムファイルが単一の文書としてカプセル化されていることを特徴とするものである。
【００２２】
請求項９に記載のカプセル化文書構造においては、マシン上で起動している文書のメタ情報を統合するメタ情報統合機能を有するプログラムファイルが単一の文書としてカプセル化されていることを特徴とするものである。
【００２３】
さらに、本発明の目的を達成するため、請求項１０に記載された発明は、マニュフェストファイルを記述し、マニュフェストファイル中のクラスファイルを指定し、マニュフェストファイルとコンテンツと、クラスファイルとしてのウェブサーバ機能を有するプログラムファイルを単一の文書としてカプセル化することを特徴とするウェブサーバ機能を有する文書の作成方法である。
【００２４】
また、請求項１１に記載のウェブサーバ機能を有する文書の作成方法においては、ウェブサーバ機能を有するプログラムファイルは、既に他のウェブサーバプログラムが起動している場合には、そのウェブサーバプログラムにウェブサーバ機能を委託することを特徴とするものである。
【００２５】
請求項１２に記載のウェブサーバ機能を有する文書の作成方法においては、委託を受ける機能を含むウェブサーバ機能を有するプログラムファイルが単一の文書としてカプセル化されていることを特徴とするものである。
【発明の効果】
【００２６】
本発明のカプセル化文書構造及びウェブサーバ機能を有する文書の作成方法によれば、簡単な手段でインターネットサービスプロバイダを介することなく、ユーザが自分のマシンをウェブサーバ化、ブログサーバ化して、個人が所有する情報の公開を容易に行うことができる。
【発明を実施するための最良の形態】
【００２７】
以下、図面を参照して本発明を説明するに、図１には、本発明によるカプセル化文書構造及びウェブサーバ機能を有する文書の作成方法を、Jar（Java ARchive）ファイルに適用した場合のファイルの構造を示す。
【００２８】
図１において、Jarファイルは、現在広く普及しているZIPファイル形式に基づくファイル形式で、複数のファイルを一つにまとめた書庫ファイルである。Jarファイルには、Javaのプログラムモジュールであるclassファイルおよびテキスト、画像、音声ファイルなどを含めることができる。
【００２９】
〔Jarファイルの構造〕
Jarファイルの構造は図１に示した通りである。図１において、META-INFフォルダ１には、マニフェストファイルが格納されており、起動されたときに最初にロードするclassファイル情報が記述されている。コンテンツフォルダ２には、テキストファイルや画像、音声ファイルなどが格納される。フォルダ自体はここではなくてもよいが、他のファイル群（プログラムファイルなど）と区別するためにここでは設けた。またフォルダ自体は複数あっても構わない。
【００３０】
プログラムフォルダ３には、Javaのプログラムファイル群が格納される。通常、Javaのプログラムはパッケージ名に応じた階層で管理される。すなわち、例えばパッケージ名をjp.co.ricoh.project とした場合、そのパッケージ内で作成されるclassファイルは、図２に示したような階層の位置になる。従って、プログラムフォルダ３の名前は、この場合はjpになる。
【００３１】
〔実行可能Jarファイル〕
実行可能Jarファイルとは、例えばWindows上でファイルを開くときにダブルクリックするように、ダブルクリックすることによってマニフェストファイルに記述されたclassファイルがロードされ、実行されるファイルである。Jarファイルは、Javaの実行環境のインストール時に、Jarファイル（拡張子jar）と関連付けられる。またコマンドラインで
java -jar sample.jar 
とすることによって起動することもできる。
【００３２】
〔機能を有する文書の起動〕
機能を有する文書の起動までの流れを図３に示す。この流れは基本的には実行可能Jarファイルの起動と同じである。
【００３３】
ここで、機能を有する文書の構造は以下の通りである。
・マニフェストファイル（文書を起動する際に最初にロードするプログラム（classファイル）の名前が記述されている。）
・コンテンツ（ここでは、プログラムによってロード、表示されるコンテンツを指す。テキスト、画像、動画、音声ファイルなど。プログラムが解釈、処理できればフォーマットは問わない。）
【００３４】
・プログラム（コンテンツフォルダに含まれる文書（テキスト、画像など）をロード、表示するプログラムを格納する。文書を表示するだけでなく、文書に様々な機能を追加するプログラムもここに格納する。機能の例としては、例えば、通信機能、加筆機能、記録機能などがある。）
【００３５】
〔動作〕
ステップＳ１におけるダブルクリックもしくはコマンドラインからの命令によって、ステップＳ２でマニフェストファイルが取得され、ステップＳ３でメインクラスの情報が取得されると、ステップＳ４でメインクラスに記述されているclassファイルがロードされて、それぞれロードされたclassファイルが実行される。すなわち、ステップＳ５でウェブサーバプログラムが実行され、ステップＳ６でコンテンツ表示プログラムが十呼応され、ステップＳ７でその他の機能が実行される。これによって、コンテンツフォルダ内のテキストや画像が表示される。
【００３６】
このようにして、コンテンツが表示されるとともに、各種機能を実現するプログラムも同様にロードされ、使用準備が整う。これにより、例えばユーザのマウス操作に応じて、文中に下線を引くような機能が実現できる。
【００３７】
さらにウェブサーバ機能を有する文書について説明する。ここで、ウェブサーバ機能を有する文書とは、コンテンツにあたる部分にHTMLやJPEGなどのウェブブラウザで閲覧できるフォーマットを格納し、プログラムにあたる部分に、コンテンツを表示するプログラムと、ウェブブラウザからのアクセスに応じてコンテンツファイルをウェブブラウザに送信するウェブサーバプログラムとを格納したものである。
【００３８】
〔ウェブサーバプログラムの処理（一般）〕
ここでは、ウェブサーバプログラムの基本的な動作について述べる。まず、ウェブサーバプログラムはウェブブラウザからの要求に応じてテキストや画像を送信するのが基本機能である。ウェブブラウザからの要求とウェブサーバプログラムの応答の概要を以下に述べる。
【００３９】
ウェブブラウザとウェブサーバの関係は典型的なクライアント／サーバシステムであると言える。ウェブブラウザの要求に対してウェブサーバが応答するという形で処理がなされる。ウェブブラウザとウェブサーバプログラムとの通信はHTTP（Hyper Text Transfer Protocol）を用いて行われる。HTTPの仕様はRFC1945(HTTP/1.0)、RFC2068(HTTP/1.1)にて定められている（RFC: Request For Comments）。
【００４０】
ウェブブラウザとウェブサーバプログラム間の通信は、このHTTPというプロトコルを通じて、ウェブブラウザがHTML（Hyper Text Markup Language）ファイルをウェブサーバプログラムに対して要求し、ウェブサーバはその要求を解釈してHTMLファイルを送信することによって実現されている。ウェブブラウザは、受信したHTMLファイルのタグを解釈しコンテンツをレンダリングするなどの機能が必要であるが、ウェブサーバプログラムは、基本的にはウェブブラウザからのコマンドを解釈し、対応ファイルを送信するだけである。
【００４１】
〔ウェブブラウザからのファイルの要求（GETコマンド）〕
ウェブブラウザから要求されるコマンドはいくつかあるが、ここでは、もっとも基本的なGETコマンドについてのみ述べることにする。ウェブサーバプログラムの起動しているマシン名をウェブserverとすると、ウェブブラウザがウェブserver上のindex.htmlファイルにアクセスするには、
http://ウェブserver:6000/index.html
をopenすればよい（6000はポート番号）。
【００４２】
このときウェブブラウザは、ソケットを使って、マシンウェブserver上でポート6000を使用しているサーバとの間にコネクションをはり、
GET /index.html HTTP/1.0[CR LF(改行)]
のような命令をウェブサーバプログラムに対して送信する（行の末尾は開業コード）。また、GETコマンドの後には様々な付加情報が続くが、ここでは、触れない。
【００４３】
最後に空行(改行コード以外に文字を一切含まない行)を付加することによって、命令の最後であることをウェブサーバプログラムに通知する。因みにウェブブラウザがproxyサーバ経由でウェブserverにアクセスする場合には、GETコマンドは以下のようになり、proxyサーバが代理でウェブserverにアクセスする。
GET http://ウェブserver:6000/index.html HTTP/1.0[CR LF]
【００４４】
〔ＧＥＴコマンドの処理（ウェブサーバプログラム）〕
ウェブサーバプログラムはGETコマンドを受信したら、コマンドから要求されているファイルを特定し、対象ファイルを送信する。ファイルを送信するのに先立って、以下のヘッダ情報を送信する必要がある。
HTTP/1.0 200 OK[CR LF]
[CR LF]
【００４５】
なお、最初の行は、GET命令が正しく受理され、要求されたファイルを送信することを意味する。２行目は空行であり、ヘッダ情報の終了を意味する。これに続けて要求されたファイルを送信し、送信し終わったところでコネクションを張っていたソケットをクローズする。
【００４６】
また、要求されたファイルが存在しないなどの原因で、ウェブブラウザに何らかのエラー情報を返す場合には、以下のようなコマンドをHTTPの仕様に従って送信する。
HTTP/1.0 404 ファイル未検出[CR LF]
[CR LF]
<h2>要求されたファイルは見つかりませんでした。</h2>
なお、３行目はウェブブラウザに表示させるエラーメッセージである。
【００４７】
以上が、ウェブサーバプログラムの処理の流れである。HTTPには、他にも多くの取り決めがあるが、基本的には、ウェブブラウザがGETコマンドを発行することによってファイルを要求し、その要求をウェブサーバプログラムが解釈して、対象のファイルをウェブブラウザに対して送信することで成り立っている。
【００４８】
〔ウェブサーバプログラム（カプセル化文書内）の処理〕
さらに、文書内のウェブサーバプログラムの処理の流れについて、図４を参照して以下に述べる。基本的には先に述べたのと同様にウェブブラウザからの要求に応じて文書内のファイルをウェブブラウザに送信する。図４では、ウェブブラウザからの要求を受けた時点でスレッドを生成し、ウェブブラウザの要求に応じる動作について示した。
【００４９】
すなわち図４において、ステップＳ１１ではウェブブラウザからの要求が待ち受けられる。そして要求があるとステップＳ１２で処理スレッドが生成され、ステップＳ１３で要求情報が解析され、ステップＳ１４で要求ファイルが解析される。さらにステップＳ１５で要求されたファイルがあるか否か判断され、ある時（Ｙｅｓ）はステップＳ１６でヘッダ情報が送信され、ステップＳ１７でファイルが送信される。またステップＳ１５で要求されたファイルがない時（Ｎｏ）はステップＳ１８でエラーメッセージが送信される。
【００５０】
このようにして、一般的なウェブサーバプログラムにおいて、ウェブブラウザからのファイルの要求があった時の要求されたファイルの送信、及び要求されたファイルが無かった場合のエラーメッセージ送信の処理が行われる。
【００５１】
さらに、複数のウェブサーバ機能を有する文書を起動したときの処理について以下に説明する。まず、複数のウェブサーバ機能を有する文書を起動する場合について述べる。
【００５２】
〔複数のソケットの生成〕
ここで、複数のウェブサーバプログラムを起動するということは、複数のソケットを生成するということである。この場合に問題となるのは、同じポート番号で複数のソケットは生成できないということである。先に述べたように、ウェブサーバプログラムは、ＩＰアドレスとポート番号のセットでソケットを作成し、ウェブブラウザからの接続を待ち受ける。従ってウェブサーバプログラムを複数起動するには、ポート番号を変更して起動する必要がある。そうしなければ通常バインドエラーになってソケットを生成できない。
【００５３】
そこで、例えばすて図５に示すように、ソケットを生成する際にポート番号を変えてやることにより、複数のウェブサーバプログラムそれぞれがソケットを生成することが可能になる。すなわち図５においては、ステップＳ２１で起動が行われると、ステップＳ２２でソケットが生成される。そしてステップＳ２３でＯＫか否か判断され、ＯＫの時（Ｙｅｓ）はステップＳ２４で接続待ちとなる。
【００５４】
また、ステップＳ２３でＯＫでない時（Ｎｏ）はステップＳ２５でポート番号を変えてソケットが制裁され、さらにステップＳ２６でＯＫか否か判断され、ＯＫの時（Ｙｅｓ）はステップＳ２４で接続待ちとなる。さらにステップＳ２６でＯＫでない時（Ｎｏ）はステップＳ２５、Ｓ２６が繰り返し実行される。このようにして、複数のウェブサーバプログラムそれぞれがソケットを生成することが可能になる。
【００５５】
しかしながらこの方法の問題点としては、ウェブサーバプログラムに接続するウェブブラウザは、ポート番号を文書ごとに変更してアドレスを指定しなければならなくなるという点があげられる。ウェブサーバプログラムがどのポート番号でソケットを生成したかはウェブブラウザでは知ることはできないので、ポート番号は固定するのが望ましいのである。そこで、さらに複数の文書を起動した場合も一つのソケットで処理する方法について以下に説明する。
【００５６】
すなわち、複数のソケットを生成してしまう方法はあまり現実的ではないので、一つのマシンで複数のウェブサーバ機能を有する文書を起動しても、ソケットの生成は一つで済む方法について図６を参照して説明する。まず、この図６において、ステップＳ２１で起動が行われると、ステップＳ２２でソケットが生成される。そしてステップＳ２３でＯＫか否か判断され、ＯＫの時（Ｙｅｓ）はステップＳ２４で接続待ちとなる。ここまでの処理は図５の場合と同じである。
【００５７】
従ってこの場合に、マシン上で最初に起動するウェブサーバ機能を有する文書は、他にそのポートを使用している文書がないためにウェブサーバプログラムにおいてソケットを生成することができる。これに対して、マシン上において２番目以降に起動するウェブサーバ機能を有する文書は、作成しようとするソケットのポート番号がすでに最初の文書において使用されているために、ソケットを生成することができず、エラーを発生する。
【００５８】
そこで、このエラーを発生した場合の処理として、すでに起動しているウェブサーバプログラムに対して委託要求を発信する。この要求を受信したウェブサーバプログラムは、応答を返し、委託を受ける旨を要求してきたウェブサーバプログラムに対して通知する。このため上述のステップＳ２３でＯＫでない時（Ｎｏ）は、ステップＳ２７で最初に起動したウェブサーバプログラムに委託を行って、ステップＳ２８でこの処理は終了される。
【００５９】
このようにして、２番目以降に起動するウェブサーバ機能を有する文書は、すでに起動しているウェブサーバプログラムに対してウェブサーバ機能を委託することによって、一つのマシンで複数のウェブサーバ機能を有する文書を起動しても、ソケットの生成は一つで済ませることができる。さらに、委託を受けたウェブサーバプログラムでの処理は以下のように行われる。
【００６０】
〔委託を受けたウェブサーバプログラム〕
委託を受けたウェブサーバプログラムは、自文書内のコンテンツのみならず、委託を受けた文書(Jarファイル)の文書内コンテンツをウェブブラウザに対して送信する処理も受け持つ。委託を受けた際には、図７に示したような文書の一覧を示すHTML文書を生成する。図７は二つの文書から委託された場合を示している。図７中のdocument1などは、任意である。一意になる名前をつける。文書中からタイトルを抜き出して表示しても良いが、リンクは同じ文書を指し示すことがないようにする必要がある。
【００６１】
従って図７において、複数の文書が起動している場合には、例えば、ウェブブラウザでマシン名をmachineとすると
http://machine:8080/
をopenすることにより、起動している文書の一覧が記述されたHTML文書を表示する。
【００６２】
ここで、一覧のリンクは、例えば、
http://machine:8080/document1/index.html 
http://machine:8080/document2/index.html 
http://machine:8080/document3/index.html 
などとなり、閲覧したい文書をクリックすることにより、ユーザは異なる文書のコンテンツを閲覧することができる。
【００６３】
さらに、委託を受けているウェブサーバプログラムの処理としては、図８に示すようにユーザのクリックイベントにより、ウェブブラウザが
http://machine:8080/document3/index.html 
をopenするので、ウェブサーバプログラムは、コマンドとして、
GET /document3/index.html HTTP/1.1
を取得することができる。
【００６４】
すなわち図８において、ステップＳ３１ではウェブブラウザからの要求が待ち受けられる。そして要求があるとステップＳ３２で処理スレッドが生成され、ステップＳ３３で要求情報が解析される。ここまでは図４のステップＳ１１〜Ｓ１３と同じである。そこで、さらにステップＳ３４で自文書内のファイルか否か判断され、自文書内のファイルである時（Ｙｅｓ）はステップＳ３５で要求ファイルが解析される。
【００６５】
また、ステップＳ３６で要求されたファイルがあるか否か判断され、ある時（Ｙｅｓ）はステップＳ３７でヘッダ情報が送信され、ステップＳ３８でファイルが送信される。またステップＳ３６で要求されたファイルがない時（Ｎｏ）はステップＳ３９でエラーメッセージが送信される。このようにして、要求されたファイルが自文書内であった時の要求されたファイルの送信、及び要求されたファイルが無かった場合のエラーメッセージ送信の処理が行われる。以上の処理は、図４のステップＳ１５〜Ｓ１８と同じである。
【００６６】
これに対して、ステップＳ３４で要求されたファイルが自文書内でなかった時（Ｎｏ）は、ステップＳ４０で他文書にファイルの要求を行い、ステップＳ４１でファイルがＯＫか否か判断される。そしてファイルがＯＫの時（Ｙｅｓ）はステップＳ４２でファイルが受信され、ステップＳ３７でヘッダ情報が送信され、ステップＳ３８でファイルが送信される。またステップＳ４１で要求されたファイルＯＫでない時（Ｎｏ）はステップＳ４３でエラーメッセージが送信される。
【００６７】
このようにして、ステップＳ３４で要求されたファイルが自文書内でなかった時に、他文書からのファイルを受信して、要求されたファイルの送信、及び要求されたファイルが無かった場合のエラーメッセージ送信の処理が行われる。すなわち、上記コマンド中のdocument3により、どの文書の要求を受けているかが判断できるので、対応する文書（document3）にアクセスし、document3からindex.html を受け取って、それをウェブブラウザに送信することで、複数の文書のコンテンツ処理を一つのウェブサーバプログラムが請け負うことが可能になる。
【００６８】
つまり、委託を受けているウェブサーバプログラムは、GETコマンドを解析した結果、自文書内のコンテンツ要求であれば、図４に示した通常とほぼ同じ動作を行い、GETコマンドを解析した結果、他文書内のコンテンツであった場合には、その文書に対してコンテンツの要求を行い、ファイルをその文書から受信し、受信したファイルをウェブブラウザに対して送信する。さらに、委託しているウェブサーバプログラムの処理の流れについては図９に示す。
【００６９】
すなわち図９において、ステップＳ５１では他のプログラムからのコンテンツ要求が待ち受けられる。そして要求があるとステップＳ５２で処理スレッドが生成され、ステップＳ５３で要求情報が解析され、ステップＳ５４で要求ファイルが解析される。さらに、ステップＳ５５で要求されたファイルがあるか否か判断され、ある時（Ｙｅｓ）はステップＳ５６でファイルが送信される。またステップＳ５５で要求されたファイルがない時（Ｎｏ）はステップＳ５７でエラーメッセージが送信される。
【００７０】
このようにして、自分でソケットを生成できない場合は、他のウェブサーバプログラムからコンテンツ要求を受け付けることのできるソケットを生成し待ち受ける。そして、他のウェブサーバプログラムからコンテンツの要求があった場合に要求を解析し、要求に応じたファイルを取得して送信する。また、要求されたファイルが存在しない場合にはエラーメッセージを送信する。
【００７１】
さらに、委託を受けているウェブサーバ機能を有する文書が閉じた場合の処理を以下に説明する。すなわち、委託を受けているウェブサーバ機能を有する文書中のプログラムがクローズイベントを取得した場合は、ソケットをクローズするとともに他に起動している文書があればその文書に委託し、ソケットを作成させる。この様子を図１０に示す。なおこの場合には、先に述べたような起動文書の情報もあわせて送信して終了する。
【００７２】
また、ウェブサーバ機能を委託している文書が閉じたときの処理は以下に説明する。すなわち、ウェブサーバ機能を他の文書に委託している場合は、その委託先のプログラムに終了することを通知する。この様子を図１１に示す。ここで、終了情報を受けたウェブサーバ機能を委託されているサーバは、図７に示した文書リンク情報から該当する文書を削除し、リンクから外す。
【００７３】
従って、上述した本発明の実施形態において、簡単な手段でインターネットサービスプロバイダを介することなく、ユーザが自分のマシンをウェブサーバ化、ブログサーバ化して、個人が所有する情報の公開を容易に行うことができる。
【００７４】
さらに以下には、ウェブサーバ機能を有する文書の作成方法を説明する。ここでは最初に、マニフェストファイルの記述例を以下に示す。
Manifest-Version: 1.0
Main-Class: jp.co.ricoh.project.AppMain
Created-By: 1.3.1 (Sun Microsystems Inc.)
【００７５】
ここで２行目はmain関数のあるclassファイル名である。これを指定しておくことによって起動時に最初にロードされるclassファイルを決定することができる。３行目はJavaのバージョンおよびサプライヤである。また、マニフェストファイルと、コンテンツ、およびプログラムファイル群（classファイル群）をZIP化して一つにする。ファイル拡張子はjarとする。
【００７６】
ZIP化の方法を以下に示す。
ZIP化するファイルの読み込みおよびバイト配列への格納
↓
ファイル書き出しストリーム生成
↓
ZIPの書き出しストリームを生成してファイル書き出しストリームを渡す
↓
ZIPエントリを生成しZIPの書き出しストリームに登録
↓
ZIPの書き出しストリームに先のバイト配列を書き込み
↓
ZIPエントリのクローズ
↓
終了処理
【００７７】
この処理は一つのファイルをZIP化する際の基本的な処理の流れであるが、複数ファイルに渡っても基本的な処理は同じである。以上のようにして、マニフェストファイル、コンテンツ、ウェブサーバ機能を提供するプログラム群を一つの書庫ファイルとして扱うことができる。
【００７８】
さらに、JavaのSDK（Software Development Kit）をインストールしてある環境であれば、
jar cvfm sample.jar manifest.mf *.*
などとコマンドを打つことにより、容易にJarファイルの生成が可能である。つまり、Javaプログラミングで言えば、Runtimeの外部プログラム呼び出しの文字列に
jar cvfm sample.jar manifest.mf *.*
としてやることによってJarファイルの作成が可能である。
【００７９】
さらに、本発明における内部コンテンツの作成方法及び編集方法について説明する。すなわち、ウェブブラウザを使って編集できれば、文書さえ起動しておけば、ネットワークにつながっていればどこからでも作成、編集ができて便利である。ここでは一番基本的なPOST（Power On Self Test）コマンドを利用した編集方法について述べる。これまでは、GETコマンドでウェブサーバプログラムにファイルを送ってもらっていたが、編集するにはウェブサーバプログラムがPOSTコマンドの処理能力が必要である。ただし、実際にはGETでも投稿可である。
【００８０】
そこで、POSTコマンドの処理は、ＣＧＩ（Common Gateway Interface）が行う場合が多い。ＣＧＩはデータ処理用のプログラムで掲示板やカウンタの機能を提供していることが多い。Perl（Practical Extraction and Report Language）で記述されることが多いが、要はPOSTコマンドを処理できれば良いのでプログラム言語は何でも構わない。またスクリプトとして埋め込んでしまう方法もある。
【００８１】
POSTコマンドは主に記事を投稿する際にウェブブラウザが発行するコマンドである。つまり、サーバプログラムに対してデータを送信するためのコマンドである。POSTコマンドを利用したウェブサーバプログラムとウェブブラウザプログラムのデータのやり取りを以下に示す。
【００８２】
まず、ウェブブラウザがGETコマンドで編集用ページを取得する。ここでは、例えば文書中「作成」などと書いたリンクをクリックするとサーバプログラムが送信してくるHTMLである(実際にはログイン認証を経る)。このような取得を行うHTMLの例を以下に示す。
【００８３】
<html>
<head>
</head>
<body>
<form action = "http://machine:8080/programs/post" method = "post">
<p>
<textarea name="textarea" rows=5 cols=50></textarea><br>
<input type = "submit" value = "send"> <input type = "reset" value = "reset"><br>
</p>
</form>
</body>
</html>
【００８４】
従って、ウェブブラウザがこのHTMLを受信し、ユーザがテキストエリアに文字を入力し、[send］ボタンを押すことによって、ウェブサーバプログラムに対してテキストエリア内に記述された情報が渡される。ウェブサーバプログラムはそれを解釈することでコンテンツに反映することができる。
【００８５】
なお、直接HTMLを編集する方法もあるが、その場合はHTML編集プログラムを呼び出して編集する。例えばJavaであれば、外部プログラムを呼び出すプロセスを生成可能である。この際にどの外部プログラムを呼び出すかは、ユーザによる指定が必要である。
【００８６】
ただし、編集及びファイル新規作成時の問題点としては、Zipファイルにはヘッダファイルがあり、そのファイルにはZip化されているファイル名とサイズなどが記載されている。このファイルと実際のファイルの整合性が取れないと単に編集したものをそのまま詰め込むだけではエラーになってしまう。これに対応するには、編集後のファイルサイズを取得してヘッダファイルの書き換えを行うか、Jarファイル自体を作り直す必要がある。新しいファイルを挿入する場合も同様である。
【００８７】
〔ＲＳＳの生成〕
RSS（RDF Site Summary または Rich Site Summary）は、ウェブサイトの概要をメタデータとして簡潔に記述するXMLフォーマットである。最近は、ウェブサイトにおいて新しい情報をRSSとして提供するところが増えてきている。多くのブログでもこの機能を提供している。RSSリーダなるものがあり、各サイトやブログのRSSを登録しておくと、各サイトの記事の一覧を取得することができる。Jarファイル内のコンテンツに変更があった場合にRSSを書き出す。なお、RSSは簡単なスクリプトで自動生成することが可能である。
【００８８】
〔ＲＳＳの例〕
<?xml version="1.0" encoding="utf-8" ?>
<rdf:RDF 
xmlns="http://purl.org/rss/1.0/" xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#" xml:lang="ja">
<channel rdf:about="http://machine.ricoh.co.jp/rss.rdf">
<title>Ricohカメラ</title>
<link>http://machine.ricoh.co.jp</link>
<description>Ricoh製のカメラについての情報を提供しています。</description>
<items>
<rdf:Seq>
<rdf:li rdf:resource="http://machine.ricoh.co.jp/camera/"/>
<rdf:li rdf:resource="http://machine.ricoh.co.jp/docs/manual.html"/>
</rdf:Seq>
</items>
</channel>
<item rdf:about="http://machine.ricoh.co.jp/camera/">
<title>歴代カメラ</title>
<link>http://machine.ricoh.co.jp/camera/</link>
<description>歴代のカメラの一覧です。</description>
</item>
<item rdf:about="http://machine.ricoh.co.jp/docs/manual.html">
<title>各カメラのマニュアル類</title>
<link>http://machine.ricoh.co.jp/docs/manual.html</link>
<description>歴代の製品のマニュアルの一覧です。</description>
</item>
</rdf:RDF>
【００８９】
これによるRSS生成の主な流れは以下の通りである。
HTMLのソースを読み込み
↓
タイトルや日付、説明文などの必要な情報の取り込み
↓
RSSの構文にしたがって出力
【００９０】
上記例にあげた形式でRSSのXMLファイルを出力してやることにより、RSSリーダで更新情報を把握することが可能になる。ウェブサーバプログラムとしては、RSSを書き出す機能を追加するのみでよく、GETコマンドでこのファイルを要求してきたプログラムに対して、ファイルを送信すればよい。つまり、通常のGETコマンドの処理と全く同じである。
【００９１】
〔複数文書のＲＳＳの統合〕
一つのマシン上で複数の文書が起動している場合、複数のRSSファイルが存在する。この場合はそれぞれのRSSを統合した新しいRSSファイルを提供する。つまり、RSSリーダなどがそのひとつのRSSファイルを読み込むことにより、複数の文書の更新情報がわかるようにする。
【００９２】
〔方法〕
先に述べたように、複数文書が起動する際には、最初に起動した文書にあるウェブサーバプログラムが複数文書分のコンテンツを提供する。RSSファイルの提供も同様である。ウェブサーバ機能を委託している文書は、文書の更新が行われたことを検知すると、RSSを生成し、委託先のプログラムに対してRSSファイル自体あるいは内容を通知する。通知するファイルの内容は例えば以下の通りである（上記と同様）。
【００９３】
<?xml version="1.0" encoding="utf-8" ?>
<rdf:RDF 
xmlns="http://purl.org/rss/1.0/" xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#" xml:lang="ja">
<channel rdf:about="http://machine.ricoh.co.jp/rss.rdf">
<title>Ricoh複写機</title>
<link>http://machine.ricoh.co.jp</link>
<description>Ricoh製の複写機についての情報を提供しています。</description>
<items>
<rdf:Seq>
<rdf:li rdf:resource="http://machine.ricoh.co.jp/copier/"/>
</rdf:Seq>
</items>
</channel>
<item rdf:about="http://machine.ricoh.co.jp/copier/">
<title>歴代複写機</title>
<link>http://machine.ricoh.co.jp/copier/</link>
<description>歴代の複写機の一覧です。</description>
</item>
</rdf:RDF>
【００９４】
ファイルもしくは情報を受信すると、委託を受けているプログラムは、自身のRSSファイル（最初の例）とマージして以下のようなRSSファイルを生成する。
【００９５】
<?xml version="1.0" encoding="utf-8" ?>
<rdf:RDF 
xmlns="http://purl.org/rss/1.0/" xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#" xml:lang="ja">
<channel rdf:about="http://machine.ricoh.co.jp/rss.rdf">
<title>文書更新情報</title>
<link>http://machine.ricoh.co.jp</link>
<description>machine上の文書の情報を提供しています。</description>
<items>
<rdf:Seq>
<rdf:li rdf:resource="http://machine.ricoh.co.jp/document1/camera/"/>
<rdf:li rdf:resource="http://machine.ricoh.co.jp/document1/docs/manual.html"/>
<rdf:li rdf:resource="http://machine.ricoh.co.jp/document2/copier/"/>
</rdf:Seq>
</items>
</channel>
<item rdf:about="http://machine.ricoh.co.jp/document1/camera/">
<title>歴代カメラ</title>
<link>http://machine.ricoh.co.jp/document1/camera/</link>
<description>歴代のカメラの一覧です。</description>
</item>
<item rdf:about="http://machine.ricoh.co.jp/document1/docs/manual.html">
<title>各カメラのマニュアル類</title>
<link>http://machine.ricoh.co.jp/document1/docs/manual.html</link>
<description>歴代の製品のマニュアルの一覧です。</description>
</item>
<item rdf:about="http://machine.ricoh.co.jp/document2/copier/">
<title>歴代複写機</title>
<link>http://machine.ricoh.co.jp/document2/copier/</link>
<description>歴代の複写機の一覧です。</description>
</item>
</rdf:RDF>
【００９６】
生成されるファイルのポイントは、リソースの指定で
http://machine.ricoh.co.jp/camera/
だったものが、統合の結果
http://machine.ricoh.co.jp/document1/camera/
のようにマシン名の下に仮想的に階層を作って文書ごとにＵＲＬを変えるところである。
【００９７】
このようにして文書同士でコンテンツ名が同じ場合でも対応できるようにする。ウェブサーバプログラムの委譲のところで述べたように、GETコマンドでdocument1以下がわかるので、対応するファイルを要求元に返すことができる。また、上記document1などの仮想的な階層名と文書とのテーブルはサーバプログラムがRSS受信時に関係を保持しておけばよい。
【００９８】
〔更新の通知〕
上記は、更新時のRSSの生成であるが、RSSファイルを生成する変わりに、サーバなどの指定のマシンに通知したり、メールを送信したりすることも可能である。ただしメールを送信する場合は、ユーザにメールサーバなどの設定を促す必要が生じる。
メールサーバの設定項目（文書保持ユーザへの入力促し)
・SMTPサーバ（送信用）
・POPもしくはIMAP4などの受信用サーバ（なしでもよい）
・ユーザID、パスワード
・その他詳細設定
以上の項目をユーザに予め設定させておく。
【００９９】
以上の設定が済んでいれば、RSSファイル記述と同様に、テキストで更新された情報に関してメールで通知することができる。なお、以上の設定は、このウェブサーバ機能付文書の所有者が設定する。他の、この文書の編集情報をメールで送信してもらいたいユーザは、メールアドレスのみを登録する。これによりサーバプログラムは、登録されたメールアドレスに対して、更新内容を送信する。
【０１００】
こうして本発明のカプセル化文書構造によれば、ウェブブラウザの要求に応じて表現実体となる１又は２以上のデジタル情報ファイルをブラウザに送信するウェブサーバ機能を有するプログラムファイルがデジタル情報ファイルとともに単一の文書としてカプセル化されていることにより、簡単な手段でインターネットサービスプロバイダを介することなく、ユーザが自分のマシンをウェブサーバ化、ブログサーバ化して、個人が所有する情報の公開を容易に行うことができるものである。
【０１０１】
また、本発明のカプセル化文書構造によれば、表現実体となる１又は２以上のデジタル情報ファイルと、デジタル情報ファイルの構造及び表示状態を特定する表示情報ファイルと、コンピュータによって共に解釈、実行され、デジタル情報を参照せずに特有の機能を実行するための機能動作プログラムを含む動作プログラムファイルとを具備し、ウェブブラウザの要求に応じてデジタル情報ファイル内のコンテンツをブラウザに送信するウェブサーバ機能を有するプログラムファイルがデジタル情報ファイルとともに単一の文書としてカプセル化されることにより、簡単な手段でインターネットサービスプロバイダを介することなく、ユーザが自分のマシンをウェブサーバ化、ブログサーバ化して、個人が所有する情報の公開を容易に行うことができるものである。
【０１０２】
さらに、本発明のウェブサーバ機能を有する文書の作成方法によれば、マニュフェストファイルを記述し、マニュフェストファイル中のクラスファイルを指定し、マニュフェストファイルとコンテンツと、クラスファイルとしてのウェブサーバ機能を有するプログラムファイルを単一の文書としてカプセル化することにより、簡単な手段でインターネットサービスプロバイダを介することなく、ユーザが自分のマシンをウェブサーバ化、ブログサーバ化して、個人が所有する情報の公開を容易に行うことのできる文書を作成することができるものである。
【０１０３】
なお本発明は、上述の説明した実施形態に限定されるものではなく、特許請求の範囲の記載を逸脱しない範囲において、種々の変形が可能とされるものである。
【図面の簡単な説明】
【０１０４】
【図１】本発明によるカプセル化文書構造及びウェブサーバ機能を有する文書の作成方法をJarファイルに適用した場合のファイルの構造を示す構成図である。
【図２】そのclassファイルの位置を示す構成図である。
【図３】その機能の説明のための文書起動のフローチャート図である。
【図４】ウェブサーバプログラムのフローチャート図である。
【図５】複数のウェブサーバプログラムの起動のフローチャート図である。
【図６】他のウェブサーバプログラムに機能を委託するフローチャート図である。
【図７】その説明のための起動文書の一覧を示す説明図である。
【図８】委託を受けているウェブサーバプログラムのフローチャート図である。
【図９】委託しているウェブサーバプログラムのフローチャート図である。
【図１０】その説明のための図である。
【図１１】その説明のための図である。
【符号の説明】
【０１０５】
１…META-INFフォルダ、２…コンテンツフォルダ、３…プログラムフォルダ