JP2010287055A - 情報処理装置、データ変換方法及びプログラム - Google Patents

Abstract

【課題】アプリケーションのバージョンダウンに伴って、データ形式が変更される場合、データの互換性を確保する情報処理装置、データ変換方法及びプログラムを提供する。
【解決手段】本発明に係る情報処理装置は、ソフトウェア機能のバージョンアップ及びバージョンダウンを含むアプリケーションの更新を行う更新手段と、更新手段によりバージョンアップを行うアプリケーションと、当該バージョンよりも下位のバージョンのアプリケーションとのバージョン間における、データのデータ形式の差異に基づくデータの変換ルールが規定された変換ルール情報を記憶する記憶手段と、更新手段により下位のバージョンのアプリケーションへのバージョンダウンに伴い、変換ルール情報に従って、データを変換する変換手段とを有する。
【選択図】図６

Description

本発明は、情報処理装置、データ変換方法及びプログラムの分野に関する。

従来から、画像形成装置、コピーおよびスキャナなどの複数の機能を一つの筐体内に収納した画像形成装置が知られている。現在の画像形成装置（MFP：Multi-Function Peripheral）は、ＣＰＵの性能向上、メモリの大容量化、通信技術の高速化及びデジタル画像技術の高度化等、ＭＦＰに関連する技術の進化に伴い、単にデジタル複写機としての機能だけでなく、例えば、ネットワークやファクシミリ等で画像や文書などのデータの送受信を可能とし、ユーザ環境において様々な利用形態を提供するものである。

また、このような画像形成装置の機能を実現するアプリケーションは、ユーザに合わせた形にカスタマイズできることが知られている。画像形成装置は提供する機能を容易にカスタマイズができるよう設計されており、具体的には、アプリケーションをプラグインとして画像形成装置に追加できる。ユーザは利用したい機能をプラグイン単位で購入して、画像形成装置に対して容易にインストール又はアンインストールすることができるようになっている。

また、画像形成装置は、プラグインのインストール（又はアンインストール）に限らず、既にインストールされているアプリケーションを、プラグインによってバージョンアップ（又はバージョンダウン）することも可能である。アプリケーション（ソフトウェア）は、新たな機能が追加されたり修正（バグ対応等）されたりして新バージョンが日々リリースされており、ユーザは必要に応じて、新たにリリースされたプラグインにより、機能等をバージョンアップすることができる。

ここで、アプリケーションがバージョンアップされる際、既存のアプリケーションとのデータの互換性が問題となる。アプリケーション機能の追加等に伴い、バージョンによって、あるデータのデータ形式が変更されたり、新データが追加（定義）される場合があるからである。このようなバージョン間におけるデータ形式の差異を吸収するため対応方法として、バージョンアップ用のプラグインには、旧バージョンと新バージョンとのデータ形式等の差異を考慮して作成されたデータ変換プログラムが含まれており、バージョンアップ処理の際、旧保存データは新形式の保存データに適切に変換されるようになっている。具体的に、旧バージョンであるデータのデータ形式について、新バージョンでは異なるデータ形式が採用されている場合、旧バージョンのデータは新バージョンで解釈可能なデータ形式に変換されるのである。

これに関し特許文献１には、様々な機種や様々なバージョンが存在する画像形成装置や画像形成装置用のアプリケーションに関して、画像形成装置と画像形成装置用のアプリケーションの不適合に伴う不都合の発生を回避する発明が記載されている。アプリケーションが画像形成装置内で起動する際、当該アプリケーションの利用する機能を示す第一の情報と当該画像形成装置でサポートされている機能を示す第二の情報とを照合することにより当該アプリケーションの利用する機能の実行の可否を判定し、その判定結果に応じて当該アプリケーションの動作を変化させる判定手段を有し、前記判定手段は、前記第一又は第二の情報の構造に対応していない場合は自動的に更新されることにより課題を解決する。

一方、例えば、新バージョンのアプリケーションに不具合があったような場合には、アプリケーションが新バージョンから旧バージョンへバージョンダウンされる場合がある。ところが、保存データの形式に変更が発生する場合、アップグレードの場合とは事情が異なり、容易に保存データを旧バージョン対応のデータ形式に変換することができない。データの変換は、過去から未来の一方向にしか考慮されないからである。つまり、旧バージョンのデータ変換プログラムは、未来のデータ形式を予め予測することはできないので、新バージョンでのデータを、旧バージョンで解釈可能なデータ形式に変換することができない。従って、アプリケーションがバージョンダウンされる際、場合によっては、保存データを全て消去しなくてはならないという問題があった。例えば、アプリケーションをＶｅｒ（Version）３からＶｅｒ２へ変更する場合、ユーザ情報について未知のデータ（データ型）が存在すると、新データ形式から旧データ形式へのデータ変換ができないため、保存されるユーザ情報は消去せざるを得ない。例えば、ｖｅｒ３で２０００件という大量のユーザ情報が登録されている場合、Ｖｅｒ２へのバージョンダウンによって、アドレス帳情報の全てが消去され再登録等が必要とされる。

特許文献２には、プラグインのカスタマイズをどれだけ実施してもすぐにユーザのシステム環境を元に戻すことのできるプラグインバージョン管理システムが記載されている。しかしながら、特許文献２記載の発明は、プラグインのインストールによりシステムが正常に動作なくなった場合に、ハードウェアの互換性の観点から、システムを元の正常な状態に戻せるようにした発明である。

本発明では上記のような問題に鑑みて、アプリケーションのバージョンダウンに伴って、データ形式が変更される場合、データの互換性を確保する情報処理装置、データ変換方法及びプログラムを提供することを目的とする。

