JP2014241035A - サーバー装置、画像の再作成方法及びプログラム - Google Patents

Abstract

【課題】サーバーの負荷を軽減すると共に、適切な大きさの画像を提供することを目的とする。
【解決手段】ビューアを介して文書にアクセスした複数のクライアント端末のクライアント情報を収集する収集手段と、収集手段により収集された複数のクライアント情報を文書と関連付けて蓄積する蓄積手段と、クライアント端末より要求されている文書と関連付けられて蓄積手段により蓄積されているクライアント情報に基づき、文書の画像を再作成するか否かを判断する判断手段と、判断手段により画像を再作成すると判断された場合、画像を再作成する再作成手段と、を有することによって課題を解決する。
【選択図】図８

Description

本発明は、サーバー装置、画像の再作成方法及びプログラムに関する。

文書管理システム等に保存されている文書を、ユーザーが使用するＰＣやモバイル端末等にダウンロードしてから専用のアプリケーションを用いて閲覧するのではなく、Ｗｅｂブラウザ等に配置されたビューアを通じてコンテンツを閲覧する技術がある。このようなビューアは一般的に、サーバーが文書の各ページを画像に変換することにより、クライアント側において専用のアプリケーションを要することなく、文書を閲覧することを可能にしている。
そこにおいてサーバーが文書の画像を生成する際に、その画像のサイズが問題となる場合があった。ビューアへアクセスするクライアントはＰＣ、タブレット端末、携帯電話、スマートフォン等と様々な種類が存在し、その画面サイズや解像度がそれぞれ異なっている。そのためクライアントによっては画像が大きすぎたり小さすぎたりしてしまうことがある。大きすぎる場合はネットワークにおける転送量の増大や、画像によるサーバーのディスク容量の消費につながる。小さすぎる場合は、画像を拡大して表示することになるため、見た目が荒く表示されてしまう。

そこで従来の技術では、クライアント端末の仕様情報に基づき、画像が所定の表示サイズで表示されるように、サーバー側で画素数を変更した表示用画像を生成するものがある（特許文献１参照）。また携帯端末の画面サイズ等の情報をサーバーへ送り、サーバーが画像を縮小するものがある（特許文献２参照）。或いはクライアントがモニターの解像度をサーバーへ送り、サーバーが画像の解像度を変換するものがある（特許文献３参照）。

特開２００８−３３２８０号公報 特開２００３−９９３５７号公報 特開平１１−７３２９５号公報

しかし、従来技術では、クライアント端末がサーバーへアクセスする度に画像変換の判断処理、及び画像変換処理が実行されているため、パフォーマンスに影響を及ぼす問題があった。

本発明はこのような問題点に鑑みなされたもので、サーバーの負荷を軽減すると共に、適切な大きさの画像を提供することを目的とする。

そこで、本発明のサーバー装置は、ビューアを介して文書にアクセスした複数のクライアント端末のクライアント情報を収集する収集手段と、前記収集手段により収集された前記複数のクライアント情報を前記文書と関連付けて蓄積する蓄積手段と、クライアント端末より要求されている文書と関連付けられて前記蓄積手段により蓄積されているクライアント情報に基づき、前記文書の画像を再作成するか否かを判断する判断手段と、前記判断手段により画像を再作成すると判断された場合、前記画像を再作成する再作成手段と、を有する。

本発明によれば、サーバーの負荷を軽減すると共に、適切な大きさの画像を提供することができる。

