JP4791910B2 - 画像形成装置、情報処理方法、情報処理プログラム、及び記録媒体 - Google Patents

Description

本発明は、コピー／プリンタ／スキャナ／ファクシミリ／複合機／融合機等の画像形成装置、情報処理方法、情報処理プログラム、ＳＤメモリカード等の記録媒体に関する。

近年、コピー機能とプリンタ機能とスキャナ機能とファクシミリ機能を備える複合機や融合機が市販されるようになった。複合機や融合機は、コピーやプリンタとして機能する場合には、画像を印刷用紙に印刷することになり、コピーやスキャナとして機能する場合には、画像を読取原稿から読み取ることになり、ファクシミリとして機能する場合には、画像を電話回線を介して他の機器と授受することになる。
特開２００２−８４３８３号公報

近年、複合機や融合機には様々なプログラムが実装される。そして、これらの機器ではこれらのプログラムをアップデートすべき場面も出て来る。機器の機能を拡張する場合やプログラムのバグを修正する場合などである。従来の複合機や融合機では、プログラムのアップデート処理は機器の起動時に実施されるのが通例であった。よって、プログラムをアップデートするには機器を再起動しなければならないという問題点があった。そして、機器の再起動を手動式にすれば、再起動操作をユーザに強制する事になりユーザに操作の負担を掛ける事になるし、だからと言って、機器の再起動を自動式にすれば、再起動処理がユーザの知らぬ間に実施される事になりユーザに心理的な抵抗感が生じる事になる。

本発明は、種々のプログラムが実装される画像形成装置に関して、画像形成装置に実装された種々のプログラムのアップデート処理（更新処理）に関する新たな手法を提案することを課題とする。

そこで上記課題を解決するため、本発明は、互いに排他的に動作する複数のモジュールの接続によって構成されるプログラムを実行する画像形成装置であって、前記プログラムの更新情報の入力を受け付ける入力手段と、前記プログラムの動作状態が、前記更新情報において指定されている更新のタイミングに相当するか否かを判定するタイミング判定手段と、前記タイミング判定手段によって前記更新のタイミングであると判定されたときに、前記更新情報に従って、前記複数のモジュールの接続関係を変更する変更手段とを有することを特徴とする。

このような画像形成装置によれば、種々のプログラムのアップデート処理（更新処理）に関する新たな手法を提案することができる。

本発明は、種々のプログラムが実装される画像形成装置に関して、画像形成装置に実装された種々のプログラムのアップデート処理（更新処理）に関する新たな手法を提案するものである。

図１は、本発明の実施例に該当する融合機１０１を表す。図１の融合機１０１は、種々のハードウェア１１１と、種々のソフトウェア１１２と、融合機起動部１１３により構成される。

融合機１０１のハードウェア１１１としては、撮像部１２１と、印刷部１２２と、その他のハードウェア１２３が存在する。撮像部１２１は、読取原稿から画像（画像データ）を読み取るためのハードウェアである。印刷部１２２は、画像（画像データ）を印刷用紙に印刷するためのハードウェアである。

融合機１０１のソフトウェア１１２としては、種々のアプリケーション１３１と、種々のプラットフォーム１３２が存在する。これらのプログラムは、ＵＮＩＸ（登録商標）等のＯＳ（オペレーティングシステム）によりプロセス単位で並列的に実行される。

アプリケーション１３１としては、コピー用のアプリケーションであるコピーアプリ１４１、プリンタ用のアプリケーションであるプリンタアプリ１４２、スキャナ用のアプリケーションであるスキャナアプリ１４３、ファクシミリ用のアプリケーションであるファクシミリアプリ１４４、ネットワークファイル用のアプリケーションであるネットワークファイルアプリ１４５が存在する。

アプリケーション１３１は、専用のＳＤＫ（ソフトウェア開発キット）を使用して開発することができる。ＳＤＫを使用して開発したアプリケーション１３１をＳＤＫアプリと呼ぶ。専用のＳＤＫとしては、Ｃ言語でアプリケーション１３１を開発するための「ＣＳＤＫ」や、Ｊａｖａ（登録商標）言語でアプリケーション１３１を開発するための「ＪＳＤＫ」が提供される。ＣＳＤＫを使用して開発したアプリケーション１３１を「ＣＳＤＫアプリ」と呼び、ＪＳＤＫを使用して開発したアプリケーション１３１を「ＪＳＤＫアプリ」と呼ぶ。図１の融合機１０１にも、ＣＳＤＫアプリ１４６と、ＪＳＤＫアプリ１４７が存在する。図１の融合機１０１にはさらに、Ｊａｖａ（登録商標）言語で記述されたＪＳＤＫアプリ１４７とＣ言語で記述された他のソフトウェア１１２との仲介を行うソフトウェア１１２として、ＪＳＤＫプラットフォーム１４８が存在する。

プラットフォーム１３２としては、種々のコントロールサービス１５１、システムリソースマネージャ１５２、種々のハンドラ１５３が存在する。コントロールサービス１５１としては、ネットワークコントロールサービス（ＮＣＳ）１６１、ファクシミリコントロールサービス（ＦＣＳ）１６２、デリバリコントロールサービス（ＤＣＳ）１６３、エンジンコントロールサービス（ＥＣＳ）１６４、メモリコントロールサービス（ＭＣＳ）１６５、オペレーションパネルコントロールサービス（ＯＣＳ）１６６、サーティフィケーションコントロールサービス（ＣＣＳ）１６７、ユーザディレクトリコントロールサービス（ＵＣＳ）１６８、システムコントロールサービス（ＳＣＳ）１６９が存在する。ハンドラ１５３としては、ファクシミリコントロールユニットハンドラ（ＦＣＵＨ）１７１、イメージメモリハンドラ（ＩＭＨ）１７２が存在する。

ＮＣＳ１６１のプロセスは、ネットワーク通信の仲介を行う。ＦＣＳ１６２のプロセスは、ファクシミリのＡＰＩを提供する。ＤＣＳ１６３のプロセスは、蓄積文書の配信処理に関する制御を行う。ＥＣＳ１６４のプロセスは、撮像部１２１や印刷部１２２に関する制御を行う。ＭＣＳ１６５のプロセスは、メモリやハードディスクドライブに関する制御を行う。ＯＣＳ１６６のプロセスは、オペレーションパネルに関する制御を行う。ＣＣＳ１６７のプロセスは、認証処理や課金処理に関する制御を行う。ＵＣＳ１６８のプロセスは、ユーザ情報の管理に関する制御を行う。ＳＣＳ１６９のプロセスは、システムの管理に関する制御を行う。

アプリケーション１３１とプラットフォーム１３２の仲介を行うソフトウェア１１２として、仮想アプリケーションサービス（ＶＡＳ）１３５が存在する。ＶＡＳ１３５は、アプリケーション１３１をクライアントとするサーバプロセスとして動作すると共に、プラットフォーム１３２をサーバとするクライアントプロセスとして動作する。ＶＡＳ１３５は、アプリケーション１３１から見てプラットフォーム１３２を隠蔽するラッピング機能を備え、プラットフォーム１３２のバージョンアップに伴うバージョン差を吸収する役割等を担う。

融合機起動部１１３は、融合機１０１の電源投入時に最初に実行される。これにより、ＵＮＩＸ（登録商標）等のＯＳが起動され、アプリケーション１３１やプラットフォーム１３２が起動される。これらのプログラムは、ハードディスクドライブやメモリカードに蓄積されており、ハードディスクドライブやメモリカードから再生されて、メモリに起動されることになる。

図２は、図１の融合機１０１に係るハードウェア構成図である。融合機１０１のハードウェア１１１としては、コントローラ２０１と、オペレーションパネル２０２と、ファクシミリコントロールユニット（ＦＣＵ）２０３と、撮像部１２１と、印刷部１２２が存在する。

コントローラ２０１は、ＣＰＵ２１１、ＡＳＩＣ２１２、ＮＢ２２１、ＳＢ２２２、ＭＥＭ−Ｐ２３１、ＭＥＭ−Ｃ２３２、ＨＤＤ（ハードディスクドライブ）２３３、メモリカードスロット２３４、ＮＩＣ（ネットワークインタフェースコントローラ）２４１、ＵＳＢデバイス２４２、ＩＥＥＥ１３９４デバイス２４３、セントロニクスデバイス２４４により構成される。

ＣＰＵ２１１は、種々の情報処理用のＩＣである。ＡＳＩＣ２１２は、種々の画像処理用のＩＣである。ＮＢ２２１は、コントローラ２０１のノースブリッジである。ＳＢ２２２は、コントローラ２０１のサウスブリッジである。ＭＥＭ−Ｐ２３１は、融合機１０１のシステムメモリである。ＭＥＭ−Ｃ２３２は、融合機１０１のローカルメモリである。ＨＤＤ２３３は、融合機１０１のストレージである。メモリカードスロット２３４は、メモリカード２３５をセットするためのスロットである。ＮＩＣ２４１は、ＭＡＣアドレスによるネットワーク通信用のコントローラである。ＵＳＢデバイス２４２は、ＵＳＢ規格の接続端子を提供するためのデバイスである。ＩＥＥＥ１３９４デバイス２４３は、ＩＥＥＥ１３９４規格の接続端子を提供するためのデバイスである。セントロニクスデバイス２４４は、セントロニクス仕様の接続端子を提供するためのデバイスである。

オペレーションパネル２０２は、オペレータが融合機１０１に入力を行うためのハードウェア（操作部）であると共に、オペレータが融合機１０１から出力を得るためのハードウェア（表示部）である。

図３は、図１の融合機１０１に係る外観図である。図３には、撮像部１２１の位置と、印刷部１２２の位置と、オペレーションパネル２０２の位置が図示されている。図３には更に、読取原稿のセット先となる原稿セット部３０１と、印刷用紙の給紙先となる給紙部３０２と、印刷用紙の排紙先となる排紙部３０３が図示されている。

オペレーションパネル２０２は、図４のように、タッチパネル３１１と、テンキー３１２と、スタートボタン３１３と、リセットボタン３１４と、機能キー３１５と、初期設定ボタン３１６により構成される。タッチパネル３１１は、タッチ操作で入力を行うためのハードウェア（タッチ操作部）であると共に、画面表示で出力を得るためのハードウェア（画面表示部）である。テンキー３１２は、キー（ボタン）操作で数字入力を行うためのハードウェアである。スタートボタン３１３は、ボタン操作でスタート操作を行うためのハードウェアである。リセットボタン３１４は、ボタン操作でリセット操作を行うためのハードウェアである。機能キー３１５は、キー（ボタン）操作でＣＳＤＫアプリ１４６やＪＳＤＫアプリ１４７による操作画面を表示させるためのハードウェアである。初期設定ボタン３１６は、ボタン操作で初期設定画面を表示させるためのハードウェアである。

原稿セット部３０１は、ＡＤＦ（自動原稿搬送装置）３２１と、フラットベッド３２２と、フラットベッドカバー３２３により構成される。給紙部３０２は、４個の給紙トレイにより構成される。排紙部３０３は、１個の排紙トレイにより構成される。

