(57)【要約】【課題】サーバの使用容量を低く抑えつつ、クライアントに余計な負荷をかけずにクライアントの要求にあった文書データを提供できる装置を提供する。【解決手段】データファイルの送信要求を受信する手段と、送信要求によって特定されるデータファイルを取得する手段と、取得したデータを加工しやすい形式に変換する手段と、変換したデータに対し指定された処理を施す手段と、加工したデータを元の形式に再変換する手段と、再変換したデータを送信する手段から構成される。【選択図】        なし【特許請求の範囲】
【請求項１】
データファイルの送信要求を受信する受信手段と、前記送信要求によって特定されるデータファイルを取得する取得手段と、前記取得手段により取得したデータファイルを解析しデータを加工しやすい構造に変換する第一の変換手段と、前記第一の変換手段により作成されたデータにおいて前期送信要求で指定された要素や属性の内容を加工する内容加工手段と、前記内容加工手段により加工されたデータを元のデータファイルと同じ形式に変換する第２の変換手段と、データファイルを送信要求に基づいて送信する送信手段とを備えることを特徴とする情報処理装置。
【請求項２】
前記内容加工手段は予めサーバに用意されたアルゴリズムに基づいて、演算処理や置換処理、翻訳処理等の処理を行う手段であることを特長とする請求項１記載の情報処理装置。
【請求項３】
前記内容加工手段は、クライアントが作成したアルゴリズムに基づいて処理を行う手段であることを特徴とする請求項１記載の情報処理装置。
【請求項４】
データファイルの送信要求を受信する受信工程と、前記送信要求によって特定されるデータファイルを取得する取得工程と、前記取得工程により取得したデータファイルを解析しデータを加工しやすい構造に変換する第一の変換工程と、前記第一の変換工程により作成されたデータにおいて前期送信要求で指定された要素や属性の内容を加工する内容加工工程と、前記内容加工工程により加工されたデータを元のデータファイルと同じ形式に変換する第２の変換工程と、データファイルを送信要求に基づいて送信する送信工程とを備えることを特徴とする情報処理方法。
【請求項５】
前記内容加工工程は予めサーバに用意されたアルゴリズムに基づいて、演算処理や置換処理、翻訳処理等の処理を行う工程であることを特長とする請求項１記載の情報処理方法。
【請求項６】
前記内容加工工程は、クライアントが作成したアルゴリズムに基づいて処理を行う工程であることを特徴とする請求項１記載の情報処理方法。
【請求項７】
請求項１乃至３のいずれかに記載の情報処理装置をドキュメントサーバとして用いた情報処理システム。
【発明の詳細な説明】
【０００１】
【発明の属する技術分野】
本発明は、文書データの蓄積・検索などに利用されるドキュメントサーバシステムを実現するための情報処理装置および方法およびシステムに関するものである。
【０００２】
【従来の技術】
ＸＭＬやＳＧＭＬのようなマーク付け言語が広く利用されている。これらの言語を利用して書かれた文書は「要素」という文章内容の単位から成り立っている。要素は要素の内容である「要素内容」を開始タグと終了タグとで囲むことにより表現され、タグに付けられた名前を「要素名」と呼ぶ。また、要素は要素の付随情報として「属性」をもつことができる。タグは利用者が自分で定義できるため、これらのマーク付け言語で一般的なデータを確実に表現することができる。このためデータ交換の標準形式として利用されつつある。
【０００３】
また、従来から、ドキュメントサーバを設けてそこに前述のような形式の文書データを蓄積しておき、外部のクライアントホストが蓄積された文書データを取得して利用することが行われている（例えば、特許文献１）。
【０００４】
【特許文献１】
特開２００１−３４４２３３号公報
【０００５】
【発明が解決しようとする課題】
しかしながら、ドキュメントサーバに蓄積されている文書データの一部の表記や値が異なる文書をクライアントが利用したい場合、データの一部を変更した別の文書データを用意しサーバに蓄積するか、欲しい内容に近い文書データをクライアントが一度取得し、その取得したデータに対してクライアントが自分で修正を加えるかの何れかの方法をとる必要があった。
【０００６】
前者の方法では、クライアント毎に少しずつ内容の違う別文書を用意することになるためサーバ内の記憶装置の使用容量が増大するという問題があり、後者の方法はデータの編集をクライアントが行うため処理能力の低いクライアントで過負荷になるという問題があった。
【０００７】
また、申請書等のテンプレート文書をサーバに用意しておき、クライアントがそれを取得して項目の内容だけを新規に入力するというようなことがよく行われるが、これも処理能力の低いクライアント場合に負荷がかかりすぎるという問題があった。
【０００８】
また、クライアントが翻訳サーバに所望の文書のＵＲＬを指定することにより、指定された文書データを翻訳する技術が知られている。しかし、この技術ではページ全体が翻訳されてしまうという問題があり、特定の箇所だけを翻訳させたいという用途には適用できなかった。
【０００９】
本発明は上記の問題に鑑みてなされたものであり、その目的は、サーバ内の記憶装置の使用容量を出来るだけ少なく抑え、なおかつクライアントに余計な負荷をかけることなしに、クライアントの要求にあわせた文書データを提供できるようにすることにある。
【００１０】
【課題を解決するための手段】
上記課題を解決するため、本発明の請求項１記載の情報処理装置は、データファイルの送信要求を受信する受信手段と、前記送信要求によって特定されるデータファイルを取得する取得手段と、前記取得手段により取得したデータファイルを解析しデータを加工しやすい構造に変換する第一の変換手段と、前記第一の変換手段により作成されたデータにおいて前期送信要求で指定された要素や属性の内容を加工する内容加工手段と、前記内容加工手段により加工されたデータを元のデータファイルと同じ形式に変換する第２の変換手段と、データファイルを送信要求に基づいて送信する送信手段とを備えることを特徴とする。
【００１１】
また、請求項２記載の情報処理装置は、請求項１に係る情報処理装置において、前記内容加工手段は予めサーバに用意されたアルゴリズムに基づいて、演算処理や置換処理、翻訳処理等の処理を行う手段であることを特長とする。
【００１２】
また、請求項３記載の情報処理装置は、請求項１に係る情報処理装置において、前記内容加工手段は、クライアントが作成したアルゴリズムに基づいて処理を行う手段であることを特徴とする。
【００１３】
また、請求項４記載の情報処理方法は、データファイルの送信要求を受信する受信工程と、前記送信要求によって特定されるデータファイルを取得する取得工程と、前記取得工程により取得したデータファイルを解析しデータを加工しやすい構造に変換する第一の変換工程と、前記第一の変換工程により作成されたデータにおいて前期送信要求で指定された要素や属性の内容を加工する内容加工工程と、前記内容加工工程により加工されたデータを元のデータファイルと同じ形式に変換する第２の変換工程とデータファイルを送信要求に基づいて送信する送信工程とを備えることを特徴とする。
【００１４】
また、請求項５記載の情報処理方法は、請求項４に係る情報処理方法において、前記内容加工工程は予めサーバに用意されたアルゴリズムに基づいて、演算処理や置換処理、翻訳処理等の処理を行う工程であることを特徴とする。
また、請求項６記載の情報処理方法は、請求項４に係る情報処理方法において、前記内容加工工程は、クライアントが作成したアルゴリズムに基づいて処理を行う工程であることを特徴とする。
【００１５】
また、請求項７記載の情報処理システムは、請求項１乃至３のいずれかに記載の情報処理装置をドキュメントサーバとして用いることを特徴とする。
【００１６】
【発明の実施の形態】
以下、添付の図面を参照して本発明の実施形態を説明する。
【００１７】
図１は本実施形態におけるドキュメントサーバシステムの構成を示す図である。図１において１１はコンピュータによって構成されるクライアント、１２は、同様にコンピュータなどにより構成されるドキュメントサーバである。１３は文書データに基づく画像を記録紙へ印刷するためのプリンタである。また、１４はインターネットを介して接続されるクライアントとしてのコンピュータである。
【００１８】
図２は本実施形態におけるドキュメントサーバの構成を示すブロック図である。２０１はＬＡＮ回線、２０２は電話回線でそれぞれドキュメントサーバへのデータの出入り口となる。２０３はネットワークインタフェースカード（ＮＩＣ）であり、ＬＡＮ回線２０１上とのデータのやり取りを行う。２０４はモデムでありシリアルポートコントローラ２０５に接続されている。モデム２０４は電話回線２０２との間でデータのやり取りを行う。
【００１９】
２０６はシステムバスであり、各構成要素間の相互のデータ交換が行われる。２０７はハードディスクコントローラであり、ハードディスクドライブ２０８をコントロールする。ハードディスクドライブ２０８には文書データや画像データが蓄積される。また、添付のフローチャートを参照して後述する制御手順を実現するための制御プログラムもハードディスクドライブ２０８に格納される。２０９はＲＡＭであり、様々な処理を実行するためのプログラムロードエリアあるいは処理のためのワークエリアとして使われる。２１０は中央演算処理装置（ＣＰＵ）であり、ＲＡＭ２０９にロードされたプログラムにより種々の処理を実行する。
【００２０】
図３は本実施形態における文書要求パケットのデータ構成例を表す図である。文書要求パケットには、パケットの種類を示すパケット種別フィールド３０１とパケットの長さを表すパケット長フィールド３０２と転送すべき文書ファイルを指定する文書ファイル名フィールド３０３とパケットに含まれる処理リストの個数を表すための処理リスト数フィールド３０４と指定したファイルに対する処理を表す複数の処理リストフィールド３０５から構成される。処理リストフィールド３０５は、処理対象の要素名を指定する要素名フィールド３０６と処理対象の属性を指定する属性名フィールド３０７と指定した要素・属性に対する処理数を示す処理数フィールド３０８および処理フィールド３０９から構成される。要素名フィールド３０６では、ルートからの要素名を列挙することにより変更したい要素の指定を行う。また、親の要素の指定にワイルドカードを利用して一度に複数の要素を指定することも可能である。
【００２１】
処理フィールド３０９は、処理の種類を表す処理種別フィールド３１０と処理内容フィールド３１２の長さを表す処理内容長フィールド３１１と処理内容フィールド３１２から構成される。処理内容フィールド３１２は、処理の種類により内容が異なり、処理の種類が演算処理の場合は計算式が記述され、処理の種類が置換処理の場合は置換するデータが記述され、処理の種類が翻訳処理の場合は処理内容フィールドには翻訳したい言語を示す言語コードが記述される。
【００２２】
図４は演算処理を行う際の処理フィールド３０９の例である。４０１は演算処理を示すコードであり、０ｘ０００１が格納されている。４０２は処理内容長を示す０ｘ０００ａが格納されている。４０３は実際の処理内容である計算式が記述されている。なお、処理内容中の＄ｄは、元の文書中の要素内容の値を表し、“ｉ（〜）”は整数値への変換を意味する。この場合、元の要素内容の値に１．０５を乗じた値の整数部がクライアントへ引き渡す文書での値となる。
【００２３】
図５は、図４の処理を適用した場合の例である。図５（い）はサーバに格納されている文書で、この文書の“＊＜値段＞”要素に図４の処理を適用したものが、図５（ろ）である。なお、“＊”はワイルドカードを意味し、“＊＜値段＞”は全ての＜値段＞要素の内容を変更することを意味する。
【００２４】
次に、クライアントから文書要求パケットを受信した場合の本実施形態におけるドキュメントサーバの動作を説明する。図６は本実施形態におけるドキュメントサーバが文書要求パケットを受け取ったときの処理手順を示すフローチャートである。
【００２５】
まず、ステップＳ６０１において文書要求パケットを受信する。次にステップＳ６０２で、ステップＳ６０１で受け取った文書要求パケットにおいて指定された文書データを読み出し、ステップＳ６０３へ進む。
【００２６】
ステップＳ６０３では処理すべき処理リスト数をチェックし、実行すべき処理リストが存在しなければステップＳ６０９へ進む。ステップＳ６０９では文書データをクライアントに送信して終了する。
【００２７】
一方、ステップＳ６０３において実行すべき処理リストが存在すると、ステップＳ６０４に進む。
【００２８】
ステップＳ６０４では、処理する箇所の特定を容易にするために文書データの構造解析を行い、ＤＯＭ（ドキュメントオブジェクトモデル）を利用してデータを更新するためにツリー構造のデータを作成する。次にステップＳ６０５で処理する要素・属性を決定する。そしてステップＳ６０６において、ステップＳ６０５で特定した要素・属性に対して処理を行い、ステップＳ６０７に進む。ステップＳ６０７では処理リストを全て処理したかをチェックする。全ての処理リストの処理が終了していない場合はステップＳ６０５へ戻る。全ての処理リストの処理が終了した場合はステップＳ６０８へ進む。ステップＳ６０８ではステップＳ６０４で作成したツリー構造のデータから元の文書データの形式に変換し、ステップＳ６０９へ進む。
【００２９】
ステップＳ６０９ではクライアントに文書データを送信し、終了する。
【００３０】
次に、ステップＳ６０６のより詳細な処理の流れを、図７を利用して説明する。まずステップＳ７０１で処理リスト内の処理を全て実行したかをチェックする。処理リスト内の処理を全て実行していない場合は、次の処理を実行するためにステップＳ７０２へ進む。
【００３１】
ステップ７０２では処理の種類を判定する。処理の種類が「演算」である場合はステップＳ７０３へ進む。ステップＳ７０３では、文書要求パケット内で指定された演算式に基づいた演算を行い、ステップＳ６０４で作成したツリー構造のデータの内容を更新してステップＳ７０１へ戻る。
【００３２】
ステップＳ７０２において、処理の種類が「置換」と判定された場合は、ステップＳ７０４へ進む。ステップＳ７０４では、文書要求パケット内で指定された内容に置換する処理を行い、ツリー構造データを更新してステップＳ７０１へ戻る。
【００３３】
ステップＳ７０２において、処理の種類が「翻訳」と判定された場合は、ステップＳ７０５へ進む。ステップＳ７０５では、文書要求パケット内で指定された言語への翻訳処理を行い、ツリー構造のデータを更新してステップＳ７０１へ戻る。
【００３４】
ステップＳ７０２において、処理の種類が「その他」と判定された場合は、このサブルーチンを抜ける。
【００３５】
また、ステップＳ７０１で処理リスト内の処理を全て実行したと判定した場合、このサブルーチンを抜ける。
【００３６】
以上述べたように本実施形態によれば、ドキュメントサーバに蓄積されている文書データをクライアントの要求に応じて修正を施した形で提供することが可能になるので、サーバの使用容量を出来るだけ少なく抑え、なおかつクライアントに余計な負荷をかけることなしに、クライアントの要求にあわせた文書データを提供できるようになる。
【００３７】
なお、上記実施形態では、送信要求においてサーバの対応していない処理を指定しても、それ以降の処理が無視されるだけで、クライアントに文書データが送信される。しかしながら、本発明はこれに限られるものではなく、対応していない処理を指定されたときにはクライアントにエラーを通知するようにしてもよい。
【００３８】
また、上記実施形態では、文書データに対する処理はサーバ側で予め用意されているため、決められた処理しか行うことが出来ない。しかしながら、本発明はこれに限られるものではなく、例えばＪａｖａ（登録商標）のようにクライアント側で作成したオブジェクトを他のホストへ送り込んで実行できるような言語を用いて、クライアント側で作成した処理アルゴリズムに基づいてサーバが文書データを加工してクライアントに文書データを引き渡すようにしてもよい。
【００３９】
また、上記実施形態では、クライアントが変更したい要素・属性の位置をルートからの階層関係で指定するようになっているが、さらに厳密に位置を指定できるようにしてもよい。また、クライアント側からは処理の種類のみを指定するようにし、サーバ側で変更すべき適当な要素・属性を判断するようにしてもよい。
【００４０】
【発明の効果】
以上説明したように、本発明では、クライアントからの要求に応じて変換・置換・翻訳等の処理を文書データに適用し、修正後の文書データをクライアントに引き渡すような構成にしたことにより、サーバにクライアント個別のデータを用意する必要が無くなり、サーバの使用容量を少なく抑えることが出来、処理能力の低いクライアントに余計な負荷をかけることなくクライアントの要求にあわせた文書データを提供することが可能となる。
【図面の簡単な説明】
【図１】本実施形態によるドキュメントサーバシステムの構成を表す図である。
【図２】本実施形態によるドキュメントサーバの構成を示すブロック図である。
【図３】本実施形態による文書要求パケットの構成例を示す図である。
【図４】本実施形態による文書要求パケット中の処理フィールドの例を示す図である。
【図５】本実施形態によるサーバに蓄積されている文書と、その文書に図４の処理を適用した後の文書の例を示す図である。
【図６】本実施形態のドキュメントサーバがクライアントから文書要求パケットを受けたときの処理手順を示すフローチャートである。
【図７】図６におけるステップＳ６０６の処理手順を示すフローチャートである。
【図１】
2004362371.tif 000002
【図２】
2004362371.tif 000003
【図３】
2004362371.tif 000004
【図４】
2004362371.tif 000005
【図５】
2004362371.tif 000006
【図６】
2004362371.tif 000007
【図７】
2004362371.tif 000008