システム構成を示す図である。 各種サービスを提供する文書管理サーバーのハードウェア構成の一例を示す図である。 文書ビューアを含むＷｅｂサイトをイメージしたＵＩの一例を示す図である。 文書管理サーバーのソフトウェア構成の一例を示した図である。 文書ビューアへアクセスのあったクライアント端末の情報を記録した表の一例を示す図である。 機種別画素数対応表の一例を示す図である。 画素数対応表の一例を示す図である。 文書管理サーバーが、文書ビューアの画像サイズの妥当性を判断する処理の流れを示したフローチャートである。 図８のＳ７０５において、クライアント端末の画素数の平均値を計算する処理の流れを示したフローチャートである。 図５に示すテーブルを生成する処理であって、文書ごとにクライアント端末のアクセス数をカウントする処理の流れを示すフローチャートである。 図５のテーブルに、ページ送りをしたクライアント端末の数を集計した列を追加した一例を示す図である。 クライアント端末からページ送りの命令を受信し、それをカウントする処理の流れを示したフローチャートである。 文書管理サーバーが、文書ビューアの画像サイズの妥当性を判断する処理の流れを示したフローチャートである。 図５のテーブルに、画面の拡大操作をしたクライアント端末の数を集計した列を追加した一例を示す図である。 クライアント端末から画面の拡大操作の命令を受信し、それをカウントする処理の流れを示したフローチャートである。 クライアント端末の画素数の平均値を計算する処理の流れを示したフローチャートである。 図５のテーブルに、文書種別の列を追加した一例を示す図である。 文書ビューアにおいて、文書の新規登録時に文書ビューアの画像を作成する処理の流れを示したフローチャートである。

以下、本発明の実施形態について図面に基づいて説明する。

＜実施形態１＞
実施形態１を図１から図９までに基づいて説明する。
図１は、システム構成を示す図である。
１０１、１０２はどちらもクライアント端末であって、１０１はモバイル端末であり、１０２はＰＣである。図では２台、２種類しか図示していないが、これより多く存在してもよい。
モバイル端末１０１はいわゆるスマートフォンと呼ばれる小型の携帯電話機でもよいし、それよりもサイズの大きいタブレット端末でもよい。モバイル端末１０１はＷｅｂブラウザ等を通じて文書のビューアをユーザーへ表示する。
ＰＣ１０２もモバイル端末１０１と同様に、文書のビューアを表示する。本明細書において両者を区別する必要がない場合は、クライアント端末１０１、１０２と記載する。
１０３は文書管理サーバーである。文書管理サーバー１０３は、一般的な文書の格納、閲覧、検索等の機能も有するが、本実施形態においては、クライアント端末１０１、１０２の要求に応じて文書ビューア機能を提供する。即ちクライアント端末１０１、１０２において専用のアプリケーションを要することなく、文書管理サーバー１０３が持つ文書の中身を閲覧可能なＷｅｂアプリケーションを提供する。図では文書管理サーバー１台のみ示しているが、データベースやアプリケーションサーバー等、機能に応じて複数台に分けた構成であってもよい。

１０４はＷｅｂサーバーである。Ｗｅｂサーバー１０４は、文書管理サーバー１０３のビューアを埋め込んで配信するためのＷｅｂページを有する。Ｗｅｂサーバー１０４が配信するＷｅｂページは、文書ビューアを提供するための専用ページでもよいし、文書管理サーバー１０３とは直接関係のないｂｌｏｇやＳＮＳ等であってもよい。何れの場合においても、文書ビューアはＷｅｂページに埋め込まれて表示される。クライアント端末１０１、１０２は、Ｗｅｂサーバー１０４へアクセスすることにより、文書ビューアを含むＷｅｂページを端末に表示する。
１０５はインターネット網を意味しており、１０１から１０４までの装置はインターネットで接続されている。ただし本システムをローカルネットワーク等のネットワークで接続されたイントラネット内で動作させてもよい。

図２は、各種サービスを提供する文書管理サーバー１０３のハードウェア構成の一例を示す図である。ＣＰＵ１２を含む制御部１１は、文書管理サーバー１０３全体の動作を制御する。ＣＰＵ１２は、ＲＯＭ１３に記憶された制御プログラムを読み出して各種制御処理を実行する。ＲＡＭ１４は、ＣＰＵ１２の主メモリ、ワークエリア等の一時記憶領域として用いられる。ＨＤＤ１５は、画像データや各種プログラム、或いは各種情報テーブル（表）を記憶する。ＣＰＵ１２が、ＲＯＭ１３又はＨＤＤ１５等に記憶されているプログラムに基づき処理を実行することによって、後述する文書管理サーバー１０３の機能や文書管理サーバー１０３におけるフローチャートに係る処理が実現される。
ネットワークＩ／Ｆ１６は、制御部１１（文書管理サーバー１０３）をインターネット１０５に接続する。ネットワークＩ／Ｆ１６は、インターネット１０５上の他の装置との間で各種情報を送受信する。
他の装置も、図２に示す文書管理サーバー１０３のハードウェア構成と同様のハードウェア構成を有し、各装置のＣＰＵが各装置のＲＯＭ等に記憶されているプログラムに基づき処理を実行することによって各装置の機能が実現される。