（ＣＳＤＫ／ＪＳＤＫ／ＯＳＧｉ）
図５は、図１のＣＳＤＫアプリ１４６とＪＳＤＫアプリ１４７のソフトウェア構成図である。ＣＳＤＫアプリ１４６は、Ｃ言語のアプリケーションであり、それぞれプロセスとして実行される事になる。ＪＳＤＫアプリ１４７は、Ｊａｖａ（登録商標）言語のアプリケーションであり、それぞれスレッドとして実行される事になる。

図１の融合機１０１には、ＣＳＤＫアプリ１４６として、他のＣＳＤＫアプリ１４６の制御を行うＳＡＳ（ＳＤＫアプリケーションサービス）４１１が存在し、ＪＳＤＫアプリ１４７として、他のＪＳＤＫアプリ１４７の制御を行うＳＡＳ Ｍａｎａｇｅｒ（ＳＤＫアプリケーションサービスマネージャ）５１１が存在する。ＣＳＤＫアプリ１４６の方はプロセスとして実行されてＪＳＤＫアプリ１４７の方はスレッドとして実行されるので、ＣＳＤＫアプリ１４６用のアプリケーション管理機構とＪＳＤＫアプリ１４７用のアプリケーション管理機構が別個に存在するのである。ＳＡＳ４１１とＳＡＳ Ｍａｎａｇｅｒ５１１はそれぞれ、ＣＳＤＫアプリ１４６とＪＳＤＫアプリ１４７の起動制御，起動解除制御，インストール制御，アンインストール制御，アップデート制御等を行う。

さて、ＳＡＳ４１１は、ＣＳＤＫアプリ１４６の制御を行う事ができるだけではなく、ＳＡＳ Ｍａｎａｇｅｒ５１１を介してＪＳＤＫアプリ１４７の制御を行う事もできる。ＳＡＳ４１１は、ＣＳＤＫアプリ１４６については直接的にその制御を行う事ができると共に、ＪＳＤＫアプリ１４７についてはＳＡＳ Ｍａｎａｇｅｒ５１１を介して間接的にその制御を行う事ができるのである。このように、ＣＳＤＫアプリ１４６用のアプリケーション管理機構とＪＳＤＫアプリ１４７用のアプリケーション管理機構は、ＳＡＳ Ｍａｎａｇｅｒ５１１を制御できる機能をＳＡＳ４１１に具備させると言う形で統合的に構成されている。融合機１０１のソフトウェアの根幹部分はＣ言語によるので、ＳＤＫアプリを制御する機能を同じくＣ言語によるＳＡＳ４１１に集中しておくのが好適なのである。

図６は、図１の融合機１０１におけるＯＳＧｉ（Ｏｐｅｎ Ｓｅｒｖｉｃｅ Ｇａｔｅｗａｙ ｉｎｉｔｉａｔｉｖｅ）サービスプラットフォームについて説明するための図である。ＯＳＧｉサービスプラットフォームは、ＯＳＧｉアライアンスによる標準化技術であり、Ｊａｖａ（登録商標）言語に基づいたオープンなソフトウェア部品化技術である。ＯＳＧｉサービスプラットフォームが実装された機器では、Ｊａｖａ（登録商標）言語のソフトウェアは「バンドル」と言うソフトウェア部品の形で実装される。そして、該機器の諸機能はバンドルをもって構成する事ができると共に、該機器の諸機能のアップデートやカスタマイズやメンテナンスはバンドルのダウンロードをもって実現する事ができる。

図１の融合機１０１には、Ｊａｖａ（登録商標）言語のソフトウェアとして、ＪＳＤＫアプリ１４７と、ＪＳＤＫプラットフォーム１４８と、ＯＳＧｉ用のアプリケーションであるＯＳＧｉアプリ４０１と、ＯＳＧｉ用のサービスであるＯＳＧｉサービス４０２と、バンドルの管理（バンドルのライフサイクルやデータの管理等）を行うＯＳＧｉフレームワーク４０３が存在する。

さて、ＯＳＧｉアプリ４０１とＪＳＤＫアプリ１４７に関して、ＯＳＧｉアプリ４０１はバンドル化された状態で融合機１０１に実装するものとするが、ＪＳＤＫアプリ１４７はバンドル化されていない状態で融合機１０１に実装するものとする。理由は、ＪＳＤＫアプリ１４７をバンドル化して実装する負担をＪＳＤＫアプリ１４７のベンダに課さないようにするためである。その代わり、ＪＳＤＫアプリ１４７をバンドル化する「Ｂｕｎｄｌｅ Ａｃｔｉｖａｔｏｒ４０４」がＪＳＤＫプラットフォーム１４８に存在している。そして、ＯＳＧｉフレームワーク４０３は、バンドル化された状態で融合機１０１に実装されたバンドル（ＯＳＧｉアプリ４０１）の管理を行うと共に、バンドル化されていない状態で融合機１０１に実装されて「Ｂｕｎｄｌｅ Ａｃｔｉｖａｔｏｒ４０４」によってバンドル化されるバンドル（ＪＳＤＫアプリ１４７）の管理を行う事になる。このようにして、ＯＳＧｉアプリ４０１用のアプリケーション管理機構とＪＳＤＫアプリ１４７用のアプリケーション管理機構は、ＯＳＧｉフレームワーク４０３とＢｕｎｄｌｅ Ａｃｔｉｖａｔｏｒ４０４を併設すると言う形で統合的に構成されているのである。これにより、Ｊａｖａ（登録商標）言語のアプリケーションの管理先の一元化が実現されている。

なお、ＯＳＧｉフレームワーク４０３は、当然の事ながら、ＯＳＧｉサービス４０２を構成するバンドルの管理や、ＪＳＤＫプラットフォーム１４８を構成するバンドルの管理も行う。Ｊａｖａ（登録商標）言語のソフトウェアの管理先の一元化が実現されていると言える。そして、ＯＳＧｉアプリ４０１はここではＳｅｒｖｌｅｔかＪＳＰであるものとする。そして、ＪＳＤＫアプリ１４７はここではＸｌｅｔであるものとする。

なお、ＪＳＤＫアプリ１４７についても、バンドル化された状態で実装するものとしてもよい。さらに、ＪＳＤＫアプリ１４７については、バンドル化された状態で実装してもバンドル化されていない状態で実装してもどちらでもよいものとしてもよい。バンドル化された状態で実装されるＪＳＤＫアプリ１４７については、Ｂｕｎｄｌｅ Ａｃｔｉｖａｔｏｒ４０４によるバンドル化は不要である。

（更新処理）
以下、バンドルとして管理されるＪａｖａ（登録商標）言語のソフトウェアの更新処理について説明する。先ず、図１の融合機１０１内のＪＳＤＫプラットフォーム（バンドルサービス）１４８の更新処理について説明して、次に、図１の融合機１０１内のＪＳＤＫアプリ（バンドルアプリ）１４７の更新処理について説明する。なお、当該融合機１０１内のＪＳＤＫプラットフォーム（バンドルサービス）１４８やＪＳＤＫアプリ（バンドルアプリ）１４７の更新処理は当該融合機１０１内のＳＡＳ Ｍａｎａｇｅｒ５１１により実行される。

図７は、バンドルサービス１４８のオブジェクト構成の具体例を表す。図７のバンドルサービス１４８は、４個のオブジェクト（モジュール）Ａ／Ｂ／Ｃ／Ｄにより構成されている。

さて、オブジェクトＡ／Ｂ／Ｃ／Ｄが相互に関連している場合には、バンドルサービス１４８の実行中（動作中）にオブジェクトＡをオブジェクトＡ'に入れ替える事は困難である。オブジェクトＡが提供するサービスをオブジェクトＢ／Ｃ／Ｄが利用すべく、オブジェクトＡをオブジェクトＢ／Ｃ／Ｄが参照している可能性があるからである。よって、オブジェクトＡをオブジェクトＡ'に入れ替える場合には、オブジェクトＡを入れ替える旨をオブジェクトＢ／Ｃ／Ｄに通知し、オブジェクトＢ／Ｃ／ＤがオブジェクトＡの参照をオブジェクトＡ'の参照に切り替える必要がある。したがって、オブジェクトＡをオブジェクトＡ'に入れ替えるなど、バンドルサービス１４８の更新処理をバンドルサービス１４８の動作中にバンドルサービス１４８のモジュール毎に実行するには、従来は融合機１０１の再起動処理が必要だった。

しかしながら、融合機１０１は、バンドルサービス１４８の更新処理をバンドルサービス１４８の動作中にバンドルサービス１４８のモジュール毎に実行するのに、融合機１０１の再起動処理を伴わずに実行する。よって、バンドルサービス１４８の更新処理を実施するのに、融合機１０１の再起動操作をユーザに強制する事もなくなるし、融合機１０１の再起動処理がユーザの知らぬ間に実施される事もなくなるのである。

すなわち、融合機１０１は、バンドルサービス１４８の更新処理をバンドルサービス１４８の更新部分のオブジェクトがアクティブ状態ではないとき（動作中でないとき）に実行する。これによって、融合機１０１は、再起動処理を伴わずに、バンドルサービス１４８の更新処理をバンドルサービス１４８の動作中にバンドルサービス１４８のモジュール毎に実行する事ができる。

以下、バンドルサービス１４８の更新処理の具体例として、バンドルサービス「ＦａｘＴｘ１」がバンドルサービス「ＦａｘＴｘ２」に更新される様子について説明する。バンドルサービス「ＦａｘＴｘ１」は、画像データをＦＡＸ送信するサービスを提供するバンドルサービス１４８である。「ＦａｘＴｘ２」は、画像データをＰＤＦからＴＩＦＦに変換してＦＡＸ送信するサービスを提供するバンドルサービス１４８である。

図８はバンドルサービス「ＦａｘＴｘ１」の状態遷移図である。ＦａｘＴｘ１の状態としては、初期状態６０１、終期状態６０２、Ｉｄｌｅ状態６０３、Ｓｅｎｄ状態６０４が存在する。Ｉｄｌｅ状態６０３は、ＦＡＸ送信処理の待機中の状態である。Ｓｅｎｄ状態６０４は、ＦＡＸ送信処理を実行中の状態である。Ｉｄｌｅ状態６０３からＳｅｎｄ状態６０４には、送信開始イベント６１１により遷移する。Ｓｅｎｄ状態６０４から終期状態６０２には、送信終了イベント６１２により遷移する。

図９はバンドルサービス「ＦａｘＴｘ２」の状態遷移図である。ＦａｘＴｘ２の状態としては、初期状態６０１、終期状態６０２、Ｉｄｌｅ状態６０３、Ｓｅｎｄ状態６０４に加えて、Ｔｒａｎｓｆｏｒｍ状態６０５が存在する。Ｔｒａｎｓｆｏｒｍ状態６０５は、ＰＤＦからＴＩＦＦへの変換処理を実行中の状態である。Ｉｄｌｅ状態６０３からＴｒａｎｓｆｏｒｍ状態６０５には、送信開始イベント６１１により遷移する。Ｔｒａｎｓｆｏｒｍ状態６０５からＳｅｎｄ状態６０４には、変換終了イベント６１３により遷移する。

状態遷移図に基づいて、本実施の形態におけるバンドルサービス１４８は、図１０に示されるようなクラス群によってモデル化されている。図１０は、バンドルサービスを構成するクラス図の一例である。

