JP2007122609A

JP2007122609A - 構造化文書、コンテンツ配信サーバ装置及びコンテンツ配信システム

Info

Publication number: JP2007122609A
Application number: JP2005316897A
Authority: JP
Inventors: Masami Mori; 雅巳森; Akira Suzuki; 明鈴木; Yushi Hasegawa; 雄史長谷川
Original assignee: Ricoh Co Ltd
Current assignee: Ricoh Co Ltd
Priority date: 2005-10-31
Filing date: 2005-10-31
Publication date: 2007-05-17
Also published as: US20070106694A1

Abstract

【課題】外部リソースを文書内に取り込んで、情報をアーカイブする。
【解決手段】インターネット１００にはＷｅｂサーバ１と端末装置２が接続され、この端末装置２に情報蓄積型文書２１が設けられる。またインターネット１００にはＬＡＮ２００が接続され、このＬＡＮ２００に、ファイルサーバ３と端末装置４、５が接続され、これらの端末装置４、５にも情報蓄積型文書４１、５１が設けられる。このシステムにおいて、文書中のプログラムファイル（外部リース取得プログラム）が、インターネット１００上のＷｅｂサーバ（サイト）１にアクセスして情報を取得したり、ＬＡＮ２００上のファイルサーバ３からファイルを取得したりして文書内に取り込んでいくものである。この場合に、情報蓄積型文書２１、４１、５１は通常の文書と同様に端末装置２、４、５上で起動され、外部リソースを取得する。
【選択図】図４

Description

本発明は、例えばウェブマガジンやメールマガジンの配布や購読等に使用して好適な構造化文書、コンテンツ配信サーバ装置及びコンテンツ配信システムに関する。詳しくは、コンテンツとプログラムを一体化した構造化文書を用いて必要なプログラムを設けることにより、配布されたウェブマガジンやメールマガジンの保存やその他の利用が良好に行われるようにしたものである。

従来の技術では、例えばＷｅｂページを巡回して得られた情報を内容に応じて自動的に整理分類することが行われている（例えば、特許文献１参照。）。

また、本願出願人は、先にプログラムを付加した文書構造として構造化文書（カプセル化文書）を提案している（例えば、特許文献２参照。）。

すなわち、従来は、例えばＷｅｂページを巡回して得られた情報を内容に応じて自動的に整理分類しているものである。一方、本願出願人は、プログラムを付加した文書構造として構造化文書（カプセル化文書）を提案しているものである。
特開２００４−３１０３７８号公報特開２００３−１５９４１号公報

〔Ｗｅｂサイトのアーカイブ〕
インターネット上では日々様々な情報が提供され続けており、ユーザは、自分に有益な情報を提供してくれるサイトをブックマークしたり、ＲＳＳ（Rich Site Summary）フィードを利用したりして最新の情報を取得できるようにしている。しかしながら、インターネット上の情報は、各個人が非営利で個人の趣味的に提供している場合が多く、突然閉鎖されてしまったり、突然コンテンツの内容が変わってしまったりといったことが少なくない。

また、かつてブックマークしておいたリンクが、現在も有効なリンクである確率は高くないのが現状であり、ＵＲＬ（Uniform Resource Locator）の平均寿命は約４４日であるということも言われている。また、ニュースサイトなどでは情報が逐一更新されていくため、掲載されている情報は常に変化しているに等しく、例えば本や新聞、雑誌などのように決まったコンテンツでひとくくりになっているようなものではないため、例えば「昨日の１５時」に掲載されていた状態を見ようと思っても記録していない限り不可能である。

これらの問題を鑑みて、ウエブアーカイブ（http://www.archive.org/）などの活動も行われている。これは、すぐに消えて行ってしまう情報をできるだけ保存していこうと言う活動であり、上記に述べたような問題（の一部）に対して取り組んでいる良い例である。

しかしながらユーザの立場で考えた場合に、インターネット全体のアーカイブは不必要であり、ハードディスクの容量は有限でもあることから、自分の好みのサイトの情報だけがアーカイブされていればそれでよいという側面もある。現状ではアーカイブするには自分でサイト情報を保存するか、定期的にデータを収集するソフトを用いて収集するしかない。定期的にデータを収集するソフトの問題点は、データの保存方法にある。指定されたフォルダにすべてファイルをばらばらに格納していくだけである。

これに対して、上述の特許文献１のようにＷｅｂサイトを巡回して情報を収集するツール（フリーもしくはシェアウエア）はいくつかインターネット上で公開されている。しかしこれらのツールの問題点としては、情報を収集することはできるが、収集してきたものは、例えばＷｅｂサイトであれば、そのフォルダ構造で収集するので、実体はバラバラになってしまって扱いにくく、実体としてひとくくりになっておらず、例えば複数のサイトの情報を収集する場合などはひとまとめになりにくいといった問題がある。

〔ＬＡＮ上のデータのアーカイブ〕
企業などではＬＡＮ（Local Area Network）が構築されているのが当たり前であり、ファイルサーバなどがいくつかあって、ファイルを共有したりしている。このような環境下において、知らないうちにファイルが追加されていたり、フォルダの階層が深くなっていたりして閲覧が面倒であることもある。また、ＬＡＮ上においてもＷｅｂサーバがあって日々情報が更新されているが、インターネット上と同様に、ある時点でどんな情報が掲載されていたかは後になっては確認することが不可能である。

〔メールマガジンのアーカイブ〕
必要な情報を取得するためにメールマガジンを購読しているユーザも少なくない。個人の好みの情報を定期的に配信してくれるメールマガジンは、いちいちＵＲＬを入力してアクティブに情報にアクセスしにいかずに済むため、便利な仕組みではある。

しかしながら、何本ものメールマガジンを登録してしまうと、メーラーの受信ボックスがすぐに未読文書で溢れてしまう。また、メールマガジンはその文面において、他の広告情報とともに少しずつ配信されるケースが多いため、後からまとめて内容を吟味しにくいといった問題がある。また、メールマガジンのアーカイブと称してバックナンバーをＷｅｂに掲載しているケースも見受けられる。この場合、第ＸＸ号というように、その回毎にバラバラにリンクが設けられており、まとめて読むのは大変である。

一般にはメールを保存管理するためのメールアーカイブソフトがある。また、Lotus Notes（登録商標）にはメールアーカイブ機能がある。これらのメールアーカイブソフト、機能の特徴は、受信メールなどを保存し、バックアップするというものである。これらのソフト、機能の問題点は、メールはテキストベースもしくはＨＴＭＬ（HyperText Markup Language）といった標準的なフォーマットであるにもかかわらず、メールをアーカイブしたメーラーでしか閲覧できないと言う点である。

〔他文書との同期を取りながらのアーカイブ〕
また、近年、テレビ会議などで文書を共有することにより、リモート環境でのコラボレーションの質の向上が図られている。現状での文書の共有の仕方は以下が挙げられる。
(１)フォルダを同期
(２)共有フォルダを利用
(３)文書を画像化して画像を共有
(４)ある地点の文書を映像化し、他の地点に送信
(５)特定フォーマットの文書表示の同期