図３は、文書ビューアを含むＷｅｂサイトをイメージしたＵＩの一例を示す図である。このＵＩはクライアント端末１０１、１０２上に表示される。
２０１はＷｅｂブラウザであり、Ｗｅｂサーバー１０４に存在するＷｅｂページ２０２を表示する。
２０３はＷｅｂページ２０２内に埋め込まれた文書ビューアである。２０３ａは文書ビューア２０３におけるコンテンツ表示領域である。２０３ｂは、コンテンツ表示領域２０３ａのページを送ったり、表示を最大化したりといった操作を指示する領域である。文書ビューア２０３は文書管理サーバー１０３が提供する。
文書ビューア２０３は、Ｗｅｂページ２０２において、ＨＴＭＬにおける＜ｅｍｂｅｄ＞タグや＜ｉｆｒａｍｅ＞タグを使用して埋め込まれる。また文書ビューア２０３は、Ｆｌａｓｈ（登録商標）やＨＴＭＬ５等の既存の技術を使用して構成されている。

図４は、文書管理サーバー１０３のソフトウェア構成の一例を示した図である。
データ送受信部３０１は、クライアント端末１０１、１０２、及びＷｅｂサーバー１０４と通信し、文書ビューア２０３を提供したり、クライアント端末１０１、１０２の情報を受信したりする。
クライアント情報収集部３０２は、クライアント端末１０１、１０２から端末の情報を受信し、それを文書ビューア経由でアクセスのあった文書に関連付けて、図５に示すような形式でデータベース３０７へ保存する。端末の情報とは、端末の画素数（画面サイズ）、解像度、機種情報等である。クライアント情報収集部３０２は、画素数をｊａｖａｓｒｉｐｔ等の言語を用いた機能を実装することで取得可能であるが、それ以外ではクライアント端末１０１、１０２において専用のプラグインやアプリケーションを実行し、画素数等を取得することもできる。また画素数、解像度が直接取得できない場合は、クライアント情報収集部３０２は、図６に示す機種別画素数対応表を用いて、機種情報から画素数を取得し、判断する。クライアント情報収集部３０２は、機種情報を文書管理サーバー１０３に記録されたログ等から取得可能である。
ここで、端末の画素数とは、クライアント端末１０１、１０２の画面の画素数、又はクライアント端末１０１、１０２に付随するモニターの画素数等のことである。

画像サイズ判断部３０３は、データベース３０７に保存されている文書ビューア２０３の画像のサイズが、クライアント端末１０１、１０２に適しているかどうか判断する。また画像サイズ判断部３０３は、画像生成部３０４が生成する画像の適切なサイズを判断する。
画像サイズ判断部３０３は、クライアント情報収集部３０２が保存した画素数の情報から、一定期間にその文書にアクセスがあったクライアント端末１０１、１０２の画素数の平均値を計算する。画像サイズ判断部３０３は、その平均値と、データベース３０７に保存されている文書ビューア２０３の画像のサイズとが、予め定められた閾値以上に異なっているかどうか判断する。異なっている場合には、画像サイズ判断部３０３は、図７に示す画素数対応表に従い、前記計算した平均値に対応する適切なサイズを取得する。

