図面 (/)

技術 クラウドシステムにおける文書ファイルの生成サービスを提供する装置、方法及びプログラム

出願人 キヤノン株式会社
発明者 母里南陽
出願日 2016年9月27日 (4年1ヶ月経過) 出願番号 2016-188119
公開日 2018年4月5日 (2年7ヶ月経過) 公開番号 2018-055241
状態 特許登録済
技術分野 検索装置 文書処理装置 計算機におけるファイル管理
主要キーワード 今後表示 SVGファイル 未アクセス 起動数 画像リソース ファイル化処理 総ファイル数 クラウドシステム
関連する未来課題
重要な関連分野

この項目の情報は公開日時点(2018年4月5日)のものです。
また、この項目は機械的に抽出しているため、正しく解析できていない場合があります

図面 (14)

課題

クラウドシステム上で文書ファイルの生成・保存のサービスを提供する場合において、生成される文書ファイルのファイル数抑制と表示パフォーマンスの維持を両立させる。

解決手段

クラウドコンピューティングシステムにおいて、文書ファイルの生成サービスを提供するサーバ装置であって、文書ファイルの元になる元データをクライアント装置から受け取る通信手段と、前記元データに含まれるリソースファイル化して文書ファイルを生成するファイル化手段と、生成された文書ファイルをストレージに保存する保存手段と、を備え、前記ファイル化手段は、前記ストレージに保存されている文書ファイルへのアクセス状況に応じて、生成する文書ファイルの構成を変更することを特徴とする。

概要

背景

近年、サーバコンピュータ側で業務データの管理や各種処理を行う形態として、クラウドコンピューティングシステム(以下、「クラウドシステム」)が普及し始めている。ユーザは、クライアント装置Webブラウザからインターネットを介してクラウドサーバWebページアクセスし、そのWebページ上で業務データを生成・閲覧編集することができる。具体的には、ユーザがWebページを介して業務データをアップロードすると、クラウドサービスによって所定フォーマット文書ファイルが生成されてWebブラウザ上に表示される。また、生成された文書ファイルはストレージに保存され、ユーザは保存された文書ファイルをダウンロードしてWebブラウザ上に表示させて、当該文書の編集を行うことができる。

クラウドサービスが生成する文書ファイルの所定フォーマットの一例としてSVG(Scalable Vector Graphics)が挙げられる。SVGは、XML (Extensible Markup Language)をベースとした、ベクタ形式で画像を描画するフォーマットであり、Webブラウザでの表示に関して親和性が高いと言われている。また、SVGは、同じベクタ形式のフォーマットであるPDF(Portable Document Format)とは異なり、各種リソース別ファイルとしても構成できるという特徴を持っている。そのため、同じ描画内容でもSVGの構成によってファイル数が異なるという特徴がある。具体的には、複数のリソースを、インライン方式記述する場合にはファイル数が少なく、外部参照方式で記述する場合にはファイル数が多くなる。

上述の通り、クラウドサービスによって生成された文書ファイルは、クラウドサーバの構成要素としてのストレージに保存され、クライアント装置はWebブラウザで表示する際にストレージにアクセスして文書ファイルを取得する。ストレージは、クラウドシステム上の複数のクライン端末からのアクセスを受け付けるため、一定以上の負荷が掛かるとアクセスが制限されるようになっている。ストレージに保存されているファイルへのアクセス数が単位時間あたりで一定数超過してアクセス制限が生じると、ユーザは、現在処理中のファイルの読み込みや書き込み処理が完了するまで待機を余儀なくされてしまう。この点、アクセスが集中しても可能な限りアクセス制限が生じないようにするには、SVG形式で文書ファイルを生成する際にインライン方式を適用すればよいということになる。しかしながら、インライン方式の場合には、ファイル数が少なくなる分だけ1ファイルあたりのデータサイズが大きくなり、生成された文書ファイルのページをクライアント装置で表示する際の処理が重くなるという欠点がある。したがって、クラウドシステム上で文書ファイルを生成・保存するにあたっては、ファイル数の抑制と表示処理パフォーマンス維持というトレードオフの関係にある事項両立を図る必要がある。

概要

クラウドシステム上で文書ファイルの生成・保存のサービスを提供する場合において、生成される文書ファイルのファイル数抑制と表示パフォーマンスの維持を両立させる。クラウドコンピューティングシステムにおいて、文書ファイルの生成サービスを提供するサーバ装置であって、文書ファイルの元になる元データをクライアント装置から受け取る通信手段と、前記元データに含まれるリソースをファイル化して文書ファイルを生成するファイル化手段と、生成された文書ファイルをストレージに保存する保存手段と、を備え、前記ファイル化手段は、前記ストレージに保存されている文書ファイルへのアクセス状況に応じて、生成する文書ファイルの構成を変更することを特徴とする。

目的

本発明に係るサーバ装置は、クラウドコンピューティングシステムにおいて、文書ファイルの生成サービスを提供する

効果

実績

技術文献被引用数
0件
牽制数
0件

この技術が所属する分野

ライセンス契約や譲渡などの可能性がある特許掲載中! 開放特許随時追加・更新中 詳しくはこちら

請求項1

クラウドコンピューティングシステムにおいて、文書ファイルの生成サービスを提供するサーバ装置であって、文書ファイルの元になる元データをクライアント装置から受け取る通信手段と、前記元データに含まれるリソースファイル化して文書ファイルを生成するファイル化手段と、生成された文書ファイルをストレージに保存する保存手段と、を備え、前記ファイル化手段は、前記ストレージに保存されている文書ファイルへのアクセス状況に応じて、生成する文書ファイルの構成を変更することを特徴とするサーバ装置。

請求項2

前記アクセス状況を、所定の指標に基づいて判定する解析手段をさらに備えたことを特徴とする請求項1に記載のサーバ装置。