図１０において、ＳｔａｔｅＭａｃｈｉｎｅクラス１００１は、一つのバンドルサービス１４８を表現するクラスである。すなわち、バンドルサービス「ＦａｘＴｘ１」や「ＦａｘＴｘ２」を表現するオブジェクトは、ＳａｔｅＭａｃｈｉｎｅクラス１００１のインスタンス（ＳｔａｔｅＭａｃｈｉｎｅオブジェクト）として生成される。ＳｔａｔｅＶｅｒｔｅｘクラス１００２は、抽象クラスであり、状態遷移図において状態を表現するクラスのルートクラスに相当する。ＳｔａｔｅＶｅｒｔｅｘクラス１００２は、ｃｏｎｎｅｃｔメソッド１００２ａや、ｒｅｃｏｎｎｅｃｔメソッド１００２ｂ等のメソッドが定義されている。ｃｏｎｎｅｃｔメソッド１００２ａは、遷移先の状態及びその状態遷移との接続を実行するメソッドである。状態遷移についてはＴｒａｎｓｉｔクラス１００３によって表現される。したがって、より具体的には、ｃｏｎｎｅｃｔメソッド１００２ａは、遷移先のＳｔａｔｅＶｅｒｔｅｘオブジェクト（厳密にはそのサブクラスのオブジェクト。以下、総称する場合「状態オブジェクト」という。）と、その状態遷移に対応するＴｒａｎｓｉｔオブジェクト（以下、「遷移オブジェクト」という。）との接続を実行するクラスである。ここでいう接続は、例えば、状態オブジェクト内に、遷移先の状態オブジェクトや、その遷移オブジェクトの識別情報（ＩＤ、参照、又はポインタ等）を保持することで実現される。ｒｅｃｏｎｎｅｃｔメソッド１００２ｂは、遷移先の変更を実行するメソッドである。なお、Ｔｒａｓｉｔクラス１００３には、インタフェースとしてＥｖｅｎｔインタフェース１００３ａ、Ｇｕｒａｄインタフェース１００３ｂ、及びＡｃｔｉｏｎインタフェース１００３ｃ等が定義されている。Ｅｖｅｎｔインタフェース１００３ａは、状態遷移の遷移イベントを実装するインタフェースである。Ｇｕａｒｄインタフェース１００３ｂは、ガード条件を実装するインタフェースである。Ａｃｔｉｏｎインタフェース１００３ｃは、状態遷移時に実行するアクションを実装するインタフェースである。

ＳｔａｔｅＶｅｒｔｅｘクラス１００２のサブクラスとしては、Ｓｔａｔｅクラス１００４及びＰｓｅｕｄｏＳｔａｔｅクラス１００５が定義されている。Ｓｔａｔｅクラス１００４は、例えば、バンドルサービス１４８に応じて定義される状態を表現するクラスである。Ｓｔａｔｅクラス１００４には、インタフェースとしてＩＳｔａｔｅインタフェース１００４ａ及びＡｃｔｉｖｉｔｙインタフェース１００４ｂ等が定義されている。ＩＳｔａｔｅインタフェース１００４ａは、状態の入場時の処理（入場処理）及び退場時の処理（退場処理）を実装するインタフェースである。Ａｃｔｉｖｉｔｙインタフェース１００４ｂは、状態にある間実行する処理を実装するインタフェースである。これらインタフェースは、クラスとして実装される。したがって、例えば、Ａｃｔｉｖｉｔｙインタフェース１００４ｂの処理は、Ａｃｔｉｖｉｔｙクラスに実装される。

ＰｓｅｕｄｏＳａｔｅクラス１００５は、初期状態や終期状態等、その名の通り擬似的な状態を表現するクラスであり、そのサブクラスとしては初期状態を表現するＩｎｉｔｉａｌＳｔａｔｅクラス１００６及び終期状態を表現するＦｉｎａｌＳｔａｔｅクラス１００７等がある。

上記クラス間の関係について説明する。ＳｔａｔｅＭａｃｈｉｎｅクラス１００１は、ＳｔａｔｅＶｅｒｔｅｘクラス１００２を集約する。これは、一つのバンドルサービスは、一つ以上の状態を有することを表現したものである。ＳｔａｔｅＶｅｒｔｅｘクラス１００２は、Ｔｒａｎｓｉｔクラスを集約する。これは、状態と状態との間は遷移によって接続されることを表現したものである。

以上のような、モデルに基づいて、バンドルサービス「ＦａｘＴｘ１」及び「ＦａｘＴｘ２」は、以下のようなオブジェクトによって構成される。

図１１はバンドルサービス「ＦａｘＴｘ１」のオブジェクト構成を表す。ＦａｘＴｘ１は、図８の状態遷移図に基づいて、初期状態オブジェクト７０１、終期状態オブジェクト７０２、Ｉｄｌｅ状態オブジェクト７０３、Ｓｅｎｄ状態オブジェクト７０４、送信開始オブジェクト７１１Ｔ、送信処理オブジェクト７１２Ａにより構成されている。

また、図１２はバンドルサービス「ＦａｘＴｘ２」のオブジェクト構成を表す。ＦａｘＴｘ２は、図９の状態遷移図に基づいて、初期状態オブジェクト７０１、終期状態オブジェクト７０２、Ｉｄｌｅ状態オブジェクト７０３、Ｓｅｎｄ状態オブジェクト７０４、Ｔｒａｎｓｆｏｒｍ状態オブジェクト７０５、送信開始オブジェクト７１１Ｔ、送信処理オブジェクト７１２Ａ、変換処理オブジェクト７１３Ａ、変換終了オブジェクト７１３Ｔにより構成されている。

図１１及び図１２においてオブジェクト同士を連結する線分は、オブジェクト同士の参照関係を表す。遷移元の状態オブジェクトは遷移先の状態オブジェクトを参照している。なお、図中では状態オブジェクト間に遷移オブジェクトが接続されている場合がある。例えば、Ｉｄｌｅ状態オブジェクト７０３とＳｅｎｄ状態オブジェクト７０４との間には送信開始オブジェクト７１１Ｔが接続されている。しかし、このことはＩｄｌｅ状態７０３が、Ｓｅｎｄ状態オブジェクト７０４を参照していないことを示すものではない。Ｉｄｌｅ状態オブジェクト７０３は、Ｓｅｎｄ状態オブジェクト７０３を参照すると共に、その状態遷移に対応する遷移オブジェクトとして送信開始オブジェクト７１１Ｔをも参照することを表現したものである。

図１１及び図１２より、バンドルサービス「ＦａｘＴｘ１」から「ＦａｘＴｘ２」への更新処理とは、ＦａｘＴｘ１に「Ｔｒａｎｓｆｏｒｍ状態オブジェクト７０５」や「変換処理オブジェクト７１３Ａ」や「変換終了オブジェクト７１３Ｔ」と言った更新処理用のオブジェクトをＦａｘＴｘ１に対して追加する事で実現できることが分かる。

バンドルサービス１４８の更新処理の影響が顕著なオブジェクトが、バンドルサービス１４８の更新部分のオブジェクトである。バンドルサービス１４８の更新部分のオブジェクトとは、オブジェクトの入替部分やオブジェクトの追加部分（バンドルサービス１４８の更新部分）に連結するオブジェクトを意味する。図１１から図１２への更新処理では、バンドルサービス１４８の更新部分に相当するのがスイッチ７２１等の追加部分であり、バンドルサービス１４８の更新部分のオブジェクトに相当するのがＳｅｎｄ状態オブジェクト７０４や送信開始オブジェクト７１１Ｔである。

オブジェクトの状態は、サービスの授受を行う「アクティブ状態」とサービスの授受を行わない「非アクティブ状態」に分類される。バンドルサービス１４８の更新処理をバンドルサービス１４８の動作中に実行するには、バンドルサービス１４８の更新部分のオブジェクトがアクティブ状態ではないとき（非アクティブ状態のとき）に実行すればよい。バンドルサービス１４８の動作中のオブジェクト同士のサービスの授受が更新処理により阻害されずに済むからである。よって、バンドルサービス１４８の更新処理をバンドルサービス１４８の更新部分のオブジェクトがアクティブ状態ではないときに実行するのである。なお、状態遷移図によるモデリングでは、一のオブジェクトがアクティブ状態のときは他のオブジェクトは非アクティブ状態に限定される。すなわち、各オブジェクトは互いに排他的に処理を実行する（動作する）。

図１３は、バンドルサービス１４８の更新処理に係るコラボレーション図である。同図の更新処理は、バンドルサービス「ＦａｘＴｘ１」をバンドルサービス「ＦａｘＴｘ２」に更新するものである。

ＦａｘＴｘ１をＦａｘＴｘ２に更新する旨の更新操作が融合機１０１又はクライアント端末８０１の操作画面で実施されると、ＦａｘＴｘ１をＦａｘＴｘ２に更新する旨の更新要求がＳＡＳ４１１からＳＡＳ Ｍａｎａｇｅｒ５１１に送信（Ｓ１１）される。次に、ＳＡＳ Ｍａｎａｇｅｒ５１１では、ＦａｘＴｘ１からＦａｘＴｘ２への更新処理を実施可能かどうかのチェックが実行（Ｓ１２）される。次に、ＳＡＳ Ｍａｎａｇｅｒ５１１では、更新処理用のモジュールを融合機１０１にインストール可能かどうかのチェックが実行（Ｓ１３）される。

続いて、ＳＡＳ Ｍａｎａｇｅｒ５１１は、更新処理用のモジュールを融合機１０１にインストール（Ｓ１４）する。続いて、ＳＡＳ Ｍａｎａｇｅｒ５１１は、更新処理用のモジュールをアクティブ状態に遷移（Ｓ１５）させる。続いて、ＳＡＳ Ｍａｎａｇｅｒ５１１は、ＦａｘＴｘ１に更新処理用のモジュールを追加して、スイッチ７２１をＦａｘＴｘ１側からＦａｘＴｘ２側に切り替えて、ＦａｘＴｘ２を生成（Ｓ１６）する。

なお、更新処理が行われるタイミングは、更新処理用のモジュールに同梱されているＡｓｐｅｃｔＳＭ８１１と言うＸＭＬファイルに記述されている。また、ＦａｘＴｘ１やＦａｘＴｘ２とＪＳＤＫアプリ１４７との仲介制御は、ＪＳＤＫプラットフォーム１４８を構成するＰｒｏｘｙ Ｓｅｒｖｉｃｅ８２２が実行する。

ＦａｘＴｘ１からＦａｘＴｘ２への更新処理について更に詳しく説明する。更新処処理自体の詳細説明の前に、図１１に示されるＦａｘＴｘ１のオブジェクト構成が構築される過程について説明する。

図１４は、バンドルサービス「ＦａｘＴｘ１」のオブジェクト構成の構築処理を説明するためのシーケンス図である。図１４の処理は、ＦａｘＴｘ１オブジェクト８３１がインスタンス化された際に実行される。

ＦａｘＴｘ１オブジェクト８３１は、インスタンス化されると、バンドルサービス「ＦａｘＴｘ１」の状態遷移情報に基づいて当該状態遷移に対応したオブジェクト構成を構築する（１０１）。状態遷移情報は、例えば、融合機１０１の所定の記憶装置内に、以下の形式で保存されている。

