JP2018063501A - 情報処理装置及び文書表示方法、文書表示システムおよびプログラム - Google Patents

Abstract

【課題】フォントファイルや画像ファイル、スタイルファイルなど複数のファイルを含むＷｅｂ文書をＷｅｂブラウザーで表示する場合、ダウンロード時間により、表示されるまでに時間を要する。【解決手段】複数ファイルで構成されるＷｅｂ文書をＺｉｐ化し、Ｗｅｂブラウザーで取得したＺｉｐ化したＷｅｂ文書を展開して、各ファイルへのリンクを含む最上層のファイルをブラウザーに返すと共に、リンクされたファイルをキャッシュする。Ｗｅｂブラウザーから各ファイルへのアクセスがあると、それをスクリプトによりフックしてキャッシュしたファイルをブラウザーに返す。ブラウザーはそのファイルを基に文書を表示する。【選択図】図９

Description

本発明は情報処理装置及び文書表示方法、文書表示システムおよびプログラムに関し、特にＷｅｂブラウザーでの複数ファイルからなるＷｅｂ文書を表示する情報処理装置及び文書表示方法、文書表示システムおよびプログラムに関する。

近年、サーバーをインターネットに公開しクライアントにサービスを提供するクラウドサービスの形態が注目を集めている。クラウドサービスは、多くのコンピューティング・リソースを用いてデータ変換やデータ処理を分散実行し、多くのクライアントからの要求を分散並列処理により並行して処理することが主な特徴である。現在、このクラウドサービスを実現するクラウドサービス環境上にＷｅｂサービスを実装し、多種多様なサービスを提供するベンダーが乱立しつつある。ＷｅｂブラウザーやモバイルアプリケーションなどのクライアントはそれらのＷｅｂ上に公開されているＷｅｂサービスを有効活用し新しい機能を作成することで開発スピードや開発コストの面で優位になる。さらにサーバーマシンやネットワーク機器などのハードウェアを保持し継続的にメンテナンスする必要がなく運用面でもクラウドサービスは優位である。

従来から数多く運用されている社内のオンプレミスシステムについても優位性を鑑みてクラウドサービスへ移行するケースが多く出てきている。銀行や保険会社などで多く利用される帳票システム（テンプレートに顧客データを当てはめて帳票を作成するシステム）においても従来はオンプレミスで運用されていたがクラウドサービスへ移行しＷｅｂ上で帳票を表示することが検討されている。

銀行や保険会社の帳票の主な利用ユースケースはセールスマンが顧客に帳票を提示しながら商品説明し契約を行うものである。そのため帳票生成は美しくデザインされ表示内容は詳細に設計が行われ、フォントや画像、グラフなどが多く利用された表現力豊かな複雑なものになる。このような複雑な帳票は画像ファイルやフォントファイル、スタイルファイルなどの多くのファイルから構成される。帳票をＷｅｂブラウザーで表示するためにこれらのファイルをクラウドサービスからダウンロードする必要がある。しかし多くのＷｅｂブラウザーは同時に６ファイルしか並行にダウンロードすることができないため、ファイル数が多くなると全ての帳票ファイルをダウンロードするのに時間がかかってしまい、なかなか帳票が表示されず待たされることになってしまう。

特許文献１ではＨＴＭＬ（ＨｙｐｅｒＴｅｘｔ Ｍａｒｋｕｐ Ｌａｎｇｕａｇｅ）ファイルを独自に１つのファイルに結合して、クライアントサイドのヘルパーアプリケーションが、ダウンロードした結合されたファイルを復元して表示することでファイルのダウンロード遅延を防ぐ方法が開示されている。

特開２００１−２２６３１号公報

従来技術ではＨＴＭＬファイルを独自に１つのファイルに結合してダウンロードし、クライアントサイドのヘルパーアプリケーションが結合されたファイルを復元して表示することでファイルのダウンロード遅延を防ぐことができる。しかしながら、ほとんどのタブレット端末ではヘルパーアプリケーションとＷｅｂブラウザーとを連携させることが難しい。またタブレット端末の種類は多岐にわたるためヘルパーアプリケーションの開発にコストがかかってしまう課題があった。

本発明は上記従来例に鑑みて成されたもので、帳票を構成する複数ファイルを結合して単一のファイルにし、Ｗｅｂブラウザーで取得したファイルを展開して表示することで、帳票を表示する遅延を小さくすることを目的とする。

上記目的を達成するために本発明は以下の構成を有する。すなわち、複数のファイルで階層的に構成された文書データをアーカイブして単一のファイルとして保存するサーバーに接続される情報処理装置であって、
アーカイブされた前記文書データを前記サーバーからダウンロードし、展開し、前記文書データの下位の階層を構成するファイルを格納手段に保存するダウンロード手段と、
前記文書データの上位の階層のファイルに記載された、前記下位の階層を構成するファイルのアクセス先にアクセスするブラウザー手段と、
前記アクセスをフックして前記下位の階層を構成するファイルを読み出し、前記サーバーに代わり前記ブラウザー手段に返す読み出し手段とを有し、
前記ブラウザー手段は、読み出した前記ファイルに基づいて前記文書データを表示することを特徴とする。

帳票を構成する複数ファイルを結合し、Ｗｅｂブラウザーで取得した、結合したファイルを展開し表示することで、Ｗｅｂブラウザーからサーバーへのリクエスト数を大幅に少なくすることができ、効率的に帳票を表示することができる。

システム構成図 モバイル端末のハードウェア構成図 各サーバーのハードウェア構成図 帳票サーバーで管理するテーブル構造を示す図 データ変換サーバーで管理するテーブル構造を示す図 ストレージサーバーで管理するテーブル構造を示す図 モバイル端末の画面例を示す図 帳票ＳＶＧプレビューフローを示す図 帳票ＳＶＧのＺｉｐ構造を示す図 帳票ＳＶＧのキャッシュ情報を示す図 Ｚｉｐ化した帳票ＳＶＧ表示フローを示す図 キャッシュ情報の定期削除フローを示す図

以下、本発明を実施するための形態について図面を用いて説明する。
［実施例１］
＜システム構成＞
図１は、本発明の実施形態に係る帳票システムの全体構成を示す図である。この帳票システムは、本実施形態では文書表示を目的としていることから、文書表示システムと呼ぶこともできる。図１において、モバイル端末１０２はローカルネットワーク１０１を介して複数台接続されていることを想定している。モバイル端末１０２は、ローカルネットワーク１０１を介してインターネットワーク１００にアクセスし、サーバー１０５〜１０８にアクセスすることができる。モバイル端末１０２は有線または無線ＬＡＮを介してネットワークに接続する。本実施例では、モバイル端末１０２は無線ＬＡＮターミナル１０３を介してネットワークに接続することを想定しているが、携帯データ通信キャリアが提供する無線ネットワークを介して接続する場合も当然想定される。無線ＬＡＮターミナル１０３は、一般的なネットワーク・ルーター機能を有した無線ＬＡＮの親機であり、家庭内や事務所などの中で無線ＬＡＮを提供している。