請求項3

前記所定の指標は、前記ストレージに保存されている文書ファイルへのアクセス履歴であることを特徴とする請求項2に記載のサーバ装置。

請求項4

前記アクセス履歴は、前記ストレージに保存されている文書ファイルのうち、前記クライアント装置から未だアクセスがなされていない文書ファイルについての、前記クライアント装置からのファイル化の要求に対応するジョブの数であることを特徴とする請求項3に記載のサーバ装置。

請求項5

前記アクセス履歴は、前記ストレージに保存された文書ファイルのうち、前記クライアント装置から未だアクセスがなされていない文書ファイルを構成するファイルの数であることを特徴とする請求項3に記載のサーバ装置。

請求項6

前記通信手段、前記ファイル化手段及び前記保存手段は、前記クライアント装置からの要求の数に応じて起動数が変動するソフトウェアによって実現され、前記所定の指標は、前記サーバ装置において起動している前記ソフトウェアの数であることを特徴とする請求項3に記載のサーバ装置。

請求項7

前記所定の指標は、前記ストレージへの単位時間あたりのアクセス数であることを特徴とする請求項3に記載のサーバ装置。

請求項8

前記ファイル化手段は、前記元データに含まれる各リソースを、インライン方式又は外部参照方式のいずれかの方式を適用してファイル化することで、生成する文書ファイルの構成を変更することを特徴とする請求項1乃至7のいずれか1項に記載のサーバ装置。

請求項9

前記解析手段は、前記アクセス状況に応じて、前記インライン方式を適用する際の条件を決定し、前記ファイル化手段は、前記元データに含まれるリソースが前記条件を満たす場合には前記インライン方式を適用して当該リソースをファイル化し、前記元データに含まれるリソースが前記条件を満たさない場合には前記外部参照方式を適用して当該リソースをファイル化することを特徴とする請求項8に記載のサーバ装置。

請求項10

前記条件は、前記リソースのデータサイズが閾値以下であることを特徴とする請求項9に記載のサーバ装置。

請求項11

前記条件は、前記リソースの数が閾値以下であることを特徴とする請求項9に記載のサーバ装置。

請求項12

前記ファイル化手段は、前記元データの複数のページ同一内容のリソースが存在する場合、当該リソースが当該複数のページで共有されるようにファイル化することを特徴とする請求項1乃至11のいずれか1項に記載のサーバ装置。

請求項13

前記ファイル化手段は、保存されている文書ファイルに対する同時アクセスが一定数以上見込まれない場合に、先頭ページのみを外部参照方式でファイル化することを特徴とする請求項1乃至11に記載のサーバ装置。

請求項14

前記リソースは、画像情報フォント情報スタイル情報であることを特徴とすることを特徴とする請求項1乃至13に記載のサーバ装置。

請求項15

前記ファイル化手段は、前記元データに、同一種類の画像情報が複数存在した場合、結合して1つの画像情報としてファイル化することを特徴とする請求項14に記載のサーバ装置。

請求項16

クラウドコンピューティングシステムにおいて、文書ファイルの生成サービスを提供する方法であって、文書ファイルの元になる元データをクライアント装置から受け取るステップと、受け取った前記元データに含まれるリソースをファイル化して文書ファイルを生成するステップと、生成された文書ファイルをストレージに保存するステップと、を含み、前記生成するステップでは、前記ストレージに保存されている文書ファイルへのアクセス状況に応じて、生成する文書ファイルの構成が変更されることを特徴とする方法。

請求項17

コンピュータを請求項1乃至15のいずれか1項に記載のサーバ装置として機能させるためのプログラム

技術分野

0001

クラウドシステム上で文書ファイルを生成する技術に関する。

背景技術

0002

近年、サーバコンピュータ側で業務データの管理や各種処理を行う形態として、クラウドコンピューティングシステム(以下、「クラウドシステム」)が普及し始めている。ユーザは、クライアント装置Webブラウザからインターネットを介してクラウドサーバWebページアクセスし、そのWebページ上で業務データを生成・閲覧編集することができる。具体的には、ユーザがWebページを介して業務データをアップロードすると、クラウドサービスによって所定フォーマットの文書ファイルが生成されてWebブラウザ上に表示される。また、生成された文書ファイルはストレージに保存され、ユーザは保存された文書ファイルをダウンロードしてWebブラウザ上に表示させて、当該文書の編集を行うことができる。

0003

クラウドサービスが生成する文書ファイルの所定フォーマットの一例としてSVG(Scalable Vector Graphics)が挙げられる。SVGは、XML (Extensible Markup Language)をベースとした、ベクタ形式で画像を描画するフォーマットであり、Webブラウザでの表示に関して親和性が高いと言われている。また、SVGは、同じベクタ形式のフォーマットであるPDF(Portable Document Format)とは異なり、各種リソース別ファイルとしても構成できるという特徴を持っている。そのため、同じ描画内容でもSVGの構成によってファイル数が異なるという特徴がある。具体的には、複数のリソースを、インライン方式記述する場合にはファイル数が少なく、外部参照方式で記述する場合にはファイル数が多くなる。

0004

上述の通り、クラウドサービスによって生成された文書ファイルは、クラウドサーバの構成要素としてのストレージに保存され、クライアント装置はWebブラウザで表示する際にストレージにアクセスして文書ファイルを取得する。ストレージは、クラウドシステム上の複数のクライン端末からのアクセスを受け付けるため、一定以上の負荷が掛かるとアクセスが制限されるようになっている。ストレージに保存されているファイルへのアクセス数が単位時間あたりで一定数超過してアクセス制限が生じると、ユーザは、現在処理中のファイルの読み込みや書き込み処理が完了するまで待機を余儀なくされてしまう。この点、アクセスが集中しても可能な限りアクセス制限が生じないようにするには、SVG形式で文書ファイルを生成する際にインライン方式を適用すればよいということになる。しかしながら、インライン方式の場合には、ファイル数が少なくなる分だけ1ファイルあたりのデータサイズが大きくなり、生成された文書ファイルのページをクライアント装置で表示する際の処理が重くなるという欠点がある。したがって、クラウドシステム上で文書ファイルを生成・保存するにあたっては、ファイル数の抑制と表示処理パフォーマンス維持というトレードオフの関係にある事項両立を図る必要がある。