画像生成部３０４は、データベース３０７に保存されている文書の各ページを画像に変換する。変換する画像の形式は問わない。画像生成部３０４は、画像サイズ判断部３０３によって判断されたサイズに従い生成する画像のサイズを決定する。また画像生成部３０４は、生成した画像を文書単位にＦｌａｓｈ等のファイルに１つにまとめてもよい。なお、文書が初めて文書管理サーバー１０３へ登録された場合は、画像生成部３０４は、予め定められた固定のサイズで画像を生成してもよいし、既に登録されている他の文書の画像サイズを参考にしてサイズを算出してもよい。他の文書を参考にする場合は、画像生成部３０４は、全文書の画像サイズの平均値を算出する。又は、画像生成部３０４は、ランダムにピックアップした文書の画像サイズの平均値を算出する。又は、画像生成部３０４は、最近アクセスの多い文書の画像サイズの平均値を算出する。例えば、画像生成部３０４は、設定値等に基づき、何に基づき画像サイズの平均値を算出するかを決定する。
文書ビューア部３０５は、クライアント端末１０１、１０２のアクセスに応じて、文書ビューア２０３を提供し、またページ送り等の要求に対して処理を実行する。
ＤＢ通信部３０６は、データベース３０７へ文書、文書ビューアの画像、クライアント端末情報等の読み書きを実行する。
データベース３０７は、文書管理サーバー１０３のＨＤＤ１５等に記憶されていてもよいし、ネットワーク等を介して通信可能な他の装置に記憶されていてもよい。以下では、説明の簡略化のため、文書管理サーバー１０３のＨＤＤ１５等に記憶されているものとして説明を行う。

図５は、文書ビューアへアクセスのあったクライアント端末１０１、１０２の情報を記録した表の一例を示す図である。４０１は文書ＩＤであり、データベース３０７に保存されている文書を一意に表したＩＤである。４０２は機種情報であり、携帯電話、スマートフォン、タブレット端末等の機種名やメーカー等の情報等が記録される。機種情報がクライアント端末１０１、１０２から取得できない場合は、空となる。４０３はクライアント端末１０１、１０２の縦方向の画素数であり、４０４は横方向の画素数である。４０３、４０４は取得できない場合は空となる。４０５は文書ＩＤ４０１に対し、同じ機種、又は同じ画素数のクライアント端末１０１、１０２のアクセス数を文書管理サーバー１０３がカウントした値である。

図６は、機種別画素数対応表の一例を示す図である。図６に示す機種別画素数対応表は、データベース３０７に予め登録されている。５０１は機種情報であり、携帯電話、スマートフォン、タブレット端末等の機種名やメーカー等の情報等が記録される。５０２は５０１に対応する縦方向の画素数である。５０３は５０１に対応する横方向の画素数である。
図７は、画素数対応表の一例を示す図である。画素数対応表は、データベース３０７に予め登録されている。６０１は画素数の平均値である。６０２は最適画像サイズである。これらの値は画像の縦横比は維持する意味から、６０１と６０２とで統一されていれば、画面の縦方向、横方向どちらを意味していてもよい。
例を挙げると、画像サイズ判断部３０３が算出した平均値が４５０だった場合、平均画素数６０１は「４００−４９９」の行に該当し、最適画像サイズ６０２は「４００」となる。これらの値の範囲や値は一例であり、管理者が不図示の入力装置等を介してチューニングしてもよい。

図８は、文書管理サーバー１０３が、文書ビューア２０３の画像サイズの妥当性を判断する処理の流れを示したフローチャートである。文書管理サーバー１０３は、この処理を、例えば１日に１回等、決められた間隔で定期的に実行する。
画像サイズ判断部３０３は、データベース３０７に保存されている文書の中から文書を１つ選択する（Ｓ７０１）。このとき、画像サイズ判断部３０３は、クライアント端末１０１、１０２から一定期間アクセスがない文書は、対象外としてもよい。
次に画像サイズ判断部３０３は、データベース３０７に保存されている図５のテーブルを参照し、その文書に対するクライアント端末１０１、１０２のアクセス数を調べる（Ｓ７０２）。
画像サイズ判断部３０３は、アクセス数が予め定められた閾値に満たないクライアント端末１０１、１０２を、以降の処理の対象外とする（Ｓ７０３）。例えば、閾値が５回で、機種「ＡＡＡ」がその文書に対して３回しかアクセスがなかった場合、画像サイズ判断部３０３は、機種「ＡＡＡ」のアクセス数はゼロであったとみなし、処理の対象外とする。