業務サーバー１０４はユーザー業務情報を管理するサーバーである。本実施例では販売する製品を業務サーバー１０４で顧客毎に管理し、販売員が業務サーバー１０４の情報を用いて顧客に対して営業を行うユースケースを想定している。業務サーバー１０４はモバイル端末１０２からのリクエスト（要求）に応じてユーザー業務情報を表示・編集するための画面を提供する。認可サーバー１０５はＯＡｕｔｈを実現するためのサーバーでありユーザー情報やクライアント情報の管理や認可トークンの発行・管理を行う。サーバー１０５〜１０８は認可サーバー１０５のセキュリティドメインに属する。サーバー１０５〜１０８の各々へのリクエストには認可サーバー１０５で発行された認可トークンが必要であり、サーバー１０５〜１０８はそれぞれ認可サーバー１０５によってリクエストに含まれる認可トークンの有効性をチェックし許可された場合にのみリクエストを処理する。認可トークンの有効性チェックには有効期限チェックやライセンスチェックなどがある。

帳票サーバー１０６は業務サーバー１０４からユーザー業務情報を受け取り、帳票テンプレートにユーザー業務情報を反映させて帳票ＰＤＦ（Ｐｏｒｔａｂｌｅ Ｄｏｃｕｍｅｎｔ Ｆｏｒｍａｔ）データ（帳票ＰＤＦとも呼ぶ）を生成し管理するサーバーである。そして帳票サーバー１０６はデータ変換サーバー１０７に生成した帳票ＰＤＦを帳票ＳＶＧ（Ｓｃａｌａｂｌｅ Ｖｅｃｔｏｒ Ｇｒａｐｈｉｃｓ）形式のデータ（帳票ＳＶＧあるいはＷｅｂ帳票データとも呼ぶ）に変換するリクエストを行う。データ変換サーバー１０７は、帳票サーバー１０６から帳票ＳＶＧ変換リクエストを受け付け、帳票ＰＤＦを帳票ＳＶＧにデータ変換し管理するサーバーである。ストレージサーバー１０８はファイル管理を行うサーバーであり、モバイル端末１０２や帳票サーバー１０６、データ変換サーバー１０７からのファイルアップロード／ダウンロードを受け付ける。帳票ＰＤＦデータは所定の処理単位で生成され、データ変換サーバー１０７はその処理単位で帳票ＰＤＦデータを帳票ＳＶＧデータに変換する。本例では処理単位は１ページである。これにより、帳票サーバー１０６による或る帳票に関する帳票ＰＤＦの生成処理と、データ変換サーバー１０７によるその帳票の帳票ＳＶＧの生成処理とを、互いに並列に実行することができる。

具体的には、指定された帳票及びユーザーに基づいて、プレビュー生成リクエストを受けた帳票サーバー１０６が処理単位ごとに帳票ＰＤＦを生成し、それをストレージサーバー１０８に格納してその格納先を示すＵＲＬを帳票インデックスファイルに記録する。帳票サーバー１０６はそれともに、データ変換サーバー１０７に対して、プレビュー生成リクエストの対象である帳票を指定して帳票ＳＶＧ生成リクエストを送る。帳票サーバー１０６は、帳票ＰＤＦの生成が完了したならその旨帳票インデックスファイルにマークする。一方帳票ＳＶＧ生成リクエストを受けたデータ変換サーバー１０７は指定された帳票の帳票インデックスファイルを例えば定期的に監視し、ＵＲＬが追加されていたなら追加されたＵＲＬを指定して帳票ＰＤＦを取得し、それを帳票ＳＶＧに変換する。そしてその帳票ＳＶＧをストレージサーバー１０８に格納し、その格納先を示すＵＲＬを変換インデックスファイルに記録する。この処理を、生成完了を示すマークを検出するまで繰り返す。変換が完了したなら変換インデックスファイルに変換済みである旨をマークする。帳票ＳＶＧにアクセスするユーザーは、変換インデックスファイルに含まれるＵＲＬにアクセスして帳票ＳＶＧを取得できる。なお帳票データは文書のひとつであり、文書データと呼ぶこともある。

ここで、サーバー１０５〜１０８はそれぞれ複数台のサーバーで冗長化されたクラウドサービスとしてインターネット上に公開されるが、本実施例では説明を簡略化するため、それぞれ１台構成としている。また業務サーバー１０４も複数台のサーバーで冗長化された構成をとることもできるが、本実施例では説明を簡略化するため１台構成としている。

＜モバイル端末１０２のハードウェア構成＞
図２ａはモバイル端末１０２のハードウェア構成図である。ハードウェアの各構成要素は、システムバス２０２に接続されている。ＲＯＭ２０４にはオペレーティングシステム及び、通話、データ通信を制御するアプリケーションプログラム（アプリケーションと呼ぶこともある）が格納されており、アプリケーションはＣＰＵ２０３で実行される。 データ通信を制御するアプリケーションとしては、ＭａｉｌソフトやＷｅｂブラウザーなどがある。ＲＡＭ２０５は、プログラムを実行するためのワークメモリエリアである。また、ＷｅｂブラウザーがＷｅｂサーバーから取得してきたＷｅｂページデータやＷｅｂサービスにアクセスするための認証情報などを一時記憶するためのメモリでもある。記憶装置２１０は不揮発性の記憶装置であり、モバイル端末の再起動後も保持しておく必要のある各種動作モード設定や、稼働ログなどが記憶される。

ＮｅｔｗｏｒｋＣｏｎｔｒｏｌｌｅｒ２０６は、無線ＬＡＮ通信部２１２、携帯キャリアの提供するネットワークに参加するための携帯電話データ通信部２１３の通信制御を行う。一般的に無線ＬＡＮのネットワークに参加できるとき、ＮｅｔｗｏｒｋＣｏｎｔｒｏｌｌｅｒ２０６は、無線ＬＡＮの接続を優先する。モバイル端末が無線ＬＡＮのネットワークエリアから外れた場合には、携帯キャリアが提供する無線通信ネットワークへ参加する。音声制御部２０７は、主に通話アプリケーションが起動しユーザーが電話をしているときに利用する。マイク・スピーカ２１４にて音声データの入出力を行い、音声制御部２０７は、その制御プログラムとの仲介を行っている。

表示制御部２０８は、モバイル端末のディスプレイ２１５にて出力する情報の制御を行っている。ディスプレイ２１５にはたとえばクラウドサービスからダウンロードしたＷｅｂ帳票などが表示される。入力制御部２０９は、モバイル端末のボタンやタッチパネル２１６にてユーザーが指示した情報の制御を行っている。これらの音声制御部２０７、表示制御部２０８、入力制御部２０９を利用して、モバイル端末上でのアプリケーションは、ネットワーク通信情報やモバイル端末のさまざまな情報をユーザーに提供する。位置検出制御部２１１は、ＧＰＳセンサー２１７からモバイル端末の位置情報を取得しＯＳに提供する。これらの制御は、ＣＰＵ２０３で動くＯＳにて制御される。

＜サーバーのハードウェア構成＞
図２ｂは、サーバー１０４〜１０８のハードウェア構成の一例を示す図である。特に断らない限り、本発明の機能が実行可能であるならば、単体の機器であっても、複数の機器からなるシステムであっても、本発明が適用できることは言うまでもない。また、特に断らない限り、本発明の機能が実行可能であるならば、ＬＡＮ、ＷＡＮ等のネットワークを介して接続が為され、処理が行われるシステムであっても本発明を適用できることは言うまでもない。本実施例ではシステムバス２１９により各構成要素が接続されているものとして説明する。