先行技術

0005

特開2015−5150号公報

発明が解決しようとする課題

0006

クラウドシステム上で扱われる文書ファイルの構成を条件に基づいて変更する手法としては、例えば、特許文献1がある。これは、PDF形式で文書ファイルを生成する際に、描画データ中のリソースの一種であるフォントの埋め込み指定の有無を判定し、指定があった場合はフォントを文書ファイルに埋め込むというものである。しかし、この特許文献1の手法は、生成される文書ファイルのファイル数に変化はなく、SVGのような構造の文書ファイルを生成するケースにおける、ファイル数の抑制と表示処理パフォーマンスとの両立という課題解決には役立たない。

課題を解決するための手段

0007

本発明に係るサーバ装置は、クラウドコンピューティングシステムにおいて、文書ファイルの生成サービスを提供するサーバ装置であって、文書ファイルの元になる元データをクライアント装置から受け取る通信手段と、前記元データに含まれるリソースをファイル化して文書ファイルを生成するファイル化手段と、生成された文書ファイルをストレージに保存する保存手段と、を備え、前記ファイル化手段は、前記ストレージに保存されている文書ファイルへのアクセス状況に応じて、生成する文書ファイルの構成を変更する
ことを特徴とする。

発明の効果

0008

本発明によれば、クラウドシステム上で文書ファイルの生成・保存のサービスを提供する場合において、ストレージへのアクセス状況に応じ、生成する文書ファイルの構成が変更される。これにより、ファイル数の抑制と表示パフォーマンスの維持を両立させることが可能になる。

図面の簡単な説明

0009

クラウドシステムの構成例を示す図である。
クラウドサーバ及びクライアント装置のハードウェア構成の一例を示すブロック図である。
クラウドシステムを実現するソフトウェアの構成例を示す図である。
ファイル生成サービスの内部構成を示す図である。
SVG文書ファイル構成の一例を示す図であり、(a)は外部参照方式、(b)はインライン方式を示す。
データストレージがSVG文書を格納する際のデータ構造の一例を示す図である。
実施例1に係る、ファイル化処理の流れを示すフローチャートである。
実施例1に係る、同一の元データから生成される3種類のSVG文書のファイル構成を説明する図である。
実施例1の変形例によって生成される、SVG文書のファイル構成を説明する図である。
実施例2に係る、ファイル化処理の流れを示すフローチャートである。
実施例2によって生成される、SVG文書のファイル構成を説明する図である。
実施例3に係る、ファイル化処理の流れを示すフローチャートである。
実施例3によって生成される、SVG文書のファイル構成を説明する図である。

0010

以下、添付図面を参照して、本発明を好適な実施例に従って詳細に説明する。なお、以下の実施例において示す構成は一例にすぎず、本発明は図示された構成に限定されるものではない。

0011

システム構成
本実施例では、クライアント装置からの要求に従い、クラウドサーバがSVG形式の文書ファイルを生成・保存するクラウドサービスを提供する場面を前提として説明を行うものとする。図1は、クラウドコンピューティングシステム(クラウドシステム)の構成例を示す図である。クラウドシステム100は、クラウドサービスを提供するサーバ装置(クラウドサーバ)102と、複数のクライアント装置103とで構成され、これらがLAN104とインターネット101を介して相互に接続されている。インターネット101は、ファイアウォールを越えてクラウドサーバ102とクライアント装置103との間で、SVG形式の文書ファイルを生成する際の元になるデータ(以下、「元データ」と呼ぶ。)やユーザ指示をやり取りするための通信回線である。クライアント装置103は、各ユーザに割り当てられたパーソナルコンピュータタブレットスマートフォンなどの端末を指す。また、LAN104、インターネット101は、例えば、TCP/IPプロトコルなどをサポートする通信回線網であり有線無線は問わない。尚、クラウドサーバ102は、1台のコンピュータでもよいし、機能・役割に応じた複数のコンピュータで構成してもよい。例えば、Webサービスを担うWebサーバ、文書ファイルの生成サービスを担うアプリケーションサーバデータ保存を担うストレージサーバといったように複数のコンピュータで構成してもよい。また、複数のコンピュータでクラウドサーバ102を実現する場合は、その一部が仮想PCとして構成されていても構わない。

0012

図2は、クラウドサーバ102及びクライアント装置103のハードウェア構成の一例を示すブロック図である。CPU201は、ROM206内部のプログラム領域に記憶されたプログラム、ハードディスク203からRAM202にロードされたOS、汎用アプリケーションなどのプログラムを実行する。RAM202は、CPU201の主メモリワークエリア等として機能する。ハードディスク203は、ブートプログラム、種々のアプリケーション、フォントデータ、ユーザファイル電子原稿ファイルなどを記憶する。本実施例におけるSVG形式の文書ファイル(以下、単に「SVG文書」と呼ぶ。)の生成・保存サービスを実現するプログラムは、クラウドサーバ102のハードディスク203に記憶されており、RAM202に読み出されCPU201によって実行される。ディスプレイコントローラ204は、不図示のディスプレイ表示制御を行う。ネットワークコントローラ205は、ネットワークに接続された他の機器との通信制御を行う。

0013

