JP4190991B2 - ネットサービス機能を有する情報処理装置およびネットサービス提供方法 - Google Patents

Description

本発明はネットサービス機能を有する情報処理装置およびネットサービス提供方法に関するものである。

近年、プリンタ、コピー、ファクシミリ、スキャナ等の各装置の機能を一つの筐体内に収納した、複合機あるいは融合機と呼ばれる画像形成装置が提供されるに至っている。更に、これらの画像形成装置は、オフィス内のイントラネット等に接続可能とされ、Ｗｅｂサービス等の各種のネットサービスを提供する機能も有している。

ところで、上述したネットサービス機能を有した従来の画像形成装置にあっては、ブラウザ等のＨＴＴＰクライアントからのリクエストをＨＴＴＰデーモン（ｈｔｔｐｄ）と呼ばれるサーバプログラムで処理しており、ＨＴＴＰデーモンはリクエストに含まれるＵＲＬパスに従って対応するＷｅｂアプリケーションに処理をディスパッチ（振り分け）し、処理のレスポンスをＨＴＴＰクライアントに戻すまでの処理を行っている。ここで、ＨＴＴＰデーモン（ｈｔｔｐｄ）と呼ばれるサーバプログラムは、一般には単一のポート番号（例えば「８０」）で識別され単独でＷｅｂサービスを提供するもの（例えばフリーのＷｅｂサーバソフトで有名な「Ａｐａｃｈｅ」等）を意味することが多いが、画像形成装置の分野では上述したような意味で用いられている。これは、画像形成装置に要求される多数の機能を満たすため、一般のネットサービスよりも細分化されたプロトコルを処理する必要があるためである。

ネットサービス機能を有した従来の画像形成装置におけるＨＴＴＰデーモンの動作をより詳しく説明すると次のようになる。

先ず、ＨＴＴＰデーモンはサービスに固定的に割り当てられたポートを起動時に全てオープンする。例えば、通常のＨＴＴＰ通信はポート「８０」、ＳＳＬ（Ｓｅｃｕｒｅ Ｓｏｃｋｅｔｓ Ｌａｙｅｒ）を使ったＨＴＴＰ通信はポート「４４３」、画像形成装置に特有のＩＰＰ（Ｉｎｔｅｒｎｅｔ Ｐｒｉｎｔｉｎｇ Ｐｒｏｔｏｃｏｌ）はポート「６３１」といったものである。

次いで、ＨＴＴＰデーモンは自己がオープンしたポートで受け付けたＨＴＴＰリクエストに対し、ＨＴＴＰリクエストに含まれるＵＲＬパスのチェックを行い、対応するＷｅｂアプリケーションに処理をディスパッチする。例えば、Ｗｅｂアプリケーション「Ｗｅｂｓｙｓ」のＵＲＬパスが「／ｗｅｂｓｙｓ／ａａａ」と定めてあった場合、ＨＴＴＰリクエストにＵＲＬパス「／ｗｅｂｓｙｓ／ａａａ」が指定されていた場合はＷｅｂアプリケーション「Ｗｅｂｓｙｓ」に処理をディスパッチする。このとき特にポート番号のチェックは行わず、ＵＲＬパスのチェックが通ればどのポート番号で受け付けたＨＴＴＰリクエストであっても対応するＷｅｂアプリケーションにディスパッチが行われる。なお、対応するＵＲＬパスが存在しない場合はエラーを返すことになる。

その後、Ｗｅｂアプリケーションで処理が行われ、結果としてＨＴＭＬ，ＸＭＬ，ＴＥＸＴ等の文書が生成されると、ＨＴＴＰデーモンはリクエスト元のＨＴＴＰクライアントに結果を返す。

一方、装置内のアドレス可能な部分（例えば、プロセス）へのメッセージの経路をポート番号を用いて選択する先行技術が開示されている（例えば、特許文献１参照。）。

また、設計者が詳細を記述することなく特定のプラットフォーム向けのソフトウェアを容易に開発することができる方法等についての先行技術が開示されている（例えば、特許文献２参照。）。
特表２００２−５２３９２４号公報 特開２０００−２５０７５５号公報

上述した従来のネットサービス機能を有した画像形成装置におけるＨＴＴＰデーモンの動作は一般のＷｅｂサーバとは異なる特徴的なものであるが、次のような問題点があった。

すなわち、ＵＲＬパスのチェックが通ればどのポート番号で受け付けたＨＴＴＰリクエストであっても対応するＷｅｂアプリケーションに処理が渡ってしまうことから、Ｗｅｂアプリケーションが想定していないポート番号からのＨＴＴＰアクセスを受け付けてしまう可能性があり、セキュリティ上の問題（セキュリティホールになりかねないという問題）があった。

また、遠隔診断サービス：ＮＲＳ（Ｎｅｗ Ｒｅｍｏｔｅ Ｓｅｒｖｉｃｅ）と呼ばれるような契約した特別なユーザしか使用しないアプリケーションに対応するポートがオープンされている可能性もあり、そのポートを介した不正アクセスなど、実際に使用していないポートがオープンされていることによるセキュリティ上の問題（セキュリティホールになりかねないという問題）があった。なお、実際に使用していないポートがオープンされる場合としては、上記のＮＲＳの他に、ファックスボードが実装されていない場合にファックスアプリケーション用のポートがオープンされる場合など、画像形成装置では多くの原因が考えられる。