ＣＰＵ２２０は情報処理装置の制御装置であり、記憶装置２２６に格納されているアプリケーションプログラム、プリントドライバプログラム、オペレーティングシステムや本発明のモバイル印刷システムプログラムを実行する。また、ＣＰＵ２２０はＲＡＭ２２２にプログラム実行に必要な情報、ファイル等を一時的に格納する制御を行う。また、ＣＰＵ２２０はディスプレイ２２７上の不図示マウスカーソル等で指示されたコマンドに基づいて登録された種々のウインドウを開き、種々のデータ処理を実行する。ＲＯＭ２２１は不揮発の記憶手段であり、内部には基本Ｉ／Ｏプログラム等のプログラム、文書処理の際に使用するフォントデータ、テンプレート用データ等の各種データを記憶する。ＲＡＭ２２２は一時記憶手段であり、ＣＰＵ２２０の主メモリやワークエリア等として機能する。表示制御部２２４は、ディスプレイ２２７にて出力する情報の制御を行っている。入力制御部２２５は、キーボード２２８より入力される情報を制御し、情報処理装置は入力制御部２２５を介して外部装置とのデータのやり取りを行う。記憶装置２２６は外部記憶手段の一つで、大容量メモリとして機能し、アプリケーションプログラム、プリントドライバプログラム、ＯＳ等を格納している。キーボード２２８は指示入力手段であり、ユーザーが各サーバーへの指示等を入力指示するためのものである。ディスプレイ２２７は表示手段であり、キーボード２２８から入力したコマンド等を表示するものである。

＜モバイル端末１０２のＷｅｂブラウザーアプリケーション＞
モバイル端末１０２にはＷｅｂブラウザーアプリケーション９００（図９参照）がインストールされる。モバイル端末１０２にインストールされたＷｅｂブラウザーアプリケーションは図２で示した記憶装置２１０に記憶されており、前述したようにＣＰＵ２０３によってＲＡＭ２０５にロードされ実行される。

ユーザーはＷｅｂブラウザーアプリケーションがモバイル端末１０２のディスプレイ２１５に表示する画面を操作することにより、サーバー１０４〜１０８の各々にリクエストを行う。Ｗｅｂブラウザーアプリケーションは業務サーバー１０４や帳票サーバー１０６、ストレージサーバー１０８からのＨＴＭＬデータやＳＶＧデータを解析し、画面に表示したりできる。後述する図６はＷｅｂブラウザーアプリケーションがモバイル端末１０２のディスプレイ２１５に表示する画面の一例である。モバイル端末１０２にはＷｅｂブラウザーアプリケーション以外にも様々なアプリケーションをインストールすることができる。本実施例ではＷｅｂブラウザーアプリケーションのみを利用するため、以降の記載ではＷｅｂブラウザーアプリケーションをモバイル端末１０２として記載する。

＜帳票サーバー１０６が管理するデータ＞
図３（ａ）、（ｂ）は帳票サーバー１０６が外部メモリに記憶するデータテーブルである。これらのデータテーブルは、帳票サーバー１０６の外部メモリではなく、インターネット１００やローカルネットワーク１０１を介して通信可能に構成された別のサーバーに記憶するように構成することもできる。帳票サーバー１０６が保持するデータテーブルはテンプレート情報３００とプレビュー情報３１０とを含む。

図３（ａ）のテンプレート情報３００は帳票サーバー１０６が保持するテンプレートを管理する情報である。テンプレートＩＤ３０１はテンプレートを一意に識別する識別子であり、帳票サーバー１０６にテンプレートが登録された際に発行される。テナントＩＤ３０２はテンプレートを登録したテナントのテナントＩＤである。帳票サーバー１０６はテンプレートをテナントＩＤ３０２毎にアクセス制御する。テンプレートＵＲＬパス３０３はテンプレートが保存されているストレージサーバー１０８のＵＲＬパスである。帳票サーバー１０６はテンプレートＩＤ３０１を含むＵＲＬパスをストレージサーバー１０８に生成し、そこにテンプレートを保存する。したがって帳票サーバー１０６が指定されたテンプレートを使用する場合には、帳票サーバー１０６は指定されたテンプレートのテンプレートＩＤ３０１に対応するテンプレートＵＲＬ３０３にアクセスする。そしてそのテンプレートに含まれたフォームデータに、帳票をリクエストしたユーザーのフィールドデータを合成した帳票ＰＤＦデータを作成する。

図３（ｂ）のプレビュー情報３１０は帳票サーバー１０６がプレビュー処理を管理する情報である。プレビューＩＤ３１１は帳票サーバー１０６がプレビュー生成リクエストを受け付けた際に発行し登録する。テナントＩＤ３１２はプレビュー生成リクエストしたテナントのテナントＩＤである。ユーザーＩＤ３１３はプレビュー生成リクエストしたユーザーの識別子である。データ変換ＩＤ３１４は、帳票サーバー１０６がデータ変換サーバー１０７への帳票ＳＶＧ生成リクエストの応答で受信するデータ変換処理を識別する識別子である。帳票ＰＤＦＵＲＬパス３１５は帳票ＰＤＦが保存されているストレージサーバー１０８のＵＲＬパスである。帳票サーバー１０６はプレビューＩＤ３１１を含むＵＲＬパスをストレージサーバー１０８に生成し、そこに帳票ＰＤＦデータを保存する。

＜データ変換サーバー１０７が管理するデータ＞
図４（ａ）、（ｂ）はデータ変換サーバー１０７が外部メモリに記憶するデータテーブルである。データ変換サーバー１０７が保持するデータテーブルは、文書情報４００とデータ変換情報４１０とを含む。

図４（ａ）の文書情報４００はデータ変換サーバー１０７が帳票ＳＶＧ生成リクエスト受信時にレコード生成する。文書ＩＤ４０１は、データ変換サーバー１０７が帳票ＳＶＧ生成リクエストを受信した際に発行する文書を一意に識別する識別子である。テナントＩＤ４０２は帳票ＳＶＧ生成リクエストしたテナントのテナントＩＤである。ユーザーＩＤ４０３は帳票ＳＶＧ生成リクエストしたユーザーの識別子である。文書ＵＲＬ４０４は帳票ＰＤＦが保存されているストレージサーバー１０８のＵＲＬパスである。帳票サーバー１０６からの帳票ＳＶＧ生成リクエストのパラメータとしてデータ変換サーバー１０７に渡される。

図４（ｂ）のデータ変換情報４１０はデータ変換サーバー１０７が帳票ＳＶＧ生成リクエスト受信時にレコード生成する。データ変換ＩＤ４１１は、データ変換サーバー１０７が帳票ＳＶＧ生成リクエストを受信した際に発行するデータ変換処理を一意に識別する識別子である。テナントＩＤ４１２、ユーザーＩＤ４１３、文書ＩＤ４１４はデータ変換サーバー１０７がデータ変換リクエスト受信時に生成する文書情報４００のテナントＩＤ４０２、ユーザーＩＤ４０３と文書ＩＤ４０１と同じ値である。インデックスＵＲＬ４１５は、データ変換サーバー１０７が帳票ＰＤＦデータに基づいて生成する帳票ＳＶＧデータのＵＲＬリストである変換インデックスファイルを保存するストレージサーバー１０８のＵＲＬである。生成した帳票ＳＶＧデータが複数ページだった場合には、複数帳票ＳＶＧデータのストレージサーバー１０８上のＵＲＬがインデックスファイルに記載される。インデックスＵＲＬ４１５はデータ変換サーバー１０７が帳票ＳＶＧ生成完了時にストレージサーバー１０８で一意になるようＵＲＬパスにデータ変換ＩＤ４１１を含めて生成し保存する。

ステータス４１６はデータ変換サーバー１０７のデータ変換状況を示しており、データ変換サーバー１０７がデータ変換状況に応じて更新する。ステータス４１６には"待機中"や"変換済み"がある。