図3は、クラウドシステム100を実現するソフトウェアの構成例を示す図である。クライアント装置103は、Webページを閲覧するためのWebブラウザ301と、帳票などの元データを作成・編集するための文書編集アプリケーション(以下、「文書編集アプリ」と呼ぶ。)302とを備える。ユーザは、Webブラウザ301を用いてクラウドサーバ102にアクセスする。そして、SVG文書の生成指示(文書編集アプリ302で作成した元データのアップロード)や、自身のクライアント装置103にSVG文書を表示させる指示(保存されたSVG文書のダウンロード)を、クラウドサーバ102に対して行う。

0014

クラウドサーバ102は、Webサービス311によって、Webブラウザ301と通信し、クライアント装置103からの要求、すなわち、SVG文書の生成や表示といったユーザ指示を処理する。例えばSVG文書の生成が要求された場合、クラウドサーバ102は、当該要求に対応する元データを、SVG形式でのファイル化を指示するジョブ(以下、単に「ジョブ」と呼ぶ。)と共に、ファイル生成サービス312へと渡す。ファイル生成サービス312は、受け取った元データとジョブに基づいてSVG文書を生成する。生成されたSVG文書は、データストレージ313にそのジョブと共に格納される。また、クライアント装置103からの要求がSVG文書の表示(取得)であれば、指定されたSVG文書がデータストレージ313からWebサービス312を介して読み出され、クライアント装置103に送られる。クライアント装置103では、Webブラウザ301を介して受け取ったSVG文書に基づき各ページをその画面上に表示する。ユーザは、自身のクライアント装置103に表示されたページを編集し、編集後の内容で新たなSVG文書の生成をWebブラウザ301を介して再び指示して、再保存させることができる。

0015

<ファイル生成サービス>
次に、本実施例の特徴である、ファイル生成サービス312について詳しく説明する。ファイル生成サービス312は、クライアント装置103からの要求の多寡に応じてその起動数が変動する。つまり、要求が多いほどそれを処理するためにより多くのファイル生成サービス312が起動されることになる。図4は、ファイル生成サービス312の内部構成を示す図である。ファイル生成サービス312は、データ取得モジュール401、アクセス解析モジュール402、ファイル化モジュール403、ファイル保存モジュール404から構成されている。

0016

データ取得モジュール401は、クライアント装置103から送信された元データを、Webサービス311を介して取得するモジュールである。ここで、元データには、例えば帳票のフォームデータや、ユーザがクライアント装置103上で当該帳票のフォームデータに入力した氏名や住所等の情報が含まれる。また、元データの形式は文書編集アプリ302に依存したもの(例えばword等)で構わない。ファイル化モジュール403が処理可能な形式と元データの形式とが異なる場合は、データ取得モジュール401において、所定の中間データ(例えばPDF)に変換するような構成であってもよい。アクセス解析モジュール402は、データストレージ313に対するアクセス状況を解析し、インライン方式でSVG文書を生成する場合におけるリソースの条件を決定するモジュールである。ファイル化モジュール403は、元データからリソースを取得して、インライン方式又は外部参照方式を適用してSVG文書を生成する処理(ファイル化処理)を行うモジュールである。ファイル化処理の詳細は後述する。ファイル保存モジュール404は、生成されたSVG文書を、データストレージ313に保存する処理を行うモジュールである。

0017

<外部参照方式とインライン方式>
ここで、SVG文書のファイル構成について確認しておく。図5はSVG文書のファイル構成の一例を示す図であり、(a)は外部参照方式の場合、(b)はインライン方式の場合を示している。図5の(a)及び(b)において、矩形は1つのファイルを表しており、1つ1つの矩形が何らかの情報を表している。また、矩形同士を結ぶ線はファイル間参照関係があることを表している。

0018

はじめに、インライン方式と外部参照方式との共通点について説明する。図5の(a)及び(b)から明らかなように、いずれの方式においても、ツリー構造のルートがHTMLファイル501又は511となっている。HTMLファイルは、SVG文書をクライアント装置103のWebブラウザ301で表示するために必要なファイルである。そして、このHTMLファイル501又は511の下流にあるファイルが、SVGファイル502又は512である。ここで、SVGファイルは、拡張子が“.svg”のファイルであり、1ページに付き1つ存在する。

0019

続いて、外部参照方式のファイル構成について説明する。外部参照方式では、描画で使用するリソースがSVGファイル502の外に別のファイル(外部ファイル)503として存在する。そして、当該外部ファイル503がSVGファイル502から参照されるというファイル構成である。図5(a)では、スタイル情報を表す“css”、画像情報を表す“jpg”及び“png”、フォント情報を表す“ttf”が外部ファイルとして個別に存在し、SVGファイル502から参照されている。外部参照方式の特徴として、ファイル1個あたりのデータサイズが小さくなり、且つ、オブジェクト単位で表示が可能である点が挙げられる。その結果、クライアント装置103にページを表示する際に、読み込みが済んだオブジェクトから段階的に表示されるため、インライン方式と比較すると、ユーザが感じストレスが小さい。一方で合計ファイル数が多くなるため、データストレージ313へのファイルの書き込みや読み出しといったアクセス負荷が高くなってしまう。

0020

次に、インライン方式のファイル構成について説明する。インライン方式では、描画で使用するリソースがSVGファイルの中に含まれている構成である。図5(b)では、図5(a)で外部参照されていたスタイル情報、画像情報、フォント情報がSVGファイル512内に記述されている。インライン方式の特徴として、ファイル1個あたりのデータサイズが大きくなり、1ページを表示するのに全てのリソースを読み込む必要があるという点が挙げられる。そのため、外部参照方式よりも1ページの表示に時間が掛かる。一方、同一内容のデータで比較するとファイル数が外部参照方式より少なくて済むため、データストレージ313へのアクセス負荷は外部参照方式よりも小さくなる。

0021

