JP2019153079A - 機器、情報処理システム、情報処理方法及びプログラム - Google Patents

Abstract

【課題】処理要求に非互換が有る他の機器との連携を可能とすること。【解決手段】第１のプログラムに対する第１の処理要求に対応する第２の処理要求を受け付ける第２のプログラムをインストール可能な機器は、ネットワークを介して前記第１の処理要求を受信する受信部と、前記受信部による前記第１の処理要求の受信に応じ、前記第１の処理要求と前記第２の処理要求との非互換部分の解消要求を生成する生成部と、前記解消要求に応じ、前記第１の処理要求に含まれている情報を前記第２の処理要求に適合するように変更し、変更後の情報を含む前記第２の処理要求を前記第２のプログラムに入力する変更部と、を有する。【選択図】図３

Description

本発明は、機器、情報処理システム、情報処理方法及びプログラムに関する。

オフィス等においてネットワークを介して接続される複数の機器が連携してサービスを提供する場合が有る。

例えば、画像形成装置Ａが、ユーザからアップロードされた印刷ジョブを蓄積し、当該ユーザが当該印刷ジョブの実行指示を画像形成装置Ｂ又は画像形成装置Ｃ等の他の機器に入力する。この場合、画像形成装置Ｂ又は画像形成装置Ｃは、クライアントとなり、画像形成装置Ａはサーバとなる。クライアントとしての画像形成装置Ｂ又は画像形成装置Ｃは、サーバとしての画像形成装置Ａから印刷ジョブを取得した後、当該印刷ジョブについて印刷処理を実行する。

上記の画像形成装置間において、クライアント及びサーバの立場は相対的なものである。すなわち、上記の例とは逆に、画像形成装置Ａがクライアントとなり、画像形成装置Ｂ又は画像形成装置Ｃがサーバとなることもある。

このように、複数の機器が連携する環境では、複数の機器間において、処理要求（例えば、ＡＰＩ（Application Program Interface）等のインタフェース）の互換性が確保されている必要が有る。

しかしながら、機器のインタフェースは、機器に搭載されるソフトウェア（例えば、アプリケーションプラットフォーム等）の大幅な設計変更等により変更される場合があり、新たな機種と既存の機種との間で互換性が失われる場合がある。

また、オフィス等における機器の置き換えは、必ずしも一括的に行われるとは限らず、一部の機器のみが新しい機種に置き換えられる場合もある。したがって、一つの環境内において、相互にインタフェースの互換性を有さない機器が混在する状態が発生する可能性が有る。

そうすると、一部の機器について、他の機器との連携が保証されなくなり、ユーザは、機器の置き換え前に可能であったサービスを利用ができなくなってしまう可能性が有る。

本発明は、上記の点に鑑みてなされたものであって、処理要求に非互換が有る他の機器との連携を可能とすることを目的とする。

そこで上記課題を解決するため、第１のプログラムに対する第１の処理要求に対応する第２の処理要求を受け付ける第２のプログラムをインストール可能な機器は、ネットワークを介して前記第１の処理要求を受信する受信部と、前記受信部による前記第１の処理要求の受信に応じ、前記第１の処理要求と前記第２の処理要求との非互換部分の解消要求を生成する生成部と、前記解消要求に応じ、前記第１の処理要求に含まれている情報を前記第２の処理要求に適合するように変更し、変更後の情報を含む前記第２の処理要求を前記第２のプログラムに入力する変更部と、を有する。

処理要求に非互換が有る他の機器との連携を可能とすることができる。

本発明の実施の形態における情報処理システムの構成例を示す図である。 本発明の実施の形態における画像形成装置１０のハードウェア構成例を示す図である。 本発明の実施の形態における画像形成装置１０の機能構成例を示す図である。 画像形成装置１０ａが実行する処理手順の一例を説明するためのシーケンス図である。 Ｗｅｂコンテナの起動処理の処理手順の一例を説明するためのシーケンス図である。

以下、図面に基づいて本発明の実施の形態を説明する。図１において、情報処理システム１は、１以上の画像形成装置１０ａ及び１以上の画像形成装置１０ｂを含む。画像形成装置１０ａは、画像形成装置１０ｂに対して相対的に新しい機種の画像形成装置である。換言すれば、画像形成装置１０ｂは、画像形成装置１０ａに対して相対的に古い機種の画像形成装置である。以下において、画像形成装置１０ａ及び画像形成装置１０ｂを区別しない場合、単に「画像形成装置１０」という。各画像形成装置１０は、他の画像形成装置１０と通信可能なように、ＬＡＮ（Local Area Network）等のネットワークを介して接続される。

本実施の形態において、機種の新旧の相違は、画像形成装置１０に搭載（インストール）されているアプリケーションプラットフォーム及びアプリケーションの新旧の相違と等価である。アプリケーションプラットフォームとは、画像形成装置１０にインストールされるアプリケーションの実行基盤となるソフトウェアをいい、本実施の形態では、便宜上、「ＳＤＫプラットフォーム」という。したがって、画像形成装置１０ａには、画像形成装置１０ｂよりも新しいＳＤＫラットフォームが搭載されている。ここで、「新しい」とは、バージョンが新しいことを意味してもよいし、アーキテクチャが新しいことを意味してもよい。

以下、画像形成装置１０ａに搭載されているＳＤＫプラットフォームを「新ＳＤＫプラットフォーム」といい、画像形成装置１０ｂに搭載されているＳＤＫプラットフォームを「旧ＳＤＫプラットフォーム」という。

図２は、本発明の実施の形態における画像形成装置１０のハードウェア構成例を示す図である。図２において、画像形成装置１０は、コントローラ１１、スキャナ１２、プリンタ１３、モデム１４、操作パネル１５、ネットワークインタフェース１６、及びＳＤカードスロット１７等のハードウェアを有する。