＜ストレージサーバー１０８のデータ＞
図５はストレージサーバー１０８が外部メモリに記憶するデータテーブルである。これらのデータテーブルは、ストレージサーバー１０８の外部メモリではなく、インターネット１００やローカルネットワーク１０１を介して通信可能に構成された別のサーバーに記憶するように構成することもできる。ストレージサーバー１０８が保持するデータテーブルはファイル情報５００より成る。

図５のファイル情報５００はストレージサーバー１０８に保存するファイルの情報である。データＵＲＬ５０１はストレージサーバー１０８に保存するファイルを一意に特定することができるＵＲＬである。ファイルパス５０２はストレージ上のファイルパスでありファイルの格納場所を示す。データＵＲＬ５０１に対してリクエストすることによりストレージのファイル操作を行うことができる。たとえば、データＵＲＬ５０１に対してＨＴＴＰ ＧＥＴメソッドをリクエストすると対応するファイルがダウンロードできる。データＵＲＬ５０１に対してＨＴＴＰ ＰＵＴメソッドにファイル添付してリクエストするとファイルをアップロードし保存できる。データＵＲＬ５０１に対してＨＴＴＰ ＤＥＬＥＴＥメソッドをリクエストすると対応するファイルを削除できる。

＜モバイル端末１０２の画面＞
図６（ａ）、（ｂ）はモバイル端末１０２に表示するＷｅｂブラウザーアプリケーションの画面例であり図２ａにおいて表示制御部２０８を介してディスプレイ２１５に表示されるものである。

図６（ａ）の商談画面６００はユーザー業務情報を表示する画面である。業務サーバー１０４はモバイル端末１０２から商談画面表示リクエストを受け付けると、ユーザー業務情報を含む商談画面６００を応答する。商談画面６００において帳票生成ボタン６０１が押下されると、業務サーバー１０４に帳票生成リクエストが行われる。図６（ｂ）のプレビュー画面６１０は帳票ＳＶＧを表示する画面であり帳票サーバー１０６が生成しモバイル端末１０２の画面に表示される。

＜帳票ＳＶＧプレビューフロー＞
図７は商談画面６００で帳票生成ボタン６０１が押下され、プレビュー画面６１０が表示されるまでの処理フローである。なお、帳票サーバー１０６やデータ変換サーバー１０７、ストレージサーバー１０８は認可サーバー１０５のセキュリティドメインに属しており、それぞれのサーバーへのリクエストには認可サーバー１０５で発行された認可トークンが必要である。帳票サーバー１０６やデータ変換サーバー１０７、ストレージサーバー１０８はリクエストで受け付けた認可トークンを認可サーバー１０５に有効性確認依頼し、認可トークンに紐づくユーザーＩＤやテナントＩＤなどのユーザー情報を取得する。図７における帳票サーバー１０６やデータ変換サーバー１０７、ストレージサーバー１０８が受け付けるリクエストは全て認可トークンが含まれるが本実施形態の発明と直接関連しない処理のため図示を省略している。

Ｓ７．１において商談画面９１０で帳票生成ボタン６０１が押下されるとモバイル端末１０２から業務サーバー１０４に帳票生成リクエストが行われる。帳票生成リクエストを受け付けた業務サーバー１０４は後述のＳ７．２、Ｓ７．３のステップを処理し、Ｓ７．４でモバイル端末１０２に応答する。

Ｓ７．２において業務サーバー１０４は帳票サーバー１０６にプレビュー生成リクエストを行う。業務サーバー１０４はＳ７．２のプレビュー生成リクエストでパラメータとして、テンプレートＩＤ４１１と商談画面９１０で指定する業務情報を指定する。

帳票サーバー１０６はＳ７．２のプレビュー生成リクエストを受け付けるとプレビューＩＤ３１１を発行し、テナントＩＤ３１２とユーザーＩＤ３１３にはプレビュー生成リクエストしたテナントＩＤとユーザーＩＤを指定しプレビュー情報３１０にレコード登録する。そして帳票サーバー１０６は発行したプレビューＩＤ３１１をＳ７．２のプレビュー生成リクエストの応答として業務サーバー１０４に返す。

Ｓ７．２−１において帳票サーバー１０６はＳ７．２のプレビュー生成リクエストのパラメータで受信したテンプレートＩＤと一致するテンプレートをテンプレート情報３００から特定し、特定したテンプレートのテンプレートＵＲＬパスからテンプレートファイルを取得する。そして帳票サーバー１０６はそのテンプレートファイルにＳ７．２のプレビュー生成リクエストのパラメータで受信した業務情報を反映させ帳票ＰＤＦを生成する。帳票サーバー１０６はプレビューＩＤ３１１からストレージサーバー１０８上のＵＲＬパスを生成し帳票ＰＤＦ ＵＲＬパス３１５に登録し、帳票ＰＤＦ ＵＲＬパス３１５に生成した帳票ＰＤＦをアップロードする。

Ｓ７．２−２において帳票サーバー１０６はデータ変換サーバー１０７に帳票ＳＶＧ生成リクエストを行う。帳票サーバー１０６は帳票ＳＶＧ生成リクエストのパラメータとして帳票ＰＤＦ ＵＲＬパス３１５を指定する。

データ変換サーバー１０７はＳ７．２−２の帳票ＳＶＧ生成リクエストを受信すると、文書ＩＤ４０１とデータ変換ＩＤ４１１を発行し文書情報４００とデータ変換情報４１０にレコード登録する。ここでテナントＩＤ４０２、４１２やユーザーＩＤ４０３、４１１には帳票ＳＶＧ生成リクエストしたテナントＩＤとユーザーＩＤを登録する。また文書ＵＲＬパス４０４にはＳ７．２−２の帳票ＳＶＧ生成リクエストのパラメータである帳票ＰＤＦ ＵＲＬパスを登録する。文書ＩＤ４１４には文書情報４００の文書ＩＤ４０１と同じものを登録する。そしてデータ変換サーバー１０７はＳ７．２−２の帳票ＳＶＧ生成リクエストの応答として発行したデータ変換ＩＤ４１１を帳票サーバー１０６に返す。Ｓ７．２−２の帳票ＳＶＧ生成リクエストの応答としてデータ変換ＩＤを受け取った帳票サーバー１０６はプレビュー情報３１０のデータ変換ＩＤ３１４として登録する。

Ｓ７．２−３においてデータ変換サーバー１０７は帳票ＰＤＦ ＵＲＬパス４０４から帳票ＰＤＦを取得し帳票ＰＤＦを帳票ＳＶＧに変換する。データ変換サーバー１０７が生成する帳票ＳＶＧはＳＶＧファイル以外にもフォントファイルや画像ファイルなどの複数ファイルから構成されるが、データ変換サーバー１０７はそれらの複数ファイルをＺｉｐ化して結合・圧縮し１ファイルにする。データ変換サーバー１０７が生成する帳票ＳＶＧについては後述の図８ａに詳細を記載する。

Ｓ７．２−４においてデータ変換サーバー１０７はストレージサーバー１０８上の帳票ＳＶＧ ＵＲＬパスとインデックスＵＲＬパスを生成し、帳票ＳＶＧ ＵＲＬパスにＺｉｐ化した帳票ＳＶＧをアップロードする。そしてデータ変換サーバー１０７は帳票ＳＶＧ ＵＲＬパスのリストである変換インデックスファイルをインデックスＵＲＬパスにアップロードする。データ変換サーバー１０７はデータ変換情報４１０にインデックスＵＲＬパス４１５を登録する。帳票ＰＤＦおよび帳票ＳＶＧはいずれも前述したように所定の処理単位、たとえばページ単位で生成されている。したがってＵＲＬもその処理単位ごとに指定される。