上述の通り、外部参照方式とインライン方式にはそれぞれに長所と短所があり、両者はトレードオフの関係にある。本実施例に係る発明は、双方の長所を極力生かすために最適な構成でファイル化処理を行うことを目的としている。

0022

続いて、ファイル化モジュール403で生成されたSVG文書が、データストレージ313にどのように格納・管理されるかについて説明する。図6は、データストレージ313がSVG文書を格納する際のデータ構造の一例を示す図である。図6に示すように、生成されたSVG文書は、「ジョブID」601、「ファイル名」602、「URL」603、「アクセス済フラグ」604の4つの項目で管理される。

0023

「ジョブID」601は、ファイル化モジュール403におけるファイル化処理を一意識別するための識別子である。データストレージ313に保存されている複数のレコードのうち、「ジョブID」601が同一のものは同じファイル化処理で生成されたファイルである。

0024

「ファイル名」602は、ファイル化処理で生成されたSVG文書の名称を表す。「ジョブID」601が同じレコード内に「ファイル名」602が同じファイルは存在しないが、「ジョブID」601が異なる場合は「ファイル名」602が同じファイルが存在する場合がある。

0025

「URL」603は、各ファイルが格納されている位置を表すパスである。この「URL」603は各ファイルで一意である。また、「URL」603によりファイル間の階層関係が表される。Webブラウザ301はこのURLにアクセスすることでSVG文書を表示することができる。

0026

「アクセス済フラグ」604は、各ファイルがクライアント装置103のWebブラウザ301によって既にアクセスされたか否かを表すフラグである。本実施例では、“TRUE”が設定されていればアクセス済みを表し、“FALSE”が設定されていれば未だアクセスされていないことを表す。図6の例では、「ジョブID」601が“1”のジョブに属するファイルはアクセス済みであり、“2”のジョブに属するファイルは未アクセスということになる。ここで、「アクセス済フラグ」604に“TRUE”が設定されているということは、生成・保存されたSVG文書がクライアント装置103上に表示されたことを意味する。クライアント装置103に表示されたSVG文書のページ内容をユーザが編集し、その都度、新たなSVG文書の生成・保存を行うようなユースケースでは、同じファイルに再びアクセスされることはない。したがって、このようなユースケースにおいて、「アクセス済フラグ」604に“FALSE”が設定されている場合は、これから編集のためにアクセスされる可能性の高いSVG文書の構成ファイルであることがわかる。したがって、「アクセス済フラグ」604は、データストレージ313へのアクセスが同時期にどの程度発生し得るか(同時アクセスが一定数以上見込まれるかどうか)を推し量る指標となり得る。

0027

次に、ファイル生成サービス312における、元データからSVG文書を生成し保存するファイル化処理について説明する。図7は、本実施例に係る、ファイル化処理の流れを示すフローチャートである。

0028

テップ701では、データ取得モジュール401が、クライント端末103から送られた元データを取得する。

0029

ステップ702では、アクセス解析モジュール402が、データストレージ313に対するアクセス状況を解析する。具体的には、前述の「アクセス済フラグ」604及び「ジョブID」601を参照し、“FALSE”が設定されているファイルを有するジョブの数を取得し、当該取得したジョブ数と予め定めた閾値とを比較して、アクセス状況をレベル分け(例えば3段階に分類)する。上述の通り“FALSE”が設定されているファイルは未だクライアント装置103上で表示されていないため、今後表示を行うためにファイルアクセスが発生する可能性が高い。よって、“FALSE”が設定されているファイルを有するジョブの数が多いときは、多くのファイルアクセス数が同じタイミングで発生する可能性が高いことを意味する。ここで、アクセス状況を例えば「多」「中」「少」の3段階に分類するとする。この場合、例えばジョブ数が50以上は「多」、25未満は「少」、その間は「中」といった具合に2つの閾値を用意しておけばよい。仮に「多」と「少」の2段階に分類する場合であれば閾値は1つで済むことになる。もちろん、分類数をもっと多くしても構わない。さらには、ジョブ数に代えて、端的に“FALSE”が設定されているファイル数に基づいてアクセス状況を判定してもよい。この場合の閾値は、入力される元データにも拠るがジョブ数の10倍から100倍程度の値とすればよい。

0030

ステップ703では、アクセス解析モジュール402が、アクセス状況の解析結果に基づき、インライン方式を適用する場合のリソースの条件を決定する。ここでは、データサイズを条件とする場合について説明する。この場合、アクセス状況の解析結果に応じたデータサイズの閾値が決定される。例えば、アクセス状況が「多」であった場合は600KB、「中」であった場合は250KB、「少」であった場合は30KBといった具合である。データサイズの閾値が大きくなるほどインライン方式のファイル構成となるリソースが増え、その結果、SVG文書の総ファイル数が減ることになる。

0031

ステップ704では、ファイル化モジュール403が、元データに含まれるヘッダ情報等を解析し、元データ内のすべてのリソースを取得する。

0032

ステップ705では、ファイル化モジュール403が、注目するページを決定する。通常は、1ページ目が最初の注目ページに決定される。

0033

ステップ706では、ファイル化モジュール403が、注目ページについてのリソースの中から注目するリソースを決定する。

0034

ステップ707では、ファイル化モジュール403が、注目リソースがステップ703で決定した条件を満たすか否かを判定する。ここでは、注目リソースのデータサイズと、アクセス状況に応じて決定された閾値とが比較される。判定の結果、注目リソースのデータサイズが閾値以下であれば、ステップ708に進む。一方、注目リソースのデータサイズが閾値を越える場合は、ステップ709に進む。

0035

ステップ708では、ファイル化モジュール403が、注目リソースに対しインライン方式を適用してファイル化する。すなわち、注目リソースをSVGファイル内に埋め込む。

0036