また、予め定められたポート番号が固定的に割り当てられてしまうため、独自のポート番号を用いた通信を行うことができず、Ｗｅｂアプリケーション側の自由度が低いという問題もあった。

以上の点はＨＴＴＰデーモンについてだけでなく、ＦＴＰデーモン（ｆｔｐｄ）等の他のネットサービスを扱うプロトコルデーモンについても同様に言える問題である。

一方、昨今ではサードパーティー（外部のソフトハウス等）によるアプリケーション開発を促進させるためＳＤＫ（Ｓｏｆｔｗａｒｅ Ｄｅｖｅｌｏｐｍｅｎｔ Ｋｉｔ）と呼ばれる開発環境を提供することが多くなってきており、例えば画像形成装置上で動作可能な「特定業種向け文書管理ソフト」といったＳＤＫアプリケーションも作成されることが想定される。

ところで、このようなＳＤＫアプリケーションがネットサービス機能を伴う場合には、利用するポートを自由に選びたいというニーズに応える必要が出てくるが、従来の画像形成装置のプロトコルデーモンのメカニズムでは対応することができなかった。

更に、サードパーティー製のＳＤＫアプリケーションを実行することを許容する以上、セキュリティについてもより慎重にならざるを得ず、上述した想定していないポート番号からの不正アクセス、および、使用されていないアプリケーション用のポートがオープンされているという問題を解決することも重要となっていた。

本発明は上記の問題点に鑑み提案されたものであり、その目的とするところは、画像形成装置を含む情報処理装置において、ＳＤＫアプリケーションがネットサービスに利用する任意のポートを選択可能とすると共に、ポートアクセスにおけるセキュリティの向上を図ることのできるネットサービス機能を有する情報処理装置およびネットサービス提供方法を提供することにある。

上記課題を解決するため、本発明は、請求項１に記載されるように、複数のポートから入ってくるリクエストをプロトコルデーモンが受け付け、当該リクエストに含まれるアプリケーションを特定する情報に基づいてアプリケーションに処理のディスパッチを行うネットサービス機能を有する情報処理装置において、上記アプリケーションからの依頼に基づき新たなポートを登録すると共に、上記アプリケーション毎に処理を受け付けるポートを対応付けて登録するポート登録部と、上記リクエストを受け付けたときに上記アプリケーションに対応するポートを取得して当該リクエストのポートと一致するか否かをチェックし、一致した場合にのみアプリケーションへのディスパッチを行うリクエスト処理部とを上記プロトコルデーモン内に備えるように構成している。

これにより、ＳＤＫアプリケーション等がネットサービスで使用する任意のポートを登録することができ、ニーズに応えることができる。また、想定しないポートからのリクエストがアプリケーションに渡ることがなくなり、セキュリティの向上を図ることができる。更に、アプリケーション毎に処理を受け付けるポートを登録するため、アプリケーション側のポート選定の自由度が高まる。

また、本発明は、請求項２に記載されるように、上記ポート登録部は、上記情報処理装置の起動後に上記アプリケーションからの依頼に基づいて処理を受け付けるポートの登録を行うと共に、登録の完了したポートについて動的にオープンするように構成することができる。

これにより、使われないポートについて不用意にオープンとされることがなくなり、セキュリティの向上を図ることができる。

また、本発明は、請求項３に記載されるように、上記ポートを登録する処理の後に処理の結果を示すメッセージをオペレーションパネルに表示するように構成することができる。これにより、ＳＤＫアプリケーションを導入する際に行う設定が適切に行われたか否かが明確になる。

また、本発明は、請求項４に記載されるように、上記ポート登録部と上記リクエスト処理部は、処理対象のポートの区別にポート識別子を用いように構成することができる。これにより、ポート番号を一斉に変更するような場合に容易に対応することができる。

また、本発明は、請求項５に記載されるように、上記ポート登録部は、ポート識別子と実際のポート番号とを対応付けて管理するポート識別子／ポート番号対応テーブルと、上記アプリケーションを識別するアプリＩＤと上記ポート識別子とを対応付けて管理するアプリＩＤ／ポート識別子対応テーブルとを用いてポートの登録を行うように構成することができる。これにより、データを適切に管理することができる。

また、本発明は、請求項６に記載されるように、上記ポート登録部は、上記アプリケーション毎に処理を受け付けるポートを対応付けて登録するに際し、上記アプリケーション毎にリクエストのディスパッチに用いるＵＲＬパスの登録を行うように構成することができる。これにより、アプリケーションからの依頼を連続して統一的に行うことができる。

また、本発明は、請求項７に記載されるように、上記ポート登録部は、上記アプリケーションを識別するアプリＩＤとＵＲＬパスとを対応付けて管理するアプリＩＤ／ＵＲＬパス対応テーブルを用いてＵＲＬパスの登録を行うように構成することができる。これにより、データを適切に管理することができる。