Ｓ７．３において業務サーバー１０４は帳票サーバー１０６にプレビューＵＲＬ取得リクエストを行う。業務サーバー１０４はＳ７．３のプレビューＵＲＬ取得リクエストのパラメータとして、Ｓ７．２のプレビュー生成リクエストの応答で受信したプレビューＩＤを指定する。なお業務サーバー１０４はＳ７．３のプレビューＵＲＬ取得リクエストをＳ７．２のプレビュー生成リクエストの応答を受信した直後に先述のＳ７．２−１〜Ｓ７．２−４の処理とは非同期で行う。

Ｓ７．３のプレビューＵＲＬ取得リクエストを受け付けた帳票サーバー１０６はパラメータとして受信したプレビューＩＤと一致するレコードをプレビュー情報３１０から特定する。そして、帳票サーバー１０６はＳ７．３のプレビューＵＲＬ取得リクエストの応答として帳票サーバー１０６のプレビュー画面ＵＲＬを返す。ここで返す帳票サーバー１０６のプレビュー画面ＵＲＬにはＵＲＬパラメータとしてＳ７．３で受信したプレビューＩＤを指定する。

Ｓ７．４において業務サーバー１０４はＳ７．１の応答としてモバイル端末１０２にＳ７．３で受信した帳票サーバー１０６のプレビュー画面ＵＲＬを返す。

Ｓ７．５においてモバイル端末１０２はプレビュー画面ＵＲＬへプレビュー画面取得リクエストしプレビュー画面６１０を表示する。

Ｓ７．６においてモバイル端末１０２は帳票サーバー１０６にインデックスＵＲＬ取得リクエストを行う。インデックスＵＲＬ取得リクエストにはプレビュー画面ＵＲＬのＵＲＬパラメータに指定されているプレビューＩＤをパラメータとして指定する。

帳票サーバー１０６はＳ７．６のインデックスＵＲＬ取得リクエストで指定されるプレビューＩＤと一致するレコードをプレビュー情報３１０から特定する。ここで帳票サーバー１０６は特定したプレビュー情報３１０にデータ変換ＩＤ３１４が登録されていない場合、帳票ＰＤＦがまだインデックスが生成されていないとしてＳ７．６にエラー応答する。モバイル端末１０２はＳ７．６のインデックスＵＲＬ取得リクエストがエラーだった場合にはエラーが解消されるまで繰り返しＳ７．６のインデックスＵＲＬ取得リクエストを繰り返す。

Ｓ７．６−１において帳票サーバー１０６はＳ７．６で特定したプレビュー情報３１０にデータ変換ＩＤ３１４が登録されていた場合、データ変換ＩＤ３１４をパラメータとしてデータ変換サーバー１０７にインデックスＵＲＬ取得リクエストを行う。

インデックスＵＲＬ取得リクエストを受信したデータ変換サーバー１０７はデータ変換情報４１０からインデックスＵＲＬ取得リクエストのパラメータのデータ変換ＩＤと一致するレコードを特定する。そして特定したデータ変換情報４１０のステータス４１６が"変換済み"だった場合に、インデックスＵＲＬパス４１５をＳ７．６−１の応答として帳票サーバー１０６に返す。そして帳票サーバー１０６はＳ７．６の応答として受信したインデックスＵＲＬパスをモバイル端末１０２に返す。ここで、特定したデータ変換情報４１０のステータス４１６が"変換済み"以外だった場合、データ変換サーバー１０７は帳票サーバー１０６に帳票ＳＶＧがまだ生成されていないとしてＳ７．６−１の応答としてエラーを返す。そして帳票サーバー１０６はＳ７．３にエラー応答する。モバイル端末１０２はＳ７．６において帳票ＳＶＧが生成されインデックスＵＲＬパスを受信できるまでリトライする。

Ｓ７．７においてモバイル端末１０２はＳ７．６の応答として取得したインデックスＵＲＬパスからインデックスを取得する。そして取得したインデックスに記載された帳票ＳＶＧ ＵＲＬからＺｉｐ化された帳票ＳＶＧを取得しプレビュー画面６１０に帳票ＳＶＧを表示する。

Ｓ７．５〜Ｓ７．７におけるモバイル端末１０２内の処理フローについては図９に詳細を記載する。

＜帳票ＳＶＧのＺｉｐ構造とキャッシュ情報＞
図８ａはデータ変換サーバー１０７が帳票ＰＤＦから変換しＺｉｐ化する帳票ＳＶＧの構造の１ページ〜３ページまでの例である。Ｚｉｐ化とは、ファイルをＺｉｐファイルフォーマットに変換することである。Ｚｉｐファイルフォーマットは、複数のファイルを一つのファイルへと結合し、まとめて取り扱う（すなわちアーカイブする）フォーマットのひとつである。

Ｚｉｐ化した帳票ＳＶＧはストレージサーバー１０８に保存されＺｉｐ化した帳票ＳＶＧのＵＲＬ８００にアクセスすることでモバイル端末１０２は取得できる。Ｚｉｐ化した帳票ＳＶＧのＵＲＬ８００はデータ変換ＩＤ４１１やページ番号が含まれており、帳票ＳＶＧをユニークに識別可能になっている。

Ｚｉｐ化した帳票ＳＶＧのファイル階層はファイル階層８０１のように構成する。Ｚｉｐ化した帳票ＳＶＧにはＳＶＧファイルの他にＣＳＳファイルやフォントファイル、画像ファイルなどが含まれる。ファイル階層８０１はＺｉｐファイルのセントラルディレクトリに記録されており、Ｚｉｐファイルに含まれた個々のファイルはセントラルディレクトリにより特定可能である。

リンク階層８０２はＳＶＧファイルを基点としたリンク階層を示している。ＳＶＧファイルにはＣＳＳファイルがリンクされており、ＣＳＳファイルにはフォントファイルや画像ファイルがリンクされている。基点であるＳＶＧファイルをＷｅｂブラウザーアプリケーションで読み込むことによりリンクされたＣＳＳファイルやフォントファイル、画像ファイルが読み込まれる。

図８ｂはモバイル端末１０２で動作するＷｅｂブラウザーアプリケーションの帳票ＳＶＧのキャッシュ情報である。キャッシュ情報８１１は図８ａのＺｉｐ化した帳票ＳＶＧのＵＲＬ８００のサブパスとＺｉｐ化した帳票ＳＶＧのファイル階層８０１を基に、データ変換ＩＤ４１１やページ番号を含める。すなわち、Ｚｉｐ化した帳票ＳＶＧのＵＲＬ８００のサブパス（すなわち少なくとも一部）とＺｉｐ化した帳票ＳＶＧのファイル階層８０１からキャッシュが特定可能なよう構成する。

以上のように帳票ＳＶＧのＺｉｐ構造とリンク階層、キャッシュ情報でパス階層を一致させることで用意にキャッシュ情報の特定が可能になる。

＜モバイル端末１０２のＺｉｐ化した帳票ＳＶＧ表示フロー＞
図９は、図７のＳ７．５〜Ｓ７．７におけるモバイル端末１０２内の処理フロー詳細である。モバイル端末１０２で動作するＷｅｂブラウザーアプリケーション９００はＵＩ９０１、レンダリングエンジン９０２、Ｊａｖａｓｃｒｉｐｔ（登録商標）インタープリター９０３で構成される。なおＪａｖａｓｃｒｉｐｔ（登録商標）については、これ以降、登録商標の表示を省略する。