次に画像サイズ判断部３０３は、Ｓ７０３で対象外とならなかったクライアント端末１０１、１０２が存在するかどうか判断し（Ｓ７０４）、存在する場合は、画素数の平均値を計算する（Ｓ７０５）。Ｓ７０５の処理は図９を用いて後述する。
画像サイズ判断部３０３は、Ｓ７０５で計算した平均値から、データベース３０７に保存されている図７のテーブルを参照し、最適な画像のサイズを取得する（Ｓ７０６）。
そして画像サイズ判断部３０３は、その時点の文書の画像サイズと、Ｓ７０６で取得した画像サイズと、を比較し、再作成が必要かどうか判断する（Ｓ７０７）。判断の基準としては、例えば３００ピクセル以上異なっていたら再作成する等がある。
Ｓ７０７において再作成が必要と判断された場合、画像生成部３０４は、Ｓ７０６で取得した画像サイズで、文書の各ページの画像を生成する（Ｓ７０８）。
画像サイズ判断部３０３はデータベース３０７に保存されている文書をすべて処理したかどうか調べ（Ｓ７０９）、処理していたら図８に示す処理を終了する。

図９は、図８のＳ７０５において、クライアント端末１０１、１０２の画素数の平均値を計算する処理の流れを示したフローチャートである。
画像サイズ判断部３０３は、図５のテーブルを参照し、文書に対応する機種を選択する（Ｓ８０１）。機種が空の場合は、画像サイズ判断部３０３は、画素数を取得する。
次に画像サイズ判断部３０３は、機種の画素数が不明かどうか調べ（Ｓ８０２）、不明であれば図６のテーブルを参照して機種に対応する画素数を取得する（Ｓ８０３）。
次に画像サイズ判断部３０３は、画素数とアクセス数とを乗算し（Ｓ８０４）、結果を一時的に保存する（Ｓ８０５）。
画像サイズ判断部３０３は、文書に対応する端末をすべて処理したかどうか調べ（Ｓ８０６）、処理していたら、Ｓ８０５で保存した値を全端末で合計し、その値を端末数で除算する（Ｓ８０７）。得られた値が平均値となる。

図１０は、図５に示すテーブルを生成する処理であって、文書ごとにクライアント端末１０１、１０２のアクセス数をカウントする処理の流れを示すフローチャートである。
クライアント情報収集部３０２は、クライアント端末１０１、１０２のアクセスを受け、データ送受信部３０１を通じて機種情報、又は画素数情報を受信する（Ｓ９０１）。
クライアント情報収集部３０２は、同じ機種、或いは同じ画素数のクライアント端末１０１、１０２がその文書に過去にアクセスがあるかどうか調べる（Ｓ９０２）。即ち、クライアント情報収集部３０２は、データベース３０７に対し、その文書に対し同じ機種、或いは同じ画素数のレコードが存在するかどうか調べる。
存在しなければ、クライアント情報収集部３０２は、新規にレコードを作成する（Ｓ９０３）。
最後にクライアント情報収集部３０２は、アクセスがあったことを示すレコードの値をインクリメントする。

＜実施形態２＞
実施形態２を図１１から図１３までに基づいて説明する。本実施形態では、文書管理サーバー１０３は、文書ビューア２０３を、ユーザーがページ送りをしたかどうかその情報を集計し、ページ送りがされていなければ、このページは画像再作成の対象外とする、又は小サイズの画像へ変換する。前記情報は、ページ送り操作が実行されたか否かの操作情報の一例である。
図１１は、図５のテーブルに、ページ送りをしたクライアント端末１０１、１０２の数を集計した列を追加した一例を示す図である。１００１はページ送りしたクライアント端末１０１、１０２を集計する列であり、４０５の値以下の値が記録される。
図１２は、クライアント端末１０１、１０２からページ送りの命令を受信し、それをカウントする処理の流れを示したフローチャートである。
クライアント情報収集部３０２は、データ送受信部３０１を通じてクライアント端末１０１、１０２の命令を受信する（Ｓ１１０１）。
クライアント情報収集部３０２は、命令がページ送りであるかどうか調べ（Ｓ１１０２）、ページ送りであれば図１１の１００１に示す、ページ送りの値をインクリメントする（Ｓ１１０３）。