また、本発明は、請求項８に記載されるように、上記リクエスト処理部は、ポート識別子と実際のポート番号とを対応付けて管理するポート識別子／ポート番号対応テーブルからリクエストのポート番号に対応する第１のポート識別子を取得し、上記アプリケーションを識別するアプリＩＤとＵＲＬパスとを対応付けて管理するアプリＩＤ／ＵＲＬパス対応テーブルからリクエストのＵＲＬパスに対応するアプリＩＤを取得し、上記アプリケーションを識別するアプリＩＤと上記ポート識別子とを対応付けて管理するアプリＩＤ／ポート識別子対応テーブルから上記リクエストのＵＲＬパスに対応するアプリＩＤに更に対応する第２のポート識別子を取得し、上記第１および第２のポート識別子を比較することでポートの一致を判断するように構成することができる。これにより、リクエストを通過させるべきか否かのチェックを適切に行うことができる。

また、本発明は、請求項９に記載されるように、上記ポート識別子／ポート番号対応テーブルは上記プロトコルデーモンとは独立して管理されるように構成することができる。これにより、他のデーモン等のプロセスからもポート識別子／ポート番号対応テーブルを参照することが容易になる。

また、本発明は、請求項１０に記載されるように、上記アプリＩＤ／ポート識別子対応テーブルは上記プロトコルデーモンの下で管理されるように構成することができる。これにより、自己の管理下で適切に使用することができる。

また、本発明は、請求項１１に記載されるように、上記アプリＩＤ／ＵＲＬパス対応テーブルは上記プロトコルデーモンの下で管理されるようにすることができる。これにより、自己の管理下で適切に使用することができる。

また、本発明は、請求項１２に記載されるように、上記プロトコルデーモンはＨＴＴＰプロトコルデーモンであるものとすることができる。これにより、特に需要の多いＷｅｂサービスに適切に対応することができる。

また、本発明は、請求項１３に記載されるように、ＳＤＫアプリケーションの格納されたメモリカードとの間でプログラムおよびデータの入出力を行うメモリカードインタフェースを備えるように構成することができる。これにより、外部から容易にＳＤＫアプリケーションを導入することができる。

また、本発明は、請求項１４に記載されるように、複数のポートから入ってくるリクエストをプロトコルデーモンが受け付け、当該リクエストに含まれるＵＲＬパスに基づいてアプリケーションに処理のディスパッチを行う情報処理装置のネットサービス提供方法において、上記プロトコルデーモンが、上記アプリケーションからの依頼に基づき新たなポートを登録すると共に、上記アプリケーション毎に処理を受け付けるポートを対応付けて登録する手順と、上記プロトコルデーモンが、上記リクエストを受け付けたときに上記アプリケーションに対応するポートを取得して当該リクエストのポートとが一致するか否かをチェックし、一致した場合にのみアプリケーションへのディスパッチを行う手順とを備えるネットサービス提供方法として構成することができる。

また、本発明は、請求項１５に記載されるように、上記プロトコルデーモンは、上記情報処理装置の起動後に上記アプリケーションからの依頼に基づいて処理を受け付けるポートの登録を行うと共に、登録の完了したポートについてオープンするネットサービス提供方法として構成することができる。

本発明によれば、ＳＤＫアプリケーション側から処理を受け付けるポートを任意に登録可能であるため、アプリケーション側のポート選定の自由度を高めることができる。また、想定しないポートからのリクエストがアプリケーションに渡ることがなくなると共に、使われないポートについて不用意にオープンとされることがなくなり、ポートアクセスにおけるセキュリティの向上を図ることができる。

以下、本発明の実施の形態を図面に基づいて説明する。

図１は本発明を画像形成装置に適用した一実施例に係る画像形成装置の機能構成を示すブロック図である。

図１において、画像形成装置１は、アプリケーション層２とプラットフォーム層４とエンジン部８とを含む。インタフェース３はアプリケーション層２に対するプラットフォーム層４の提供するインタフェース（ＡＰＩ）であり、インタフェース７はプラットフォーム層４とエンジン部８との間のインタフェース（エンジンＩ／Ｆ）である。

アプリケーション層２は画像形成装置１における個別の処理を行うソフトウェア群であり、コピー用のアプリケーションであるコピーアプリケーション２１と、ファックス用のアプリケーションであるファックスアプリケーション２２と、プリンタ用のアプリケーションであるプリンタアプリケーション２３と、ネットワークを介してファイルのやりとりを行うネットファイル用のアプリケーションであるネットファイルアプリケーション２４とを含む。また、Ｗｅｂアプリケーション２０はＨＴＴＰプロトコルによるＷｅｂサービスを行うアプリケーション群であり、ブラウザを使って機器の状態を見たり、機器のネットワーク設定等をすることができるＷｅｂアプリケーション（Ｗｅｂｓｙｓ）２５と、ネットファイルアプリケーション２４の機能を使い、ブラウザを使って文書の引き取りおよび文書管理を行うＷｅｂアプリケーション（ｗｅｂｄｏｃｂｏｘ）２６と、プリンタのジョブ履歴（スプールの状態）等を表示するＷｅｂアプリケーション（ＧＰＳ−ｗｅｂ）２７と、ファックスの初期設定やファックスの通信管理レポート（通信履歴）を表形式で見ることのできるＷｅｂアプリケーション（Ｆａｘ−ｗｅｂ）２８とを含む。

また、ＮＲＳアプリケーション２９は従来技術の部分でも説明したように、遠隔診断サービス：ＮＲＳ（Ｎｅｗ Ｒｅｍｏｔｅ Ｓｅｒｖｉｃｅ）と呼ばれる、契約した特別なユーザに提供される遠隔診断サービスを行うアプリケーションである。