図１５及び図１６は、バンドルサービス「ＦａｘＴｘ１」の状態遷移情報の定義例を示す図である。図１５及び図１６によって一つの状態遷移情報９００の記述例が示されている。状態遷移情報９００は、ＸＭＩ（XML Metadata Interchange）に従った記述例が示されている。ＸＭＩは、モデルを各種のソフトウェアの間でＸＭＬ文書によって交換することを目的とした標準規格である。但し、本実施の形態を実施するにあたり、状態遷移情報は、必ずしもＸＭＩに従って記述される必要はない。なお、図中における行番号は、説明の便宜上付加したものである。

状態遷移情報９００の１２１行目における＜ＳｔａｔｅＭａｃｈｉｎｅ＞タグのタグ名、及びそのｎａｍｅ属性の値（「ＦａｘＴｘ１」）によって、状態遷移情報９００は、バンドルサービス「ＦａｘＴｘ１」に対応するものであることが定義されている。また、当該＜ＳｔａｔｅＭａｃｈｉｎｅ＞タグにおけるｘｍｉ．ｉｄ属性の値（「００４」）は、バンドルサービス「ＦａｘＴｘ１」を識別するＩＤである。

１２５行目の＜ＣｏｍｐｏｓｉｔｅＳｔａｔｅ＞タグは、バンドルサービス「ＦａｘＴｘ１」における状態の定義の開始の宣言に相当する。当該宣言は、＜ＣｏｍｐｏｓｉｔｅＳｔａｔｅ＞タグのｘｍｉ．ｉｄの値（「０１７」）によって識別される。

１３０行目から１３７行目における＜Ｐｓｅｕｄｏｓｔａｔｅ＞タグによって囲まれたＰｓｅｕｄｏｓｔａｔｅ要素９１０は、初期状態６０１に対する定義である。Ｐｓｅｕｄｏｓｔａｔｅ要素９１０のｎａｍｅ属性の値には「Ｉｎｉｔ」が設定され、ｘｍｉ．ｉｄ要素の値には、「０１８」が設定されている。

１３８行目から１４８行目におけるＣｏｍｐｏｓｉｔｅＳｔａｔｅ要素９２０は、Ｓｅｎｄ状態６０４に対する定義である。ＣｏｍｐｏｓｉｔｅＳｔａｔｅ要素９２０のｎａｍｅ属性の値には「Ｓｅｎｄ」が設定され、ｘｍｉ．ｉｄ要素の値には、「０１９」が設定されている。

１４９行目から１５９行目におけるＣｏｍｐｏｓｉｔｅＳｔａｔｅ要素９３０は、Ｉｄｌｅ状態６０３に対する定義である。ＣｏｍｐｏｓｉｔｅＳｔａｔｅ要素９３０のｎａｍｅ属性の値には「Ｉｄｌｅ」が設定され、ｘｍｉ．ｉｄ要素の値には、「０２２」が設定されている。

１６０行目から１８３行目におけるＰｓｅｕｄｏｓｔａｔｅ要素９４０は、終期状態６０２に対する定義である。Ｐｓｅｕｄｏｓｔａｔｅ要素９４０のｎａｍｅ属性の値には「ｅｎｄ」が設定され、ｘｍｉ．ｉｄ要素の値には、「０２４」が設定されている。

また、１９１行目から２２８行目には、バンドルサービス「ＦａｘＴｘ１」における各状態遷移が定義されている。すなわち、１９１行目から２０４行目におけるＴｒａｎｓｉｔｉｏｎ要素９５０は、Ｉｄｌｅ状態６０３からＳｅｎｄ状態６０４への状態遷移に対する定義である。Ｔｒａｎｓｉｔｉｏｎ要素９５０が当該状態遷移に対する定義であることは、Ｔｒａｎｓｉｔｉｏｎ要素９５０の子要素として定義されている、Ｔｒａｎｓｉｔｉｏｎ．ｓｏｕｒｃｅ要素９５１及びＴｒａｎｓｉｔｉｏｎ．ｔａｒｇｅｔ要素９５２より特定される。Ｔｒａｎｓｉｔｉｏｎ．ｓｏｕｒｃｅ要素９５１は遷移元の状態が設定される要素である。Ｔｒａｎｓｉｔｉｏｎ．ｓｏｕｒｃｅ要素９５１の子要素のｘｍｉ．ｉｄｒｅｆ属性の値は「０２２」である。したがって、遷移元は、ｘｍｉ．ｉｄ属性の値が「０２２」の状態、すなわち、Ｉｄｌｅ状態６０３であることが分かる。また、Ｔｒａｎｓｉｔｉｏｎ．ｔａｒｇｅｔ要素９５２は遷移先の状態が設定される要素である。Ｔｒａｎｓｉｔｉｏｎ．ｔａｒｇｅｔ要素９５２の子要素のｘｍｉ．ｉｄｒｅｆ属性の値は「０１９」である。したがって、遷移先は、ｘｍｉ．ｉｄの値が「０１９」の状態、すなわち、Ｓｅｎｄ状態６０４であることが分かる。なお、Ｔｒａｎｓｉｔｉｏｎ要素９５０のｎａｍｅ属性の値は「送信開始」であり、ｘｍｉ．ｉｄ属性の値は「０２３」である。

２０５行目から２１８行目におけるＴｒａｎｓｉｔｉｏｎ要素９６０は、Ｓｅｎｄ状態６０４から終期状態６０２への状態遷移に対する定義である。Ｔｒａｎｓｉｔｉｏｎ要素９６０が当該状態遷移に対する定義であることは、Ｔｒａｎｓｉｔｉｏｎ．ｓｏｕｒｃｅ要素９６１内のｘｍｉ．ｉｄｒｅｆ属性の値が「０１９」（Ｓｅｎｄ状態６０４）であり、Ｔｒａｎｓｉｔｉｏｎ．ｔａｒｇｅｔ要素９６２内のｘｍｉ．ｉｄｒｅｆ属性の値が「０２４」（終期状態６０２）であることから特定される。なお、Ｔｒａｎｓｉｔｉｏｎ要素９６０のｎａｍｅ属性の値は「送信終了」であり、ｘｍｉ．ｉｄ属性の値は「０２０」である。

２１９行目から２２８行目におけるＴｒａｎｓｉｔｉｏｎ要素９７０は、初期状態６０１からＩｄｌｅ状態６０３への状態遷移に対する定義である。Ｔｒａｎｓｉｔｉｏｎ要素９７０が当該状態遷移に対する定義であることは、Ｔｒａｎｓｉｔｉｏｎ．ｓｏｕｒｃｅ要素９７１内のｘｍｉ．ｉｄｒｅｆ属性の値が「０１８」（初期状態６０１）であり、Ｔｒａｎｓｉｔｉｏｎ．ｔａｒｇｅｔ要素９７２内のｘｍｉ．ｉｄｒｅｆ属性の値が「０２２」（Ｉｄｌｅ状態６０３）であることから特定される。なお、Ｔｒａｎｓｉｔｉｏｎ要素９７０のｘｍｉ．ｉｄ属性の値は「０１８」である。

１３０行目以降の説明に戻る。各状態に対応する、Ｐｓｅｕｄｏｓｔａｔｅ要素９１０、ＣｏｍｐｏｓｉｔｅＳｔａｔｅ要素９２０、及びＣｏｍｐｏｓｉｔｅＳｔａｔｅ要素９３０は、ＳｔａｔｅＶｅｒｔｅｘ．ｏｕｔｇｏｉｎｇ要素及びＳｔａｔｅＶｅｒｔｅｘ．ｉｎｃｏｍｉｎｇ要素の少なくともいずれか一方を子要素として有する。ＳｔａｔｅＶｅｒｔｅｘ．ｏｕｔｇｏｉｎｇ要素は、遷移元からの状態遷移に対する接続が定義される要素である。ＳｔａｔｅＶｅｒｔｅｘ．ｉｎｃｏｍｉｎｇ要素は、遷移先への状態遷移に対する接続が定義される要素である。

例えば、初期状態６０１に対応するＰｓｅｕｄｏｓｔａｔｅ要素９１０におけるＳｔａｔｅＶｅｒｔｅｘ．ｏｕｔｇｏｉｎｇ要素９１１において、その子要素のｘｍｉ．ｉｄｒｅｆ属性の値は「０１８」である。したがって、初期状態６０１からの遷移先への状態遷移は、Ｔｒａｎｓｉｔｉｏｎ要素９７０が対応する状態遷移に相当することが分かる。

また、Ｓｅｎｄ状態６０４に対応するＣｏｍｐｏｓｉｔｅＳｔａｔｅ要素９２０おけるＳｔａｔｅＶｅｒｔｅｘ．ｏｕｔｇｏｉｎｇ要素９２１においてその子要素のｘｍｉ．ｉｄｒｅｆ属性の値は「０２０」であり、ＳｔａｔｅＶｅｒｔｅｘ．ｉｎｃｏｍｉｎｇ要素９２２において、その子要素のｘｍｉ．ｉｄｒｅｆ属性の値は「０２３」である。したがって、Ｓｅｎｄ状態６０４からの遷移先への状態遷移は、Ｔｒａｎｓｉｔｉｏｎ要素９６０が対応する状態遷移に相当し、遷移元の状態遷移は、Ｔｒａｎｓｉｔｉｏｎ要素９５０が対応する状態遷移に相当することが分かる。

なお、Ｉｄｌｅ状態６０３に対応するＣｏｍｐｏｓｉｔｅＳｔａｔｅ要素９３０、終期状態６０２に対応するＰｓｅｕｄｏｓｔａｔｅ要素９４０においても同様に状態遷移との接続が定義されている。

上記のような状態遷移情報９００に基づいて、ＦａｘＴｘ１オブジェクト８３１は、まず、各状態オブジェクト及び遷移オブジェクト等をインスタンス化する。図中では、状態遷移情報９００におけるＰｓｅｕｄｏｓｔａｔｅ要素９１０、ＣｏｍｐｏｓｉｔｅＳｔａｔｅ要素９３０、ＣｏｍｐｏｓｉｔｅＳｔａｔｅ要素９４０、Ｐｓｅｕｄｏｓｔａｔｅ要素９４０、及びＴｒａｎｓｉｔｉｏｎ要素９５０のそれぞれに基づいて、初期状態オブジェクト７０１、Ｉｄｌｅ状態オブジェクト７０３、Ｓｅｎｄ状態オブジェクト７０４、終期状態オブジェクト７０２、送信開始オブジェクト７１１Ｔが生成されている例が示されている（Ｓ１０２〜Ｓ１０６）。

