JP2015179105A - 情報処理装置、情報処理方法及びプログラム - Google Patents

情報処理装置、情報処理方法及びプログラム Download PDF

Info

Publication number
JP2015179105A
JP2015179105A JP2014055434A JP2014055434A JP2015179105A JP 2015179105 A JP2015179105 A JP 2015179105A JP 2014055434 A JP2014055434 A JP 2014055434A JP 2014055434 A JP2014055434 A JP 2014055434A JP 2015179105 A JP2015179105 A JP 2015179105A
Authority
JP
Japan
Prior art keywords
communication
response
format
request
side proxy
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Granted
Application number
JP2014055434A
Other languages
English (en)
Other versions
JP6395405B2 (ja
Inventor
健太 福島
Kenta Fukushima
健太 福島
大樹 舘
Hiroki Tachi
大樹 舘
将司 西山
Masashi Nishiyama
将司 西山
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Canon Inc
Original Assignee
Canon Inc
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Canon Inc filed Critical Canon Inc
Priority to JP2014055434A priority Critical patent/JP6395405B2/ja
Publication of JP2015179105A publication Critical patent/JP2015179105A/ja
Application granted granted Critical
Publication of JP6395405B2 publication Critical patent/JP6395405B2/ja
Expired - Fee Related legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Images

Abstract

【課題】セキュアな通信環境でのWebサービスの利用における利便性を向上させる。
【解決手段】第1の形式の通信要求を処理する処理手段が暗号化された通信を要するか否かを判定する判定手段と、前記判定手段により前記処理手段が暗号化された通信を要すると判定された場合、要求された第2の形式の通信要求を変換した第1の形式の通信要求を暗号化する暗号化手段と、前記暗号化手段により暗号化された前記第1の形式の通信要求に対する前記処理手段からの暗号化された第1の形式の通信応答を復号する復号手段と、前記復号手段により復号された前記第1の形式の通信応答を変換した第2の形式の通信応答を、前記第2の形式の通信要求に対する応答として送信する応答手段と、を有することによって課題を解決する。
【選択図】図5

Description

本発明は、情報処理装置、情報処理方法及びプログラムに関する。
現在、画像形成装置では、音声や動画通信、遠隔操作による遠隔保守サービスが提案されている(例えば特許文献1)。
また、画像形成装置はWebサーバやファイルサーバといったサーバ機能を持つようになっており、ユーザは、ネットワークを介してリモートの端末から画像形成装置のサーバ機能を利用することが可能である。そのようなサーバ機能の一つとしてRUI(Remote User Interface)といったWebサービスがある。
ユーザは、RUI機能を持つ画像形成装置に対しては、PCに搭載されているWebブラウザ等から画像形成装置の情報をPCへバックアップし別の画像形成装置へリストアすることができる(例えば特許文献2)。
特開2005−208974号公報 特開2005−202918号公報
しかしながら、ユーザは、遠隔保守サービスを使用して遠隔地にある画像形成装置のRUIへ接続しようとしても、画像形成装置がインターネット上のファイアウォールの内側に存在しているような環境ではRUIに接続することができない。なぜなら、ファイアウォールは、その外側から内側の端末に対する接続を拒否するように構成されており、外側の端末からではインターネット上のRUIに接続することができないためである。
そのため、画像形成装置の製造社のサービスマン等は、遠隔保守サービスを使用して顧客先の画像形成装置のRUIに接続して情報のバックアップやリストアを行うことはできなかった。
本発明は、セキュアな通信環境でのWebサービスの利用における利便性を向上させることを目的とする。
そこで、本発明の情報処理装置は、第1の形式の通信要求を処理する処理手段が暗号化された通信を要するか否かを判定する判定手段と、前記判定手段により前記処理手段が暗号化された通信を要すると判定された場合、要求された第2の形式の通信要求を変換した第1の形式の通信要求を暗号化する暗号化手段と、前記暗号化手段により暗号化された前記第1の形式の通信要求に対する前記処理手段からの暗号化された第1の形式の通信応答を復号する復号手段と、前記復号手段により復号された前記第1の形式の通信応答を変換した第2の形式の通信応答を、前記第2の形式の通信要求に対する応答として送信する応答手段と、を有する。
本発明によれば、セキュアな通信環境でのWebサービスの利用における利便性を向上させることができる。
システム構成の一例を示す図(その1)である。 MFPのハードウェア構成の一例を示す図である。 PC及び中継サーバのハードウェア構成の一例を示す図である。 MFP、PC、中継サーバの機能構成の一例を示す図(その1)である。 MFP、PC、中継サーバの処理の一例を示すシーケンス図である。 HTTPデータの一例を示す図(その1)である。 IDテーブルの一例を示す図(その1)である。 実施形態1のMFPの処理の一例を示すフローチャートである。 MFPの操作画面の一例を示す図である。 HTTPデータの一例を示す図(その2)である。 実施形態1のPCの処理の一例を示すフローチャートである。 PCの操作画面の一例を示す図である。 HTTPデータの一例を示す図(その3)である。 実施形態1の中継サーバの処理の一例を示すフローチャートである。 実施形態2のPCの処理の一例を示すフローチャートである。 HTTPデータの一例を示す図(その4)である。 実施形態2の中継サーバの処理の一例を示すフローチャートである。 IDテーブルの一例を示す図(その2)である。 HTTPデータの一例を示す図(その5)である。 実施形態3のMFPの処理の一例を示すフローチャートである。 HTTPデータの一例を示す図(その6)である。 実施形態3の中継サーバの処理の一例を示すフローチャートである。 実施形態4のMFPの処理の一例を示すフローチャートである。 実施形態4のPCの処理の一例を示すフローチャートである。 HTTPデータの一例を示す図(その7)である。 実施形態4の中継サーバの処理の一例を示すフローチャートである。 システム構成の一例を示す図(その2)である。 MFP、PC、中継サーバの機能構成の一例を示す図(その2)である。 実施形態5のPCの処理の一例を示すフローチャートである。 実施形態5の中継サーバの処理の一例を示すフローチャートである。 実施形態6のPCの処理の一例を示すフローチャート(その1)である。 実施形態6のPCの処理の一例を示すフローチャート(その2)である。 実施形態6の中継サーバの処理の一例を示すフローチャートである。 実施形態7のMFPの処理の一例を示すフローチャートである。 実施形態8のMFPの処理の一例を示すフローチャートである。
以下、本発明を実施するための形態について図面を用いて説明する。
<実施形態1>
図1は、ネットワークを介したセキュアな遠隔保守サービスを提供する通信システムのシステム構成の一例を示す図である。
MFP(画像形成装置)100は、ユーザ環境102の中に配置され、インターネット130にアクセス可能である。画像形成装置は、情報処理装置の一例である。なお、MFPは、Multifunction Peripheralの略である。
PC110は、コールセンター112の中に配置され、インターネット130にアクセス可能である。PC110は、情報処理装置の一例である。
ユーザ環境102、コールセンター112、MFP100、PC110は、複数あってもよい。また、図1では、MFP100がユーザ環境102の中に配置されているものとして説明するが、他の情報処理装置が配置されていてもよい。ここでいう他の情報処理装置は、例えば、PC、サーバ装置、タブレット端末等であってもよい。
ユーザ環境102には、ファイアウォール101が設けられている。また、コールセンター112には、ファイアウォール111が設けられている。ファイアウォール101は、ユーザ環境102の内側にある端末からインターネット130への接続は許可するが、インターネット130側からユーザ環境102の内側にある端末への接続は拒否するように構成されている。ファイアウォール111は、コールセンター112の内側にある端末からインターネット130への接続は許可するが、インターネット130側からコールセンター112の内側にある端末への接続は拒否するように構成されている。
サーバ群121は、インターネット130を介してサービスを提供するサーバコンピュータからなるサーバ群であり、サーバコンピュータは1台であっても複数台であってもよい。図1では、サーバ群121が中継サーバ装置(以下、中継サーバ)120の1台のみで構成されているものとして図示している。中継サーバ120は、情報処理装置の一例である。
図2は、MFP100のハードウェア構成の一例を示す図である。
CPU211を含む制御部210は、MFP100全体の動作を制御する。
CPU211は、ROM212やHDD214に記憶されたプログラムを実行することにより、MFP100の機能、後述するシーケンス図におけるMFP100の処理及びMFP100に関するフローチャートの処理を実現する。ここでは、1つのCPU211が1つのメモリ(RAM213又はHDD214)を用いてMFP100の機能、後述するシーケンス図におけるMFP100の処理及びMFP100に関するフローチャートの処理を実現するものとするが、他の構成でもよい。例えば、複数のCPUが複数のRAM又はHDDを用いてMFP100の機能、後述するシーケンス図におけるMFP100の処理及びMFP100に関するフローチャートの処理を実現するようにしてもよい。
ROM212は、CPU211が実行する各種のプログラムを記憶する。
RAM213は、CPU211の主メモリ、ワークエリア等の一時記憶領域として用いられる。
HDD214は、画像データや各種プログラムを記憶する。
操作部I/F215は、操作部219と制御部210とを接続する。
操作部219には、タッチパネル機能を有する液晶表示部やキーボード等が備えられている。
プリンタI/F216は、プリンタ220と制御部210とを接続する。制御部210は、印刷する画像データをプリンタI/F216を介してプリンタ220に送信する。
プリンタ220は、プリンタI/F216を介して制御部210から受け付けた画像データを記録媒体上に印刷する。
スキャナI/F217は、スキャナ221と制御部210とを接続する。
スキャナ221は、原稿上の画像を読み取って画像データ(画像ファイル)を生成し、スキャナI/F217を介して制御部210に入力する。MFP100は、スキャナ221で生成された画像データ(画像ファイル)をファイル送信又はメール送信することができる。
ネットワークI/F218は、制御部210をインターネット130に接続する。
図3は、PC110のハードウェア構成の一例を示す図である。
CPU311を含む制御部310は、PC110全体の動作を制御する。
CPU311は、ROM312やHDD314に記憶されたプログラムを実行することにより、PC110の機能、後述するシーケンス図におけるPC110の処理及びPC110に関するフローチャートの処理を実現する。
ROM312は、CPU311が実行する各種のプログラムを記憶する。
RAM313は、CPU311の主メモリ、ワークエリア等の一時記憶領域として用いられる。
HDD314は、画像データや各種プログラムを記憶する。
操作部I/F315は、操作部317と制御部310とを接続する。
操作部317には、タッチパネル機能を有する液晶表示部やキーボード、マウス等が備えられている。
ネットワークI/F316は、制御部310をインターネット130に接続する。
中継サーバ120のハードウェア構成も、PC110のハードウェア構成と同様であるものとする。即ち、中継サーバ120のCPU311は、中継サーバ120のROM312やHDD314に記憶されたプログラムを実行する。これにより、中継サーバ120は、中継サーバ120の機能、後述するシーケンス図における中継サーバ120の処理及び中継サーバ120に関するフローチャートの処理を実現する。
図4は、MFP100、PC110、中継サーバ120の機能構成の一例を示す図である。
サーバサイドプロキシ401は、操作部219を介して接続指示を受けると、中継サービス420と接続を確立した後、中継サービス420とWebサーバ402との間の通信を仲介(中継)する。
Webサーバ402は、中継サーバ120からHTTP(Hyper Text Transfer Protocol)通信要求を受けると、要求に応じた応答を返す機能を有する。
クライアントサイドプロキシ410は、Webブラウザ411と中継サービス420との間の通信を仲介(中継)する。
中継サービス420は、Webサーバ機能を提供しており、PC110及びMFP100からHTTP通信要求を受けると要求に応じた応答を返す機能を有する。
ここで、サーバサイドプロキシ401と中継サービス420との間で行われるHTTP通信、及びクライアントサイドプロキシ410と中継サービス420との間で行われるHTTP通信について説明する。
HTTPは、RFC(Request For Comment)2616で定義されるクライアント/サーバ型のプロトコルであり、複数のメソッドがある。一般に、クライアントがサーバから情報を受信する場合はGETメソッドが使用され、クライアントからサーバに情報を送信する場合はPOSTメソッドが使用される。
本実施形態においては、サーバサイドプロキシ401が中継サービス420へデータ送信する際、及びクライアントサイドプロキシ410が中継サービス420へデータ送信する際はPOSTメソッドが使用される。また、サーバサイドプロキシ401が中継サービス420からデータ受信する際、及びクライアントサイドプロキシ410が中継サービス420からデータ受信する際はGETメソッドが使用される。更に、送信用と受信用とで別々の接続が使用される。
図5は、MFP100、PC110、中継サーバ120の処理の一例を示すシーケンス図である。本シーケンス図は、MFP100とPC110とのRUI接続の一例を示す図である。
サーバサイドプロキシ401は、ユーザにより操作部219を介してコールセンターが起動され認証情報が入力されると、入力された認証情報を中継サービス420へ送信する(S501)。
中継サービス420は、サーバサイドプロキシ401から受信した認証情報を確認する(S502)。より具体的には、中継サービス420は、予め記憶している認証情報と、サーバサイドプロキシ401から受信した認証情報とを比較することにより、MFP100の接続を認証するか否かを判定する。
中継サービス420は、認証結果をサーバサイドプロキシ401へ通知する(S503)。
クライアントサイドプロキシ410は、ユーザからのアプリの起動と認証情報の入力とを受け付けると、認証情報を中継サービス420に通知する(S504)。
中継サービス420は、クライアントサイドプロキシ410から受信した認証情報を確認する(S505)。より具体的には、中継サービス420は、予め記憶している認証情報と、クライアントサイドプロキシ410から受信した認証情報とを比較することにより、PC110の接続を認証するか否かを判定する。
中継サービス420は、認証結果とコールセンター通知を行ったMFP一覧とをクライアントサイドプロキシ410へ送信する(S506)。
クライアントサイドプロキシ410は、ユーザにより選択されたMFPの情報を中継サービス420へ通知する(S507)。
サーバサイドプロキシ401は、操作部219を介してRUI接続許可を受け付けると、中継サービス420にRUIの接続許可を通知する(S508)。
中継サービス420は、RUI要求データキューとRUI応答データキューとを作成する(S509)。RUI要求データキューには、RUIに対する要求データが格納される。要求データは、例えば、図6の(a)に示すようなRUIへのHTTP要求(HTTPデータ)である。RUI応答データキューには、RUIからの応答データが格納される。応答データは、例えば、図6の(b)に示すようなRUIからのHTTP応答(HTTPデータ)である。
中継サービス420は、サーバサイドプロキシ401向けに、RUI要求データキューから取り出すための搬出用URLと、RUI応答データキューへ格納するための格納用URLとを作成する(S510)。中継サービス420は、サーバサイドプロキシ401から格納用URLへのPOST要求を受けると、対応するキューにPOSTされたデータを格納する。また、中継サービス420は、サーバサイドプロキシ401から搬出用URLへのGET要求を受けると、対応するキューからデータを取り出し、GET要求の応答として、データを返す。
中継サービス420は、格納用URLと搬出用URLとをサーバサイドプロキシ401に通知する(S511)。
クライアントサイドプロキシ410は、中継サービス420にRUI接続が許可されているか確認する(S512)。ここで、クライアントサイドプロキシ410は、中継サービス420へポーリング等を行い、RUI接続が許可されているかを定期的に確認する。
中継サービス420は、クライアントサイドプロキシ410にMFP100からRUIへの接続許可を受けたことを通知する(S513)。
クライアントサイドプロキシ410は、RUI接続許可通知を受けると中継サービス420にRUI接続を通知する(S514)。
中継サービス420は、クライアントサイドプロキシ410向けに、RUI要求データキューへの格納用URLと、RUI応答データキューからの搬出用URLとを作成する(S515)。なお、本実施形態では、中継サービス420は、データキューへの格納用URLと搬出用URLとを別々に作成しているが、同じURLにしてもよい。この場合、中継サービス420は、POST要求かGET要求かによって、格納するか搬出するかを切り分ける。
中継サービス420は、格納用URLと搬出用URLとをクライアントサイドプロキシ410へ通知する(S516)。
以降、サーバサイドプロキシ401とクライアントサイドプロキシ410と中継サービス420とは、Webサーバ402とWebブラウザ411とのデータの送受信を各URLを用いて行う。
Webブラウザ411は、Webサーバ402に対するHTTP要求(例えばRUI画面を取得するGET要求や指示を行うPOST要求)をクライアントサイドプロキシ410へ通知する(S517)。
クライアントサイドプロキシ410は、Webブラウザ411からのHTTP要求を受けると、中継サービス420のRUI要求データキューの格納用URLへHTTP要求をPOSTする(S518)。クライアントサイドプロキシ410が中継サービス420にHTTP要求を送信する処理は、要求送信処理の一例である。
サーバサイドプロキシ401は、中継サービス420のRUI要求データキューの搬出用URLにHTTP要求のGETを送信する(S519)。ここで、サーバサイドプロキシ401は、ポーリング等を行い、中継サービス420へのGET要求を定期的に送信する。
中継サービス420は、サーバサイドプロキシ401からのGET要求に対してRUI要求データキューにHTTP要求データがあれば応答として返す(S520)。サーバサイドプロキシ401が中継サービス420からHTTP要求を受信する処理は、要求受信処理の一例である。
サーバサイドプロキシ401は、中継サービス420から受信したHTTP要求をWebサーバ402へ送信する(S521)。
Webサーバ402は、サーバサイドプロキシ401から受けたHTTP要求に対するHTTP応答を返す(S522)。
サーバサイドプロキシ401は、Webサーバ402から受信したHTTP応答をRUI応答データキューの格納用URLへPOSTする(S523)。サーバサイドプロキシ401が中継サービス420にHTTP応答を送信する処理は、応答送信処理の一例である。
クライアントサイドプロキシ410は、中継サービス420のRUI応答データキューの搬出用URLに対してGETを送信する(S524)。ここで、クライアントサイドプロキシ410は、ポーリング等を行い、中継サービス420へのGET要求を定期的に送信する。
中継サービス420は、クライアントサイドプロキシ410からのGET要求に対してRUI要求データキューにHTTP応答データがあれば応答として返す(S525)。クライアントサイドプロキシ410が中継サービス420からHTTP応答を受信する処理は、応答受信処理の一例である。
クライアントサイドプロキシ410は、中継サービス420から受信したHTTP応答をWebブラウザ411にS517の応答として返す(S526)。
なお、Webサーバ402とサーバサイドプロキシ401との間、及びWebブラウザ411とクライアントサイドプロキシ410との間で行われるHTTP通信(通信要求、通信応答)は、第1の形式のHTTP通信である。また、サーバサイドプロキシ401と中継サービス420との間、及びクライアントサイドプロキシ410と中継サービス420との間で行われるHTTP通信(通信要求、通信応答)は、URIスキームによる第2の形式のHTTP通信である。即ち、サーバサイドプロキシ401は、第1の形式のHTTP通信と第2の形式のHTTP通信との通信形式を相互に変換して、Webサーバ402と中継サービス420と通信する。また、クライアントサイドプロキシ410は、第1の形式のHTTP通信と第2の形式のHTTP通信との通信形式を相互に変換して、Webブラウザ411と中継サービス420と通信する。
以上の処理により、PC110とMFP100とが異なるファイアウォールの内側にある場合であっても、中継サーバ120を介した双方向の通信が可能となる。これにより、ファイアウォールの内側にある装置から、インターネットを介して異なるファイアウォールの内側にある装置にある装置のWebサービスに接続して利用することができるようになる。
図7は、PC110のHDD314に記憶されているID(識別情報)テーブルの一例を示す図である。
情報601は、PC110がPOSTしたHTTP要求に対するHTTP応答であるかを判定するためのIDを示す情報である。情報602は、PC110がHTTP要求をPOSTした時刻を示す情報である。情報603は、PC110がHTTP要求をPOSTしたユーザの名称を示す情報である。情報604は、PC110がHTTP要求をPOSTした格納用URLを示す情報である。
図7に示すIDは、後述する図8、図11の処理において用いられる。
図8は、本実施形態におけるMFP100の処理の一例を示すフローチャートである。
サーバサイドプロキシ401は、操作部219を介してコールセンターの起動指示があったか否かを判定する(S701)。より具体的には、サーバサイドプロキシ401は、図9の(a)で後述する操作画面のボタン800が押下(選択)されたか否かを判定する。
図9の(a)は、操作部219に表示される操作画面の一例を示す図である。
図9の(a)に示す操作画面は、ユーザがMFP100の機能を選択するときに表示されるメインメニューを表示する画面である。ボタン800は、ユーザがコールセンター112内のPC110へ接続を要求する際に押下するボタンである。サーバサイドプロキシ401は、ボタン800が押下されると中継サーバ120との接続を開始する。
サーバサイドプロキシ401は、S701でコールセンターの起動指示があったと判定した場合、即ち、ボタン800が押下されたと判定した場合、後述する図9の(b)に示す認証情報入力画面を表示する(S702)。
図9の(b)は、操作部219に表示される操作画面の一例を示す図である。
図9の(b)に示す操作画面は、中継サーバ120に認証を行う際に表示される認証情報入力画面である。
入力欄810は、中継サーバ120にアクセスするために必要な認証情報であるユーザ名の入力欄である。
入力欄811は、中継サーバ120にアクセスするために必要な認証情報であるパスワードの入力欄である。
ボタン812は、入力欄810及び入力欄811に認証情報を入力したユーザがログインを指示するために押下するログインボタンである。
サーバサイドプロキシ401は、S702で表示した認証情報入力画面で認証情報が入力され、ボタン812が押下されたか否かを判定する(S703)。サーバサイドプロキシ401は、認証情報が入力され、ボタン812が押下されたと判定した場合はS704へ進む。また、サーバサイドプロキシ401は、認証情報が入力されていないと判定した場合、認証情報が入力されるまで待機する。なお、サーバサイドプロキシ401は、一定時間、認証情報の入力がなければ、図8の処理を終了するようにしてもよい。
サーバサイドプロキシ401は、入力された認証情報を中継サービス420へ送信し認証結果を待つ(S704)。
サーバサイドプロキシ401は、中継サービス420に送信した認証情報に対して通知された認証結果が成功か否かを判定する(S705)。サーバサイドプロキシ401は、判定の結果、認証が成功であれば、RUI接続の許可/不可を選択する図9の(c)に示す操作画面を表示する。そして、サーバサイドプロキシ401は、図9の(c)に示す操作画面の操作を介したユーザの指示により、RUI接続を許可するか否かを判定する(S706)。一方、サーバサイドプロキシ401は、認証が失敗であれば、図8の処理を終了する。
図9の(c)は、操作部219に表示される操作画面の一例を示す図である。
図9の(c)に示す操作画面は、コールセンターからのRUI接続を許可するかしないかを選択する際に表示される画面である。
ボタン820は、コールセンターからのRUI接続を許可する場合に押下するボタンである。サーバサイドプロキシ401は、ユーザによるボタン820の押下を受け付けるとS707へ進む。
ボタン821は、コールセンターからのRUI接続を許可しない場合に押下されるボタンである。サーバサイドプロキシ401は、ユーザによるボタン821の押下を受け付けると図8の処理を終了する。
サーバサイドプロキシ401は、中継サーバ120にRUI接続許可を送信する(S707)。
サーバサイドプロキシ401は、中継サービス420のRUI要求データキューからデータを取り出すための搬出用URLと、RUI応答データキューへデータを格納するための格納用URLとを中継サーバ120から受信しHDD214に記憶する(S708)。
サーバサイドプロキシ401は、搬出用URLからRUI要求データキューの図10の(a)に示すHTTP要求をGETする(S709)。
サーバサイドプロキシ401は、S709でGETした例えば図10の(b)に示すGET応答(HTTP要求)のBODY部からIDとHTTP要求とを取り出し、IDをHDD214に記憶する(S710)。即ち、サーバサイドプロキシ401は、GET応答を変換して、IDとHTTP要求とを取得する。
サーバサイドプロキシ401は、取り出したHTTP要求をWebサーバ402へ送信する(S711)。
サーバサイドプロキシ401は、Webサーバ402から図10の(c)に示すHTTP応答を受信する(S712)。
サーバサイドプロキシ401は、受信したHTTP応答にHDD214に記憶しているIDを付加し、RUI応答データキューに格納するため格納用URLへ送信する(S713)。
サーバサイドプロキシ401は、操作部219を介してユーザから終了指示を受けたか否かを判定する(S714)。サーバサイドプロキシ401は、終了指示を受けたと判定した場合、中継サービス420に切断指示を出し、図8の処理を終了する(S715)。一方、サーバサイドプロキシ401は、終了指示を受けていないと判定した場合、S709へ戻る。
以上の処理により、MFP100は、中継サーバ120から受け付けたHTTP要求に対するWebサーバ402からのHTTP応答に、前記HTTP要求に付加されているIDと同一のIDを付加して中継サーバ120に送信することができる。これにより、MFP100とPC110との間におけるHTTP要求とHTTP応答とを一対にすることができ、要求と応答との整合性があるHTTP通信を実現することができる。
図11は、本実施形態におけるPC110の処理の一例を示すフローチャートである。
クライアントサイドプロキシ410は、PC110の操作部317(以下、図11の処理においては単に操作部317という)を介してアプリケーションが起動されたか否かを判定する(S901)。
クライアントサイドプロキシ410は、アプリケーションが起動されたと判定した場合、後述する図12の(a)に示す認証情報入力画面を表示する(S902)。一方、クライアントサイドプロキシ410は、アプリケーションが起動されていないと判定した場合、S901の処理を繰り返す。
図12の(a)は、操作部317に表示される操作画面の一例を示す図である。
図12の(a)に示す操作画面は、中継サーバ120に認証を行う際に表示される画面である。
入力欄830は、中継サーバ120にアクセスするために必要な認証情報であるユーザ名の入力欄である。
入力欄831は、中継サーバ120にアクセスするために必要な認証情報であるパスワードの入力欄である。
ボタン832は、入力欄830及び入力欄831に認証情報を入力したユーザがログインを指示するために押下するログインボタンである。
クライアントサイドプロキシ410は、S902で表示した認証情報入力画面で認証情報が入力され、ボタン832が押下されたか否かを判定する(S903)。クライアントサイドプロキシ410は、認証情報が入力され、ボタン832が押下されたと判定した場合はS904へ進む。また、クライアントサイドプロキシ410は、認証情報が入力されていないと判定した場合、認証情報が入力されるまで待機する。なお、クライアントサイドプロキシ410は、一定時間、認証情報の入力がなければ、図11の処理を終了するようにしてもよい。
クライアントサイドプロキシ410は、中継サービス420と接続を行い、入力された認証情報を中継サービス420へ送信し、認証結果を待つ(S904)。
クライアントサイドプロキシ410は、中継サービス420に送信した認証情報に対して通知された認証結果が成功か否かを判定する(S905)。クライアントサイドプロキシ410は、判定の結果、認証が成功であれば、後述する図12の(b)に示す支援するMFPの選択画面を表示する(S906)。一方、クライアントサイドプロキシ410は、認証が失敗であれば、図11の処理を終了する。
図12の(b)は、操作部317に表示される操作画面の一例を示す図である。
図12の(b)に示す操作画面は、支援するMFPをユーザが選択する際に表示される画面である。
情報840は、図8のS706で中継サーバ120と接続を行ったMFPが配置されているユーザ環境一覧である。図12の(b)では、一例として情報840が1件のみ表示されているが、他のユーザ環境にあるMFPが中継サービス420に接続されると、情報840が追加される。
ボタン841は、ユーザが支援開始を指示する際に押下するボタンである。クライアントサイドプロキシ410は、ユーザによるボタン841の押下を受け付けると、S907へ進む。
クライアントサイドプロキシ410は、中継サーバ120からRUI接続許可を受信し、後述する図12の(c)に示すRUI接続画面を表示する(S907)。そして、クライアントサイドプロキシ410は、図12の(c)に示すRUI接続画面を介して受け付けたユーザの指示により、RUI接続するか否かを判定する(S908)。
図12の(c)は、操作部317に表示される操作画面の一例を示す図である。
図12の(c)に示す操作画面は、MFP100のRUIに接続するか否かをユーザが決定する際に表示される画面である。
ボタン850は、支援するMFP100のRUI接続を行う場合に押下されるボタンである。クライアントサイドプロキシ410は、ユーザによるボタン850の押下を受け付けると、S909へ進む。
ボタン851は、支援するMFP100のRUI接続を行わない場合に押下されるボタンである。クライアントサイドプロキシ410は、ユーザによるボタン851の押下を受け付けると、図11の処理を終了する。
クライアントサイドプロキシ410は、中継サーバ120にRUI接続要求を送信する(S909)。
クライアントサイドプロキシ410は、中継サーバ120から受信したRUI要求データキューへの格納用URLとRUI応答データキューからの搬出用URLとをPC110のHDD314に記憶する(S910)。以下、図11の処理においては、PC110のHDD314のことを単にHDD314という。
クライアントサイドプロキシ410は、Webブラウザ411から図6の(a)を用いて上述したHTTP要求を受信したか否かを判定する(S911)。クライアントサイドプロキシ410は、HTTP要求を受信したと判定した場合、S912へ進み、HTTP要求を受信していないと判定した場合、HTTP要求を受信するまで待つ。
クライアントサイドプロキシ410は、一意となるIDを発行する(S912)。例えば、クライアントサイドプロキシ410は、図7を用いて上述したIDテーブルでIDを管理する。
クライアントサイドプロキシ410は、発行したIDを受信したHTTP要求に付加し、RUI要求データキューに格納するためHDD314に記憶している格納用URLへPOSTする(S913)。ここで、クライアントサイドプロキシ410は、POSTに対する応答として図13の(a)に示す応答を得る。
クライアントサイドプロキシ410は、RUI応答データキューからHTTP応答を受信するため、搬出用URLへ図13の(b)に示すGETを送信する(S914)。
クライアントサイドプロキシ410は、S914で送信したGETに対してHTTP応答を受信したか否か判定する(S915)。クライアントサイドプロキシ410は、受信したと判定した場合、S916へ進み、受信していないと判定した場合、S914へ戻る。
クライアントサイドプロキシ410は、受信したGET応答のBODY部からIDとHTTP応答とを取り出す(S916)。即ち、クライアントサイドプロキシ410は、GET応答を変換して、IDとHTTP要求とを取得する。
クライアントサイドプロキシ410は、図7を用いて上述したIDテーブルを確認し、取り出したIDと、S913で送信したHTTP要求に付加したIDとが一致するか否かを判定する(S917)。クライアントサイドプロキシ410は、IDが一致すると判定した場合、S918へ進む。一方、クライアントサイドプロキシ410は、IDが一致しないと判定した場合、S914へ戻る。これにより、クライアントサイドプロキシ410は、送信したHTTP要求の対となるHTTP応答をIDに基づいて判定して取得することができる。
クライアントサイドプロキシ410は、図13の(c)に示すようなHTTP応答をWebブラウザ411からのHTTP要求に対する応答として返す(S918)。
クライアントサイドプロキシ410は、操作部317を介してユーザから終了指示を受けたか否かを判定する(S919)。クライアントサイドプロキシ410は、終了指示を受けたと判定した場合、中継サービス420に切断指示を出し、図11の処理を終了する(S920)。一方、クライアントサイドプロキシ410は、終了指示を受けていないと判定した場合、S911へ戻る。
以上の処理により、PC110は、送信したHTTP要求に付加したIDと、受信したHTTP応答に付加されているIDとを比較することで、MFP100とPC110との間におけるHTTP要求とHTTP応答とを一対にすることができる。これにより、PC110は、要求と応答との整合性があるHTTP通信を実現することができる。
図14は、本実施形態における中継サーバ120の処理の一例を示すフローチャートである。
中継サービス420は、サーバサイドプロキシ401から認証情報を受信する(S1001)。
中継サービス420は、受信した認証情報を確認する(S1002)。
中継サービス420は、サーバサイドプロキシ401へ認証結果を通知する(S1003)。
中継サービス420は、クライアントサイドプロキシ410から認証情報を受信する(S1004)。
中継サービス420は、受信した認証情報を確認する(S1005)。
中継サービス420は、クライアントサイドプロキシ410へ認証結果を通知する(S1006)。
中継サービス420は、サーバサイドプロキシ401からRUI接続許可通知を受信する(S1007)。
中継サービス420は、RUI要求データキューとRUI応答データキューとを作成する(S1008)。
中継サービス420は、サーバサイドプロキシ401向けに、RUI要求データキューから取り出すための搬出用URLと、RUI応答データキューへ格納するための格納用URLとを作成する(S1009)。
中継サービス420は、サーバサイドプロキシ401に作成したURLを通知する(S1010)。
中継サービス420は、クライアントサイドプロキシ410にRUI接続可能通知を通知する(S1011)。
中継サービス420は、クライアントサイドプロキシ410からRUI接続要求を受ける(S1012)。
中継サービス420は、クライアントサイドプロキシ410向けに、RUI要求データキューへの格納用URLと、RUI応答データキューからの搬出用URLとを作成する(S1013)。
中継サービス420は、クライアントサイドプロキシ410に作成したURLを通知する(S1014)。
中継サービス420は、POSTの受信を待つ(S1015)。
中継サービス420は、受けたPOSTがクライアントサイドプロキシ410からのPOSTであるか否かを判定する(S1016)。中継サービス420は、クライアントサイドプロキシ410からのPOSTであると判定した場合、S1017へ進む。一方、中継サービス420は、クライアントサイドプロキシ410からのPOSTでないと判定した場合、S1021へ進む。
中継サービス420は、クライアントサイドプロキシ410からのHTTP要求をRUI要求データキューに格納する(S1017)。
中継サービス420は、RUI要求データキューから取り出すための搬出用URLへのサーバサイドプロキシ401からのGETを待つ(S1018)。
中継サービス420は、RUI要求データキューに格納したHTTP要求をGETの応答としてサーバサイドプロキシ401に送信する(S1019)。
中継サービス420は、MFP100又はPC110から切断処理を受けたか否かを判定する(S1020)。中継サービス420は、切断処理を受けたと判定した場合、図14の処理を終了し、切断処理を受けていないと判定した場合、S1016へ戻る。
中継サービス420は、サーバサイドプロキシ401から受信したHTTP応答をRUI応答データキューに格納する(S1021)。
中継サービス420は、RUI応答データキューから取り出すための搬出用URLへのクライアントサイドプロキシ410からのGETを待つ(S1022)。
中継サービス420は、RUI応答データキューに格納したHTTP応答をGETの応答としてクライアントサイドプロキシ410に送信し、S1020へ進む(S1023)。
以上の処理により、中継サーバ120は、PC110とMFP100との通信を中継することができる。なお、本実施形態で説明したHTTPデータは、特定の形式のデータに限る必要はなく、説明した形式とは異なる形式のデータであってもよい。
以上、本実施形態によれば、PC110のクライアントサイドプロキシ410と、MFP100のサーバサイドプロキシ401とがHTTPデータにIDを付加して通信することで、HTTP要求とHTTP応答とを一対にして双方向通信することができる。これにより、ファイアウォールの内側にある装置がインターネットを介して異なるファイアウォールの内側にある装置のWebサービスに接続してサービスを利用する際に、要求と応答とを対応させることができるシステムを実現することができる。
<実施形態2>
実施形態1では、クライアントサイドプロキシ410、及びサーバサイドプロキシ401がHTTPデータにIDを付与していた。本実施形態では、中継サービス420がHTTPデータにIDを付与する構成について説明する。なお、上述した実施形態1と同様の構成については詳細な説明を省略する。
図15は、本実施形態におけるPC110の処理の一例を示すフローチャートである。
S1201からS1210までの処理は、図11のS901からS910までの処理と同様であるため説明を省略する。
クライアントサイドプロキシ410は、Webブラウザ411から図16の(a)に示すHTTP要求を受信したか否かを判定する(S1211)。クライアントサイドプロキシ410は、受信したと判定した場合、S1212へ進み、受信していないと判定した場合、受信するまで待つ。
クライアントサイドプロキシ410は、図16の(b)に示すように、HTTP要求をRUI要求データキューに格納するため、PC110のHDD314に記憶している格納用URLへPOSTする(S1212)。
クライアントサイドプロキシ410は、図16の(c)に示すように、RUI応答データキューからHTTP応答を受信するため、搬出用URLへGETを送信する(S1213)。
クライアントサイドプロキシ410は、S1213で出したGETに対するHTTP応答を受信したか否かを判定する(S1214)。クライアントサイドプロキシ410は、受信したと判定した場合、S1215へ進み、受信していないと判定した場合、S1213へ戻る。
クライアントサイドプロキシ410は、図16の(d)に示すHTTP応答をWebブラウザ411からのHTTP要求に対する応答として返す(S1215)。
クライアントサイドプロキシ410は、PC110の操作部317を介してユーザから終了指示を受けたか否かを判定する(S1216)。クライアントサイドプロキシ410は、終了指示を受けたと判定した場合、中継サービス420に切断指示を出し、図15の処理を終了する(S1217)。一方、クライアントサイドプロキシ410は、終了指示を受けていないと判定した場合、S1211へ戻る。
図17は、本実施形態における中継サーバ120の処理の一例を示すフローチャートである。
S1301からS1316までの処理は、図14のS1001からS1016までの処理と同様であるため説明を省略する。
中継サービス420は、一意となるIDを作成し中継サーバ120のHDD314(以下、図17の処理においては単にHDD314という)に記憶する(S1317)。例えば、中継サービス420は、図18のようなIDテーブルでIDを管理する。
図18は、中継サーバ120のHDD314に記憶されているIDテーブルの一例を示す図である。
情報1401は、HTTP要求に対するHTTP応答であるか否かを判定するためのIDを示す情報である。情報1402は、支援するデバイス名を示す情報である。情報1403は、支援を行うクライアント名を示す情報である。情報1404は、サーバ(サーバサイドプロキシ)用格納用URLを示す情報である。情報1405は、サーバ用搬出用URLを示す情報である。情報1406は、クライアント(クライアントサイドプロキシ)用格納用URLを示す情報である。情報1407は、クライアント用搬出用URLを示す情報である。情報1408は、HTTP要求がGETされた時刻を示す情報である。
中継サービス420は、クライアントサイドプロキシ410からPOSTされたHTTP要求にS1317で作成したIDを図19のように付加し、RUI要求データキューに記憶する(S1318)。
中継サービス420は、RUI要求データキューから取り出すための搬出用URLへのサーバサイドプロキシ401からのGETを待つ(S1319)。
中継サービス420は、RUI要求データキューに格納したHTTP要求をGETの応答としてサーバサイドプロキシ401に送信する(S1320)。
中継サービス420は、MFP100又はPC110から切断処理を受けたか否かを判定する(S1321)。中継サービス420は、切断処理を受けたと判定した場合、図17の処理を終了し、切断処理を受けていないと判定した場合、S1315へ戻る。
中継サービス420は、サーバサイドプロキシ401から受信したHTTP応答データからIDを取得する(S1322)。
中継サービス420は、取得したIDと、図18を用いて上述したHDD314に記憶しているIDテーブルのIDとが一致するか否かを判定する(S1323)。中継サービス420は、IDが一致すると判定した場合、S1324へ進み、一致しないと判定した場合、S1321へ進む。
中継サービス420は、HTTP応答からIDを削除してRUI応答データキューに格納し、更に、HDD314に記憶しているIDテーブルから前記削除したIDに対応するデータを削除する(S1324)。
中継サービス420は、RUI応答データキューの搬出用URLへのクライアントサイドプロキシ410からのGETを待つ(S1325)。
中継サービス420は、GET要求を受けるとHTTP応答をGETの応答としてクライアントサイドプロキシ410に返し、S1321へ進む(S1326)。
以上の処理により、中継サーバ120は、HTTPデータにIDを付加してHTTP要求とHTTP応答とを一対にして、PC110とMFP100との通信を中継することができる。なお、本実施形態で説明したHTTPデータは、特定の形式のデータに限る必要はなく、説明した形式とは異なる形式のデータであってもよい。また、本実施形態におけるMFP100の処理は、実施形態1と同じとなるため説明を省略する。
以上、本実施形態によれば、PC110とMFP100との通信を中継する中継サーバ120がHTTPデータにIDを付加して管理することにより、PC110とMFP100とがHTTP要求とHTTP応答とを一対にして双方向通信することができる。これにより、ファイアウォールの内側にある装置がインターネットを介して異なるファイアウォールの内側にある装置のWebサービスに接続してサービスを利用する際に、要求と応答とを対応させることができるシステムを実現することができる。
<実施形態3>
実施形態1、2ではプロキシ又は中継サービス420がHTTPデータにIDを付加することでWebブラウザ411からのHTTP要求に対してHTTP応答を一致させていた。
本実施形態では、図1のシステムにおいて、IDを使用せずにHTTP要求に対するHTTP応答を一致させる構成について説明する。より具体的には、中継サーバ120が、PC110がHTTP応答を受け取るまでPC110からの新しいHTTP要求のPOSTを受け付けない構成について説明する。なお、上述した実施形態1、2と同様の構成については詳細な説明を省略する。
図20は、本実施形態におけるMFP100の処理の一例を示すフローチャートである。
S1601からS1608までの処理は、図8のS701からS708までの処理と同様であるため説明を省略する。
サーバサイドプロキシ401は、RUI要求データキューの搬出用URLから図21の(a)に示すHTTP要求をGETする(S1609)。
サーバサイドプロキシ401は、図21の(b)に示すようにGETしたHTTP要求をWebサーバ402へ送信する(S1610)。
サーバサイドプロキシ401は、Webサーバ402から図21の(c)に示すHTTP応答を受信する(S1611)。
サーバサイドプロキシ401は、受信したHTTP応答をRUI応答データキューに格納するため格納用URLへ送信する(S1612)。
S1613からS1614までの処理は、図8のS714からS715までの処理と同様であるため説明を省略する。
図22は、本実施形態における中継サーバ120の処理の一例を示すフローチャートである。
S1701からS1716までの処理は、図14のS1001からS1016までの処理と同様であるため説明を省略する。
中継サービス420は、既にクライアント側RUIデータ送信用URLからPOSTを受けているか否かを判定する(S1717)。ここでは、中継サービス420は、POSTフラグを確認することで、前記POSTを受けているか否かを判定する。より具体的には、中継サービス420は、POSTフラグ=0であれば、前記POSTを受けていないと判定し、S1718へ進む。一方、中継サービス420は、POSTフラグ=1であれば、前記POSTを受けていると判定し、S1715へ戻る。
中継サービス420は、POSTを受付(POSTフラグ=1)に変更する(S1718)。
中継サービス420は、クライアントサイドプロキシ410から受信したHTTP要求をRUI要求データキューに格納する(S1719)。
中継サービス420は、RUI要求データキューの搬出用URLへのサーバサイドプロキシ401からのGETを待つ(S1720)。
中継サービス420は、RUI要求データキューに格納したHTTP要求をGETの応答としてサーバサイドプロキシ401に送信する(S1721)。
中継サービス420は、MFP100又はPC110から切断処理を受けたか否かを判定する(S1722)。中継サービス420は、切断処理を受けたと判定した場合、図22の処理を終了し、切断処理を受けていないと判定した場合、S1715へ戻る。
中継サービス420は、HTTP応答をRUI応答データキューに格納する(S1723)。
中継サービス420は、RUI応答データキューの搬出用URLへのクライアントサイドプロキシ410からのGETを待つ(S1724)。
中継サービス420は、送信要求を受けていない(POSTフラグ=0)に変更する(S1725)。
中継サービス420は、クライアントサイドプロキシ410から要求を受けると、HTTP応答をGETの応答として返し、S1722へ進む(S1326)。
以上の処理により、中継サーバ120は、PC110がHTTP応答を受け取るまでPC110からの新しいHTTP要求のPOSTを受け付けないことで、HTTP要求とHTTP応答とを一対にして、PC110とMFP100との通信を中継することができる。なお、本実施形態で説明したHTTPデータは、特定の形式のデータに限る必要はなく、説明した形式とは異なる形式のデータであってもよい。また、本実施形態におけるPC110の処理は、実施形態2と同じとなるため説明を省略する。
以上、本実施形態によれば、PC110がHTTP応答を受け取るまで、中継サーバ120がPC110からの新しいHTTP要求のPOSTを受け付けない構成とすることで、HTTP要求とHTTP応答とを一致させることができる。そのため、PC110とMFP100とがHTTP要求とHTTP応答とを一対にして双方向通信することができるようになる。これにより、ファイアウォールの内側にある装置がインターネットを介して異なるファイアウォールの内側にある装置のWebサービスに接続してサービスを利用する際に、要求と応答とを対応させることができるシステムを実現することができる。
<実施形態4>
本実施形態では、図1のシステムにおいて、URL(アドレス情報)を使用することでWebブラウザ411からのHTTP要求と、その要求に対するHTTP応答とを一致させる構成について説明する。より具体的には、中継サーバ120は、PC110からのHTTP要求のPOST応答としてHTTP応答のGET用URLを通知する。また、中継サーバ120は、MFP100からのHTTP要求のGET応答としてHTTP応答のPOST用URLを通知する。なお、上述した実施形態1、2、3と同様の構成については詳細な説明を省略する。
図23は、本実施形態におけるMFP100の処理の一例を示すフローチャートである。
S1901からS1907までの処理は、図8のS701からS707までの処理と同様であるため説明を省略する。
サーバサイドプロキシ401は、中継サーバ120から受信したRUI要求データキューへの格納用URLをHDD214に記憶する(S1908)。
サーバサイドプロキシ401は、RUI要求データキューのHTTP要求を搬出用URLからGETする(S1909)。
サーバサイドプロキシ401は、上述した図10の(b)に示すGET応答を変換してURLとHTTP要求とを取得し、取得したURLをHDD214に記憶する(S1910)。
サーバサイドプロキシ401は、取得したHTTP要求をWebサーバ402へ送信する(S1911)。
サーバサイドプロキシ401は、Webサーバ402へ送信したHTTP要求に対するWebサーバ402からのHTTP応答を、HDD214に記憶しているURLへPOSTする(S1912)。
サーバサイドプロキシ401は、HDD214に記憶しているURLを削除する(S1913)。
S1914からS1915までの処理は、図8のS714からS715までの処理と同様であるため説明を省略する。
以上の処理により、MFP100は、GET応答から取得したURLを用いて、Webサーバ402からのHTTP応答をPSOTすることができる。これにより、MFP100とPC110との間におけるHTTP要求とHTTP応答とを一対にすることができ、要求と応答との整合性があるHTTP通信を実現することができる。
図24は、本実施形態におけるPC110の処理の一例を示すフローチャートである。
S2001からS2009までの処理は、図11のS901からS909までの処理と同様であるため説明を省略する。
クライアントサイドプロキシ410は、中継サーバ120から受信したRUI要求データキューへの格納用URLをPC110のHDD314(以下、図24の処理においては単にHDD314という)に記憶する(S2010)。
クライアントサイドプロキシ410は、Webブラウザ411から図25の(a)に示すHTTP要求を受信したか否かを判定する(S2011)。クライアントサイドプロキシ410は、HTTP要求を受信したと判定した場合、S2012へ進み、HTTP要求を受信していないと判定した場合、HTTP要求を受信するまで待つ。
クライアントサイドプロキシ410は、Webブラウザ411から受信したHTTP要求をRUI要求データキューに格納するため、図25の(b)に示すようにHDD314に記憶している格納用URLへPOSTする(S2012)。
クライアントサイドプロキシ410は、格納用URLへのPOSTの応答として中継サーバ120から受信した図25の(c)に示す応答内のURLをHDD314に記憶する(S2013)。
クライアントサイドプロキシ410は、図25の(d)に示すように、RUI応答データキューからデータを受信するため、HDD314に記憶しているURLへのHTTP応答のGETを行う(S2014)。
クライアントサイドプロキシ410は、S2014で送信したGETに対してHTTP応答を受信したか否かを判定する(S2015)。クライアントサイドプロキシ410は、受信したと判定した場合、S2016へ進み、受信していないと判定した場合、S2014へ戻る。
クライアントサイドプロキシ410は、Webブラウザ411からのHTTP要求の応答として、図25の(e)に示すHTTP応答を返す(S2016)。
クライアントサイドプロキシ410は、HDD314に記憶しているURLを削除する(S2017)。
S2018からS2019までの処理は、図11のS919からS920までの処理と同様であるため説明を省略する。
以上の処理により、PC110は、HTTP要求のPOSTの応答として中継サーバ120から通知されたURLに基づいて、HTTP応答のGETを行うことができる。これにより、MFP100とPC110との間におけるHTTP要求とHTTP応答とを一対にすることができ、要求と応答との整合性があるHTTP通信を実現することができる。
図26は、本実施形態における中継サーバ120の処理の一例を示すフローチャートである。
中継サービス420は、サーバサイドプロキシ401から認証情報を受信する(S2101)。
中継サービス420は、受信した認証情報を確認する(S2102)。
中継サービス420は、サーバサイドプロキシ401へ認証結果を通知する(S2103)。
中継サービス420は、クライアントサイドプロキシ410から認証情報を受信する(S2104)。
中継サービス420は、受信した認証情報を確認する(S2105)。
中継サービス420は、クライアントサイドプロキシ410へ認証結果を通知する(S2106)。
中継サービス420は、サーバサイドプロキシ401からRUI接続許可通知を受信する(S2107)。
中継サービス420は、RUI要求データキューとRUI応答データキューとを作成する(S2108)。
中継サービス420は、サーバサイドプロキシ401向けに、RUI要求データキューから取り出すための搬出用URLを作成する(S2109)。
中継サービス420は、サーバサイドプロキシ401に作成したURLを通知する(S2110)。
中継サービス420は、クライアントサイドプロキシ410にRUI接続可能通知を通知する(S2111)。
中継サービス420は、クライアントサイドプロキシ410からRUI接続要求を受ける(S2112)。
中継サービス420は、クライアントサイドプロキシ410向けに、RUI要求データキューへの格納用URLを作成する(S2113)。
中継サービス420は、クライアントサイドプロキシ410に作成したURLを通知する(S2114)。
中継サービス420は、POSTを受けるのを待つ(S2115)。
中継サービス420は、受けたPOSTがクライアントサイドプロキシ410からのPOSTであるか否かを判定する(S2116)。中継サービス420は、クライアントサイドプロキシ410からのPOSTであれば、S2117へ進み、クライアントサイドプロキシ410からのPOSTでなければ、S2124へ進む。
中継サービス420は、RUI応答データキューを取得するためのクライアントサイドプロキシ410向けの搬出用URLを作成する(S2117)。
中継サービス420は、作成したURLをクライアントサイドプロキシ410へのPOST応答に付加して送信する(S2118)。
中継サービス420は、RUI応答データキューに送信するためのサーバサイドプロキシ401向けの格納用URLを作成する(S2119)。
中継サービス420は、作成した格納用URLをHTTP要求に付加してRUI要求データキューに格納する(S2120)。
中継サービス420は、サーバサイドプロキシ401からのRUI要求データキューの搬出用URLへのGETを待つ(S2121)。
中継サービス420は、RUI要求データキューに格納したHTTP要求をGETの応答として送信する(S2122)。
中継サービス420は、MFP100又はPC110から切断処理を受けたか否かを判定する(S2123)。中継サービス420は、切断処理を受けたと判定した場合、図26の処理を終了し、切断処理を受けていないと判定した場合、S2115へ戻る。
中継サービス4201は、サーバサイドプロキシ401から受信したHTTP応答をRUI応答データキューに格納する(S2124)。
中継サービス420は、RUI応答データキューから取り出すための搬出用URLへのクライアントサイドプロキシ410からのGETを待つ(S2125)。
中継サービス420は、RUI応答データキューに格納したHTTP応答をGETの応答としてクライアントサイドプロキシ410に送信し、S2123へ進む(S2126)。
以上の処理により、中継サーバ120は、URLを使用することで、HTTP要求とHTTP応答とを一致させることができる。なお、本実施形態で説明したHTTPデータは、特定の形式のデータに限る必要はなく、説明した形式とは異なる形式のデータであってもよい。
以上、本実施形態によれば、URLを使用することでWebブラウザ411からのHTTP要求と、その要求に対するHTTP応答とを一対にすることができる。これにより、ファイアウォールの内側にある装置がインターネットを介して異なるファイアウォールの内側にある装置のWebサービスに接続してサービスを利用する際に、要求と応答とを対応させることができるシステムを実現することができる。
<実施形態5>
本実施形態は、MFP100とPC110との間のRUI通信内容を、後述する図27のシステム構成図に示される他のPCであるPC103から閲覧可能とするものである。一般的に、サービスマンがユーザの画像形成装置の保守を行う場合、その作業状況を顧客側でも確認できなければならない。例えば、画像形成装置の保守において、サービスマンが画像形成装置の修復のため設定値を変更する場合、画像形成装置の情報をPCにバックアップする作業がよく行われる。この場合、サービスマンがどの設定値をバックアップしているかを、ユーザ側は把握できなければならない。
本実施形態では、MFP100とPC110との間におけるRUI通信の通信内容を、ユーザ側のPC103から閲覧可能とする構成について説明する。なお、上述した実施形態1から4までと同様の構成については詳細な説明を省略する。
図27は、本実施形態におけるネットワークを介したセキュアな遠隔保守サービスを提供する通信システムのシステム構成の一例を示す図である。
PC103がユーザ環境102の中に配置されており、インターネット130にアクセス可能である。その他の構成は上述した図1と同様であるため説明を省略する。
また、PC103のハードウェア構成は上述した図3と同様である。即ち、PC103のCPU311は、PC103のROM312やHDD314に記憶されたプログラムを実行することにより、PC103の機能、及び後述するPC103に関するフローチャートの処理を実現する。その他の構成については説明を省略する。
図28は、本実施形態におけるMFP100、PC103、PC110、中継サーバ120の機能構成の一例を示す図である。
MFP100、PC110、中継サーバ120の機能構成は図4と同様であるため説明を省略する。
PC103内のクライアントサイドプロキシ430は、Webブラウザ431と中継サービス420との間の通信を仲介(中継)する。クライアントサイドプロキシ430は、中継サービス420へのデータ送信に、POSTメソッドを使用する。また、クライアントサイドプロキシ430は、中継サーバ120からのデータ受信に、GETメソッドを使用する。また、クライアントサイドプロキシ430は、送信用と受信用とで別々の接続を使用するものとする。
図29は、本実施形態におけるPC103の処理の一例を示すフローチャートである。
S2501からS2506までの処理は、図11のS901からS906までの処理と同様であるため説明を省略する。本実施形態では、S2506で選択された支援先のMFP100は既にPC110と通信中であるものとする。
クライアントサイドプロキシ430は、中継サーバ120からRUI接続許可を受信する(S2507)。S2507でクライアントサイドプロキシ430が受信したRUI接続許可情報には、既にMFP100とPC110とがRUI通信状態である旨を示す情報が含まれる。
クライアントサイドプロキシ430は、RUI閲覧を実行するか否かを判定する(S2508)。より具体的には、クライアントサイドプロキシ430は、RUI閲覧を実行するか否かの選択を促す画面をPC103の操作部317(以下、図29の処理においては単に操作部317という)に表示する。そして、クライアントサイドプロキシ430は、操作部317を介してユーザによる閲覧実行の選択を受け付けると、S2509へ進む。一方、クライアントサイドプロキシ430は、操作部317を介してユーザによる閲覧実行の選択を受け付けなかった場合、即ち、ユーザが閲覧実行を選択せず終了する場合は、S2518へ進む。
クライアントサイドプロキシ430は、中継サーバ120にRUI閲覧を送信する(S2509)。
クライアントサイドプロキシ430は、中継サーバ120から受信したRUI要求データキューへの格納用URLと、RUI応答データキューからの搬出用URLとをPC103のHDD314(以下、図29の処理においては単にHDD314という)に記憶する(S2510)。
クライアントサイドプロキシ430は、Webブラウザ431からHTTP要求を受信したか否かを判定する(S2511)。クライアントサイドプロキシ430は、HTTP要求を受信したと判定した場合、S2512へ進み、HTTP要求を受信していないと判定した場合、HTTP要求の受信を待つ。
クライアントサイドプロキシ430は、Webブラウザ431から受信したHTTP要求を、HDD314に記憶している格納用URLへPOSTする(S2512)。なお、本実施形態では、S2512でクライアントサイドプロキシ430がPOSTしたHTTP要求は、中継サーバ120上で読み捨てられる。また、本実施形態では、Webブラウザ431からのHTTP要求をクライアントサイドプロキシ430が中継サーバ120にPOSTしているが、クライアントサイドプロキシ430が読み捨てる構成であってもよい。
クライアントサイドプロキシ430は、RUI応答データキューからHTTP応答を受信するため搬出用URLへGETを出す(S2513)。
クライアントサイドプロキシ430は、S2513で出したGETに対して中継サーバ120からHTTP応答を受信したか否かを判定する(S2514)。クライアントサイドプロキシ430は、受信したと判定した場合、S2515へ進み、受信していないと判定した場合、S2513へ戻る。
クライアントサイドプロキシ430は、中継サーバ120から受信したGET応答(HTTP応答)からID部分を取り出す(S2515)。より具体的には、クライアントサイドプロキシ430は、GET応答を変換して、IDとHTTP要求とを取得する。
クライアントサイドプロキシ430は、ID部分を取り除いたHTTP応答を、Webブラウザ431からのHTTP要求の応答として返す(S2516)。
クライアントサイドプロキシ430は、操作部317を介してユーザから終了指示を受けたか否かを判定する(S2517)。クライアントサイドプロキシ430は、終了指示を受けたと判定した場合、中継サービス420に切断指示を出し、図29の処理を終了する(S2518)。一方、クライアントサイドプロキシ430は、終了指示を受けていないと判定した場合、S2511へ戻る。
以上の処理により、MFP100とPC110との間におけるRUI通信の通信内容を、ユーザ側のPC103から閲覧することができる。
図30は、本実施形態における中継サーバ120の処理の一例を示すフローチャートである。
S2601からS2619までの処理は、図14のS1001からS1019までの処理と同様であるため説明を省略する。また、S2621からS2623までの処理は、図14のS1021からS1023までの処理と同様であるため説明を省略する。なお、図30において、第1のクライアントサイドプロキシとは、PC110のクライアントサイドプロキシ410のことである。また、第2のクライアントサイドプロキシとは、PC103のクライアントサイドプロキシ430のことである。
中継サービス420は、クライアントサイドプロキシ430から認証情報を受信したか否かを判定する(S2620)。中継サービス420は、認証情報を受信したと判定した場合、S2624へ進み、認証情報を受信していないと判定した場合、S2615へ戻る。
中継サービス420は、クライアントサイドプロキシ430から受信した認証情報を確認する(S2624)。より具体的には、中継サービス420は、予め記憶している認証情報と、クライアントサイドプロキシ430から受信した認証情報とを比較することにより、PC103の接続を認証するか否かを判定する。
中継サービス420は、クライアントサイドプロキシ430へ認証結果を通知する(S2625)。
中継サービス420は、クライアントサイドプロキシ430へRUI接続可能を通知する(S2626)。
中継サービス420は、クライアントサイドプロキシ430からRUI閲覧要求を受信する(S2627)。RUI閲覧要求は、通信内容の取得要求の一例である。
中継サービス420は、クライアントサイドプロキシ430へ送受信用URLを通知する(S2628)。ここで、中継サービス420は、S2613で作成したURLと同じURLをクライアントサイドプロキシ430へ通知する。より具体的には、中継サービス420は、RUI要求データキューへ格納するための格納用URLと、RUI応答データキューから取り出すための搬出用URLとをクライアントサイドプロキシ430へ通知する。これらのURLは、MFP100とPC110とがRUI通信するためにも使用されている。
中継サービス420は、POSTの受信を待つ(S2629)。
中継サービス420は、受けたPOSTがクライアントサイドプロキシ410からのPOSTであるか否かを判定する(S2630)。中継サービス420は、クライアントサイドプロキシ410からのPOSTであると判定した場合、S2631へ進む。一方、中継サービス420は、クライアントサイドプロキシ410からのPOSTでないと判定した場合、S2634へ進む。
中継サービス420は、HTTP要求をRUI要求データキューに格納する(S2631)。
中継サービス420は、RUI要求データキューから取り出すための搬出用URLへのサーバサイドプロキシ401からのGETを待つ(S2632)。
中継サービス420は、RUI要求データキューに格納したHTTP要求をGETの応答としてサーバサイドプロキシ401へ送信する(S2633)。
中継サービス420は、MFP100、PC110、又はPC103から切断処理を受けたか否かを判定する(S2642)。中継サービス420は、切断処理を受けたと判定した場合、図30の処理を終了し、切断処理を受けていないと判定した場合、S2629へ戻る。
中継サービス420は、S2629で受けたPOSTがサーバサイドプロキシ401からのPOSTであるか否かを判定する(S2634)。中継サービス420は、サーバサイドプロキシ401からのPOSTであると判定した場合、S2635へ進む。一方、中継サービス420は、サーバサイドプロキシ401からのPOSTでないと判定した場合、S2640へ進む。
中継サービス420は、サーバサイドプロキシ401から受信したHTTP応答をRUI応答データキューに格納する(S2635)。
中継サービス420は、搬出用URLへのクライアントサイドプロキシ410からのGETを待つ(S2636)。
中継サービス420は、RUI応答データキューに格納されているHTTP応答をGETの応答として、クライアントサイドプロキシ410へ送信する(S2637)。
中継サービス420は、搬出用URLへのクライアントサイドプロキシ430からのGETを待つ(S2638)。
中継サービス420は、RUI応答データキューに格納されているHTTP応答をGETの応答として、クライアントサイドプロキシ430へ送信する(S2639)。即ち、中継サービス420は、S2637でクライアントサイドプロキシ410へ送信したHTTP応答と同じHTTP応答をクライアントサイドプロキシ430へ送信する。これにより、PC103が、MFP100とPC110との間におけるRUI通信の通信内容を取得することができるようになる。
中継サービス420は、S2629で受けたPOSTがクライアントサイドプロキシ430からのPOSTであるか否かを判定する(S2640)。中継サービス420は、クライアントサイドプロキシ430からPOSTであると判定した場合、S2641へ進む。一方、中継サービス420は、クライアントサイドプロキシ430からPOSTでないと判定した場合、S2642へ進む。
中継サービス420は、クライアントサイドプロキシ430からPOSTされたHTTP要求を読み捨てる(S2641)。S2641における処理は、削除処理の一例である。これにより、中継サービス420は、PC103からのGET要求に対して、PC110用にRUI応答データキューに格納されている最新のHTTP応答を送信することができる。即ち、PC103は、MFP100とPC110との間の最新のRUI通信における通信内容を取得することができる。
以上の処理により、中継サーバ120は、MFP100とPC110との間のRUI通信の通信内容をPC103に送信することができる。その際、中継サーバ120は、PC103からのGET要求に対するGET応答を、PC110用の最新のGET応答に差し替えて応答することができる。
以上、本実施形態によれば、MFP100とPC110との間におけるRUI通信の通信内容を、ユーザ側のPC103から閲覧することができる。なお、本実施形態では、クライアントサイドプロキシ430とWebブラウザ431とはPC103上にあるものとしたが、MFP100上にあってもよい。この場合、クライアントサイドプロキシ430が直接、サーバサイドプロキシ401と通信し、Webサーバ402からのHTTP応答を横流しする構成であってもよい。また、PC110が実行する処理は、上述した図11と同様であるため説明を省略する。
<実施形態6>
本実施形態は、MFP100とPC110との間のRUI通信を、MFP100とPC103との間のRUI通信に切り替え可能とするものである。一般的に、サービスマンがユーザの画像形成装置の保守を行う場合、作業内容によっては、顧客側で実施してもらう場合もある。例えば、画像形成装置の保守において、サービスマンが画像形成装置の修復のため設定値を変更する場合、画像形成装置の情報をPCにバックアップする作業がよく行われる。バックアップする情報に顧客側の機密情報が含まれる場合、そのバックアップ操作は顧客側で実施してもらわなければならない。
本実施形態では、MFP100とPC110との間で行われているRUI通信を、MFP100とPC103との間の接続に切り替える構成について説明する。なお、上述した実施形態1から5までと同様の構成については詳細な説明を省略する。また、本実施形態におけるシステム構成は、図27と同様であるものとする。
図31は、本実施形態におけるPC110の処理の一例を示すフローチャートである。
S2701からS2718までの処理は、図11のS901からS918までの処理と同様であるため説明を省略する。
クライアントサイドプロキシ410は、中継サーバ120からRUI閲覧切替要求を受信する(S2719)。
クライアントサイドプロキシ410は、Webブラウザ411からHTTP要求を受信したか否か判定する(S2720)。クライアントサイドプロキシ410は、HTTP要求を受信したと判定した場合、S2721へ進み、HTTP要求を受信していないと判定した場合、HTTP要求の受信を待つ。
クライアントサイドプロキシ410は、HTTP要求を中継サーバ120にPOSTする(S2721)。クライアントサイドプロキシ410によりS2721で中継サーバ120にPOSTされたHTTP要求は、中継サーバ120側で読み捨てられる。本実施形態では、Webブラウザ411からのHTTP要求をクライアントサイドプロキシ410が中継サーバ120にPOSTしているが、クライアントサイドプロキシ430が読み捨てる構成であってもよい。
クライアントサイドプロキシ410は、RUI応答データキューからHTTP応答を受信するため搬出用URLへGETを出す(S2722)。
クライアントサイドプロキシ410は、S2722で出したGETに対するHTTP応答を中継サーバ120から受信したか否かを判定する(S2723)。クライアントサイドプロキシ410は、HTTP応答を受信したと判定した場合、S2724へ進み、HTTP応答を受信していないと判定した場合、S2722へ戻る。なお、S2723でクライアントサイドプロキシ410が受信したHTTP応答は、MFP100がPC103向けに返しているHTTP応答である。
クライアントサイドプロキシ410は、中継サーバ120から受信したGET応答(HTTP応答)からID部分を取り出す(S2724)。より具体的には、クライアントサイドプロキシ410は、GET応答を変換して、IDとHTTP要求とを取得する。
クライアントサイドプロキシ410は、ID部分を取り除いたHTTP応答を、Webブラウザ411からのHTTP要求の応答として返す(S2725)。
クライアントサイドプロキシ410は、PC110の操作部317を介してユーザから終了指示を受けたか否かを判定する(S2726)。クライアントサイドプロキシ410は、終了指示を受けたと判定した場合、中継サービス420に切断指示を出し、図31の処理を終了する(S2727)。一方、クライアントサイドプロキシ410は、終了指示を受けていないと判定した場合、S2720へ戻る。
図32は、本実施形態におけるPC103の処理の一例を示すフローチャートである。
S2801からS2820までの処理は、図11のS901からS920までの処理と同様であるため説明を省略する。本実施形態では、S2806で選択される支援先のMFP100は、既にPC110と通信中であるものとする。また、S2809で、クライアントサイドプロキシ430が中継サーバ120にRUI接続要求を送信することにより、PC103とMFP100との間のRUI通信が開始される。既に通信中であったMFP100とPC110との間のRUI通信は、閲覧のみだけの通信となる。
図33は、本実施形態における中継サーバ120の処理の一例を示すフローチャートである。
S2901からS2926までの処理は、図30のS2601からS2626までの処理と同様であるため説明を省略する。
中継サービス420は、クライアントサイドプロキシ430からRUI接続要求を受信する(S2927)。
中継サービス420は、クライアントサイドプロキシ410へRUI閲覧切替を通知する(S2928)。これにより、中継サービス420は、MFP100とPC110との通信を閲覧のみのRUI通信に切り替え、操作可能なRUI通信がMFP100とPC103との間で行われるように切り替えることができる。
S2930からS2932までの処理は、図30のS2628からS2630までの処理と同様であるため説明を省略する。
S2934、S2940の処理は、図30のS2634、S2640の処理と同様であるため説明を省略する。
中継サービス420は、クライアントサイドプロキシ410からPOSTされたHTTP要求を読み捨てる(S2933)。S2933の処理は、削除処理の一例である。これにより、中継サービス420は、MFP100とPC110との通信を閲覧のみのRUI通信にすることができる。
S2935からS2939までの処理は、図30のS2635からS2639までの処理と同様であるため説明を省略する。
中継サービス420は、HTTP要求をRUI要求データキューに格納する(S2941)。
中継サービス420は、RUI要求データキューから取り出すための搬出用URLへのサーバサイドプロキシ401からのGETを待つ(S2942)。
中継サービス420は、RUI要求データキューに格納したHTTP要求をGETの応答としてサーバサイドプロキシ401へ送信する(S2943)。
S2944の処理は、図30のS2642の処理と同様であるため説明を省略する。
以上、本実施形態によれば、中継サーバ120は、MFP100とPC110との間のRUI通信を閲覧のみの通信に切り替え、MFP100とのRUI通信における操作権を新たに接続されたPC103に切り替えることができる。これにより、MFP100に対するサービスマン(PC110のユーザ)の操作権を顧客(PC103のユーザ)に移行させることができるようになる。
<実施形態7>
本実施形態では、RUIがSSL(Secure Sockets Layer)通信(暗号化通信)を必要としていても、MFP100とPC110との間のRUI通信の内容を、ユーザ(顧客)側のPC103から閲覧可能とする構成について説明する。なお、上述した実施形態1から6までと同様の構成については詳細な説明を省略する。また、本実施形態におけるシステム構成は、図27と同様であるものとする。
PC110が中継サーバ120と接続を行う際の処理を示すフローチャートは、実施形態5と同様で図11に示す通りだが、一部の処理が異なるため、差異について説明する。
図11のS902の処理において、クライアントサイドプロキシ410は、S901でアプリが起動されたと判定した場合、PC110の操作部317に認証情報入力画面を表示する。加えて本実施形態では、S902において、クライアントサイドプロキシ410は、中継サーバ120とSSLのネゴシエーションを実施する。これにより、PC110は、SSL共通鍵を取得し、以降の中継サーバ120とのHTTP通信を全て暗号化して実施する。
PC103が中継サーバ120と接続を行う際の処理を示すフローチャートは、実施形態5で図29を用いて説明した通りだが、一部の処理が異なるため、差異について説明する。
図29のS2502の処理において、クライアントサイドプロキシ430は、S2501でアプリが起動されたと判定した場合、PC103の操作部317に認証情報入力画面を表示する。加えて本実施形態では、S2502において、クライアントサイドプロキシ430は、中継サーバ120とSSLのネゴシエーションを実施する。これにより、PC103は、SSL共通鍵を取得し、以降の中継サーバ120とのHTTP通信を全て暗号化して実施する。
中継サーバ120がMFP100やPC110と接続を行う際の処理を示すフローチャートは、実施形態5で図30を用いて上述した通りであるため説明を省略する。
図34は、本実施形態におけるMFP100が中継サーバ120と接続を行う処理の一例を示すフローチャートである。
サーバサイドプロキシ401は、操作部219を介してコールセンターの起動指示があったか否かを判定する(S3001)。
サーバサイドプロキシ401は、中継サーバ120とSSLのネゴシエーションを実施する(S3002)。これにより、サーバサイドプロキシ401は、SSL共通鍵を取得し、以降の中継サーバ120とのHTTP通信を全て暗号化して実施することができる。
S3003からS3011までの処理は、図8のS702からS710までの処理と同様であるため説明を省略する。なお、S3010において、サーバサイドプロキシ401は、S3002で取得したSSL共通鍵を使用してGETしたHTTPデータを復号する。
サーバサイドプロキシ401は、S3011の処理でHTTP要求を取得すると、HTTP要求の接続先のWebサーバ402がSSLでの接続を必要としているか否かを判定する(S3012)。サーバサイドプロキシ401は、SSL接続が必要だと判定した場合、S3013へ進み、SSL接続が不要だと判定した場合、S3018へ進む。S3012での判定の方法として、サーバサイドプロキシ401は、Webサーバ402に接続してからHTTPSのページにリダイレクト(誘導)されるか否かで判定してもよい。この際、サーバサイドプロキシ401は、HTTPSのページにリダイレクトされた場合、SSL接続が必要だと判定する。また、サーバサイドプロキシ401は、予めHDD214にSSL接続が必要なWebサーバ402の情報(登録情報)を登録しておくことにより判定してもよい。なお、HTTPSは、Hypertext Transfer Protocol Secureの略である。
サーバサイドプロキシ401は、S3012でSSL接続が必要だと判定した場合、Webサーバ402とSSLのネゴシエーションを実施する(S3013)。
サーバサイドプロキシ401は、S3013でWebサーバ402から取得したSSL共通鍵により、S3011で取得したHTTP要求を暗号化する(S3014)。
サーバサイドプロキシ401は、S3014で暗号化したHTTP要求をWebサーバ402に送信する(S3015)。
サーバサイドプロキシ401は、S3015の要求の応答として、Webサーバ402から暗号化されたHTTP応答を受信する(S3016)。
サーバサイドプロキシ401は、SSL共通鍵により、S3016で受信したHTTP応答を復号する(S3017)。そして、サーバサイドプロキシ401は、S3020へ進む。
サーバサイドプロキシ401は、S3012でSSL接続が不要だと判定した場合、Webサーバ402へHTTP要求を送信する(S3018)。
サーバサイドプロキシ401は、S3017の要求の応答として、Webサーバ402からHTTP応答を受信する(S3019)。そして、サーバサイドプロキシ401は、S3020へ進む。
サーバサイドプロキシ401は、S3017又はS3019の処理の後、Webサーバ402から受信したHTTP応答にHDD214に記憶しているIDを付加しRUI応答データキューに格納するため格納用URLへ送信する(S3020)。
S3021、S3022の処理は、図8のS714、S715の処理と同様であるため説明を省略する。
これらの一連の処理では、PC110とMFP100との通信経路はSSLで暗号化されているが、サーバサイドプロキシ401がWebサーバ402からの暗号化されたHTTPデータを復号して中継サービス420に送信する。そのため、PC103が中継サーバ120への認証を行った上で接続した場合、PC110とMFP100との通信の内容を監視することが可能となる。
以上、本実施形態によれば、RUIがSSL通信を必要としていても、MFP100とPC110との間のRUI通信の内容を、ユーザ側のPC103から閲覧することができるようになる。
<実施形態8>
本実施形態では、RUIがSSL通信を必要としていても、Webサーバ402で受け付けたHTTP要求の接続元(要求元)がMFP100の外部からでない場合、SSL接続なしでも接続を可能とする構成について説明する。なお、上述した実施形態1から7までと同様の構成については詳細な説明を省略する。また、本実施形態におけるシステム構成は、図27と同様であるものとする。
図35は、本実施形態におけるMFP100が中継サーバ120と接続を行う際の処理の一例を示すフローチャートである。
S3101からS3111までの処理は、図34のS3001からS3011までの処理と同様であるため説明を省略する。
サーバサイドプロキシ401は、Webサーバ402へHTTP要求を送信する(S3112)。
サーバサイドプロキシ401は、Webサーバ402で受け付けたHTTP要求の接続元がMFP100の外部からでない、即ち、MFP100の内部からであることを確認する(S3113)。ここで、サーバサイドプロキシ401は、ローカルループバックアドレスからの接続であれば、接続元がMFP100の外部からでないと判定するようにしてもよい。また、サーバサイドプロキシ401は、前記接続元の所有する証明書(証明情報)によって、前記接続元がMFP100の外部からでないことを確認するようにしてもよい。より具体的には、サーバサイドプロキシ401は、予め記憶されている証明書と、前記接続元の所有する証明書とが一致する場合、前記接続元がMFP100の外部からでないと判定するようにしてもよい。上述したように、本実施形態では、Webサーバ402で受け付けたHTTP要求の接続元がMFP100の外部からでない場合、SSL接続なしでも接続を可能とする。
サーバサイドプロキシ401は、S3113で、Webサーバ402で受け付けたHTTP要求の接続元がMFP100の外部からでないことを確認すると、S3114へ進む。一方、サーバサイドプロキシ401は、S3113で、HTTP要求の接続元がMFP100の外部からであることを確認した場合、前記接続元とのセキュアでない(暗号化されていない)接続を切断して、図35の処理を終了する。
サーバサイドプロキシ401は、S3112の要求の応答として、Webサーバ402からHTTP応答を受信する(S3114)。
S3115からS3117までの処理は、図34のS3020からS3022までの処理と同様であるため説明を省略する。
PC110、PC103が中継サーバ120と接続を行う際の処理は、実施形態7で図29を用いて説明した通りであるため説明を省略する。また、中継サーバ120がMFP100やPC110と接続を行う際の処理は、実施形態5で図30を用いて上述した通りであるため説明を省略する。なお、本実施形態では、RUIがSSL通信を必要とする場合を前提として説明したが、図34のS3012のように、サーバサイドプロキシ401が、Webサーバ402がSSLでの接続を必要としているか否かを判定するようにしてもよい。
以上、本実施形態によれば、RUIがSSL通信を必要としていても、Webサーバ402で受け付けたHTTP要求の接続元がMFP100の内部に存在する場合、SSL接続なしでも接続が可能となる。これにより、前記接続元がMFP100の内部に存在する場合、前記接続元は、RUIがSSL通信を必要としていても、MFP100内のHTTPデータを閲覧することができるようになる。
<その他の実施形態>
また、本発明は、以下の処理を実行することによっても実現される。即ち、上述した実施形態の機能を実現するソフトウェア(プログラム)を、ネットワーク又は各種記憶媒体を介してシステム或いは装置に供給し、そのシステム或いは装置のコンピュータ(又はCPUやMPU等)がプログラムを読み出して実行する処理である。
また、上述した各実施形態におけるシステムに含まれるMFPを、PC、サーバ装置、タブレット端末等の他の情報処理装置に置き換えた場合においても同様の効果を得ることができる。
以上、上述した各実施形態によれば、セキュアな通信環境でのWebサービスの利用における利便性を向上させることができる。より具体的には、ファイアウォールの内側にある情報処理装置から、インターネットを経由して異なるファイアウォールの内側にある画像形成装置のWebサービス機能に接続することができる。これにより、前記情報処理装置から前記Webサービスにおけるバックアップ、リストア等の機能を利用することが可能となる。
以上、本発明の好ましい形態について詳述したが、本実施形態は係る特定の実施形態に限定されるものではなく、特許請求の範囲に記載された本発明の要旨の範囲内において、種々の変形・変更が可能である。

Claims (14)

  1. 第1の形式の通信要求を処理する処理手段が暗号化された通信を要するか否かを判定する判定手段と、
    前記判定手段により前記処理手段が暗号化された通信を要すると判定された場合、要求された第2の形式の通信要求を変換した第1の形式の通信要求を暗号化する暗号化手段と、
    前記暗号化手段により暗号化された前記第1の形式の通信要求に対する前記処理手段からの暗号化された第1の形式の通信応答を復号する復号手段と、
    前記復号手段により復号された前記第1の形式の通信応答を変換した第2の形式の通信応答を、前記第2の形式の通信要求に対する応答として送信する応答手段と、
    を有する情報処理装置。
  2. 前記判定手段は、前記処理手段が暗号化された通信を要求するか否かを、前記処理手段に接続した際に暗号化された通信に係る処理へ誘導されるか否かに基づいて判定する請求項1に記載の情報処理装置。
  3. 前記判定手段は、前記処理手段が暗号化された通信を要求するか否かを、暗号化された通信を要する処理手段を示す登録情報に基づいて判定する請求項1に記載の情報処理装置。
  4. 自装置と前記第1の形式の通信要求の要求元との通信を中継するサーバ装置から、前記第1の形式の通信要求を変換した前記第2の形式の通信要求を受信する受信手段を更に有し、
    前記暗号化手段は、前記受信手段により受信された前記第2の形式の通信要求を変換した前記第1の形式の通信要求を暗号化し、
    前記応答手段は、前記第2の形式の通信応答を、前記第2の形式の通信要求に対する応答として前記サーバ装置に送信する請求項1乃至3の何れか1項に記載の情報処理装置。
  5. 第1の形式の通信要求を処理する処理手段に対する前記第1の形式の通信要求の要求元が自装置の内部であるか否かを判定する判定手段と、
    前記処理手段が暗号化された通信を要する場合であっても、前記判定手段により前記要求元が自装置の内部であると判定された場合、要求された第2の形式の通信要求を変換した暗号化されていない第1の形式の通信要求を前記処理手段に送信する送信手段と、
    前記送信手段により送信された前記第1の形式の通信要求に対する前記処理手段からの第1の形式の通信応答を変換した第2の形式の通信応答を、前記第2の形式の通信要求に対する応答として送信する応答手段と、
    を有する情報処理装置。
  6. 前記判定手段により前記要求元が自装置の内部でないと判定された場合であって、前記要求元との通信が暗号化されていない場合、前記要求元との通信を切断する切断手段を更に有する請求項5に記載の情報処理装置。
  7. 前記判定手段は、前記要求元がループバックアドレスからの接続であれば、前記要求元が自装置の内部であると判定する請求項5又は6に記載の情報処理装置。
  8. 前記判定手段は、前記要求元の証明情報が登録されている証明情報と一致する場合、前記要求元が自装置の内部であると判定する請求項5又は6に記載の情報処理装置。
  9. 自装置と前記第1の形式の通信要求の要求元との通信を中継するサーバ装置から、前記第1の形式の通信要求を変換した前記第2の形式の通信要求を受信する受信手段を更に有し、
    前記送信手段は、前記受信手段により受信された前記第2の形式の通信要求を変換した暗号化されていない前記第1の形式の通信要求を前記処理手段に送信し、
    前記応答手段は、前記第2の形式の通信応答を、前記第2の形式の通信要求に対する応答として前記サーバ装置に送信する請求項5乃至8の何れか1項に記載の情報処理装置。
  10. 前記第1の形式は、HTTPに係る通信形式であり、
    前記第2の形式は、URIスキームでのHTTPに係る通信形式である請求項1乃至9の何れか1項に記載の情報処理装置。
  11. 前記情報処理装置は画像形成装置である請求項1乃至10の何れか1項に記載の情報処理装置。
  12. 情報処理装置が実行する情報処理方法であって、
    第1の形式の通信要求を処理する処理手段が暗号化された通信を要するか否かを判定する判定ステップと、
    前記判定ステップにより前記処理手段が暗号化された通信を要すると判定された場合、要求された第2の形式の通信要求を変換した第1の形式の通信要求を暗号化する暗号化ステップと、
    前記暗号化ステップにより暗号化された前記第1の形式の通信要求に対する前記処理手段からの暗号化された第1の形式の通信応答を復号する復号ステップと、
    前記復号ステップにより復号された前記第1の形式の通信応答を変換した第2の形式の通信応答を、前記第2の形式の通信要求に対する応答として送信する応答ステップと、
    を含む情報処理方法。
  13. 情報処理装置が実行する情報処理方法であって、
    第1の形式の通信要求を処理する処理手段に対する前記第1の形式の通信要求の要求元が自装置の内部であるか否かを判定する判定ステップと、
    前記処理手段が暗号化された通信を要する場合であっても、前記判定ステップにより前記要求元が自装置の内部であると判定された場合、要求された第2の形式の通信要求を変換した暗号化されていない第1の形式の通信要求を前記処理手段に送信する送信ステップと、
    前記送信ステップにより送信された前記第1の形式の通信要求に対する前記処理手段からの第1の形式の通信応答を変換した第2の形式の通信応答を、前記第2の形式の通信要求に対する応答として送信する応答ステップと、
    を含む情報処理方法。
  14. 請求項12又は13に記載の情報処理方法をコンピュータに実行させるためのプログラム。
JP2014055434A 2014-03-18 2014-03-18 情報処理装置、情報処理方法及びプログラム Expired - Fee Related JP6395405B2 (ja)

Priority Applications (1)

Application Number Priority Date Filing Date Title
JP2014055434A JP6395405B2 (ja) 2014-03-18 2014-03-18 情報処理装置、情報処理方法及びプログラム

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
JP2014055434A JP6395405B2 (ja) 2014-03-18 2014-03-18 情報処理装置、情報処理方法及びプログラム

Publications (2)

Publication Number Publication Date
JP2015179105A true JP2015179105A (ja) 2015-10-08
JP6395405B2 JP6395405B2 (ja) 2018-09-26

Family

ID=54263221

Family Applications (1)

Application Number Title Priority Date Filing Date
JP2014055434A Expired - Fee Related JP6395405B2 (ja) 2014-03-18 2014-03-18 情報処理装置、情報処理方法及びプログラム

Country Status (1)

Country Link
JP (1) JP6395405B2 (ja)

Citations (8)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2001292176A (ja) * 2000-04-10 2001-10-19 Fuji Electric Co Ltd 制御・情報ネットワーク統合用ゲートウェイ装置および制御・情報ネットワーク統合方法
US20030200331A1 (en) * 2002-03-28 2003-10-23 Netaphor Software, Inc. Mechanism for communicating with multiple HTTP servers through a HTTP proxy server from HTML/XSL based web pages
JP2006048588A (ja) * 2004-08-09 2006-02-16 Matsushita Electric Ind Co Ltd リモート診断システム及びリモート診断方法
JP2006352336A (ja) * 2005-06-14 2006-12-28 Canon Inc 電子機器の制御方法
US20080084576A1 (en) * 2006-10-10 2008-04-10 Nehal Dantwala System and method to remotely control the front panel of a multi-function peripheral from an embedded web server
JP2008536369A (ja) * 2005-03-18 2008-09-04 リバーベッド テクノロジー インコーポレーティッド 接続転送
JP2010102704A (ja) * 2008-10-07 2010-05-06 Ricoh Co Ltd ソフトウエア更新リクエストを処理するためのシステム、方法及びコンピュータ読取可能な記録媒体
US20100281188A1 (en) * 2009-04-29 2010-11-04 Andrew Rodney Ferlitsch Methods and Systems for Outlying Peripheral Device Management

Patent Citations (8)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2001292176A (ja) * 2000-04-10 2001-10-19 Fuji Electric Co Ltd 制御・情報ネットワーク統合用ゲートウェイ装置および制御・情報ネットワーク統合方法
US20030200331A1 (en) * 2002-03-28 2003-10-23 Netaphor Software, Inc. Mechanism for communicating with multiple HTTP servers through a HTTP proxy server from HTML/XSL based web pages
JP2006048588A (ja) * 2004-08-09 2006-02-16 Matsushita Electric Ind Co Ltd リモート診断システム及びリモート診断方法
JP2008536369A (ja) * 2005-03-18 2008-09-04 リバーベッド テクノロジー インコーポレーティッド 接続転送
JP2006352336A (ja) * 2005-06-14 2006-12-28 Canon Inc 電子機器の制御方法
US20080084576A1 (en) * 2006-10-10 2008-04-10 Nehal Dantwala System and method to remotely control the front panel of a multi-function peripheral from an embedded web server
JP2010102704A (ja) * 2008-10-07 2010-05-06 Ricoh Co Ltd ソフトウエア更新リクエストを処理するためのシステム、方法及びコンピュータ読取可能な記録媒体
US20100281188A1 (en) * 2009-04-29 2010-11-04 Andrew Rodney Ferlitsch Methods and Systems for Outlying Peripheral Device Management

Also Published As

Publication number Publication date
JP6395405B2 (ja) 2018-09-26

Similar Documents

Publication Publication Date Title
KR101900799B1 (ko) 정보처리장치, 시스템, 정보처리방법 및 기억매체
CN101465888B (zh) 网络系统、直接访问方法和网络家用电器
US9407611B2 (en) Network system, management server system, control method, and storage medium for tenant transition
JP2018156411A (ja) ドキュメント管理システム及び管理装置
JP2005157881A (ja) サーバ端末装置、クライアント端末装置、オブジェクト管理システム、オブジェクト管理方法、コンピュータプログラム及び記録媒体
JP2015103917A (ja) スキャン実行の際の認証及び設定に関するサーバ、画像処理装置、サービス方法及び画像処理方法
JP6341710B2 (ja) サーバ装置及び情報処理方法
JP2015225616A (ja) クライアント装置、サービス実行システム、及びプログラム
EP3588907B1 (en) Information processing apparatus, control method for information processing apparatus, and storage medium
JP6197286B2 (ja) 通信装置、情報処理システム及び情報処理システムの制御方法
JP6395405B2 (ja) 情報処理装置、情報処理方法及びプログラム
JP5011692B2 (ja) バックアップリストアシステム、バックアップリストア方法、バックアップシステム、バックアップ方法
JP2019160056A (ja) 情報処理装置及びクッキー情報管理方法
US10521168B2 (en) Encrypted document printing utilizing multiple networks
JP2018037927A (ja) 情報処理装置、情報処理システム、情報処理方法、及びプログラム
JP2020160503A (ja) 情報処理システム
JP6318759B2 (ja) 情報管理装置、情報管理システム、情報管理方法、及びプログラム
JP6723804B2 (ja) システム、中継クライアント、制御方法、及びプログラム
JP7040271B2 (ja) 情報処理装置、情報処理システム、画像処理システム、情報処理方法、及びプログラム
JP2015226292A (ja) 中継装置、サービス実行システム、及びプログラム
JP2016038805A (ja) 情報処理システム、情報処理装置及びその制御方法、及びプログラム
JP2018055569A (ja) 情報処理装置及びその制御方法、及びプログラム
JP2008102566A (ja) 印刷処理システムおよび印刷処理プログラム
CN117319067A (zh) 一种基于数字证书的身份认证方法、系统及可读存储介质
JP2019207732A (ja) ドキュメント管理システム、管理装置及び処理装置

Legal Events

Date Code Title Description
A621 Written request for application examination

Free format text: JAPANESE INTERMEDIATE CODE: A621

Effective date: 20170316

A977 Report on retrieval

Free format text: JAPANESE INTERMEDIATE CODE: A971007

Effective date: 20180119

A131 Notification of reasons for refusal

Free format text: JAPANESE INTERMEDIATE CODE: A131

Effective date: 20180206

A521 Request for written amendment filed

Free format text: JAPANESE INTERMEDIATE CODE: A523

Effective date: 20180329

TRDD Decision of grant or rejection written
A01 Written decision to grant a patent or to grant a registration (utility model)

Free format text: JAPANESE INTERMEDIATE CODE: A01

Effective date: 20180731

A61 First payment of annual fees (during grant procedure)

Free format text: JAPANESE INTERMEDIATE CODE: A61

Effective date: 20180828

R151 Written notification of patent or utility model registration

Ref document number: 6395405

Country of ref document: JP

Free format text: JAPANESE INTERMEDIATE CODE: R151

LAPS Cancellation because of no payment of annual fees