コントローラ１１は、ＣＰＵ１１１、ＲＡＭ１１２、ＲＯＭ１１３、ＨＤＤ１１４、及びＮＶＲＡＭ１１５等を有する。ＲＯＭ１１３には、各種のプログラムやプログラムによって利用されるデータ等が記憶されている。ＲＡＭ１１２は、プログラムをロードするための記憶領域や、ロードされたプログラムのワーク領域等として用いられる。ＣＰＵ１１１は、ＲＡＭ１１２にロードされたプログラムを処理することにより、各種の機能を実現する。ＨＤＤ１１４には、プログラムやプログラムが利用する各種のデータ等が記憶される。ＮＶＲＡＭ１１５には、各種の設定情報等が記憶される。

スキャナ１２は、原稿より画像データを読み取るためのハードウェア（画像読取手段）である。プリンタ１３は、印刷データを印刷用紙に印刷するためのハードウェア（印刷手段）である。モデム１４は、電話回線に接続するためのハードウェアであり、ＦＡＸ通信による画像データの送受信を実行するために用いられる。操作パネル１５は、ユーザからの入力の受け付けを行うためのボタン等の入力手段や、液晶パネル等の表示手段等を備えたハードウェアである。液晶パネルは、タッチパネル機能を有していてもよい。この場合、当該液晶パネルは、入力手段の機能をも兼ねる。ネットワークインタフェース１６は、ＬＡＮ等のネットワーク（有線又は無線の別は問わない。）に接続するためのハードウェアである。ＳＤカードスロット１７は、ＳＤカード８０に記憶されたプログラムを読み取るために利用される。すなわち、画像形成装置１０では、ＲＯＭ１１３に記憶されたプログラムだけでなく、ＳＤカード８０に記憶されたプログラムもＲＡＭ１１２にロードされ、実行されうる。なお、他の記録媒体（例えば、ＣＤ−ＲＯＭ又はＵＳＢ（Universal Serial Bus）メモリ等）によってＳＤカード８０が代替されてもよい。すなわち、ＳＤカード８０の位置付けに相当する記録媒体の種類は、所定のものに限定されない。この場合、ＳＤカードスロット１７は、記録媒体の種類に応じたハードウェアによって代替されればよい。

なお、画像形成装置１０ａと画像形成装置１０ｂとの各ハードウェアの性能や仕様は異なっていてもよい。また、図示されない範囲において、画像形成装置１０ａと画像形成装置１０ｂとのハードウェア構成は異なっていてもよい。

図３は、本発明の実施の形態における画像形成装置１０の機能構成例を示す図である。図３において、画像形成装置１０ａは、新ＳＤＫプラットフォーム１２１、印刷Ｗｅｂアプリ１２３、及び新ＳＤＫＰＦ起動管理部１２２に加えて、旧ＳＤＫプラットフォーム１３１ａ、旧ＳＤＫＰＦ起動管理部１３２ａ、Ｗｅｂプロキシアプリ１３３、Ｗｅｂコンテナ１４１、Ｗｅｂプロキシアプリ１４３及びＷｅｂコンテナ起動部１４２等を有する。これら各部は、ＣＰＵ１１１に処理を実行させることで機能を実現するソフトウェアプログラムである。また、画像形成装置１０ａは、Ｗｅｂコンテナ設定記憶部１５１及びＷｅｂプロキシ設定記憶部１５２を有する。これら各記憶部は、例えば、ＨＤＤ１１４又はＮＶＲＡＭ１１５等を利用して実現可能である。

すなわち、新ＳＤＫプラットフォーム上で動作するサーブレット等のＷｅｂアプリ（以下、「新Ｗｅｂアプリ」という。）は、旧ＳＤＫプラットフォーム上で動作するサーブレット等のＷｅｂアプリ（以下、「旧Ｗｅｂアプリ」という。）に対してポート番号やＵＲＬ等において互換性を有さないため、そのままでは、画像形成装置１０ａは、画像形成装置１０ｂからのＨＴＴＰリクエストに対応することができない。そこで、画像形成装置１０ａは、旧ＳＤＫプラットフォーム１３１ａ、旧ＳＤＫＰＦ起動管理部１３２ａ、Ｗｅｂプロキシアプリ１３３、Ｗｅｂコンテナ１４１、Ｗｅｂプロキシアプリ１４３及びＷｅｂコンテナ起動部１４２等を有するように構成される。

新ＳＤＫプラットフォーム１２１及び旧ＳＤＫプラットフォーム１３１ａは、Ｗｅｂアプリや操作パネル１５を利用するＵＩアプリなどの各ＳＤＫアプリのインストール、起動、終了、アンインストール等を制御する。

旧ＳＤＫプラットフォーム１３１ａは、Ｗｅｂコンテナ１３４ａ等を含む。Ｗｅｂコンテナ１３４ａは、一般的なＷｅｂコンテナであり、旧ＳＤＫプラットフォーム１３１ａの起動時に起動する。一般的なＷｅｂコンテナとは、Ｗｅｂアプリの実行環境として機能するＷｅｂコンテナをいう。具体的には、一般的なＷｅｂコンテナは、ＨＴＴＰリクエストの受信、当該ＨＴＴＰリクエストに対応したＷｅｂアプリのメソッドの呼び出し等を行う。

本実施の形態において、Ｗｅｂコンテナ１３４ａ上では、旧Ｗｅｂアプリの一例であるＷｅｂプロキシアプリ１３３が動作する。Ｗｅｂプロキシアプリ１３３は、クライアント（画像形成装置１０ｂ）からのＨＴＴＰリクエストについての非互換部分の解消要求に相当するＨＴＴＰリクエストを、新ＳＤＫプラットフォーム１２１上の非互換吸収部１２５へフォワード（送信）する。フォワード対象のＵＲＬ及びフォワード先のＵＲＬ（非互換部分の解消要求に対応するＵＲＬ）は、Ｗｅｂプロキシ設定記憶部１５２から取得される。

Ｗｅｂプロキシ設定記憶部１５２は、フォワード対象のＵＲＬとフォワード先のＵＲＬとを対応付けて記憶する。すなわち、Ｗｅｂプロキシ設定記憶部１５２には、フォワード対象のＵＲＬとフォワード先のＵＲＬとの対応関係が記憶される。