上記課題を解決するため、本発明に係る情報処理装置は、ソフトウェア機能のバージョンアップ及びバージョンダウンを含むアプリケーションの更新を行う更新手段と、前記更新手段によりバージョンアップを行うアプリケーションと、当該バージョンよりも下位のバージョンのアプリケーションとのバージョン間における、データのデータ形式の差異に基づくデータの変換ルールが規定された変換ルール情報を記憶する記憶手段と、前記更新手段により前記下位のバージョンのアプリケーションへのバージョンダウンに伴い、前記変換ルール情報に従って、前記データを変換する変換手段とを有することを特徴とする。

また上記課題を解決するため、前記情報処理装置において、前記変換ルール情報は、バージョンアップを行うアプリケーションに含まれ、バージョンアップに伴い前記記憶手段に記憶されることを特徴とする。

また上記課題を解決するため、前記情報処理装置において、前記変換ルール情報は、統一されたプログラム言語により定義されることを特徴とする。

また上記課題を解決するため、前記情報処理装置において、前記記憶手段は、同一の変換ルール情報が記憶されている場合、バージョンアップに伴い記憶される変換ルール情報の記憶を省略することを特徴とする。

また上記課題を解決するため、前記情報処理装置において、前記変換ルール情報は、前記更新手段により当該バージョンアップを行うアプリケーションの当該バージョンよりも下位全てのバージョンのアプリケーションとのバージョン間における、データのデータ形式の差異に基づくデータの変換ルールが規定されることを特徴とする。

なお、本発明の構成要素、表現または構成要素の任意の組合せを、方法、装置、システム、コンピュータプログラム、記録媒体などに適用したものも本発明の態様として有効である。

本発明によれば、アプリケーションのバージョンダウンに伴って、データ形式が変更される場合、データの互換性を確保する情報処理装置、データ変換方法及びプログラムを提供することができる。

本発明の実施形態に係る画像形成装置１のハードウェア構成の一例を示す図である。 画像形成装置１の一実施形態の主要構成を示す機能ブロック図である。 実施形態の画像形成装置１のソフトウェア構成の一例を示す。 Ｖｅｒ３へのバージョンアップ時の画像形成装置１のソフトウェア構成の一例を示す。 Ｖｅｒ３へのバージョンアップされたときの画像形成装置１のソフトウェア構成の一例を示す。 Ｖｅｒ２へのバージョンダウン時の画像形成装置１のソフトウェア構成の一例を示す。 Ｖｅｒ２へのバージョンダウンされた時の画像形成装置１のソフトウェア構成の一例を示す。 ＦＡＸアプリ（Ｖｅｒ１）におけるデータ及びデータ形式情報の一例を示す。 ＦＡＸアプリ（Ｖｅｒ３）におけるデータ及びデータ形式情報の一例を示す。 変換ルール情報（Ｖｅｒ３→２、１）２５ａ−３の一例を示す。 データの変換の一例を示す。 ルールテーブル１００５によるデータの変換の一例を示す。 変換ルール情報の実装例を示す。 変換ルール情報（Ｖｅｒ２→１）２５ａ−２の一例を示す。 バージョンアップ時の画像形成装置１の動作を説明するシーケンス図である。 バージョンダウン時の画像形成装置１の動作を説明するシーケンス図である。

本発明を実施するための形態を各実施形態において図面を用いて説明する。なお、本発明を説明するにあたって、情報処理装置の一実施形態である画像形成装置に本発明を適用した例を以下に示す。

＜システム＞
（画像形成装置）
本発明の実施形態に係る画像形成装置１は、例えば、プリンタ、コピーおよびスキャナなどの複数の機能を一つの筐体内に収納した複合機が適用できる。また、上述したように、画像形成装置は提供する機能を容易にカスタマイズができるよう設計されており、具体的には、アプリケーションをプラグインとして画像形成装置１に追加できる。また、画像形成装置１は、既にインストールされているアプリケーションを、プラグインによってバージョンアップ又はバージョンダウンすることも可能である。

図１は、本発明の実施形態に係る画像形成装置１のハードウェア構成の一例を示す図である。本発明による情報処理装置の一実施形態としての画像形成装置１は、操作パネル１１と、記憶メディアＩ／Ｆ１２と、コントローラ１３と、データ通信Ｉ／Ｆ１４と、スキャナ１５と、プロッタ１６と、ＨＤＤ（Hard Disk Drive）１７とから構成され、それぞれ相互に接続されている。

操作パネル１１は、入力装置１１aと表示装置１１bとを有しており、入力装置１１aは、ハードキーなどで構成され、装置本体に各操作信号を入力するのに用いられる。また、表示装置１１bは、ディスプレイなどで構成され、例えば画像形成動作に関する各種情報を表示する。データ通信Ｉ／Ｆ１４は、インタフェース装置１４aを有しており、画像形成装置をネットワークやファックスなどのデータ伝送路に接続するインタフェースである。ＨＤＤ１７は、画像形成装置で取り扱われる受信文書データや読み取り画像データ、各アプリケーションにより利用されるデータなど、各種データを格納している。また、ＨＤＤ１７は、これらの各種データを、所定のファイルシステムやＤＢ（Data Base）により管理している。

ＨＤＤ１７に格納される各種データの中には、記録媒体１２bから入力されるデータを含む。記録媒体１２bは、記憶メディアＩ／Ｆ１２が有するドライブ装置１２aにセットされ各種データが記録媒体１２bからドライブ装置１２aを介してＨＤＤ１７に格納される。

コントローラ１３は、ＲＯＭ（Read Only Memory）１３a、ＲＡＭ（Random Access Memory）１３b、及びＣＰＵ（Central Processing Unit）１３cとを有しており、ＲＯＭ１３aは、画像形成装置が起動されるときに実行されるプログラムや各種データを格納している。また、ＲＡＭ１３bは、ＲＯＭ１３aやＨＤＤ１７から読み出された各種プログラムやデータを一時保持する。更に、ＣＰＵ１３cは、ＲＡＭ１３bが一時保持しているプログラムを実行する。コントローラ１３は、例えば、データ通信Ｉ／Ｆ１４を介して印刷データを受信した場合に、ＲＯＭ１３aからＲＡＭ１３b上に読み出された、ＰＤＬ（Page Description Language）を解釈可能なプログラム（ＰＤＬパーサ）をＣＰＵ１３cにより実行し、印刷データを解釈してビットマップイメージを生成する。