更に、ＳＤＫアプリケーション２００はサードパーティーによって開発されたアプリケーションであり、例えば「特定業種向け文書管理ソフト」といったようなものである。

なお、図では省略してあるが、アプリケーションとインタフェース３の間にはアプリケーションに対して共通的な機能を提供しソフトウェア開発を容易にするためのライブラリ（プラットフォーム）が適宜に設けられる。

一方、プラットフォーム層４はアプリケーション層２のアプリケーション２１〜２９，２００に対してインタフェース３を介して共通的なサービス機能を提供するソフトウェア群であり、サービス層５とＯＳ層６に分かれる。サービス層５には、アプリケーション管理、操作部制御、システム画面表示、ＬＥＤ表示、リソース管理、および割り込み制御等の複数の機能を有するＳＣＳ５１と、ファックス機能のＡＰＩを提供するＦＣＳ５２と、エンジン部の制御を行うＥＣＳ５３と、メモリ制御を行うＭＣＳ５４と、オペレータ（操作者）とのインタフェースとなる操作部（オペレーションパネル）の制御を行うＯＣＳ５５と、ネットワーク入出力を必要とするアプリケーションに対して共通に利用できるサービスを提供するＮＣＳ５６とが含まれる。ＯＳ層６にはＯＳ（ＬＰＵＸ）６１が含まれる。

一方、エンジン部８には、プロッタ８１、スキャナ８２、その他ハードウェアリソース８３等のエンジンと、これらのエンジンを制御するエンジン制御ボード８４とが含まれる。

図２は図１に示す画像形成装置のハードウェア構成を示すブロック図である。

図２において、画像形成装置１は、画像形成装置における主たる制御動作を行うコントローラ１０１にオペレーションパネル１１３とファックスコントロールユニット１１４とプロッタ８１とスキャナ８２とその他ハードウェアリソース８３とが接続されて構成されている。

コントローラ１０１は、画像処理用途向けのＩＣであるＡＳＩＣ１０２にブリッジとしてのＮＢ１０５を介して一般制御用のＩＣであるＣＰＵ１０６が接続され、ＮＢ１０５のバス（ＰＣＩ ＢＵＳ）に、周辺デバイス等との接続を行うブリッジであるＳＢ１０８と、ネットワーク通信を制御するＮＩＣ１０９と、ＵＳＢインタフェースを提供するＵＳＢ１１０と、ＩＥＥＥ１３９４インタフェースを提供するＩＥＥＥ１３９４１１１と、セントロニクスインタフェースを提供するセントロニクス１１２と、ＳＤＫアプリケーション２００の格納されたメモリカード１１６との間でプログラムおよびデータの入出力を行うメモリカードインタフェース１１５とが接続され、ＡＳＩＣ１０２に記憶装置としてのＭＥＭ−Ｃ１０３とＨＤＤ１０４が接続され、ＮＢ１０５に記憶装置としてのＭＥＭ−Ｐ１０７が接続されて構成されている。なお、メモリカードインタフェース１１５はＵＳＢ１１０の機能の一部または全部を利用するものとしてもよい。

図３は図１に示す画像形成装置のネットサービス機能に関する部分の機能構成を示すブロック図である。

図３において、ＮＣＳ５６は図１のサービス層５におけるものと同じであり、本発明の機能に関係する内部構成のみを示している。なお、図３の上部に同名のＮＣＳ５６Ａが示されており、ＮＣＳ５６と一体をなすものであるが、機能的に分けて示してある。

ＮＣＳ５６にはインタフェース３を介し、ＳＤＫアプリケーション２００が配置されている。

また、ＮＣＳ５６にはインタフェース３を介し、Ｗｅｂアプリライブラリ２０２およびＷｅｂページライブラリ２０１を挟んで、Ｗｅｂアプリケーション（Ｗｅｂｓｙｓ）２５等のＷｅｂアプリケーション２０が配置されている。

一方、ＮＣＳ５６にはＨＴＴＰのプロトコルに関する処理を行うＨＴＴＰデーモン５６１と、ＦＴＰのプロトコルに関する処理を行うＦＴＰデーモン５６４が含まれており、ＨＴＴＰデーモン５６１にはＩＰＰライブラリ２０３を介してプリンタアプリケーション２３が配置されている。ここで、ＩＰＰライブラリ２０３はＨＴＴＰのプロトコルを使った印刷であるＩＰＰ（Ｉｎｔｅｒｎｅｔ Ｐｒｉｎｔｉｎｇ Ｐｒｏｔｏｃｏｌ）に対応させるためのものであり、ＨＴＴＰデーモン５６１から直接にＩＰＰライブラリ２０３を経由してプリンタアプリケーション２３にジョブを渡すようにしている。

一方、ＨＴＴＰクライアント９はネットワークを経由してリクエストを出しレスポンスを受ける部分であり、通常はパーソナルコンピュータ上で稼動するブラウザである。