旧ＳＤＫＰＦ起動管理部１３２ａは、旧ＳＤＫプラットフォーム１３１ａの起動及び終了や、起動状態の管理等を行う。旧ＳＤＫＰＦ起動管理部１３２ａは、旧ＳＤＫプラットフォーム１３１ａの自動起動に関する設定情報（以下、「ＳＤＫ起動設定情報」という。）を参照し、ＳＤＫ起動設定情報において自動起動が有効とされている場合には、画像形成装置１０ａの起動時等において、旧ＳＤＫプラットフォーム１３１ａを自動起動する。ＳＤＫ起動設定情報は、例えば、ＨＤＤ１１４又はＮＶＲＡＭ１１５等に記憶されている。旧ＳＤＫＰＦ起動管理部１３２ａは、また、他モジュールからの問い合わせに対して、旧ＳＤＫプラットフォーム１３１ａの起動状態やＳＤＫ起動設定情報の内容を返却する。旧ＳＤＫＰＦ起動管理部１３２ａは、また、旧ＳＤＫプラットフォーム１３１ａの起動通知を各モジュールに配布することもある。

Ｗｅｂコンテナ起動部１４２は、Ｗｅｂコンテナ１４１の起動を制御する。Ｗｅｂコンテナ起動部１４２は、旧ＳＤＫＰＦ起動管理部１３２ａに対してＳＤＫ起動設定情報を問い合わせ、旧ＳＤＫプラットフォーム１３１ａの自動起動設定が無効であれば、Ｗｅｂコンテナ１４１を起動する。また、Ｗｅｂコンテナ起動部１４２は、Ｗｅｂコンテナ１４１の起動中に、旧ＳＤＫＰＦ起動管理部１３２ａからの通知などにより旧ＳＤＫプラットフォーム１３１ａの起動を検知した場合、Ｗｅｂコンテナ１４１を速やかにシャットダウンし、Ｗｅｂコンテナ１４１のポート、ＵＲＬ等のシステムリソースを開放する。すなわち、Ｗｅｂコンテナ１４１は、旧ＳＤＫプラットフォーム１３１ａが起動されない場合に起動される。但し、Ｗｅｂコンテナ１４１は、旧ＳＤＫプラットフォーム１３１ａが起動されない場合に常に起動されるとは限らない。Ｗｅｂコンテナ１４１が起動されるか否かは、Ｗｅｂコンテナ設定記憶部１５１に記憶されている情報に依存する。すなわち、当該情報は、Ｗｅｂコンテナ１４１の起動の要否を示す。

Ｗｅｂコンテナ１４１は、Ｗｅｂコンテナ１３４ａと同様に一般的なＷｅｂコンテナである。本実施の形態において、Ｗｅｂコンテナ１４１上では、Ｗｅｂプロキシアプリ１４３が動作する。Ｗｅｂプロキシアプリ１４３は、Ｗｅｂプロキシアプリ１３３と同様の機能を有する。

新ＳＤＫプラットフォーム１２１は、新機種の画像形成装置１０ａにおいて動作可能なアプリケーションプラットフォームである。新ＳＤＫプラットフォーム１２１は、旧ＳＤＫプラットフォーム１３１ａと異なるＣＰＵにおいて動作してもよい。例えば、操作パネル１５がタブレット端末等の情報処理端末である場合、新ＳＤＫプラットフォーム１２１は、操作パネル１５において動作するアプリケーションプラットフォームであってもよい。

図３において、新ＳＤＫプラットフォーム１２１は、Ｗｅｂコンテナ１２４及び非互換吸収部１２５等を含む。

Ｗｅｂコンテナ１２４は、Ｗｅｂコンテナ１３４ａ等と同様に一般的なＷｅｂコンテナであり、新ＳＤＫプラットフォーム１２１の起動時に起動する。図３では、画像形成装置１０ａにインストール可能であり、Ｗｅｂコンテナ１２４上で動作する新Ｗｅｂアプリの一例として、印刷Ｗｅｂアプリ１２３が示されている。

非互換吸収部１２５は、Ｗｅｂプロキシアプリ１３３又はＷｅｂプロキシアプリ１４３を経由して送られてくるＨＴＴＰリクエスト（非互換解消要求）に応じ、新ＳＤＫプラットフォーム１２１上で動作するＷｅｂアプリのインタフェースと旧ＳＤＫプラットフォーム１３１ａ上で動作するＷｅｂアプリのインタフェースとの非互換を吸収（解消）するための処理を実行する。

なお、非互換吸収部１２５は、新ＳＤＫプラットフォーム１２１の一部でなくてもよい。例えば、非互換吸収部１２５は、単独のＷｅｂアプリであってもよいし、新ＳＤＫプラットフォーム１２１上の各Ｗｅｂアプリによって包含されてもよい。

新ＳＤＫＰＦ起動管理部１２２は、新ＳＤＫプラットフォーム１２１に関して、旧ＳＤＫ起動管理部と同様の処理を行う。

なお、Ｗｅｂアプリが公開するポート番号及びＵＲＬパスは、Ｗｅｂコンテナの設定・実装に依存する。本実施の形態では、Ｗｅｂコンテナ１２４のポート番号は８０であり、ＵＲＬパスは、／ＳｍａｒｔＳＤＫ／から開始されるとし、Ｗｅｂコンテナ１３４ａ及びＷｅｂコンテナ１４１のポート番号は８０８０であり、ＵＲＬパスは、／ＬｅｇａｃｙＳＤＫ／から開始されるとする。

一方、画像形成装置１０ｂは、旧ＳＤＫプラットフォーム１３１ｂ、旧ＳＤＫＰＦ起動管理部１３２ｂ、印刷Ｗｅｂアプリ１３６ｂ及び印刷ＵＩアプリ１３５ｂ等を有する。また、旧ＳＤＫプラットフォーム１３１ｂは、Ｗｅｂコンテナ１３４ｂを含む。

旧ＳＤＫプラットフォーム１３１ｂ、旧ＳＤＫＰＦ起動管理部１３２ｂ、Ｗｅｂコンテナ１３４ｂは、それぞれ、画像形成装置１０ａにおける旧ＳＤＫプラットフォーム１３１ａ、旧ＳＤＫＰＦ起動管理部１３２ａ及びＷｅｂコンテナ１３４ａと同様の機能を有する。