ステップ709では、ファイル化モジュール403が、注目リソースに対し外部参照方式を適用してファイル化する。すなわち、注目リソースをSVGファイルとは別の外部ファイルとして構成する。

0037

ステップ710では、注目ページについての全リソースについて処理が完了したか否かが判定される。未処理のリソースがあればステップ706に戻って次の注目リソースを決定して処理を続行する。一方、注目ページについての全リソースについて処理が完了していれば、ステップ711に進む。

0038

ステップ711では、元データの全ページについて処理が完了したか否かが判定される。未処理のページがあればステップ705に戻って次の注目ページを決定して処理を続行する。一方、元データの全ページについて処理が完了していれば、ステップ712に進む。

0039

ステップ712では、ファイル保存モジュール404が、出来上がったSVG文書をデータストレージ313に格納する。図8は、本実施例に係る、同一の元データから生成される3種類のSVG文書のファイル構成を説明する図である。図8(a)は、SVG文書生成前の元データの構成を示す図である。図8(a)の元データは2ページで構成され、1ページ目は500KBと100KBの画像情報(jpg1及びjpg2)と50KBのフォント情報(ttf1)の計3つのリソースが含まれている。また、2ページ目には300KBと100KBの画像情報(png1及びpng2)と200KBのフォント情報(ttf2)の3つのリソースが含まれている。このような元データからアクセス状況の解析結果に応じて、図8(b)〜(d)に示す3種類のSVG文書が生成される。図8(b)は、アクセス状況「少」の下でデータサイズ閾値「30KB」の場合に生成されるSVG文書であり、30KB以下のリソースがインライン方式でファイル化される。図8(a)の元データには30KB以下のデータは存在しないため、全てのリソースが外部参照方式でファイル化されている。図8(c)は、アクセス状況「中」の下でデータサイズ閾値「250KB」の場合に生成されるSVG文書であり、250KB以下のリソースがインライン方式でファイル化される。この場合は、1ページ目のjpg1の画像情報と2ページ目のpng1の画像情報のみ外部参照方式でファイル化され、その他のリソースはインライン方式でファイル化されている。図8(d)は、アクセス状況「多」の下でデータサイズ閾値「600KB」の場合に生成されるSVG文書であり、600KB以下のリソースがインライン方式でファイル化される。いま、元データの全てのリソースが600KB以下のサイズであるため、全てのリソースがインライン方式でファイル化されることになる。ここで、図8(b)〜(d)のファイル数を比べてみると、それぞれ9個、5個、3個である。すなわち、データストレージ313へのアクセスが少ない状況ではファイル数は多くても構わないため、外部参照方式が適用されやすくなっている。一方、アクセスが多い状況ではファイル数を少なくしてアクセスされるファイル数が増えないように、インライン方式が適用されやすくなっている。

0040

以上が、本実施例におけるファイル化処理の内容である。

0041

<変形例>
上述の例では、同一内容のリソースが複数存在した場合に、それぞれが別個独立に扱われる結果、別々の外部ファイルとして構成され得た。そこで、同一内容のリソースが複数存在する場合に、リソースの共有を行ってより効率的なファイル構成を実現する態様を変形例として説明する。

0042

本変形例では、上述のステップ704で元データ内のすべてのリソースを取得した段階で同一内容のリソースの有無を判定し、同一内容のリソースがあれば、共有リソースとして1個のリソースに整理・統合する。ステップ705以降の処理は、上述の通りであるので説明を省く。

0043

図9は、本変形例によって生成される、SVG文書のファイル構成を説明する図である。図9(a)は、SVG文書生成前の元データの構成を示す図である。図9(a)の元データは2ページで構成され、1ページ目は500KBと100KBの画像情報(jpg1及びjpg2)と50KBのフォント情報(ttf1)の計3つのリソースが含まれている。2ページ目は1ページ目と同じ500KBの画像情報(jpg1)と100KBの画像情報(png1)と200KBのフォント情報(ttf2)の3つのリソースが含まれている。このように、1ページ目のjpg1の画像情報と2ページ目のjpg1の画像情報とが同一内容のリソースである。この元データから生成されるSVG文書の一例が図9の(b)と(c)に示されている。なお、インライン方式を適用するリソースのデータサイズの閾値はいずれも250KBであるものとする。

0044

そして、図9(b)が上述の実施例によって生成されるSVG文書のファイル構成であり、図9(c)が本変形例によって生成されるSVG文書のファイル構成を示している。図9(b)では各ページのSVGファイルから参照されているjpg1が別々の外部ファイルであるのに対し、図9(c)では1つのjpg1の外部ファイルが共有参照されていることがわかる。その結果、図9(c)のSVG文書ではファイル数が4個になり、ファイル数を削減することができている。ここでは説明の便宜上、最も単純な例を説明したためファイル数の削減効果が大きくないが、同一内容のリソースが3個以上あったり、複数種類複数ページで存在する場合は効果が大きくなる。また、ここでは共有リソースが外部参照方式による別ファイルとなる場合について説明したが、インライン方式の場合であっても同一ページ内であれば共有は可能である。この場合、ファイル数に変更はないためファイル数の抑制には寄与しないがファイルサイズが小さくなるため、システム上の処理負荷が軽減される。

0045

なお、本実施例では、アクセス状況を判定する際の基準に未表示のジョブ数(或いはファイル数)といったアクセス履歴を用いたが、これに限定されない。例えば、クラウドサーバ102上で起動しているファイル生成サービス312の数を指標としてもよい。あるいは、データストレージ313への単位時間あたりのアクセス数を指標としても構わない。すなわち、データストレージ313にどれだけのアクセスが同時に発生し得るかを判断できるものであればどのような指標でもよい。

0046

また、インライン方式を適用する場合の条件としてリソースのデータサイズを用いたが、例えばリソース数を条件とし、一定のリソース数以下であればSVGファイル内に記述するようにしてもよい。この手法によっても、SVG文書のファイル数を抑制することができる。