ＨＴＴＰデーモン５６１の内部構成について説明すると、ＨＴＴＰデーモン５６１には、アプリケーション（２００，２５，２３等）からの依頼に基づき新たなポートを登録すると共に、アプリケーション毎に処理を受け付けるポートを対応付けて登録する処理等を行うポート登録部５６２と、ネットワークを経由してＨＴＴＰクライアント９からリクエストを受け付けたときにアプリケーションに対応するポートを取得して当該リクエストのポートとが一致するか否かをチェックし、一致した場合にのみアプリケーションへのディスパッチを行うリクエスト処理部５６３と、アプリケーションを識別するアプリＩＤとＵＲＬパスとを対応付けて管理するアプリＩＤ／ＵＲＬパス対応テーブルＴ２と、アプリケーションを識別するアプリＩＤとポート識別子とを対応付けて管理するアプリＩＤ／ポート識別子対応テーブルＴ３とを含んでいる。

ここで、「ＵＲＬパス」とはＨＴＴＰリクエストを例えば「http://xxx.xxx.xxx.xxx/web/user/ja/websys/webArch/mainFrame.cgi」とした場合、ホスト「xxx.xxx.xxx.xxx」の次から最後までの「web/user/ja/websys/webArch/mainFrame.cgi」部分を意味するものである。ちなみに、ホスト「xxx.xxx.xxx.xxx」に続く１階層分の「web」部分は「アプリケーションパス」と呼ばれる。

また、アプリＩＤ／ＵＲＬパス対応テーブルＴ２およびアプリＩＤ／ポート識別子対応テーブルＴ３はＨＴＴＰデーモン５６１の管理するメモリ上に配置される。これは、他のプロセスでは使用されないデータであると共に、セキュリティの確保からデータを適切に管理するためである。なお、アプリＩＤ／ＵＲＬパス対応テーブルＴ２およびアプリＩＤ／ポート識別子対応テーブルＴ３は画像形成装置１の起動直後は空の状態であり、その後のポート登録部５６２の動作によりデータが登録されていく。

また、ＨＴＴＰデーモン５６１のポート登録部５６２からはＯＣＳ５５に対してメッセージ表示のための依頼が送られるようになっており、ＯＣＳ５５にはオペレーションパネル１１３が接続されている。

一方、ＮＣＳ５６の外にポート識別子と実際のポート番号とを対応付けて管理するポート識別子／ポート番号対応テーブルＴ１が設けられている。このポート識別子／ポート番号対応テーブルＴ１はハードディスク装置等にファイルとして存在すると共に、画像形成装置１の起動後はメモリ上にコピーされて使用されるものである。これは、ポート識別子とポート番号の対応を示すに過ぎないものであると共に、他のプロセス、例えばＦＴＰデーモン５６４等によって参照される可能性のあるデータであるからである。なお、ポート識別子／ポート番号対応テーブルＴ１は予めポート識別子とポート番号とが管理者等によって登録されているものであると共に、後述するようにアプリケーション側からも登録が可能となっている。

図４はポート識別子／ポート番号の登録の処理手順を示すシーケンス図である。

以下、図４に沿ってポート識別子／ポート番号の登録の処理手順を説明する。

先ず、画像形成装置１の起動後の任意の時点でいずれかのアプリケーション（２００，２５，２３等）から利用するポート番号と対応するポート識別子の登録の依頼がＨＴＴＰデーモン５６１に対して行われると（ステップＳ１）、ＨＴＴＰデーモン５６１のポート登録部５６２はポート識別子／ポート番号対応テーブルＴ１を参照して依頼されたポート識別子が既に登録されているか否かを確認する（ステップＳ２）。

そして、登録されていなかった場合、ＨＴＴＰデーモン５６１のポート登録部５６２はポート識別子／ポート番号対応テーブルＴ１に対してポート番号とポート識別子とを対応付けて登録する（ステップＳ３）。既に登録されていた場合は重複して登録は行わない。

その後、ＨＴＴＰデーモン５６１のポート登録部５６２は処理結果の表示をＯＣＳ５５に依頼し（ステップＳ４）、ＯＣＳ５５はオペレーションパネル１１３を制御して結果を表示する（ステップＳ５）。

図５は上記のポート識別子／ポート番号の登録におけるアプリケーションからの依頼とテーブルに登録される内容の関係を示す図である。

図５においては、ＳＤＫアプリケーション２００から依頼Ｄ１としてポート番号「２００３」、ポート識別子「Ｎｅｗ Ｐｏｒｔ」の登録依頼があったものとしており、これが新たなポートとしてポート識別子／ポート番号対応テーブルＴ１に登録された状態を示している。

また、図６および図７は上記のポート識別子／ポート番号の登録におけるオペレーションパネル１１３でのメッセージの例を示す図である。すなわち、ポート識別子／ポート番号の登録が成功した場合には、図６に示すように「ポート識別子ＮｅｗＰｏｒｔの登録に成功しました。」というメッセージＭ１が画面の上部に一行メッセージとして表示される。また、登録が失敗した場合には、図７に示すように「ポート識別子の登録に失敗しました。ポート識別子ＮｅｗＰｏｒｔは既に登録されています。」というメッセージＭ２が画面の上部に一行メッセージとして表示される。なお、一行メッセージとは、画像形成装置に致命的でないエラー等につき行われる簡易型のメッセージである。

図８はアプリＩＤ／ＵＲＬパスおよびアプリＩＤ／ポート識別子の登録の処理手順を示すシーケンス図である。