しかしながら、これらの文書共有方法では、いくつかの問題がある。すなわち、(１)及び(２)に関しては、フォルダを共有しているだけで文書を共有していないため、コミュニケーションがしにくいといった問題がある。また(３)に関しては、文書が画像化されてしまっているため、大きく拡大すると表示がぎざぎざになるといった画像特有の問題の影響を受ける。

さらに(４)に関しては、文書を保持している地点は良いが、文書の映像だけ送られてくる地点のユーザは文書を操作できず、良好なコミュニケーションができないといった問題がある。また(５)に関しては、表示の同期ができる文書フォーマットが限られており、他のフォーマットはやはり画像化するなどして表示の同期を行わざるを得ないという問題がある。

なお、最近では上記の問題点を解決するために、多地点でそれぞれ同じ文書を保持し、文書間で情報をやりとりして文書を同期させるという技術が紹介されている。(５)もこの範疇にある。この技術を用いると、(４)のような主従関係もなく文書を操作することができるので、良好なコミュニケーションが実現できる。しかし、この技術においても、他のリソースを追加してコミュニケーションしたり、検索した結果を同期したりといったことはできないものであった。

この発明はこのような問題点に鑑みて成されたものであって、本発明の目的は、ＷｅｂやＬＡＮ上にあるデータをはじめとする外部データを取り込んでパッケージ化して文書化し、文書化したものでさらに同期を行えるようにすることによって、データの記録やコラボレーションを円滑に行うことのできる文書の生成が行われるようにするものである。

上記の課題を解決し、本発明の目的を達成するため、請求項１に記載された発明は、少なくともプログラム部とコンテンツ部を含む構造化文書であって、プログラム部に設けられるプログラムには、任意のコンテンツ配信サーバ装置にアクセスしてコンテンツ配信サーバ装置に用意されたコンテンツを外部リソースとして取り込む機能と、取り込まれた外部リソースを再構成してコンテンツ部へ単一の文書として保存する機能とを有することを特徴とする構造化文書である。

また、請求項２に記載の構造化文書においては、取り込まれる外部リソースは、電子メールのコンテンツ、若しくは指定のＵＲＬにおけるコンテンツであることを特徴とするものである。

請求項３に記載の構造化文書においては、外部リソースを取り込むごとに課金を発生させる機能をさらに有することを特徴とするものである。

請求項４に記載の構造化文書においては、取り込まれた外部リソースから再構成された文書を外部の文書と同期させる機能をさらに有することを特徴とするものである。

請求項５に記載の構造化文書においては、プログラム部に設けられるプログラムには識別符号が付加され、コンテンツ配信サーバ装置から外部リソースを取り込む回数が識別符号により制限されることを特徴とするものである。

請求項６に記載の構造化文書においては、コンテンツ配信サーバ装置に用意されたコンテンツを外部リソースとして取り込む機能は、外部リソースに含まれる更新情報を判断して更新が行われたときのみ実行されることを特徴とするものである。

さらに、本発明の目的を達成するため、請求項７に記載された発明は、少なくとも外部リソースを取り込む機能と取り込まれた外部リソースを再構成して単一の文書として保存する機能とが設けられた構造化文書を保存する手段と、任意の端末装置からのアクセスに応じて構造化文書を送信する手段と、二つの手段とは一体または別体に設けられて、端末装置からのアクセスに応じて用意されたコンテンツを外部リソースとして送信する手段とを有することを特徴とするコンテンツ配信サーバ装置である。

また、請求項８に記載のコンテンツ配信サーバ装置においては、送信される外部リソースは、電子メールのコンテンツ、若しくは指定のＵＲＬにおけるコンテンツであることを特徴とするものである。

請求項９に記載のコンテンツ配信サーバ装置においては、外部リソースの送信ごとに端末装置に対する課金を発生させる手段をさらに有することを特徴とするものである。

請求項１０に記載のコンテンツ配信サーバ装置においては、保存される構造化文書には、取り込まれた外部リソースから再構成された文書を外部の文書と同期させる機能をさらに有することを特徴とするものである。

請求項１１に記載のコンテンツ配信サーバ装置においては、保存される構造化文書の外部リソースを取り込む機能には識別符号が付加され、端末装置が外部リソースを取り込む回数を識別符号により制限することを特徴とするものである。

請求項１２に記載のコンテンツ配信サーバ装置においては、外部リソースには更新情報を含めることを特徴とするものである。

さらに、本発明の目的を達成するため、請求項１３に記載された発明は、少なくとも外部リソースを取り込む機能及び取り込まれた外部リソースを再構成して単一の文書として保存する機能を有する構造化文書が保存されたコンテンツ配信サーバ装置と、端末装置とが情報ネットワークを通じて接続され、コンテンツ配信サーバ装置は、端末装置からのアクセスに応じてコンテンツ配信サーバ装置に保存された構造化文書を送信する手段を有すると共に、端末装置からのアクセスに応じて用意されたコンテンツを外部リソースとして送信する手段が、コンテンツ配信サーバ装置と一体または別体に設けられることを特徴とするコンテンツ配信システムである。

また、請求項１４に記載のコンテンツ配信システムにおいては、端末装置からのアクセスに応じてコンテンツ配信サーバ装置から送信される外部リソースは、電子メールのコンテンツ、若しくは指定のＵＲＬにおけるコンテンツであることを特徴とするものである。

請求項１５に記載のコンテンツ配信システムにおいては、端末装置からのアクセスに応じてコンテンツ配信サーバ装置から外部リソースが送信されるごとに端末装置に対する課金を発生させる手段がさらに設けられることを特徴とするものである。

請求項１６に記載のコンテンツ配信システムにおいては、構造化文書には、取り込まれた外部リソースから再構成された文書を他の端末装置の文書と同期させる機能をさらに有することを特徴とするものである。

請求項１７に記載のコンテンツ配信システムにおいては、構造化文書の外部リソースを取り込む機能には識別符号が付加され、端末装置がコンテンツ配信サーバ装置から外部リソースを取り込む回数が識別符号により制限されることを特徴とするものである。

請求項１８に記載のコンテンツ配信システムにおいては、外部リソースには更新情報を含め、コンテンツ配信サーバ装置に用意されたコンテンツを外部リソースとして取り込む機能は、外部リソースに含まれる更新情報を判断して更新が行われたときのみ実行されることを特徴とするものである。

本発明の構造化文書、コンテンツ配信サーバ装置及びコンテンツ配信システムによれば、ＷｅｂやＬＡＮ上にあるデータをはじめとする外部データを取り込んでパッケージ化して文書化し、文書化したものでさらに同期を行えるようにすることによって、データの記録やコラボレーションを行いやすい文書を生成することができる。

〔情報蓄積型文書（カプセル化文書）の構造〕
以下の説明では、情報蓄積型文書（カプセル化文書）の実現手段の一つとして、Ｊａｒ(Java ARchive)ファイルを用いた例を述べる。Ｊａｒファイルは、現在広く普及している書庫（ＺＩＰ）ファイル形式に基づくファイル形式で、複数のファイルを一つにまとめたプラットフォーム非依存のファイル形式の代表である。そこで、最初に、本発明の前提部分であるカプセル化文書の構造、生成方法などについて述べる。

