(57)【要約】【課題】  情報処理装置がファイアウォールで守られていたり、ネットワークアドレス変換を用いる環境にある場合には、Ｗｅｂサーバからの要求を受け付けることができなかった。【解決手段】  Ｗｅｂサーバにより提供される操作画面を表示可能なＷｅｂブラウザを備えた情報処理装置とその制御方法であって、Ｗｅｂブラウザからのリクエストに応答してＷｅｂサーバから処理要求を受信すると、その処理要求で要求された処理を実行する。その際、Ｗｅｂサーバから受信した処理要求が所定の情報を含むかどうかを判定し、所定の情報を含むと判定すると、処理要求とセキュリティ情報とを処理手段に転送し、その転送された処理要求が予め定められた送信元からの処理要求である場合に処理手段により、その処理要求に対応する処理を実行させる。【選択図】  図５
2014235667.tif 000002
【特許請求の範囲】
【請求項１】
Ｗｅｂサーバにより提供される操作画面を表示可能なＷｅｂブラウザを備えた情報処理装置であって、
前記Ｗｅｂブラウザからのリクエストに応答して前記Ｗｅｂサーバから処理要求を受信すると、前記処理要求で要求された処理を実行する処理手段と、
前記Ｗｅｂサーバから受信した前記処理要求が所定の情報を含むかどうかを判定する判定手段と、
前記判定手段が前記処理要求が所定の情報を含むと判定すると、前記処理要求とセキュリティ情報とを前記処理手段に転送する転送手段と、
前記転送手段により転送された前記処理要求が予め定められた送信元からの処理要求である場合に前記処理手段により前記処理要求に対応する処理を実行させるように制御する制御手段と、
を有することを特徴とする情報処理装置。
【請求項２】
前記転送手段により転送された前記処理要求の送信元は、前記情報処理装置或いは前記Ｗｅｂサーバであり、前記制御手段は、前記処理要求の送信元が前記情報処理装置の場合は、前記セキュリティ情報に基づいて前記送信元を識別することを特徴とする請求項１に記載の情報処理装置。
【請求項３】
前記処理要求は、前記ＷｅｂサーバからのＨＴＴＰレスポンスに含まれ、前記所定の情報は前記ＨＴＴＰレスポンスのヘッダのＣｏｎｔｅｎｔ−Ｔｙｐｅフィールドに含まれていることを特徴とする請求項１に記載の情報処理装置。
【請求項４】
前記予め定められた送信元を記憶する記憶手段を更に有し、前記制御手段は、前記記憶手段に記憶された前記予め定められた送信元を参照して、前記転送手段により転送された前記処理要求が予め定められた送信元からの処理要求かどうかを判定することを特徴とする請求項１乃至３のいずれか１項に記載の情報処理装置。
【請求項５】
前記セキュリティ情報は、前記処理要求を送信した送信元のアドレス及び暗号化の有無を示す情報を含むことを特徴とする請求項１乃至４のいずれか１項に記載の情報処理装置。
【請求項６】
前記処理要求に対する処理結果を前記Ｗｅｂサーバにアップロードするアップロード手段を更に有することを特徴とする請求項１乃至５のいずれか１項に記載の情報処理装置。
【請求項７】
Ｗｅｂサーバにより提供される操作画面を表示可能なＷｅｂブラウザを備えた情報処理装置を制御する制御方法であって、
処理手段が、前記Ｗｅｂブラウザからのリクエストに応答して前記Ｗｅｂサーバから処理要求を受信すると、前記処理要求で要求された処理を実行する処理工程と、
判定手段が、前記Ｗｅｂサーバから受信した前記処理要求が所定の情報を含むかどうかを判定する判定工程と、
転送手段が、前記判定工程が前記処理要求が所定の情報を含むと判定すると、前記処理要求とセキュリティ情報とを前記処理工程に転送する転送工程と、
制御手段が、前記転送工程により転送された前記処理要求が予め定められた送信元からの処理要求である場合に前記処理工程により前記処理要求に対応する処理を実行させるように制御する制御工程と、
を有することを特徴とする情報処理装置の制御方法。
【請求項８】
コンピュータを、請求項１乃至６のいずれか１項に情報処理装置として機能させるためのプログラム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、Ｗｅｂサーバに接続され、そのＷｅｂサーバから提供される操作画面を表示するＷｅｂブラウザを備えた情報処理装置とその制御方法、プログラムに関する。
【背景技術】
【０００２】
ＰＣ等の情報処理装置がネットワーク上のＷｅｂサーバに接続され、そのＷｅｂサーバにより提供される操作画面を、その情報処理装置が備えるＷｅｂブラウザで表示することが知られている。この場合、まず情報処理装置のＷｅｂブラウザが、Ｗｅｂサーバに対して操作画面の情報を要求（リクエスト）する。この要求に応えて、ＷｅｂサーバのＷｅｂアプリケーションが、Ｗｅｂブラウザに操作画面を表示させるためのＨＴＭＬデータを情報処理装置に送信（レスポンス）する。これにより情報処理装置のＷｅｂブラウザは、受信したＨＴＭＬデータを解析し、そのＨＴＭＬデータの記述に基づいた操作画面を表示する。更に、Ｗｅｂブラウザで表示された操作画面を介してユーザが指示を入力すると、その入力された指示をＷｅｂブラウザがＷｅｂサーバに対して通知する。そして、この通知を受けたＷｅｂサーバのＷｅｂアプリケーションは、その入力された指示に従って処理を実行する。
【０００３】
ところで、最近ではスキャナやプリンタを備えた複合機（ＭＦＰ）にも、上述したようなＷｅｂブラウザを備えているものがある。そのようなＭＦＰは、上述した手順を用いてＷｅｂサーバより提供される操作画面をＭＦＰのＷｅｂブラウザで表示し、ユーザからの各種指示を受け付ける。また更には、ＭＦＰが備える各種機能を利用するための指示を入力する操作画面をＷｅｂサーバが提供し、ユーザが、その提供された操作画面を介して、ＭＦＰに対する指示を入力するシステムも考えられている。このシステムでは、Ｗｅｂサーバは、ユーザから入力された指示の内容に従って、ＭＦＰに対して各種処理の実行を依頼する。この依頼を受けたＭＦＰのジョブ実行モジュールは、依頼された処理を実行する。これにより、ＭＦＰを操作するための全ての操作画面情報をＭＦＰで保持する必要がなくなり、また操作画面の変更もＷｅｂサーバで容易に行うことができるようになる。
【０００４】
具体的には、ＭＦＰの各機能をＲＰＣ（Ｒｅｍｏｔｅ  Ｐｒｏｃｅｄｕｒｅ  Ｃａｌｌ）で公開し、Ｗｅｂサーバから適宜、指示された機能を呼び出す方法が考えられている。この方法では、Ｗｅｂサーバに処理のメインロジックを持たせ、ＭＦＰの制御やユーザとの対話的処理をＷｅｂサーバに実行させることにより、ＭＦＰの処理の負荷を軽減できる。例えばＷｅｂサービスとしてＭＦＰの機能を公開することで、ＭＦＰがＷｅｂサーバのローカルなサブルーチンを呼び出して、ＭＦＰが提供する機能を実行できる。また、その呼び出しの応答を管理することで、処理のメインロジックをＷｅｂサーバに持たせることができる。
【０００５】
しかしながらＲＰＣは、クライアントが要求メッセージをサーバに送信することで開始されるため、サービスを提供するサーバに、クライアントから通信コネクションを行う必要がある。即ち、この方法では、ＭＦＰがファイアウォールで守られていたり、ネットワークアドレス変換を用いる環境にある場合、ＭＦＰは外部ネットワークに存在するＷｅｂサーバからのＲＰＣ要求を受け付けることができない。これはファイアウォールは、一般的に内部から外部への接続は許可するが、外部から内部への接続は許可しないためである。また、ＭＦＰがアドレス変換を用いる環境にある場合は、サーバ側からＭＦＰを特定できないためである。
【０００６】
そこで、デバイスのＷｅｂブラウザで表示された操作画面を介して入力された指示に基づいてＷｅｂサーバが制御スクリプトを提供し、そのデバイスがその制御スクリプトを実行することで操作することが考えられる。制御スクリプトは、Ｗｅｂブラウザからのリクエストに対する応答としてＷｅｂブラウザが受信し、ジョブ実行モジュールに転送される。そのため、ＷｅｂサーバからＭＦＰにコネクションを張る必要がなく、ＭＦＰがファイアウォールで守られていたり、ネットワークアドレス変換を用いる環境にある場合でも利用できる。
【０００７】
しかしながら、このような仕組みを用いた場合、ジョブ実行モジュールは、処理要求の依頼元のサーバが複数ある場合に、どのサーバから依頼であるかを知ることができない。なぜならば、制御スクリプトを受信するのはＷｅｂブラウザであり、ジョブ実行モジュールはＷｅｂブラウザから転送される制御スクリプトを受け取っているにすぎないからである。例えば、ジョブ実行モジュールが、デバイスや、利用しているユーザの情報を提供するためのモジュールであった場合、セキュリティの観点から、ジョブ実行モジュールは、特定のサーバからの依頼のみを実行したい場合があるが、上記の問題により実現できない。
【０００８】
そこで特許文献１のような技術が考えられている。特許文献１に記載の方法では、ＷｅｂブラウザがＷｅｂサーバにアクセスする際のＨＴＴＰリクエストヘッダに、必要となる情報を載せることによって、Ｗｅｂサーバにデバイスの情報を通知する。また、この際に、アクセスするＵＲＩが、予め記憶されているパターンと一致するかどうかを判断し、一致する場合に情報を送信する。
【先行技術文献】
【特許文献】
【０００９】
【特許文献１】特開２０１１−８３４９号公報
【発明の概要】
【発明が解決しようとする課題】
【００１０】
しかしながら、特許文献１の方法では、ＷｅｂブラウザがＷｅｂサーバにアクセスする度に情報が付加されるため、送る情報が多い場合には、通信コストがかかってしまうという問題がある。また、セキュリティの観点からも、Ｗｅｂアプリケーションが必要としない場合は情報を送信せず、送信の回数は最小限に抑えるのが望ましい。
【００１１】
本発明の目的は、上記従来技術の問題点を解決することにある。
【００１２】
本発明の特徴は、情報処理装置がファイアウォールで守られている場合でも、信頼するＷｅｂサーバだけから情報を取得でき、かつ情報処理装置からの情報の送信を最小限にする技術を提供することにある。
【課題を解決するための手段】
【００１３】
上記目的を達成するために本発明の一態様に係る情報処理装置は以下のような構成を備える。即ち、
Ｗｅｂサーバにより提供される操作画面を表示可能なＷｅｂブラウザを備えた情報処理装置であって、
前記Ｗｅｂブラウザからのリクエストに応答して前記Ｗｅｂサーバから処理要求を受信すると、前記処理要求で要求された処理を実行する処理手段と、
前記Ｗｅｂサーバから受信した前記処理要求が所定の情報を含むかどうかを判定する判定手段と、
前記判定手段が前記処理要求が所定の情報を含むと判定すると、前記処理要求とセキュリティ情報とを前記処理手段に転送する転送手段と、
前記転送手段により転送された前記処理要求が予め定められた送信元からの処理要求である場合に前記処理手段により前記処理要求に対応する処理を実行させるように制御する制御手段と、を有することを特徴とする。
【発明の効果】
【００１４】
本発明によれば、情報処理装置がファイアウォールで守られている場合でも、信頼するＷｅｂサーバだけから情報を取得でき、かつ情報処理装置からの情報の送信を最小限にできるという効果がある。
【図面の簡単な説明】
【００１５】
【図１】本発明の実施形態に係る情報処理装置を収容する通信システムの構成例を示す図。
【図２】本実施形態に係るＭＦＰのハードウェア構成を説明するブロック図。
【図３】実施形態に係るサーバのハードウェア構成を説明するブロック図。
【図４】本実施形態に係る通信システム全体のソフトウェア構成を説明するための図。
【図５】本実施形態に係る通信システムにおける一連の処理の流れを説明するシーケンス図。
【図６】実施形態に係るＭＦＰのサービスプロバイダによる処理を説明するフローチャート。
【図７】本実施形態に係るＷｅｂアプリケーションがＷｅｂブラウザに対して返すＨＴＴＰレスポンスヘッダの一例を示す図。
【図８】レスポンスとして返す処理要求の内容例を示す図で、（Ａ）はＷｅｂアプリケーションが生成してＷｅｂブラウザにレスポンスとして返す例を示し、（Ｂ）はサービスプロバイダが生成して転送アプリケーションにレスポンスとして返す例を示し、（Ｃ）はサービスプロバイダが生成して転送アプリケーションにレスポンスとして返すエラー結果例を示す図。
【図９】転送アプリケーションが処理要求をサービスプロバイダに転送する際のＨＴＴＰリクエストヘッダの内容例を示す図。
【図１０】実施形態に係るＭＦＰの信頼情報記憶部に記憶されている信頼情報の内容例を示す図。
【発明を実施するための形態】
【００１６】
以下、添付図面を参照して本発明の実施形態を詳しく説明する。尚、以下の実施形態は特許請求の範囲に係る本発明を限定するものでなく、また本実施形態で説明されている特徴の組み合わせの全てが本発明の解決手段に必須のものとは限らない。
【００１７】
図１は、本発明の実施形態に係る情報処理装置（ＭＦＰ）を収容する通信システムの構成例を示す図である。この実施形態では、Ｗｅｂサーバに接続され、そのＷｅｂサーバから提供される操作画面を表示可能なＷｅｂブラウザを備えた複合機（ＭＦＰ）を例に説明するが、本発明はこれに限定されるものでなく、ＰＣ等の情報処理装置であっても良い。
【００１８】
この通信システムは、ネットワーク１００を介して接続されるＭＦＰ１０１とサーバ１０２とを有している。ネットワーク１００は各装置間で通信を行うための基盤であって、インターネット１０３に接続されている。ＭＦＰ１０１はＷｅｂブラウザ機能を有していれば、一般的なＰＣ等の情報処理装置であっても良い。更に、ＭＦＰ１０１はローカルなＩＰアドレスで管理されていても良い。その場合、ネットワーク１００とＭＦＰ１０１の間にゲートウェイ（不図示）が存在し、そのゲートウェイはアドレス変換を行う。例えばゲートウェイにはルータが含まれる。またゲートウェイやＭＦＰ１０１がファイアウォール機能を備えていても良い。サーバ１０２は、Ｗｅｂコンテンツをネットワークを介して配信する機能を持っており、ＭＦＰ１０１からのリクエストに応じてＷｅｂコンテンツを返す。
【００１９】
図２は、本実施形態に係るＭＦＰ１０１のハードウェア構成を説明するブロック図である。
【００２０】
実施形態に係るＭＦＰ１０１は、ＣＰＵ２０１，ＣＰＵ２０１のワークエリアを提供するＲＡＭ２０２、原稿の画像を読み取る読取部２０３、画像を印刷する印刷部２０４を有する。記憶部２０５は、ＣＰＵ２０１が実行するプログラムや様々な設定等を記憶している。この記憶部２０５は、例えばＨＤＤ（ハードディスクドライブ）やＮＶＲＡＭ（不揮発メモリ）等でもよい。更に、ユーザがコマンドの入力を行う入力部２０６、操作画面などを表示する表示部２０７、他機器とネットワークによる通信を行うネットワーク・インターフェース（Ｉ／Ｆ）２０８、メインバス２００を有している。尚、本実施形態では、特に断らない限り、ＭＦＰ１０１はＣＰＵ２０１がメインバス２００を介してＲＡＭ２０２、読取部２０３、印刷部２０４、記憶部２０５、入力部２０６、表示部２０７、ネットワーク・インターフェース２０８を制御する。またタッチパネルディスプレイのように表示部２０７が入力部２０６を兼ねても良い。
【００２１】
図３は、実施形態に係るサーバ１０２のハードウェア構成を説明するブロック図である。
【００２２】
サーバ１０２は、ＣＰＵ３０１、ＣＰＵ３０１のワークエリアを提供するＲＡＭ３０２、ＣＰＵ３０１が実行するプログラム、各種設定等を記憶する記憶部３０３、他機器とネットワークによる通信を行うネットワーク・インターフェース３０４を備えている。メインバス３００は、上述した各部とＣＰＵ３０１とを接続して、データ信号や各種制御信号を伝送している。尚、本実施形態では特に断らない限り、ＣＰＵ３０１がメインバス３００を介してＲＡＭ３０２、記憶部３０３、ネットワーク・インターフェース３０４を制御する。
【００２３】
図４は、本実施形態に係る通信システム全体のソフトウェア構成を説明するための図である。
【００２４】
図４に示す各機能部は、ＭＦＰ１０１及びサーバ１０２のそれぞれが有しているＣＰＵ２０１或いはＣＰＵ３０１が、各対応する制御プログラムを実行することにより実現される。
【００２５】
サーバ１０２は、Ｗｅｂアプリケーション４１０、通信部４０１を有する。更に、Ｗｅｂアプリケーション４１０には、プレゼンテーション部４１１及びロジック部４１２が含まれる。
【００２６】
プレゼンテーション部４１１は、通信部４０１を介して受信したＭＦＰ１０１からのリクエストに応えて、ＭＦＰ１０１のＷｅｂブラウザ４２０で表示する操作画面、又はサービスプロバイダ４４０への処理要求を、ＭＦＰ１０１にレスポンスとして送信する。また、ＭＦＰ１０１のＷｅｂブラウザ４２０で表示された操作画面を介して入力されたユーザからの入力情報を、通信部４０１を介してＭＦＰ１０１から受け取る。
【００２７】
ロジック部４１２は、プレゼンテーション部４１１から渡されたＭＦＰ１０１からの入力情報に対して処理を行う。例えば、ユーザからの入力に応じて、表示すべき画面を変更したり、ＭＦＰ１０１の機能を実行させるための処理要求を作成する。通信部４０１は、ネットワーク・インターフェース３０４を制御してＨＴＴＰプロトコルにより通信を行うソフトウェアモジュールである。
【００２８】
一方、ＭＦＰ１０１は、Ｗｅｂブラウザ４２０、転送アプリケーション４３０、サービスプロバイダ４４０、信頼情報記憶部４５０を有している。Ｗｅｂブラウザ４２０、転送アプリケーション４３０、サービスプロバイダ４４０、信頼情報記憶部４５０のそれぞれは、ＭＦＰ１０１が有しているＣＰＵ２０１が制御プログラムを実行することにより実現される。尚、このＷｅｂブラウザ４２０は、サーバ１０２のコンテンツを表示するものに限定するものではない。同様に、サーバ１０２もＨＴＴＰプロトコルに従ってリクエスト及びレスポンスを送受信するＷｅｂサーバに限定するものではない。Ｗｅｂブラウザ４２０は、任意のサーバと通信を行うことによってコンテンツを取得し、画面に表示するといった機能を有するものであればよい。
【００２９】
Ｗｅｂブラウザ４２０は、通信部４２１、解析部４２２、画面表示部４２３、転送アプリ起動部４２４、及びアップロード処理部４２５を有する。通信部４２１は、ＨＴＴＰプロトコルに従って、サーバ１０２の通信部４０１を介してＷｅｂアプリケーション４１０のプレゼンテーション部４１１と通信する。より具体的には、通信部４２１は、Ｗｅｂブラウザ４２０で表示した操作画面を介して入力される情報を、Ｗｅｂアプリケーション４１０に対するリクエストとして送信する。また通信部４２１は、Ｗｅｂアプリケーション４１０から送信されるレスポンスを受信する。
【００３０】
解析部４２２は、Ｗｅｂアプリケーション４１０から受信したレスポンスを解析する。このレスポンスの中には、Ｗｅｂブラウザ４２０に表示すべき操作画面の内容を示す記述であるＨＴＭＬデータや、サービスプロバイダ４４０への処理要求が記載されている。解析部４２２は、ＨＴＴＰレスポンスヘッダのＣｏｎｔｅｎｔ−Ｔｙｐｅフィールドが、所定の情報（例えば、application/vnd.abc.Webservice）と一致するかどうかを判定する。そして一致すると判定した場合は、転送アプリ起動部４２４に受信したレスポンスに対する処理を依頼する。画面表示部４２３は、解析部４２２による解析結果に基づいて、ＨＴＭＬデータに従って、表示部２０７に操作画面を表示する。
【００３１】
転送アプリ起動部４２４は、解析部４２２による解析結果に基づいて、Ｗｅｂアプリケーション４１０から受信したレスポンスを処理要求とみなして、転送アプリケーション４３０に対して、転送するように依頼する。尚、レスポンスがＭＦＰ１０１への処理要求であるかどうかを判定できれば、ＨＴＴＰレスポンスヘッダを参照する以外の方法でも良い。また、レスポンスの転送を依頼する際に、転送アプリケーション４３０に対して、セキュリティ情報としてＷｅｂアプリケーション４１０とＷｅｂブラウザ４２０との通信に関する様々な情報も渡す。この情報は、例えば、通信先のサーバのアドレスや、通信時の暗号化の有無などを含む。
【００３２】
アップロード処理部４２５は、ＭＦＰ１０１の要求に応じて、指定されたデータを、通信部４２１を介してサーバ１０２に送信する。本実施形態では、ＨＴＴＰ ＰＯＳＴコマンドを用いて指定のデータをアップロードするが、Ｗｅｂブラウザ４２０が処理可能なプロトコルであれば何でもよい。
【００３３】
転送アプリケーション４３０は、通信部４３１及び処理部４３２を有する。
【００３４】
通信部４３１は、処理部４３２から依頼を受け、サービスプロバイダ４４０の通信部４４１にＨＴＴＰ ＰＯＳＴコマンドを用いて処理要求を転送し、また、その処理要求に対する結果を受信する。
【００３５】
処理部４３２は、Ｗｅｂブラウザ４２０の転送アプリ起動部４２４からの依頼を受け、サービスプロバイダ４４０への処理要求を通信部４３１を介して転送する。このときＷｅｂアプリケーション４１０から受信したレスポンスのヘッダに記載されている宛先に転送する。また、Ｗｅｂブラウザ４２０から受信したセキュリティ情報をＨＴＴＰリクエストヘッダに付加する。ＨＴＴＰリクエストヘッダの宛先（図７の７０１）、及びセキュリティ情報（図９の９０１）については後述する。
【００３６】
転送アプリケーション４３０は、一般的にＷｅｂブラウザで対応できない形式のファイル（音声や動画，アニメーションなど）を処理できるようにするヘルパーアプリケーションとして動作し、Ｗｅｂブラウザと独立して動作する。しかしながら、処理要求の転送を行う機能を有すれば、転送アプリケーションはヘルパーアプリケーションではなく、プラグインや、Ｗｅｂブラウザ内の一機能、または受信したレスポンス内に記載されたＪａｖａＳｃｒｉｐｔ（登録商標）として存在しても良い。
【００３７】
次にサービスプロバイダ４４０は、通信部４４１、判断部４４２、処理部４４３を有する。
【００３８】
通信部４４１は、転送アプリケーション４３０から処理要求とセキュリティ情報を受け付ける。判断部４４２は、受信したセキュリティ情報と、信頼情報記憶部４５０に保存されている情報から、処理を実行するかどうか判断する。具体的には、判断部４４２は、信頼情報記憶部４５０に保存されているＩＰアドレス等のＷｅｂサーバを識別する情報と、セキュリティ情報に含まれるＩＰアドレスなどのＷｅｂサーバを識別する情報を照らし合わせて比較する。本実施形態では、信頼情報記憶部４５０には、Ｗｅｂアプリケーションが存在するＷｅｂサーバのＩＰアドレスやホスト名が保存されており、判断部４４２は、これに一致するサーバからの処理依頼であれば処理を実行するように処理部４４３に依頼する。
【００３９】
処理部４４３は、通信部４４１が受け付けた処理依頼を受け取り、依頼された処理を実行する。本実施形態では、ＭＦＰ１０１の識別情報を取得し、処理結果としてその識別子を返却する。
【００４０】
信頼情報記憶部４５０は、前述の通り、信頼するＷｅｂサーバを識別するための情報として、ＷｅｂサーバのＩＰアドレスやホスト名を保存している。しかしながら、処理の依頼を行ったＷｅｂサーバを識別できれば、この情報はどのような情報でも良い。また信頼情報記憶部４５０は、ＭＦＰ１０１の中にあれば、サービスプロバイダ４４０やＷｅｂブラウザ４２０の一部として存在しても良い。本実施形態において、信頼情報記憶部４５０に記憶されている情報は、予めユーザによって入力されて保存されているものとし、ＭＦＰ１０１は、この信頼情報をユーザが入力するためのインターフェース（不図示）を持っていても良い。
【００４１】
図５は、本実施形態に係る通信システムにおける一連の処理の流れを説明するシーケンス図である。以下、このシーケンス図を参照して、このシステムで実施される処理を説明する。このシーケンス図で表される処理は、Ｗｅｂアプリケーション４１０がＭＦＰ１０１のデバイスのシリアルナンバーを取得し、Ｗｅｂブラウザ４２０に対して、そのデバイスシリアルナンバーに応じた固有の画面を返すものである。
【００４２】
まずＳ５０１で、ユーザがＭＦＰ１０１の入力部２０６から、Ｗｅｂブラウザ４２０を起動するためのボタン（不図示）の押下を受けると、Ｗｅｂブラウザ４２０を起動する。このボタンはハードウェアボタンに限ったものではなく、表示部２０７のタッチパネル上に表示されたボタンでも良い。そしてＷｅｂブラウザ４２０は、起動するとサーバ１０２上のＷｅｂアプリケーション４１０に画面情報のリクエストを行う。本実施形態では、画面のコンテンツを示すＵＲＬが予めＭＦＰ１０１に設定されているものとする。
【００４３】
ここではＷｅｂブラウザ４２０は、そのＵＲＬで示されるコンテンツを保持するＷｅｂアプリケーション４１０に対して、ＨＴＴＰのＧＥＴコマンドによるリクエストを行う。具体的には、Ｗｅｂブラウザ４２０が通信部４２１を介してＨＴＴＰプロトコルによりサーバ１０２の通信部４０１と通信を行う。通信部４０１は、ＭＦＰ１０１から受け取ったＵＲＬに応じて、適切なＷｅｂアプリケーションに受け取ったデータを渡す。これにより、Ｗｅｂブラウザ４２０からＷｅｂアプリケーション４１０へのリクエストが行われる。以下、通信部４０１と通信部４２１の動作は省略して説明する。
【００４４】
次にＳ５０２で、Ｗｅｂアプリケーション４１０のロジック部４１２が、Ｓ５０１で送信された情報を基に、ＨＴＴＰレスポンスヘッダと、ＨＴＴＰレスポンスボディとして処理要求を生成する。そして、ＨＴＴＰレスポンスヘッダとＨＴＴＰレスポンスボディとを合わせて、ＨＴＴＰレスポンスとしてＷｅｂブラウザ４２０に送信する。これによりＷｅｂブラウザ４２０は、Ｗｅｂアプリケーション４１０が送信したＨＴＴＰレスポンスを受信する。このＨＴＴＰレスポンスには、ＨＴＴＰレスポンスヘッダと処理要求が含まれる。これらの詳細については後述する。
【００４５】
Ｓ５０３では、解析部４２２は、Ｓ５０２で受信したＨＴＴＰレスポンスヘッダのＣｏｎｔｅｎｔ−Ｔｙｐｅフィールドが、所定の情報（例えば、application/vnd.abc.Webservice）と一致するか否かを判定する。一致する場合は、転送アプリ起動部４２４が、転送アプリケーション４３０の処理部４３２に対して、Ｓ５０２で受信したＨＴＴＰレスポンスボディを送信し、サービスプロバイダ４４０に転送するように依頼する。このとき、転送に必要な情報として、Ｓ５０２で受信したＨＴＴＰレスポンスヘッダと、セキュリティ情報としてＷｅｂアプリケーション４１０が動作しているＷｅｂサーバのＩＰアドレスとを転送アプリケーション４３０に渡す。更に、Ｗｅｂブラウザ４２０とＷｅｂアプリケーション４１０間の通信が暗号化されているかどうかの情報を転送アプリケーション４３０に渡す。尚、Ｃｏｎｔｅｎｔ−Ｔｙｐｅフィールドが所定の情報と一致しない場合は、解析部４２２は、ＨＴＭＬデータの解析結果に基づいて表示部２０７に操作画面を表示する。
【００４６】
Ｓ５０４では、転送アプリケーション４３０の処理部４３２は、Ｓ５０３で受信したＨＴＴＰレスポンスヘッダに記載されている宛先に対して、Ｓ５０３で受信したＨＴＴＰレスポンスボディとセキュリティ情報を、通信部４３１を介して送信する。
【００４７】
本実施形態では、ＨＴＴＰ ＰＯＳＴコマンドを用いて、サービスプロバイダ４４０に対して送信するが、この送信方法は他の方法でも良い。そして、サービスプロバイダ４４０は、転送アプリケーション４３０が送信した処理要求とセキュリティ情報を通信部４４１で受信する。本実施形態では、サービスプロバイダ４４０は、転送アプリケーション４３０からリクエストを受信している。しかしＷｅｂアプリケーション４１０からＭＦＰ１０１に対して、直接通信が可能な環境であれば、Ｗｅｂアプリケーション４１０から直接リクエストを受け取ることができる。
【００４８】
Ｓ５０５では、サービスプロバイダ４４０の判断部４４２は、Ｓ５０４において通信部４４１で受信した処理要求が、ループバックアドレス（ｌｏｃａｌｈｏｓｔ、１２７．０．０．１等）から送られていたものかどうかを確認する。
【００４９】
Ｓ５０６では、サービスプロバイダ４４０の判断部４４２は、信頼情報記憶部４５０を参照し、Ｓ５０４における処理要求の送信元アドレスが信頼情報記憶部４５０に記憶されている情報に含まれるかどうかを判定する。このとき、判断部４４２は、Ｓ５０５の確認の結果に基づき、ループバックアドレスからの通信であれば、Ｓ５０４で受信したセキュリティ情報から送信元アドレスを識別し、そうでなければ、実際に通信を行った際の情報を基に送信元アドレスを識別する。
【００５０】
判断部４４２は、送信元アドレスが信頼情報記憶部４５０に記憶されていれば、送信元が信頼できると判断し、その結果、処理部４４３はＳ５０３で受信した処理要求に従って処理を実行する。そうでなければ、送信元が信頼できないと判断して処理を実行しない。また、送信元が信頼できるかどうかの判断には、送信元のアドレス以外に、Ｗｅｂアプリケーション４１０とＭＦＰ１０１の間の通信が暗号化されているかなどのセキュリティに関わる様々な情報を基に判断しても良い。本実施形態では、処理要求はループバックアドレスから送られてきているため、セキュリティ情報から送信元アドレスを識別している。
【００５１】
Ｓ５０６で判断部４４２が処理要求の依頼元が信頼できると判断した場合、ＭＦＰ１０２のサービスプロバイダ４４０は、処理結果をＳ５０４で受信したリクエストのレスポンスとして、Ｓ５０７で通信部４４１を介して転送アプリケーション４３０に送信する。一方、処理要求の依頼元が信頼できないと判断した場合は、エラー結果を送信する。こうして転送アプリケーション４３０の処理部４３２は、処理結果又はエラー結果を、通信部４３１を介してサービスプロバイダ４４０から受信する。
【００５２】
Ｓ５０８では、転送アプリケーション４３０の処理部４３３は、Ｗｅｂブラウザ４２０のアップロード処理部４２５に対して、処理結果又はエラー結果をＷｅｂアプリケーション４１０に対してアップロードするように依頼する。この依頼に際して、処理部４３２は、アップロード処理部４２５に対してアップロードの宛先としてアップロード宛先を指定する。このアップロード宛先はＨＴＴＰレスポンスヘッダに記載されており、転送アプリケーション４３０からアップロード処理部４２５に指定せず、Ｗｅｂブラウザ４２０がこの情報を記憶しておいてその情報を使用してもよい。また宛先を固定値とし、Ｗｅｂアプリケーション４１０から指定しないようにしても良い。
【００５３】
Ｓ５０９では、アップロード処理部４２５は、通信部４２１を介してＨＴＴＰ ＰＯＳＴコマンドで、処理部４３３からの依頼に従って処理結果又はエラー結果をアップロードする。このとき、転送アプリケーション４３０の処理部４３２から依頼された宛先に対してアップロードを行う。
【００５４】
Ｓ５１０では、Ｗｅｂアプリケーション４１０はＷｅｂブラウザ４２０に対して、Ｓ５０９でアップロードを受け付けた処理結果又はエラー結果に応じた画面表示用のＨＴＭＬコンテンツを生成し、レスポンスする。このレスポンスを受け取ったＷｅｂブラウザ４２０は、解析部４２２による、画面表示用のＨＴＭＬコンテンツの解析結果に基づいて、表示部２０７に操作画面を表示する。
【００５５】
このように本実施形態に係るＭＦＰ１０１によれば、ユーザがＭＦＰ１０１のＷｅｂブラウザ４２０を起動すると、ＨＴＴＰのＧＥＴコマンドにより、Ｗｅｂサーバ１０２に画面情報をリクエストする。これによりＷｅｂサーバ１０２は、処理要求を含むＨＴＴＰレスポンスをＭＦＰ１０１に返し、ＭＦＰ１０１のＷｅｂブラウザは、そのＨＴＴＰレスポンスヘッダのコンテンツタイプが予め決められているものと一致するかどうかを調べる。そして、一致したときはその処理要求を、ＭＦＰ１０１のサービスプロバイダに転送する。この時、その処理要求にＷｅｂサーバ１０２のＩＰアドレスと、ＷｅｂアプリケーションとＷｅｂブラウザとの間の通信が暗号化されているか等のセキュリティ情報を付加して転送する。
【００５６】
サービスプロバイダは、その処理要求がループバックアドレスから送られていたと判定すると、セキュリティ情報から送信元のＷｅｂサーバのＩＰアドレスを求める。一方、ループバックアドレスから送られていないときは、その処理要求の送信元のアドレスを識別し、その送信元のアドレスが信頼情報として記憶されていれば、その処理要求の送信元が信頼できると判断して、その処理要求に対する処理を実行する。
【００５７】
これにより、ＭＦＰがファイアウォールで守られていたり、ネットワークアドレス変換を用いる環境にある場合でも、ＭＦＰのサービスプロバイダは、Ｗｅｂサーバからの処理要求を受信できる。そしてサービスプロバイダは、その処理要求に含まれる送信元のアドレスが、信頼できるアドレスとして記憶されているかアドレスと一致するかどうかを判定し、信頼できるアドレスと一致した場合にのみ、その処理要求に対する処理を実行できる。これによりＭＦＰがファイアウォールで守られている場合でも、ＭＦＰが信頼できると判定したＷｅｂアプリケーションが、ＭＦＰやユーザの情報を取得でき、かつＭＦＰからＷｅｂサーバへの情報の送信を最小限にすることが可能となる。
【００５８】
図６は、実施形態に係るＭＦＰ１０１のサービスプロバイダ４４０による処理を説明するフローチャートである。
【００５９】
このサービスプロバイダ４４０による処理は、図５のＳ５０４からＳ５０７において既に説明しているため、不足部分を補足する形で説明する。
【００６０】
Ｓ６０１では、サービスプロバイダ４４０の通信部４４１は、転送アプリケーション４３０が送信した処理要求とセキュリティ情報を受信する。次にＳ６０２に進み、図５のＳ５０５で実行したように、処理要求がループバックアドレスから送られたかどうかを判定する。このとき、受信した処理要求がループバックアドレスから送られていると判定した場合はＳ６０３へ進み、そうでない場合はＳ６０７へ進む。Ｓ６０３では、サービスプロバイダ４４０の処理部４４３は、通信部４４１を介して処理要求とセキュリティ情報を受信する。そしてＳ６０４に進み、図５のＳ５０６で示すように、処理要求の依頼元が信頼できるかどうかを判定する。このとき、送信元が信頼できるか否かの判断には、Ｓ５０４で受信したセキュリティ情報を用いる。そして、送信元が信頼できると判定した場合はＳ６０５へ進み、信頼できないと判断した場合はＳ６０９へ進む。
【００６１】
Ｓ６０５では、サービスプロバイダ４４０の処理部４４３は、その処理要求に従って処理を実行する。この処理要求は、デバイスシリアルナンバーの取得要求であり、処理部４４０はＭＦＰ１０１の情報提供部（不図示）からデバイスシリアルナンバーを取得し、処理結果を生成する。そしてＳ６０６に進み、サービスプロバイダ４４０は、Ｓ６０５又はＳ６０９で実行した処理結果又はエラー結果を、転送アプリケーション４３０に対して、レスポンスする。
【００６２】
一方、Ｓ６０２で処理要求がループバックアドレスから送られたものでないときはＳ６０７に進み、サービスプロバイダ４４０の処理部４４３は、通信部４４１を介して処理要求（図８（Ａ））を受信する。そしてＳ６０８に進み、Ｓ６０４と同様に、処理要求の依頼元が信頼できるかどうかを判定する。このとき、送信元が信頼できるかの判断には、通信部４４１が実際に通信を行った際の情報を基に送信元アドレスを識別する。そして、送信元が信頼できると判断した場合はＳ６０５へ進み、信頼できないと判断した場合はＳ６０９へ進む。Ｓ６０９では、サービスプロバイダ４４０の処理部４４３は、Ｓ６０４又はＳ６０８における、送信元が信頼できないという判定に従って、エラー結果を生成してＳ６０６に進む。
【００６３】
図７は、本実施形態に係るＷｅｂアプリケーション４１０がＷｅｂブラウザ４２０に対して返すＨＴＴＰレスポンスヘッダの一例を示す図である。
【００６４】
ＨＴＴＰレスポンスヘッダ７００は、宛先７０１、転送時コンテントタイプ７０２、アップロード宛先７０３、コンテントタイプ７０４を含んでいる。
【００６５】
宛先７０１は前述の通り、図５のＳ５０４において、転送アプリケーション４３０が処理要求であるＨＴＴＰレスポンスボディを転送する際の宛先である。この宛先７０１は、複数のサービスプロバイダが公開するサービスの何れかを指し示す。
【００６６】
転送時コンテントタイプ７０２は、図５のＳ５０４において、転送アプリケーション４３０が、サービスプロバイダ４４０にＨＴＴＰレスポンスボディを転送する際にＨＴＴＰヘッダのＣｏｎｔｅｎｔ−Ｔｙｐｅフィールドに記載する内容である。ＨＴＴＰ Ｐｏｓｔコマンドを用いた転送の際に、転送先のサービスプロバイダ４４０が正しく理解できるＣｏｎｔｅｎｔ−Ｔｙｐｅを記載する必要があるためである。転送時コンテントタイプ７０２が省略されている場合は、転送アプリケーション４３０が転送時にデフォルトの値を設定するようにしても良い。
【００６７】
アップロード宛先７０３は前述の通り、図５のＳ５０９においてＷｅｂブラウザ４２０が処理結果をＷｅｂアプリケーション４１０にアップロードする際の宛先である。
【００６８】
コンテントタイプ７０４は前述の通り、図５のＳ５０３において、Ｓ５０２で受信したＨＴＴＰレスポンスボディの内容が、処理要求か、Ｗｅｂブラウザ４２０に表示するＨＴＭＬコンテンツかの判定に用いられる。
【００６９】
図８（Ａ）は、Ｗｅｂアプリケーション４１０が生成し、Ｗｅｂブラウザ４２０にレスポンスとして返す処理要求の内容例を示す図である。
【００７０】
処理要求８００は、デバイスシリアルナンバー取得要求８０１を有し、Ｓ５０２でＷｅｂブラウザ４２０が受信するレスポンスボディに含まれる。この処理要求８００は、ＸＭＬ（Ｅｘｔｅｎｓｉｂｌｅ  Ｍａｒｋｕｐ  Ｌａｎｇｕａｇｅ）フォーマットで記載されているが、ＭＦＰ１０１に対する処理が記載できて、ＭＦＰ１０１が処理できる形式であれば何でもよい。
【００７１】
デバイスシリアルナンバー取得要求８０１は、ＭＦＰ１０１に対してデバイスシリアルナンバーの取得を要求する命令である。
【００７２】
図８（Ｂ）は、サービスプロバイダ４４０が生成し、転送アプリケーション４３０にレスポンスとして返す処理結果の内容例を示す図である。
【００７３】
処理結果８１０は、処理結果コード８１１とデバイスシリアルナンバー８１２を含んでいる。処理結果８１０は、処理要求８００と同様に、ＸＭＬフォーマットで記載されているが、他の形式であっても良い。処理結果コード８１１には、サービスプロバイダ４４０で実行された処理の処理結果コードが記載されている。Ｗｅｂアプリケーション４１０は、この処理結果８１０をＷｅｂブラウザ４２０のアップロードによって受信することで、ユーザに対して処理結果に応じたＨＴＭＬコンテンツを生成し、Ｗｅｂブラウザ４２０に送信することができる。サービスプロバイダ４４０が処理の実行に成功した場合、処理結果コード８１１には「ｏｋ」が記載され、失敗した場合は「ｎｇ」やエラーコードが記載される。デバイスシリアルナンバー８１２には、サービスプロバイダ４４０がデバイスシリアルナンバー取得要求８０１に従って取得したデバイスシリアルナンバー（ここでは「aaa12345」）が記載されている。
【００７４】
図８（Ｃ）は、サービスプロバイダ４４０が生成し、転送アプリケーション４３０にレスポンスとして返すエラー結果の内容例を示す図である。
【００７５】
エラー結果８２０は、処理結果８２１を含んでいる。処理結果８２１には「ｎｇ」が記載され、サービスプロバイダ４４０が処理の実行に失敗したことを示す。
【００７６】
図９は、転送アプリケーション４３０が、処理要求８００をサービスプロバイダ４４０に転送する際のＨＴＴＰリクエストヘッダの内容例を示す図である。
【００７７】
転送時リクエストヘッダ９００は、セキュリティ情報９０１を有する。セキュリティ情報９０１には、通信先のサーバのアドレスや、通信時の暗号化の有無（図９では暗号化有り（true）となっている）が記載されている。この他にも、ＷｅｂアプリケーションとＷｅｂブラウザの通信に関する情報など、処理要求の依頼元を信頼できるかどうか判断に必要な情報が記載されていても良い。
【００７８】
図１０は、実施形態に係るＭＦＰ１０１の信頼情報記憶部４５０に記憶されている信頼情報の内容例を示す図である。
【００７９】
信頼情報１０００には、ＭＦＰ１０１が信頼すべきサーバのアドレスが記載されており、ＩＰアドレス（ここでは「192.168.38.100」）や、ホスト名で管理されている。但し、情報の形式はこれに限らず、対象となるサーバ、及びＷｅｂアプリケーションを識別できれば、他の形式でもよい。
【００８０】
以上説明したように本実施形態によれば、ＭＦＰはＷｅｂアプリケーションから、Ｗｅｂブラウザへの応答である処理要求を受信してサービスプロバイダ（処理手段）に転送すると共に、処理要求の依頼元との通信に関する情報も処理手段に転送する。これにより、処理手段が処理要求の依頼元であるサーバが信頼できるかどうかを判定できる。よって、ＭＦＰがファイアウォールで守られている場合でも、ＭＦＰが信頼できると判定したＷｅｂアプリケーションが、ＭＦＰやユーザの情報を取得でき、かつＭＦＰからＷｅｂサーバへの情報の送信を最小限にすることが可能となる。
【００８１】
（その他の実施形態）
また、本発明は、以下の処理を実行することによっても実現される。即ち、上述した実施形態の機能を実現するソフトウェア（プログラム）を、ネットワーク又は各種記憶媒体を介してシステム或いは装置に供給し、そのシステム或いは装置のコンピュータ（又はＣＰＵやＭＰＵ等）がプログラムを読み出して実行する処理である。
【図１】
2014235667.tif 000003
【図２】
2014235667.tif 000004
【図３】
2014235667.tif 000005
【図４】
2014235667.tif 000006
【図５】
2014235667.tif 000007
【図６】
2014235667.tif 000008
【図７】
2014235667.tif 000009
【図８】
2014235667.tif 000010
【図９】
2014235667.tif 000011
【図１０】
2014235667.tif 000012