印刷Ｗｅｂアプリ１３６ｂは、画像形成装置１０ｂにインストール可能であり、旧ＳＤＫプラットフォーム１３１ａ上で動作する、印刷用のＷｅｂアプリである。すなわち、印刷Ｗｅｂアプリ１３６ｂは、印刷Ｗｅｂアプリ１２３に対応する、旧ＳＤＫプラットフォーム上で動作するＷｅｂアプリである。

印刷ＵＩアプリ１３５ｂは、印刷Ｗｅｂアプリ１３６ｂに対するユーザインタフェースを提供するＳＤＫアプリである。

以下、画像形成装置１０ａが実行する処理手順について説明する。図４は、画像形成装置１０ａが実行する処理手順の一例を説明するためのシーケンス図である。

例えば、管理者等に設定操作によって、フォワード対象のＵＲＬとフォワード先のＵＲＬとの組の設定（以下、「プロキシ設定」という。）がＷｅｂプロキシ設定記憶部１５２に登録される（Ｓ１０１）。例えば、以下のような設定がＷｅｂプロキシ設定記憶部１５２に登録される。
［フォワード対象ＵＲＬ］（ＩＰアドレス）／ＬｅｇａｃｙＳＤＫ／ｐｒｉｎｔ／＊：８０８０
［フォワード先ＵＲＬ］（ＩＰアドレス）／ＳｍａｒｔＳＤＫ／ｃｏｍｐａｔｉｂｉｌｉｔｙ／ｐｒｉｎｔ／：８０
このように、プロキシ設定には「＊」のようなワイルドカードが指定されてもよい。なお、フォワード対象ＵＲＬとフォワード先ＵＲＬとのＩＰアドレスが共通する場合には、ＩＰアドレスは省略されてよい。また、フォワード対象ＵＲＬとフォワード先ＵＲＬとについて、複数の組がプロキシ設定に含まれてもよい。

上記のようなプロキシ設定の場合、例えば、
「／ＬｅｇａｃｙＳＤＫ／ｐｒｉｎｔ／ＧｅｔＪｏｂＩｎｆｏ：８０８０」をＵＲＬとするＨＴＴＰリクエストは、
「／ＳｍａｒｔＳＤＫ／ｃｏｍｐａｔｉｂｉｌｉｔｙ／ｐｒｉｎｔ／ＧｅｔＪｏｂＩｎｆｏ：８０」へフォワードされる。
「／ＬｅｇａｃｙＳＤＫ／ｐｒｉｎｔ／ＰｏｓｔＪｏｂＤａｔａ：８０８０」をＵＲＬとするＨＴＴＰリクエストは、
「／ＳｍａｒｔＳＤＫ／ｃｏｍｐａｔｉｂｉｌｉｔｙ／ｐｒｉｎｔ／ＰｏｓｔＪｏｂＤａｔａ：８０」へフォワードされる。

ここで、「／ＳｍａｒｔＳＤＫ／ｃｏｍｐａｔｉｂｉｌｉｔｙ／ｐｒｉｎｔ／ＧｅｔＪｏｂＩｎｆｏ：８０」は、印刷Ｗｅｂアプリ１２３が公開するＵＲＬである「／ＳｍａｒｔＳＤＫ／ｐｒｉｎｔ／ＧｅｔＪｏｂＩｎｆｏ：８０」に対応させて非互換吸収部１２５が公開する、「ＧｅｔＪｏｂＩｎｆｏ」に関する非互換の解消要求（吸収要求）に相当するＵＲＬである。また、「／ＳｍａｒｔＳＤＫ／ｃｏｍｐａｔｉｂｉｌｉｔｙ／ｐｒｉｎｔ／ＰｏｓｔＪｏｂＤａｔａ：８０」は、印刷Ｗｅｂアプリ１２３が公開するＵＲＬである「／ＳｍａｒｔＳＤＫ／ｐｒｉｎｔ／ＰｏｓｔＪｏｂＤａｔａ：８０」に対応させて非互換吸収部１２５が公開する、「ＰｏｓｔＪｏｂＤａｔａ」に関する非互換の解消要求（吸収要求）に相当するＵＲＬである。なお、プロキシ設定は、画像形成装置１０ａの操作パネル１５を介して行われてもよいし、リモートからネットワーク経由で行われてもよい。

その後、新ＳＤＫＰＦ起動管理部１２２によって新ＳＤＫプラットフォーム１２１が起動されると、Ｗｅｂコンテナ１２４が起動され、更に、印刷Ｗｅｂアプリ１２３及び非互換吸収部１２５が起動される。非互換吸収部１２５は、起動に応じ、自身が公開するＵＲＬ（非互換の解消要求に相当するＵＲＬ）をＷｅｂプロキシ設定記憶部１５２から取得し（Ｓ１１１、Ｓ１１２）、当該ＵＲＬを公開するＵＲＬのリストとしてＷｅｂコンテナ１２４に登録する（Ｓ１１３）。Ｗｅｂプロキシ設定記憶部１５２に記憶されているＵＲＬのうち、フォワード先ＵＲＬが、非互換吸収部１２５が公開するＵＲＬに相当する。したがって、非互換吸収部１２５は、フォワード先ＵＲＬの一覧をＷｅｂプロキシ設定記憶部１５２から取得する。但し、非互換吸収部１２５が公開するＵＲＬは、Ｗｅｂプロキシ設定記憶部１５２ではなく、非互換吸収部１２５の管理下に有る記憶領域に記憶されていてもよい。なお、印刷Ｗｅｂアプリ１２３も、一般的なＷｅｂアプリと同様に、自らが公開するＵＲＬをＷｅｂコンテナ１２４に登録する。

また、Ｗｅｂコンテナ１３４ａの起動時に、Ｗｅｂプロキシアプリ１３３は、フォワード対象ＵＲＬ及びフォワード先ＵＲＬの組の一覧をＷｅｂプロキシ設定記憶部１５２から取得する（Ｓ１２１、Ｓ１２２）。続いて、Ｗｅｂプロキシアプリ１３３は、取得した一覧に含まれているフォワード対象ＵＲＬを、Ｗｅｂプロキシアプリ１３３に対応するＵＲＬとしてＷｅｂコンテナ１３４ａに登録する（Ｓ１２３）。その結果、Ｗｅｂコンテナ１３４ａは、当該フォワード対象ＵＲＬに対応するＷｅｂアプリが、Ｗｅｂプロキシアプリ１３３であることを認識することができる。