続いて、ＦａｘＴｘ１オブジェクト８３１は、各状態オブジェクトの参照関係が状態遷移情報９００に定義された状態遷移の順になるよう、遷移元の状態オブジェクトに対して遷移先の状態オブジェクトを接続する。例えば、ＦａｘＴｘ１オブジェクト８３１は、Ｉｄｌｅ状態オブジェクト７０３の識別情報を引数として、初期状態オブジェクト７０１のｃｏｎｎｅｃｔ（）メソッドを呼び出す（Ｓ１０７）。また、ＦａｘＴｘ１オブジェクト８３１は、Ｓｅｎｄ状態オブジェクト７０４の識別情報を引数として、Ｉｄｌｅ状態オブジェクト７０３のｃｏｎｎｅｃｔ（）メソッドを呼び出す（Ｓ１０８）。また、ＦａｘＴｘ１オブジェクト８３１は、終期状態オブジェクト７０２の識別情報を引数として、Ｓｅｎｄ状態オブジェクト７０４のｃｏｎｎｅｃｔ（）メソッドを呼び出す（Ｓ１０９）。ｃｏｎｎｅｃｔ（）メソッドを呼び出された各状態オブジェクトは、当該状態オブジェクト内において引数に指定された識別情報を保持する。

また、必要に応じて、ｃｏｎｎｅｃｔ（）メソッドの引数には遷移オブジェクトの識別情報も指定される。例えば、ステップＳ１０８において、Ｉｄｌｅ状態オブジェクト７０３のｃｏｎｎｅｃｔ（）メソッドが呼び出される際は、送信開始オブジェクト７１１Ｔの識別情報も引数に指定される。このように、ｃｏｎｎｅｃｔ（）メソッドの引数に、状態オブジェクトと遷移オブジェクトとのそれぞれの識別情報が指定された場合、当該メソッドが呼び出された状態オブジェクトは、その状態オブジェクトの識別情報と遷移オブジェクトの識別情報とを関連付けて（ペアで）保持する。これによって、ある状態オブジェクトがアクティブのときに、あるイベントが発生したときの遷移先の状態オブジェクトが特定され得る。

以上の処理によって、バンドルサービス「ＦａｘＴｘ１」について、図１１に示されるようなオブジェクト構成が構築される。

上記をふまえて、バンドルサービス「ＦａｘＴｘ１」の「ＦａｘＴｘ２」への更新処理の詳細について説明する。図１７は、ＦａｘＴｘ１からＦａｘＴｘ２への更新処理を説明するためのシーケンス図である。

例えば、管理者は、ＦａｘＴｘ２とＦａｘＴｘ１との差分の追加モジュールが格納されたＳＤカードを融合機１０１のメモリカードスロット２３４に挿入する（Ｓ２０１）。

図１８は、ＳＤカード内の追加モジュールの構成例を示す図である。図１８に示されるＳＤカード２３５ａには、更新差分サービスバンドル８４０とＡｓｐｅｃｔＳＭ．ｘｍｌファイル８１１（ＡｓｐｅｃｔＳＭ８１１）とが格納されている。更新差分サービスバンドル８４０には、更新処理を実行するにあたり、図１０のクラス図において、ＩＳｔａｔｅインタフェース１００４ａ、Ａｃｔｉｖｉｔｙインタフェース１００４ｂ、Ｅｖｅｎｔインタフェース１００３ａ、Ｇｕａｒｄインタフェース１００３ｂ、又はＡｃｔｉｏｎインタフェース１００３ｃに対応するクラスのうち、追加が必要とされるクラスが実装された機能モジュール（例えば、Ｊａｖａ（登録商標）のクラスファイル。以下「追加モジュール」という。））が格納されている。ここでは、追加モジュールとして、ＰＤＦ２Ｔｉｆｆ８４１とＣｏｎｖｅｒｔＥｎｄ８４２とが格納されている。

ＡｓｐｅｃｔＳＭ８１１は、ＦａｘＴｘ１からＦａｘＴｘ２への更新処理をどのように実施するかについての仕様がＸＭＬ形式記述されているファイルである。

図１９は、ＡｓｐｅｃｔＳＭの記述例を示す図である。図中、行番号は説明の便宜上付加したものである。ＡｓｐｅｃｔＳＭ８１１には、バンドルサービス「ＦａｘＴｘ１」の状態遷移情報９００（図１５及び図１６）に対する変更内容が記述されている。

ＡｘｐｅｃｔＳＭ８１１の記述例において、２行目は、ｘｍｉ．ｉｄの値が「００４」であるＦａｘＴｘ１に対して状態遷移の変更を行うことを指示している。すなわち、２行目におけるｘｍｉ．ｉｄｒｅｆ属性は、変更の対象となるバンドルサービスのｘｍｉ．ｉｄが指定される。

３行目から２０行目までは一つ目の変更箇所に関する変更情報が記述されている。３行目には、変更箇所と変更タイミングが指定されている。変更箇所は、ｐｏｉｎｔｃｕｔ．＜ｘｘｘ＞における＜ｘｘｘ＞の記述とｘｍｉ．ｒｅｆ属性の値とによって指定される。ここで、＜ｘｘｘ＞の部分は「ＣｏｍｐｏｓｉｔｅＳｔａｔｅ」であり、ｘｍｉ．ｒｅｆ属性の値は「０１７」である。したがって、状態遷移情報９００の１２５行目における＜ＣｏｍｐｏｓｉｔｅＳｔａｔｅ＞タグ内に対する変更が指定されていることになる。また、変更のタイミングは、ｔｉｍｉｎｇ属性の値によって指定される。ここでは、「Ｉｄｌｅ」が指定されている。したがって、ＦａｘＴｘ１がＩｄｌｅ状態６０３にあるときに、変更を行うべきことが指定されている。

４行目には、変更の内容が指定されている。すなわち、＜ａｄｖｉｃｅ．ＣｏｍｐｏｓｉｔｅＳｔａｔｅ＞タグのタグ名におけるａｄｖｉｃｅ．以降によって、変更の対象がＣｏｍｐｏｓｉｔｅＳｔａｔｅ要素であることが指定されている。また、ｔｙｐｅ属性によって、変更の種別が「ｉｎｓｅｒｔ」（挿入）であることが指定されている。すなわち、３行目及び４行目によって、＜ＣｏｍｐｏｓｉｔｅＳｔａｔｅ＞タグ内に新たなＣｏｍｐｏｓｉｔｅＳｔａｔｅ要素を挿入すべき旨が指定されている。

５行目から１８行目は、挿入の対象となるＣｏｍｐｏｓｉｔｅＳｔａｔｅ要素８５０の定義である。ＣｏｍｐｏｓｉｔｅＳｔａｔｅ要素８５０は、ＦａｘＴｘ２のＴｒａｎｓｆｏｒｍ状態６０５に対応する。ＣｏｍｐｏｓｉｔｅＳｔａｔｅ要素８５０内の記述形式は、図１５及び図１６において説明した通りである。すなわち、ＣｏｍｐｏｓｉｔｅＳｔａｔｅ要素８５０の子要素である、ＳｔａｔｅＶｅｒｔｅｘ．ｏｕｔｇｏｉｎｇ要素８５１において遷移先への接続が定義され、ＳｔａｔｅＶｅｒｔｅｘ．ｉｎｃｏｍｉｎｇ要素８５２において遷移元への接続が定義されている。

ところで、ＣｏｍｐｏｓｉｔｅＳｔａｔｅ要素８５０は、Ｓｔａｔｅ．ｅｎｔｒｙ要素８５３が子要素として定義されている。Ｓｔａｔｅ．ｅｎｔｒｙ要素８５３は、ＣｏｍｐｏｓｉｔｅＳｔａｔｅ要素８５０が対応するＴｒａｎｓｆｏｒｍ状態６０５における入場処理が定義される要素である。すなわち、ＣｏｍｐｏｓｉｔｅＳｔａｔｅ要素８５０の子要素として、Ａｃｔｉｏｎ要素８５４が定義されているが、そのｘｍｉ．ｉｄ属性とｎａｍｅ属性より、ｘｍｉ．ｉｄ属性の値が「０２６」であり、ｎａｍｅ属性の値がｐｄｆ２ｔｉｆｆによって識別される処理が実行されることが指定されている。

２１行目から４２行目までは二つ目の変更箇所に関する変更情報が指定されている。２１行目には、変更箇所及び変更のタイミングが指定されている。ここでは、Ｉｄｌｅ状態６０３のときにＴｒａｎｓｉｔｉｏｎ要素９５０（図１６参照）に対して変更を行うことが指定されている。

二つ目の変更箇所には、二つの変更が指定されている。２２行目から２４行目までに一つ目の変更が指定されており、２５行目から４１行目までに二つ目の変更が指定されている。

一つ目の変更については、２２行目の＜ａｄｖｉｃｅ．Ｔｒａｎｓｉｔｉｏｎ．ｔａｒｇｅｔ＞タグのタグ名におけるａｄｏｖｉｃｅ．以降によって変更対象がＴｒａｎｓｉｔｉｏｎ．ｔａｒｇｅｔ要素９５２であることが指定されている。また、ｔｙｐｅ属性によって、変更の種別が修正（ｍｏｄｉｆｙ）であることが指定されている。２３行目には、変更の対象に関して修正後の定義が記述されている。すなわち、一つ目の変更は、Ｉｄｌｅ状態６０３からＳｅｎｄ状態６０４への状態遷移を、Ｉｄｌｅ状態６０３からＴｒａｎｓｆｏｒｍ状態６０５への状態遷移に修正することである。

二つ目の変更（２５行目から４１行目）は、新たな状態遷移（Ｔｒａｎｆｏｒｍ状態６０５からＳｅｎｄ状態６０４への状態遷移）に対応するＴｒａｎｓｉｓｉｏｎ要素の挿入をＩｄｌｅ状態６０３のときに行うことである。この内容は、上記の説明から読み取れるため、各行毎の説明は省略する。

４３行目から５５行目は、標準ではなく独自の書式に基づく定義が行われている拡張記述部分である。４３行目のｐｏｉｎｔｃｕｔ．以下の「ＸＭＩ．ｅｘｔｅｎｓｉｏｎ」によって、拡張記述部分であることが指定されている。本実施の形態では、この部分に、状態遷移処理で呼ばれるアクション処理と、イベント処理等に使用する機能モジュール（例えば、Ｊａｖａ（登録商標）クラス）との関連付けが定義される。

４４行目では、当該ａｄｖｉｃｅ要素の子要素の定義を挿入（ｉｎｓｅｒｔ）すべきことが指定されている。

４５行目から４９行目までは、挿入される定義である。４５行目には、Ｂｕｎｄｌｅを実装することが指定されている。Ｂｕｎｄｌｅの実装先は、ｘｍｉ．ｉｄｒｅｆ属性の値（「００４」）で指定される。すなわち、ＦａｘＴｘ１である。

４６行目から４９行目までは、Ｔｒａｎｓｆｏｒｍ状態６０５に対応させて新たに挿入するＣｏｍｐｏｓｉｔｅＳｔａｔｅ要素８５０（５行目から１８行目）の入場処理の定義（１５行目から１７行目）におけるｐｄｆ２ｔｉｆｆと、実際にその処理が実装されているｊｐ．ｃｏ．ｒｒｒ．ｆｕｎｃｔｉｏｎ．ｐｄｆ２ｔｉｆｆクラスとの関連付けが定義されている。これによって、ＦａｘＴｘ２に更新された後、Ｔｒａｎｓｆｏｒｍ状態６０５に遷移したときには、ｊｐ．ｃｏ．ｒｒｒ．ｆｕｎｃｔｉｏｎ．ｐｄｆ２ｔｉｆｆが実行されることになる。４８行目のｐｒｏｐｅｒｔｙ要素は、ｊｐ．ｃｏ．ｒｒｒ．ｆｕｎｃｔｉｏｎ．ｐｄｆ２ｔｉｆｆクラスが実行されるときのプロパティ情報である。