スキャナ１５は、画像読取装置１５aを有しており、読み取り面に配置された原稿を光学的に読み取り画像データを生成する。プロッタ１６は、印刷装置１６aを有しており、例えば、電子写真プロセス方式によってビットマップイメージを記録紙に印刷する。

このように、本実施形態に係る情報処理装置の一実施形態としての画像形成装置は、上記ハードウェア構成により、コピー、画像形成装置、ファクシミリ、スキャナなどの複数の機能を実現している。

（機能）
本発明に係る実施形態の画像形成装置１の主な機能について説明する。図２は、画像形成装置１の一実施形態の主要構成を示す機能ブロック図である。図に示されるように、画像形成装置１は、更新部２１、変換部２２、記憶部２３を含む構成である。より詳しくは後述する動作において説明するため、ここでは各機能について簡単に説明する。

更新部２１は、プラグインを追加して、アプリケーションのインストール及びアンインストール、ソフトウェア機能のバージョンアップ及びバージョンダウンを含むアプリケーションの更新を行う機能を有している。

記憶部２３は、スキーマ内に各種アプリケーションによって利用されるデータ及各データの形式情報２４を記憶している。データ及びデータの形式情報２４の内容は、アプリケーションにより様々なデータが記憶される。データの例として、ＦＡＸアプリケーションの場合、登録された送信先を示すＦＡＸ先名称、そのＦＡＸ番号、ＦＡＸ操作を実行可能なユーザ情報等がある。データの形式情報の例として、データの型（string：文字列型、int：整数型など）、データの初期値、データ値のルール（とり得る値の定義）、データのサイズ、データの保存領域（ＮＶＲＡＭ等）、データのユニーク（固有）性の有無等がある。データはアプリケーションのバージョン間に渡って利用されるが、本実施形態においては、アプリケーションが（プラグインの更新によって）バージョンアップされる場合、データのデータ形式（例えばデータ型）は変更され得る。例えば、ソフトウェア機能の変更（拡張等）に伴い、新たなデータ形式が定義されたりして、データのデータ形式が変更される場合である。なお、スキーマ内のデータのデータ形式は形式情報２４により規定されるので、ソフトウェア機能のバージョンアップにより、データのデータ形式の定義が変更されるともいえる。詳細については再度後述する。

また、記憶部２３は、変換ルール情報２５を記憶する。変換ルール情報２５には、バージョン間でのデータの形式情報２４の差異に基づく、データの変換ルールが定義されている。変換ルール情報２５は、アプリケーションのバージョン変更時においてデータを変換する際に参照される。バージョン間で扱われるデータのデータ形式が異なる場合、データの互換性を保てるよう、データの変換ルールが規定されている。

変換部２２は、更新部２１により、下位のバージョンから上位のバージョンのアプリケーションへのバージョンアップに伴い、又は上位のバージョンから下位のバージョンのアプリケーションへのバージョンダウンに伴い、変換ルール情報２５に従って形式情報２４を変換する機能を有している。アプリケーションのバージョン間で扱われるデータのデータ形式が異なる場合でも、変換部２２により、データの互換性が確保される。

以上これらの機能は、実際には前述のＣＰＵ１３ｃが実行するプログラムによりコンピュータに実現させるものである。例えば、更新部２１はアプリケーションの更新プログラムにより実現され、変換部２２は更新プログラムに伴うデータ変換プログラムにより実現される。次に、本発明の実施形態に係る画像形成装置１の動作について詳しく説明していく。

＜動作＞
次に、本発明の実施形態に係る画像形成装置１の動作について詳しく説明していく。ここで、詳細な処理を説明する前に、変換ルール情報２５に注目しながら、アプリケーションのバージョンアップ及びバージョンダウンの流れについてまず説明する。以下、ＦＡＸアプリケーションが、ｖｅｒ１からｖｅｒ３にバージョンアップされ、さらにｖｅｒ３からｖｅｒ２にバージョンダウンされる例を取り上げて説明する。ここで、アプリケーションは必ずしもバージョン順にバージョンアップ又はバージョンダウンされるとは限らないことはいうまでもない。

（バージョンアップ）
図３は、実施形態の画像形成装置１のソフトウェア構成の一例を示す。図中、画像形成装置１には、プリンタアプリ（Ｖｅｒ１）３１１、コピーアプリ（Ｖｅｒ１）３１２、スキャナアプリ（Ｖｅｒ１）３１３、ＦＡＸアプリ（Ｖｅｒ１）３２４などのアプリケーションが既にインストールされている。また、データ用記憶領域３２０には、これら各アプリケーションにより利用されるデータ（上記のデータ及び形式情報２４に対応）が記憶されている。具体的には各アプリケーションに対応するように、プリンタアプリ用データ（ｆｏｒ Ｖｅｒ１）３２１、コピーアプリ用データ（ｆｏｒ Ｖｅｒ１）３２２、スキャナアプリ用データ（ｆｏｒ Ｖｅｒ１）３２３、ＦＡＸアプリ用データ（ｆｏｒ Ｖｅｒ１）３２４が記憶される。このようにアプリケーションに利用されるデータ用記憶領域３２０は、アプリケーションがインストールされたとき、そのアプリケーションが利用可能な所定領域が確保される。また、変換ルール用記憶領域３３０には、変換ルール情報２５が記憶される。詳細は後述するが、変換ルール情報２５は、少なくともバージョンアップを行うアプリケーションに含まれ又は付加されており、バージョンアップされるタイミングで記憶される。図３に示される画像形成装置１においては、いずれのアプリケーションもそのバージョンはｖｅｒ１であるので、この時点で変換ルール情報２５は記憶されていない。