〔カプセル化文書の構造〕
カプセル化文書（Ｊａｒ）ファイルの構造は図１に示したとおりである。定義（ＪａｒでいうところのＭＥＴＡ−ＩＮＦ）フォルダには、メインプログラム定義ファイル（マニフェストファイル）が格納されており、起動されたときに最初にロードするプログラム情報が記述されている。

コンテンツフォルダには、テキストファイルや画像、音声ファイルなどが格納されるが、本発明においては、最初はコンテンツが無い場合もある。従ってフォルダ自体はここではなくてもよいが、他のファイル群（プログラムファイルなど）と区別するためにここでは設けた。またフォルダ自体は複数あっても構わない。

プログラムフォルダにはプログラムファイル群が格納される。コンテンツやプログラムの管理がしやすくなるように、図２に示すように構造ファイルを用意しても良い。構造ファイルは、文書ファイル（Ｊａｒファイル）中のプログラム群やコンテンツ群を管理するものであり、例えば下記のようなＸＭＬ（eXtensible Markup Language）で記述する。

<?xml version="1.0" encoding="utf-8"?>
<encapsulateddoc>
<programs>
<prog1/>
<prog2/>
<prog3/>
</programs>
<contents>
<page1>
<index.html/>
</page1>
</contents>
</encapsulateddoc>

このようなＸＭＬが記述されている場合には、プログラムは、prog1 → prog2 → prog3というようにプログラムをロードする順番を指定することや、コンテンツも１ページ目はindex.htmlであるというような指定が可能である。つまり、外部リソースを取得しながら情報を蓄積していく情報蓄積型文書は、プログラムフォルダに外部リソースを取得するプログラムを格納し、構造ファイルにそのプログラム名を記述することにより、情報蓄積型文書を構成することができる。以下には文書の生成方法を記述する。

〔情報蓄積型文書の生成方法〕
カプセル化文書（Ｊａｒ）ファイル自体はＺＩＰと同じ書庫ファイルである。図２に示したものを一つのファイルにパッケージ化する。カプセル化文書ファイルとして必要なメインプログラム定義ファイルの記述例を以下に示す。
Manifest-Version: 1.0
Main-Class: AppMain
Created-By: 1.3.1 (Ricoh Company, LTD.)

ここで、２行目はメイン関数のあるプログラムファイル名である。これを指定しておくことによって起動時に最初にロードされるプログラムファイルを決定することができる。３行目はプログラムのバージョン（ここではＪａｖａのバージョン）及びサプライヤである。

さらにこのようなメインプログラム定義ファイルと、コンテンツ及び外部リソース取得プログラムを含むプログラムファイル群を書庫化して一つにする。すなわちこの場合に、書庫化の処理は、例えば図３に示すフローチャートのように行われる。

図３において、ステップＳ１で書庫化するファイルの読み込み及びバイト配列への格納が行われ、ステップＳ２でファイル書き出しストリーム生成が行われる。さらにステップＳ３で書庫の書き出しストリームを生成してファイル書き出しストリームを渡す。そしてステップＳ４で書庫エントリを生成しＺＩＰの書き出しストリームに登録する。また、ステップＳ５で書庫の書き出しストリームに先のバイト配列を書き込み、ステップＳ６で書庫エントリのクローズをして、終了処理となる。

なお、この処理は一つのファイルを書庫化する際の基本的な処理の流れであるが、複数ファイルに渡っても基本的な処理は同じである。以上のようにして、マニフェストファイル、コンテンツ、外部リソース取得プログラムなどのプログラム群を一つの書庫ファイルとして扱うことができる。

また、Ｊａｒファイルに限って言えば、ＪａｖａのＳＤＫ（Software Developement Kit）をインストールしてある環境であれば、〔jar cvfmsample.jar manifest.mf *.*〕などとコマンドを打つことにより、容易にＪａｒファイルの生成が可能である。つまり、Ｊａｖａプログラミングで言えば、Ｒｕｎｔｉｍｅの外部プログラム呼び出しの文字列に〔jar cvfm sample.jar manifest.mf *.*〕とすることによってＪａｒファイルの作成が可能である。以上が、外部リソース取得プログラムを含むカプセル化（情報蓄積型）文書の構造および生成方法である。

〔外部リソース取得プログラムを含むカプセル化（情報蓄積型）文書と外部リソース〕
本発明における外部リソース取得プログラムを含むカプセル化（情報蓄積型）文書と外部リソースの位置などを図４に示した。すなわち図４において、インターネット１００にはＷｅｂサーバ１と端末装置２が接続され、この端末装置２に情報蓄積型文書２１が設けられる。またインターネット１００にはＬＡＮ２００が接続され、このＬＡＮ２００に、ファイルサーバ３と端末装置４、５が接続され、これらの端末装置４、５にも情報蓄積型文書４１、５１が設けられる。

従って本発明においては、文書中のプログラムファイル（外部リース取得プログラム）が、インターネット１００上のＷｅｂサーバ（サイト）１にアクセスして情報を取得したり、ＬＡＮ２００上のファイルサーバ３からファイルを取得したりして文書内に取り込んでいくものである。この場合に、情報蓄積型文書２１、４１、５１は通常の文書と同様に端末装置２、４、５上で起動され、外部リソースを取得する。また文書間でコンテンツをやり取りして所持しているコンテンツの同期も行う。

〔情報蓄積型（外部リソース取得機能を有する）文書の起動〕
ここでは、図５を参照して外部リソース取得機能を有する文書の起動までの流れを説明する。図５においてステップＳ１１で起動が検知されると、ステップＳ１２でメインプログラム定義ファイルが取得され、ステップＳ１３でメインプログラム情報が取得され、ステップＳ１４でメインプログラムがロードされる。このプログラムはいわばメインルーチン的な役割を果たし、これによりステップＳ１５〜ステップＳ１７で必要な各種プログラムファイルの実行などの指示が行われる。

なおこの場合に、文書の中身は以下の通りである。
・構造ファイル：プログラムのロード順や、コンテンツの表示順など、文書ファイル内にあるコンテンツやプログラムを管理する。
・メインプログラム定義ファイル（マニフェストファイル）：文書を起動する際に最初にロードするプログラム（クラスファイル）の名前が記述されている。
・コンテンツ（最初は無い場合もある）：ここでは、プログラムによってロード、表示されるコンテンツを指す。テキスト、画像、動画、音声ファイルその他の各種ファイル。

・プログラム（クラスファイル）：コンテンツフォルダに含まれる文書（テキスト、画像など）をロード、表示するプログラムを格納する。すなわち想定されるコンテンツを表示するためのプログラムを文書生成時に格納しておく。外部リソースを取り込んだり、取り込んだコンテンツを表示したりするだけでなく、文書に様々な機能を追加するプログラムもここに格納する。機能の例としては、例えば、通信機能（文書間で表示の同期）、加筆機能、記録機能（操作の記録）などがある。