５０行目から５２行目は、Ｔｒａｎｓｆｏｒｍ状態６０５からＳｅｎｄ状態６０４への状態遷移のトリガーとなる変換完了イベントとｊｐ．ｃｏ．ｒｒｒ．ｆｕｎｃｔｉｏｎ．ｃｏｎｖｅｒｔＥｎｄクラスとの関連付けが定義されている。これによって、Ｔｒａｎｅｆｏｒｍ状態６０５中に変換完了イベントが検知されると、ｊｐ．ｃｏ．ｒｒｒ．ｆｕｎｃｔｉｏｎ．ｃｏｎｖｅｒｔＥｎｄクラスが実行され、その実行結果がｔｒｕｅであれば、Ｓｅｎｄ状態６０４に遷移することになる。

図１７に戻る。管理者によるＳＤカード２３５ａの挿入が自動的に検知されると、又はＳＤカード２３５ａが挿入され、オペレーションパネル２０２から更新指示が入力されると、ＳＡＳ４１１は、ＳＡＳ Ｍａｎａｇｅｒ５１１に更新処理の実行を要求する（Ｓ２０２）。なお、ＳＤカード２３５ａに記録された情報は、ネットワークを介してダウンロードされてもよい。この場合、ＳＤカードのような記録媒体を用いる必要はない。

ＳＡＳ Ｍａｎａｇｅｒ５１１は、挿入されたＳＤカード２３５ａの更新差分サービスバンドル８４０によるＦａｘＴｘ１からＦａｘＴｘ２への更新の可否についてチェックを行う（Ｓ２０３）。更新が可能な場合、ＳＡＳ Ｍａｎａｇｅｒ５１１は、更新差分サービスバンドル８４０の融合機１０１へのインストールの可否をチェックする（Ｓ２０４）。インストールが可能な場合、ＳＡＳ Ｍａｎａｇｅｒ５１１は、ＳＤカード２３５ａ内の更新差分サービスバンドル８４０をＯＳＧｉフレームワーク４０３（融合機１０１）にインストールする（Ｓ２０５）。更新差分サービスバンドル８４０のインストールが完了すると、ＳＡＳ Ｍａｎａｇｅｒ５１１は、更新差分サービスバンドル８４０をアクティブ状態に遷移させるようにＯＳＧｉフレームワーク４０３に要求する（Ｓ２０６）。

ＯＳＧｉフレームワーク４０３は、更新差分サービスバンドル８４０のインスタンスを（以下、「更新差分オブジェクト８４０ａ」という。）生成し、アクティブな状態に遷移させる（Ｓ２０７）。更新差分オブジェクト８４０ａは、Ｐｌｕｇｉｎ Ａｇｅｎｔ８２１に対して更新差分サービスバンドル８４０がプラグインされたことをＡｓｐｅｃｔＳＭ８１１を添えて通知する（Ｓ２０８）。

Ｐｌｕｇｉｎ Ａｇｅｎｔ８２１は、ＦａｘＴｘ１オブジェクト８３１に対して、ＡｓｐｅｃｔＳＭ８１１を添えてＦａｘＴｘ２への更新要求を行う（Ｓ２０９）。ＦａｘＴｘ１オブジェクト８３１は、ＡｓｐｅｃｔＳＭ８１１に基づいて、サービスバンドル「ＦａｘＴｘ１」をＦａｘＴｘ２へ更新する為に必要な追加モジュール判断し、当該追加モジュール（ここでは、ＰＤＦ２Ｔｉｆｆ８４１及びＣｏｎｖｅｒｔＥｎｄ８４２）の取得を更新差分オブジェクト８４０ａに要求する（Ｓ２１０）。更新差分オブジェクト８４０ａは、当該追加モジュールを取得し、ＦａｘＴｘ１オブジェクト８３１に返却する（Ｓ２１１）。

続いて、ＦａｘＴｘ１オブジェクト８３１は、ＡｓｐｅｃｔＳＭ８１１に従って、バンドルサービス「ＦａｘＴｘ１」のオブジェクト構成を、ＦａｘＴｘ２に対応するものに更新すると共に、当該更新によって新たに追加されたＡｃｔｉｖｉｔｙオブジェクトと追加モジュールとの関連付けを行う（Ｓ２１２）。なお、ステップＳ２１２の処理は、ＡｓｐｅｃｔＳＭ８１１に記述されているタイミングで行われる。

続いて、ＦａｘＴｘ１オブジェクト８３１は、バンドルサービス「ＦａｘＴｘ１」について「ＦａｘＴｘ２」への更新が完了したことをＰｌｕｇｉｎ Ａｇｅｎｔ８２１に通知する（Ｓ２１３）。但し、ＦａｘＴｘ１をＦａｘＴｘ２に切り替えるスイッチ７２１は、ＦａｘＴｘ１の状態のままである。

更新が完了した旨の通知は、ＳＡＳ Ｍａｎａｅｒ５１１を介してＳＡＳ４１１に通知される（Ｓ２１４、Ｓ２１５）。ＳＡＳ４１１は、管理者に更新完了を通知するため、オペレーションパネル２０２に更新完了を通知するメッセージを表示させる（Ｓ２１６）。なお、この状態では、スイッチ７２１は、まだＦａｘＴｘ２には切り替えられていないので、ＳＡＳ４１１は、管理者にＦａｘＴｘ２へ切り替える否かを問い合わせる。

そこで、管理者が、オペレーションパネル２０２を介してＦａｘＴｘ２への切替指示を入力すると（Ｓ２１７）、ＳＡＳ４１１は、ＦａｘＴｘ２への切替要求をＳＡＳ Ｍａｎａｇｅｒ５１１に通知する（Ｓ２１８）。ＳＡＳ Ｍａｎａｇｅｒ５１１は、Ｐｌｕｇｉｎ Ａｇｅｎｔ８２１にＦａｘＴｘ２への切り替えを要求する（Ｓ２１９）。Ｐｌｕｇｉｎ Ａｇｅｎｔ８２１は、ＦａｘＴｘ１オブジェクト８３１に対して、その振る舞い（状態遷移）をＦａｘＴｘ２に対応するものに切り替えるように指示する（Ｓ２２０）。

ＦａｘＴｘ１オブジェクト８３１は、バンドルサービス「ＦａｘＴｘ１」がＩｄｌｅ状態７０３になるまで待機する。Ｉｄｌｅ状態７０３に遷移すると、ＦａｘＴｘ１オブジェクト８３１は、スイッチ７２１を切り換えることにより、自己の振る舞いをＦａｘＴｘ２に対応するものに切り替える（Ｓ２２１）。切り替えが完了すると、ＦａｘＴｘ１オブジェクト８３１は、Ｐｌｕｇｉｎ Ａｇｅｎｔ８２１に対して、切替完了通知を行う（Ｓ２２２）。切替完了通知は、ＳＡＳ Ｍａｎａｇｅｒ５１１を介してＳＡＳ４１１に伝達される（Ｓ２２３、Ｓ２２４）。ＳＡＳ４１１は、切替完了通知に応じ、バンドルサービス「ＦａｘＴｘ１」の切り替えが完了した旨をオペレーションパネル２０２に表示させる（Ｓ２２５）。

次に、ステップＳ２１２における、バンドルサービス「ＦａｘＴｘ１」のオブジェクト構成の更新処理の詳細について説明する。図２０は、バンドルサービス「ＦａｘＴｘ１」のオブジェクト構成の更新処理を説明するためのシーケンス図である。

まず、ＦａｘＴｘ１オブジェクト８３１は、バンドルサービス「ＦａｘＴｘ１」の状態が、ＡｓｐｅｃｔＳＭ８１１に指定されている変更箇所ごとにおけるｔｉｍｉｎｇ属性の値に指定されている状態に遷移するまで待機する（Ｓ２１１１）。図１９のＡｓｐｅｃｔＳＭ８１１の例では、全ての変更箇所に対するタイミングは、Ｉｄｌｅ状態６０３として指定されている。したがって、ここでは、Ｉｄｌｅ状態６０３に遷移するまで待機する。

バンドルサービス「ＦａｘＴｘ１」の状態がＩｄｌｅ状態６０３に遷移すると、ＦａｘＴｘ１オブジェクト８３１は、ＡｓｐｅｃｔＳＭ８１１の記述にしたがって、更新処理を開始する。

例えば、ＦａｘＴｘ１オブジェクト８３１は、ＡｓｐｅｃｔＳＭ８１１の３行目から２０行目に基づいてＴｒａｎｓｆｏｒｍ状態６０５に対応するＴｒａｎｓｆｏｒｍオブジェクト状態７０５を生成する（Ｓ２１１２）。続いて、ＦａｘＴｘ１オブジェクト８３１は、ＡｓｐｅｃｔＳＭ８１１の２５行目から４１行目に基づいて、変換終了オブジェクト７１３Ｔを生成する（Ｓ２１１３）。続いて、ＦａｘＴｘ１オブジェクト８３１は、ＡｓｐｅｃｔＳＭ８１１の９行目から１４行目や、２２行目から２４行目に基づいて、オブジェクト間の接続関係を変更する。すなわち、ＦａｘＴｘ１オブジェクト８３１は、Ｔｒａｎｓｆｏｒｍ状態オブジェクト７０５の識別情報を引数としてＩｄｌｅ状態オブジェクト７０３のｒｅｃｏｎｎｅｃｔ（）メソッドを呼び出す（Ｓ２１１４）。これに応じて、Ｉｄｌｅ状態オブジェクト７０４は、遷移先の状態オブジェクトとして、Ｓｅｎｄ状態オブジェクト７０４とＴｒａｎｓＦｏｒｍ状態オブジェクト７０５とを保持することになる。これは、ちょうど図１２において、スイッチ７２１によって遷移先が分岐している状態に相当する。スイッチ７２１は、例えば、Ｉｄｌｅ状態オブジェクト７０３が参照可能なフラグ変数として実装される。例えば、当該フラグ変数の値が０のときには遷移先はＳｅｎｄ状態オブジェクト７０４とされ、１のときには遷移先はＴｒａｎｓｆｏｒｍ状態オブジェクト７０５とされるといった具合である。なお、Ｉｄｌｅ状態オブジェクト７０３とＴｒａｎｓｆｏｒｍ状態オブジェクト７０５との接続は行われたが、図１７において説明したように、この時点では、スイッチ７２１は切り替えられていないため、Ｉｄｌｅ状態オブジェクト７０３からの遷移先のオブジェクトはＳｅｎｄ状態オブジェクト７０４のままである（すなわち、バンドルサービス「ＦａｘＴｘ１」として機能する。）。

続いて、ＦａｘＴｘ１オブジェクト８３１は、Ｓｅｎｄ状態オブジェクト７０４の識別情報と変換完了オブジェクト７１３Ｔの識別情報とを引数としてＴｒａｎｓｆｏｒｍ状態オブジェクト７０５のｃｏｎｎｅｃｔ（）メソッドを呼び出す（Ｓ２１１５）。これに応じて、Ｔｒａｎｓｆｏｒｍ状態オブジェクト７０５は、Ｓｅｎｄ状態オブジェクト７０４の識別情報と変換完了オブジェクト７１３Ｔの識別情報とを関連付けて保持する。すなわち、変換終了イベントが発生した際のＴｒａｎｓｆｏｒｍ状態６０５からＳｅｎｄ状態６０４への状態遷移に対応する接続が構築されたことになる。