以下、図８に沿ってアプリＩＤ／ＵＲＬパスおよびアプリＩＤ／ポート識別子の登録の処理手順を説明する。

先ず、画像形成装置１の起動後の任意の時点でいずれかのアプリケーション（２００，２５，２３等）から、自己を示すアプリＩＤを伴って利用するＵＲＬパスの登録の依頼がＨＴＴＰデーモン５６１に対して行われると（ステップＳ１１）、ＨＴＴＰデーモン５６１のポート登録部５６２はアプリＩＤ／ＵＲＬパス対応テーブルＴ２を参照し、依頼されたアプリＩＤとＵＲＬパスの組み合わせが既に登録されているか否かを確認する（ステップＳ１２）。

そして、登録されていなかった場合、ＨＴＴＰデーモン５６１のポート登録部５６２はアプリＩＤ／ＵＲＬパス対応テーブルＴ２に対して依頼されたアプリＩＤとＵＲＬパスとを対応付けて登録する（ステップＳ１３）。既に登録されていた場合は重複して登録は行わない。

その後、ＨＴＴＰデーモン５６１のポート登録部５６２は処理結果の表示をＯＣＳ５５に依頼し（ステップＳ１４）、ＯＣＳ５５はオペレーションパネル１１３を制御して結果を表示する（ステップＳ１５）。

次いで、アプリケーションから自己へのアクセスを許可するリクエストのポートに対応するポート識別子の登録の依頼が行われると（ステップＳ１６）、ＨＴＴＰデーモン５６１のポート登録部５６２は依頼元のアプリケーションを識別するアプリＩＤと指定されたポート識別子を対応付けてアプリＩＤ／ポート識別子対応テーブルＴ３に登録する（ステップＳ１７）。

次いで、ＨＴＴＰデーモン５６１のポート登録部５６２はポート識別子／ポート番号対応テーブルＴ１を参照し、登録の完了したポート識別子に対応するポート番号を取得し（ステップＳ１８）、そのポート番号のポートがオープンされているか否かを判断した上でオープンされていない場合（クローズの場合）はそのポートを動的にオープンする（ステップＳ１９）。

図９は上記のアプリＩＤ／ＵＲＬパスおよびアプリＩＤ／ポート識別子の登録におけるアプリケーションからの依頼とテーブルに登録される内容の関係を示す図である。

図９において、Ｗｅｂアプリケーション（Ｗｅｂｓｙｓ）２５， プリンタアプリケーション２３，ＳＤＫアプリケーション２００からそれぞれ依頼Ｄ２，Ｄ３，Ｄ４が前後して行われた場合、図８に示した処理手順により、アプリＩＤ／ＵＲＬパス対応テーブルＴ２およびアプリＩＤ／ポート識別子対応テーブルＴ３にデータが登録される。すなわち、例えば依頼Ｄ２については、依頼元のアプリケーションを識別するアプリＩＤ「Ｗｅｂｓｙｓ」と指定されたＵＲＬパス「／ｗｅｂｓｙｓ／ａａａ」「／ｗｅｂｓｙｓ／ｂｂｂ」が対応付けられてアプリＩＤ／ＵＲＬパス対応テーブルＴ２に登録され、アプリＩＤ「Ｗｅｂｓｙｓ」と指定されたポート識別子「ＨＴＴＰ」「ＨＴＴＰＳ」が対応付けられてアプリＩＤ／ポート識別子対応テーブルＴ３に登録される。

そして、個々の依頼Ｄ２〜Ｄ４につき、アプリＩＤ／ポート識別子対応テーブルＴ３への登録が完了した時点でポート識別子／ポート番号対応テーブルＴ１の参照を経由してポートがオープンされる。

このように、画像形成装置１の起動後に依頼のあったポートについてのみ登録を行い、動的にオープンするようにしているので、使われていないサービスに対応するポートが不用意にオープンされることがなくなり、不正なアクセスを低減させてセキュリティを向上させることができる。

また、図１０および図１１は上記のアプリＩＤ／ＵＲＬパスの登録におけるオペレーションパネル１１３でのメッセージの例を示す図である。すなわち、アプリＩＤ／ＵＲＬパスの登録が成功した場合には、図１０に示すように「ＵＲＬ ／ｓｄｋａｐｐ１／ｄｄｄの追加に成功しました。」というメッセージＭ３が画面の上部に一行メッセージとして表示される。また、登録が失敗した場合には、図１１に示すように「ＵＲＬの追加に失敗しました。／ｓｄｋａｐｐ１／ｄｄｄは既に登録されています。」というメッセージＭ４が画面の上部に一行メッセージとして表示される。

図１２はリクエスト受付時の処理手順を示すシーケンス図である。

図１２において、ＨＴＴＰクライアント９からネットワークを経由してリクエストが行われると（ステップＳ２１）、ＮＣＳ５６のＨＴＴＰデーモン５６１がそのリクエストを受け付ける。

そして、ＨＴＴＰデーモン５６１のリクエスト処理部５６３はリクエストを受け付けたポート番号を認識した上でポート識別子／ポート番号対応テーブルＴ１を参照し、そのポート番号に対応するポート識別子を取得する（ステップＳ２２）。