ＵＩ９０１はモバイル端末１０２のディスプレイ２１５に画面表示し、ユーザーからのタッチ操作を検知し、Ｊａｖａｓｃｒｉｐｔインタープリター９０３を介してＪａｖａｓｃｒｉｐｔプログラムにタッチ操作イベントを通知したりする。

レンダリングエンジン９０２はｈｔｍｌファイルやＳＶＧファイルなどのＷｅｂブラウザーアプリケーション９００で表示可能な構造化文書を解析し、ＵＩ９０１に表示する。レンダリングエンジン９０２はｈｔｍｌファイルやＳＶＧファイルの解析結果をＤＯＭ（ドキュメントオブジェクトモデル）として保持する。ＤＯＭはＪａｖａｓｃｒｉｐｔプログラムから編集可能であり、ＤＯＭが変更されたことをレンダリングエンジン９０２が検知して変更内容に従ってＵＩ９０１に画面変更を指示する。

Ｊａｖａｓｃｒｉｐｔインタープリター９０３はＪａｖａｓｃｒｉｐｔプログラムの実行環境である。レンダリングエンジン９０２がｈｔｍｌファイルやＳＶＧファイルを解析した結果、Ｊａｖａｓｃｒｉｐｔプログラム実行が指定されていた場合にＪａｖａｓｃｒｉｐｔプログラムがＪａｖａｓｃｒｉｐｔインタープリター９０３に渡されて実行される。本実施例ではプレビュー画面６１０を表示するｈｔｍｌファイルにｐｒｅｖｉｅｗ．ｊｓ９０６というＪａｖａｓｃｒｉｐｔプログラム実行が指定されておりＪａｖａｓｃｒｉｐｔインタープリター９０３で実行される。

Ｊａｖａｓｃｒｉｐｔインタープリター９０３内にはＳｅｒｖｉｃｅ Ｗｏｒｋｅｒ９０４とＣａｃｈｅ９０５が含まれる。Ｓｅｒｖｉｃｅ Ｗｏｒｋｅｒ９０４とＣａｃｈｅ９０５はＪａｖａｓｃｒｉｐｔプログラムから利用可能なようにＡＰＩ（Ａｐｐｌｉｃａｔｉｏｎ Ｐｒｏｇｒａｍｍｉｎｇ Ｉｎｔｅｒｆａｃｅ）を提供している。本実施例ではｐｒｅｖｉｅｗ．ｊｓ９０６や後述のｗｏｒｋｅｒ．ｊｓ９０４１がＳｅｒｖｉｃｅ Ｗｏｒｋｅｒ９０４やＣａｃｈｅ９０５のＡＰＩを利用してそれぞれの機能を利用する。

Ｓｅｒｖｉｃｅ Ｗｏｒｋｅｒ９０４はＷｅｂブラウザーアプリケーション９００にＪａｖａｓｃｒｉｐｔプログラムを常駐させる機能を提供する。Ｓｅｒｖｉｃｅ Ｗｏｒｋｅｒ９０４に登録されたＪａｖａｓｃｒｉｐｔプログラムはＷｅｂブラウザーアプリケーション９００の画面操作とは無関係にバックグラウンドで動作させることができる。またＳｅｒｖｉｃｅ Ｗｏｒｋｅｒ９０４に登録されたＪａｖａｓｃｒｉｐｔプログラムはレンダリングエンジン９０２からサーバーへのデータ取得リクエストをフックするよう構成することができる。本実施例ではｗｏｒｋｅｒ．ｊｓ９０４１というＪａｖａｓｃｒｉｐｔプログラムをＳｅｒｖｉｃｅ Ｗｏｒｋｅｒ９０４に登録し、ｗｏｒｋｅｒ．ｊｓ９０４１が帳票ＳＶＧのデータ取得リクエストをフックする。

Ｃａｃｈｅ９０５はデータのキャッシュ機能をキー・バリュー型でＪａｖａｓｃｒｉｐｔプログラムに提供する。Ｊａｖａｓｃｒｉｐｔプログラムはキーを指定してキャッシュ情報を追加・参照・削除することができる。本実施例では図８ｂに記載したキャッシュ情報をキーとして帳票ＳＶＧを構成するファイルをＣａｃｈｅ９０５に保存する。

帳票プレビュー時の処理シーケンスを説明する。Ｗｅｂブラウザーアプリケーション９００は、たとえばＵＩ９０１を通してプレビュー画面ＵＲＬを開くこと指示されると、Ｓ９．１においてレンダリングエンジン９０２がプレビュー画面ＵＲＬに接続（アクセス）する。プレビュー画面ＵＲＬは帳票サーバー１０６を指し示しており、レンダリングエンジン９０２は帳票サーバー１０６からプレビュー画面のｈｔｍｌファイルを取得する。

Ｓ９．２においてレンダリングエンジン９０２はＳ９．１で取得したプレビュー画面のｈｔｍｌファイルを解析しＵＩ９０１にプレビュー画面を表示する。

また、Ｓ９．３においてレンダリングエンジン９０２は、Ｓ９．１で取得したプレビュー画面のｈｔｍｌファイルにはｐｒｅｖｉｅｗ．ｊｓ９０６ファイルへのリンクが記載されており、レンダリングエンジン９０２はｐｒｅｖｉｅｗ．ｊｓファイルを取得しＪａｖａｓｃｒｉｐｔインタープリター９０３で実行する。ここでｐｒｅｖｉｅｗ．ｊｓファイルは帳票サーバー１０６に保存されておりレンダリングエンジン９０２は帳票サーバー１０６からｐｒｅｖｉｅｗ．ｊｓファイルを取得するが図示省略している。

Ｓ９．４において、実行されているｐｒｅｖｉｅｗ．ｊｓ９０６は、アーカイブされた帳票ＳＶＧのダウンロードに先立って、Ｃａｃｈｅ９０５が提供するＡＰＩを介してＣａｃｈｅ９０５保存されているキャッシュ情報をすべて削除する。

Ｓ９．５においてｐｒｅｖｉｅｗ．ｊｓ９０６はｗｏｒｋｅｒ．ｊｓ９０４１をＳｅｒｖｉｃｅ Ｗｏｒｋｅｒ９０４に登録する。ここでｗｏｒｋｅｒ．ｊｓファイルは帳票サーバー１０６に保存されておりｐｒｅｖｉｅｗ．ｊｓ９０６はｗｏｒｋｅｒ．ｊｓファイルのＵＲＬをＳｅｒｖｉｃｅ Ｗｏｒｋｅｒ９０４に登録する。Ｓｅｒｖｉｃｅ Ｗｏｒｋｅｒ９０４は登録されたｗｏｒｋｅｒ．ｊｓファイルのＵＲＬからｗｏｒｋｅｒ．ｊｓファイルを取得し実行するが図示省略している。

Ｓ９．６においてｐｒｅｖｉｅｗ．ｊｓ９０６は帳票サーバー１０６にインデックスＵＲＬ取得リクエストを行う。Ｓ９．６は図７におけるＳ７．６の処理と同じであり説明省略する。