0047

以上のとおり本実施例によれば、インライン方式を適用する際のリソースの条件がデータストレージへのアクセス状況に応じて決定される。これにより、クラウドシステム上で生成する文書ファイルの構成を動的に変更することができ、ファイル数の抑制と表示パフォーマンスの維持というトレードオフの関係にある両者のバランスを最適に保つことが可能になる。

0048

実施例1において、図8(b)のようなファイル構成は、保存されている文書ファイルに対する同時多数のアクセスが見込まれない場合に生成されるため、データストレージ313のアクセス制限が発生する可能性は低い。しかしながら、元データのページ数やリソース数によっては想定以上のファイル数でSVG文書が構成されてしまう可能性がある。そこで、保存されている文書ファイルに対する同時多数のアクセスが見込まれない場合において、先頭ページのみを外部参照方式でファイル化する態様について、実施例2として説明する。なお、実施例1と共通する部分は説明を省略ないしは簡略化し、本実施例では差異点を中心に説明するものとする。

0049

図10は、本実施例に係る、ファイル化処理の流れを示すフローチャートである。ステップ1001〜ステップ1005は、実施例1に係る図7のフローのステップ701〜705と同じである。ステップ1005で注目ページが決定されると、ステップ1006において、ファイル化モジュール403が、当該注目ページが先頭ページであるかどうかを判定する。注目ページが先頭ページであれば、ステップ1007に進む。一方、注目ページが先頭ページ以外のページであれば、ステップ1008に進む。ステップ1007では、ステップ1002での判定の結果、多くのファイルアクセスが見込まれない状況であるかどうか(ここでは、アクセス状況が「少」であったかどうか)によって処理が切り分けられる。アクセス状況が「少」であった場合はステップ1013に進み、「少」でなかった場合はステップ1008に進む。

0050

ステップ1008〜ステップ1012は、図7のフローのステップ706〜ステップ710にそれぞれ相当する。すなわち、注目ページについて注目リソース毎にステップ1003で決定した条件を満たすかどうかが判定され、判定結果に応じてインライン方式又は外部参照方式による注目リソースのファイル化処理がなされる。

0051

ステップ1013では、ファイル化モジュール403が、先頭ページ内のすべてのリソースについて、外部参照方式によるファイル化処理を行う。先頭ページについてのファイル化処理が完了すると、ステップ1014に進む。

0052

ステップ1014及びステップ1015は、図7フローのステップ711及びステップ712に相当する。すなわち、元データの全ページについて処理が完了するまでステップ1005以下の処理が繰り返され、出来上がったSVG文書がデータストレージ313に格納される。

0053

図11は、本実施例によって生成される、SVG文書のファイル構成を説明する図である。図11(a)は、SVG文書生成前の元データの構成を示す図である。図11(a)の元データは2ページで構成され、1ページ目は500KBと100KBの画像情報(jpg1及びjpg2)と50KBのフォント情報(ttf1)の計3つのリソースが含まれている。2ページ目は300KBと100KBの画像情報(png1及びpng2)と200KBのフォント情報(ttf2)の3つのリソースが含まれている。この元データから生成されるSVG文書の一例が図11の(b)と(c)に示されている。なお、インライン方式を適用するリソースのデータサイズの閾値はいずれも30KBであるものとする。

0054

そして、図11(b)が実施例1によって生成されるSVG文書のファイル構成であり、図11(c)が本実施例によって生成されるSVG文書のファイル構成を示している。図11(b)では1ページ目と2ページ目ともにすべてのリソースが外部参照方式でファイル化されている。これに対し、図11(c)では先頭ページのみリソースが外部参照方式でファイル化され、2ページ目はインライン方式でSVGファイル内に記述されている。また、図11(b)と(c)とでファイル数を比較してみると、それぞれ9個と6個であり、本実施例を適用した方がよりファイル数を削減することができている。そして、先頭ページ内のリソース数が多いほどその効果は大きくなる。

0055

本実施例によれば、アクセス状況が多くないと判定された場合に先頭ページのみを外部参照方式でファイル化し、先頭ページ以外のページについてはインライン方式でファイル化する。このような制御を行うことで、先頭ページについては表示パフォーマンスの良好なファイル構成となり、迅速に表示させることができる。こうすることで、ユーザが先頭ページを閲覧している間に2ページ目以降の描画データの読み込みができるため、ユーザの感じるストレスが軽減される。また、トータルのファイル数が減るため、ファイルアクセス負荷をさらに抑制することができる。

0056

次に、元データの各ページに含まれる画像リソースについて、スプライト画像を作成する態様について実施例3として説明する。ここで、スプライト画像とは、複数の画像を連結して1つにまとめた画像である。このスプライト画像に対しCSS表示範囲を指定することによって個々の画像を表示する手法が「CSSスプライト」であり、本実施例はこれを利用するものである。なお、実施例1と共通する部分は説明を省略ないしは簡略化し、本実施例では差異点を中心に説明するものとする。

0057

図12は、本実施例に係る、ファイル化処理の流れを示すフローチャートである。ステップ1201〜ステップ1204は、実施例1に係る図7のフローのステップ701〜704と同じである。ステップ1204で元データからすべてのリソースが取得されると、ステップ1205において、ファイル化モジュール403が、取得されたリソース内に同一種類の画像情報が複数あるかどうかを判定する。この場合において、同一種類とは画像形式が同じであることを意味し、例えばjpgとpngとは異なる画像形式であるため同一種類ではない。同一種類の画像情報が複数あれば、ステップ1206に進む。一方、同一種類の画像情報が複数なければ、ステップ1207に進む。

0058