次いで、ＨＴＴＰデーモン５６１のリクエスト処理部５６３はリクエストで指定されたＵＲＬパスを認識した上でアプリＩＤ／ＵＲＬパス対応テーブルＴ２を参照し、そのＵＲＬパスに対応するアプリＩＤを取得する（ステップＳ２３）。

次いで、ＨＴＴＰデーモン５６１のリクエスト処理部５６３は取得したアプリＩＤに基づき、アプリＩＤ／ポート識別子対応テーブルＴ３を参照し、そのアプリＩＤに対応するポート識別子を取得する（ステップＳ２４）。

そして、ステップＳ２２で取得したポート識別子とステップＳ２４で取得したポート識別子とを比較し、一致する場合にはＵＲＬパスで指定されるアプリケーションにリクエストをディスパッチし（ステップＳ２５）、一致しない場合にはＨＴＴＰクライアント９に対してエラーを返す（ステップＳ２６）。

図１３は上記のリクエスト受付時のポートのチェックにおけるリクエストとテーブルの内容の関係を示す図である。

図１３において、到来したリクエストＲ１がポート番号「２００３」、ＵＲＬパス「／ｓｄｋａｐｐ１／ａａａ」であったとすると、図１２に示した処理手順により、リクエストＲ１のポート番号「２００３」からポート識別子／ポート番号対応テーブルＴ１の参照によりポート識別子「ＮｅｗＰｏｒｔ」が得られる。一方で、リクエストＲ１のＵＲＬパス「／ｓｄｋａｐｐ１／ａａａ」からアプリＩＤ／ＵＲＬパス対応テーブルＴ２の参照によりアプリＩＤ「ＳＤＫＡｐｐ１」が得られ、このアプリＩＤ「ＳＤＫＡｐｐ１」に基づきアプリＩＤ／ポート識別子対応テーブルＴ３の参照によりポート識別子「ＮｅｗＰｏｒｔ」が得られる。

ここで、両者が比較されることになるが、ここでは同じ「ＮｅｗＰｏｒｔ」であるため一致すると判断され、アプリケーションへのディスパッチが行われる。なお、比較はリクエストのポート番号とＵＲＬパスとからそれぞれ求めたポート識別子に共通のものがあるか否かという観点で一致を見るため、一方（アプリＩＤ／ポート識別子対応テーブルＴ３から求めたポート識別子）が複数となる場合であっても、両者の間に共通するものがあれば一致すると判断される。

このように、アプリケーションが予め登録したポートからのリクエストしかディスパッチしないようにしているので、想定しないポートからのリクエストがアプリケーションに渡ることがなくなり、セキュリティの向上を図ることができる。

上記の実施例においては、ＨＴＴＰデーモン５６１について説明したが、ＦＴＰデーモン５６４（図３）等の他のプロトコルデーモンについても同様である。すなわち、プロトコルデーモン内にポート登録部、リクエスト処理部、アプリＩＤ／ＵＲＬパス対応テーブル、アプリＩＤ／ポート識別子対応テーブルを設けることにより、他のプロトコルにおいても、想定しないポートからのリクエストを防止し、使用しないポートの不用意なオープンを防止することができる。

本発明の一実施例に係る画像形成装置の機能構成を示すブロック図である。 図１に示す画像形成装置のハードウェア構成を示すブロック図である。 図１に示す画像形成装置のＷｅｂサービス機能に関する部分の機能構成を示すブロック図である。 ポート識別子／ポート番号の登録の処理手順を示すシーケンス図である。 ポート識別子／ポート番号の登録におけるアプリケーションからの依頼とテーブルに登録される内容の関係を示す図である。 ポート識別子／ポート番号の登録が成功した際のオペレーションパネルにおけるメッセージの例を示す図である。 ポート識別子／ポート番号の登録が失敗した際のオペレーションパネルにおけるメッセージの例を示す図である。 アプリＩＤ／ＵＲＬパスおよびアプリＩＤ／ポート識別子の登録の処理手順を示すシーケンス図である。 アプリＩＤ／ＵＲＬパスおよびアプリＩＤ／ポート識別子の登録におけるアプリケーションからの依頼とテーブルに登録される内容の関係を示す図である。 アプリＩＤ／ＵＲＬパスの登録が成功した際のオペレーションパネルにおけるメッセージの例を示す図である。 アプリＩＤ／ＵＲＬパスの登録が失敗した際のオペレーションパネルにおけるメッセージの例を示す図である。 リクエスト受付時の処理手順を示すシーケンス図である。 リクエスト受付時のポートのチェックにおけるリクエストとテーブルの内容の関係を示す図である。

符号の説明

１ 画像形成装置
２０ Ｗｅｂアプリケーション
２５ Ｗｅｂアプリケーション（Ｗｅｂｓｙｓ）
２６ Ｗｅｂアプリケーション（ｗｅｂｄｏｃｂｏｘ）
２００ ＳＤＫアプリケーション
５６ ＮＣＳ
５６１ ＨＴＴＰデーモン
５６２ ポート登録部
５６３ リクエスト処理部
Ｔ１ ポート識別子／ポート番号対応テーブル
Ｔ２ アプリＩＤ／ＵＲＬパス対応テーブル
Ｔ３ アプリＩＤ／ポート識別子対応テーブル
１１５ メモリカードインタフェース
１１６ メモリカード

Claims (15)