その後、Ｗｅｂコンテナ１３４ａは、旧機種の画像形成装置１０ｂの印刷ＵＩアプリ１３５ｂからの旧機種のインタフェース仕様に従ったＨＴＴＰリクエスト（以下、「対象リクエスト」という。）を受信すると（Ｓ１３１）、対象リクエストのＵＲＬに対応するＷｅｂアプリが有するメソッド（ｄｏＧｅｔ、ｄｏＰｏｓｔ等）のうち、対象リクエストのメソッド（ＧＥＴメソッド、ＰＯＳＴメソッド等）に対応するメソッドを呼び出す。対象リクエストのＵＲＬに対応するＷｅｂアプリとは、当該ＵＲＬをＷｅｂコンテナ１３４ａに登録したＷｅｂアプリをいう。したがって、対象リクエストのＵＲＬが、いずれかのフォワード対象ＵＲＬであれば、Ｗｅｂプロキシアプリ１３３のメソッド（ｄｏＧｅｔ、ｄｏＰｏｓｔ等）が呼び出される（Ｓ１３２）。当該メソッドの引数には、対象リクエストのＵＲＬや対象リクエストの内容等を含む情報が指定される。

Ｗｅｂプロキシアプリ１３３は、当該メソッドの呼び出しに応じ、新ＳＤＫＰＦ起動管理部１２２に対して、新ＳＤＫプラットフォーム１２１のＷｅｂコンテナ１２４の起動状態を照会する（Ｓ１３３、Ｓ１３４）。なお、新ＳＤＫＰＦ起動管理部１２２は、画像形成装置１０ａの起動時等において、新ＳＤＫプラットフォーム１２１を起動する。したがって、新ＳＤＫＰＦ起動管理部１２２は、新ＳＤＫプラットフォーム１２１及び新ＳＤＫプラットフォーム１２１に含まれるＷｅｂコンテナ１２４が正常に起動されたか否かを把握しているため、Ｗｅｂコンテナ１２４の起動状態の照会に対して応答することができる。

Ｗｅｂコンテナ１２４が起動していない場合、Ｗｅｂプロキシアプリ１３３は、Ｗｅｂコンテナ１３４ａを介して、５００系もしくは４００系のエラーコードを含むＨＴＴＰレスポンスをクライアントに返信する。Ｗｅｂコンテナ１２４が起動していない場合に、リクエストがタイムアウトするまで待機（ｗａｉｔ）が発生することを回避するためである。

一方、Ｗｅｂコンテナ１２４が起動中である場合、Ｗｅｂプロキシアプリ１３３は、呼び出されたメソッドに対応するメソッド（ＧＥＴメソッド、ＰＯＳＴメソッド等）を含むＨＴＴＰリクエストであって、対象リクエストのＵＲＬに対してフォワード先ＵＲＬとして対応付けられているＵＲＬを宛先とするとともに、当該ＵＲＬを当該メソッドのＵＲＩとするＨＴＴＰリクエスト（以下、「フォワードリクエスト」という。）を生成し、当該フォワードリクエストのポート番号（８０）に対応するＷｅｂコンテナ１２４に当該フォワードリクエストを送信する（Ｓ１３５）。なお、対象リクエストとフォワードリクエストとの間で、メソッドやヘッダ等の内容は基本的には同じであるが、必要に応じて変更が行われてもよい。なお、当該フォワードリクエストは、実質的に、非互換の解消要求に相当する。

Ｗｅｂコンテナ１２４は、フォワードリクエストを受信すると、当該フォワードリクエストのＵＲＬの登録元である非互換吸収部１２５が有するメソッドのうち、フォワードリクエストのメソッドに対応するメソッド（ｄｏＧｅｔ、ｄｏＰｏｓｔ等）を呼び出す（Ｓ１３６）。当該メソッドの引数には、フォワードリクエストのＵＲＬやフォワードリクエストの内容等を含む情報が指定される。

非互換吸収部１２５は、当該メソッドの呼び出しに応じ、当該メソッドに関して、旧ＳＤＫプラットフォーム１３１ａ上の印刷Ｗｅｂアプリ１３６ｂと、新ＳＤＫプラットフォーム１２１上の印刷Ｗｅｂアプリ１２３との非互換部分を解消（吸収）するための処理を実行する（Ｓ１３７）。例えば、フォワードリクエストのＵＲＬが、新ＳＤＫプラットフォーム１２１の印刷Ｗｅｂアプリ１２３のＡＰＩである「／ＳｍａｒｔＳＤＫ／ｐｒｉｎｔ／ＧｅｔＪｏｂＩｎｆｏ：８０」に対応する「／ＳｍａｒｔＳＤＫ／ｃｏｍｐａｔｉｂｉｌｉｔｙ／ｐｒｉｎｔ／ＧｅｔＪｏｂＩｎｆｏ：８０」であったとする。また、新ＳＤＫプラットフォーム１２１の印刷Ｗｅｂアプリ１２３のＡＰＩである「／ＳｍａｒｔＳＤＫ／ｐｒｉｎｔ／ＧｅｔＪｏｂＩｎｆｏ：８０」は、旧ＳＤＫプラットフォーム１３１ａの印刷Ｗｅｂアプリ１３６ｂにおいて当該ＡＰＩに対応する「／ＬｅｇａｃｙＳＤＫ／ｐｒｉｎｔ／ＧｅｔＪｏｂＩｎｆｏ：８０８０」に対して、パラメータの相違点（過不足等）が有るとする。この場合、非互換吸収部１２５は、当該相違点について、新ＳＤＫプラットフォーム１２１の印刷Ｗｅｂアプリ１２３のＡＰＩに適合するようにフォワードリクエストの内容を変更する。具体的には、非互換吸収部１２５は、新ＳＤＫプラットフォーム１２１の印刷Ｗｅｂアプリ１２３のＡＰＩに新しいパラメータが追加されていれば、当該新しいパラメータの既定値を、フォワードリクエストに追加してもよい。また、非互換吸収部１２５は、新ＳＤＫプラットフォーム１２１の印刷Ｗｅｂアプリ１２３のＡＰＩにおいて不要となっているパラメータが有れば、当該パラメータを削除してもよい。