〔動作〕
すなわち、端末装置２、４、５では、ダブルクリックもしくはコマンドラインからの命令（ステップＳ１１）によって、情報蓄積型文書２１、４１、５１のメインプログラム定義ファイルに記述されているプログラムファイルがロード（ステップＳ１４）される。このプログラムはいわばメインルーチン的な役割を果たし、必要な各種プログラムファイルの実行や、構造ファイル（ＸＭＬ）を読み込んで解釈し、必要なプログラムのロード、実行などの指示を行う。

そしてロードされたプログラムファイルが実行され、ステップＳ１５ではプログラムファイルの一つであるコンテンツ取得プログラムがロード、実行される。また、ステップＳ１６ではコンテンツフォルダ内のテキストや画像が（あれば）表示プログラムによって表示される。このようにして、コンテンツが表示されると共に、ステップＳ１７では各種機能を実現するプログラムも同様にロードされ、使用準備が整う。そこで、以下には、この文書でのコンテンツの取得、表示動作について述べる。

〔情報蓄積型文書によるコンテンツ取得〕
最も単純な例として、情報蓄積型文書がＷｅｂにアクセスし情報を取得して表示する例を述べる。ここで必要となるプログラム、つまり文書に最初に格納しておくべきプログラムは、ＷｅｂサーバにアクセスしてＨＴＭＬなどのコンテンツを取得するプログラムと、ＨＴＭＬなどのコンテンツを表示するためのプログラムである。ここに出てくるＷｅｂサーバは通常のインターネット上のサーバである。なおここでは、予めアクセスするＷｅｂサーバはプログラム内で指定してあるとするが、ユーザに指定させてももちろん良い。

さらに図６に情報蓄積型文書のコンテンツ取得について流れを示した。ここで情報蓄積型文書２１、４１、５１はユーザのダブルクリックなどにより起動すると、コンテンツ取得プログラムがロード、実行され、ＨＴＴＰのＧＥＴコマンドを所定のＷｅｂサーバ２に対して送信する。

例えば（http://webserver/index.html）を取得するようになっている場合、コンテンツ取得プログラムは、ソケットを使って、Ｗｅｂサーバ２との間にコネクションをはり、
GET /index.html HTTP/1.0[CR LF(改行)]
のような命令をＷｅｂサーバ２に対して送信する（行の末尾は改行コード）。ＧＥＴコマンドの後には様々な付加情報が続くが、ここでは、触れない。

そして最後に空行（改行コード以外に文字を一切含まない行）を付加することによって、命令の最後であることをＷｅｂサーバ２に通知する。なお、端末装置２、４、５がｐｒｏｘｙサーバ経由でＷｅｂサーバ２にアクセスする場合には、ＧＥＴコマンドは以下のようになり、ｐｒｏｘｙサーバが代理でＷｅｂサーバ２にアクセスする。
GET http://webserver/index.html HTTP/1.0[CR LF]

このコマンドをＷｅｂサーバ２が受け取ると、Ｗｅｂサーバ２は情報蓄積型文書２１、４１、５１に対して要求されたファイルを送信する。情報蓄積型文書２１、４１、５１はこの送信されたファイル（index.html）を受信し、情報蓄積型文書２１、４１、５１内に取り込み表示する。この場合に、情報蓄積型文書２１、４１、５１に設けられる表示プログラムは、ＨＴＭＬを解析し、レンダリングできるプログラムである。

これら一連の動作を定期的に行うようにプログラムすることによって、特定のサイトのページを定期的に取得することが可能である。また、上記の例では一つのサイト（Ｗｅｂサーバ２）しか参照してないが、複数のサイトを指定することにより、インターネット１００上に分散したデータの一括管理がより容易になる。

〔コンテンツ取り込み後の保存処理〕
一方、コンテンツを文書内に取り込むためには、ファイル自体を作り直す必要がある。そこで図２に示したコンテンツフォルダ内にコンテンツを配置し、書庫化し直すことによって外部ファイルを取り込むことができる。この際、取得したコンテンツが過去に取得したコンテンツと名前が競合する場合があるので、時間ごとにフォルダを生成したり、ファイル名を振り直したりする必要がある。ここで書庫化しなおすには、以下の点で注意が必要である。

すなわち、書庫ファイルにはヘッダファイルがあり、そのファイルには書庫化されているファイル名とサイズなどが記載されている。このファイルと実際のファイルの整合性が取れないとエラーになってしまう。これに対応するには、情報蓄積型文書を生成する際と同様にして、書庫ファイル自体を作り直してヘッダファイルと保持しているファイルの整合をとる必要がある。また、構造ファイルを用いて管理している場合は、構造ファイルを書き換える必要がある。

なお、例えば新しいコンテンツを追加した場合には、上記ＸＭＬの例のコンテンツタグにおいて
<page2>
<newpage.html/>
</page2>
を加えたりする。このようにして、構造ファイルを更新した上で書庫化を行うことができる。なお、書庫化の方法については先に述べた通りである。

〔特定ファイルの取得〕
なお上記例は、ＨＴＭＬを単純に取得しているだけであるが、特定ファイルのみ取得することもできる。ここで画像であれば、ＨＴＭＬのソースをチェックするとＩＭＧタグで
<IMG SRC="/images/sampl.jpg" HEIGHT="100" WIDTH="100">
のような記述があるので、それを取得することができる。動画ファイルやＭＰ３ファイルなど、他のフォーマットに関しても同様である。

また、リンクとして、<A HREF="sample.jpg">のようにアンカータグとリファレンス属性にもファイル指定があるので、参照先からファイルを取得することができる。いずれも拡張子からファイルの種類は判断する。

〔特定フォルダの参照（ＬＡＮ上のファイルサーバや共有フォルダなど）〕
例えばスキャナで取得したデータやデジタルカメラの画像をＰＣ（Personal Computer）に保存する際には通常決まった場所に保存する場合が多い、このフォルダを予め指定しておくことにより、このフォルダを監視し、新しいコンテンツが追加されたらファイルを文書に取り込むことも可能である。

そこで予めユーザにフォルダを指定させる。これにより図７のフローチャートに示すように、ステップＳ２１で文書起動し、ステップＳ２２でユーザによって予め指定されたフォルダをチェックし、ステップＳ２３で取り込んでないファイルがあればそのファイルを取り込み、ステップＳ２４で表示というように、Ｗｅｂ上ではなく、ＬＡＮ上の共有フォルダや、自ＰＣのフォルダなど、アクセス可能なフォルダの情報を取得することが可能である。

なおこの例は、一つのフォルダの場合であるが、複数のフォルダを指定することによって、ＬＡＮ上に分散したフォルダ内の情報を常に一つのフォルダにアーカイビングすることが可能である。

〔ＲＳＳの利用〕
また上記の例では、定期的にＷｅｂサーバから情報を取得しているが、場合によっては全く更新がなく、更新があったときのみ取得をする場合や、更新された部分のみを取得したい場合もある。この場合にはＲＳＳ（RDF Site SummaryまたはRich Site Summary）を利用する。ＲＳＳは、Ｗｅｂサイトの概要をメタデータとして簡潔に記述するＸＭＬフォーマットである。