Ｓ９．７とＳ９．８においてｐｒｅｖｉｅｗ．ｊｓ９０６は取得したインデックスＵＲＬにアクセスしてインデックスを取得し、インデックスに記載されたＵＲＬでＺｉｐ化した帳票ＳＶＧを取得する。Ｓ９．７とＳ９．８は図７におけるＳ７．７の処理と同じであり説明省略する。Ｓ９．８はアーカイブされた帳票ＳＶＧとしてｐａｇｅ１．ｚｉｐを取得している例である。図９ではｐａｇｅ１．ｚｉｐを例として説明する。

Ｓ９．９においてｐｒｅｖｉｅｗ．ｊｓ９０６はＳ９．８で取得したＺｉｐ化した帳票ＳＶＧ（ｐａｇｅ１．ｚｉｐ）を展開（解凍）する。Ｓ９．９においてＺｉｐ化した帳票ＳＶＧを展開すると図８で記載した帳票ＳＶＧファイル階層８０１を得ることができる。

Ｓ９．１０においてｐｒｅｖｉｅｗ．ｊｓ９０６はＳ９．９でＺｉｐ化した帳票ＳＶＧを展開して得られた帳票ＳＶＧファイル階層８０１をＣａｃｈｅ９０５に登録する。ここで登録するキャッシュ情報の例としてキー８１１を図８ｂに示す。キャッシュされるキーは、もともとストレージサーバー１０８に格納されていた際のパスを示すパス情報であり、そのパス情報をキーとしてファイルを特定できるようにファイルがキャッシュされる。キャッシュされるキー情報は、ファイルを一意に特定できるものであればよい。

Ｓ９．１１においてｐｒｅｖｉｅｗ．ｊｓ９０６はＳ９．９でＺｉｐ化した帳票ＳＶＧを展開して得られたＳＶＧファイル（ｐａｇｅ１．ｓｖｇ）をレンダリングエンジン９０２のＤＯＭ（ドキュメントオブジェクトモデル）に追加する。ＤＯＭにＳＶＧファイルを追加することでレンダリングエンジン９０２は追加されたＳＶＧファイルを解析し、画面に帳票ＳＶＧを表示する。Ｓ９．１１では、ｐｒｅｖｉｅｗ．ｊｓ９０６がレンダリングエンジン９０２のＤＯＭに追加するファイルは、Ｚｉｐ化した帳票ＳＶＧのファイル名（ｐａｇｅ１．ｚｉｐ）と拡張子を除いて一致する名称のＳＶＧファイル（ｐａｇｅ１．ｓｖｇ）を利用した。しかしＳＶＧファイル名は一般的なｉｎｄｅｘ．ｓｖｇのような固定ファイル名で特定してもよいし、ファイル階層の先頭（ルート）にあるすべてのＳＶＧファイルをＤＯＭに追加してもよい。また本実施例ではＳＶＧをデータフォーマットとしているがｈｔｍｌファイルなど他のフォーマットでも問題ない。ｈｔｍｌファイルの場合にはｐａｇｅ１．ｈｔｍｌや、固定ファイル名であればｉｎｄｅｘ．ｈｔｍｌがＤＯＭに追加される。

Ｓ９．１２においてＳＶＧファイル（ｐａｇｅ１．ｓｖｇ）がＤＯＭに追加されたことを検知したレンダリングエンジン９０２はＳＶＧファイル（ｐａｇｅ１．ｓｖｇ）を表示する。

またレンダリングエンジン９０２はＳ９．１３、Ｓ９．１６、Ｓ９．１９においてＳＶＧファイル（ｐａｇｅ１．ｓｖｇ）にリンクされた全てのファイルをファイル数分繰り返し取得する。図９においては３つのファイルをＳ９．１３、Ｓ９．１６、Ｓ９．１９で取得している例を図示しているがＳＶＧファイル（ｐａｇｅ１．ｓｖｇ）にリンクされた全てのファイルが取得される。ＳＶＧファイル（ｐａｇｅ１．ｓｖｇ）を基点としたリンク階層８０２は図８ａで先述した。

Ｓ９．１３、Ｓ９．１６、Ｓ９．１９においてレンダリングエンジンがアクセスする先は、対象であるＳＶＧファイルと同じくストレージサーバー１０８である。しかしｗｏｒｋｅｒ．ｊｓ９０４は帳票ＳＶＧのデータ取得リクエストをフックするよう構成され、Ｓ９．１３、Ｓ９．１６、Ｓ９．１９のレンダリングエンジン９０２からのファイル数分のリクエストを繰り返し受け付ける。

Ｓ９．１４、Ｓ９．１７、Ｓ９．２０においてｗｏｒｋｅｒ．ｊｓ９０４はＳ９．１３、Ｓ９．１６、Ｓ９．１９でファイル数分繰り返し受け付けたリクエストＵＲＬを基に、Ｃａｃｈｅ９０５から、キャッシュしたファイルを取得しＳ９．１３、Ｓ９．１６、Ｓ９．１９にそれぞれファイル数分繰り返し応答する。図９においてはＳ９．１３、Ｓ９．１６、Ｓ９．１９のリクエストＵＲＬを相対パスで図示しているため省略しているが、ファイル名の他にリクエストＵＲＬにはデータ変換ＩＤやページ番号が含まれ、Ｃａｃｈｅ９０５のキャッシュ情報（図８ｂ）から該当ファイルを特定可能である。

Ｓ９．１５、Ｓ９．１８、Ｓ９．２１においてレンダリングエンジン９０２は、Ｓ９．１３、Ｓ９．１６、Ｓ９．１９で受け取ったファイルをファイル数分繰り返し表示する。

Ｓ９．２２〜Ｓ９．２５はＣａｃｈｅ９０５のキャッシュ情報８１１（図８ｂ）にないファイル取得が行われた場合の例を示している。Ｃａｃｈｅ９０５のキャッシュ情報（図８ｂ）が削除された場合や、Ｚｉｐ化した帳票ＳＶＧに含まれていないファイルがリクエストされた場合は、Ｃａｃｈｅ９０５のキャッシュ情報（図８ｂ）にキャッシュが存在しない。Ｓ９．２２においてレンダリングエンジン９０２がキャッシュに存在しないファイル（ｔｉｔｌｅ．ｊｐｇ）の取得リクエストを行うと、ｗｏｒｋｅｒ．ｊｓ９０４はそのリクエストをフックし、Ｓ９．２３においてｗｏｒｋｅｒ．ｊｓ９０４はＣａｃｈｅ９０５からキャッシュ情報取得を試みる。Ｃａｃｈｅ９０５からのキャッシュ取得に失敗した場合、Ｓ９．２４においてｗｏｒｋｅｒ．ｊｓ９０４はＳ９．２２の本来のリクエストＵＲＬに対して取得リクエストを行い、取得したファイルをＳ９．２２の応答とする。

Ｓ９．２５においてレンダリングエンジン９０２はＳ９．２２で受け取ったファイルを表示する。

以上のように、複数ファイルで構成される帳票ＳＶＧをＺｉｐ化し、Ｗｅｂブラウザーアプリケーション９００で取得したＺｉｐ化した帳票ＳＶＧを展開し表示する。こうすることで、Ｗｅｂブラウザーアプリケーション９００からサーバーへのリクエスト数を大幅に少なくすることができ、効率的に帳票ＳＶＧを表示することができる。また、帳票ＳＶＧのＵＲＬやＷｅｂブラウザーアプリケーション９００内のキャッシュ情報にユニークなデータ変換ＩＤやページ番号を含めることで、Ｗｅｂブラウザーアプリケーション９００で異なる帳票ＳＶＧやページが処理可能となる。さらに、Ｗｅｂブラウザーアプリケーション９００内のキャッシュ情報にキャッシュファイルが存在しない場合にはサーバーから取得することでエラーすることなく帳票ＳＶＧを表示することができる。

