KR20170118643A - 정보처리장치, 시스템, 정보처리방법 및 기억매체 - Google Patents

정보처리장치, 시스템, 정보처리방법 및 기억매체 Download PDF

Info

Publication number
KR20170118643A
KR20170118643A KR1020170129424A KR20170129424A KR20170118643A KR 20170118643 A KR20170118643 A KR 20170118643A KR 1020170129424 A KR1020170129424 A KR 1020170129424A KR 20170129424 A KR20170129424 A KR 20170129424A KR 20170118643 A KR20170118643 A KR 20170118643A
Authority
KR
South Korea
Prior art keywords
side proxy
request
server
client
response
Prior art date
Application number
KR1020170129424A
Other languages
English (en)
Other versions
KR101900799B1 (ko
Inventor
다이키 타치
마사시 니시야마
켄타 후쿠시마
Original Assignee
캐논 가부시끼가이샤
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 캐논 가부시끼가이샤 filed Critical 캐논 가부시끼가이샤
Publication of KR20170118643A publication Critical patent/KR20170118643A/ko
Application granted granted Critical
Publication of KR101900799B1 publication Critical patent/KR101900799B1/ko

Links

Images

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/02—Network architectures or network communication protocols for network security for separating internal from external traffic, e.g. firewalls
    • H04L63/029—Firewall traversal, e.g. tunnelling or, creating pinholes
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/50—Network services
    • H04L67/60—Scheduling or organising the servicing of application requests, e.g. requests for application data transmissions using the analysis and optimisation of the required network resources
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N1/00—Scanning, transmission or reproduction of documents or the like, e.g. facsimile transmission; Details thereof
    • H04N1/00127—Connection or combination of a still picture apparatus with another apparatus, e.g. for storage, processing or transmission of still picture signals or of information associated with a still picture
    • H04N1/00344—Connection or combination of a still picture apparatus with another apparatus, e.g. for storage, processing or transmission of still picture signals or of information associated with a still picture with a management, maintenance, service or repair apparatus
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L69/00—Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass
    • H04L69/08—Protocols for interworking; Protocol conversion
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F3/00—Input arrangements for transferring data to be processed into a form capable of being handled by the computer; Output arrangements for transferring data from processing unit to output unit, e.g. interface arrangements
    • G06F3/12—Digital output to print unit, e.g. line printer, chain printer
    • G06F3/1201—Dedicated interfaces to print systems
    • G06F3/1278—Dedicated interfaces to print systems specifically adapted to adopt a particular infrastructure
    • G06F3/1285—Remote printer device, e.g. being remote from client or server
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/16—Implementing security features at a particular protocol layer
    • H04L63/168—Implementing security features at a particular protocol layer above the transport layer
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/01—Protocols
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/01—Protocols
    • H04L67/02—Protocols based on web technology, e.g. hypertext transfer protocol [HTTP]
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/2866—Architectures; Arrangements
    • H04L67/2876—Pairs of inter-processing entities at each side of the network, e.g. split proxies
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/50—Network services
    • H04L67/56—Provisioning of proxy services
    • H04L67/562—Brokering proxy services
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/50—Network services
    • H04L67/56—Provisioning of proxy services
    • H04L67/565—Conversion or adaptation of application format or content
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N1/00—Scanning, transmission or reproduction of documents or the like, e.g. facsimile transmission; Details thereof
    • H04N1/32—Circuits or arrangements for control or supervision between transmitter and receiver or between image input and image output device, e.g. between a still-image camera and its memory or between a still-image camera and a printer device
    • H04N1/32101—Display, printing, storage or transmission of additional information, e.g. ID code, date and time or title
    • H04N1/32106—Display, printing, storage or transmission of additional information, e.g. ID code, date and time or title separate from the image data, e.g. in a different computer file
    • H04N1/32117—Display, printing, storage or transmission of additional information, e.g. ID code, date and time or title separate from the image data, e.g. in a different computer file in a separate transmission or protocol signal prior to or subsequent to the image data transmission, e.g. in digital identification signal [DIS], in non standard setup [NSS] or in non standard field [NSF]
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N1/00—Scanning, transmission or reproduction of documents or the like, e.g. facsimile transmission; Details thereof
    • H04N1/44—Secrecy systems
    • H04N1/4406—Restricting access, e.g. according to user identity

Landscapes

  • Engineering & Computer Science (AREA)
  • Signal Processing (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Computer Security & Cryptography (AREA)
  • General Engineering & Computer Science (AREA)
  • Computer Hardware Design (AREA)
  • Computing Systems (AREA)
  • Multimedia (AREA)
  • Theoretical Computer Science (AREA)
  • Human Computer Interaction (AREA)
  • General Physics & Mathematics (AREA)
  • Physics & Mathematics (AREA)
  • Information Transfer Between Computers (AREA)
  • Computer And Data Communications (AREA)
  • Facsimiles In General (AREA)
  • Communication Control (AREA)
  • Control Or Security For Electrophotography (AREA)
  • Telephonic Communication Services (AREA)

Abstract

안전한 통신 환경에서의 웹 서비스의 이용에 있어서의 편리성을 향상시키기 위해서, 정보처리장치는, 제1 형식에 따른 통신 요구를 제2 형식에 따른 통신 요구로 변환하는 변환부와, 상기 변환부에 의해 변환된 상기 제2 형식에 따른 상기 통신 요구를 송신하는 요구 송신부와, 상기 요구 송신부에 의해 송신된 상기 제2 형식에 따른 상기 통신 요구에 응답하여 되돌려진 상기 제2 형식에 따른 통신 응답을 수신하는 응답 수신부와, 상기 응답 수신부에 의해 수신된 상기 제2 형식에 따른 통신 응답으로부터 변환된 상기 제1 형식에 따른 통신 응답을, 상기 제1 형식에 따른 상기 통신 요구에 대한 응답으로서, 취득하는 취득부를 구비한다.

Description

정보처리장치, 시스템, 정보처리방법 및 기억매체{INFORMATION PROCESSING APPARATUS, SYSTEM, INFORMATION PROCESSING METHOD, AND STORAGE MEDIUM}
본 발명은, 정보처리장치, 시스템, 정보처리방법 및 기억매체에 관한 것이다.
현재, 화상형성장치로는, 음성이나 동영상 통신, 원격조작에 의거한 원격 보수 서비스가 제안되어 있다(일본국 공개특허공보 특개2005-208974호).
또한, 화상형성장치는 웹 서버나 파일서버 등의 서버 기능을 가지게 되어 있고, 유저는, 네트워크를 거쳐서 리모트(remote) 단말로부터 화상형성장치의 서버 기능을 이용할 수 있다. 이러한 서버 기능의 하나로서 리모트 유저 인터페이스(ＲＵＩ) 등의 웹 서비스가 있다.
유저는, ＲＵＩ기능을 가지는 화상형성장치에 대하여는, 퍼스널 컴퓨터(ＰＣ)에 설치된 웹 브라우저 등으로부터 화상형성장치의 정보를 ＰＣ에 백업해, 이 정보를 다른 화상형성장치에 리스토어(restore)할 수 있다(일본국 공개특허공보 특개2005-202918호).
그렇지만, 유저는, 원격보수 서비스를 사용해서 원격지에 있는 화상형성장치의 ＲＵＩ에 접속하려고 하는 경우에도, 화상형성장치가 인터넷상의 파이어월(firewall)의 내측에 존재하는 환경에서는 ＲＵＩ에 접속할 수 없다. 왜냐하면, 파이어월은, 파이어월 외측의 단말로부터 파이어월 내측의 단말까지의 접속을 거부하도록 구성되어 있으므로, 유저가 파이어월 외측의 단말로부터 인터넷상의 ＲＵＩ에 접속할 수 없기 때문이다.
그 때문에, 화상형성장치의 제조사의 서비스 엔지니어 등은, 원격보수 서비스를 사용해서 고객처에 있는 화상형성장치의 ＲＵＩ에 접속해서 정보의 백업이나 리스토어를 행할 수는 없었다.
본 발명은, 안전한(secure) 통신 환경에서의 웹 서비스의 이용에 있어서의 편리성을 향상시킬 수 있는 정보처리장치, 시스템 및 정보처리방법을 대상으로 삼는다.
본 발명의 일 국면에 따른 정보처리장치는, 제1 형식에 따른 통신 요구를 제2 형식에 따른 통신 요구로 변환하는 변환부와, 상기 제2 형식에 따른 통신 요구를 송신하는 요구 송신부와, 상기 제2 형식에 따른 통신 요구에 응답하여 되돌려진 상기 제2 형식에 따른 통신 응답을 수신하는 응답 수신부와, 상기 제2 형식에 따른 상기 수신된 통신 응답으로부터 변환된 상기 제1 형식에 따른 통신 응답을, 상기 제1 형식에 따른 통신 요구에 대한 응답으로서, 취득하는 취득부를 구비한다.
본 발명의 또 다른 특징들은, 첨부도면을 참조하여 이하의 예시적 실시예들의 설명으로부터 명백해질 것이다.
도 1은 시스템 구성의 일례를 도시한 블록도다.
도 2는 복합기(ＭＦＰ)의 하드웨어 구성의 일례를 도시한 블록도다.
도 3은 퍼스널 컴퓨터(ＰＣ) 및 중계 서버의 하드웨어 구성의 일례를 도시한 블록도다.
도 4는 ＭＦＰ, ＰＣ 및 중계 서버 각각의 기능 구성의 일례를 도시한 블록도다.
도 5는 ＭＦＰ, ＰＣ 및 중계 서버에서 행한 처리의 일례를 도시하는 시퀀스 도다.
도 6a 및 6b는 하이퍼텍스트 전송 프로토콜(ＨＴＴＰ) 데이터의 일례를 각각 도시한 도면이다.
도 7은 식별(ＩＤ)테이블의 일례를 도시한 도면이다.
도 8은 제1 예시적 실시예에 따른 ＭＦＰ가 행한 처리의 일례를 도시하는 흐름도다.
도 9a, 9b 및 9c는 ＭＦＰ의 조작 화면의 일례를 각각 도시한 도면이다.
도 10a 및 10b는 ＨＴＴＰ데이터의 일례를 각각 도시한 도면이다.
(도 11a 및 도 11b로 이루어진) 도 11은 제1 예시적 실시예에 따른 ＰＣ가 행한 처리의 일례를 도시하는 흐름도다.
도 12a, 12b 및 12c는 ＰＣ의 조작 화면의 일례를 각각 도시한 도면이다.
도 13a, 13b 및 13c는 ＨＴＴＰ데이터의 일례를 각각 도시한 도면이다.
도 14는 제1 예시적 실시예에 따른 중계 서버가 행한 처리의 일례를 도시하는 흐름도다.
(도 15a 및 도 15b로 이루어진) 도 15는 제2 예시적 실시예에 따른 ＰＣ가 행한 처리의 일례를 도시하는 흐름도다.
도 16a, 16b 및 16c는, ＨＴＴＰ데이터의 일례를 각각 도시한 도면이다.
도 17은 제2 예시적 실시예에 따른 중계 서버가 행한 처리의 일례를 도시하는 흐름도다.
도 18은 ＩＤ테이블의 일례를 도시한 도면이다.
도 19는 ＨＴＴＰ데이터의 일례를 도시한 도면이다.
도 20은 제3 예시적 실시예에 따른 ＭＦＰ가 행한 처리의 일례를 도시하는 흐름도다.
도 21a, 21b 및 21c는 ＨＴＴＰ데이터의 일례를 각각 도시한 도면이다.
도 22는 제3 예시적 실시예에 따른 중계 서버가 행한 처리의 일례를 도시하는 흐름도다.
도 23은 제4 예시적 실시예에 따른 ＭＦＰ가 행한 처리의 일례를 도시하는 흐름도다.
(도 24a 및 도 24b로 이루어진) 도 24는 제4 예시적 실시예에 따른 ＰＣ가 행한 처리의 일례를 도시하는 흐름도다.
도 25a, 25b, 25c, 25d, 25e는 ＨＴＴＰ데이터의 일례를 각각 도시한 도면이다.
도 26은 제4 예시적 실시예에 따른 중계 서버가 행한 처리의 일례를 도시하는 흐름도다.
도 27은 시스템 구성의 일례를 도시한 도면이다.
도 28은 ＭＦＰ, ＰＣ 및 중계 서버 각각의 기능 구성의 일례를 도시한 블록도다.
(도 29a 및 도 29b로 이루어진) 도 29는 제5 예시적 실시예에 따른 ＰＣ가 행한 처리의 일례를 도시하는 흐름도다.
(도 30a 및 도 30b로 이루어진) 도 30은 제5 예시적 실시예에 따른 중계 서버가 행한 처리의 일례를 도시하는 흐름도다.
(도 31a 및 도 31b로 이루어진) 도 31은 제6 예시적 실시예에 따른 ＰＣ가 행한 처리의 일례를 도시하는 흐름도다.
(도 32a 및 도 32b로 이루어진) 도 32는 제6 예시적 실시예에 따른 ＰＣ가 행한 처리의 일례를 도시하는 흐름도다.
(도 33a 및 도 33b로 이루어진) 도 33은 제6 예시적 실시예에 따른 중계 서버가 행한 처리의 일례를 도시하는 흐름도다.
(도 34a 및 도 34b로 이루어진) 도 34는 제7 예시적 실시예에 따른 ＭＦＰ가 행한 처리의 일례를 도시하는 흐름도다.
도 35는 제8 예시적 실시예에 따른 ＭＦＰ가 행한 처리의 일례를 도시하는 흐름도다.
이하, 본 발명을 실시하기 위한 예시적 실시예들에 대해서 도면들을 참조하여 설명한다.
도 1은, 제1 예시적 실시예에 따른 네트워크를 통한 안전한 원격보수 서비스를 제공하는 통신시스템의 시스템 구성의 일례를 도시한 블록도다.
복합기(ＭＦＰ)(즉, 화상형성장치)(100)는, 유저 환경(102)내에 배치되어, 인터넷(130)에 액세스 가능하다. ＭＦＰ(100)는, 정보처리장치의 일례다. "ＭＦＰ"란, "Ｍｕｌｔｉｆｕｎｃｔｉｏｎ Ｐｅｒｉｐｈｅｒａｌ"를 의미한다.
ＰＣ(110)는, 콜 센터(112)내에 배치되어, 인터넷(130)에 액세스 가능하다. ＰＣ(110)는, 정보처리장치의 일례다.
통신 시스템은, 복수의 유저 환경(102), 복수의 콜 센터(112), 복수의 ＭＦＰ(100) 및 복수의 ＰＣ(110)를 구비하여도 된다. 또한, 도 1에서는, ＭＦＰ(100)가 유저 환경(102)내에 배치되어 있는 것으로 가정하여 상기 통신 시스템을 설명하지만, 다른 정보처리장치가 유저 환경(102)내에 배치되어 있어도 된다. 여기에서 기술한 그 밖의 정보처리장치는, 예를 들면, ＰＣ, 서버 장치 및 타블렛 단말이어도 된다.
그 유저 환경(102)에는, 파이어월(101)이 설치된다. 또한, 콜 센터(112)에는, 파이어월(111)이 설치된다. 파이어월(101)은, 유저 환경(102)의 내측에 있는 단말로부터 인터넷(130)에의 접속은 허가하지만, 인터넷(130)측으로부터 유저 환경(102)의 내측에 있는 단말에의 접속은 거부하도록 구성되어 있다. 파이어월(111)은, 콜 센터(112)의 내측에 있는 단말로부터 인터넷(130)에의 접속은 허가하지만, 인터넷(130)측으로부터 콜 센터(112)의 내측에 있는 단말에의 접속은 거부하도록 구성되어 있다.
서버 군(121)은, 인터넷(130)을 거쳐 서비스를 각각 제공하는 서버 컴퓨터로 이루어진 서버 군이다. 서버 군(121)은, 서버 컴퓨터는 1대이여도 복수대이어도 된다. 도 1에서는, 서버 군(121)이 중계 서버 장치(이하, 중계 서버)(120)의 1대만으로 구성되어 있는 것으로서 도시하고 있다. 중계 서버(120)는, 정보처리장치의 일례다.
도 2는, ＭＦＰ(100)의 하드웨어 구성의 일례를 도시한 블록도다.
중앙처리장치(ＣＰＵ)(211)를 포함하는 제어부(210)는, ＭＦＰ(100)전체의 동작을 제어한다.
ＣＰＵ(211)는, 판독전용 메모리(ＲＯＭ)(212)나 하드디스크 드라이브(ＨＤＤ)(214)에 격납된 프로그램을 실행하여서, ＭＦＰ(100)의 기능, 후술하는 시퀀스 도에 도시된 ＭＦＰ(100)의 처리 및 ＭＦＰ(100)에 관한 흐름도에 도시된 처리를 실현한다. 1개의 ＣＰＵ(211)가 1개의 메모리(랜덤 액세스 메모리(ＲＡＭ)(213) 또는 ＨＤＤ(214))를 사용해서 ＭＦＰ(100)의 기능, 후술하는 시퀀스 도에 도시된 ＭＦＰ(100)의 처리 및 ＭＦＰ(100)에 관한 흐름도에 도시된 처리를 실현하는 것으로 하는, 본 예시적 실시예를 설명한다. 그러나, ＭＦＰ(100)는 다른 방식으로 구성되어도 된다. 예를 들면, ＭＦＰ(100)는, 복수의 ＣＰＵ가 복수의 ＲＡＭ 또는 ＨＤＤ를 사용해서 ＭＦＰ(100)의 기능, 후술하는 시퀀스 도에 도시된 ＭＦＰ(100)의 처리 및 ＭＦＰ(100)에 관한 흐름도에 도시된 처리를 실현하도록 구성되어도 된다.
ＲＯＭ(212)은, ＣＰＵ(211)가 실행하는 각종의 프로그램을 기억한다.
ＲＡＭ(213)은, ＣＰＵ(211)의 주메모리, 워크 에어리어 등의 일시 기억영역으로서 사용된다.
ＨＤＤ(214)는, 화상 데이터와 각종 프로그램을 기억한다.
조작부 인터페이스(I/F)(215)는, 조작부(219)와 제어부(210)를 서로 접속한다.
조작부(219)에는, 터치패널 기능을 가지는 액정표시부나 키보드 등이 구비되어 있다.
프린터I/F(216)는, 프린터(220)와 제어부(210)를 서로 접속한다. 제어부(210)는, 인쇄하는 화상 데이터를 프린터I/F(216)를 거쳐 프린터(220)에 송신한다.
프린터(220)는, 프린터I/F(216)를 거쳐 제어부(210)로부터 수신한 화상 데이터를 기록 매체상에 인쇄한다.
스캐너I/F(217)는, 스캐너(221)와 제어부(210)를 서로 접속한다.
스캐너(221)는, 원고상의 화상을 판독해서 화상 데이터(화상 파일)를 생성하여 스캐너I/F(217)를 거쳐 제어부(210)에 입력한다. ＭＦＰ(100)는, 스캐너(221)에서 생성된 화상 데이터(화상 파일)를 파일 송신 또는 전자메일 송신으로 송신할 수 있다.
네트워크I/F(218)는, 제어부(210)를 인터넷(130)에 접속한다.
도 3은, ＰＣ(110)의 하드웨어 구성의 일례를 도시한 블록도다.
ＣＰＵ(311)를 포함하는 제어부(310)는, ＰＣ(110) 전체의 동작을 제어한다.
ＣＰＵ(311)는, ＲＯＭ(312)이나 ＨＤＤ(314)에 기억된 프로그램을 실행함에 의해, ＰＣ(110)의 기능, 후술하는 시퀀스 도에 도시된 ＰＣ(110)의 처리 및 ＰＣ(110)에 관한 흐름도에 도시된 처리를 실현한다.
ＲＯＭ(312)은, ＣＰＵ(311)가 실행하는 각종의 프로그램을 기억한다.
ＲＡＭ(313)은, ＣＰＵ(311)의 주메모리, 워크 에어리어 등의 일시 기억영역으로서 사용된다.
ＨＤＤ(314)는, 화상 데이터와 각종 프로그램을 기억한다.
조작부I/F(315)는, 조작부(317)와 제어부(310)를 서로 접속한다.
조작부(317)에는, 터치패널 기능을 가지는 액정표시부나 키보드, 마우스 등이 구비되어 있다.
네트워크I/F(316)는, 제어부(310)를 인터넷(130)에 접속한다.
중계 서버(120)의 하드웨어 구성도, ＰＣ(110)의 하드웨어 구성과 같은 것으로 한다. 다시 말해, 중계 서버(120)의 ＣＰＵ(311)는, 중계 서버(120)의 ＲＯＭ(312)이나 ＨＤＤ(314)에 기억된 프로그램을 실행한다. 이 프로그램을 실행함으로써, 중계 서버(120)는, 중계 서버(120)의 기능, 후술하는 시퀀스 도에 도시된 중계 서버(120)의 처리 및 중계 서버(120)에 관한 흐름도에 도시된 처리를 실현한다.
도 4는, ＭＦＰ(100), ＰＣ(110) 및 중계 서버(120) 각각의 기능 구성의 일례를 도시한 블록도다.
서버측 프록시(401)는, 조작부(219)를 거쳐 접속 지시를 받으면, 중계 서비스(420)와 접속을 확립한 후, 중계 서비스(420)와 웹 서버(402)와의 사이의 통신을 중개(중계)한다.
웹 서버(402)는, 중계 서버(120)로부터 하이퍼텍스트 전송 프로토콜(ＨＴＴＰ) 통신 요구를 받으면, 그 요구에 따른 응답을 되돌리는 기능을 가진다.
클라이언트측 프록시(410)는, 웹 브라우저(411)와 중계 서비스(420)와의 사이의 통신을 중개(중계)한다.
중계 서비스(420)는, 웹 서버 기능을 제공하고, ＰＣ(110) 및 ＭＦＰ(100)로부터 ＨＴＴＰ통신 요구를 받으면 그 요구에 따른 응답을 되돌리는 기능을 가진다.
이제, 서버측 프록시(401)와 중계 서비스(420)와의 사이에서 행해지는 ＨＴＴＰ통신, 및 클라이언트측 프록시(410)와 중계 서비스(420)와의 사이에서 행해지는 ＨＴＴＰ통신에 관하여 설명한다.
ＨＴＴＰ는, ＲＦＣ(Ｒｅｑｕｅｓｔ Ｆｏｒ Ｃｏｍｍｅｎｔ)(2616)에 정의된 클라이언트/서버형의 프로토콜이며, 복수의 방법이 있다. 일반적으로, 클라이언트가 서버로부터 정보를 수신하는 경우에는 ＧＥＴ방법이 사용되고, 클라이언트에서 서버에 정보를 송신하는 경우에는 ＰＯＳＴ방법이 사용된다.
본 예시적 실시예에 있어서는, 서버측 프록시(401)가 중계 서비스(420)에 데이터 송신할 때와, 클라이언트측 프록시(410)가 중계 서비스(420)에 데이터 송신할 때에, ＰＯＳＴ방법이 사용된다. 또한, 서버측 프록시(401)가 중계 서비스(420)로부터 데이터 수신할 때와, 클라이언트측 프록시(410)가 중계 서비스(420)로부터 데이터 수신할 때에, ＧＥＴ방법이 사용된다. 또한, 송신용 접속과 수신용 접속으로서 상이한 접속이 사용된다.
도 5는, ＭＦＰ(100), ＰＣ(110) 및 중계 서버(120)가 행한 처리의 일례를 도시하는 시퀀스 도다. 본 시퀀스 도는, ＭＦＰ(100)와 ＰＣ(110)와의 ＲＵＩ접속의 일례를 도시한 도면이다.
단계S501에서, 서버측 프록시(401)는, 유저에 의해 조작부(219)를 거쳐 콜 센터가 기동되어 인증 정보가 입력되면, 입력된 인증 정보를 중계 서비스(420)에 송신한다.
단계S502에서, 중계 서비스(420)는, 서버측 프록시(401)로부터 수신한 인증 정보를 확인한다. 더 구체적으로는, 중계 서비스(420)는, 미리 기억된 인증 정보와, 서버측 프록시(401)로부터 수신한 인증 정보를 비교 함에 의해, ＭＦＰ(100)로부터의 접속을 인증할 것인가 아닌가를 판정한다.
단계S503에서, 중계 서비스(420)는, 인증 결과를 서버측 프록시(401)에 통지한다.
단계S504에서, 클라이언트측 프록시(410)는, 유저에 의해 어플리케이션이 기동되고 인증 정보가 입력되면, 인증 정보를 중계 서비스(420)에 통지한다.
단계S505에서, 중계 서비스(420)는, 클라이언트측 프록시(410)로부터 수신한 인증 정보를 확인한다. 더 구체적으로는, 중계 서비스(420)는, 미리 기억된 인증 정보와, 클라이언트측 프록시(410)로부터 수신한 인증 정보를 비교 함에 의해, ＰＣ(110)로부터의 접속을 인증할 것인가 아닌가를 판정한다.
단계S506에서, 중계 서비스(420)는, 인증 결과와, 콜 센터 통지를 발행한 ＭＦＰ일람을, 클라이언트측 프록시(410)에 송신한다.
단계S507에서, 클라이언트측 프록시(410)는, 유저에 의해 선택된 ＭＦＰ의 정보를 중계 서비스(420)에 통지한다.
단계S508에서, 서버측 프록시(401)는, 조작부(219)를 거쳐 ＲＵＩ접속 허가를 수신하면, 중계 서비스(420)에 ＲＵＩ의 접속 허가를 통지한다.
단계S509에서, 중계 서비스(420)는, ＲＵＩ요구 데이터 큐와 ＲＵＩ응답 데이터 큐를 작성한다. ＲＵＩ요구 데이터 큐에는, ＲＵＩ로 향한 요구 데이터가 격납된다. 요구 데이터는, 예를 들면 도 6ａ에 나타나 있는 바와 같은 ＲＵＩ에의 ＨＴＴＰ요구(ＨＴＴＰ데이터)다. ＲＵＩ응답 데이터 큐에는, ＲＵＩ로부터의 응답 데이터가 격납된다. 응답 데이터는, 예를 들면 도 6b에 나타나 있는 바와 같은 ＲＵＩ로부터의 ＨＴＴＰ응답(ＨＴＴＰ데이터)다.
단계S510에서, 중계 서비스(420)는, 서버측 프록시(401) 대상으로, ＲＵＩ요구 데이터 큐로부터 취득하기 위한 취득용 Uniform Resource Locator(ＵＲＬ)과, ＲＵＩ응답 데이터 큐에 격납하기 위한 격납용 ＵＲＬ을 작성한다. 중계 서비스(420)는, 서버측 프록시(401)로부터 격납용 ＵＲＬ에의 ＰＯＳＴ요구를 받으면, 대응하는 큐에 포스트된 데이터를 격납한다. 또한, 중계 서비스(420)는, 서버측 프록시(401)로부터 취득용 ＵＲＬ에의 ＧＥＴ요구를 받으면, 대응하는 큐로부터 데이터를 추출하여, ＧＥＴ요구에 대한 응답으로서, 그 추출된 데이터를 되돌린다.
단계S511에서, 중계 서비스(420)는, 격납용 ＵＲＬ과 취득용 ＵＲＬ을 서버측 프록시(401)에 통지한다.
단계S512에서, 클라이언트측 프록시(410)는, 중계 서비스(420)에 ＲＵＩ접속이 허가되어 있는지 확인한다. 이때에, 클라이언트측 프록시(410)는, 중계 서비스(420)에 폴링 등을 행하고, ＲＵＩ접속이 허가되어 있는지를 정기적으로 확인한다. 단계S513에서, 중계 서비스(420)는, 클라이언트측 프록시(410)에, ＭＦＰ(100)로부터 ＲＵＩ에의 접속 허가를 받은 것을 통지한다.
단계S514에서, 클라이언트측 프록시(410)는, ＲＵＩ접속 허가를 받으면, 중계 서비스(420)에 ＲＵＩ접속을 통지한다.
단계S515에서, 중계 서비스(420)는, 클라이언트측 프록시(410) 대상으로, ＲＵＩ요구 데이터 큐에 격납하기 위한 격납용 ＵＲＬ과, ＲＵＩ응답 데이터 큐로부터 취득하기 위한 취득용 ＵＲＬ을 작성한다. 본 예시적 실시예에서는, 중계 서비스(420)는, 데이터 큐에 격납하기 위한 격납용 ＵＲＬ과 그 데이터 큐로부터 취득하기 위한 취득용 ＵＲＬ을 작성하지만, 양쪽을 위한 공통 ＵＲＬ을 작성하여도 된다. 이 경우, 중계 서비스(420)는, ＰＯＳＴ요구 또는 ＧＥＴ요구가 수신되는 것에 따라, 데이터를 격납하거나 데이터를 취득할지를 판정한다.
단계S516에서, 중계 서비스(420)는, 격납용 ＵＲＬ과 취득용 ＵＲＬ을 클라이언트측 프록시(410)에 통지한다.
그 후, 서버측 프록시(401), 클라이언트측 프록시(410) 및 중계 서비스(420)는, 웹 서버(402)와 웹 브라우저(411)간의 데이터의 송수신을 각 ＵＲＬ을 사용해서 행한다.
단계S517에서, 웹 브라우저(411)는, 웹 서버(402)에 대한 ＨＴＴＰ요구(예를 들면, ＲＵＩ화면을 취득하는 ＧＥＴ요구와 지시를 발행하는 ＰＯＳＴ요구)를 클라이언트측 프록시(410)에 통지한다.
단계S518에서, 클라이언트측 프록시(410)는, 웹 브라우저(411)로부터의 ＨＴＴＰ요구를 받으면, 중계 서비스(420)의 ＲＵＩ요구 데이터 큐의 격납용 ＵＲＬ에 ＨＴＴＰ요구를 포스트 한다. 클라이언트측 프록시(410)가 중계 서비스(420)에 ＨＴＴＰ요구를 송신하는 처리는, 요구 송신 처리의 일례다.
단계S519에서, 서버측 프록시(401)는, 중계 서비스(420)의 ＲＵＩ요구 데이터 큐의 취득용 ＵＲＬ에 ＨＴＴＰ요구를 취득하는 ＧＥＴ요구를 송신한다. 이때, 서버측 프록시(401)는, 중계 서비스(420)에 폴링 등을 행하여 ＧＥＴ요구를 중계 서비스(420)에 정기적으로 송신한다.
단계S520에서, 중계 서비스(420)는, 서버측 프록시(401)로부터의 ＧＥＴ요구에 응답하여, ＲＵＩ요구 데이터 큐에 ＨＴＴＰ요구 데이터가 있으면, ＨＴＴＰ요구 데이터를 응답으로서 되돌린다. 서버측 프록시(401)가 중계 서비스(420)로부터 ＨＴＴＰ요구를 수신하는 처리는, 요구 수신 처리의 일례다.
단계S521에서, 서버측 프록시(401)는, 중계 서비스(420)로부터 수신한 ＨＴＴＰ요구를 웹 서버(402)에 송신한다.
단계S522에서, 웹 서버(402)는, 서버측 프록시(401)로부터 받은 ＨＴＴＰ요구에 따라 ＨＴＴＰ응답을 되돌린다.
단계S523에서, 서버측 프록시(401)는, 웹 서버(402)로부터 수신한 ＨＴＴＰ응답을 ＲＵＩ응답 데이터 큐의 격납용 ＵＲＬ에 포스트 한다. 서버측 프록시(401)가 중계 서비스(420)에 ＨＴＴＰ응답을 송신하는 처리는, 응답 송신 처리의 일례다.
단계S524에서, 클라이언트측 프록시(410)는, 중계 서비스(420)의 ＲＵＩ응답 데이터 큐의 취득용 ＵＲＬ에 대하여 ＧＥＴ요구를 송신한다. 이때에, 클라이언트측 프록시(410)는, 폴링 등을 행하여, 중계 서비스(420)에의 ＧＥＴ요구를 정기적으로 송신한다.
단계S525에서, 중계 서비스(420)는, 클라이언트측 프록시(410)로부터의 ＧＥＴ요구에 응답하여, ＲＵＩ응답 데이터 큐에 ＨＴＴＰ응답 데이터가 있으면, 그 ＨＴＴＰ응답 데이터를 응답으로서 되돌린다. 클라이언트측 프록시(410)가 중계 서비스(420)로부터 ＨＴＴＰ응답을 수신하는 처리는, 응답 수신 처리의 일례다.
단계S526에서, 클라이언트측 프록시(410)는, 중계 서비스(420)로부터 수신한 ＨＴＴＰ응답을 웹 브라우저(411)에 단계S517에서 송신된 ＨＴＴＰ요구에 대한 응답으로서 되돌린다.
웹 서버(402)와 서버측 프록시(401)와의 사이, 및 웹 브라우저(411)와 클라이언트측 프록시(410)와의 사이에서 행해진 ＨＴＴＰ통신(통신 요구와, 통신 응답)은, 제1 형식에 따른 ＨＴＴＰ통신이다. 또한, 서버측 프록시(401)와 중계 서비스(420)와의 사이, 및 클라이언트측 프록시(410)와 중계 서비스(420)와의 사이에서 행해진 ＨＴＴＰ통신(통신 요구와, 통신 응답)은, 유니폼 리소스 식별자(ＵＲＩ) 스킴에 의거한 제2 형식에 따른 ＨＴＴＰ통신이다. 다시 말해, 서버측 프록시(401)는, 제1 형식에 따른 ＨＴＴＰ통신과 제2 형식에 따른 ＨＴＴＰ통신과의 통신 형식을 상호 변환하면서 웹 서버(402) 및 중계 서비스(420)와 통신한다. 또한, 클라이언트측 프록시(410)는, 제1 형식에 따른 ＨＴＴＰ통신과 제2 형식에 따른 ＨＴＴＰ통신과의 통신 형식을 상호 변환하면서 웹 브라우저(411) 및 중계 서비스(420)와 통신한다.
이상의 처리를 행함으로써, ＰＣ(110)와 ＭＦＰ(100)는, 상이한 파이어월 110과 101의 내측에 설치되는 경우에도, 중계 서버(120)를 거쳐 서로 양방향으로 통신할 수 있다. 이와 같이, 본 예시적 실시예에 의해, 파이어월의 내측에 있는 장치가, 인터넷을 거쳐서 상이한 파이어월의 내측에 있는 장치의 웹 서비스에 접속해서 이용할 수 있다.
도 7은, ＰＣ(110)의 ＨＤＤ(314)에 기억된 식별(ＩＤ)(식별 정보)테이블의 일례를 도시한 도면이다.
정보 601은, ＨＴＴＰ응답이, ＰＣ(110)에서 포스트한 특정의 ＨＴＴＰ요구에 따른 ＨＴＴＰ응답인지를 판정하는데 사용된 ＩＤ를 나타내는 정보다. 정보 602는, ＰＣ(110)가 ＨＴＴＰ요구를 포스트한 시각을 나타내는 정보다. 정보 603은, ＰＣ(110)가 ＨＴＴＰ요구를 포스트한 유저의 이름을 나타내는 정보다. 정보 604는, ＰＣ(110)가 ＨＴＴＰ요구를 포스트한 격납용 ＵＲＬ을 나타내는 정보다.
도 7에 도시된 ＩＤ는, 후술하는 도 8 및 도 11에 도시된 처리에서 사용된다.
도 8은, 본 예시적 실시예에 따른 ＭＦＰ(100)가 행한 처리의 일례를 도시하는 흐름도다. 단계S701에서, 서버측 프록시(401)는, 조작부(219)를 거쳐 콜 센터의 기동 지시가 있었던 것인가 아닌가를 판정한다. 더 구체적으로는, 서버측 프록시(401)는, 도 9a를 참조하여 후술하는 조작 화면의 버튼(800)이 눌렸는가(선택되었는가) 아닌가를 판정한다.
도 9a는, 조작부(219)에 표시된 조작 화면의 일례를 도시한 도면이다.
도 9a에 도시된 조작 화면은, 유저가 ＭＦＰ(100)의 기능을 선택할 때에 표시된 메인 메뉴를 표시하는 화면이다. 버튼(800)은, 유저가 콜 센터(112)내의 ＰＣ(110)에 접속을 요구할 때에 누른 버튼이다. 서버측 프록시(401)는, 버튼(800)이 눌려지면 중계 서버(120)와의 접속을 시작한다.
서버측 프록시(401)가 단계S701에서 콜 센터의 기동 지시가 있었다고 판정했을 경우, 다시 말해, 버튼(800)이 눌려졌다고 판정했을 경우(단계S701에서 YES), 단계S702에서, 서버측 프록시(401)는, 후술하는 도 9b에 도시된 인증 정보 입력 화면을 표시한다.
도 9b는, 조작부(219)에 표시된 조작 화면의 일례를 도시한 도면이다.
도 9b에 도시된 조작 화면은, 유저가 중계 서버(120)에 인증을 요구할 때에 표시된 인증 정보 입력 화면이다.
입력란(input field) 810은, 중계 서버(120)에 액세스하기 위해서 필요한 인증 정보인 유저명을 입력하기 위한 입력란이다.
입력란 811은, 중계 서버(120)에 액세스하기 위해서 필요한 인증 정보인 패스워드를 입력하기 위한 입력란이다.
버튼(812)은, 입력란 810 및 입력란 811에 인증 정보를 입력한 후 유저가 로그인을 지시하기 위해서 유저에 의해 눌리는 로그인 버튼이다.
단계S703에서, 서버측 프록시(401)는, 단계S702에서 표시한 인증 정보 입력 화면에서 인증 정보가 입력되어, 버튼(812)이 눌려진 것인가 아닌가를 판정한다. 서버측 프록시(401)는, 인증 정보가 입력되고, 버튼(812)이 눌려졌다고 판정한 경우에는(단계S703에서 YES), 단계S704의 처리로 진행된다. 한편, 서버측 프록시(401)가 인증 정보가 입력되지 않고 있다고 판정했을 경우(단계S703에서 NO), 서버측 프록시(401)는, 인증 정보가 입력될 때까지 대기한다. 서버측 프록시(401)는, 소정 기간동안 인증 정보의 입력이 없으면, 도 8에 도시된 처리를 종료하도록 구성되어도 된다.
단계S704에서, 서버측 프록시(401)는, 입력된 인증 정보를 중계 서비스(420)에 송신하고, 인증 결과를 기다린다.
단계S705에서, 서버측 프록시(401)는, 중계 서비스(420)에 송신한 인증 정보에 따라 수신된 인증 결과 통지가 성공인가 실패인가를 판정한다. 단계S706에서, 서버측 프록시(401)는, 판정의 결과, 인증이 성공이면(단계S705에서 YES), ＲＵＩ접속의 허가할지 또는 불가할지를 선택하는 도 9c에 도시된 조작 화면을 표시한다. 그리고, 서버측 프록시(401)는, 도 9c에 도시된 조작 화면에서 행해진 조작을 거쳐 내려진 유저의 지시에 의거해, ＲＵＩ접속을 허가할 것인가 불가할 것인가를 판정한다. 한편, 서버측 프록시(401)는, 인증이 실패이면(단계S705에서 NO), 도 8에 도시된 처리를 종료한다.
도 9c는, 조작부(219)에 표시된 조작 화면의 일례를 도시한 도면이다.
도 9c에 도시된 조작 화면은, 유저가 콜 센터로부터의 ＲＵＩ접속을 허가할 것인가 불가할 것인가를 선택할 때에 표시된 화면이다.
버튼(820)은, 유저가 콜 센터로부터의 ＲＵＩ접속을 허가할 경우에 눌려지는 버튼이다. 서버측 프록시(401)는, 유저에 의한 버튼(820)의 눌림을 수신하면(단계S706에서 YES), 단계S707의 처리로 진행된다.
버튼(821)은, 유저가 콜 센터로부터의 ＲＵＩ접속을 불가할 경우에 눌려지는 버튼이다. 서버측 프록시(401)는, 유저에 의한 버튼(821)의 눌림을 수신하면(단계S706에서 NO), 도 8에 도시된 처리를 종료한다.
단계S707에서, 서버측 프록시(401)는, 중계 서버(120)에 ＲＵＩ접속 허가를 송신한다.
단계S708에서, 서버측 프록시(401)는, 중계 서비스(420)의 ＲＵＩ요구 데이터 큐로부터 데이터를 취득하기 위한 취득용 ＵＲＬ과, ＲＵＩ응답 데이터 큐에 데이터를 격납하기 위한 격납용 ＵＲＬ을, 중계 서버(120)로부터 수신해, ＨＤＤ(214)에 기억한다. 단계S709에서, 서버측 프록시(401)는, 취득용 ＵＲＬ로부터 ＲＵＩ요구 데이터 큐에 격납된 도 10a에 도시된 ＨＴＴＰ요구를 취득(ＧＥＴ)한다.
단계S710에서, 서버측 프록시(401)는, 단계S709에서 취득한(ＧＥＴ) 한 예를 들면 도 10b에 도시된 ＧＥＴ응답(ＨＴＴＰ요구)의 ＢＯＤＹ부로부터 ＩＤ와 ＨＴＴＰ요구를 추출하고, 그 추출된 ＩＤ를 ＨＤＤ(214)에 기억한다. 다시 말해, 서버측 프록시(401)는, ＧＥＴ응답을 변환하여, 그 ＩＤ와 ＨＴＴＰ요구를 취득한다.
단계S711에서, 서버측 프록시(401)는, 상기 추출한 ＨＴＴＰ요구를 웹 서버(402)에 송신한다.
단계S712에서, 서버측 프록시(401)는, 웹 서버(402)로부터 도 10c에 도시된 ＨＴＴＰ응답을 수신한다.
단계S713에서, 서버측 프록시(401)는, 수신한 ＨＴＴＰ응답에 ＨＤＤ(214)에 기억된 ＩＤ를 부가하여, 그 ＨＴＴＰ응답을 ＲＵＩ응답 데이터 큐에 격납하기 위해서 격납용 ＵＲＬ에 송신한다.
단계S714에서, 서버측 프록시(401)는, 조작부(219)를 거쳐 유저로부터 종료 지시를 받은 것인가 아닌가를 판정한다. 서버측 프록시(401)가 종료 지시를 받았다고 판정했을 경우(단계S714에서 YES), 단계S715에서, 서버측 프록시(401)는, 중계 서비스(420)에 절단 지시를 내린다. 그 후, 도 8에 도시된 처리를 종료한다. 한편, 서버측 프록시(401)는, 종료 지시를 받지 않았다고 판정했을 경우(단계S714에서 NO), 단계S709의 처리로 되돌아간다.
이상의 처리를 행함으로써, ＭＦＰ(100)는, 중계 서버(120)로부터 접수한 ＨＴＴＰ요구에 따라 웹 서버(402)로부터의 되돌아온 ＨＴＴＰ응답을, 상기 ＨＴＴＰ요구에 부가되어 있는 ＩＤ와 동일한 ＩＤ를 부가한 후 중계 서버(120)에 송신할 수 있다. 이에 따라 ＭＦＰ(100)와 ＰＣ(110)와의 사이에 있어서의 ＨＴＴＰ요구와 ＨＴＴＰ응답을 한 쌍으로 할 수 있어서, 그 요구와 그 응답이 서로 일치하는 상기 ＨＴＴＰ통신을 실현한다.
(도 11a와 도 11b로 이루어진) 도 11은, 본 예시적 실시예에 따른 ＰＣ(110)가 행한 처리의 일례를 도시하는 흐름도다. 단계S901에서, 클라이언트측 프록시(410)는, ＰＣ(110)의 조작부(317)(이하, 도 11에 도시된 처리에 있어서는 간단히 조작부(317)라고 한다)를 거쳐서 어플리케이션이 기동된 것인가 아닌가를 판정한다.
클라이언트측 프록시(410)가 어플리케이션이 기동되었다고 판정했을 경우(단계S901에서 YES), 단계S902에서, 클라이언트측 프록시(410)는 후술하는 도 12a에 도시된 인증 정보 입력 화면을 표시한다. 한편, 클라이언트측 프록시(410)는, 어플리케이션이 기동되지 않았다고 판정했을 경우(단계S901에서 NO), 단계S901의 처리를 반복한다.
도 12a는, 조작부(317)에 표시되는 조작 화면의 일례를 도시한 도면이다.
도 12a에 도시된 조작 화면은, 유저가 중계 서버(120)에 인증을 요구할 때에 표시된 화면이다.
입력란 830은, 중계 서버(120)에 액세스하기 위해서 필요한 인증 정보인 유저명을 입력하기 위한 입력란이다.
입력란 831은, 중계 서버(120)에 액세스하기 위해서 필요한 인증 정보인 패스워드를 입력하기 위한 입력란이다.
버튼(832)은, 입력란 830 및 입력란 831에 인증 정보를 입력한 후 유저가 로그인을 지시하기 위해서 누르는 로그인 버튼이다.
단계S903에서, 클라이언트측 프록시(410)는, 단계S902에서 표시한 인증 정보 입력 화면에서 인증 정보가 입력되어, 버튼(832)이 눌려진 것인가 아닌가를 판정한다. 클라이언트측 프록시(410)는, 인증 정보가 입력되어, 버튼(832)이 눌려졌다고 판정한 경우에는(단계S903에서 YES), 단계S904의 처리로 진행된다. 한편, 클라이언트측 프록시(410)는, 인증 정보가 입력되지 않았다고 판정했을 경우(단계S903에서 NO), 인증 정보가 입력될 때까지 대기한다. 클라이언트측 프록시(410)는, 소정 시간동안, 인증 정보의 입력이 없으면, 도 11에 도시된 처리를 종료하도록 구성하여도 된다.
단계S904에서, 클라이언트측 프록시(410)는, 중계 서비스(420)와 접속을 행하고, 입력된 인증 정보를 중계 서비스(420)에 송신하고, 인증 결과를 기다린다.
단계S905에서, 클라이언트측 프록시(410)는, 중계 서비스(420)에 송신한 인증 정보에 따라 수신된 인증 결과 통지가 성공인가 또는 실패인가를 판정한다. 클라이언트측 프록시(410)는, 판정의 결과, 인증이 성공이면(단계S905에서 YES), 단계S906에서, 클라이언트측 프록시(410)는 후술하는 도 12b에 도시된 것처럼 유저가 지원할 ＭＦＰ를 선택하기 위한 화면을 표시한다. 한편, 클라이언트측 프록시(410)는, 인증이 실패이면(단계S905에서 NO), 도 11에 도시된 처리를 종료한다.
도 12b는, 조작부(317)에 표시된 조작 화면의 일례를 도시한 도면이다.
도 12b에 도시된 조작 화면은, 지원하는 ＭＦＰ를 유저가 선택할 때에 표시된 화면이다.
정보(840)는, 도 8에 도시된 단계S706에서 중계 서버(120)와 접속을 행한 ＭＦＰ이 배치되어 있는 유저 환경의 일람이다. 도 12b는, 일례로서 정보(840)로서 하나의 유저 환경만 도시하지만, 그 정보(840)는 다른 유저 환경에 있는 ＭＦＰ가 중계 서비스(420)에 접속될 때 더욱 추가된다.
버튼(841)은, 유저가 ＰＣ(110)에 지원 시작을 지시할 때에 눌려지는 버튼이다. 클라이언트측 프록시(410)는, 유저에 의한 버튼(841)의 눌림을 수신하면, 단계S907의 처리로 진행된다.
단계S907에서, 클라이언트측 프록시(410)는, 중계 서버(120)로부터 ＲＵＩ접속 허가를 수신하고, 후술하는 도 12c에 도시된 ＲＵＩ접속 화면을 표시한다. 그리고, 단계S908에서, 클라이언트측 프록시(410)는, 도 12c에 도시된 ＲＵＩ접속 화면을 거쳐서 수신된 유저의 지시에 의거해, ＲＵＩ접속할 것인가 아닌가를 판정한다.
도 12c는, 조작부(317)에 표시된 조작 화면의 일례를 도시한 도면이다.
도 12c에 도시된 조작 화면은, ＭＦＰ(100)의 ＲＵＩ에 접속할 것인가 아닌가를 유저가 결정할 때에 표시된 화면이다.
버튼(850)은, 유저가 지원하는 ＭＦＰ(100)의 ＲＵＩ접속을 유저가 결정할 때에 눌려지는 버튼이다. 클라이언트측 프록시(410)는, 유저에 의한 버튼(850)의 눌림을 수신하면(단계S908에서 YES), 단계S909의 처리로 진행된다.
버튼(851)은, 이와는 달리 유저가 지원하는 ＭＦＰ(100)의 ＲＵＩ접속을 유저가 결정하지 않을 때에 눌려지는 버튼이다. 클라이언트측 프록시(410)는, 유저에 의한 버튼(851)의 눌림을 수신하면(단계S908에서 NO), 도 11에 도시된 처리를 종료한다.
단계S909에서, 클라이언트측 프록시(410)는, 중계 서버(120)에 ＲＵＩ접속 요구를 송신한다.
단계S910에서, 클라이언트측 프록시(410)는, 중계 서버(120)로부터 수신한 ＲＵＩ요구 데이터 큐에 격납하기 위한 격납용 ＵＲＬ과 ＲＵＩ응답 데이터 큐로부터 취득하기 위한 취득용 ＵＲＬ을, ＰＣ(110)의 ＨＤＤ(314)에 기억한다. 이하, 도 11에 도시된 처리에 있어서는, ＰＣ(110)의 ＨＤＤ(314)를 간단히 ＨＤＤ(314)라고 한다.
단계S911에서, 클라이언트측 프록시(410)는, 웹 브라우저(411)로부터 도 6a를 참조하여 전술한 ＨＴＴＰ요구를 수신한 것인가 아닌가를 판정한다. 클라이언트측 프록시(410)는, ＨＴＴＰ요구를 수신했다고 판정했을 경우(단계S911에서 YES), 단계S912의 처리로 진행된다. 클라이언트측 프록시(410)는, ＨＴＴＰ요구를 수신하지 않았다고 판정했을 경우(단계S911에서 NO), ＨＴＴＰ요구를 수신할 때까지 기다린다.
단계S912에서, 클라이언트측 프록시(410)는, 유일한 ＩＤ를 발행한다. 예를 들면, 클라이언트측 프록시(410)는, 도 7을 참조하여 전술한 ＩＤ테이블로 그 ＩＤ를 관리한다.
단계S913에서, 클라이언트측 프록시(410)는, 발행한 ＩＤ를 수신한 ＨＴＴＰ요구에 부가하여, ＲＵＩ요구 데이터 큐에 격납하기 위해서 ＨＤＤ(314)에 기억된 격납용 ＵＲＬ에 그 ＨＴＴＰ요구를 포스트한다. 이때에, 클라이언트측 프록시(410)는, 포스트 요구에 대한 응답으로서 도 13a에 도시된 응답을 취득한다.
단계S914에서, 클라이언트측 프록시(410)는, ＲＵＩ응답 데이터 큐로부터 ＨＴＴＰ응답을 수신하기 위해서, 취득용 ＵＲＬ에 도 13b에 도시된 ＧＥＴ요구를 송신한다.
단계S915에서, 클라이언트측 프록시(410)는, 단계S914에서 송신한 ＧＥＴ요구에 따라 ＨＴＴＰ응답을 수신한 것인가 아닌가를 판정한다. 클라이언트측 프록시(410)는, ＨＴＴＰ응답을 수신했다고 판정했을 경우(단계S915에서 YES), 단계S916의 처리로 진행된다. 클라이언트측 프록시(410)는, ＨＴＴＰ응답을 수신하지 않았다고 판정했을 경우(단계S915에서 NO), 단계S914의 처리로 되돌아간다.
단계S916에서, 클라이언트측 프록시(410)는, 수신한 ＧＥＴ응답의 ＢＯＤＹ부로부터 ＩＤ와 ＨＴＴＰ응답을 추출한다. 다시 말해, 클라이언트측 프록시(410)는, ＧＥＴ응답을 변환하여, 상기 ＩＤ와 상기 ＨＴＴＰ응답을 취득한다.
단계S917에서, 클라이언트측 프록시(410)는, 도 7을 참조해서 전술한 ＩＤ테이블을 참조하여, 상기 추출한 ＩＤ와, 단계S913에서 송신한 ＨＴＴＰ요구에 부가한 ＩＤ가 일치하는 것인가 아닌가를 판정한다. 클라이언트측 프록시(410)는, 이들 ＩＤ가 일치한다고 판정했을 경우(단계S917에서 YES), 단계S918의 처리로 진행된다. 한편, 클라이언트측 프록시(410)는, 이들 ＩＤ가 일치하지 않는다고 판정했을 경우(단계S917에서 NO), 단계S914의 처리로 되돌아간다. 이에 따라, 클라이언트측 프록시(410)는, 송신한 ＨＴＴＰ요구의 한 쌍이 되는 ＨＴＴＰ응답을 상기 ＩＤ에 의거하여 판정해서 취득할 수 있다.
단계S918에서, 클라이언트측 프록시(410)는, 도 13c에 나타나 있는 바와 같은 ＨＴＴＰ응답을 웹 브라우저(411)로부터의 ＨＴＴＰ요구에 대한 응답으로서 되돌린다.
단계S919에서, 클라이언트측 프록시(410)는, 조작부(317)를 거쳐 유저로부터 종료 지시를 받은 것인가 아닌가를 판정한다. 클라이언트측 프록시(410)는, 종료 지시를 받았다고 판정했을 경우(단계S919에서 YES), 단계S920에서, 클라이언트측 프록시(410)는 중계 서비스(420)에 절단 지시를 내린다. 그 후, 도 11에 도시된 처리를 종료한다. 한편, 클라이언트측 프록시(410)는, 종료 지시를 받지 않았다고 판정했을 경우(단계S919에서 NO), 단계S911의 처리로 되돌아간다.
이상의 처리를 행함으로써, ＰＣ(110)는, 송신한 ＨＴＴＰ요구에 부가한 ＩＤ와, 수신한 ＨＴＴＰ응답에 부가되어 있는 ＩＤ를 비교함으로써, ＭＦＰ(100)와 ＰＣ(110)와의 사이에 있어서의 ＨＴＴＰ요구와 ＨＴＴＰ응답을 한 쌍으로 할 수 있다. 이에 따라, ＰＣ(110)는, 상기 요구와 상기 응답이 일치하는 ＨＴＴＰ통신을 실현할 수 있다.
도 14는, 본 예시적 실시예에 따른 중계 서버(120)가 행한 처리의 일례를 도시하는 흐름도다.
단계S1001에서, 중계 서비스(420)는, 서버측 프록시(401)로부터 인증 정보를 수신한다.
단계S1002에서, 중계 서비스(420)는, 수신한 인증 정보를 확인한다.
단계S1003에서, 중계 서비스(420)는, 서버측 프록시(401)에 인증 결과를 통지한다.
단계S1004에서, 중계 서비스(420)는, 클라이언트측 프록시(410)로부터 인증 정보를 수신한다.
단계S1005에서, 중계 서비스(420)는, 수신한 인증 정보를 확인한다.
단계S1006에서, 중계 서비스(420)는, 클라이언트측 프록시(410)에 인증 결과를 통지한다.
단계S1007에서, 중계 서비스(420)는, 서버측 프록시(401)로부터 ＲＵＩ접속 허가를 나타내는 통지를 수신한다.
단계S1008에서, 중계 서비스(420)는, ＲＵＩ요구 데이터 큐와 ＲＵＩ응답 데이터 큐를 작성한다.
단계S1009에서, 중계 서비스(420)는, 서버측 프록시(401) 대상으로, ＲＵＩ요구 데이터 큐로부터 취득하기 위한 취득용 ＵＲＬ과, ＲＵＩ응답 데이터 큐에 격납하기 위한 격납용 ＵＲＬ을 작성한다.
단계S1010에서, 중계 서비스(420)는, 서버측 프록시(401)에 작성한 ＵＲＬ들을 통지한다.
단계S1011에서, 중계 서비스(420)는, 클라이언트측 프록시(410)에 ＲＵＩ접속 가능을 나타내는 통지를 통지한다.
단계S1012에서, 중계 서비스(420)는, 클라이언트측 프록시(410)로부터 ＲＵＩ접속 요구를 받는다.
단계S1013에서, 중계 서비스(420)는, 클라이언트측 프록시(410) 대상으로, ＲＵＩ요구 데이터 큐에 격납하기 위한 격납용 ＵＲＬ과, ＲＵＩ응답 데이터 큐로부터 취득하기 위한 취득용 ＵＲＬ을 작성한다.
단계S1014에서, 중계 서비스(420)는, 클라이언트측 프록시(410)에 작성한 ＵＲＬ들을 통지한다.
단계S1015에서, 중계 서비스(420)는, ＰＯSＴ요구의 수신을 기다린다.
단계S1016에서, 중계 서비스(420)는, 수신한 ＰＯSＴ요구가 클라이언트측 프록시(410)로부터 송신된 ＰＯSＴ요구인지의 여부를 판정한다. 중계 서비스(420)는, 그 수신된 ＰＯSＴ요구가 클라이언트측 프록시(410)로부터 송신된 ＰＯSＴ요구라고 판정했을 경우(단계S1016에서 YES), 단계S1017의 처리로 진행된다. 한편, 중계 서비스(420)는, 그 수신된 ＰＯSＴ요구가 클라이언트측 프록시(410)로부터 송신된 ＰＯSＴ요구가 아니라고 판정했을 경우(단계S1016에서 NO), 단계S1021의 처리로 진행된다.
단계S1017에서, 중계 서비스(420)는, 클라이언트측 프록시(410)로부터 송신된 ＨＴＴＰ요구를 ＲＵＩ요구 데이터 큐에 격납한다.
단계S1018에서, 중계 서비스(420)는, ＲＵＩ요구 데이터 큐로부터 취득하기 위한 취득용 ＵＲＬ에 서버측 프록시(401)로부터 송신된 ＧＥＴ요구를 기다린다.
단계S1019에서, 중계 서비스(420)는, ＲＵＩ요구 데이터 큐에 격납된 ＨＴＴＰ요구를 ＧＥＴ요구에 대한 응답으로서 서버측 프록시(401)에 송신한다.
단계S1020에서, 중계 서비스(420)는, ＭＦＰ(100) 또는 ＰＣ(110)로부터 절단 처리를 받은 것인가 아닌가를 판정한다. 중계 서비스(420)는, 절단 처리를 받았다고 판정했을 경우(단계S1020에서 YES), 도 14에 도시된 처리를 종료한다. 중계 서비스(420)는, 절단 처리를 받지 않았다고 판정했을 경우(단계S1020에서 NO), 단계S1016의 처리로 되돌아간다.
단계S1021에서, 중계 서비스(420)는, 서버측 프록시(401)로부터 수신한 ＨＴＴＰ응답을 ＲＵＩ응답 데이터 큐에 격납한다.
단계S1022에서, 중계 서비스(420)는, ＲＵＩ응답 데이터 큐로부터 취득하기 위한 취득용 ＵＲＬ에 클라이언트측 프록시(410)로부터 송신된 ＧＥＴ요구를 기다린다.
단계S1023에서, 중계 서비스(420)는, ＲＵＩ응답 데이터 큐에 격납된 ＨＴＴＰ응답을 ＧＥＴ요구에 대한 응답으로서 클라이언트측 프록시(410)에 송신한다. 그후, 단계S1020의 처리로 진행된다.
이상의 처리를 행함으로써, 중계 서버(120)는, ＰＣ(110)와 ＭＦＰ(100)와의 통신을 중계할 수 있다. 본 예시적 실시예에서 설명한 ＨＴＴＰ데이터는, 반드시 특정한 형식에 따른 데이터에 한정되지 않고, 그 설명된 형식과는 다른 형식에 따른 데이터이어도 된다.
상술한 것처럼, 본 예시적 실시예에 의하면, ＰＣ(110)의 클라이언트측 프록시(410)와, ＭＦＰ(100)의 서버측 프록시(401)는, ＨＴＴＰ데이터에 ＩＤ를 부가하면서 서로 통신함으로써, ＨＴＴＰ요구와 ＨＴＴＰ응답을 한 쌍으로 해서 쌍방향 통신을 한다. 이에 따라, 본 예시적 실시예는, 파이어월의 내측에 있는 장치가 인터넷을 거쳐서 다른 파이어월의 내측에 있는 장치의 웹 서비스에 접속해서 서비스를 이용할 때에, 요구와 응답을 대응시킬 수 있는 시스템을 실현할 수 있다.
상기 제1 예시적 실시예에 의하면, 클라이언트측 프록시(410) 및 서버측 프록시(401)가, ＨＴＴＰ데이터에 ＩＤ를 부가하였다. 제2 예시적 실시예에서는 중계 서비스(420)가 ＨＴＴＰ데이터에 ＩＤ를 부가하는 구성에 관하여 설명한다. 이하, 전술한 제1 예시적 실시예와 동일한 제2 예시적 실시예의 구성에 대해서는 상세히 설명하지 않겠다.
(도 15a 및 도 15b로 이루어진) 도 15는, 본 예시적 실시예에 따른 ＰＣ(110)가 행한 처리의 일례를 도시하는 흐름도다. 단계S1201로부터 단계S1210까지의 처리는, 도 11에 도시된 단계S901로부터 단계S910까지의 처리와 같기 때문에, 여기서는 그 설명을 생략한다.
단계S1211에서, 클라이언트측 프록시(410)는, 웹 브라우저(411)로부터 도 16a에 도시된 ＨＴＴＰ요구를 수신한 것인가 아닌가를 판정한다. 클라이언트측 프록시(410)는, ＨＴＴＰ요구를 수신했다고 판정했을 경우(단계S1211에서 YES), 단계S1212의 처리로 진행된다. ＨＴＴＰ요구를 수신하지 않았다고 판정했을 경우(단계S1211에서 NO), 클라이언트측 프록시(410)는, ＨＴＴＰ요구를 수신할 때까지 기다린다.
단계S1212에서, 클라이언트측 프록시(410)는, 도 16b에 나타나 있는 바와 같이 ＨＴＴＰ요구를 ＲＵＩ요구 데이터 큐에 격납하기 위해서, ＰＣ(110)의 ＨＤＤ(314)에 기억된 격납용 ＵＲＬ에 ＨＴＴＰ요구를 포스트한다.
단계S1213에서, 클라이언트측 프록시(410)는, 도 16c에 나타나 있는 바와 같이 ＲＵＩ응답 데이터 큐로부터 ＨＴＴＰ응답을 수신하기 위해서, 취득용 ＵＲＬ에 ＧＥＴ요구를 송신한다.
단계S1214에서, 클라이언트측 프록시(410)는, 단계S1213에서 송신된 ＧＥＴ요구에 대한 ＨＴＴＰ응답을 수신한 것인가 아닌가를 판정한다. 클라이언트측 프록시(410)는, 그 ＨＴＴＰ응답을 수신했다고 판정했을 경우(단계S1214에서 YES), 단계S1215의 처리로 진행된다. 클라이언트측 프록시(410)는 그 ＨＴＴＰ응답을 수신하지 않았다고 판정했을 경우(단계S1214에서 NO), 단계S1213의 처리로 되돌아간다.
단계S1215에서, 클라이언트측 프록시(410)는, 도 16d에 도시된 ＨＴＴＰ응답을 웹 브라우저(411)로부터의 ＨＴＴＰ요구에 대한 응답으로서 되돌린다.
단계S1216에서, 클라이언트측 프록시(410)는, ＰＣ(110)의 조작부(317)를 거쳐 유저로부터 종료 지시를 받은 것인가 아닌가를 판정한다. 클라이언트측 프록시(410)는, 종료 지시를 받았다고 판정했을 경우(단계S1216에서 YES), 단계S1217에서, 클라이언트측 프록시(410)는, 중계 서비스(420)에 절단 지시를 내린다. 그리고, 도 15에 도시된 처리를 종료한다. 한편, 클라이언트측 프록시(410)는, 종료 지시를 받지 않았다고 판정했을 경우(단계S1216에서 NO), 단계S1211의 처리로 되돌아간다.
도 17은, 본 예시적 실시예에 따른 중계 서버(120)가 행한 처리의 일례를 도시하는 흐름도다.
단계S1301로부터 단계S1316까지의 처리는, 도 14에 도시된 단계S1001로부터 단계S1016까지의 처리와 같기 때문에, 여기서는 그 설명을 생략한다.
단계S1317에서, 중계 서비스(420)는, 유일한 ＩＤ를 작성해 중계 서버(120)의 ＨＤＤ(314)(이하, 도 17에 도시된 처리에 있어서는 간단히 ＨＤＤ(314)라고 한다)에 기억한다. 예를 들면, 중계 서비스(420)는, 도 18에 도시된 ＩＤ테이블로 상기 ＩＤ를 관리한다.
도 18은, 중계 서버(120)의 ＨＤＤ(314)에 기억되어 있는 ＩＤ테이블의 일례를 도시한 도면이다.
정보 1401은, ＨＴＴＰ응답이 특정의 ＨＴＴＰ요구에 대한 ＨＴＴＰ응답인지의 여부를 판정하기 위한 ＩＤ를 나타내는 정보다. 정보 1402는, 지원하는 디바이스명을 나타내는 정보다. 정보 1403은, 그 디바이스를 지원하는 클라이언트명을 나타내는 정보다. 정보 1404는, 서버(서버측 프록시401)용 격납용 ＵＲＬ을 나타내는 정보다. 정보 1405는, 서버용 상기 취득용 ＵＲＬ을 나타내는 정보다. 정보 1406은, 클라이언트(클라이언트측 프록시410)용 격납용 ＵＲＬ을 나타내는 정보다. 정보 1407은, 클라이언트용 상기 취득용 ＵＲＬ을 나타내는 정보다. 정보 1408은, ＨＴＴＰ요구가 ＧＥＴ방법에 의해 취득된 시각을 나타내는 정보다.
단계S1318에서, 중계 서비스(420)는, 클라이언트측 프록시(410)로부터 포스트된 ＨＴＴＰ요구에 단계S1317에서 작성한 ＩＤ를 도 19에 도시된 것처럼 부가하고, 이 ＨＴＴＰ요구를 ＲＵＩ요구 데이터 큐에 기억한다.
단계S1319에서, 중계 서비스(420)는, ＲＵＩ요구 데이터 큐로부터 취득하기 위한 취득용 ＵＲＬ에 서버측 프록시(401)로부터 송신된 ＧＥＴ요구를 기다린다.
단계S1320에서, 중계 서비스(420)는, ＲＵＩ요구 데이터 큐에 격납된 ＨＴＴＰ요구를 상기 ＧＥＴ요구에 대한 응답으로서 서버측 프록시(401)에 송신한다.
단계S1321에서, 중계 서비스(420)는, ＭＦＰ(100) 또는 ＰＣ(110)로부터 절단 처리를 받은 것인가 아닌가를 판정한다. 중계 서비스(420)는, 절단 처리를 받았다고 판정했을 경우(단계S1321에서 YES), 도 17에 도시된 처리를 종료한다. 중계 서비스(420)는, 절단 처리를 받지 않았다고 판정했을 경우(단계S1321에서 NO), 단계S1316의 처리로 되돌아간다.
단계S1322에서, 중계 서비스(420)는, 서버측 프록시(401)로부터 수신한 ＨＴＴＰ응답 데이터로부터 ＩＤ를 취득한다.
단계S1323에서, 중계 서비스(420)는, 취득한 ＩＤ가, 도 18을 참조하여 상술한 ＨＤＤ(314)에 기억된 ＩＤ테이블의 ＩＤ와 일치하는 것인가 아닌가를 판정한다. 중계 서비스(420)는, 이들 ＩＤ가 서로 일치한다고 판정했을 경우(단계S1323에서 YES), 단계S1324의 처리로 진행된다. 중계 서비스(420)는, 이들 ＩＤ가 서로 일치하지 않는다고 판정했을 경우(단계S1323에서 NO), 단계S1321의 처리로 진행된다.
단계S1324에서, 중계 서비스(420)는, ＨＴＴＰ응답으로부터의 ＩＤ를 삭제해서 이 ＨＴＴＰ응답을 ＲＵＩ응답 데이터 큐에 격납하고, 또한, ＨＤＤ(314)에 기억된 ＩＤ테이블로부터 상기 삭제된 ＩＤ에 대응하는 데이터를 삭제한다.
단계S1325에서, 중계 서비스(420)는, ＲＵＩ응답 데이터 큐의 취득용 ＵＲＬ에 클라이언트측 프록시(410)로부터 송신된 ＧＥＴ요구를 기다린다.
단계S1326에서, 중계 서비스(420)는, 그 ＧＥＴ요구를 받으면, ＨＴＴＰ응답을 ＧＥＴ요구에 대한 응답으로서 클라이언트측 프록시(410)에 되돌린다. 그리고, 단계S1321의 처리로 진행된다.
이상의 처리를 행함으로써, 중계 서버(120)는, ＨＴＴＰ데이터에 ＩＤ를 부가해서 ＨＴＴＰ요구와 ＨＴＴＰ응답을 한 쌍으로 하면서, ＰＣ(110)와 ＭＦＰ(100)간의 통신을 중계할 수 있다. 본 예시적 실시예에서 설명한 ＨＴＴＰ데이터는, 반드시 특정한 형식에 따른 데이터에 한정되지 않고, 그 설명한 형식과는 다른 형식에 따른 데이터이어도 된다. 또한, 본 예시적 실시예에 따른 ＭＦＰ(100)에서 행한 처리는, 상기 제1 예시적 실시예와 같기 때문에, 여기서는 그에 대한 설명을 생략한다.
상술한 것처럼, 본 예시적 실시예에 의하면, ＰＣ(110)와 ＭＦＰ(100)간의 통신을 중계하는 중계 서버(120)는, ＨＴＴＰ데이터에 ＩＤ를 부가해서 관리함으로써, ＰＣ(110)와 ＭＦＰ(100)가 ＨＴＴＰ요구와 ＨＴＴＰ응답을 한 쌍으로 해서 쌍방향으로 통신할 수 있다. 이에 따라, 본 예시적 실시예는, 파이어월의 내측에 있는 장치가 인터넷을 거쳐서 다른 파이어월의 내측에 있는 장치의 웹 서비스에 접속해서 서비스를 이용할 때에, 요구와 응답을 대응시킬 수 있는 시스템을 실현할 수 있다.
상기 제1 및 제2의 예시적 실시예에 의하면, 프록시 또는 중계 서비스(420)가 ＨＴＴＰ데이터에 ＩＤ를 부가함으로써, ＨＴＴＰ응답을 웹 브라우저(411)로부터의 ＨＴＴＰ요구에 대응시킬 수 있다.
제3 예시적 실시예에서는, 도 1에 도시된 시스템에 있어서, ＨＴＴＰ응답을 ＩＤ를 사용하지 않고 ＨＴＴＰ요구에 대응시킬 수 있는 구성에 관하여 설명한다. 더 구체적으로는, 상기 제3 예시적 실시예에서는, 중계 서버(120)가, ＰＣ(110)가 ＨＴＴＰ응답을 받을 때까지 ＰＣ(110)로부터의 새로운 ＨＴＴＰ요구의 ＰＯSＴ요구를 접수하지 않는 구성에 관하여 설명한다. 이하, 제3 예시적 실시예가 상술한 제1 및 제2 예시적 실시예와 동일한 구성에 대해서는 상세히 설명하지 않겠다.
도 20은, 본 예시적 실시예에 따른 ＭＦＰ(100)가 행한 처리의 일례를 도시하는 흐름도다.
단계S1601로부터 단계S1608까지의 처리는, 도 8의 단계S701로부터 단계S708까지의 처리와 같기 때문에, 그 설명을 생략한다.
단계S1609에서, 서버측 프록시(401)는, ＲＵＩ요구 데이터 큐의 취득용 ＵＲＬ로부터 도 21a에 도시된 ＨＴＴＰ요구를 ＧＥＴ 한다.
단계S1610에서, 서버측 프록시(401)는, 도 21b에 나타나 있는 바와 같이 취득(ＧＥＴ)한 ＨＴＴＰ요구를 웹 서버(402)에 송신한다.
단계S1611에서, 서버측 프록시(401)는, 웹 서버(402)로부터 도 21c에 도시된 ＨＴＴＰ응답을 수신한다.
단계S1612에서, 서버측 프록시(401)는, 수신한 ＨＴＴＰ응답을 ＲＵＩ응답 데이터 큐에 격납하기 위해서 격납용 ＵＲＬ에 송신한다.
단계S1613 및 단계S1614의 처리는, 도 8에 도시된 단계S714 및 단계S715의 처리와 같기 때문에, 여기서는 그 설명을 생략한다.
도 22는, 본 예시적 실시예에 따른 중계 서버(120)가 행한 처리의 일례를 도시하는 흐름도다.
단계S1701로부터 단계S1716까지의 처리는, 도 14에 도시된 단계S1001로부터 단계S1016까지의 처리와 같기 때문에, 여기서는 그 설명을 생략한다.
단계S1717에서, 중계 서비스(420)는, 이미 클라이언트측 ＲＵＩ데이터 송신용 ＵＲＬ로부터 ＰＯSＴ요구를 받았는가 아닌가를 판정한다. 이때, 중계 서비스(420)는, ＰＯSＴ플래그를 확인함으로써 상기 ＰＯSＴ요구를 받았는가 아닌가를 판정한다. 더 구체적으로는, 중계 서비스(420)는, ＰＯSＴ플래그가 0으로 설정되면(단계S1717에서 YES), 상기 ＰＯSＴ요구를 받지 않았다고 판정한다. 그 후, 단계S1718의 처리로 진행된다. 한편, 중계 서비스(420)는, ＰＯSＴ플래그가 1로 설정되면(단계S1717에서 NO), 상기 ＰＯSＴ요구를 받았다고 판정한다. 그 후, 단계S1715의 처리로 되돌아간다.
단계S1718에서, 중계 서비스(420)는, ＰＯSＴ요구를 받은 것을 나타내도록 ＰＯSＴ플래그를 변경한다(ＰＯSＴ플래그=1).
단계S1719에서, 중계 서비스(420)는, 클라이언트측 프록시(410)로부터 수신한 ＨＴＴＰ요구를 ＲＵＩ요구 데이터 큐에 격납한다.
단계S1720에서, 중계 서비스(420)는, ＲＵＩ요구 데이터 큐의 취득용 ＵＲＬ에 서버측 프록시(401)로부터 송신된 ＧＥＴ요구를 기다린다.
단계S1721에서, 중계 서비스(420)는, ＲＵＩ요구 데이터 큐에 격납된 ＨＴＴＰ요구를 상기 ＧＥＴ요구에 대한 응답으로서 서버측 프록시(401)에 송신한다.
단계S1722에서, 중계 서비스(420)는, ＭＦＰ(100) 또는 ＰＣ(110)로부터 절단 처리를 받은 것인가 아닌가를 판정한다. 중계 서비스(420)는, 절단 처리를 받았다고 판정했을 경우(단계S1722에서 YES), 도 22에 도시된 처리를 종료한다. 중계 서비스(420)는 절단 처리를 받지 않았다고 판정했을 경우(단계S1722에서 NO), 단계S1716의 처리로 되돌아간다.
단계S1723에서, 중계 서비스(420)는, ＨＴＴＰ응답을 ＲＵＩ응답 데이터 큐에 격납한다.
단계S1724에서, 중계 서비스(420)는, ＲＵＩ응답 데이터 큐의 취득용 ＵＲＬ에 클라이언트측 프록시(410)로부터 송신된 ＧＥＴ요구를 기다린다.
단계S1725에서, 중계 서비스(420)는, 송신 요구를 받지 않은 것을 나타내도록 ＰＯSＴ플래그를 변경한다(ＰＯSＴ플래그=0).
단계S1726에서, 중계 서비스(420)는, 클라이언트측 프록시(410)로부터 요구를 받으면, ＨＴＴＰ응답을 상기 ＧＥＴ요구에 대한 응답으로서 되돌린다. 그 후, 단계S1722의 처리로 진행된다.
이상의 처리를 행함으로써, 중계 서버(120)는, ＰＣ(110)가 ＨＴＴＰ응답을 받을 때까지 ＰＣ(110)로부터의 새로운 ＨＴＴＰ요구의 ＰＯSＴ요구를 접수하지 않음으로써, ＨＴＴＰ요구와 ＨＴＴＰ응답을 한 쌍으로 해서, ＰＣ(110)와 ＭＦＰ(100)간의 통신을 중계하는 것에 성공한다. 본 예시적 실시예에서 설명한 ＨＴＴＰ데이터는, 반드시 특정한 형식에 따른 데이터에 한정되지 않고, 그 설명한 형식과는 다른 형식에 따른 데이터이어도 된다. 또한, 본 예시적 실시예에 따른 ＰＣ(110)가 행한 처리는, 제2 예시적 실시예와 같기 때문에, 여기서는 그에 대한 설명을 생략한다.
상술한 것처럼, 본 예시적 실시예에 의하면, ＰＣ(110)가 ＨＴＴＰ응답을 받을 때까지, 중계 서버(120)가 ＰＣ(110)로부터의 새로운 ＨＴＴＰ요구의 ＰＯSＴ요구를 접수하지 않도록 구성됨으로써, ＨＴＴＰ요구와 ＨＴＴＰ응답을 서로 대응시킬 수 있다. 이에 따라 ＰＣ(110)와 ＭＦＰ(100)가 ＨＴＴＰ요구와 ＨＴＴＰ응답을 한 쌍으로 해서 쌍방향으로 통신할 수 있다. 이에 따라, 본 예시적 실시예에서는, 파이어월의 내측에 있는 장치가 인터넷을 거쳐서 다른 파이어월의 내측에 있는 장치의 웹 서비스에 접속해서 서비스를 이용할 때에, 요구와 응답을 대응시킬 수 있는 시스템을 실현할 수 있다.
제4 예시적 실시예에서는, 도 1에 도시된 시스템에 있어서, ＵＲＬ(어드레스 정보)을 사용하여 웹 브라우저(411)로부터의 ＨＴＴＰ요구와, 그 ＨＴＴＰ요구에 대한 ＨＴＴＰ응답을 대응시키는 구성에 관하여 설명한다. 더 구체적으로는, 중계 서버(120)는, ＰＣ(110)로부터 송신된 ＨＴＴＰ요구의 ＰＯSＴ요구에 대한 응답으로서 ＨＴＴＰ응답을 취득(ＧＥＴ)하기 위한 ＵＲＬ을 상기 ＰＣ(110)에 통지한다. 또한, 중계 서버(120)는, ＭＦＰ(100)로부터 송신된 ＨＴＴＰ요구의 ＧＥＴ요구에 대한 응답으로서 ＨＴＴＰ응답을 포스트하기 위한 ＵＲＬ을 상기 ＭＦＰ(100)에 통지한다. 이하, 제4 예시적 실시예가 상술한 제1 내지 제3의 예시적 실시예와 동일한 구성에 대해서는 상세히 설명하지 않겠다.
도 23은, 본 예시적 실시예에 따른 ＭＦＰ(100)가 행한 처리의 일례를 도시하는 흐름도다.
단계S1901로부터 단계S1907까지의 처리는, 도 8에 도시된 단계S701로부터 단계S707까지의 처리와 같기 때문에, 여기서는 그에 대한 설명을 생략한다.
단계S1908에서, 서버측 프록시(401)는, 중계 서버(120)로부터 수신한 ＲＵＩ요구 데이터 큐에의 그 취득용 ＵＲＬ을 ＨＤＤ(214)에 기억한다.
단계S1909에서, 서버측 프록시(401)는, ＲＵＩ요구 데이터 큐의 ＨＴＴＰ요구를 취득용 ＵＲＬ로부터 취득(ＧＥＴ) 한다.
단계S1910에서, 서버측 프록시(401)는, 전술한 도 10b에 도시된 ＧＥＴ응답을 변환해서 ＵＲＬ과 ＨＴＴＰ요구를 취득하고, 그 취득한 ＵＲＬ을 ＨＤＤ(214)에 기억한다.
단계S1911에서, 서버측 프록시(401)는, 취득한 ＨＴＴＰ요구를 웹 서버(402)에 송신한다.
단계S1912에서, 서버측 프록시(401)는, 웹 서버(402)에 송신한 ＨＴＴＰ요구에 따라 웹 서버(402)로부터 되돌려진 ＨＴＴＰ응답을, ＨＤＤ(214)에 기억된 ＵＲＬ에 포스트한다.
단계S1913에서, 서버측 프록시(401)는, ＨＤＤ(214)에 기억된 ＵＲＬ을 삭제한다.
단계S1914 및 단계S1915의 처리는, 도 8에 도시된 단계S714 및 단계S715의 처리와 같기 때문에, 여기서는 그에 대한 설명을 생략한다.
이상의 처리를 행함으로써, ＭＦＰ(100)는, ＧＥＴ응답으로부터 취득한 ＵＲＬ을 사용하여, 웹 서버(402)로부터 되돌려진 ＨＴＴＰ응답을 포스트할 수 있다. 이에 따라 ＭＦＰ(100)와 ＰＣ(110)와의 사이에 있어서의 ＨＴＴＰ요구와 ＨＴＴＰ응답을 한 쌍으로 할 수 있어서, 그 요구와 그 응답이 서로 일치하는 ＨＴＴＰ통신을 실현할 수 있다.
도 24는, 본 예시적 실시예에 따른 ＰＣ(110)가 행한 처리의 일례를 도시하는 흐름도다. 단계S2001로부터 단계S2009까지의 처리는, 도 11에 도시된 단계S901로부터 단계S909까지의 처리와 같기 때문에, 여기서는 그에 대한 설명을 생략한다.
단계S2010에서, 클라이언트측 프록시(410)는, 중계 서버(120)로부터 수신한 ＲＵＩ요구 데이터 큐에 격납하기 위한 격납용 ＵＲＬ을 ＰＣ(110)의 ＨＤＤ(314)(이하, 도 24에 도시된 처리에 있어서는 간단히 ＨＤＤ(314)라고 한다)에 기억한다.
단계S2011에서, 클라이언트측 프록시(410)는, 웹 브라우저(411)로부터 도 25a에 도시된 ＨＴＴＰ요구를 수신한 것인가 아닌가를 판정한다. 클라이언트측 프록시(410)는, ＨＴＴＰ요구를 수신했다고 판정했을 경우(단계S2011에서 YES), 단계S2012의 처리로 진행된다. 클라이언트측 프록시(410)는, ＨＴＴＰ요구를 수신하지 않았다고 판정했을 경우(단계S2011에서 NO), ＨＴＴＰ요구를 수신할 때까지 기다린다.
단계S2012에서, 클라이언트측 프록시(410)는, 웹 브라우저(411)로부터 수신한 ＨＴＴＰ요구를 ＲＵＩ요구 데이터 큐에 격납하기 위해서, 도 25b에 나타나 있는 바와 같이 ＨＤＤ(314)에 기억된 격납용 ＵＲＬ에 포스트한다.
단계S2013에서, 클라이언트측 프록시(410)는, 격납용 ＵＲＬ에 송신된 ＰＯSＴ요구에 대한 응답으로서 중계 서버(120)로부터 수신한 도 25c에 도시된 응답내의 ＵＲＬ을 ＨＤＤ(314)에 기억한다.
단계S2014에서, 클라이언트측 프록시(410)는, 도 25d에 나타나 있는 바와 같이 ＲＵＩ응답 데이터 큐로부터 데이터를 수신하기 위해서, ＨＤＤ(314)에 기억된 ＵＲＬ에 대한 ＨＴＴＰ응답을 취득하기 위한 ＧＥＴ요구를 송신한다.
단계S2015에서, 클라이언트측 프록시(410)는, 단계S2014에서 송신된 ＧＥＴ요구에 따라 ＨＴＴＰ응답을 수신한 것인가 아닌가를 판정한다. 클라이언트측 프록시(410)는, ＨＴＴＰ응답을 수신했다고 판정했을 경우(단계S2015에서 YES), 단계S2016의 처리로 진행된다. 클라이언트측 프록시(410)는, ＨＴＴＰ응답을 수신하지 않았다고 판정했을 경우(단계S2015에서 NO), 단계S2014의 처리로 되돌아간다.
단계S2016에서, 클라이언트측 프록시(410)는, 웹 브라우저(411)로부터의 ＨＴＴＰ요구에 대한 응답으로서, 도 25e에 도시된 ＨＴＴＰ응답을 되돌린다.
단계S2017에서, 클라이언트측 프록시(410)는, ＨＤＤ(314)에 기억된 ＵＲＬ을 삭제한다.
단계S2018 및 단계S2019의 처리는, 도 11에 도시된 단계S919 및 단계S920의 처리와 같기 때문에, 여기서는 그에 대한 설명을 생략한다.
이상의 처리를 행함으로써, ＰＣ(110)는, ＨＴＴＰ요구의 ＰＯSＴ요구에 대한 응답으로서 중계 서버(120)로부터 통지된 ＵＲＬ에 의거하여 ＨＴＴＰ응답을 취득(ＧＥＴ)할 수 있다. 이에 따라 ＭＦＰ(100)와 ＰＣ(110)와의 사이에 있어서의 ＨＴＴＰ요구와 ＨＴＴＰ응답을 한 쌍으로 할 수 있어서, 그 요구와 그 응답이 서로 일치하는 ＨＴＴＰ통신을 실현할 수 있다.
도 26은, 본 예시적 실시예에 따른 중계 서버(120)가 행한 처리의 일례를 도시하는 흐름도다.
단계S2101에서, 중계 서비스(420)는, 서버측 프록시(401)로부터 인증 정보를 수신한다.
단계S2102에서, 중계 서비스(420)는, 수신한 인증 정보를 확인한다.
단계S2103에서, 중계 서비스(420)는, 서버측 프록시(401)에 인증 결과를 통지한다.
단계S2104에서, 중계 서비스(420)는, 클라이언트측 프록시(410)로부터 인증 정보를 수신한다.
단계S2105에서, 중계 서비스(420)는, 수신한 인증 정보를 확인한다.
단계S2106에서, 중계 서비스(420)는, 클라이언트측 프록시(410)에 인증 결과를 통지한다.
단계S2107에서, 중계 서비스(420)는, 서버측 프록시(401)로부터 ＲＵＩ접속 허가를 나타내는 통지를 수신한다.
단계S2108에서, 중계 서비스(420)는, ＲＵＩ요구 데이터 큐와 ＲＵＩ응답 데이터 큐를 작성한다.
단계S2109에서, 중계 서비스(420)는, 서버측 프록시(401) 대상으로, ＲＵＩ요구 데이터 큐로부터 취득하기 위한 취득용 ＵＲＬ을 작성한다.
단계S2110에서, 중계 서비스(420)는, 서버측 프록시(401)에 상기 작성한 ＵＲＬ을 통지한다.
단계S2111에서, 중계 서비스(420)는, 클라이언트측 프록시(410)에, ＲＵＩ접속이 가능한 것을 나타내는 통지를 통지한다.
단계S2112에서, 중계 서비스(420)는, 클라이언트측 프록시(410)로부터 ＲＵＩ접속 요구를 받는다.
단계S2113에서, 중계 서비스(420)는, 클라이언트측 프록시(410) 대상으로, ＲＵＩ요구 데이터 큐에 격납하기 위한 격납용 ＵＲＬ을 작성한다.
단계S2114에서, 중계 서비스(420)는, 클라이언트측 프록시(410)에 상기 작성한 ＵＲＬ을 통지한다.
단계S2115에서, 중계 서비스(420)는, ＰＯSＴ요구의 수신을 기다린다.
단계S2116에서, 중계 서비스(420)는, 그 수신한 ＰＯSＴ요구가 클라이언트측 프록시(410)로부터 송신된 ＰＯSＴ요구인지의 여부를 판정한다. 중계 서비스(420)는, 그 수신한 ＰＯSＴ요구가 클라이언트측 프록시(410)로부터 송신된 ＰＯSＴ요구라고 판정했을 경우(단계S2116에서 YES), 단계S2117의 처리로 진행된다. 그 수신한 ＰＯSＴ요구가 클라이언트측 프록시(410)로부터 송신된 ＰＯSＴ요구가 아니라고 판정했을 경우(단계S2116에서 NO), 단계S2124의 처리로 진행된다.
단계S2117에서, 중계 서비스(420)는, ＲＵＩ응답 데이터 큐로부터 취득하기 위한 클라이언트측 프록시(410)용의 취득용 ＵＲＬ을 작성한다.
단계S2118에서, 중계 서비스(420)는, 작성한 ＵＲＬ을 클라이언트측 프록시(410)에의 ＰＯSＴ응답에 부가해서, 이 ＰＯSＴ응답을 송신한다.
단계S2119에서, 중계 서비스(420)는, ＲＵＩ응답 데이터 큐에 송신하기 위한 서버측 프록시(401)용의 격납용 ＵＲＬ을 작성한다.
단계S2120에서, 중계 서비스(420)는, 작성한 격납용 ＵＲＬ을 ＨＴＴＰ요구에 부가해서 ＲＵＩ요구 데이터 큐에 격납한다.
단계S2121에서, 중계 서비스(420)는, 서버측 프록시(401)로부터 상기 ＲＵＩ요구 데이터 큐의 취득용 ＵＲＬ에 송신된 ＧＥＴ요구를 기다린다.
단계S2122에서, 중계 서비스(420)는, ＲＵＩ요구 데이터 큐에 격납된 ＨＴＴＰ요구를 상기 ＧＥＴ요구에 대한 응답으로서 송신한다.
단계S2123에서, 중계 서비스(420)는, ＭＦＰ(100) 또는 ＰＣ(110)로부터 절단 처리를 받은 것인가 아닌가를 판정한다. 중계 서비스(420)는, 절단 처리를 받았다고 판정했을 경우(단계S2123에서 YES), 도 26에 도시된 처리를 종료한다. 중계 서비스(420)는 절단 처리를 받지 않았다고 판정했을 경우(단계S2123에서 NO), 단계S2116의 처리로 되돌아간다.
단계S2124에서, 중계 서비스(420)는, 서버측 프록시(401)로부터 수신한 ＨＴＴＰ응답을 ＲＵＩ응답 데이터 큐에 격납한다.
단계S2125에서, 중계 서비스(420)는, ＲＵＩ응답 데이터 큐로부터 취득하기 위한 취득용 ＵＲＬ에 클라이언트측 프록시(410)로부터 송신된 ＧＥＴ요구를 기다린다.
단계S2126에서, 중계 서비스(420)는, ＲＵＩ응답 데이터 큐에 격납된 ＨＴＴＰ응답을 상기 ＧＥＴ요구에 대한 응답으로서 클라이언트측 프록시(410)에 송신한다. 그 후, 단계S2123의 처리로 진행된다.
이상의 처리를 행함으로써, 중계 서버(120)는, 그 ＵＲＬ들을 사용하여 상기 ＨＴＴＰ요구와 ＨＴＴＰ응답을 서로 대응시킬 수 있다. 본 예시적 실시예에서 설명한 ＨＴＴＰ데이터는, 반드시 특정한 형식에 따른 데이터에 한정되지 않고, 그 설명한 형식과는 다른 형식에 따른 데이터이어도 된다.
상술한 것처럼, 본 예시적 실시예에 의하면, ＵＲＬ을 사용하여 웹 브라우저(411)로부터의 ＨＴＴＰ요구와, 그 요구에 대한 ＨＴＴＰ응답을 한 쌍으로 할 수 있다. 이에 따라, 본 예시적 실시예에서는, 파이어월의 내측에 있는 장치가 인터넷을 거쳐서 다른 파이어월의 내측에 있는 장치의 웹 서비스에 접속해서 서비스를 이용할 때에, 요구와 응답을 대응시킬 수 있는 시스템을 실현할 수 있다.
제5 예시적 실시예는, ＭＦＰ(100)와 ＰＣ 110과의 사이의 ＲＵＩ통신 내용을, 후술하는 도 27의 시스템 구성도에 도시된 별도의 ＰＣ인 ＰＣ103으로부터 열람 가능하도록 구성된다. 일반적으로, 서비스 엔지니어가 유저의 화상형성장치의 보수를 행할 경우, 그 작업 상황을 고객측에서도 확인할 수 없으면 안된다. 예를 들면, 화상형성장치의 보수시에, 서비스 엔지니어가 화상형성장치를 복구하기 위한 설정 값을 변경할 경우, 이 보수는 화상형성장치의 정보를 ＰＣ에 백업하는 작업을 자주 수반한다. 이 경우, 서비스 엔지니어가 어느 설정 값을 백업하고 있는지를, 유저측이 확인할 수 있어야 한다.
본 예시적 실시예에서는, ＭＦＰ(100)와 ＰＣ110과의 사이에 있어서의 ＲＵＩ통신의 내용을, 유저측의 ＰＣ103으로부터 열람 가능하게 하는 구성에 관하여 설명한다. 이하에서는, 제5 예시적 실시예가 상술한 제1 내지 제4 예시적 실시예와 동일한 구성에 대해서는 상세히 설명하지 않겠다.
도 27은, 본 예시적 실시예에 따른 네트워크를 거쳐 안전한 원격보수 서비스를 제공하는 통신시스템의 시스템 구성의 일례를 도시한 도면이다.
ＰＣ(103)가 유저 환경(102)내에 배치되어, 인터넷(130)에 액세스가능하다. 그 밖의 구성요소는 도 1에 도시된 상술한 구성요소와 같기 때문에, 여기서는 그에 대한 설명을 생략한다.
또한, ＰＣ(103)의 하드웨어 구성은 상술한 도 3과 같다. 다시 말해, ＰＣ(103)의 ＣＰＵ(311)는, ＰＣ(103)의 ＲＯＭ(312)이나 ＨＤＤ(314)에 기억된 프로그램을 실행하여서, ＰＣ(103)의 기능, 및 후술하는 ＰＣ(103)에 관한 흐름도에 도시된 처리를 실현한다. 여기에서는 그 밖의 부들에 관해서 설명을 생략한다.
도 28은, 본 예시적 실시예에 따른 ＭＦＰ(100), ＰＣ(103), ＰＣ(110) 및 중계 서버(120) 각각의 기능 구성의 일례를 도시한 도면이다.
ＭＦＰ(100), ＰＣ(110) 및 중계 서버(120)의 기능 구성은 도 4와 같기 때문에, 여기서는 그에 대한 설명을 생략한다.
ＰＣ(103)내의 클라이언트측 프록시(430)는, 웹 브라우저(431)와 중계 서비스(420)와의 사이의 통신을 중개(중계)한다. 클라이언트측 프록시(430)는, 중계 서비스(420)에의 데이터 송신을 위해, ＰＯSＴ방법을 사용한다. 또한, 클라이언트측 프록시(430)는, 중계 서버(120)로부터의 데이터 수신을 위해 ＧＥＴ방법을 사용한다. 또한, 클라이언트측 프록시(430)는, 송신용 접속과 수신용 접속으로서 서로 다른 접속을 사용하는 것으로 한다.
도 29는, 본 예시적 실시예에 따른 ＰＣ(103)가 행한 처리의 일례를 도시하는 흐름도다. 단계S2501로부터 단계S2506까지의 처리는, 도 11에 도시된 단계S901로부터 단계S906까지의 처리와 같기 때문에, 여기서는 그에 대한 설명을 생략한다. 본 예시적 실시예에서는, 단계S2506에서 선택된 지원처인 ＭＦＰ(100)는 이미 ＰＣ(110)와 통신중인 것으로 한다.
단계S2507에서, 클라이언트측 프록시(430)는, 중계 서버(120)로부터 ＲＵＩ접속 허가를 수신한다. 단계S2507에서 클라이언트측 프록시(430)가 수신한 ＲＵＩ접속 허가 정보에는, 이미 ＲＵＩ접속이 ＭＦＰ(100)와 ＰＣ(110) 사이에서 확립된 것을 나타내는 정보가 포함된다.
단계S2508에서, 클라이언트측 프록시(430)는, ＲＵＩ열람을 실행할 것인가 아닌가를 판정한다. 더 구체적으로는, 클라이언트측 프록시(430)는, 유저에게 ＲＵＩ열람을 실행할 것인가 아닌가의 선택을 재촉시키는 화면을 ＰＣ(103)의 조작부(317)(이하, 도 29에 도시된 처리에서는 간단히 조작부(317)라고 한다)에 표시한다. 그리고, 클라이언트측 프록시(430)는, 조작부(317)를 거쳐 유저에 의한 열람 실행의 선택을 접수하면(단계S2508에서 YES), 단계S2509의 처리로 진행된다. 한편, 클라이언트측 프록시(430)는, 조작부(317)를 거쳐 유저에 의한 열람 실행의 선택을 접수하지 않았을 경우, 다시 말해, 유저가 열람 실행을 선택하지 않고 종료를 요구하는 경우에는(단계S2508에서 NO), 단계S2518의 처리로 진행된다.
단계S2509에서, 클라이언트측 프록시(430)는, 중계 서버(120)에 ＲＵＩ열람을 송신한다.
단계S2510에서, 클라이언트측 프록시(430)는, 중계 서버(120)로부터 수신한 ＲＵＩ요구 데이터 큐에 격납하기 위한 격납용 ＵＲＬ과, ＲＵＩ응답 데이터 큐로부터 취득하기 위한 취득용 ＵＲＬ을, ＰＣ(103)의 ＨＤＤ(314)(이하, 도 29에 도시된 처리에 있어서는 간단히 ＨＤＤ(314)라고 한다)에 기억한다.
단계S2511에서, 클라이언트측 프록시(430)는, 웹 브라우저(431)로부터 ＨＴＴＰ요구를 수신한 것인가 아닌가를 판정한다. 클라이언트측 프록시(430)는, ＨＴＴＰ요구를 수신했다고 판정했을 경우(단계S2511에서 YES), 단계S2512의 처리로 진행된다. 클라이언트측 프록시(430)는, ＨＴＴＰ요구를 수신하지 않았다고 판정했을 경우(단계S2511에서 NO), ＨＴＴＰ요구의 수신을 기다린다.
단계S2512에서, 클라이언트측 프록시(430)는, 웹 브라우저(431)로부터 수신한 ＨＴＴＰ요구를, ＨＤＤ(314)에 기억된 격납용 ＵＲＬ에 포스트한다. 본 예시적 실시예에서는, 단계S2512에서 클라이언트측 프록시(430)가 포스트한 ＨＴＴＰ요구는, 중계 서버(120)에서 읽고나서 삭제된다. 또한, 본 예시적 실시예에서는, 웹 브라우저(431)로부터 송신된 ＨＴＴＰ요구를 클라이언트측 프록시(430)가 중계 서버(120)에 포스트하고 있지만, 그 통신시스템은 클라이언트측 프록시(430)가 그것을 읽고나서 삭제하도록 구성되어도 된다.
단계S2513에서, 클라이언트측 프록시(430)는, ＲＵＩ응답 데이터 큐로부터 ＨＴＴＰ응답을 수신하기 위해서 취득용 ＵＲＬ에 ＧＥＴ요구를 송신한다.
단계S2514에서, 클라이언트측 프록시(430)는, 단계S2513에서 송신된 ＧＥＴ요구에 따라 중계 서버(120)로부터 ＨＴＴＰ응답을 수신한 것인가 아닌가를 판정한다. 클라이언트측 프록시(430)는, ＨＴＴＰ응답을 수신했다고 판정했을 경우(단계S2514에서 YES), 단계S2515의 처리로 진행된다. 클라이언트측 프록시(430)는, ＨＴＴＰ응답을 수신하지 않았다고 판정했을 경우(단계S2514에서 NO), 단계S2513의 처리로 되돌아간다.
단계S2515에서, 클라이언트측 프록시(430)는, 중계 서버(120)로부터 수신한 ＧＥＴ응답(ＨＴＴＰ응답)으로부터 ＩＤ부분을 추출한다. 더 구체적으로는, 클라이언트측 프록시(430)는, ＧＥＴ응답을 변환하여, ＩＤ와 ＨＴＴＰ응답을 취득한다.
단계S2516에서, 클라이언트측 프록시(430)는, ＩＤ부분을 제거한 ＨＴＴＰ응답을, 웹 브라우저(431)로부터의 ＨＴＴＰ요구에 대한 응답으로서 되돌린다.
단계S2517에서, 클라이언트측 프록시(430)는, 조작부(317)를 거쳐 유저로부터 종료 지시를 받은 것인가 아닌가를 판정한다. 클라이언트측 프록시(430)가 종료 지시를 받았다고 판정했을 경우(단계S2517에서 YES), 단계S2518에서, 클라이언트측 프록시(430)는 중계 서비스(420)에 절단 지시를 내린다. 그리고, 도 29에 도시된 처리를 종료한다. 한편, 클라이언트측 프록시(430)는, 종료 지시를 받지 않았다고 판정했을 경우(단계S2517에서 NO), 단계S2511의 처리로 되돌아간다.
이상의 처리의 실행에 의해, ＭＦＰ(100)와 ＰＣ(110)와의 사이에 있어서의 ＲＵＩ통신의 통신 내용을, 유저측의 ＰＣ(103)로부터 열람할 수 있다.
(도 30a 및 도 30b로 이루어진) 도 30은, 본 예시적 실시예에 따른 중계 서버(120)가 행한 처리의 일례를 도시하는 흐름도다.
단계S2601로부터 단계S2619까지의 처리는, 도 14에 도시된 단계S1001로부터 단계S1019까지의 처리와 같기 때문에, 여기서는 그에 대한 설명을 생략한다. 또한, 단계S2621로부터 단계S2623까지의 처리는, 도 14에 도시된 단계S1021로부터 단계S1023까지의 처리와 같기 때문에, 여기서는 그에 대한 설명을 생략한다. 도 30에 있어서, 제1클라이언트측 프록시는, ＰＣ(110)내의 클라이언트측 프록시(410)를 나타낸다. 또한, 제2클라이언트측 프록시는, ＰＣ(103)내 클라이언트측 프록시(430)를 나타낸다.
단계S2620에서, 중계 서비스(420)는, 클라이언트측 프록시(430)로부터 인증 정보를 수신한 것인가 아닌가를 판정한다. 중계 서비스(420)는, 인증 정보를 수신했다고 판정했을 경우(단계S2620에서 YES), 단계S2624의 처리로 진행된다. 중계 서비스(420)는, 인증 정보를 수신하지 않았다고 판정했을 경우(단계S2620에서 NO), 단계S2615의 처리로 되돌아간다.
단계S2624에서, 중계 서비스(420)는, 클라이언트측 프록시(430)로부터 수신한 인증 정보를 확인한다. 더 구체적으로는, 중계 서비스(420)는, 미리 기억된 인증 정보와, 클라이언트측 프록시(430)로부터 수신한 인증 정보를 비교하여서, ＰＣ(103)로부터의 접속을 인증할 것인가 아닌가를 판정한다.
단계S2625에서, 중계 서비스(420)는, 클라이언트측 프록시(430)에 인증 결과를 통지한다.
단계S2626에서, 중계 서비스(420)는, 클라이언트측 프록시(430)에 ＲＵＩ접속이 가능한 것을 통지한다.
단계S2627에서, 중계 서비스(420)는, 클라이언트측 프록시(430)로부터 ＲＵＩ열람 요구를 수신한다. 그 ＲＵＩ열람 요구는, 통신 내용의 취득 요구의 일례다.
단계S2628에서, 중계 서비스(420)는, 클라이언트측 프록시(430)에 송수신용 ＵＲＬ을 통지한다. 이때, 중계 서비스(420)는, 단계S2613에서 작성한 ＵＲＬ들과 같은 ＵＲＬ들을 클라이언트측 프록시(430)에 통지한다. 더 구체적으로는, 중계 서비스(420)는, ＲＵＩ요구 데이터 큐에 격납하기 위한 격납용 ＵＲＬ과, ＲＵＩ응답 데이터 큐로부터 취득하기 위한 취득용 ＵＲＬ을 클라이언트측 프록시(430)에 통지한다. 이것들의 ＵＲＬ은, ＭＦＰ(100)와 ＰＣ(110)가 ＲＵＩ통신하기 위해서도 사용된다.
단계S2629에서, 중계 서비스(420)는, ＰＯSＴ요구의 수신을 기다린다.
단계S2630에서, 중계 서비스(420)는, 수신된 ＰＯSＴ요구가 클라이언트측 프록시(410)로부터 송신된 ＰＯSＴ요구인지의 여부를 판정한다. 중계 서비스(420)는, 수신된 ＰＯSＴ요구가 클라이언트측 프록시(410)로부터 송신된 ＰＯSＴ요구라고 판정했을 경우(단계S2630에서 YES), 단계S2631의 처리로 진행된다. 한편, 중계 서비스(420)는, 수신된 ＰＯSＴ요구가 클라이언트측 프록시(410)로부터 송신된 ＰＯSＴ요구가 아니라고 판정했을 경우(단계S2630에서 NO), 단계S2634의 처리로 진행된다.
단계S2631에서, 중계 서비스(420)는, ＨＴＴＰ요구를 ＲＵＩ요구 데이터 큐에 격납한다.
단계S2632에서, 중계 서비스(420)는, ＲＵＩ요구 데이터 큐로부터 취득하기 위한 취득용 ＵＲＬ에 서버측 프록시(401)로부터 송신된 ＧＥＴ요구를 기다린다.
단계S2633에서, 중계 서비스(420)는, ＲＵＩ요구 데이터 큐에 격납된 ＨＴＴＰ요구를 ＧＥＴ요구에 대한 응답으로서 서버측 프록시(401)에 송신한다.
단계S2642에서, 중계 서비스(420)는, ＭＦＰ(100), ＰＣ(110) 또는 ＰＣ(103)로부터 절단 처리를 받은 것인가 아닌가를 판정한다. 중계 서비스(420)는, 절단 처리를 받았다고 판정했을 경우(단계S2642에서 YES), 도 30의 처리를 종료한다. 중계 서비스(420)는, 절단 처리를 받지 않았다고 판정했을 경우(단계S2642에서 NO), 단계S2629의 처리로 되돌아간다.
단계S2634에서, 중계 서비스(420)는, 단계S2629에서 수신된 ＰＯSＴ요구가 서버측 프록시(401)로부터 송신된 ＰＯSＴ요구인지의 여부를 판정한다. 중계 서비스(420)는, 수신된 ＰＯSＴ요구가 서버측 프록시(401)로부터 송신된 ＰＯSＴ요구라고 판정했을 경우(단계S2634에서 YES), 단계S2635의 처리로 진행된다. 한편, 중계 서비스(420)는, 수신된 ＰＯSＴ요구가 서버측 프록시(401)로부터 송신된 ＰＯSＴ요구가 아니라고 판정했을 경우(단계S2634에서 NO), 단계S2640의 처리로 진행된다.
단계S2635에서, 중계 서비스(420)는, 서버측 프록시(401)로부터 수신한 ＨＴＴＰ응답을 ＲＵＩ응답 데이터 큐에 격납한다.
단계S2636에서, 중계 서비스(420)는, 취득용 ＵＲＬ에 클라이언트측 프록시(410)로부터 송신된 ＧＥＴ요구를 기다린다.
단계S2637에서, 중계 서비스(420)는, ＲＵＩ응답 데이터 큐에 격납된 ＨＴＴＰ응답을 상기 ＧＥＴ요구에 대한 응답으로서, 클라이언트측 프록시(410)에 송신한다.
단계S2638에서, 중계 서비스(420)는, 취득용 ＵＲＬ에 클라이언트측 프록시(430)로부터 송신된 상기 ＧＥＴ요구를 기다린다.
단계S2639에서, 중계 서비스(420)는, ＲＵＩ응답 데이터 큐에 격납된 ＨＴＴＰ응답을 상기 ＧＥＴ요구에 대한 응답으로서, 클라이언트측 프록시(430)에 송신한다. 다시 말해, 중계 서비스(420)는, 단계S2637에서 클라이언트측 프록시(410)에 송신된 ＨＴＴＰ응답과 같은 ＨＴＴＰ응답을, 클라이언트측 프록시(430)에 송신한다. 이에 따라 ＰＣ(103)가, ＭＦＰ(100)와 ＰＣ(110)와의 사이에 있어서의 ＲＵＩ통신의 통신 내용을 취득할 수 있게 된다.
단계S2640에서, 중계 서비스(420)는, 단계S2629에서 수신된 ＰＯSＴ요구가 클라이언트측 프록시(430)로부터 송신된 ＰＯSＴ요구인지의 여부를 판정한다. 중계 서비스(420)는, 그 수신된 ＰＯSＴ요구가 클라이언트측 프록시(430)로부터 송신된 ＰＯSＴ요구라고 판정했을 경우(단계S2640에서 YES), 단계S2641의 처리로 진행된다. 한편, 중계 서비스(420)는, 그 수신된 ＰＯSＴ요구가 클라이언트측 프록시(430)로부터 송신된 ＰＯSＴ요구가 아니라고 판정했을 경우(단계S2640에서 NO), 단계S2642의 처리로 진행된다.
단계S2641에서, 중계 서비스(420)는, 클라이언트측 프록시(430)로부터 포스트된 ＨＴＴＰ요구를 읽고나서 삭제한다. 단계S2641의 처리는, 삭제 처리의 일례다. 이에 따라, 중계 서비스(420)는, ＰＣ(103)로부터의 ＧＥＴ요구에 따라, ＰＣ(110)용으로 ＲＵＩ응답 데이터 큐에 격납된 최신의 ＨＴＴＰ응답을 송신할 수 있다. 다시 말해, ＰＣ(103)는, ＭＦＰ(100)와 ＰＣ(110)와의 사이의 최신의 ＲＵＩ통신에 있어서의 통신 내용을 취득할 수 있다.
이상의 처리를 행함으로써, 중계 서버(120)는, ＭＦＰ(100)와 ＰＣ(110)와의 사이의 ＲＵＩ통신의 통신 내용을 ＰＣ(103)에 송신할 수 있다. 이때, 중계 서버(120)는, ＰＣ(103)로부터의 ＧＥＴ요구에 대한 ＧＥＴ응답을, ＰＣ(110)용의 최신의 ＧＥＴ응답으로 바꾸면서 송신할 수 있다.
상술한 것처럼, 본 예시적 실시예에 의하면, ＭＦＰ(100)와 ＰＣ(110)와의 사이에 있어서의 ＲＵＩ통신의 통신 내용을, 유저측의 ＰＣ(103)로부터 열람할 수 있다. 본 예시적 실시예에서는, 클라이언트측 프록시(430)와 웹 브라우저(431)는 ＰＣ(103)상에 있는 것으로 했지만, ＭＦＰ(100)상에 있어도 된다. 이 경우, 통신시스템은, 클라이언트측 프록시(430)가 직접 서버측 프록시(401)와 통신하고, 서버측 프록시(401)가 웹 서버(402)로부터의 ＨＴＴＰ응답을 클라이언트측 프록시(430)에 직접 전송하도록 구성되어도 된다. 또한, ＰＣ(110)가 행하는 처리는, 상술한 도 11에 도시된 처리와 같기 때문에, 여기서는 그에 대한 설명을 생략한다.
제6 예시적 실시예는, ＭＦＰ(100)와 ＰＣ(110)와의 사이의 ＲＵＩ통신을, ＭＦＰ(100)와 ＰＣ(103)와의 사이의 ＲＵＩ통신으로 전환 가능하도록 구성된다. 일반적으로, 서비스 엔지니어가 유저의 화상형성장치의 보수를 행할 경우, 서비스 엔지니어는, 작업 내용에 따라 고객측에 작업을 실시해주기를 부탁한다. 예를 들면, 화상형성장치의 보수동안에, 서비스 엔지니어가 화상형성장치의 복구를 위해 설정 값을 변경할 경우, 이러한 보수는 화상형성장치의 정보를 ＰＣ에 백업하는 작업을 종종 포함한다. 그 백업되는 정보에 고객측의 기밀정보가 포함될 경우, 이 정보를 백업하는 조작은 고객측에서 실시해주지 않으면 안 된다.
본 예시적 실시예에서는 ＭＦＰ(100)와 ＰＣ(110)와의 사이에서 행해지고 있는 ＲＵＩ통신을, ＭＦＰ(100)와 ＰＣ(103)와의 사이의 접속으로 전환하는 구성에 관하여 설명한다. 이하에서는, 제6 예시적 실시예가 상술한 제1 내지 제5 예시적 실시예와 동일한 구성에 대해서는 상세히 설명하지 않겠다. 또한, 본 예시적 실시예에 따른 시스템 구성은, 도 27에 도시된 시스템 구성과 같은 것으로 한다.
(도 31a 및 도 31b로 이루어진) 도 31은, 본 예시적 실시예에 따른 ＰＣ(110)가 행한 처리의 일례를 도시하는 흐름도다. 단계S2701로부터 단계S2718까지의 처리는, 도 11에 도시된 단계S901로부터 단계S918까지의 처리와 같기 때문에, 여기서는 그에 대한 설명을 생략한다.
단계S2719에서, 클라이언트측 프록시(410)는, 중계 서버(120)로부터 ＲＵＩ열람 전환 요구를 수신한다.
단계S2720에서, 클라이언트측 프록시(410)는, 웹 브라우저(411)로부터 ＨＴＴＰ요구를 수신한 것인가 아닌가를 판정한다. 클라이언트측 프록시(410)는, ＨＴＴＰ요구를 수신했다고 판정했을 경우(단계S2720에서 YES), 단계S2721의 처리로 진행된다. 클라이언트측 프록시(410)는, ＨＴＴＰ요구를 수신하지 않았다고 판정했을 경우(단계S2720에서 NO), ＨＴＴＰ요구의 수신을 기다린다.
단계S2721에서, 클라이언트측 프록시(410)는, ＨＴＴＰ요구를 중계 서버(120)에 포스트한다. 클라이언트측 프록시(410)에 의해 단계S2721에서 중계 서버(120)에 포스트된 ＨＴＴＰ요구는, 중계 서버(120)측에서 읽고나서 삭제된다. 본 예시적 실시예에서는, 웹 브라우저(411)로부터 송신된 ＨＴＴＰ요구를 클라이언트측 프록시(410)가 중계 서버(120)에 포스트하고 있지만, 클라이언트측 프록시(410)가 이 ＨＴＴＰ요구를 읽고 나서 삭제하도록 구성되어도 된다.
단계S2722에서, 클라이언트측 프록시(410)는, ＲＵＩ응답 데이터 큐로부터 ＨＴＴＰ응답을 수신하기 위해서 취득용 ＵＲＬ에 ＧＥＴ요구를 송신한다.
단계S2723에서, 클라이언트측 프록시(410)는, 단계S2722에서 송신된 ＧＥＴ요구에 따라 ＨＴＴＰ응답을 중계 서버(120)로부터 수신한 것인가 아닌가를 판정한다. 클라이언트측 프록시(410)는, ＨＴＴＰ응답을 수신했다고 판정했을 경우(단계S2723에서 YES), 단계S2724의 처리로 진행된다. 클라이언트측 프록시(410)는, ＨＴＴＰ응답을 수신하지 않았다고 판정했을 경우(단계S2723에서 NO), 단계S2722의 처리로 되돌아간다. 단계S2723에서 클라이언트측 프록시(410)가 수신한 ＨＴＴＰ응답은, ＭＦＰ(100)가 ＰＣ(103)를 향해 되돌려진 ＨＴＴＰ응답이다.
단계S2724에서, 클라이언트측 프록시(410)는, 중계 서버(120)로부터 수신한 ＧＥＴ응답(ＨＴＴＰ응답)으로부터 ＩＤ부분을 추출한다. 더 구체적으로는, 클라이언트측 프록시(410)는, ＧＥＴ응답을 변환하여, 상기 ＩＤ와 상기 ＨＴＴＰ응답을 취득한다.
단계S2725에서, 클라이언트측 프록시(410)는, ＩＤ부분을 제거한 ＨＴＴＰ응답을, 웹 브라우저(411)로부터의 ＨＴＴＰ요구에 대한 응답으로서 되돌린다.
단계S2726에서, 클라이언트측 프록시(410)는, ＰＣ(110)의 조작부(317)를 거쳐 유저로부터 종료 지시를 받은 것인가 아닌가를 판정한다. 클라이언트측 프록시(410)가 종료 지시를 받았다고 판정했을 경우(단계S2726에서 YES), 단계S2727에서, 클라이언트측 프록시(410)는, 중계 서비스(420)에 절단 지시를 내린다. 그리고, 도 31에 도시된 처리를 종료한다. 한편, 클라이언트측 프록시(410)는, 종료 지시를 받지 않았다고 판정했을 경우(단계S2726에서 NO), 단계S2720의 처리로 되돌아간다.
(도 32a 및 도 32b로 이루어진) 도 32는, 본 예시적 실시예에 따른 ＰＣ(103)가 행한 처리의 일례를 도시하는 흐름도다. 단계S2801로부터 단계S2820까지의 처리는, 도 11에 도시된 단계S901로부터 단계S920까지의 처리와 같기 때문에, 여기서는 그에 대한 설명을 생략한다. 본 예시적 실시예에서는, 단계S2806에서 선택되는 지원처인 ＭＦＰ(100)는, 이미 ＰＣ(110)와 통신중인 것으로 한다. 또한, 단계S2809에서, 클라이언트측 프록시(430)는, 중계 서버(120)에 ＲＵＩ접속 요구를 송신 함에 의해, ＰＣ(103)와 ＭＦＰ(100)와의 사이의 ＲＵＩ통신이 시작된다. 이미 통신중인 ＭＦＰ(100)와 ＰＣ(110)와의 사이의 ＲＵＩ통신은, 열람을 위한 통신만으로 전환된다.
(도 33a 및 도 33b로 이루어진) 도 33은, 본 예시적 실시예에 따른 중계 서버(120)가 행한 처리의 일례를 도시하는 흐름도다.
단계S2901로부터 단계S2926까지의 처리는, 도 30의 단계S2601로부터 단계S2626까지의 처리와 같기 때문에, 여기서는 그에 대한 설명을 생략한다.
단계S2927에서, 중계 서비스(420)는, 클라이언트측 프록시(430)로부터 ＲＵＩ접속 요구를 수신한다.
단계S2928에서, 중계 서비스(420)는, 클라이언트측 프록시(410)에, ＲＵＩ통신이 열람을 위한 ＲＵＩ통신으로 전환되는 것을 통지한다. 이와 같이, 중계 서비스(420)는, ＭＦＰ(100)와 ＰＣ(110)와의 통신을 열람을 위한 ＲＵＩ통신만으로 전환할 수 있고, 조작가능한 ＲＵＩ통신이 ＭＦＰ(100)와 ＰＣ(103)와의 사이에서 행해지도록 상기 통신을 전환할 수 있다.
단계S2930으로부터 단계S2932까지의 처리는, 도 30에 도시된 단계S2628로부터 단계S2630까지의 처리와 같기 때문에, 여기서는 그에 대한 설명을 생략한다.
단계S2934 및 단계S2940의 처리는, 도 30에 도시된 단계S2634 및 단계S2640의 처리와 같기 때문에, 여기서는 그에 대한 설명을 생략한다.
단계S2933에서, 중계 서비스(420)는, 클라이언트측 프록시(410)로부터 포스트된 ＨＴＴＰ요구를 읽고나서 삭제한다. 단계S2933의 처리는, 삭제 처리의 일례다. 이에 따라, 중계 서비스(420)는, ＭＦＰ(100)와 ＰＣ(110)와의 통신을 열람을 위한 ＲＵＩ통신만으로 전환할 수 있다.
단계S2935로부터 단계S2939까지의 처리는, 도 30에 도시된 단계S2635로부터 단계S2639까지의 처리와 같기 때문에, 여기서는 그에 대한 설명을 생략한다.
단계S2941에서, 중계 서비스(420)는, ＨＴＴＰ요구를 ＲＵＩ요구 데이터 큐에 격납한다.
단계S2942에서, 중계 서비스(420)는, ＲＵＩ요구 데이터 큐로부터 취득하기 위한 취득용 ＵＲＬ에 서버측 프록시(401)로부터 송신된 ＧＥＴ요구를 기다린다.
단계S2943에서, 중계 서비스(420)는, ＲＵＩ요구 데이터 큐에 격납된 ＨＴＴＰ요구를 상기 ＧＥＴ요구에 대한 응답으로서 서버측 프록시(401)에 송신한다.
단계S2944의 처리는, 도 30에 도시된 단계S2642의 처리와 같기 때문에, 여기서는 그에 대한 설명을 생략한다.
상술한 것처럼, 본 예시적 실시예에 의하면, 중계 서버(120)는, ＭＦＰ(100)와 ＰＣ(110)와의 사이의 ＲＵＩ통신을 열람을 위한 ＲＵＩ통신만으로 전환하고, ＭＦＰ(100)와의 ＲＵＩ통신에 있어서의 조작권을 새롭게 접속된 ＰＣ(103)로 전환할 수 있다. 이에 따라 중계 서버(120)가, ＭＦＰ(100)에 대한 서비스 엔지니어(ＰＣ(110)의 유저)의 조작권을 고객(ＰＣ(103)의 유저)에 이행시킬 수 있게 된다.
제7 예시적 실시예에서는 ＲＵＩ가 보안 소켓 계층(SSL)통신(암호화 통신)을 필요로 할 때에도, ＭＦＰ(100)와 ＰＣ(110)와의 사이의 ＲＵＩ통신의 내용을, 유저(고객)측의 ＰＣ(103)로부터 열람 가능하게 하는 구성에 관하여 설명한다. 이하, 제7 예시적 실시예가 상술한 제1 내지 제6 예시적 실시예와 동일한 구성에 대해서는 상세히 설명하지 않는다. 또한, 본 예시적 실시예에 따른 시스템 구성은, 도 27에 도시된 시스템 구성과 같은 것으로 한다.
ＰＣ(110)가 중계 서버(120)와 접속할 때에 행해진 처리를 나타내는 흐름도는, 제5 예시적 실시예와 같게 도 11에 도시된 바와 같지만, 일부의 처리가 다르기 때문에, 이하에서는 이 차이를 설명한다. 도 11에 도시된 단계S902의 처리에 있어서, 클라이언트측 프록시(410)가 단계S901에서 어플리케이션이 기동되었다고 판정했을 경우, 클라이언트측 프록시(410)는, ＰＣ(110)의 조작부(317)에 인증 정보 입력 화면을 표시한다. 본 예시적 실시예는, 이에 단계S902에 있어서 추가의 수순을 포함한다. 단계S902에서, 클라이언트측 프록시(410)는, 중계 서버(120)와 SSL의 니고시에이션을 실시한다. 이에 따라, ＰＣ(110)는, SSＬ공통 키를 취득하고, 이후의 중계 서버(120)와의 ＨＴＴＰ통신을 모두 암호화하면서 실시한다.
ＰＣ(103)가 중계 서버(120)와 접속할 때에 행해진 처리를 나타내는 흐름도는, 제5 예시적 실시예에서 도 29를 참조하여 설명한 대로이지만, 일부의 처리가 다르기 때문에, 이하에서는 이 차이를 설명한다.
도 29에 도시된 단계S2502의 처리에 있어서, 클라이언트측 프록시(430)가 단계S2501에서 어플리케이션이 기동되었다고 판정했을 경우, 클라이언트측 프록시(430)는, ＰＣ(103)의 조작부(317)에 인증 정보 입력 화면을 표시한다. 본 예시적 실시예는, 이에 단계S2502에 있어서 추가의 수순을 포함한다. 단계S2502에서, 클라이언트측 프록시(430)는, 중계 서버(120)와 SSＬ의 니고시에이션을 실시한다. 이에 따라, ＰＣ(103)는, SSＬ공통 키를 취득하고, 이후의 중계 서버(120)와의 ＨＴＴＰ통신을 모두 암호화하면서 실시한다.
중계 서버(120)가 ＭＦＰ(100) 및 ＰＣ(110)와 접속할 때에 행해진 처리를 나타내는 흐름도는, 제5 예시적 실시예에서 도 30을 참조하여 상술한 바와 같기 때문에, 여기서는 그에 대한 설명을 생략한다.
(도 34a 및 도 34b로 이루어진) 도 34는, 본 예시적 실시예에 따른 ＭＦＰ(100)가 중계 서버(120)와 접속할 때에 행해진 처리의 일례를 도시하는 흐름도다.
단계S3001에서, 서버측 프록시(401)는, 조작부(219)를 거쳐 콜 센터의 기동 지시가 있었던 것인가 아닌가를 판정한다.
단계S3002에서, 서버측 프록시(401)는, 중계 서버(120)와 SSＬ의 니고시에이션을 실시한다. 이에 따라, 서버측 프록시(401)는, SSＬ공통 키를 취득하고, 이후의 중계 서버(120)와의 ＨＴＴＰ통신을 모두 암호화하면서 실시할 수 있다. 단계S3003으로부터 단계S3011까지의 처리는, 도 8에 도시된 단계S702로부터 단계S710까지의 처리와 같기 때문에, 여기서는 그에 대한 설명을 생략한다. 그러나, 단계S3010에 있어서, 서버측 프록시(401)는, 단계S3002에서 취득한 SSＬ공통 키를 사용해서 ＧＥＴ방법에 의해 취득된 ＨＴＴＰ데이터를 복호한다.
단계S3012에서, 서버측 프록시(401)는, 단계S3011의 처리를 행하여서 ＨＴＴＰ요구를 취득하면, ＨＴＴＰ요구의 접속처인 웹 서버(402)가 SSＬ 접속이 필요한가 아닌가를 판정한다. 서버측 프록시(401)는, SSＬ접속이 필요하다고 판정했을 경우(단계S3012에서 YES), 단계S3013의 처리로 진행된다. 서버측 프록시(401)는, SSＬ접속이 불필요하다고 판정했을 경우(단계S3012에서 NO), 단계S3018의 처리로 진행된다. 단계S3012에서의 판정에 사용된 방법으로서, 서버측 프록시(401)는, 웹 서버(402)에 접속하려고 시도하나서 서버측 프록시(401)가 하이퍼텍스트 전송 프로토콜 시큐어(ＨＴＴＰS)에 의거한 페이지에 리다이렉트(redirect)(유도)된 것인가 아닌가에 의거하여 판정해도 된다. 이때, 서버측 프록시(401)는, ＨＴＴＰS에 의거한 페이지에 리다이렉트되었을 경우, SSＬ접속이 필요하다고 판정한다. 또는, 서버측 프록시(401)는, 미리 ＨＤＤ(214)에 SSＬ접속이 필요한 웹 서버(402)에 관한 정보(등록 정보)를 등록해 두는 것에 의해 판정해도 된다. "ＨＴＴＰS"란, Ｈｙｐｅｒｔｅｘｔ Ｔｒａｎｓｆｅｒ Ｐｒｏｔｏｃｏｌ Sｅｃｕｒｅ"를 나타낸다.
서버측 프록시(401)는, 단계S3012에서 SSＬ접속이 필요하다고 판정했을 경우(단계S3012에서 YES), 단계S3013에서, 웹 서버(402)와 SSＬ의 니고시에이션을 실시한다.
단계S3014에서, 서버측 프록시(401)는, 단계S3013에서 웹 서버(402)로부터 취득한 SSＬ공통 키를 사용하여 단계S3011에서 취득된 ＨＴＴＰ요구를 암호화한다.
단계S3015에서, 서버측 프록시(401)는, 단계S3014에서 암호화한 ＨＴＴＰ요구를 웹 서버(402)에 송신한다.
단계S3016에서, 서버측 프록시(401)는, 단계S3015에서 송신한 상기 요구에 대한 응답으로서, 웹 서버(402)로부터 암호화된 ＨＴＴＰ응답을 수신한다.
단계S3017에서, 서버측 프록시(401)는, SSＬ공통 키를 사용하여 단계S3016에서 수신한 ＨＴＴＰ응답을 복호한다. 그리고, 단계S3020의 처리로 진행된다.
서버측 프록시(401)는, 단계S3012에서 SSＬ접속이 불필요하다고 판정했을 경우(단계S3012에서 NO), 단계S3018에서, 서버측 프록시(401)는, 웹 서버(402)에 ＨＴＴＰ요구를 송신한다.
단계S3019에서, 서버측 프록시(401)는, 단계S3018에서 송신한 상기 요구에 대한 응답으로서, 웹 서버(402)로부터 ＨＴＴＰ응답을 수신한다. 그리고, 단계S3020의 처리로 진행된다.
단계S3017 또는 단계S3019의 처리 후, 단계S3020에서, 서버측 프록시(401)는, 웹 서버(402)로부터 수신한 ＨＴＴＰ응답에 ＨＤＤ(214)에 기억된 ＩＤ를 부가하고, 이 ＨＴＴＰ응답을 ＲＵＩ응답 데이터 큐에 격납하기 위해서 격납용 ＵＲＬ에 송신한다.
단계S3021 및 단계S3022의 처리는, 도 8에 도시된 단계S714 및 단계S715의 처리와 같기 때문에, 여기서는 그에 대한 설명을 생략한다.
이러한 일련의 처리에서는, ＰＣ(110)와 ＭＦＰ(100)와의 통신 경로는 SSＬ로 암호화되어 있지만, 서버측 프록시(401)가 웹 서버(402)로부터 수신된 암호화된 ＨＴＴＰ데이터를 복호해서 중계 서비스(420)에 송신한다. 이에 따라 ＰＣ(103)가 중계 서버(120)에 의해 인증된 후에 접속했을 경우, ＰＣ(103)가, ＰＣ(110)와 ＭＦＰ(100)간의 통신의 내용을 감시할 수 있다.
상술한 것처럼, 본 예시적 실시예에 의하면, ＲＵＩ가 SSＬ통신이 필요할 때에도, ＭＦＰ(100)와 ＰＣ(110)와의 사이의 ＲＵＩ통신의 내용을, 유저측의 ＰＣ(103)로부터 열람할 수 있게 된다.
제8 예시적 실시예에서는, ＲＵＩ가 SSＬ통신이 필요할 때에도, 웹 서버(402)로 접수한 ＨＴＴＰ요구의 접속원(요구원)이 ＭＦＰ(100)의 외부에 있지 않기만 하면, 그 접속원을 SSＬ접속 없이도 접속시킬 수 있는 구성에 관하여 설명한다. 이하에서는, 제8 예시적 실시예가 상술한 제1 내지 제7 예시적 실시예와 동일한 구성에 대해서는 상세히 설명하지 않는다. 또한, 본 예시적 실시예에 따른 시스템 구성은, 도 27과 같은 것으로 한다.
도 35는, 본 예시적 실시예에 따른 ＭＦＰ(100)가 중계 서버(120)와 접속할 때에 행해진 처리의 일례를 도시하는 흐름도다.
단계S3101로부터 단계S3111까지의 처리는, 도 34의 단계S3001로부터 단계S3011까지의 처리와 같기 때문에, 여기서는 그에 대한 설명을 생략한다.
단계S3112에서, 서버측 프록시(401)는, 웹 서버(402)에 ＨＴＴＰ요구를 송신한다.
단계S3113에서, 서버측 프록시(401)는, 웹 서버(402)에 의해 수신한 ＨＴＴＰ요구의 접속원이 ＭＦＰ(100)의 외부에 있지 않는, 다시 말해, 그 접속원이 ＭＦＰ(100)내에 있는 것을 확인한다. 이때, 서버측 프록시(401)는, 이 접속이 로컬 루프백(loop-back) 어드레스로부터의 접속이면, 상기 접속원이 ＭＦＰ(100)의 외부에 있지 않는 것을 판정하도록 구성되어도 된다. 또한, 서버측 프록시(401)는, 상기 접속원이 소유하는 증명서(증명 정보)에 의거해, 상기 접속원이 ＭＦＰ(100)의 외부에 있지 않는 것을 확인하도록 구성하여도 된다. 더 구체적으로, 서버측 프록시(401)는, 미리 기억되어 있는 증명서와, 상기 접속원이 소유하는 증명서가 일치할 경우, 상기 접속원이 ＭＦＰ(100)의 외부에 있지 않는 것을 판정하도록 구성되어도 된다. 상기한 바와 같이, 본 예시적 실시예에서는, 웹 서버(402)에 의해 수신한 ＨＴＴＰ요구의 접속원이 ＭＦＰ(100)의 외부에 있지 않는 경우, SSＬ접속 없이도 접속원이 접속가능하게 한다.
서버측 프록시(401)는 단계S3113에서 웹 서버(402)에 의해 수신한 ＨＴＴＰ요구의 접속원이 ＭＦＰ(100)의 외부에 있지 않는 것을 확인한 후, 단계S3114의 처리로 진행된다. 한편, 서버측 프록시(401)는 단계S3113에서 ＨＴＴＰ요구의 접속원이 ＭＦＰ(100)의 외부에 있는 것을 확인했을 경우, 서버측 프록시(401)는, 이 접속원과의 안전하지 않은(암호화되지 않은) 접속을 절단한다. 그 후, 도 35에 도시된 처리를 종료한다.
단계S3114에서, 서버측 프록시(401)는, 단계S3112에서 송신된 요구에 대한 응답으로서, 웹 서버(402)로부터 ＨＴＴＰ응답을 수신한다.
단계S3115로부터 단계S3117까지의 처리는, 도 34에 도시된 단계S3020으로부터 단계S3022까지의 처리와 같기 때문에, 여기서는 그에 대한 설명을 생략한다.
ＰＣ110 및 ＰＣ103이 중계 서버(120)와 접속할 때 행해진 처리는, 제7 예시적 실시예에서 도 11 및 도 29를 참조하여 설명한 바와 같기 때문에, 여기서는 그에 대한 설명을 생략한다. 또한, 중계 서버(120)가 ＭＦＰ(100) 및 ＰＣ(110)와 접속할 때 행해진 처리는, 제5 예시적 실시예에서 도 30을 참조하여 설명한 바와 같기 때문에, 여기서는 그에 대한 설명을 생략한다. 본 예시적 실시예에서는, ＲＵＩ가 SSＬ통신을 필요로 하는 것을 가정하여 설명했지만, 도 34에 도시된 단계S3012와 같이, 서버측 프록시(401)가, 웹 서버(402)가 SSＬ 접속을 필요로 하는 것인가 아닌가를 판정하도록 구성되어도 된다.
상술한 것처럼, 본 예시적 실시예에 의하면, ＲＵＩ가 SSＬ통신이 필요할 때에도, 웹 서버(402)에서 수신한 ＨＴＴＰ요구의 접속원이 ＭＦＰ(100)의 내부에 있는 경우, 그 접속원이 SSＬ접속 없이도 접속 가능하게 된다. 이에 따라, 상기 접속원이 ＭＦＰ(100)의 내부에 있는 경우, 이 접속원은, ＲＵＩ가 SSＬ통신이 필요할 때에도, ＭＦＰ(100)내의 ＨＴＴＰ데이터를 열람할 수 있게 된다.
<그 밖의 예시적 실시예>
또한, 본 발명은, 이하의 처리를 행함으로써도 실현될 수 있다. 즉, 본 발명은, 상술한 예시적 실시예들의 기능을 실현하는 소프트웨어(프로그램)를, 네트워크 또는 각종 기억매체를 거쳐서 시스템 또는 장치에 공급하고, 그 시스템 또는 장치의 컴퓨터(또는 ＣＰＵ, 마이크로처리장치(ＭＰＵ)등)가 그 프로그램을 판독해서 실행하게 하는 처리를 행함으로써 실현될 수 있다.
또한, 상술한 각 예시적 실시예에 따른 시스템에 포함된 ＭＦＰ(100)를, ＰＣ, 서버 장치 및 타블렛 단말등의 다른 정보처리장치로 대체할 때에도 동일한 효과를 취득할 수 있다.
상술한 것처럼, 상술한 각 예시적 실시예에 의하면, 안전한 통신 환경에서의 웹 서비스의 이용에 있어서의 편리성을 향상시킬 수 있다. 더 구체적으로, 유저는, 파이어월의 내측에 있는 정보처리장치로부터, 인터넷을 거쳐서 상이한 파이어월의 내측에 있는 화상형성장치의 웹 서비스 기능에 접속할 수 있다. 이에 따라 유저가 상기 정보처리장치로부터 상기 웹 서비스에 있어서의 백업 기능과 리스토어 기능 등의 기능을 이용할 수 있다.
본 발명에 의하면, 안전한 통신 환경에서의 웹 서비스의 이용에 있어서의 편리성을 향상시킬 수 있다.
그 밖의 실시예들
또한, 본 발명의 실시예(들)는, 기억매체(보다 완전하게는 '비일시적 컴퓨터 판독 가능한 기억매체'라고도 함)에 레코딩된 컴퓨터 실행가능한 명령어들(예를 들면, 하나 이상의 프로그램)을 판독하고 실행하여 상술한 실시예(들)의 하나 이상의 기능을 수행하는 것 및/또는 상술한 실시예(들)의 하나 이상의 기능을 수행하기 위한 하나 이상의 회로(예를 들면, 주문형 반도체(ASIC))를 구비하는 것인, 시스템 또는 장치를 갖는 컴퓨터에 의해 실현되고, 또 예를 들면 상기 기억매체로부터 상기 컴퓨터 실행가능한 명령어를 판독하고 실행하여 상기 실시예(들)의 하나 이상의 기능을 수행하는 것 및/또는 상술한 실시예(들)의 하나 이상의 기능을 수행하는 상기 하나 이상의 회로를 제어하는 것에 의해 상기 시스템 또는 상기 장치를 갖는 상기 컴퓨터에 의해 행해지는 방법에 의해 실현될 수 있다. 상기 컴퓨터는, 하나 이상의 프로세서(예를 들면, 중앙처리장치(CPU), 마이크로처리장치(MPU))를 구비하여도 되고, 컴퓨터 실행 가능한 명령어를 판독하여 실행하기 위해 별개의 컴퓨터나 별개의 프로세서의 네트워크를 구비하여도 된다. 상기 컴퓨터 실행가능한 명령어를, 예를 들면 네트워크나 상기 기억매체로부터 상기 컴퓨터에 제공하여도 된다. 상기 기억매체는, 예를 들면, 하드 디스크, 랜덤액세스 메모리(RAM), 판독전용 메모리(ROM), 분산형 컴퓨팅 시스템의 스토리지, 광디스크(콤팩트 디스크(CD), 디지털 다기능 디스크(DVD) 또는 블루레이 디스크(BD)TM등), 플래시 메모리 소자, 메모리 카드 등 중 하나 이상을 구비하여도 된다.
본 발명을 예시적 실시예들을 참조하여 기재하였지만, 본 발명은 상기 개시된 예시적 실시예들에 한정되지 않는다는 것을 알 것이다. 아래의 청구항의 범위는, 모든 변형예, 동등한 구조 및 기능을 포함하도록 폭 넓게 해석해야 한다.

Claims (1)

  1. 중계 서버를 거쳐서, 웹 서버를 포함한 통신장치와 통신하는 정보처리장치로서,
    상기 통신장치 내의 상기 웹 서버에 대한 제1 요구를 생성하는 제1 생성부;
    상기 중계 서버에 대한 제2 요구를 생성하는 제2 생성부;
    상기 중계 서버에 상기 제1 요구를 격납하기 위하여, 상기 생성된 제2 요구를, 제1 파이어월을 거쳐서 상기 중계 서버에, 송신하고, 상기 중계 서버에 격납된 상기 제1 요구에 대한 제1 응답을 취득하기 위하여 제3 요구를, 상기 제1 파이어월을 거쳐서 상기 중계 서버에 송신하는 요구 송신부; 및
    상기 제3 요구에 대한 제2 응답에 포함된 상기 제1 요구에 대한 상기 제1 응답을 취득하는 취득부를 구비하고,
    상기 제2 요구는 상기 생성된 제1 요구를 포함하며,
    상기 통신장치는 제2 파이어월을 거쳐서 상기 중계 서버에, 상기 제1 요구에 대한 상기 제1 응답을 송신하고, 상기 송신된 제1 응답은 상기 중계 서버에 격납되고,
    상기 정보처리장치는 제1 상태 및 제2 상태에서 상기 통신장치와 통신하고,
    상기 정보처리장치는 상기 통신장치를 조작할 수 있고, 다른 정보처리장치는 상기 제1 상태에서 상기 통신장치를 조작할 수 없으며, 상기 정보처리장치는 상기 통신장치의 조작 화면을 표시할 수 있고, 상기 다른 정보처리장치는 상기 제2 상태에서 상기 통신장치를 조작할 수 있는, 정보처리장치.
KR1020170129424A 2014-03-18 2017-10-11 정보처리장치, 시스템, 정보처리방법 및 기억매체 KR101900799B1 (ko)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
JPJP-P-2014-055371 2014-03-18
JP2014055371A JP2015179894A (ja) 2014-03-18 2014-03-18 情報処理装置、システム、情報処理方法及びプログラム

Related Parent Applications (1)

Application Number Title Priority Date Filing Date
KR1020150037206A Division KR101786608B1 (ko) 2014-03-18 2015-03-18 정보처리장치, 시스템, 정보처리방법 및 기억매체

Publications (2)

Publication Number Publication Date
KR20170118643A true KR20170118643A (ko) 2017-10-25
KR101900799B1 KR101900799B1 (ko) 2018-09-20

Family

ID=52736859

Family Applications (2)

Application Number Title Priority Date Filing Date
KR1020150037206A KR101786608B1 (ko) 2014-03-18 2015-03-18 정보처리장치, 시스템, 정보처리방법 및 기억매체
KR1020170129424A KR101900799B1 (ko) 2014-03-18 2017-10-11 정보처리장치, 시스템, 정보처리방법 및 기억매체

Family Applications Before (1)

Application Number Title Priority Date Filing Date
KR1020150037206A KR101786608B1 (ko) 2014-03-18 2015-03-18 정보처리장치, 시스템, 정보처리방법 및 기억매체

Country Status (5)

Country Link
US (2) US20150271292A1 (ko)
EP (1) EP2922270B1 (ko)
JP (1) JP2015179894A (ko)
KR (2) KR101786608B1 (ko)
CN (1) CN104935773B (ko)

Families Citing this family (11)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US10756916B2 (en) * 2014-06-17 2020-08-25 Intrepid Networks, Llc Distributed processing network system, integrated response systems and methods providing situational awareness information for emergency response
JP6555218B2 (ja) * 2016-09-21 2019-08-07 京セラドキュメントソリューションズ株式会社 情報処理システムおよび情報処理方法
JP2018112895A (ja) * 2017-01-11 2018-07-19 キヤノン株式会社 情報処理装置、その制御方法、プログラム、及び情報処理システム
JP6751267B2 (ja) * 2017-06-30 2020-09-02 京セラドキュメントソリューションズ株式会社 リモート通信制御システム、リモート通信システム、セッション管理システムおよびセッション管理プログラム
JP7094809B2 (ja) * 2018-07-10 2022-07-04 キヤノン株式会社 情報処理装置、情報処理装置の制御方法、及びプログラム
JP7064410B2 (ja) * 2018-09-11 2022-05-10 サトーホールディングス株式会社 情報処理端末、情報処理方法、および、プログラム
US11178111B2 (en) * 2018-11-28 2021-11-16 International Business Machines Corporation Licensing authority controlled modification of http headers in a proxy-based system
US11159370B2 (en) * 2019-10-31 2021-10-26 Juniper Networks, Inc. Bulk discovery of devices behind a network address translation device
US11784874B2 (en) 2019-10-31 2023-10-10 Juniper Networks, Inc. Bulk discovery of devices behind a network address translation device
JP7406386B2 (ja) * 2020-02-03 2023-12-27 アラクサラネットワークス株式会社 通信監視装置、通信監視方法、及び通信監視プログラム
JPWO2023199387A1 (ko) * 2022-04-11 2023-10-19

Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20050229243A1 (en) * 2004-03-31 2005-10-13 Svendsen Hugh B Method and system for providing Web browsing through a firewall in a peer to peer network
KR20080039382A (ko) * 2005-08-31 2008-05-07 마이크로소프트 코포레이션 Ｈｔｔｐ 작성 프로토콜의 조합
KR20110015382A (ko) * 2009-08-07 2011-02-15 캐논 가부시끼가이샤 정보 처리 시스템, 그 제어 방법 및 기억 매체
JP2011186912A (ja) * 2010-03-10 2011-09-22 Fujitsu Ltd 中継処理方法、プログラム及び装置
KR20120114228A (ko) * 2009-11-30 2012-10-16 삼성전자주식회사 원격 사용자 인터페이스 기반의 특화된 제어 사용자 인터페이스를 받아 오는 방법 및 장치

Family Cites Families (26)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2002223483A (ja) * 2000-11-09 2002-08-09 Yamatake Corp 遠隔管理システム
US7003799B2 (en) * 2001-01-30 2006-02-21 Hewlett-Packard Development Company, L.P. Secure routable file upload/download across the internet
JP4315696B2 (ja) * 2002-03-29 2009-08-19 富士通株式会社 ホスト端末エミュレーションプログラム、中継用プログラムおよびホスト端末エミュレーション方法
JP5079039B2 (ja) * 2002-09-24 2012-11-21 株式会社リコー 管理仲介装置、画像形成装置、管理仲介プログラム及び管理仲介プログラムを記録した記録媒体
JP2005202918A (ja) 2003-12-15 2005-07-28 Noboru Ikuta ネットワークを利用した携帯端末データ管理システム
JP2005208974A (ja) 2004-01-23 2005-08-04 Canon Inc 画像処理装置のヘルプシステム
US8549541B2 (en) * 2004-03-26 2013-10-01 Intellectual Ventures Ii Llc Bridging local device communications across the wide area
US20060061803A1 (en) * 2004-09-20 2006-03-23 Kabushiki Kaisha Toshiba Image forming system and communication method
NO20055084L (no) * 2005-10-31 2007-05-02 Telenor Asa System og fremgangsmate for etablering av en forbindelse mellom en klient i et nettverk og en web-tjeneste i et annet nettverk
US20070150610A1 (en) * 2005-12-22 2007-06-28 Konstantin Vassilev Javascript relay
JP2008102704A (ja) * 2006-10-18 2008-05-01 Canon Inc デバイス装置及びその制御方法、コンピュータプログラム、記憶媒体
US20090077251A1 (en) * 2007-09-13 2009-03-19 International Business Machines Corporation Protocol for enabling dynamic and hierarchical interconnection of autonomous federations of enterprise service buses
JP4890605B2 (ja) * 2009-12-08 2012-03-07 シャープ株式会社 複合機、複合機制御システム、プログラムおよび記録媒体
JP5539043B2 (ja) * 2010-06-08 2014-07-02 キヤノン株式会社 情報送信装置、情報送信装置の制御方法及びコンピュータプログラム
EP2672689B1 (en) * 2011-02-03 2018-02-28 NEC Corporation Remote operation system, relay apparatus, mobile communication apparatus, in-terminal server control method and relay processing method
WO2012125564A1 (en) * 2011-03-11 2012-09-20 Resource Interactive, Llc Payment card industry data security standard compliant proxy service
JPWO2012153457A1 (ja) * 2011-05-12 2014-07-31 Ｎｅｃカシオモバイルコミュニケーションズ株式会社 遠隔操作システム、中継装置、移動通信端末装置、中継方法、及び判定プログラム
JP5662360B2 (ja) * 2012-02-07 2015-01-28 日本電信電話株式会社 情報通信システム、コミュニティ管理サーバ、ゲートウェイ装置、情報通信方法およびプログラム
JP2013210896A (ja) * 2012-03-30 2013-10-10 Fujifilm Corp プロキシサーバ装置、クライアント端末装置、リモートアクセスシステム、転送制御方法及びプログラム、並びにアクセス方法及びプログラム
JP5721659B2 (ja) * 2012-04-06 2015-05-20 キヤノン株式会社 管理装置、管理システム、及び制御方法
US9319449B2 (en) * 2012-06-29 2016-04-19 Mckesson Financial Holdings Method, apparatus, and computer program product for processing data requests
US20140075541A1 (en) * 2012-09-11 2014-03-13 Orion Energy Systems, Inc. Systems and methods for accessing resources through a firewall
US20140075533A1 (en) * 2012-09-11 2014-03-13 Orion Energy Systems, Inc. Accessing resources through a firewall
KR101478662B1 (ko) * 2013-01-15 2015-01-02 서정환 클라이언트의 ｉｐ주소를 서버로 전송하는 중계 시스템 및 방법
US8923116B1 (en) * 2013-06-17 2014-12-30 Seven Networks, Inc. Selective activation of network management policies of mobile devices in a mobile network
JP6335607B2 (ja) * 2014-04-21 2018-05-30 キヤノン株式会社 通信システム、画像処理装置、画像処理装置の制御方法、及びプログラム

Patent Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20050229243A1 (en) * 2004-03-31 2005-10-13 Svendsen Hugh B Method and system for providing Web browsing through a firewall in a peer to peer network
KR20080039382A (ko) * 2005-08-31 2008-05-07 마이크로소프트 코포레이션 Ｈｔｔｐ 작성 프로토콜의 조합
KR20110015382A (ko) * 2009-08-07 2011-02-15 캐논 가부시끼가이샤 정보 처리 시스템, 그 제어 방법 및 기억 매체
KR20120114228A (ko) * 2009-11-30 2012-10-16 삼성전자주식회사 원격 사용자 인터페이스 기반의 특화된 제어 사용자 인터페이스를 받아 오는 방법 및 장치
JP2011186912A (ja) * 2010-03-10 2011-09-22 Fujitsu Ltd 中継処理方法、プログラム及び装置

Also Published As

Publication number Publication date
JP2015179894A (ja) 2015-10-08
US10708385B2 (en) 2020-07-07
KR101786608B1 (ko) 2017-10-18
EP2922270A3 (en) 2015-10-07
KR20150108786A (ko) 2015-09-30
CN104935773A (zh) 2015-09-23
US20180332137A1 (en) 2018-11-15
EP2922270A2 (en) 2015-09-23
CN104935773B (zh) 2019-06-25
EP2922270B1 (en) 2020-09-02
KR101900799B1 (ko) 2018-09-20
US20150271292A1 (en) 2015-09-24

Similar Documents

Publication Publication Date Title
KR101900799B1 (ko) 정보처리장치, 시스템, 정보처리방법 및 기억매체
JP3982736B2 (ja) 翻訳システム
KR101804966B1 (ko) 정보처리장치 및 그 제어방법
JP5768419B2 (ja) 編集制御システム、画像処理装置、編集制御プログラム、及び記録媒体
JP2018205840A (ja) システム、その方法およびそのプログラム
JP2011191888A (ja) 画像形成装置、制御方法、及びプログラム
JP6278651B2 (ja) ネットワークシステム、管理サーバシステム、制御方法及びプログラム
JP2014081779A (ja) 機器管理システム、周辺機器、及びその制御方法。
JP2018077623A (ja) 管理システム、および制御方法
JP2019086937A (ja) 画像処理装置、画像処理装置の制御方法、プログラム、システム、およびシステムの制御方法
JP2018033102A (ja) 情報処理システム、情報処理装置及びその制御方法、及びプログラム
JP6341710B2 (ja) サーバ装置及び情報処理方法
US10713098B2 (en) Information processing apparatus and cookie information management method
JP6197286B2 (ja) 通信装置、情報処理システム及び情報処理システムの制御方法
JP5011692B2 (ja) バックアップリストアシステム、バックアップリストア方法、バックアップシステム、バックアップ方法
JP6395405B2 (ja) 情報処理装置、情報処理方法及びプログラム
JP7215542B2 (ja) 認証連携装置、情報処理プログラム及び認証連携システム
JP6318759B2 (ja) 情報管理装置、情報管理システム、情報管理方法、及びプログラム
JP6179641B2 (ja) 編集制御システム、画像処理装置、編集制御プログラム、及び記録媒体
JP2016038805A (ja) 情報処理システム、情報処理装置及びその制御方法、及びプログラム
JP2015226292A (ja) 中継装置、サービス実行システム、及びプログラム
JP5745013B2 (ja) 画像処理システム、画像処理装置、画像処理システムにおける制御方法、画像処理装置の制御方法、及びプログラム
JP2018055569A (ja) 情報処理装置及びその制御方法、及びプログラム
JP2008102566A (ja) 印刷処理システムおよび印刷処理プログラム
JP5958612B2 (ja) 編集制御システム、画像処理装置、編集制御プログラム、及び記録媒体

Legal Events

Date Code Title Description
A107 Divisional application of patent
A201 Request for examination
E902 Notification of reason for refusal
E701 Decision to grant or registration of patent right