最近は、Ｗｅｂサイトにおいて新しい情報をＲＳＳとして提供するところが増えてきている。多くのブログでもこの機能を提供している。ＲＳＳリーダなるものがあり、各サイトやブログのＲＳＳを登録しておくと、各サイトの記事の一覧を取得することができる。ＲＳＳは以下のようなXMLファイルであり、これを解析することにより、更新情報を取得できる。

〔ＲＳＳの例〕
<?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>
<dc:date>2005-09-06T14:21:08+09:00</dc:date>
<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>
</rdf:RDF>

このＲＳＳの利用によって、ファイルを解析した結果を文書内に取り込んだり、対応するコンテンツの部分のみを取り込んだりといったことが可能である。上記の例であれば、titleという要素が、「Ricohカメラ」という内容を持っており、descriptionという要素が、「Ricoh製のカメラについての情報を提供しています。」という内容を持っている。このように、基本的に要素名とその内容を見ていくことで、情報の取得が可能である。また、rdf:resource属性の値を見ることで、参照しているページも取得できるので（上記であれば、http://machine.ricoh.co.jp/docs/manual.htmlなど）、そのページを取得してくることが可能である。

〔外部サービスの利用方法〕
さらに、単にＷｅｂの情報を取得するのではなく、Ｗｅｂ上のサービスを利用した結果を文書内に取り込む場合の動作について述べる。ここでは、Google APIの利用に関して述べる。Google APIは、プログラムから検索サービスなどを利用できるように提供されているものであり、以下に示したような処理をプログラミングすれば、プログラムからGoogleの検索サービスを利用することができる。（Proxy関係のセットはProxyを利用する場合にセットする）

Google Search s = new GoogleSearch(); //検索のためのインスタンス生成
s.setProxyHost("proxy server name"); //proxyサーバのセット
s.setProxyPort(port Number); //ポート番号のセット
s.setProxyUserName("name"); //proxyユーザ名のセット
s.setProxyPassword("password"); //proxy パスワードのセット
s.setQueryString(“検索語”); //検索語のセット
GoogleSearchResult r = s.doSearch(); //検索、検索結果の取得

ただ、これでは欲しい情報の候補を取得することしかできないので、ユーザとしては、候補を順番に見ていって、これだというものを取り込みたい。候補を順に見る場合は、内部のプログラムを用いる。取り込みたいコンテンツをみつけた場合は、表示したページを取り込む。右クリックでメニューとして「取り込み」を表示できるようにしても良い。このような検索サービスを利用する場合の動作を以下に示す。

文書中に含まれるプログラムとして、上述したような検索サービスプログラムが用意される。検索サービスプログラムは、例えば図８のＡに示された文書中の検索窓にユーザが何らかの文字列を記述してリターンなどすると、プログラムはそのアクションを検知してユーザが入力した文字列を取得し、上記プログラム処理を行って、検索サービスに問い合わせる。

これによる検索結果は、例えば図８のＢに示すように文書とは別のウインドウで表示され、ユーザはこのリストの中から所望の情報をウインドウ内で表示して探す。このウインドウはユーザのマウス操作イベントを取得し、例えば図８のＣに示すようなメニューを表示する。そしてユーザがメニュー中の「取り込み」を指定することによって、図８のＤに示すようにウインドウ中のコンテンツを文書内に取り込む。

さらに、上記は検索サービスの例を出したが、単にＵＲＬをユーザに入力させる窓を設けて、例えば図９のＡのフローチャートに示すように、ステップＳ３１で入力された文字列（ＵＲＬ）を取得し、ステップＳ３２でＵＲＬをもとにＷｅｂアクセスをし、ステップＳ３３に示すようにページの取得、表示を行い、ステップＳ３４に示すように文書内に取り込む、というような流れでＷｅｂ上の情報を取り込んでも良い。

あるいは先にＷｅｂページではなく、画像やＭＰ３などの取り込みについて触れたが、すでに文書内にあるテキスト情報を右クリックすると、例えば図９のＢのフローチャートに示すように、ステップＳ４１でメニュー表示し、ステップＳ４２でＵＲＩ指定（ファイルのありかを指定）し、ステップＳ４３で取り込みなどして、テキストに画像などのファイルへのリンクとして表現しても良い。

また、ブラウザで表示しているページの一部コンテンツの画像やテキストなどをコピー＆ペーストして取り込む方法もある。この場合には、コピーするとクリップボードに情報が取り込まれるので、ペーストでその情報を取得すればよい。取得した情報が、http:// で始まるいわゆるリンク情報の場合は、そのＵＲＬにアクセスし、ページを取得、表示し、文書内に取り込めるのは先に述べたとおりである。

また、取り込みたい情報をドラッグして、文書上にドロップすることで取り込むことも可能である。この場合の処理はコピー＆ペーストの場合と基本的に変わらないが、プログラムとしては、ドロップイベントの取得と、取得したイベントの情報の取得が必要である。

〔他文書との同期：取得した情報の同期方法〕
文書間で表示を同期する例はすでにいくつかの従来技術にあるが、コミュニケーション中にコンテンツを追加する例はない。これまで述べてきたように何らかの方法でデータを取り込んだ場合、取り込んだ情報を他文書と同期できるとコミュニケーション上都合がよい。つまり、起動したときに通信を確立し、文書の表示を同期させるような場合に、ある文書がコンテンツを新たに追加しても、円滑にコミュニケーションが継続できるように、他文書に対して取得したコンテンツを提供する必要がある。

そこで図１０にコンテンツ取得の際の同期について基本的な流れを示す。この例では、情報蓄積型文書Ａ及びＢ（情報蓄積型文書２１、４１、５１のいずれか）がユーザによって起動され、通信の確立を行う。通信の確立とは、ここでは、互いの文書ＩＤおよび起動しているＩＰアドレスをやりとりすることで、それぞれが、ネットワーク上で他の文書がどのアドレスで起動しているかを認識している状態を指す。

この状態において例えば文書Ａのページ２が表示されると、通信確立している文書Ｂもページ２が表示される状態である。ここで、図１０にあるように、ユーザ操作などで文書Ｂが先に述べたような方法でＷｅｂサーバ２にアクセスし、なんらかのコンテンツを取得し、文書Ｂ内に取り込む。ここで文書Ｂは、通信確立している文書Ａに対して、取り込んだコンテンツのコピーを送信する。文書Ａは文書Ｂから送信されたコンテンツの（コピー）を受信してそれを文書内に取り込み、表示する。

以上の処理により通信確立をしている文書間で文書の表示の同期および保持コンテンツの同一性が保たれることになる。なお、取り込む際、文書表示中は文書内に取り込むのは困難であるので、テンポラリーのフォルダに保存しておき、表示だけ同期させ、文書が閉じられる際に取り込むか、文書を起動しなおすかする必要がある場合もある。