図１３は、文書管理サーバー１０３が、文書ビューア２０３の画像サイズの妥当性を判断する処理の流れを示したフローチャートである。図８と異なる処理についてのみ説明する。
画像サイズ判断部３０３は、データベース３０７にアクセスし、ページ送りがされた回数を調べ、２ページ目以降も画像を再作成する必要があるかどうか判断する（Ｓ１２０１）。例えば、画像サイズ判断部３０３は、その文書に対する全端末の「ページ送りしたクライアントの数」を合計し、予め定められた閾値を超えるか否かで前記判断を行う。
Ｓ１２０１において全ページ再作成すると判断した場合は、画像生成部３０４は、全ページの画像を再作成する（Ｓ１２０２）。この処理は図８のＳ７０８と同一である。
Ｓ１２０１において２ページ目以降は画像を再作成しないと判断した場合は、画像生成部３０４は、１ページ目のみ画像を再作成する（Ｓ１２０３）。２ページ目以降は処理の対象外とする。或いは、図では表していないが、画像生成部３０４は、２ページ目以降は画像のサイズを小さくするように再作成してもよい。

なお本実施形態では、クライアント端末１０１、１０２によって２ページ目以降が閲覧されたかどうかで判断をしたが、より詳細に各ページで判断してもよい。即ち、画像サイズ判断部３０３は、５ページ目以降は閲覧されていない、２０ページから２５ページだけ閲覧されている等、ページごとにアクセス数をカウントし、それに応じて画像の再作成もページごとに判断してもよい。また、画像サイズ判断部３０３は、各ページの閲覧時間（＝表示している時間）に基づき、閲覧されている、されていないを判断してもよい。
本実施形態によって、閲覧数が少ないページの画像を再作成する処理を省くことができる。或いは、閲覧数が少ないページの画像のサイズを小さくする。このことにより、文書管理サーバー１０３のディスク消費量の削減やデータ通信量を低減することができる。

＜実施形態３＞
実施形態３を図１４から図１６までに基づいて説明する。本実施形態では、文書管理サーバー１０３は、文書ビューア２０３を、ユーザーが画面を拡大する操作をしたかどうかその情報を集計し、拡大操作されていたら大きいサイズの画像を作成する。前記情報は、文書の拡大操作が実行されたか否かの操作情報の一例である。
図１４は、図５のテーブルに、画面の拡大操作をしたクライアント端末１０１、１０２の数を集計した列を追加した一例を示す図である。１３０１は画面の拡大操作をしたクライアント端末１０１、１０２を集計する列であり、４０５の値以下の値が記録される。
図１５は、クライアント端末１０１、１０２から画面の拡大操作の命令を受信し、それをカウントする処理の流れを示したフローチャートである。
クライアント情報収集部３０２は、データ送受信部３０１を通じてクライアント端末１０１、１０２の命令を受信する（Ｓ１４０１）。クライアント情報収集部３０２は、命令が画面の拡大操作であるかどうか調べ（Ｓ１４０２）、拡大操作であれば、図１４の１３０１に示す、拡大操作の値をインクリメントする（Ｓ１４０３）。

図１６は、クライアント端末１０１、１０２の画素数の平均値を計算する処理の流れを示したフローチャートである。図９と異なる処理についてのみ説明する。
画像サイズ判断部３０３は、データベース３０７にアクセスし、拡大操作がされた回数を調べる（Ｓ１５０１）。例えばその端末の拡大操作が予め定められた閾値よりも多かった場合、画像サイズ判断部３０３は、拡大操作があると判断する。
Ｓ１５０１で拡大操作があると判断した場合は、画像サイズ判断部３０３は、画素数に拡大操作分の値をプラスする（Ｓ１５０２）。例えば、ユーザーが３０％画面を拡大操作したとした場合、画像サイズ判断部３０３は、Ｓ８０３までのステップで得られた画素数の値を３０％増加させる。Ｓ８０４以降の処理は、増加した画素数に対し、処理が実行される。その結果、サイズが増大された画像が再作成される。
本実施形態によって、画面の拡大操作を行うクライアント端末１０１、１０２が多く存在する場合は、画像のサイズをより大きくすることで、拡大しても荒い画像になることなく文書ビューア２０３を提供することができる。
なお本実施形態では拡大操作について述べたが、文書管理サーバー１０３は、縮小についてもどうような処理を実行してもよい。また、文書管理サーバー１０３は、文書ビューア２０３を構成する画像のサイズのみならず、文書ビューア２０３自体のサイズを拡大、縮小操作に応じて変化させてもよい。その場合、文書管理サーバー１０３は、例えばＨＴＭＬタグのピクセル数、又はパーセンテージの値を変更する。