続いて、ＦａｘＴｘ１オブジェクト８３１は、ＡｓｐｅｃｔＳＭ８１１の４３行目から５５行目に基づいて、追加モジュールとオブジェクトとの関連付けを行う。すなわち、Ｔｒａｎｓｆｏｒｍ状態オブジェクト７０５の入場処理のインタフェース（ＩＳｔａｔｅインタフェース１００４ａ）に対してＰＤＦ２ＴＩＦＦ８４１を関連付ける（Ｓ２１１６）。続いて、変換完了オブジェクト７１３ＴのＥｖｅｎｔインタフェース１００３ａに対してＣｏｎｖｅｒｔＥｎｄ８４２を関連付ける（Ｓ２１１７）。

以上の処理によって、バンドルサービスＦａｘＴｘ１のオブジェクト構成は、図１２に示されるようなものに更新される。

ところで、図１９において、ＡｓｐｅｃｔＳＭ８１１にはバンドルサービス「ＦａｘＴｘ１」の状態遷移情報９００（図１５及び図１６）に対する変更内容が記述されていると説明した。しかし、上記のように、ＦａｘＴｘ１オブジェクト８３１は、ＡｓｐｅｃｔＳＭ８１１に基づいて状態遷移情報９００を書き換えるのではなく、バンドルサービス「ＦａｘＴｘ１」を構成するオブジェクトを変更することで更新処理を実現する。図１４において説明したように、バンドルサービス「ＦａｘＴｘ１」は、状態遷移情報９００に基づいてそのオブジェクトが構築されたものである。したがって、状態遷移情報９００に対する変更内容が記述されたＡｓｐｅｃｔＳＭ８１１は、そのままバンドルサービス「ＦａｘＴｘ１」のオブジェクト構成に適用することができるのである。なお、ＡｓｐｅｃｔＳＭ８１１に基づいて状態遷移情報９００を更新し、更新された状態遷移情報９００に基づいてＦａｘＴｘ１（厳密には、ＦａｘＴｘ２に更新されたもの）を再構築してもよい。但し、この場合、再構築の前にバンドルサービス「ＦａｘＴｘ１」を構成するオブジェクト群が破棄されるため、バンドルサービス「ＦａｘＴｘ１」を利用中のアプリケーション等との参照関係が破壊されてしまう。したがって、本実施の形態のように、オブジェクト群を再構築するのではなく、既存のオブジェクト構成を変更する方が好適である。

なお、上記のように、更新処理後は、バンドルサービス「ＦａｘＴｘ１」と「ＦａｘＴｘ２」とは、スイッチ７２１を切り替えることにより容易に切り替えが可能である。したがって、「ＦａｘＴｘ１」から「ＦａｘＴｘ２」への更新後、再度「ＦａｘＴｘ２」から「ＦａｘＴｘ１」に戻したい場合は、スイッチ７２１を切り替えることにより実現すればよい。すなわち、Ｉｄｌｅ状態オブジェクト７０３が参照可能なフラグ変数の値を更新すればよい。また、「ＦａｘＴｘ２」から「ＦａｘＴｘ１」への更新指示が記述されたＡｓｐｅｃｔＳＭに基づいて、「ＦａｘＴｘ２」から「ＦａｘＴｘ１」への更新を実現してもよい。この場合スイッチ７２１を切り替えるタイミングは、当該ＡｓｐｅｃｔＳＭに記述されたタイミングで行われる。

上述したように、本実施の形態におけるバンドルサービスは、状態オブジェクトの遷移によってサービスを実現する。また、サービスの実現過程において、アクティブな状態オブジェクトが限定されるように構成されている。言い換えれば、非アクティブな状態オブジェクトが存在することになる。このような構成を前提として、ＡｓｐｅｃｔＳＭ８１１には、更新部分が非アクティブなタイミングで更新が行われるような更新指示が記述されている。そして、かかるＡｓｐｅｃｔＳＭ８１１に従って、更新部分が非アクティブなときに更新が実行される。したがって、本実施の形態におけるバンドルサービスは、当該バンドルサービスの実行中にその振る舞いの更新を実行することができる。また、振る舞いの更新にあたり、オブジェクト群が再構築されるわけではないので、当該バンドルサービスの参照側との参照関係が破壊されることなく、動的にその振る舞いを更新することが可能となっている。よって、融合機１０１を再起動することなくバンドルサービスの振る舞いは更新され得る。

なお、本実施の形態においては、バンドルサービスが状態遷移図に基づいて設計された例を用いて説明したが、本発明が適用可能なプログラムは、状態ごとにオブジェクトが構築されるような構成であるものに限定されない。お互いに排他的に動作する複数のモジュール（オブジェクトも含む）の接続によって構成されているものでればよい。ここで排他的に処理を実行するとは、あるモジュールが動作中（アクティブ）のときは、他のモジュールは動作中でない（非アクティブである）ことが保証されることをいう。このようなソフトウェアであれば、動作中でないモジュールの接続関係を変更することが可能であり、本実施の形態において説明した更新処理を適用させることができる。

以上、バンドルサービス１４８の更新処理を説明したが、以下、図２１ではバンドルアプリ１４７の更新処理を説明する。バンドルアプリ１４７の更新処理ではバンドルサービス１４８の更新処理と異なりサービスの提供が問題にならないので、バンドルアプリ１４７の更新処理はバンドルサービス１４８の更新処理に比べて単純になる。

図２１は、バンドルアプリ１４７の更新処理に係るコラボレーション図である。同図の更新処理は、バンドルアプリ「ＡｐｐＸｔ１」をバンドルアプリ「ＡｐｐＸｔ２」に更新するものである。

ＡｐｐＸｔ１をＡｐｐＸｔ２に更新する旨の更新操作が融合機１０１又はクライアント端末８０１の操作画面で実施されると、ＡｐｐＸｔ１をＡｐｐＸｔ２に更新する旨の更新要求がＳＡＳ４１１からＳＡＳ Ｍａｎａｇｅｒ５１１に送信（Ｓ２１）される。次に、ＳＡＳ Ｍａｎａｇｅｒ５１１では、更新処理用のモジュールを融合機１０１にインストール可能かどうかのチェックが実行（Ｓ２２）される。

続いて、ＳＡＳ Ｍａｎａｇｅｒ５１１は、更新処理用のモジュールを融合機１０１にインストール（Ｓ２３）する。続いて、ＳＡＳ Ｍａｎａｇｅｒ５１１は、更新処理用のモジュールをアクティブ状態に遷移（Ｓ２４）させる。続いて、ＳＡＳ Ｍａｎａｇｅｒ５１１は、ＡｐｐＸｔ１に更新処理用のモジュールを追加して、所定のスイッチをＡｐｐＸｔ１側からＡｐｐＸｔ２側に切り替えて、ＡｐｐＸｔ２を生成（Ｓ２５）する。

なお、上記のスイッチをＡｐｐＸｔ１側からＡｐｐＸｔ２側に切り替えるタイミングは任意である。

以上、バンドルアプリ１４７に係る説明とバンドルサービス１４８に係る説明とを別個に実施したが、以下、バンドルアプリ１４７に係る説明とバンドルサービス１４８に係る説明とを同時に実施する。

図２２は、バンドルアプリ１４７とバンドルサービス１４８との間の利用関係の具体例を表す。バンドルアプリ１４７やバンドルサービス１４８の更新処理が実施される場合において、どのバンドルアプリ１４７がどのバンドルサービス１４８を利用するかと言う利用関係を設定できるようにしてもよい。図２２は、バンドルアプリ「ＡｐｐＸｔ１」がバンドルサービス「ＦａｘＴｘ１」を利用する、バンドルアプリ「ＡｐｐＸｔ２」がバンドルサービス「ＦａｘＴｘ２」を利用する、バンドルアプリ「ＡｐｐＸｔ３」がバンドルサービス「ＦａｘＴｘ３」を利用すると言う利用関係を表す。

図２３は、ＦａｘＴｘ１とＦａｘＴｘ２とＦａｘＴｘ３との間の継承関係の例を表す。ＦａｘＴｘ１とＦａｘＴｘ２については、ＦａｘＴｘ１が親でＦａｘＴｘ２が子の関係の継承関係にある。ＦａｘＴｘ３については、ＦａｘＴｘ１ともＦａｘＴｘ２とも継承関係にない。ＦａｘＴｘ１やＦａｘＴｘ２やＦａｘＴｘ３の継承関係はＰｌｕｇｉｎ Ａｇｅｎｔ８２１の処理やＰｒｏｘｙ Ｓｅｒｖｉｃｅ８２２の処理に影響する。

Ｐｌｕｇｉｎ Ａｇｅｎｔ８２１では、ＦａｘＴｘ１やＦａｘＴｘ２やＦａｘＴｘ３の管理を継承関係を利用せず実施する。図２３のように、Ｐｌｕｇｉｎ Ａｇｅｎｔ８２１では、ＦａｘＴｘ１もＦａｘＴｘ２もＦａｘＴｘ３もそれぞれ個別に管理する。継承関係がＰｌｕｇｉｎ Ａｇｅｎｔ８２１の処理に影響するのは、継承関係にあるＦａｘＴｘ１とＦａｘＴｘ２のスイッチをＦａｘＴｘ１側からＦａｘＴｘ２側に切り替える切替制御である。

Ｐｒｏｘｙ Ｓｅｒｖｉｃｅ８２２では、ＦａｘＴｘ１やＦａｘＴｘ２やＦａｘＴｘ３の登録を継承関係を利用して実施する。ＦａｘＴｘ１とＦａｘＴｘ２については継承関係にあるため、図２３のように、親のＦａｘＴｘ１は登録されるが子のＦａｘＴｘ２は登録不要である。ＦａｘＴｘ３についてはＦａｘＴｘ１ともＦａｘＴｘ２とも継承関係にないため、図２３のように、ＦａｘＴｘ３は登録される。Ｐｒｏｘｙ Ｓｅｒｖｉｃｅ８２２では、ＡｐｐＸｔ１／２／３とＦａｘＴｘ１／２／３との仲介制御を実行する。

図２４は、利用関係の設定画面の具体例を表す。図２４の設定画面は、融合機１０１やクライアント端末８０１の表示画面にＳＡＳ４１１が表示する。前者はいわゆるローカル表示であり、後者はいわゆるリモート表示である。リモート表示を実現するには例えば、融合機１０１とクライアント端末８０１にＷｅｂサーバ機能とＷｅｂクライアント機能を具備させればよい。

図２４の設定画面は、ＡｐｐＸｔ１にＦａｘＴｘ１を利用させるかＦａｘＴｘ２を利用させるかＦａｘＴｘ３を利用させるかを設定するための設定画面である。ＡｐｐＸｔ１に係る表示情報は、ＡｐｐＸｔ１のＪＡＲファイルに対応するＪＮＬＰファイル（アプリケーション管理ファイル）に起因する。図２４の設定画面で指定されたＦａｘＴｘ（ＦａｘＴｘ１／２／３）が融合機１０１に実装されていない場合、図１３のようなインストール処理やアップデート処理が実行される。なお、図２４の設定画面での指定操作は、図１３の説明で登場した操作画面での更新操作の一環として実施されるものとしてもよい。