＜モバイル端末１０２のキャッシュ情報の削除フロー＞
図１０は、図９のＳ９．１０においてｐｒｅｖｉｅｗ．ｊｓ９０６がＣａｃｈｅ９０５に保存したキャッシュ情報（図８ｂ）を削除する処理フローである。

Ｓ１０．１においてｐｒｅｖｉｅｗ．ｊｓ９０６はプレビュー画面６１０表示から一定時間たった場合や、一定時間ユーザーが操作しなかった場合に、Ｃａｃｈｅ９０５に保存したキャッシュ情報（図８ｂ）を全て削除する。すなわち、図１０の手順そのものが、プレビュー画面６１０表示から一定時間経過した場合や、ユーザーが一定時間操作しなかった場合に実行され、Ｓ１０．１においてキャッシュを削除する。

Ｓ１０．２においてｐｒｅｖｉｅｗ．ｊｓ９０６は帳票サーバー１０６に対して、プレビュー削除リクエストを行う。プレビュー削除リクエストにはパラメータとしてプレビューＩＤが指定され、受け付けた帳票サーバー１０６はプレビュー情報３１０からプレビューＩＤが一致するレコードを削除し、ストレージサーバー１０８に保存した帳票ＰＤＦデータや帳票ＳＶＧデータを削除する。

Ｓ１０．２においてｐｒｅｖｉｅｗ．ｊｓ９０６はプレビュー画面６１０を閉じてユーザーが使えないようにする。

この結果、プレビュー画面６１０表示から一定時間たった場合や、一定時間ユーザーが操作しなかった場合にＷｅｂブラウザーアプリケーション９００内のキャッシュ情報を削除することで、不必要なキャッシュ情報を残ることがなくなる。

以上のようにして、本実施形態によれば、帳票サーバーおよびデータ変換サーバーにより、Ｗｅｂ帳票データ（帳票ＳＶＧデータ）を所定の処理単位（たとえばページ）ごとに生成する。それとともに、その処理単位が複数のファイルで構成されている場合にも、それらファイルをアーカイブしてまとめた単一のファイルとして端末にダウンロードする。こうすることで、ひとつの処理単位を構成する複数のファイルそれぞれを個別にダウンロードすることがなく、迅速にＷｅｂ帳票を表示できる。またダウンロードした各ファイルはキャッシュされ、そのキャッシュにはスクリプトでアクセスすることで、汎用のＷｅｂブラウザーを用いることができる。

なお本実施形態では、Ｗｅｂ帳票データをＳＶＧ形式としたが、ブラウザーでの表示に適した形式であれば、例えば他の階層的に構成されたものであってもよい。いずれにしても、本実施形態の発明は以下のような構成となる。

アーカイブされた帳票データをサーバーからダウンロードし、展開し、帳票データの上位にある、下位の階層を構成するファイルへのリンクを含むファイルをＷｅｂブラウザーに返す。また、下位の階層を構成するファイルを格納キャッシュに保存する。Ｗｅｂブラウザーは、帳票データの上位の階層のファイルに含まれた、下位のファイルへのリンクをアクセス先としてアクセスを行う。そしてアクセスはクライアント内でフックされキャッシュしたファイルが読み出されてＷｅｂブラウザーに返され、表示される。

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

１０２ モバイル端末、１０４ 業務サーバー、１０６ 帳票サーバー、１０７ データ変換サーバー、１０８ ストレージサーバー

Claims (11)

1. 複数のファイルで階層的に構成された文書データをアーカイブして単一のファイルとして保存するサーバーに接続される情報処理装置であって、
   アーカイブされた前記文書データを前記サーバーからダウンロードし、展開し、前記文書データの下位の階層を構成するファイルを格納手段に保存するダウンロード手段と、
   前記文書データの上位の階層のファイルに記載された、前記下位の階層を構成するファイルのアクセス先にアクセスするブラウザー手段と、
   前記アクセスをフックして前記下位の階層を構成するファイルを読み出し、前記サーバーに代わり前記ブラウザー手段に返す読み出し手段と
   を有し、
   前記ブラウザー手段は、読み出した前記ファイルに基づいて前記文書データを表示することを特徴とする情報処理装置。
2. 前記ダウンロード手段は、前記アーカイブされた文書データのダウンロードに先立って、前記格納手段に保存されたファイルを削除することを特徴とする請求項１に記載の情報処理装置。
3. 前記ダウンロード手段は、前記文書データが表示されてから一定時間経過した場合、または、ユーザーが一定時間操作していない場合に、前記格納手段に保存されたファイルを削除することを特徴とする請求項１または２に記載の情報処理装置。
4. 前記ダウンロード手段は、前記文書データの下位の階層を構成するファイルを、前記サーバーに保存されていたときのパスの少なくとも一部とともに保存し、
   前記読み出し手段は、前記アクセスで指定された前記アクセス先の前記少なくとも一部と一致するパスと共に保存されたファイルを前記ブラウザー手段に返すことを特徴とする請求項１乃至３のいずれか一項に記載の情報処理装置。
5. 前記文書データは所定の処理単位でアーカイブされて保存され、
   前記ダウンロード手段は、前記処理単位で前記アーカイブされた文書データをダウンロードすることを特徴とする請求項１乃至４のいずれか一項に記載の情報処理装置。
6. 前記ダウンロード手段および前記読み出し手段は、前記ブラウザー手段が実行するスクリプトにより実現されることを特徴とする請求項１乃至５のいずれか一項に記載の情報処理装置。
7. 前記ブラウザー手段は、操作に応じて、前記サーバーに対して前記文書データのプレビューを要求し、
   前記サーバーは前記プレビューの要求に応じて前記文書データを生成し、アーカイブして保存することを特徴とする請求項１乃至６のいずれか一項に記載の情報処理装置。
8. 前記文書データはＳＶＧ（Ｓｃａｌａｂｌｅ Ｖｅｃｔｏｒ Ｇｒａｐｈｉｃｓ）形式であり、前記上位の階層のファイルには、下位の階層のファイルへのリンクが含まれており、
   前記ブラウザー手段は、前記リンクをアクセス先として前記下位の階層のファイルへとアクセスを試みることを特徴とする請求項１乃至７のいずれか一項に記載の情報処理装置。
9. 請求項１乃至８のいずれか一項に記載の情報処理装置と、
   前記情報処理装置からの要求に応じて文書データを生成し、生成した文書データを複数のファイルで階層的に構成された文書データに変換し、当該文書データをアーカイブして単一のファイルとして保存するサーバーと
   を含むことを特徴とする文書表示システム。
10. 請求項１乃至８のいずれか一項に記載の情報処理装置としてコンピュータを機能させるためのプログラム。
11. 複数のファイルで階層的に構成された文書データをアーカイブして単一のファイルとして保存するサーバーに接続される情報処理装置による文書表示方法であって、
    アーカイブされた前記文書データを前記サーバーからダウンロードし、展開し、前記文書データの下位の階層を構成するファイルを格納手段に保存し、
    ブラウザー手段が、前記文書データの上位の階層のファイルに記載された、前記下位の階層を構成するファイルのアクセス先にアクセスし、
    前記アクセスをフックして前記下位の階層を構成するファイルを読み出し、前記サーバーに代わり前記ブラウザー手段に返し、
    前記ブラウザー手段は、読み出した前記ファイルに基づいて前記文書データを表示することを特徴とする文書表示方法。

Images