〔起動していない文書がある場合〕
起動していない文書がある場合に問題になるのは、文書内のコンテンツの同一性を保持できないことである。例えば図１０において、文書Ａとは通信確立したものの、文書Ｂがコンテンツを取得したときには既に文書Ａが閉じられていたり、また、文書Ａ、Ｂで表示の同期を取るようにプログラムされているのにも関わらず、文書Ｂだけ起動して、単独でコンテンツを追加したときなどである。

このような場合、起動後に通信確立する際に、通信確立を行った他の文書と保持しているコンテンツの情報交換を行い、コンテンツの過不足を確認して文書としての同一性を保つ必要がある。コンテンツを付加したり、消したりといった時には、例えばそのログ情報を文書内に記録しておくことによって、コンテンツの過不足を確認できる。不足があれば他文書にそのコンテンツを要求すればよいし、ない場合はそのコンテンツを消去すればよい。消去する場合は、先に示した構造ファイルの該当する要素を消去し、コンテンツを消去し、ＺＩＰ化しなおせばよい。この場合、コンテンツは必ずしも消去する必要はない。

さらにログ情報の例を図１１に示す。ここでは、コンテンツを取得、削除した時刻とコンテンツ名を記録している。このログを参照することによって上記の処理が可能であり、現在保持しているコンテンツが何かもわかる。例えばこの例では、FILE2、FILE3、FILE4が現在保持しているコンテンツである。

〔競合した場合の対処〕
例えば文書Ａ、文書Ｂでほぼ同時に、それぞれ別の何らかのコンテンツを取り込む場合がある。ここでコンテンツを取り込んだ時点では、ＡとＢの両文書に異なるコンテンツが入っていることになる。この状態で文書ＡとＢが同期するとなると、コンテンツの順番などの問題がある。この場合、コンテンツを取り込んだ際の時刻を記録しておき、早いコンテンツの方を順番的に早くする。

なおこの際に、時間情報は各端末でまちまちであるので、実際にはどちらのコンテンツが早く取り込まれているかは不明であるが、ここでは、文書どうしで不整合が起こらないようにするのが目的であるので、時間的な不正確さは問題にならないと考える。また完全に同時刻の場合は、どちらを優先させるかを決めておけばよいだけである。またタイムサーバにアクセスできる環境にある場合は、タイムサーバから時間情報を取得するという手段もある。それとは別に、文書Ａ、Ｂでコンテンツ名がバッティングする場合は、コンテンツ名を振りなおす必要がある。

〔メールのアーカイブ〕
ここでは特定メールのアーカイブについて述べる。これは、例えば文書中に特定メールマガジンのメールを蓄積していくことによって、そのメールマガジンを一つのファイルに収めていくのに用いることができる。一つの例として、これまで述べてきたコンテンツを取得するプログラムの変わりに、メールサーバにアクセスし特定サブジェクトのメールのコピーを取得するプログラムを文書に入れる。

特定サブジェクトはユーザに指定させる。メールマガジンはそのサブジェクトがある程度固定されている。基本的には「タイトル＋号＋日付」であるので、例えばタイトルをユーザに指定させる（一度）。また、ユーザには通常のメーラの設定（ＰＯＰサーバやＩＭＡＰサーバアクセスのための設定）をさせる必要がある（一度）。

プログラムは、ユーザに指定させた情報をもとに定期的にメールサーバにアクセスする。アクセスした結果、ユーザが指定した文字列と合致するメールのコピーを取得し、文書に取り込む。これらの処理は先に述べた方法と同じである。また、定期的にメールサーバにアクセスするには、情報蓄積型文書は起動しておく必要がある。定期的にアクセスしなくても、文書起動時にメールサーバにアクセスしてまとめて取り込んでも良い。ただし、通常使っているメーラの設定として、メッセージをサーバに残しておくようにしておかないとこの方法は使えない（メールサーバがＰＯＰの場合）。

〔各種サーバの動作〕
これまでの説明は、サーバ側は通常あるＷｅｂサーバやメールサーバを指していたが、ここからは「情報蓄積型文書」配信サーバなど、発明に関するサーバの動作、利用について述べる。

〔サーバから必要なプログラムを取得〕
文書に何らかのコンテンツを取り込む場合に、先の例では予め文書にそれらのコンテンツを閲覧するためのプログラム（classファイル）を入れておくとしたが、文書を作成した時点では想定していない形式のコンテンツを取り込む場合がある。コンテンツとそれを閲覧するためのプログラムは、コンテンツのファイルの拡張子で関連づけられる。Jpg, gif, pngなどであれば画像ビューワであるし、HtmlであればＨＴＭＬビューワであるし、ＭＰ３であれば、それに対応した音楽再生プログラムであるといったように、ファイル拡張子から使用するプログラムが決定される。

ここで図１２のフローチャートを参照しながら、対応していない拡張子のコンテンツを文書に取り込む場合の処理について述べる。この図１２においては、ステップＳ５１で取り込むファイルの拡張子を取得し、ステップＳ５２で対応プログラムを保持しているか否か判断される。そして保持していない場合（Ｎｏ）は、ステップＳ５３でプログラム提供サーバに問い合わせ、ステップＳ５４でサーバから対応プログラムを取得する。さらにステップＳ５５でコンテンツの表示再生を行う。なお、ステップＳ５２で対応プログラムを保持している場合（Ｙｅｓ）は、直接ステップＳ５５でコンテンツの表示再生を行う。

以上が基本的な処理の流れである。なお、サーバは、拡張子の情報から対応するプログラムを問い合わせのあった文書に送信すればよい。また対応するプログラムがなければ、その旨文書に応答し、文書は「対応するプログラムがありませんでした。」のダイアログを表示するなどする。さらに文書とプログラム提供サーバの大まかな処理の流れを図１３に示す。

この図１３において、情報蓄積型文書２１、４１、５１はユーザのダブルクリックなどにより起動すると、プログラム取得プログラムがロード、実行され、ＨＴＴＰのＧＥＴコマンドを所定のプログラム提供サーバ６０に対して送信する。このコマンドをプログラム提供サーバ６０が受け取ると、プログラム提供サーバ６０は情報蓄積型文書２１、４１、５１に対して要求されたプログラムを送信する。情報蓄積型文書２１、４１、５１はこの送信されたプログラムを受信し、情報蓄積型文書２１、４１、５１内に取り込み文書を再起動する。

〔情報蓄積型文書配信サーバ〕
情報蓄積型文書配信サーバは、サーバ上で情報蓄積型文書を作成し、それを端末に配信するものである。ここでは、Ｗｅｂマガジン配信サーバとして説明する。なお、図１４は、ユーザのＷｅｂブラウザを介しての操作、情報蓄積型文書（Ｗｅｂマガジン）、Ｗｅｂマガジン配信サーバの動作や対応関係を示したものである。この図１４を参照して、以下にユーザの操作、文書およびサーバの動作について時系列に述べる。