＜実施形態４＞
実施形態４を図１７、図１８に基づいて説明する。本実施形態では、文書の種別に応じて文書ビューア２０３の画像のサイズを変更する。
図１７は、図５のテーブルに、文書種別の列を追加した一例を示す図である。１６０１は文書種別の列で、いわゆるファイルの拡張子で分類され、例えば「スライド」、「画像」、「ＰＤＦ」等に分類される。
図１８は、文書ビューア２０３において、文書の新規登録時に文書ビューア２０３の画像を作成する処理の流れを示したフローチャートである。
ＤＢ通信部３０６が新規に文書の登録を受け付けると（Ｓ１７０１）、画像サイズ判断部３０３は、文書種別を調べる（Ｓ１７０２）。
文書種別がスライド、或いは画像である場合は（Ｓ１７０３）、画像生成部３０４は、文書の画像を小さいサイズで生成する（Ｓ１７０４）。文書種別がスライド、或いは画像でない場合は、画像生成部３０４は、文書の画像を大きいサイズで生成する（Ｓ１７０５）。小さいサイズ、大きいサイズ、とは予め拡縮の割合が定められているものとする。

本実施形態によって、スライドや画像等、概要が把握できれば目的を達成できる可能性が高い文書については小さいサイズで画像を作成される。それでなく文字を認識したいと思われる文書については大きいサイズで画像を作成される。このことによって、より適切なサイズで画像を生成できる。
なお文書管理サーバー１０３は、画像系のファイルに関してはＯＣＲをかけた上で文字が存在するかどうか調べ、存在すればＳ１７０５と同じく画像を大きいサイズで作成してもよい。

＜その他の実施形態＞
また、本発明は、以下の処理を実行することによっても実現される。即ち、上述した実施形態の機能を実現するソフトウェア（プログラム）を、ネットワーク又は各種記憶媒体を介してシステム或いは装置に供給し、そのシステム或いは装置のコンピュータ（又はＣＰＵやＭＰＵ等）がプログラムを読み出して実行する処理である。

以上、上述した各実施形態によれば、ビューアの画像を適切なサイズで生成できると共に、クライアント端末の情報を収集、蓄積し、統計した情報を用いることによって画像サイズを判断する。そのため、アクセス毎の判断を回避でき、パフォーマンスの向上を図ることができる。
よって、サーバーの処理等に負荷をかけずに、適切な大きさの画像を提供することができる。

以上、本発明の好ましい実施形態について詳述したが、本発明は係る特定の実施形態に限定されるものではなく、特許請求の範囲に記載された本発明の要旨の範囲内において、種々の変形・変更が可能である。

Claims (9)

1. ビューアを介して文書にアクセスした複数のクライアント端末のクライアント情報を収集する収集手段と、
   前記収集手段により収集された前記複数のクライアント情報を前記文書と関連付けて蓄積する蓄積手段と、
   クライアント端末より要求されている文書と関連付けられて前記蓄積手段により蓄積されているクライアント情報に基づき、前記文書の画像を再作成するか否かを判断する判断手段と、
   前記判断手段により画像を再作成すると判断された場合、前記画像を再作成する再作成手段と、
   を有するサーバー装置。