図２５は、バンドルアプリ１４７やバンドルサービス１４８の更新処理用のモジュールの取得態様について説明するための図である。

図中のＡの矢印は、更新処理用のモジュールを融合機１０１に挿入されたメモリカード２３５から取得する態様を表す。メモリカード２３５は例えば、ＳＤカードやＩＣカードである。図２５のＡでは、ＳＡＳ Ｍａｎａｇｅｒ５１１は、融合機１０１に実装されたバンドルアプリ１４７やバンドルサービス１４８を、メモリカード２３５から取得されたプログラムにより更新する。図２５のＡの取得態様では、ネットワーク接続されていない機器においても更新処理を実施する事ができる。

図中のＢの矢印は、更新処理用のモジュールをＰｕｌｌ型の通信によりバンドルサーバ９０１から取得する態様を表す。Ｐｕｌｌ型の通信処理の主体は、融合機１０１のＳＡＳ４１１である。図２５のＢでは、ＳＡＳ Ｍａｎａｇｅｒ５１１は、融合機１０１に実装されたバンドルアプリ１４７やバンドルサービス１４８を、Ｐｕｌｌ型の通信により取得されたプログラムにより更新する。図２５のＢの取得態様では、ＳＤカードやＩＣカードを利用せずに更新処理を実施する事ができる。

図中のＣの矢印は、更新処理用のモジュールをＰｕｓｈ型の通信によりバンドルサーバ９０１から取得する態様を表す。Ｐｕｓｈ型の通信処理の主体は、バンドルサーバ９０１である。図２５のＣでは、ＳＡＳ Ｍａｎａｇｅｒ５１１は、融合機１０１に実装されたバンドルアプリ１４７やバンドルサービス１４８を、Ｐｕｓｈ型の通信により取得されたプログラムにより更新する。図２５のＣの取得態様では、サーバからの遠隔制御のもとで更新処理を実施する事ができる。

なお、更新処理の実施態様は自動更新でも手動更新でもよい。図１３や図２１では更新操作の直後に更新処理が実施されるようにしているが、更新操作による更新設定を契機として更新処理が定期的に実施されるようにしてもよい。

本発明の実施例に該当する融合機を表す。 図１の融合機に係るハードウェア構成図である。 図１の融合機に係る外観図である。 オペレーションパネルを表す。 図１のＣＳＤＫアプリとＪＳＤＫアプリのソフトウェア構成図である。 図１の融合機におけるＯＳＧｉについて説明するための図である。 バンドルサービスのオブジェクト構成の具体例を表す。 バンドルサービス「ＦａｘＴｘ１」の状態遷移図である。 バンドルサービス「ＦａｘＴｘ２」の状態遷移図である。 バンドルサービスを構成するクラス図の一例である。 バンドルサービス「ＦａｘＴｘ１」のオブジェクト構成を表す。 バンドルサービス「ＦａｘＴｘ２」のオブジェクト構成を表す。 バンドルサービスの更新処理に係るコラボレーション図である。 バンドルサービス「ＦａｘＴｘ１」のオブジェクト構成の構築処理を説明するためのシーケンス図である。 バンドルサービス「ＦａｘＴｘ１」の状態遷移情報の定義例を示す図である。 バンドルサービス「ＦａｘＴｘ１」の状態遷移情報の定義例を示す図である。 ＦａｘＴｘ１からＦａｘＴｘ２への更新処理を説明するためのシーケンス図である。 ＳＤカード内の追加モジュールの構成例を示す図である。 ＡｓｐｅｃｔＳＭの記述例を示す図である。 バンドルサービス「ＦａｘＴｘ１」のオブジェクト構成の更新処理を説明するためのシーケンス図である。 バンドルアプリの更新処理に係るコラボレーション図である。 バンドルアプリとバンドルサービスとの間の利用関係の具体例を表す。 ＦａｘＴｘ１とＦａｘＴｘ２とＦａｘＴｘ３との間の継承関係の例を表す。 利用関係の設定画面の具体例を表す。 更新処理用のモジュールの取得態様について説明するための図である。

符号の説明

１０１ 融合機
１１１ ハードウェア
１１２ ソフトウェア
１１３ 融合機起動部
１２１ 撮像部
１２２ 印刷部
１２３ その他のハードウェア
１３１ アプリケーション
１３２ プラットフォーム
１３３ アプリケーションプログラムインタフェース
１３４ エンジンインタフェース
１３５ 仮想アプリケーションサービス
１４１ コピーアプリ
１４２ プリンタアプリ
１４３ スキャナアプリ
１４４ ファクシミリアプリ
１４５ ネットワークファイルアプリ
１４６ ＣＳＤＫアプリ
１４７ ＪＳＤＫアプリ
１４８ ＪＳＤＫプラットフォーム
１５１ コントロールサービス
１５２ システムリソースマネージャ
１５３ ハンドラ
１６１ ネットワークコントロールサービス
１６２ ファクシミリコントロールサービス
１６３ デリバリコントロールサービス
１６４ エンジンコントロールサービス
１６５ メモリコントロールサービス
１６６ オペレーションパネルコントロールサービス
１６７ サーティフィケーションコントロールサービス
１６８ ユーザディレクトリコントロールサービス
１６９ システムコントロールサービス
１７１ ファクシミリコントロールユニットハンドラ
１７２ イメージメモリハンドラ
２０１ コントローラ
２０２ オペレーションパネル
２０３ ファクシミリコントロールユニット
２１１ ＣＰＵ
２１２ ＡＳＩＣ
２２１ ＮＢ
２２２ ＳＢ
２３１ ＭＥＭ−Ｐ
２３２ ＭＥＭ−Ｃ
２３３ ＨＤＤ
２３４ メモリカードスロット
２３５ メモリカード
２４１ ＮＩＣ
２４２ ＵＳＢデバイス
２４３ ＩＥＥＥ１３９４デバイス
２４４ セントロニクスデバイス
３０１ 原稿セット部
３０２ 給紙部
３０３ 排紙部
３１１ タッチパネル
３１２ テンキー
３１３ スタートボタン
３１４ リセットボタン
３１５ 機能キー
３１６ 初期設定ボタン
３２１ ＡＤＦ
３２２ フラットベッド
３２３ フラットベッドカバー
４０１ ＯＳＧｉアプリ
４０２ ＯＳＧｉサービス
４０３ ＯＳＧｉフレームワーク
４０４ Ｂｕｎｄｌｅ Ａｃｔｉｖａｔｏｒ
４１１ ＳＡＳ
５１１ ＳＡＳ Ｍａｎａｇｅｒ
５５５ ＣＶＭ
８０１ クライアント端末
８１１ ＡｓｐｅｃｔＳＭ
８２１ Ｐｌｕｇｉｎ Ａｇｅｎｔ
８２２ Ｐｒｏｘｙ Ｓｅｒｖｉｃｅ
９０１ バンドルサーバ
１００１ ＳｔａｔｅＭａｃｈｉｎｅクラス
１００２ ＳｔａｔｅＶｅｒｔｅｘクラス
１００３ Ｔｒａｎｓｉｔクラス
１００３ａ Ｅｖｅｎｔインタフェース
１００３ｂ Ｇｕａｒｄインタフェース
１００３ｃ Ａｃｔｉｏｎインタフェース
１００４ Ｓｔａｔｅクラス
１００４ａ ＩＳｔａｔｅインタフェース
１００４ｂ Ａｃｔｉｖｉｔｙインタフェース
１００５ ＰｓｅｕｄｏＳｔａｔｅクラス
１００６ ＩｎｉｔｉａｌＳｔａｔｅクラス
１００７ ＦｉｎａｌＳｔａｔｅクラス

Claims (14)

1. 互いに排他的に動作する複数のモジュールの接続によって構成されるプログラムを実行する画像形成装置であって、
   前記プログラムの更新情報の入力を受け付ける入力手段と、
   前記プログラムの動作状態が、前記更新情報において指定されている更新のタイミングに相当するか否かを判定するタイミング判定手段と、
   前記タイミング判定手段によって前記更新のタイミングであると判定されたときに、前記更新情報に従って、前記複数のモジュールの接続関係を変更する変更手段とを有することを特徴とする画像形成装置。
2. 前記変更手段は、前記更新情報に指定されている変更箇所に対応するモジュールの接続関係を変更することを特徴とする請求項１記載の画像形成装置。
3. 前記更新情報には、少なくとも前記変更箇所に対応するモジュールが動作中でないときが前記更新のタイミングとして指定されていることを特徴とする請求項２記載の画像形成装置。
4. 前記判定手段によって前記更新のタイミングであると判定されるまで、前記変更手段による変更を待機することを特徴とする請求項１乃至３いずれか一項記載の画像形成装置。
5. 前記変更手段は、前記更新情報に新たなモジュールの追加が指定されているときは、当該新たなモジュールを生成し、当該新たなモジュールも含めて複数の前記モジュールの接続関係を変更することを特徴とする請求項１乃至４いずれか一項記載の画像形成装置。
6. 前記プログラムを構成する各モジュールは、当該プログラムの状態遷移における各状態に対応することを特徴とする請求項１乃至５いずれか一項記載の画像形成装置。
7. 互いに排他的に動作する複数のモジュールの接続によって構成されるプログラムを実行する画像形成装置によって実行される情報処理方法であって、
   前記プログラムの更新情報の入力を受け付ける入力手順と、
   前記プログラムの動作状態が、前記更新情報において指定されている更新のタイミングに相当するか否かを判定するタイミング判定手順と、
   前記タイミング判定手順において前記更新のタイミングであると判定されたときに、前記更新情報に従って、前記複数のモジュールの接続関係を変更する変更手順とを有することを特徴とする情報処理方法。
8. 前記変更手順は、前記更新情報に指定されている変更箇所に対応するモジュールの接続関係を変更することを特徴とする請求項７記載の情報処理方法。
9. 前記更新情報には、少なくとも前記変更箇所に対応するモジュールが動作中でないときが前記更新のタイミングとして指定されていることを特徴とする請求項８記載の情報処理方法。
10. 前記判定手順において前記更新のタイミングであると判定されるまで、前記変更手順による変更を待機することを特徴とする請求項７乃至９いずれか一項記載の情報処理方法。
11. 前記変更手順は、前記更新情報に新たなモジュールの追加が指定されているときは、当該新たなモジュールを生成し、当該新たなモジュールも含めて複数の前記モジュールの接続関係を変更することを特徴とする請求項７乃至１０いずれか一項記載の情報処理方法。
12. 前記プログラムを構成する各モジュールは、当該プログラムの状態遷移における各状態に対応することを特徴とする請求項７乃至１１いずれか一項記載の情報処理方法。
13. 請求項７乃至１２いずれか一項記載の情報処理方法をコンピュータに実行させるための情報処理プログラム。
14. 請求項１３記載の情報処理プログラムを記録したコンピュータ読取可能な記録媒体。

Images