続いて、非互換吸収部１２５は、印刷Ｗｅｂアプリ１２３が有するメソッドのうち、非互換部分が解消された（非互換部分の変更後の）フォワードリクエストのメソッドに対応するメソッドを呼び出す（Ｓ１３８）。当該メソッドの引数には、フォワードリクエストのＵＲＬに対応するＷｅｂアプリのＡＰＩのＵＲＬや、フォワードリクエストの内容等を含む情報が指定される。その結果、画像形成装置１０ｂ（印刷ＵＩアプリ１３５）にとっては未知である新ＳＤＫプラットフォーム１２１上のＷｅｂアプリのＡＰＩが呼び出される。フォワードリクエストのＵＲＬに対応するＷｅｂアプリのＡＰＩのＵＲＬとは、例えば、フォワードリクエストのＵＲＬが「／ＳｍａｒｔＳＤＫ／ｃｏｍｐａｔｉｂｉｌｉｔｙ／ｐｒｉｎｔ／ＧｅｔＪｏｂＩｎｆｏ：８０」であれば、「／ＳｍａｒｔＳＤＫ／ｐｒｉｎｔ／ＧｅｔＪｏｂＩｎｆｏ：８０」である。すなわち、本実施の形態では、非互換吸収部１２５のＡＰＩのＵＲＬは、印刷Ｗｅｂアプリ１２３のＡＰＩのＵＲＬにおいて「ＳｍａｒｔＳＤＫ」の後に「ｃｏｍｐａｔｉｂｉｌｉｔｙ」が挿入されたものとなっている。

続いて、印刷Ｗｅｂアプリ１２３は、呼び出されたメソッド及び当該メソッドに指定された引数の内容に応じた処理を実行し、当該処理の結果を非互換吸収部１２５に出力する（Ｓ１３９）。非互換吸収部１２５は、当該処理結果をＷｅｂコンテナ１２４に出力する（Ｓ１４０）。なお、非互換吸収部１２５は、当該処理結果に関しても、非互換部分を解消（吸収）するための処理を実行してもよい。例えば、処理結果のデータ形式について非互換が有る場合、非互換吸収部１２５は、画像形成装置１０ｂ（印刷ＵＩアプリ１３５）が期待しているデータ形式となるように、当該処理結果を変更してもよい。

続いて、Ｗｅｂコンテナ１２４は、当該処理結果（非互換が吸収された場合には、非互換の吸収後の処理結果）を含むＨＴＴＰレスポンスを、フォワードリクエストの送信元であるＷｅｂプロキシアプリ１３３へ返信する（Ｓ１４１）。Ｗｅｂプロキシアプリ１３３は、当該ＨＴＴＰレスポンスに含まれている処理結果をＷｅｂコンテナ１３４ａへ出力する（Ｓ１４２）。Ｗｅｂコンテナ１３４ａは、当該処理結果を含むＨＴＴＰレスポンスを、対象リクエストの送信元である画像形成装置１０ｂ（印刷ＵＩアプリ１３５）へ返信する（Ｓ１４３）。その結果、画像形成装置１０ｂ（印刷ＵＩアプリ１３５）から見て、画像形成装置１０ａが、画像形成装置１０ｂと互換性を有しているように見える。

なお、上記では、非互換吸収部１２５を介して、パラメータの非互換が吸収される例を示したが、旧ＳＤＫプラットフォーム１３１ａの印刷Ｗｅｂアプリ１３６ｂと新ＳＤＫアプリの印刷Ｗｅｂアプリ１２３との間で、ＵＲＬのみが異なり、パラメータが同じである場合には、Ｗｅｂコンテナ１２４は、Ｗｅｂプロキシアプリ１３３からのＨＴＴＰリクエストの受信に応じ、印刷Ｗｅｂアプリ１２３のメソッドを呼び出すようにしてもよい。この場合、Ｗｅｂプロキシ設定記憶部１５２には、フォワード先ＵＲＬとして、印刷Ｗｅｂアプリ１２３が公開するＵＲＬが設定されればよい。

なお、図４では、Ｗｅｂプロキシアプリ１３３が、対象リクエストに対応するフォワードリクエストをフォワード先に送信する例について説明したが、Ｗｅｂプロキシアプリ１３３は、対象リクエストの送信元である画像形成装置１０ｂ（印刷ＵＩアプリ１３５）に対して、フォワード先へのリダイレクション命令を含むＨＴＴＰレスポンスを返信するようにしてもよい。

例えば、Ｗｅｂプロキシアプリ１３３は、ＨＴＴＰレスポンスとして
ＨＴＴＰレスポンスコード：３０２
Ｌｏｃａｔｉｏｎ：／ＳｍａｒｔＳＤＫ／ｐｒｉｎｔ／ＧｅｔＪｏｂＩｎｆｏ：８０
を返信する。印刷ＵＩアプリ１３５は、当該ＨＴＴレスポンスに従ってＬｏｃａｔｉｏｎ先にリダイレクトする。続いて、ステップＳ１３６以降が実行される。

但し、この場合、画像形成装置１０ｂが、リダイレクションのレスポンスを解釈可能である必要がある。

なお、Ｗｅｂプロキシアプリ１３３が、フォワードを行うのかリダイレクションを行うのかについて、外部から（ユーザによって）設定可能とされてもよい。例えば、フォワードを行うのかリダイレクションを行うのかを示す情報が、Ｗｅｂプロキシ設定記憶部１５２に記憶されてもよい。この場合、Ｗｅｂプロキシアプリ１３３は、当該情報を参照して、フォワードリクエストをＷｅｂコンテナ１２４に送信するのか、リダイレクション命令をクライアント（画像形成装置１０ｂ）に送信するのかを決定すればよい。