2. 前記収集手段は、ビューアを介して文書にアクセスした複数のクライアント端末に係る画素数をクライアント情報として収集し、
   前記蓄積手段は、前記収集手段により収集された前記複数のクライアント端末に係る画素数を前記文書と関連付けて蓄積し、
   前記判断手段は、クライアント端末より要求されている文書と関連付けられて前記蓄積手段により蓄積されている前記複数のクライアント端末に係る画素数の平均値と、前記ビューアの画像のサイズと、に基づいて、前記文書の画像を再作成するか否かを判断する請求項１記載のサーバー装置。
3. 前記収集手段は、ビューアを介して文書にアクセスした複数のクライアント端末の機種情報をクライアント情報として収集し、
   前記蓄積手段は、前記収集手段により収集された前記複数のクライアント端末の機種情報を前記文書と関連付けて蓄積し、
   前記判断手段は、クライアント端末より要求されている文書と関連付けられて前記蓄積手段により蓄積されている前記複数のクライアント端末の機種情報から前記複数のクライアント端末に係る画素数を取得し、取得した前記複数のクライアント端末に係る画素数の平均値と、前記ビューアの画像のサイズと、に基づいて、前記文書の画像を再作成するか否かを判断する請求項１記載のサーバー装置。
4. 前記収集手段は、ビューアを介して文書にアクセスした複数のクライアント端末において前記ビューアを介して文書のページ送り操作が実行されたか否かの操作情報を更に収集し、
   前記蓄積手段は、前記収集手段により収集された前記操作情報を前記文書と関連付けて蓄積し、
   前記判断手段は、クライアント端末より要求されている文書と関連付けられて前記蓄積手段により蓄積されている前記操作情報に基づいて、文書の２ページ目以降の画像も再作成するか否かを更に判断し、
   前記再作成手段は、前記判断手段により前記文書の画像を再作成し、更に前記文書の２ページ目以降の画像も再作成すると判断された場合、前記文書の全ページの画像を再作成し、前記判断手段により前記文書の画像を再作成するが、前記文書の２ページ目以降の画像は再作成しないと判断された場合、前記文書の１ページ目の画像を再作成する請求項１乃至３何れか１項記載のサーバー装置。
5. 前記収集手段は、ビューアを介して文書にアクセスした複数のクライアント端末において前記ビューアを介して文書の拡大操作が実行されたか否かの操作情報を更に収集し、
   前記蓄積手段は、前記収集手段により収集された前記操作情報を前記文書と関連付けて蓄積し、
   前記再作成手段は、前記画像を再作成する際に、クライアント端末より要求されている文書と関連付けて前記蓄積手段により蓄積されている前記操作情報に基づいて、拡大操作がなされているか否かを判断し、拡大操作がなされている場合は、画像のサイズを増大させて画像を再作成する請求項１乃至３何れか１項記載のサーバー装置。
6. 文書の新規登録時に前記文書の画像を作成し、登録する作成手段を更に有する請求項１乃至５何れか１項記載のサーバー装置。
7. 前記作成手段は、前記文書の種別に応じて、作成する画像のサイズを決定する請求項６記載のサーバー装置。
8. サーバー装置が実行する画像の再作成方法であって、
   ビューアを介して文書にアクセスした複数のクライアント端末のクライアント情報を収集する収集ステップと、
   前記収集ステップにより収集された前記複数のクライアント情報を前記文書と関連付けて蓄積する蓄積ステップと、
   クライアント端末より要求されている文書と関連付けられて前記蓄積ステップにより蓄積されているクライアント情報に基づき、前記文書の画像を再作成するか否かを判断する判断ステップと、
   前記判断ステップにより画像を再作成すると判断された場合、前記画像を再作成する再作成ステップと、
   を含む画像の再作成方法。
9. コンピュータに、
   ビューアを介して文書にアクセスした複数のクライアント端末のクライアント情報を収集する収集ステップと、
   前記収集ステップにより収集された前記複数のクライアント情報を前記文書と関連付けて蓄積する蓄積ステップと、
   クライアント端末より要求されている文書と関連付けられて前記蓄積ステップにより蓄積されているクライアント情報に基づき、前記文書の画像を再作成するか否かを判断する判断ステップと、
   前記判断ステップにより画像を再作成すると判断された場合、前記画像を再作成する再作成ステップと、
   を実行させるためのプログラム。

Images