図１４において、ステップＳ６１でユーザがＷｅｂブラウザを使ってインターネット上のサイトにアクセスしＷｅｂマガジン配信を申し込む。これに対してステップＳ６２でサーバは、ブラウザに対して申し込み用のフォームを送信する。さらにステップＳ６３でユーザは表示されたフォームに対して必要事項を入力する。ここではユーザはメールアドレス、配信してもらいたい情報のタイトルなどを記入（もしくは選択）する。

さらにステップＳ６４でサーバはこれを受け付け登録し、所望のタイトルの情報が取得できるＵＲＬをセットして情報蓄積型文書を生成し、ステップＳ６５ユーザのメールアドレスに送信する。もしくは、文書のダウンロードページをブラウザに対して送信する。これによりステップＳ６６でユーザがメールの添付ファイルもしくは、ダウンロードで文書を取得する。これによりステップＳ６７でユーザは受信した情報蓄積型文書を起動する。

さらにステップＳ６８で文書が起動すると、文書内のプログラムがセットされたＵＲＬにアクセスする。このとき文書は、保持しているコンテンツ情報をサーバに送信する。そしてステップＳ６９でサーバはコンテンツ情報を参照し、保持していないコンテンツがあれば文書に対してそのコンテンツを送信する。さらにステップＳ７０で文書は、コンテンツを受信し、文書内に取り込み、表示する。またステップＳ７１でユーザの操作により文書が閉じられる。さらにステップＳ６７〜７１を繰り返すことにより、コンテンツが蓄積されていく。

このようにして、従来のメールマガジンとは趣の異なる情報配信の仕組みを構築することができる。この場合に、サイトと配信サーバは同一でもかまわないし、別々でもよい。また場合によっては、コンテンツを蓄積していくだけでなく、一定期間過ぎたデータは消去するなどのオプションがあってもよい。また、ＬＡＮ上で起動し、インターネットアクセスする場合にプロキシを通す場合には、ユーザは、予めプロキシサーバ、ポート番号、ユーザ名、パスワードをセットする必要があるが、これはＷｅｂブラウザで設定する場合と全く同じである。

さらに上述の情報蓄積型文書配信サーバを利用している場合においては、例えばフリーのＷｅｂマガジンを、リモートで複数のユーザが同期させながら閲覧している際に、Ｗｅｂマガジンの内容に関連するファイルを追加する、というような事を行うことができる。また、Ｗｅｂマガジンが何らかの教材的なものであるしたら、他者とコミュニケーションして確認しながら閲覧し、「こんな情報もあります！」というように保持しているファイルを取り込むというようなこともかのうである。

また、図１５には課金を行う場合の処理について説明する。この図１５において、ステップＳ８１で文書を起動すると、ステップＳ８２で文書はコンテンツ保持情報をサーバに送信する。これに対し、サーバは保持コンテンツ情報を受信し、ステップＳ８３で文書が保持していないコンテンツが予め決められた範囲内（図中ではコンテンツナンバー５以内）であれば、ステップＳ８４でそのままコンテンツを送信する。

また課金対象コンテンツを保持していない場合は、ステップＳ８５で登録ユーザであるかどうかの判定をする。なお登録ユーザであるかいなかは、コンテンツ保持情報送信時に登録ＩＤを送信させるなどして確認を取ることが可能である。そして登録ユーザであることの確認がとれた場合には、ステップＳ８６で文書が保持していないコンテンツを文書に対して送信する。

また登録ユーザでない場合は、ステップＳ８７で申し込みフォームを文書に対して送信する。これにより文書はフォームを受信し表示する。そしてステップＳ８８でユーザが入力し、ステップＳ８９で情報がサーバに送信、登録され、課金される。その後に、ステップＳ９０でサーバからはコンテンツが配信される。なお上述の説明では、申し込み時点で１回の課金となっているが、新しいコンテンツを配信するたびに課金することもできる。

さらに不正コピーの防止については、例えば図１６のようにして行う。すなわちこの手法は、同じＩＤからの同一コンテンツ取得の回数を制限するものである。これは、文書がいくつかコピーされた場合に、複数の同じＩＤの文書ができることになるので、同じＩＤから何回も同じコンテンツを配信するのはおかしいということになるものである。

そこで、ステップＳ９１で文書が起動すると、ステップＳ９２でＩＤおよび保持コンテンツ情報をサーバに送信する。これによりサーバはＩＤと受信情報をもとに、ステップＳ９３でＩＤに該当するコンテンツナンバと配信回数のテーブルを参照する。そしてサーバが文書に配信すべきコンテンツが規定以内の配信回数である場合、ステップＳ９４でコンテンツを文書に送信する。逆に、配信すべきコンテンツが規定配信回数に達している場合は、ステップＳ９５で不正である旨を文書に対して送信する。

こうして本発明の構造化文書によれば、少なくともプログラム部とコンテンツ部を含む構造化文書であって、プログラム部に設けられるプログラムには、任意のコンテンツ配信サーバ装置にアクセスしてコンテンツ配信サーバ装置に用意されたコンテンツを外部リソースとして取り込む機能と、取り込まれた外部リソースを再構成してコンテンツ部へ単一の文書として保存する機能とを有することにより、外部リソースを文書内に取り込んでいくことによって、情報をアーカイブして行くことが可能であり、しかもそれが一つの文書として扱うことができるので、ＷｅｂやＬＡＮ上などに分散した情報をまとめることができると共に、Ｗｅｂ情報の定点観測など、様々な使い方が可能になるものである。

また、本発明の構造化文書においては、取り込まれる外部リソースは、電子メールのコンテンツ、若しくは指定のＵＲＬにおけるコンテンツとすることにより、文書としてアーカイビングする際に特別なプログラムを起動しなくても良くなり、保存に適し、また可搬性が上がるので、扱いやすくなるものである。

本発明の構造化文書においては、外部リソースを取り込むごとに課金を発生させる機能をさらに有することにより、有料のコンテンツの配信等にも利用することができるものである。

本発明の構造化文書においては、取り込まれた外部リソースから再構成された文書を外部の文書と同期させる機能をさらに有することにより、例えば文書を用いたコミュニケーション中に調べた結果を他方の文書に反映することができるので、文書を用いたコミュニケーションの質を上げることができるものである。

本発明の構造化文書においては、プログラム部に設けられるプログラムには識別符号が付加され、コンテンツ配信サーバ装置から外部リソースを取り込む回数が識別符号により制限されることにより、不正なコピー等の防止を行うことができるものである。

本発明の構造化文書においては、コンテンツ配信サーバ装置に用意されたコンテンツを外部リソースとして取り込む機能は、外部リソースに含まれる更新情報を判断して更新が行われたときのみ実行されることにより、文書の汎用性を高めることができ、また、一旦取得すればその後はサーバに接続する必要は無いため、通信コスト（料金やトラフィック）の低減を実現できると共に、サーバに接続できない環境下においても閲覧が可能になるものである。