また、図４では、Ｗｅｂアプリの一例である印刷Ｗｅｂアプリについて説明したが、本実施の形態は、印刷系のＷｅｂアプリだけでなく、スキャン系のＷｅｂアプリ等、他の機能に係るＷｅｂアプリの非互換の吸収についても有効である。いずれのＷｅｂアプリに対して本実施の形態を適用可能とするのかについては、Ｗｅｂプロキシ設定記憶部１５２の記憶内容を編集することで容易に変更可能である。

また、Ｗｅｂプロキシアプリ１３３は、Ｗｅｂアプリではなく、旧ＳＤＫプラットフォーム１３１ａに組み込まれた機能であってもよい。

ところで、図４では、Ｗｅｂコンテナ１３４ａが起動される場合の処理手順について説明したが、Ｗｅｂコンテナ１３４ａが起動されずに、Ｗｅｂコンテナ１４１が起動される場合には、図４においてＷｅｂコンテナ１３４ａ、Ｗｅｂプロキシアプリ１３３が実行する処理は、Ｗｅｂコンテナ１４１、Ｗｅｂプロキシアプリ１４３によって実行される。

続いて、起動対象のＷｅｂコンテナがどのように決定されるのかについて説明する。図５は、Ｗｅｂコンテナの起動処理の処理手順の一例を説明するためのシーケンス図である。図５の処理手順は、例えば、画像形成装置１０ａの起動時等において実行される。

まず、Ｗｅｂコンテナ起動部１４２は、旧ＳＤＫＰＦ起動管理部１３２ａからＳＤＫ起動設定情報を取得する（Ｓ２０１、Ｓ２０２）。ＳＤＫ起動設定情報は、旧ＳＤＫプラットフォーム１３１ａの自動起動が有効であるのか無効であるのかを示す情報である。ポートやＵＲＬのようなシステムリソースは、システム内の複数のモジュールによって競合されないようにする必要が有るが、旧ＳＤＫプラットフォーム１３１ａの自動起動が無効であれば、Ｗｅｂコンテナ１３４ａは起動しないため、Ｗｅｂコンテナ１４１を起動できる。但し、Ｗｅｂコンテナ１４１を起動するか否かは、Ｗｅｂコンテナ設定記憶部１５１における設定内容に依存する。これは、将来的に、旧機種が市場機から無くなり、全機器が新機種に移行した時点で、Ｗｅｂコンテナ１３４ａ及びＷｅｂコンテナ１４１を起動する必要が無くなった場合に、セキュリティの観点から、使用されないポートの開設を回避するためである。なお、Ｗｅｂコンテナ設定記憶部１５１に対する設定は、リモートからネットワーク経由で設定及び変更できてよい。

旧ＳＤＫプラットフォーム１３１ａの自動起動設定が無効である場合、Ｗｅｂコンテナ起動部１４２は、Ｗｅｂコンテナ設定記憶部１５１の設定内容を参照する（Ｓ２０３、Ｓ２０４）。当該設定内容が、Ｗｅｂコンテナ１４１の起動が必要であることを示す場合、Ｗｅｂコンテナ起動部１４２は、Ｗｅｂコンテナ１４１を起動する（Ｓ２０５）。当該設定内容が、Ｗｅｂコンテナ１４１の起動が不要であることを示す場合、Ｗｅｂコンテナ起動部１４２は、Ｗｅｂコンテナ１４１を起動しない。

一方、旧ＳＤＫプラットフォーム１３１ａの自動起動設定が有効である場合、旧ＳＤＫＰＦ起動管理部１３２ａが、Ｗｅｂコンテナ１３４ａを起動する（Ｓ２１１）。厳密には、旧ＳＤＫＰＦ起動管理部１３２ａが、旧ＳＤＫプラットフォーム１３１ａを起動することで、Ｗｅｂコンテナ１３４ａが起動される。

なお、旧ＳＤＫプラットフォーム１３１ａの自動起動設定が無効である場合、画像形成装置１０ａの起動後におけるユーザ（管理者等）の任意のタイミングで、旧ＳＤＫプラットフォーム１３１ａが起動される可能性も有る。その場合、旧ＳＤＫＰＦ起動管理部１３２ａは、旧ＳＤＫプラットフォーム１３１ａが起動することを全モジュール（もしくは登録されたモジュール）に通知する。当該モジュールには、Ｗｅｂコンテナ起動部１４２も含まれる。Ｗｅｂコンテナ起動部１４２は、当通知を受信した場合、Ｗｅｂコンテナ１４１のポートなどのシステムリソースを速やかに破棄し、旧ＳＤＫプラットフォーム１３１ａのＷｅｂコンテナ１３４ａが起動できるようにしてもよい。

図５に示す処理手順により、旧ＳＤＫプラットフォーム１３１ａが、将来的にアンインストールされたり、旧ＳＤＫプラットフォーム１３１ａの自動起動設定が無効とされたりした場合であっても、Ｗｅｂコンテナ１４１が起動されるため、画像形成装置１０ａは、旧機種からのＨＴＴＰリクエストを受信することが可能となる。

なお、本実施の形態では、画像形成装置１０が機器の一例とされたが、プロジェクタ、電子黒板、又はテレビ会議システム等の他の機器について本実施の形態が適用されてもよい。

上述したように、本実施の形態によれば、画像形成装置１０ａにとって非互換な処理要求（ＨＴＴＰリクエスト）が受信された場合であっても、Ｗｅｂプロキシアプリ１３３又はＷｅｂプロキシアプリ１４３と非互換吸収部１２５とによって、当該処理要求について非互換が解消された後で、印刷Ｗｅｂアプリ１２３に対して処理要求が入力される。したがって、本実施の形態によれば、処理要求に非互換が有る他の機器との連携を可能とすることができる。