1. 複数のポートから入ってくるリクエストをプロトコルデーモンが受け付け、当該リクエストに含まれるアプリケーションを特定する情報に基づいてアプリケーションに処理のディスパッチを行うネットサービス機能を有する情報処理装置において、
   上記アプリケーションからの依頼に基づき新たなポートを登録すると共に、上記アプリケーション毎に処理を受け付けるポートを対応付けて登録するポート登録部と、
   上記リクエストを受け付けたときに上記アプリケーションに対応するポートを取得して当該リクエストのポートと一致するか否かをチェックし、一致した場合にのみアプリケーションへのディスパッチを行うリクエスト処理部とを上記プロトコルデーモン内に備えたことを特徴とするネットサービス機能を有する情報処理装置。
2. 上記ポート登録部は、上記情報処理装置の起動後に上記アプリケーションからの依頼に基づいて処理を受け付けるポートの登録を行うと共に、登録の完了したポートについて動的にオープンする請求項１に記載のネットサービス機能を有する情報処理装置。
3. 上記ポートを登録する処理の後に処理の結果を示すメッセージをオペレーションパネルに表示する請求項１または２のいずれか一項に記載のネットサービス機能を有する情報処理装置。
4. 上記ポート登録部と上記リクエスト処理部は、処理対象のポートの区別にポート識別子を用いた請求項１乃至３のいずれか一項に記載のネットサービス機能を有する情報処理装置。
5. 上記ポート登録部は、ポート識別子と実際のポート番号とを対応付けて管理するポート識別子／ポート番号対応テーブルと、上記アプリケーションを識別するアプリＩＤと上記ポート識別子とを対応付けて管理するアプリＩＤ／ポート識別子対応テーブルとを用いてポートの登録を行う請求項４に記載のネットサービス機能を有する情報処理装置。
6. 上記ポート登録部は、上記アプリケーション毎に処理を受け付けるポートを対応付けて登録するに際し、上記アプリケーション毎にリクエストのディスパッチに用いるＵＲＬパスの登録を行う請求項１乃至５のいずれか一項に記載のネットサービス機能を有する情報処理装置。
7. 上記ポート登録部は、上記アプリケーションを識別するアプリＩＤとＵＲＬパスとを対応付けて管理するアプリＩＤ／ＵＲＬパス対応テーブルを用いてＵＲＬパスの登録を行う請求項６に記載のネットサービス機能を有する情報処理装置。
8. 上記リクエスト処理部は、ポート識別子と実際のポート番号とを対応付けて管理するポート識別子／ポート番号対応テーブルからリクエストのポート番号に対応する第１のポート識別子を取得し、上記アプリケーションを識別するアプリＩＤとＵＲＬパスとを対応付けて管理するアプリＩＤ／ＵＲＬパス対応テーブルからリクエストのＵＲＬパスに対応するアプリＩＤを取得し、上記アプリケーションを識別するアプリＩＤと上記ポート識別子とを対応付けて管理するアプリＩＤ／ポート識別子対応テーブルから上記リクエストのＵＲＬパスに対応するアプリＩＤに更に対応する第２のポート識別子を取得し、上記第１および第２のポート識別子を比較することでポートの一致を判断する請求項４乃至７のいずれか一項に記載のネットサービス機能を有する情報処理装置。
9. 上記ポート識別子／ポート番号対応テーブルは上記プロトコルデーモンとは独立して管理される請求項５または８のいずれか一項に記載のネットサービス機能を有する情報処理装置。
10. 上記アプリＩＤ／ポート識別子対応テーブルは上記プロトコルデーモンの下で管理される請求項５または８のいずれか一項に記載のネットサービス機能を有する情報処理装置。
11. 上記アプリＩＤ／ＵＲＬパス対応テーブルは上記プロトコルデーモンの下で管理される請求項７または８のいずれか一項に記載のネットサービス機能を有する情報処理装置。
12. 上記プロトコルデーモンはＨＴＴＰプロトコルデーモンである請求項１乃至１１のいずれか一項に記載のネットサービス機能を有する情報処理装置。
13. ＳＤＫアプリケーションの格納されたメモリカードとの間でプログラムおよびデータの入出力を行うメモリカードインタフェースを備えた請求項１乃至１２のいずれか一項に記載のネットサービス機能を有する情報処理装置。
14. 複数のポートから入ってくるリクエストをプロトコルデーモンが受け付け、当該リクエストに含まれるＵＲＬパスに基づいてアプリケーションに処理のディスパッチを行う情報処理装置のネットサービス提供方法において、
    上記プロトコルデーモンが、上記アプリケーションからの依頼に基づき新たなポートを登録すると共に、上記アプリケーション毎に処理を受け付けるポートを対応付けて登録する手順と、
    上記プロトコルデーモンが、上記リクエストを受け付けたときに上記アプリケーションに対応するポートを取得して当該リクエストのポートとが一致するか否かをチェックし、一致した場合にのみアプリケーションへのディスパッチを行う手順とを備えたネットサービス提供方法。
15. 上記プロトコルデーモンは、上記情報処理装置の起動後に上記アプリケーションからの依頼に基づいて処理を受け付けるポートの登録を行うと共に、登録の完了したポートについてオープンする請求項１４に記載のネットサービス提供方法。
    

Images