さらに本発明のコンテンツ配信サーバ装置によれば、少なくとも外部リソースを取り込む機能と取り込まれた外部リソースを再構成して単一の文書として保存する機能とが設けられた構造化文書を保存する手段と、任意の端末装置からのアクセスに応じて構造化文書を送信する手段と、二つの手段とは一体または別体に設けられて、端末装置からのアクセスに応じて用意されたコンテンツを外部リソースとして送信する手段とを有することにより、外部リソースを文書内に取り込んでいくことによって、情報をアーカイブして行くことが可能であり、しかもそれが一つの文書として扱うことができるので、ＷｅｂやＬＡＮ上などに分散した情報をまとめることができると共に、Ｗｅｂ情報の定点観測など、様々な使い方が可能になるものである。

また、本発明のコンテンツ配信システムによれば、少なくとも外部リソースを取り込む機能及び取り込まれた外部リソースを再構成して単一の文書として保存する機能を有する構造化文書が保存されたコンテンツ配信サーバ装置と、端末装置とが情報ネットワークを通じて接続され、コンテンツ配信サーバ装置は、端末装置からのアクセスに応じてコンテンツ配信サーバ装置に保存された構造化文書を送信する手段を有すると共に、端末装置からのアクセスに応じて用意されたコンテンツを外部リソースとして送信する手段が、コンテンツ配信サーバ装置と一体または別体に設けられることにより、外部リソースを文書内に取り込んでいくことによって、情報をアーカイブして行くことが可能であり、しかもそれが一つの文書として扱うことができるので、ＷｅｂやＬＡＮ上などに分散した情報をまとめることができると共に、Ｗｅｂ情報の定点観測など、様々な使い方が可能になるものである。

なお本発明は、上述の説明した実施形態に限定されるものではなく、特許請求の範囲の記載を逸脱しない範囲において、種々の変形が可能とされるものである。

本発明の適用される構造化文書ファイルの一例の構造を示す図である。本発明の適用される構造化文書ファイルの他の例の構造を示す図である。その動作の説明のためのフローチャート図である。本発明における外部リソース取得プログラムを含む情報蓄積型文書と外部リソースの位置を示す全体の構成図である。その動作の説明のための図である。その動作の説明のための図である。その動作の説明のための図である。その動作の説明のための図である。その動作の説明のための図である。その動作の説明のための図である。その動作の説明のための図である。その動作の説明のための図である。その動作の説明のための図である。その動作の説明のための図である。その動作の説明のための図である。その動作の説明のための図である。

符号の説明

１…Ｗｅｂサーバ、２…端末装置、３…ファイルサーバ、４，５…端末装置、２１，４１，５１…情報蓄積型文書、１００…インターネット、２００…ＬＡＮ

Claims

少なくともプログラム部とコンテンツ部を含む構造化文書であって、
前記プログラム部に設けられるプログラムには、
任意のコンテンツ配信サーバ装置にアクセスして前記コンテンツ配信サーバ装置に用意されたコンテンツを外部リソースとして取り込む機能と、
前記取り込まれた外部リソースを再構成して前記コンテンツ部へ単一の文書として保存する機能と
を有することを特徴とする構造化文書。
前記取り込まれる外部リソースは、電子メールのコンテンツ、若しくは指定のＵＲＬにおけるコンテンツであることを特徴とする請求項１記載の構造化文書。
前記外部リソースを取り込むごとに課金を発生させる機能をさらに有することを特徴とする請求項１記載の構造化文書。
前記取り込まれた外部リソースから再構成された文書を外部の文書と同期させる機能をさらに有することを特徴とする請求項１記載の構造化文書。
前記プログラム部に設けられるプログラムには識別符号が付加され、前記コンテンツ配信サーバ装置から前記外部リソースを取り込む回数が前記識別符号により制限されることを特徴とする請求項１記載の構造化文書。
前記コンテンツ配信サーバ装置に用意されたコンテンツを外部リソースとして取り込む機能は、前記外部リソースに含まれる更新情報を判断して更新が行われたときのみ実行されることを特徴とする請求項１記載の構造化文書。
少なくとも外部リソースを取り込む機能と前記取り込まれた外部リソースを再構成して単一の文書として保存する機能とが設けられた構造化文書を保存する手段と、
任意の端末装置からのアクセスに応じて前記構造化文書を送信する手段と、
前記二つの手段とは一体または別体に設けられて、前記端末装置からのアクセスに応じて用意されたコンテンツを前記外部リソースとして送信する手段と
を有することを特徴とするコンテンツ配信サーバ装置。
前記送信される外部リソースは、電子メールのコンテンツ、若しくは指定のＵＲＬにおけるコンテンツであることを特徴とする請求項７記載のコンテンツ配信サーバ装置。
前記外部リソースの送信ごとに前記端末装置に対する課金を発生させる手段をさらに有することを特徴とする請求項７記載のコンテンツ配信サーバ装置。
前記保存される構造化文書には、前記取り込まれた外部リソースから再構成された文書を外部の文書と同期させる機能をさらに有することを特徴とする請求項７記載のコンテンツ配信サーバ装置。
前記保存される構造化文書の外部リソースを取り込む機能には識別符号が付加され、前記端末装置が前記外部リソースを取り込む回数を前記識別符号により制限することを特徴とする請求項７記載のコンテンツ配信サーバ装置。
前記外部リソースには更新情報を含めることを特徴とする請求項７記載のコンテンツ配信サーバ装置。
少なくとも外部リソースを取り込む機能及び前記取り込まれた外部リソースを再構成して単一の文書として保存する機能を有する構造化文書が保存されたコンテンツ配信サーバ装置と、端末装置とが情報ネットワークを通じて接続され、
前記コンテンツ配信サーバ装置は、前記端末装置からのアクセスに応じて前記コンテンツ配信サーバ装置に保存された前記構造化文書を送信する手段を有すると共に、
前記端末装置からのアクセスに応じて用意されたコンテンツを前記外部リソースとして送信する手段が、前記コンテンツ配信サーバ装置と一体または別体に設けられる
ことを特徴とするコンテンツ配信システム。
前記端末装置からのアクセスに応じて前記コンテンツ配信サーバ装置から送信される外部リソースは、電子メールのコンテンツ、若しくは指定のＵＲＬにおけるコンテンツであることを特徴とする請求項１３記載のコンテンツ配信システム。
前記端末装置からのアクセスに応じて前記コンテンツ配信サーバ装置から前記外部リソースが送信されるごとに前記端末装置に対する課金を発生させる手段がさらに設けられることを特徴とする請求項１３記載のコンテンツ配信システム。
前記構造化文書には、前記取り込まれた外部リソースから再構成された文書を他の端末装置の文書と同期させる機能をさらに有することを特徴とする請求項１３記載のコンテンツ配信システム。
前記構造化文書の外部リソースを取り込む機能には識別符号が付加され、前記端末装置が前記コンテンツ配信サーバ装置から前記外部リソースを取り込む回数が前記識別符号により制限されることを特徴とする請求項１３記載のコンテンツ配信システム。
前記外部リソースには更新情報を含め、前記コンテンツ配信サーバ装置に用意されたコンテンツを外部リソースとして取り込む機能は、前記外部リソースに含まれる更新情報を判断して更新が行われたときのみ実行されることを特徴とする請求項１３記載のコンテンツ配信システム。