なお、本実施の形態において、印刷Ｗｅｂアプリ１３６ｂは、第１のプログラムの一例である。印刷Ｗｅｂアプリ１２３は、第２のプログラムの一例である。「／ＬｅｇａｃｙＳＤＫ／ｐｒｉｎｔ／＊：８０８０」は、第１の処理要求の一例である。「／ＳｍａｒｔＳＤＫ／ｐｒｉｎｔ／：８０」は、第２の処理要求の一例である。「／ＳｍａｒｔＳＤＫ／ｃｏｍｐａｔｉｂｉｌｉｔｙ／ｐｒｉｎｔ／：８０」は、解消要求の一例である。Ｗｅｂコンテナ１３４ａ又はＷｅｂコンテナ１４１は、受信部の一例である。Ｗｅｂプロキシアプリ１３３又はＷｅｂプロキシアプリ１４３は、生成部の一例である。非互換吸収部１２５は、変更部の一例である。画像形成装置１０ｂは、第１の機器の一例である。画像形成装置１０ａは、第２の機器の一例である。

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

１ 情報処理システム
１０ 画像形成装置
１１ コントローラ
１２ スキャナ
１３ プリンタ
１４ モデム
１５ 操作パネル
１６ ネットワークインタフェース
１７ ＳＤカードスロット
８０ ＳＤカード
１１１ ＣＰＵ
１１２ ＲＡＭ
１１３ ＲＯＭ
１１４ ＨＤＤ
１１５ ＮＶＲＡＭ
１２１ 新ＳＤＫプラットフォーム
１２２ 新ＳＤＫＰＦ起動管理部
１２３ 印刷Ｗｅｂアプリ
１２４ Ｗｅｂコンテナ
１２５ 非互換吸収部
１３１ａ 旧ＳＤＫプラットフォーム
１３２ａ 旧ＳＤＫＰＦ起動管理部
１３３ Ｗｅｂプロキシアプリ
１３４ａ Ｗｅｂコンテナ
１３１ｂ 旧ＳＤＫプラットフォーム
１３２ｂ 旧ＳＤＫＰＦ起動管理部
１３４ｂ Ｗｅｂコンテナ
１３５ｂ 印刷ＵＩアプリ
１３６ｂ 印刷Ｗｅｂアプリ
１４１ Ｗｅｂコンテナ
１４２ Ｗｅｂコンテナ起動部
１４３ Ｗｅｂプロキシアプリ
１５１ Ｗｅｂコンテナ設定記憶部
１５２ Ｗｅｂプロキシ設定記憶部

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

Claims (9)

1. 第１のプログラムに対する第１の処理要求に対応する第２の処理要求を受け付ける第２のプログラムをインストール可能な機器であって、
   ネットワークを介して前記第１の処理要求を受信する受信部と、
   前記受信部による前記第１の処理要求の受信に応じ、前記第１の処理要求と前記第２の処理要求との非互換部分の解消要求を生成する生成部と、
   前記解消要求に応じ、前記第１の処理要求に含まれている情報を前記第２の処理要求に適合するように変更し、変更後の情報を含む前記第２の処理要求を前記第２のプログラムに入力する変更部と、
   を有することを特徴とする機器。
2. 前記変更部は、前記第１の処理要求に含まれているパラメータを前記第２の処理要求に適合するように変更し、変更後のパラメータを含む前記第２の処理要求を前記第２のプログラムに入力する、
   ことを特徴とする請求項１記載の機器。
3. 前記生成部は、複数の前記第１の処理要求のそれぞれごとに、当該第１の処理要求に対応する前記解消要求に関する情報を記憶した記憶部を参照して、前記受信部によって受信された前記第１の処理要求に対応する前記解消要求を生成する、
   ことを特徴とする請求項１又は２記載の機器。
4. 前記第１の処理要求及び前記第２の処理要求は、ＨＴＴＰリクエストである、
   ことを特徴とする請求項１乃至３いずれか一項記載の機器。
5. 前記生成部は、前記解消要求のリダイレクション命令を生成し、前記リダイレクション命令を前記第１の処理要求の送信元に送信し、
   前記変更部は、前記リダイレクション命令に応じて前記送信元から送信される前記解消要求に応じ、前記第１の処理要求に含まれている情報の変更を行う、
   ことを特徴とする請求項３記載の機器。
6. 前記生成部は、リダイレクション命令を生成することが記憶部に記憶されている場合に、前記リダイレクション命令を生成する、
   ことを特徴とする請求項４記載の機器。
7. 第１の処理要求を受け付ける第１のプログラムをインストール可能な第１の機器と、前記第１の処理要求に対応する第２の処理要求を受け付ける第２のプログラムをインストール可能な第２の機器とを含む情報処理システムであって、
   前記第２の機器は、
   前記第１の機器からネットワークを介して前記第１の処理要求を受信する受信部と、
   前記受信部による前記第１の処理要求の受信に応じ、前記第１の処理要求と前記第２の処理要求との非互換部分の解消要求を生成する生成部と、
   前記解消要求に応じ、前記第１の処理要求に含まれている情報を前記第２の処理要求に適合するように変更し、変更後の情報を含む前記第２の処理要求を前記第２のプログラムに入力する変更部と、
   を有することを特徴とする情報処理システム。
8. 第１のプログラムに対する第１の処理要求に対応する第２の処理要求を受け付ける第２のプログラムをインストール可能な機器が、
   ネットワークを介して前記第１の処理要求を受信する受信手順と、
   前記受信手順における前記第１の処理要求の受信に応じ、前記第１の処理要求と前記第２の処理要求との非互換部分の解消要求を生成する生成手順と、
   前記解消要求に応じ、前記第１の処理要求に含まれている情報を前記第２の処理要求に適合するように変更し、変更後の情報を含む前記第２の処理要求を前記第２のプログラムに入力する変更手順と、
   を実行することを特徴とする情報処理方法。
9. 第１のプログラムに対する第１の処理要求に対応する第２の処理要求を受け付ける第２のプログラムをインストール可能な機器に、
   ネットワークを介して前記第１の処理要求を受信する受信手順と、
   前記受信手順における前記第１の処理要求の受信に応じ、前記第１の処理要求と前記第２の処理要求との非互換部分の解消要求を生成する生成手順と、
   前記解消要求に応じ、前記第１の処理要求に含まれている情報を前記第２の処理要求に適合するように変更し、変更後の情報を含む前記第２の処理要求を前記第２のプログラムに入力する変更手順と、
   を実行させることを特徴とする情報処理プログラム。

Images