図４は、Ｖｅｒ３へのバージョンアップ時の画像形成装置１のソフトウェア構成の一例を示す。ここで、ＦＡＸアプリ（Ｖｅｒ１）３１４は、ＦＡＸアプリ（Ｖｅｒ３）３１４−３へバージョンアップされる。バージョンアップを行うアプリケーションであるＦＡＸアプリ（Ｖｅｒ３）３２４−３は、変換ルール情報（Ｖｅｒ３→２、１）２５ａ−３、変換ルール情報（Ｖｅｒ１、２→３）２５ｂを有している。変換ルール情報（Ｖｅｒ１、２→３）２５ｂは、バージョンアップ用の変換ルール情報であり、Ｖｅｒ１からＶｅｒ２へバージョンアップ時、もしくはＶｅｒ１からＶｅｒ３へバージョンアップ時（まさに今この時）に参照される。変換ルール情報（Ｖｅｒ３→２、１）２５ａ−３は、バージョンダウン用の変換ルール情報であり、将来、Ｖｅｒ３からＶｅｒ１又は２へバージョンダウン時に参照されるので、Ｖｅｒ３へバージョンアップされるタイミングで変換ルール用記憶領域３３０に記憶（保存）される。変換ルール情報の詳細については後述する。

図５は、Ｖｅｒ３へのバージョンアップされたときの画像形成装置１のソフトウェア構成の一例を示す。図に示されるように、更新部２１により、ＦＡＸアプリ(Ｖｅｒ１）３２４は、ＦＡＸアプリ(Ｖｅｒ３）３２４−３に更新されている。また、変換部２２により、変換ルール情報（Ｖｅｒ１、２→３）２５ｂが参照され、ＦＡＸアプリ用データ（ｆｏｒ Ｖｅｒ１）３２４は、ＦＡＸアプリ用データ（ｆｏｒ Ｖｅｒ３）３２４−３に変換されている。また、変換ルール情報（Ｖｅｒ３→２、１）２５ａ−３は、将来のバージョンダウンに備え、変換ルール用記憶領域３３０に記憶（保存）されている。

（バージョンダウン）
図６は、Ｖｅｒ２へのバージョンダウン時の画像形成装置１のソフトウェア構成の一例を示す。バージョンダウンを行うアプリケーションであるＦＡＸアプリ（Ｖｅｒ２）３２４−２は、変換ルール情報（Ｖｅｒ２→１）２５ａ−２、変換ルール情報（Ｖｅｒ１→２）２５ｂを有している。変換ルール情報（Ｖｅｒ１→２）２５ｂは、Ｖｅｒ１からＶｅｒ２へバージョンアップ時に参照されるものであるが、ここでは既にインストールされているＦＡＸアプリのバージョンはＶｅｒ３であるので、参照（使用）されない。変換ルール情報（Ｖｅｒ２→１）２５ａ−２は、将来、Ｖｅｒ２からＶｅｒ１へバージョンダウン時に参照されるので、変換ルール用記憶領域３３０に記憶（保存）される。

なお、変換ルール情報２５は、少なくともバージョンアップを行うアプリケーションに含まれ又は付加されると上述説明したが、バージョンダウンを行うアプリケーションであっても、自身が最下位のバージョンのアプリケーションでなければ、変換ルール情報２５が含まれ又は付加されていてもよい。但し、最下位バージョンのアプリケーションには変換ルール情報２５が含まれない。変換ルール情報２５は、自身のバージョンより下位バージョンのアプリケーションにバージョンダウンされる際に利用されるものであるので、自身より下位バージョンを持たない最下位バージョンのアプリケーションについては、変換ルール情報２５を持つ必要がないからである。

図７は、Ｖｅｒ２へのバージョンダウンされた時の画像形成装置１のソフトウェア構成の一例を示す。図に示されるように、更新部２１により、ＦＡＸアプリ(Ｖｅｒ３）３２４−３は、ＦＡＸアプリ(Ｖｅｒ２）３２４−２に更新されている。また、変換部２２により、変換ルール用記憶領域３３０に記憶されていた変換ルール情報（Ｖｅｒ３→２、１）２５ａ−２が参照され、ＦＡＸアプリ用データ（ｆｏｒ Ｖｅｒ３）３２４−４は、ＦＡＸアプリ用データ（ｆｏｒ Ｖｅｒ２）３２４−２に変換されている。また、変換ルール情報（Ｖｅｒ２→１）２５ａ−２は、将来のバージョンダウンに備え、変換ルール用記憶領域３３０に記憶（保存）されている。

ところで、上述したように、ＦＡＸアプリ用データ自体はＦＡＸアプリのバージョン間に渡って利用される。ＦＡＸアプリ用データは、例えば、ＦＡＸ送信先名称やＦＡＸ番号であったりするので、一旦登録されている情報はバージョンが変更されても、そのまま利用されるべきであるからである。しかしながら、アプリケーションがバージョンアップされる場合、一般に上位バージョンではソフトウェア機能の変更（拡張等）がなされているので、データの互換性が問題となる。上位バージョンのアプリケーションでは、共通で利用されるべきＦＡＸアプリ用データのデータ形式（の定義）が変更されている場合があるので、このような場合、そのまま下位バージョンで採用されていたデータ形式では、バージョンアップ後のアプリケーションでＦＡＸ用データを利用できない。この点、一般に、バージョンアップされるアプリケーションの更新プログラムには、旧バージョンと新バージョンとのデータ形式等の差異を考慮して作成されたデータ変換プログラム及びバージョンアップ用の変換ルール情報が含まれており、バージョンアップ処理の過程で、旧データは新形式のデータに適切に変換されるようになっている。

一方、アプリケーションがバージョンダウンされる場合、一般に、これから更新を行おうとするアプリケーションの更新プログラムには、新バージョンから旧バージョンへのデータ形式等の差異を考慮して作成されたデータ変換プログラム及びバージョンダウン用の変換ルール情報は含まれていない。具体的に、ＦＡＸアプリがＶｅｒ３からＶｅｒ２へバージョンダウンされる場合、Ｖｅｒ３のＦＡＸアプリで利用されていたＦＡＸアプリ用データを、Ｖｅｒ２のＦＡＸアプリで利用可能（解釈可能）なデータ形式に変換される必要があるところ、これから更新を行おうとするＶｅｒ２のＦＡＸアプリの更新プログラムは、Ｖｅｒ３のデータを変換することができない。Ｖｅｒ２のデータ変換プログラムは、Ｖｅｒ３のＦＡＸアプリより時間的に前にリリースされているので、将来において開発されたＶｅｒ３のＦＡＸアプリで利用されるデータ形式を予測することができないからである。なお、これから更新を行おうとするＶｅｒ２のデータ変換プログラムがデータの形式を変換できるのは、時間的に前にリリースされているＶｅｒ１のＦＡＸアプリのデータのみとなる。

以上踏まえ、本発明の実施形態に係る画像形成装置１においては、上位バージョンのアプリケーション（いわば未来のアプリケーション）から、下位バージョンのアプリケーション（いわば過去のアプリケーション）へのデータ形式の変換方法を指示する情報（変換ルール情報２５ａ）を提供する。そしてこの変換ルール情報２５ａを参照することにより、上位バージョンのアプリケーションで利用されていたデータのデータ形式を、下位バージョンのアプリケーションで利用可能（解釈可能）なデータ形式に変換されることを可能としている。続いて、変換ルール情報２５及びデータ形式の変換処理について、詳しく説明していく。

（データ及びデータ形式情報）
はじめに、アプリケーションで利用されるデータ及びデータ形式情報について説明する。図８は、ＦＡＸアプリ（Ｖｅｒ１）におけるデータ及びデータ形式情報の一例を示す。ＦＡＸアプリで取り扱われるデータとしては、ＦＡＸ先名称、ＦＡＸ番号、実行可能なユーザ情報等があるが、この中からユーザ情報についての例を示す。ユーザ情報８００には、「Name」、「Address」、「UserType」等の情報項目が設けられている。「Name」は、ユーザの名称を示し、「Address」はユーザの所在を示す情報であり、任意に登録される。「UserType」は、０〜３の整数値を取る。値にはそれぞれ利用上の意味が対応付けられており、例えば、「０」であれば表示上「Guest」と、「３」であれば「Administrator」として表示される。また、ユーザ情報８００は、形式情報８１０によってそのデータ形式が規定されている。ここではデータ形式を規定する情報として、データの「型」、「初期値」、「値のルール」、「保存領域」、「サイズ」、「unique」といった情報項目が設けられており、ユーザ情報８００の各情報項目は形式情報８１０に従って登録される必要がある。例えば、「Name」はＮｕｌｌ（空欄）禁止であり２０文字以下で登録される必要がある。また「UserType」は０〜３の整数値（int）で登録されなくてはならない。なお、ここではＦＡＸアプリ（Ｖｅｒ２）についても、ＦＡＸアプリ（Ｖｅｒ１）における形式情報８１０が採用されているものとする。

次に、図９は、ＦＡＸアプリ（Ｖｅｒ３）におけるデータ及びデータ形式情報の一例を示す。ユーザ情報９００には、「Name」、「Address」、「UserType」等の情報項目が設けられている点は、Ｖｅｒ１（及びＶｅｒ２）と同様である。但し、形式情報９１０が変更されており、具体的にはData「Address」において「unique」、Data「UserType」において「型」及び「値のルール」についてデータ形式が変更されている。「unique」は同一空間内で重複することが認められない固有情報であることを示し、例えばアカウント情報やシリアル番号といった識別子でよく利用される。よって、Data「Address」は、「unique」が「No」と規定されているので情報の重複は認められないようになっている。また、Data「UserType」は使用者権限を分配する為の情報であるが、「型」が「UserType」という拡張型に変更されるとともに、「値のルール」が「Guest,User,PowerUser,Administrator,UserAdministrator」の何れかとして規定しなくてはならなくなっている。よって、ユーザ情報９００の「UserType」は、この規定に従い登録される。以上ここまで、データ及びデータ形式情報についての例を示し説明を行った。次に、変換ルール情報について説明を行う。

（変換ルール情報）
図１０は、変換ルール情報（Ｖｅｒ３→２、１）２５ａ−３の一例を示す。この変換ルール情報は、バージョンダウン用の変換ルール情報であり、Ｖｅｒ３へバージョンアップされるタイミングで変換ルール用記憶領域３３０に記憶され、Ｖｅｒ３からＶｅｒ１又は２へバージョンダウン時に参照される。なお、図５、６における変換ルール用記憶領域３３０に記憶されている変換ルール情報（Ｖｅｒ３→２、１）２５ａ−３に対応する。

図に示されるように、変換ルール情報（Ｖｅｒ３→２、１）２５ａ−３は、４つのテーブルに示される情報を概念的に含む。テーブル１００１では、データ変換の対象であるユーザ情報の情報項目（「Name」、「Address」、「UserType」等）毎に、変換ルールという情報が規定されている。つまり、テーブル１００１では、バージョンダウンに伴い、各情報項目のデータ形式を変換する場合に従うべきルールテーブルが規定される。例えば、Ｖｅｒ３からＶｅｒ２へのバージョンダウンに伴いデータ形式の変換がされる場合、「Name」について「H-000」、「Address」について「H-001,H-000」、「UserType」について「H-0002,H-000」のルールテーブルに規定される変換ルールが適用される。

より具体的に説明する。再び図６を参照し、ＦＡＸアプリをＶｅｒ３からＶｅｒ２へバージョンダウンを行う場合、
（１）ＦＡＸアプリ（アプリケーションプログラム）の更新
（２）ＦＡＸ用アプリデータのデータ形式の変換
という手順によりバージョンダウンの処理が進行する。

まず（１）について、既存のＦＡＸアプリ（Ｖｅｒ３）３１４−３から、更新を行うＦＡＸアプリ（Ｖｅｒ２）３１４−２へ、ＦＡＸアプリ（Ｖｅｒ２）３１４−２の更新プログラム（更新部２１に対応）により、アプリケーションプログラムの更新が行われる。図７のＦＡＸアプリ（Ｖｅｒ２）３１４−２は、アプリケーションプログラムの更新が完了した様子を示している。

次に（２）について、更新されたＦＡＸアプリ（Ｖｅｒ２）３１４−２のデータ変換プログラム（変換部２２に対応）により、Ｖｅｒ３で利用されていたＦＡＸアプリ用データ（ｆｏｒ Ｖｅｒ３）３２４−３から、Ｖｅｒ２で利用可能なＦＡＸアプリ用データ（ｆｏｒ Ｖｅｒ２）３２４−２へ変換される。ここで変換される対象は、ユーザ情報９００である（図９）。なおこのとき、更新される側のＦＡＸアプリ（Ｖｅｒ３）３１４−３が、過去にバージョンアップされたタイミングで変換ルール用記憶領域３３０に記憶されていた変換ルール情報（Ｖｅｒ３→２、１）２５ａ−３が参照される。

ここで仮に、変換ルール情報（Ｖｅｒ３→２、１）２５ａ−３が参照されない場合、更新されたＦＡＸアプリ（Ｖｅｒ２）のデータ変換プログラムは、Ｖｅｒ３で利用されていたＦＡＸアプリ用データ（ｆｏｒ Ｖｅｒ３）を、Ｖｅｒ２で利用可能なＦＡＸアプリ用データ（ｆｏｒ Ｖｅｒ２）に変換できない。ＦＡＸアプリ（Ｖｅｒ２）のデータ変換プログラムは、Ｖｅｒ３のＦＡＸアプリより時間的に前にリリースされているので、将来において開発されたＶｅｒ３のＦＡＸアプリで利用されるデータ形式を予測することができないからである。つまり、未来で使用される未知のデータに対して、過去においてどのようなデータ形式で取り扱うべきか予測できないのである。なお、Ｖｅｒ２のＦＡＸアプリのデータ変換プログラムがデータ形式を変換できるのは、時間的に前にリリースされているＶｅｒ１のＦＡＸアプリのデータのみとなる。

再び図１０に戻る。ルールテーブル１００２〜１００４は、データを移行先毎で利用（解釈）できるようなデータ形式に変換する為の変換ルールを規定している。例えば、Data「Address」についてデータ変換を行う場合、参照先（H-001）であるルールテーブル１００２が参照される。Ｖｅｒ１及び２では「unique」の規定が「Ｙｅｓ」であるので（図８、８１０）、Data「Address」については、データ値の重複は認められない。従って、ルールテーブル１００２では、データ値が重複しないように、データの変換ルールが規定される。また例えば、Data「UserType」についてデータ変換を行う場合、参照先（H-002）であるルールテーブル１００３が参照される。移行先のＶｅｒ２では「型」の規定が「int（整数型）」であり、これに伴い「値のルール」の規定が「０〜３」であるので（図８、８１０）、Data「UserType」については、データの変換が必要である。従って、ルールテーブル１００３では、データ形式に違反しないように、データの変換ルールが規定される。

なお、変換ルール情報は、Ｖｅｒ３からＶｅｒ２及び１といったように、移行先として、過去（下位）全てのバーションへの変換ルールが規定される。これは、必ずしもバージョン順にバージョンダウンされるとは限らず、例えばＶｅｒ３からＶｅｒ１というように、飛び級でバージョンダウンされる場合に対応できるようにする為である。

図１１は、データの変換の一例を示す。Ｖｅｒ３で利用されていたユーザ情報９００が、Ｖｅｒ２で利用可能なデータ形式のユーザ情報９０１に変換されている。Data「Address」については、データ値の重複は解消され、またData「UserType」については、int（整数型）の値に変換されている。また、Ｖｅｒ２では未定義の「UserType」である「UserAdministrator」は、「Administrator」と同様に取り扱うよう規定された結果、「３」に変換されている。ユーザ情報９０１は、このようなデータ変換によって、ＦＡＸアプリ（Ｖｅｒ２）３１４−２において利用可能となる。例えば、図７のＦＡＸアプリ用データ（ｆｏｒ Ｖｅｒ２）３２４−２は、ＦＡＸアプリ（Ｖｅｒ２）３１４−２が利用可能となったデータを示している。

なお、参照先（H-000）であるルールテーブル１００４は、変換ルールが見当たらない場合の救済措置として設けられている。図１２は、ルールテーブル１００５によるデータの変換の一例を示す。例えば、Data「UserType」についてデータ変換を行う場合、「TestUser」はルールテーブル１００４に規定されていない。従って、次の参照先（H-000）であるルールテーブル１００５が参照され、「φ」に変換される。原則的にはルールテーブル１００５が参照されることはないが、参照される場合（例外）として、「値のルール」に違反して登録されていたり、「値のルール」に規定されているものの、変換ルール情報において変換のルールが規定されていないような場合が考えられる。

図１３は、変換ルール情報の実装例を示す。具体的には、上述の変換ルール情報（Ｖｅｒ３→２、１）２５ａ−３を示す。一例として、変換ルール情報は、ＸＭＬ（Extensible Markup Language）により記述されている。データの変換ルール情報は、全バージョン（特に下位のバージョン）におけるデータ変換プログラムにより解釈される必要があるので、何れのバージョンにおいても利用できるように汎用的な形式で規定（記述）される。図１３の変換ルール情報（Ｖｅｒ３→２、１）２５ａ−３には、テーブル１００１、テーブル１００３に対応する箇所が示されている（一部省略）。なお、上述のＸＭＬは一例であり、変換ルール情報は、汎用性のある形式で規定されると望ましいが、全バージョンのデータ変換プログラムにより解釈可能な統一された形式で規定されればよい。

以上、データ形式の変換処理の具体例を示しながら、変換ルール情報について説明を行った。なおここで、変換ルール情報（Ｖｅｒ２→１）２５ａ−２について補足しておく。変換ルール情報（Ｖｅｒ２→１）２５ａ−２は、ＦＡＸアプリ（Ｖｅｒ２）３１４−２へバージョンダウンされるタイミングで変換ルール用記憶領域３３０に記憶されている(図６、７)。変換ルール情報（Ｖｅｒ２→１）２５ａ−２は、バージョンダウン用の変換ルール情報であり、将来、Ｖｅｒ２からＶｅｒ１へバージョンダウンされる場合に参照される。図１４は、変換ルール情報（Ｖｅｒ２→１）２５ａ−２の一例を示す。上述したように、ＦＡＸアプリ（Ｖｅｒ２）については、ＦＡＸアプリ（Ｖｅｒ１）における形式情報８１０が採用されているものとしているので(図８)、データ形式は、Ｖｅｒ１とＶｅｒ２では差異がない。従って、データの変換は必要とされず、上述の救済措置の規定を除き、原則変換ルールが規定されることはないことになる。このように、データ変換の必要性は、バージョン間のデータ形式の差異に基づくといえる。

（シーケンス）
次に、バージョンアップ時及びバージョンダウン時の画像形成装置１の動作について、上述の説明と重複する点もあるが、シーケンス図を参照しながら確認的に説明を行う。これまでと同様、アプリケーションが、ｖｅｒ１からｖｅｒ３にバージョンアップされ、さらにｖｅｒ３からｖｅｒ２にバージョンダウンされる例を取り上げて説明する。図１５は、バージョンアップ時の画像形成装置１の動作を説明するシーケンス図である。

まず、更新部２１は、Ｖｅｒ３のアプリケーションを取得して、アプリケーションをｖｅｒ１からｖｅｒ３にバージョンアップさせる（ステップＳ１５０１）。

Ｖｅｒ３のアプリケーションには、変換ルール情報（Ｖｅｒ１→２、３）及び変換ルール情報（Ｖｅｒ３→２、１）が含まれている。変換部２２は、アプリケーションの現行のバージョンと更新されるバージョンを把握しており、バージョンアップされる場合、更新部２１よりバージョンアップ時に参照される変換ルール情報（Ｖｅｒ１→２、３）を取得する（Ｓ１５０２）。また更新部２１は、将来、バージョンダウン時に参照される変換ルール情報（Ｖｅｒ３→２、１）を記憶部２３に記憶させる（Ｓ１５０３）。このとき、記憶部２３に既に同一の変換ルール情報の有無を確認する。同一の変換ルール情報（Ｖｅｒ３→２、１）が既に記憶されている場合、記憶（書き込み）を省略して、処理時間や記憶領域を節約できるからである。なお、既に同一の変換ルール情報が記憶されている場合とは、過去にＶｅｒ３のアプリケーションにバージョンアップされていたことを意味する。例えば、Ｖｅｒ１、Ｖｅｒ３、Ｖｅｒ２というように遷移して、再度Ｖｅｒ３アプリケーションにバージョンアップするような場合である。

変換部２２は、変換の対象となるデータを記憶部２３より取得し（Ｓ１５０４）、更新部２１より取得した変換ルール情報（Ｖｅｒ１→２、３）を参照して、データの変換処理を行う（Ｓ１５０５）。記憶部２３が変換を行ったデータを再度記憶することにより（Ｓ１５０６）、更新されたＶｅｒ３のアプリケーションは、変換後のデータを利用できるようになる。

図１６は、バージョンダウン時の画像形成装置１の動作を説明するシーケンス図である。更新部２１は、Ｖｅｒ２のアプリケーションを取得して、アプリケーションをｖｅｒ３からｖｅｒ２にバージョンダウンさせる（ステップＳ１６０１）。

Ｖｅｒ２のアプリケーションには、変換ルール情報（Ｖｅｒ１→２）及び変換ルール情報（Ｖｅｒ２→１）が含まれている。変換部２２は、アプリケーションの現行のバージョンと更新されるバージョンを把握しており、バージョンダウンされる場合、記憶部２３よりバージョンアップ時に参照される変換ルール情報（Ｖｅｒ３→２、１）を取得する（Ｓ１６０２）。また更新部２１は、将来、バージョンダウン時に参照される変換ルール情報（Ｖｅｒ２→１）を記憶部２３に記憶させる（Ｓ１６０３）。このとき、上述と同様に、記憶部２３に既に同一の変換ルール情報の有無を確認する。

変換部２２は、変換の対象となるデータを記憶部２３より取得し（Ｓ１６０４）、記憶部２３より取得した変換ルール情報（Ｖｅｒ３→２、１）を参照して、データの変換処理を行う（Ｓ１６０５）。記憶部２３が変換を行ったデータを再度記憶することにより（Ｓ１６０６）、更新されたＶｅｒ２のアプリケーションは、変換後のデータを利用できるようになる。

なお、バージョンダウンされる場合、変換部２２は、記憶部２３よりバージョンアップ時に参照される変換ルール情報（Ｖｅｒ３→２、１）を取得する（Ｓ１６０２）が、該当する変換ルール情報を取得できない場合（消去されて場合等）、救済措置として、データを一律に上述の「φ」に変換するなどの措置を行うことができる。

＜総括＞
以上、本発明の実施形態に係る画像形成装置１は、アプリケーションのバージョンアップ時に、将来のバージョンダウンに備え、変換ルール情報を記憶しておく。変換ルール情報には、バージョンアップを行うアプリケーションと、当該バージョンよりも下位全てのバージョンのアプリケーションとのバージョン間におけるデータの変換ルールが規定される。そして、アプリケーションのバージョンダウン時に、記憶されている変換ルール情報を参照して、上位のバージョンのアプリケーションで利用されていたデータを、その下位のバージョンのアプリケーションで利用可能なデータ形式に変換する。

このように、アプリケーションが新バージョンから旧バージョンへバージョンダウンされる場合でも、データ（ユーザデータ）を旧バージョン対応のデータ形式に容易に変換できるので、アプリケーションのバージョン移行、特にバージョンダウン時に伴うデータの互換性を容易に確保できる。例えば、新データ形式から旧データ形式へのデータ変換ができずに、ユーザデータを消去して再登録する手間や、別途データのコンバージョンを行うといった手間を省くことができる。

即ち本発明の実施形態によれば、アプリケーションのバージョンダウンに伴って、データ形式が変更される場合、データの互換性を確保する情報処理装置、方法、プログラム、記録媒体を提供することが可能である。

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

１ 画像形成装置
１１ 操作パネル
１１ａ 入力装置
１１ｂ 表示装置
１２ 記憶メディアＩ／Ｆ
１２ａ ドライブ装置
１２ｂ 記録媒体
１３ コントローラ
１３ａ ＲＯＭ
１３ｂ ＲＡＭ
１３ｃ ＣＰＵ
１４ データ通信Ｉ／Ｆ
１４ａ インターフェース装置
１５ スキャナ
１５ａ 画像読取装置
１６ プロッタ
１６ａ 印刷装置
１７ ＨＤＤ
２１ 更新部
２２ 変換部
２３ 記憶部
２４ データ及び形式情報
２５ 変換ルール情報
３１１ プリンタアプリ
３１２ コピーアプリ
３１３ スキャナアプリ
３１４ ＦＡＸアプリ
３２０ データ用記憶領域
３２１ プリンタアプリ用データ
３２２ コピーアプリ用データ
３２３ スキャナアプリ用データ
３２４ ＦＡＸアプリ用データ
３３０ 変換ルール用記憶領域

特開２００６‐３０９７１９号公報 特開２００７‐３１０８０７号公報

Claims (11)

1. ソフトウェア機能のバージョンアップ及びバージョンダウンを含むアプリケーションの更新を行う更新手段と、
   前記更新手段によりバージョンアップを行うアプリケーションと、当該バージョンよりも下位のバージョンのアプリケーションとのバージョン間における、データのデータ形式の差異に基づくデータの変換ルールが規定された変換ルール情報を記憶する記憶手段と、
   前記更新手段により前記下位のバージョンのアプリケーションへのバージョンダウンに伴い、前記変換ルール情報に従って、前記データを変換する変換手段と、
   を有することを特徴とする情報処理装置。
2. 前記変換ルール情報は、バージョンアップを行うアプリケーションに含まれ、バージョンアップに伴い前記記憶手段に記憶されること、
   を特徴とする請求項１に記載の情報処理装置。
3. 前記変換ルール情報は、統一されたプログラム言語により定義されること、
   を特徴とする請求項２に記載の情報処理装置。
4. 前記記憶手段は、同一の変換ルール情報が記憶されている場合、バージョンアップに伴い記憶される変換ルール情報の記憶を省略すること、
   を特徴とする請求項２又は３に記載の情報処理装置。
5. 前記変換ルール情報は、前記更新手段により当該バージョンアップを行うアプリケーションの当該バージョンよりも下位全てのバージョンのアプリケーションとのバージョン間における、データのデータ形式の差異に基づくデータの変換ルールが規定されること、
   を特徴とする請求項１ないし４いずれ一項に記載の情報処理装置。
6. コンピュータが、
   ソフトウェア機能のバージョンアップ及びバージョンダウンを含むアプリケーションの更新を行う更新手順と、
   前記更新手順によりバージョンアップを行うアプリケーションと、当該バージョンよりも下位のバージョンのアプリケーションとのバージョン間における、データのデータ形式の差異に基づくデータの変換ルールが規定された変換ルール情報を記憶する記憶手順と、
   前記更新手順により前記下位のバージョンのアプリケーションへのバージョンダウンに伴い、前記変換ルール情報に従って、前記データを変換する変換手順と、
   を有することを特徴とするデータ変換方法。
7. 前記変換ルール情報は、バージョンアップを行うアプリケーションに含まれ、バージョンアップに伴い前記記憶手順により記憶されること、
   を特徴とする請求項６に記載のデータ変換方法。
8. 前記変換ルール情報は、統一されたプログラム言語により定義されること、
   を特徴とする請求項７に記載のデータ変換方法。
9. 前記記憶手順は、同一の変換ルール情報が記憶されている場合、バージョンアップに伴い記憶される変換ルール情報の記憶を省略すること、
   を特徴とする請求項７又は８に記載のデータ変換方法。
10. 前記変換ルール情報は、前記更新手順により当該バージョンアップを行うアプリケーションの当該バージョンよりも下位全てのバージョンのアプリケーションとのバージョン間における、データのデータ形式の差異に基づくデータの変換ルールが規定されること、
    を特徴とする請求項６ないし９いずれ一項に記載のデータ変換方法。
11. 請求項６ないし１０いずれか一項に記載のデータ変換方法をコンピュータに実行させるためのプログラム。

Images