ステップ1206では、ステップ1204で取得したリソースのうち複数の画像情報に関し、上述のスプライト画像を作成する。作成されたスプライト画像のデータは、以降のステップにおいて1つのリソースとして扱われる。

0059

ステップ1207及びステップ1208は、図7のフローのステップ705及び706に相当し、注目ページと注目リソースがそれぞれ決定される。そして、ステップ1209では、注目リソースが上述のスプライト画像であるかどうかによって処理が切り分けられる。注目リソースがスプライト画像でなければステップ1210に進み、スプライト画像であればステップ1212に進む。

0060

ステップ1210〜ステップ1215は、図7のフローのステップ707〜ステップ710にそれぞれ相当する。すなわち、注目ページについて注目リソース毎にステップ1203で決定した条件を満たすかどうかが判定され、判定結果に応じてインライン方式又は外部参照方式による注目リソースのファイル化処理がなされる。この場合において、スプライト画像については外部参照方式が適用され、外部ファイルとして構成されることになる。そして、元データの全ページについて処理が完了するまで処理が続行され、出来上がったSVG文書がデータストレージ313に格納される。

0061

図13は、本実施例によって生成される、SVG文書のファイル構成を説明する図である。図13(a)は、SVG文書生成前の元データの構成を示す図である。図13(a)の元データは2ページで構成され、1ページ目は500KBと100KBの画像情報(jpg1及びjpg2)と50KBのフォント情報(ttf1)の計3つのリソースが含まれている。2ページ目は300KBと100KBの画像情報(jpg3及びjpg4)と200KBのフォント情報(ttf2)の3つのリソースが含まれている。つまり、1ページ目と2ページ目を合わせて同一種類の画像情報が4個存在している。そして、図13(b)がこの元データから実施例1によって生成されるSVG文書のファイル構成であり、図13(c)が本実施例によって生成されるSVG文書のファイル構成を示している。図13(b)では各画像情報が別々の外部ファイルとして構成されているのに対し、図13(c)では4つの画像情報を結合した1個のスプライト画像ファイルが共有参照されている。そして、図13(b)と(c)とでファイル数を比較してみると、それぞれ7個と4個であり、ファイル数を大きく削減することができている。

0062

本実施例によれば、元データ内に同一種類の画像リソースが含まれる場合に1個のスプライト画像にまとめられるので、同一種類の画像リソースが多いほどファイル数削減の効果が大きい。したがって、元データの構成によっては、トータルのファイル数をより大きく減らせることができ、ファイルアクセス負荷をさらに抑制することができる。

0063

以上、3つの実施形態に分けて説明を行ったが、各実施例はそれぞれが独立しているものではなく、各実施例の内容を組み合わせることも可能である。例えば、実施例1の変形例と実施例2とを組み合わせて、リソースの共有を行うとともに先頭ページのみインライン方式を適用するといったことも可能である。

0064

また上述の各実施例では、SVG形式の文書ファイルを生成する場合を例に説明を行ったが、これに限定されない。さらに、SVGと同様にXMLをベースとしたJDF(Job Definition Format)など、SVG類似の構造を持つフォーマットの文書ファイルの生成に幅広く適用可能である。

実施例

0065

(その他の実施例)
本発明は、上述の実施例の1以上の機能を実現するプログラムを、ネットワーク又は記憶媒体を介してシステム又は装置に供給し、そのシステム又は装置のコンピュータにおける1つ以上のプロセッサがプログラムを読出し実行する処理でも実現可能である。また、1以上の機能を実現する回路(例えば、ASIC)によっても実現可能である。

ページトップへ

この技術を出願した法人

この技術を発明した人物

ページトップへ

関連する挑戦したい社会課題

関連する公募課題

ページトップへ

技術視点だけで見ていませんか?

この技術の活用可能性がある分野

分野別動向を把握したい方- 事業化視点で見る -

ページトップへ

おススメ サービス

おススメ astavisionコンテンツ

新着 最近 公開された関連が強い技術

  • 富士ゼロックス株式会社の「 データ管理システム」が 公開されました。( 2020/09/24)

    【課題】階層構造になっている管理システムにおいて、管理対象データの実体を最上位の装置が全て管理する場合と比較して、管理対象データがユーザの意図しない装置に提供されないシステムを提供する。【解決手段】管... 詳細

  • 株式会社ウフルの「 デバイス管理システム、デバイス管理方法、情報処理装置、及びプログラム」が 公開されました。( 2020/09/24)

    【課題】デバイスの信頼性を向上可能なデバイス管理システム、デバイス管理方法、情報処理装置、デバイス及びプログラムを提供する。【解決手段】デバイス管理システム1は、複数の情報処理装置2をネットワーク3で... 詳細

  • 本田技研工業株式会社の「 サーバ」が 公開されました。( 2020/09/24)

    【課題】車両の利用者が、該利用者の生活圏外の人であって前記利用者の属性に類似した属性を持つ地域人(地元民)が利用したPOI情報をリコメンドとして受けることができるサーバを提供する。【解決手段】サーバ1... 詳細

この 技術と関連性が強い人物

関連性が強い人物一覧

この 技術と関連する社会課題

関連する挑戦したい社会課題一覧

この 技術と関連する公募課題

関連する公募課題一覧

astavision 新着記事

サイト情報について

本サービスは、国が公開している情報(公開特許公報、特許整理標準化データ等)を元に構成されています。出典元のデータには一部間違いやノイズがあり、情報の正確さについては保証致しかねます。また一時的に、各データの収録範囲や更新周期によって、一部の情報が正しく表示されないことがございます。当サイトの情報を元にした諸問題、不利益等について当方は何ら責任を負いかねることを予めご承知おきのほど宜しくお願い申し上げます。

主たる情報の出典

特許情報…特許整理標準化データ(XML編)、公開特許公報、特許公報、審決公報、Patent Map Guidance System データ