KR100779790B1 - 프로토콜 변환 처리를 실행하는 장치, 방법, 및 기록 매체 - Google Patents

프로토콜 변환 처리를 실행하는 장치, 방법, 및 기록 매체 Download PDF

Info

Publication number
KR100779790B1
KR100779790B1 KR1020057021489A KR20057021489A KR100779790B1 KR 100779790 B1 KR100779790 B1 KR 100779790B1 KR 1020057021489 A KR1020057021489 A KR 1020057021489A KR 20057021489 A KR20057021489 A KR 20057021489A KR 100779790 B1 KR100779790 B1 KR 100779790B1
Authority
KR
South Korea
Prior art keywords
protocol
protocol conversion
network
printer
proxy server
Prior art date
Application number
KR1020057021489A
Other languages
English (en)
Other versions
KR20060021840A (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 KR20060021840A publication Critical patent/KR20060021840A/ko
Application granted granted Critical
Publication of KR100779790B1 publication Critical patent/KR100779790B1/ko

Links

Images

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F13/00—Interconnection of, or transfer of information or other signals between, memories, input/output devices or central processing units
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L12/00—Data switching networks
    • H04L12/28—Data switching networks characterised by path configuration, e.g. LAN [Local Area Networks] or WAN [Wide Area Networks]
    • H04L12/2803—Home automation networks
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L12/00—Data switching networks
    • H04L12/28—Data switching networks characterised by path configuration, e.g. LAN [Local Area Networks] or WAN [Wide Area Networks]
    • H04L12/2803—Home automation networks
    • H04L12/283—Processing of data at an internetworking point of a home automation network
    • H04L12/2836—Protocol conversion between an external network and a home network
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L41/00—Arrangements for maintenance, administration or management of data switching networks, e.g. of packet switching networks
    • H04L41/02—Standardisation; Integration
    • H04L41/0226—Mapping or translating multiple network management protocols
    • 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
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L12/00—Data switching networks
    • H04L12/28—Data switching networks characterised by path configuration, e.g. LAN [Local Area Networks] or WAN [Wide Area Networks]
    • H04L12/2803—Home automation networks
    • H04L12/2807—Exchanging configuration information on appliance services in a home automation network
    • H04L12/2809—Exchanging configuration information on appliance services in a home automation network indicating that an appliance service is present in a home automation network
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L12/00—Data switching networks
    • H04L12/28—Data switching networks characterised by path configuration, e.g. LAN [Local Area Networks] or WAN [Wide Area Networks]
    • H04L12/2803—Home automation networks
    • H04L2012/284—Home automation networks characterised by the type of medium used
    • H04L2012/2845—Telephone line
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L12/00—Data switching networks
    • H04L12/28—Data switching networks characterised by path configuration, e.g. LAN [Local Area Networks] or WAN [Wide Area Networks]
    • H04L12/2803—Home automation networks
    • H04L2012/2847—Home automation networks characterised by the type of home appliance used
    • H04L2012/2849—Audio/video appliances
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L12/00—Data switching networks
    • H04L12/28—Data switching networks characterised by path configuration, e.g. LAN [Local Area Networks] or WAN [Wide Area Networks]
    • H04L12/2803—Home automation networks
    • H04L2012/2847—Home automation networks characterised by the type of home appliance used
    • H04L2012/285—Generic home appliances, e.g. refrigerators
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L41/00—Arrangements for maintenance, administration or management of data switching networks, e.g. of packet switching networks
    • H04L41/02—Standardisation; Integration
    • H04L41/0213—Standardised network management protocols, e.g. simple network management protocol [SNMP]
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L41/00—Arrangements for maintenance, administration or management of data switching networks, e.g. of packet switching networks
    • H04L41/02—Standardisation; Integration
    • H04L41/0246—Exchanging or transporting network management information using the Internet; Embedding network management web servers in network elements; Web-services-based protocols
    • H04L41/0273—Exchanging or transporting network management information using the Internet; Embedding network management web servers in network elements; Web-services-based protocols using web services for network management, e.g. simple object access protocol [SOAP]

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Automation & Control Theory (AREA)
  • Computer Security & Cryptography (AREA)
  • Multimedia (AREA)
  • Computing Systems (AREA)
  • Theoretical Computer Science (AREA)
  • Physics & Mathematics (AREA)
  • General Engineering & Computer Science (AREA)
  • General Physics & Mathematics (AREA)
  • Computer And Data Communications (AREA)

Abstract

장치가 네트워크를 검색하는 때에, 프로토콜 A로 검색되는 것과 프로토콜 B 로 검색되는 것으로서 다른 장치로 장치가 인식되는 경우가 있다. 네트워크 시스템에서 프로토콜 변환 처리를 실행하기 위한 프록시 서버(9300)에서, 소정의 프로토콜 변환 처리를 실행하기 위한 또 다른 프로토콜 변환 장치가 네트워크 상에 존재하는지 여부가 검색된다. 네트워크 상에서 또 다른 프로토콜 변환 장치가 검색되는 경우, 검색된 프로토콜 변환 장치가 프로토콜 변환 처리를 수행하였는지 여부가 판별된다.
UPnP, SNMP, 프린터 프로토콜, Windows, 프로토콜 스택

Description

프로토콜 변환 처리를 실행하는 장치, 방법, 및 기록 매체{APPARATUS, METHOD, AND RECORDING MEDIUM FOR EXECUTING PROTOCOL CONVERTING PROCESS}
본 발명은 소정의 프로토콜에 따라 통신 프로세스를 수행하는 네트워크 장치 및 서버 장치, 이를 포함하는 시스템, 방법, 제어 프로그램, 등에 관한 것이다.
종래에는 네트워크 상의 클라이언트 장치로부터의 서비스 요청에 응답하여 서비스를 부여하는 서비스 제공 장치 및 서비스 제공 시스템이 공지되어 있다.
예컨대, 인터넷에 의한 통신의 급속한 확산과 함께, 종래의 퍼스널 컴퓨터 뿐만 아니라 PDA, 셀룰러 폰 등의 사용자 양방향 장치들, 스캐너, 프린터, 복사기, 디지털 카메라, 등의 화상 처리장치들, 및 텔레비젼, 에어컨, 냉장고, 등의 가전제품들도 네트워크 상에서 통신될 수 있도록 네트워크 지원 장치들이 급속히 진보되어 왔다.
이러한 진보와 함께, 그러한 네트워크 지원 장치들의 사용 편이성과 간편성을 증진시키기 위하여, 네트워크 어드레스의 자동 설정 수단, 네트워크 장치의 발견 수단 및 네트워크 지원 장치를 제어하기 위한 어플리케이션 소프트웨어, 유틸리티 소프트웨어, 운영체제 등의 자동 설정 수단을 제공하는 다양한 프로토콜들이 제안되었다. 예컨대, 주로 Microsoft사에 의해 그 표준화가 진행중인 "유니버셜 플러그 앤 플레이(Universal Plug and Play, 이하 UPnP)", JBMIA(Japan Business Machine Makers Industrial Association)에 의해 개발중인 "BMLinkS", "Apple OSX"에 의해 지원되는 "Renedzvous", 등의 프로토콜들이 있다.
그러한 프로토콜들의 등장의 결과, 사용 편이성과 간편성이 개선된 반면, 네트워크 장치들이 그러한 복수의 프로토콜에 상응하도록 할 필요성을 촉발하였다. 고급 복사기, 프린터와 같이 대규모의 하드웨어와 대량의 소프트웨어 리소스들을 갖는 장치들에서는 복수의 프로토콜들이 구현될 수 있을지라도, 그 밖의 장치들에서는 사용 어플리케이션에 따라서 각각의 프로토콜이 구현되어야 하므로, 이는 개발 비용 증가의 한 요인이 된다. 이미 시중에 나와 있는 네트워크 상에서 운용중인 장치들은 그러한 프로토콜들에 상응할 수 없다.
이러한 문제점을 해결하는 수단으로서, 프록시(Proxy) 또는 브릿지(Bridge)라고 하는 장치들이 네트워크 상에서 동작가능하도록 하여, 프로토콜 일치를 위한 프록시 처리를 실행하도록 하는 방법이 통상적으로 사용된다.
그러나, 이러한 종래 기술에 의하면, 프로토콜 변환 처리를 실행하고자 하는 경우, 예컨대, 복수의 프로토콜들(A 및 B)에 상응하는 한 특정 장치가 다른 장치들 중에 존재하는 경우, 그 장치가 네트워크를 검색하는 때에는, 그 장치는 프로토콜 A에 의해 검색되는 하나와 프로토콜 B에 의해 검색되는 다른 하나로서, 상이한 장치들로 인식된다.
그 장치가 소정의 프로토콜로 검색을 실행하는 경우, 프록시 서버(프로토콜 변환 서버)를 통해 응답을 수신한다. 이 때, 복수의 프로토콜 변환 서버들이 동작 하는 경우, 한 장치가 검색 요청에 응답한다면, 이러한 응답이 프로토콜 변환을 실행하기 위하여 복수의 프록시 서버에 의해 각각 변환되어, 검색된 장치로부터의 응답이 각각의 프록시 서버에 의해 복수회 이루어지는 문제점이 있다. 따라서, 검색이 이루어지는 경우, 복수의 프록시 서버가 존재한다면, 복수의 장치들이 존재하는 것처럼 된다.
본 발명은 전술한 문제점들 중 적어도 하나를 해결하기 위하여 이루어진 것으로서, 이하의 수단이 개시된다.
본 발명은, 복수 종류의 프로토콜들이 혼재하는 네트워크 시스템에서 프로토콜 변환 처리를 실행하는 제어 장치로서, 네트워크 상에서 소정의 프로토콜 처리를 실행하는 다른 프로토콜 변환 장치를 검색하기 위한 검색 요청을 상기 네트워크 상에 발행하고, 활성화에 따라 검색 처리를 수행하는 검색 수단; 상기 다른 프로토콜 변환 장치가 상기 검색 수단에 의해 네트워크 상에서 검색되는 경우, 상기 검색된 프로토콜 변환 장치가 프로토콜 변환 처리를 실행할 수 있는지 또는 상기 검색된 프로토콜 변환 장치가 프로토콜 변환 처리를 수행하였는지를 인식하는 인식 수단; 및 상기 인식 수단에 의해, 상기 검색된 프로토콜 변환 장치가 프로토콜 변환 처리를 수행할 수 없거나, 프로토콜 변환 처리를 실행하지 않음이 인식되는 경우, 프로토콜 변환 처리를 활성화시키는 활성화 수단을 포함하는 제어 장치를 개시한다. 또한, 이러한 제어 장치에 적용되는 방법 및 제어 프로그램을 개시한다.
본 발명은, 복수의 프로토콜을 사용하는 장치들을 대상으로 하여 프로토콜 변환 제어를 행하는 제어 장치로서, 제1 프로토콜을 사용하고 있는 장치를 검색하는 검색 수단; 상기 제1 프로토콜에 따라 장치가 통신하도록 제2 프로토콜을 변환시키는 변환 수단; 상기 검색 수단에 의해 검색된 장치가 상기 제1 프로토콜을 지원하는지 여부를 인식하는 인식 수단; 및 상기 인식 수단에 의해 상기 검색 수단에 의해 검색된 장치가 상기 제1 프로토콜을 지원하는 것으로 인식되는 장치에 대하여 제1 프로토콜로의 프로토콜 변환을 실행하지 않도록 상기 변환 수단을 제어하는 제어 수단을 포함하는 제어 장치를 개시한다. 또한, 이러한 제어 장치에 적용될 수 있는 방법 및 제어 프로그램을 개시한다.
첨부된 도면과 함께 이루어지는 이하의 설명으로부터 본 발명의 기타의 특징 및 장점들이 명확해 질 것이며, 그 첨부된 도면 전체에서 동일한 참조 부호는 동일 또는 유사한 부분을 지칭한다.
도 1은 본 발명의 일실시예에 따른 프로토콜 변환 시스템을 구성하는 네트워크 통신 프린터들, 클라이언트, 및 프록시 서버 각각의 기능적 구조를 나타낸 도면.
도 2는 본 발명의 프로토콜 변환 시스템의 프로토콜 변환 처리 방법을 나타낸 전체 플로우차트.
도 3은 본 발명의 프로토콜 변환 시스템의 프로토콜 변환 처리 방법에서 UPnP 수행 프린터의 검색을 위한 처리를 나타낸 플로우차트.
도 4는 "UPnP(niversal Plug and Play Device Architecture) v.1.0"에 명시된 M-SEARCH 디스커버리(discovery) 패킷의 포맷을 나타낸 도면.
도 5는 "Universal Plug and Play Device Architecture v1"에 명시된 M-SEARCH 디스커버리 패킷에 대한 응답 패킷 포맷을 나타낸 도면.
도 6은 본 발명의 프로토콜 변환 시스템의 프로토콜 변환 처리 방법에서 프린터 정보 취득 처리를 나타낸 플로우차트.
도 7은 관리 테이블의 포맷을 나타낸 도면.
도 8은 본 발명의 프로토콜 변환 시스템의 프로토콜 변환 처리 방법에서 프로토콜 변환 처리의 프로세스를 나타낸 플로우차트.
도 9는 본 발명의 일실시예에 따른 프로토콜 변환 시스템을 구성하는 네트워크 통신 프린터, 클라이언트, 프록시 서버의 기능적 구성을 나타낸 도면.
도 10은 본 발명의 프로토콜 변환 시스템의 프로토콜 변환 처리 방법의 플로우차트를 나타낸 도 10A 및 도 10B로 이루어진 도면.
도 11은 본 발명의 프로토콜 변환 시스템의 프로토콜 변환 처리 방법에서 프린터 정보 취득 처리의 플로우차트를 나타낸 도 11A 및 도 11B로 이루어진 도면.
도 12는 본 발명의 프로토콜 변환 시스템의 프로토콜 변환 처리 방법에서 프로토콜 변환 처리의 플로우차트를 나타낸 도 12A 및 도 12B로 이루어진 도면.
도 13은 본 발명의 프로토콜 변환 시스템의 프로토콜 변환 처리 방법에서 Notify 패킷 처리의 프로세스를 나타낸 플로우차트.
도 14는 Notify 상태가 WakeUp 인 패킷 포맷을 나타낸 도면.
도 15는 Notify 응답 패킷 상태가 FULL인 패킷 포맷을 나타낸 도면.
도 16은 본 발명의 일실시예에 따른 프로토콜 변환 시스템을 구성하는 네트워크 지원 프린터, 클라이언트, 및 프록시 서버의 기능적 구성을 나타낸 도면.
도 17은 본 발명의 프로토콜 변환 시스템의 프로토콜 변환 처리 방법을 나타낸 전체 플로우차트.
도 18은 본 발명의 프로토콜 변환 시스템의 프로토콜 변환 처리 방법에서 UPnP 수행 프린터 정보를 취득하는 처리를 나타낸 플로우차트.
도 19는 관리 테이블의 포맷을 나타낸 도면.
도 20은 본 발명의 프로토콜 변환 시스템의 프로토콜 변환 처리 방법에서 프로토콜 변환 처리의 프로세스의 플로우차트를 나타낸 도 20A 및 도 20B로 이루어진 도면.
도 21은 본 발명의 프로토콜 변환 장치에 의해 형성되는 프리젠테이션 문서를 나타낸 도면.
도 22는 본 발명의 프로토콜 변환 장치에 의해 생성되는 프리젠테이션 문서를 나타낸 도면.
도 23은 Notify 응답 패킷 상태가 WORKING인 패킷 포맷을 나타낸 도면.
도 24는 Notify 상태가 FULL인 패킷 포맷을 나타낸 도면.
도 25는 관리 테이블의 포맷을 나타낸 도면.
도 26은 Notify 상태가 ByeBye인 패킷 포맷을 나타낸 도면.
프로토콜 A를 지원하는 (x)개의 장치들과 프로토콜 A 및 B를 모두 지원하는 (y)개의 장치들이 네트워크 상에서 동작하고 있는 상태에서(x 및 y는 모두 1 이상의 정수), 프로토콜 A에서 프로토콜 B로 변환하기 위한 프록시가 활성화되는 경우, 프록시는 프로토콜 A 및 B를 모두 지원하는 장치들에 대하여 프로토콜 A를 사용하여 프로토콜 B로의 변환을 실행한다. 따라서, 프록시의 개입으로 인하여, 프로토콜 B를 사용하는 네트워크 클라이언트에 대하여, 프로토콜 B 대응의 장치들이 (x+2y)개 동작하고 있는 것 처럼, 즉, 프로토콜 A 및 프로토콜 B 모두를 지원하는 동일한 장치들임에도 불구하고, 실제 장치수의 두 배의 장치들이 네트워크상에서 동작하고 있는 것처럼 처리가 수행될 가능성이 있다. 프록시의 개입은 장치를 사용하는 사용자에게 혼동을 일으키는 한 요인이 될 수 있는 문제점이 있다.
이하, 첨부된 도면을 참조하여 본 발명의 바람직한 실시예를 일례로 상세하게 설명한다. 본 실시예에 개시된 프로토콜, 버젼, 어드레스, 수치값 등은 달리 지정하지 않는 한 본 발명의 범위를 제한하는 것은 아니다.
이하, 본 발명에 따른 서비스 제공 시스템의 일실시예로서 프로토콜 변환 시스템을 설명한다. 도 1은 본 발명의 일실시예에 따른 인쇄 시스템의 구성을 나타낸 블록도이다.
Microsoft 사의 "Windows(등록 상표)", Apple 컴퓨터사의 MacOS와 같은 범용 운영체제, 및 운영체제에서 실행될 수 있는 범용 어플리케이션들이 클라이언트(100)에 장착되었다. 본 실시예에 도시된 "Windows(등록 상표)" OS(1)의 경우, 네트워크 상에서 장치들의 발견(discovery), 제어, 상태의 취득, 등은 "XML(eXtensible Markup Language)/SOAP(Simple Object Access Protocol)"를 사용하는 "Universal Plug and Play(UPnP)" 프로토콜(2)을 사용하여 실현된다. 예컨대, 어플리케이션 소프트웨어로서 워드프로세서(4)로 만들어진 문서가 프린터 드라이버(3)에 의해 인쇄가능한 데이터로 변환된 후, UPnP 프로토콜(2)에 의해 검색 및 발견된 UPnP 프로토콜 대응 프린터에 대하여 UPnP 프로토콜(2)을 사용하여 인쇄 작업(print job)이 발행된다.
네트워크 대응 장치, 즉, 본 실시예에 있어서의 네트워크 지원 프린터(200)는 통신 기능으로서 TCP/UDP/IP 프로토콜 스택(5)을 갖는다. 프로토콜 스택에는 SNMP(Simple Network Management Protocol) 처리부(6)가 제공된다. 프로토콜 스택(5)에는, 인쇄 프로토콜 처리부(7)가 구비되어, 클라이언트에 의해 발행된 인쇄 요청을 분석하고, 인쇄 요청을 프린터 컨트롤러(8)에 송신하는 기능을 갖는다.
이 프린터는 UPnP 프로토콜 처리부를 갖지 않으며, 이 프린터 단독으로는 클라이언트(100)에 의해 발행되는 UPnP 프로토콜을 사용하는 장치 검색 요청 및 UPnP 인쇄 작업 요청에 응답할 수는 없다.
또 다른 네트워크 지원 장치, 즉, 본 실시예에서의 네트워크 지원 프린터(400)는 통신 기능으로서 TCP/UDP/IP 프로토콜 스택(17)을 갖는다. 이러한 프로토콜 스택에는 HTTP(19)가 제공되어, HTTP 요청의 분석과 응답 처리가 실행된다.
네트워크 프린터(200)와 마찬가지의 방식으로, 프로토콜 스택(17)에는 SNMP 처리부(18)가 제공된다.
HTTP(19)의 상부층에는 SOAP 처리부(20)가 제공되며, 또한 UPnP 처리부(21) 가 제공된다. 네트워크 지원 프린터(400)에서, UPnP 포럼에서 지정된 Print Basic 서비스가 구현되었다. UPnP 프로토콜 처리부는 이러한 서비스에 의해 정의되는 속성 정보와 인쇄 작업들을 분석하고, 프린터 컨트롤러(22)에 인쇄 요청을 송신하는 기능을 갖는다.
또한, 프록시 서버(300)도 마찬가지로 통신 기능으로서 TCP/UDP/IP 프로토콜 스택(9)을 갖는다. 이러한 프로토콜 스택에는 HTTP(10)가 제공되어, HTTP 요청에 대한 분석과 응답 처리가 실행된다.
프로토콜 스택(9)에는 SNMP 처리부(11)가 제공된다. 이 프로토콜에 의해 UPnP 프로토콜 처리부를 갖지 않는 네트워크 지원 프린터(200)의 검색 및 정보의 취득이 실행된다.
프로토콜 스택(9)에 인쇄 프로토콜 처리부(12)가 탑재되어, UPnP 프로토콜 처리부를 갖지 않는 네트워크 지원 프린터(200)의 인쇄 작업의 발행이 인쇄 프로토콜 처리부(12)에서 실행된다.
HTTP(10)의 상부층에는 SOAP 처리부(13)가 제공된다. UPnP 처리부(14)와 프로토콜 변환 처리부(16)는 SOAP 처리부(13)를 통해, 클라이언트(100) 및 다른 프록시 서버가 네트워크 상에 존재하는 경우, XML(eXtensible Markup Language)에 의해 기술되는 데이터의 양방향 통신을 각각 실현한다.
프로토콜 변환 처리부(16)는 SNMP 처리부(11), SOAP 처리부(13), UPnP 처리부(14), 인쇄 프로토콜 처리부(12), 및 기록 장치 제어부(15)의 상부층에 위치하여 이하의 처리를 실행한다. 즉, UPnP 프로토콜에서 사용되는 다양한 XML 문서들이 생성된 후, SNMP 처리부(11)를 통해 취득된 네트워크 지원 프린터의 정보가 기록 장치 제어부(15)에 의해 제어되는 기록 장치에 기록되거나, UPnP 프로토콜로부터의 요청이 있는 경우, 해당 관리 테이블에 기록된 XML 다큐먼트가 기록 장치 제어부(15)를 통해 판독되어, UPnP 프로토콜 처리부(14) 등에 전송된다.
UPnP 프로토콜에 의해 인쇄 작업에 대한 요청이 수신되는 경우, 프로토콜 변환 처리부(16)는 SOAP 처리부(13)를 통해 작업 명령과 작업 속성 정보를 취득하여, 그 내용을 출력이 지정되어 있는 프린터에 의해 지원되는 인쇄 프로토콜로 변환한 후, 인쇄 프로토콜 처리부(12)를 통해 지정 프린터에 전송한다.
프로토콜 변환 처리부(16)는 프록시 서버(300)에 의해 관리되는 관리 테이블을 제어부(15)를 통해 기록 장치 제어부(15)에 의해 제어되는 기록 장치로 판독 및 기입하는 처리들을 실행한다. 마찬가지로, 프로토콜 변환 처리부(16)가 네트워크 상에 존재하는 또 다른 프록시 서버에 의해 관리되는 관리 테이블을 취득하는 경우, 이를 제어부(15)를 통해 기록 장치 제어부(15)에 의해 제어되는 기록 장치에 판독 및 기입하는 처리들을 실행한다.
이하, 도 2의 플로우차트를 참조하여 본 시스템의 제어 흐름을 설명한다.
프록시 서버(300)의 프로토콜 변환 처리부(16)가 활성화 된 후, 기록 장치 제어부(15)를 통해, 프로토콜 변환 처리를 실행한 네트워크 장치의 정보가 기록된 관리 테이블 내의 내용을 클리어시킨다(단계 2-1). 이하의 처리들에서 관리 테이블의 세부 사항을 기술한다.
이어서, 클라이언트가 네트워크에 참여하여 서비스를 시작하는 때에, 이 네트워크 상에 존재하는 UPnP 대응 프린터가 검색된다(단계 2-2). 이하, 도 3을 참조하여 단계 2-2를 설명한다. 도 3의 플로우차트의 단계 3-1에 도시된 바와 같이, UPnP 장치 아키텍쳐 v1.0에 지정된 도 4에 도시된 포맷의 HTTPM-SEARCH 패킷이 멀티캐스트 어드레스 239.255.255.250 및 포트번호 1900으로 발행된다.
M-SEARCH 패킷이 발행된 후 소정의 시간 내에, 예컨대, 본 실시예에서 30초 내에 응답이 있다면, 프록시 서버(300)의 프로토콜 변환 처리부(16)는 모든 응답들에 응답하여 응답 패킷의 분석을 실행한다.
도 5는 네트워크 장치의 일례로서 프린터로부터의 응답 패킷의 포맷을 나타낸다. 프록시 서버(300)의 프로토콜 변환 처리부(16)는 패킷에 나타난 네트워크 프린터의 URL을 제어부(15)를 통해 기록 장치 제어부(15)에 의해 제어되는 기록 장치에 기록한다. 수신된 모든 응답 패킷들에 대하여 이러한 처리가 실행되어, 프록시 서버(300)는 네트워크 상에 존재하는 모든 UPnP 대응 프린터들의 URL을 기록한다(단계 3-2).
전술한 처리의 종료 후에, 또는 단계 3-3에서 아무런 응답이 없는 경우, 프록시 서버(300)의 프로토콜 변환 처리부(16)는 UPnP 검색 처리를 종료하고, 단계 2-3으로 진행하여, 프린터 정보의 취득을 시작한다.
도 5에서는 URL로서 "123.123.123.123"이 나타나 있다. 이 URL은 네트워크 장치의 식별 정보의 바람직한 일례이다. ST는 서비스 타입을 지칭한다.
도 6의 플로우차트는 프린터 정보의 취득을 제어하는 흐름을 나타낸다. 프록시 서버(300)의 프로토콜 변환 처리부(16)는, 네트워크 상에 존재하는 프린터들 의 프린터 정보를 취득하기 위하여, SNMP 처리부(11)로부터 다음의 MIB 객체에 SNMP Get 요청을 브로드캐스트 한다(단계 6-1).
PrinterMakerAndModel: 프린터 배포업체/모델명
PrinterName: 프린터 명
PrinterLocation: 프린터 설정 위치
IPAddress: 프린터 IP 어드레스
MACAddrerss: 프린터 MAC 어드레스
SupportedPDL: 지원되는 페이지 기술 언어
SupportedPrintProtocol: 지원되는 인쇄 프로토콜
SNMP Get 요청을 수신한 네트워크 지원 프린터들(200 및 400)은, SNMP 처리부(6)내의 각각의 객체에 해당하는 정보를 생성한 후, SNMP 응답으로서의 응답을 유니캐스트 방식으로 프록시 서버(300)에 전송한다.
단계 6-1-1에서 응답이 수신되었는지 여부가 판별된다. 단계 6-1-1에서 응답이 수신된 것으로 판정되면, 단계 6-2로 진행한다. 아무런 응답이 없는 것으로 판정되면, 단계 6-9로 진행한다. 각 네트워크 지원 프린터로부터의 응답을 수신한 프록시 서버(300) 내의 프로토콜 변환 처리부(16)는, 각 응답의 내용을 이미 기록 장치에 등록된 관리 테이블의 내용과 비교하여(단계 6-2), 그 프린터가 프로토콜 변환을 이미 실행한 프린터인지 여부를 판별한다(단계 6-3).
단계 6-3에서 그 프린터가 프로토콜 변환을 실행하지 않은 프린터인 것으로 판정되면, 즉, 새롭게 발견된 프린터인 것으로 판정되면, 프록시 서버(300)의 프로토콜 변환 처리부(16)는 이어서 기록 장치에 이미 기록된 UPnP 대응 프린터의 URL과 이 URL을 비교함으로써 프린터가 UPnP 대응 프린터인지, 즉, SSDP에 대응하는 프린터인지 여부를 판별한다(단계 6-4). 네트워크 상에 연결된 장치들을 발견하여 기능을 취득하기 위하여 SSDP(Simple Service Discover Protocol)가 사용된다. SSDP는 UPnP를 구성하는 기본적인 부분으로서, IETF로부터 표준 명세사항이 발행되었다.
네임 솔루션(name solution)과 마찬가지의 방식으로, 장치들을 발견하는데 IP 브로드캐스트가 사용된다. 브로드캐스트 방식으로 조회(inquiry)가 전송되는 경우, 조건을 충족하는 각각의 장치는 IP 어드레스와 호스트 네임을 조회하는 소스측으로 자주적으로 전송한다. 이 때, 구체적으로 어떠한 기능을 장치가 갖는지를 나타내는 정보 등의 장치에 고유한 정보가 교환된다.
이러한 경우, SNMP Get 요청에 대한 응답으로서 취득한 프린터 IP 어드레스가 기록 장치에 기록된 URL과 일치하는 경우(단계 6-4), 새롭게 발견된 프린터는 UPnP 대응 프린터인 것으로 판정된다. 이 프린터에는 프로토콜 변환이 실행되지 않는다.
단계 6-4에서 프린터가 UPnP 대응 프린터가 아니라고 판정되는 경우, 프록시 서버(300)의 프로토콜 변환 처리부(16)는 SNMP Get 요청에 대한 응답으로서 취득한 정보를 관리 테이블에 추가하여 갱신하고, 이를 기록 장치 제어부(15)를 통해 기록 장치에 기록한다(단계 6-6).
이어서, 관리 테이블에 새롭게 등록된 프린터에 대하여, 취득된 정보에 기초 하여 "UPnP 장치 아키텍쳐 v1.0"에 명시된 "장치 기술 문서(device description document)"가 생성되어, 기록 장치 제어부(15)를 통해 기록 장치에 기록된다(단계 6-7). 단계 6-8에서, "UPnP 장치 아키텍쳐 v1.0"에 명시된 통지 수단에 기초하여, 관리 테이블에 기록된 모든 프린터들에 대한 Notify 패킷이 UPnP 프로토콜 처리부(14)에 의해 발행되어, 그 프린터들이 네트워크 상에서 서비스를 실행하고 있음을 통지한다.
프록시 서버에 의해 발행된 SNMP Get 요청에 대하여 아무런 응답이 취득되지 않으면(단계 6-1-1에서 "아니오"), 단계 6-9로 진행한다. 단계 6-9에서, 관리 테이블을 검색하여, 등록된 프린터를 확인한다.
프록시 서버(300)에 의해 발행된 SNMP Get 요청에 대하여 응답이 취득되면(단계 6-1-1에서 "예"), 단계 6-2로 진행한다. 프록시 서버(300)에 등록된 프린터 장치들은 응답한 프린터의 정보와 비교된다. 단계 6-1에서 SNMP 패킷이 발행된 타겟으로서의 프린터의 IP 어드레스, URL 정보 등과 관리 테이블을 비교하여, 검색된 프린터가 관리 테이블에 존재하는지 여부를 확인한다. 처리 루틴은 단계 6-3으로 진행한다.
등록된 프린터가 자신의 관리 테이블에 이미 존재하고 있을지라도, 이 프린터로부터 아무런 응답이 취득되지 않으면(단계 6-9-1에서 "예"), 프록시 서버(300)의 프로토콜 변환 처리부(16)는 관리 테이블로부터 이러한 프린터의 정보를 삭제하고 이를 갱신한 후(단계 6-10), "장치 기술 문서"를 삭제한다(단계 6-11).
등록된 프린터가 이미 자신의 관리 테이블에 존재하였을지라도, 이 프린터로부터 응답이 취득되면(단계 6-9-1에서 "아니오"), 프린터 정보 취득 처리가 종료되고, 처리 루틴은 다음의 처리로 진행한다.
프록시 서버(300)의 프로토콜 변환 처리부(16)가 갱신된 관리 테이블을 기록 장치 제어부(15)를 통해 기록 장치에 기록한 후에는, 프로토콜 변환 처리부가 "UPnP 장치 아키텍쳐 v1.0"에 명시된 통지 수단에 기초하여 UPnP 처리부(14)로부터 관리 테이블에서 삭제된 모든 프린터들에 대하여 Notify 패킷을 발행하고, 그 프린터들은 네트워크 상에서 서비스를 중단하였음을 통지한다(단계 6-12).
본 발명에 있어서, 도 7에 도시된 바와 같이, 앞서 언급한 취득된 SNMP 객체의 내용이 XML로 기술되었던 텍스트 파일의 포맷으로 관리 테이블이 관리된다. 전술한 프린터 정보 취득 처리후에는, 프록시 서버(300)의 프로토콜 변환 처리부(16)가 프로토콜 변환 처리를 시작한다(단계 2-4). 도 8의 플로우차트는 프로토콜 변환 처리의 흐름을 나타낸다.
프록시 서버(300)의 프로토콜 변환 처리부(16)는, 클라이언트에 의해 발행된 "UPnP 장치 아키텍쳐 v1.0"에 규정된 장치 검색 프로토콜 SSDP 패킷의 수신 통지가 UPnP 프로토콜 처리부(14)로부터 수신되었는지 판별한다. 수신되었던 것으로 판정되면(단계 8-1에서 "예"), 프록시 서버(300)의 프로토콜 변환 처리부(16)에 의해 관리되는 관리 테이블이 기록 장치 제어부(15)를 통해 검색된다. SSDP 패킷의 검색 조건에 해당하는 프린터의 "장치 기술 문서"가 기록된 URL이 SSDP 응답으로서 UPnP 프로토콜 처리부(14)를 통해 반송되고(단계 8-2), 단계 8-3으로 진행한다.
이러한 URL을 취득한 클라이언트 장치로부터의 HTTPGet 요청에 의해 "장치 기술 문서"를 취득하고자 하는 요청이 UPnP 프르토콜 처리부(14)를 통해 수신되었는지 여부가 판별된다. 취득 요청이 수신된 것으로 판정되는 경우(단계 8-3에서 "예"), 프록시 서버(300)의 프로토콜 변환 처리부(16)에 의해 관리되는 관리 테이블이 기록 장치 제어부(15)를 통해 검색된다. 지정된 URL에 기록된 "장치 기술 문서"가 판독된 후, UPnP 프로토콜 처리부(14)를 통해 반송된다(단계 8-4).
"UPnP 장치 아키텍쳐 v1.0"에 명시된 제어 수단에 기초하여 "장치 기술 문서"를 획득한 클라이언트 장치로부터 인쇄 작업이 발행된다. 이 경우, XML 포맷으로 작업 명령과 작업 속성이 기술되기 때문에, 프록시 서버(300)의 프로토콜 변환 처리부(16)가 UPnP 프로토콜 처리부(14)를 통해 인쇄 작업을 수신하였다면(단계 8-5에서 "예"), 프로토콜 변환 처리부(16)는 SOAP 처리부에 있어서의 작업 속성과 명령을 분석한다. 이어서, 기록 장치 제어부(15)를 통해 출력이 지정된 프린터에 해당하는 관리 테이블 정보로부터 지원되는 인쇄 프로토콜 및 IP 어드레스들이 취득된다. 수신된 명령과 속성 정보는 인쇄 프로토콜로 변환된다(단계 8-6). 그 후, 변환 후의 정보가 출력이 지정된 프린터의 IP 어드레스로 전송된다(단계 8-7).
이어서, 인쇄 작업을 발행한 클라이언트가 "UPnP 장치 아키텍쳐 v1.0"에 명시된 제어 수단에 기초하여 작업 데이터, 이 경우에는 PDL을 HTTPPost 명령을 사용하여 프록시 서버(300)에 전송한다. 작업 데이터를 수신한 프록시 서버(300)의 프로토콜 변환 처리부(16)는, 수신된 작업 데이터를 전술한 단계와 마찬가지의 방법으로 지정된 프린터에 의해 지원되는 프린터 프로토콜로 변환하고, 작업 데이터를 앞서 취득된 프린터 IP 어드레스에 전송한다(단계 8-9).
UPnP 작업 데이터가 수신되었는지 여부가 판별된다(단계 8-8-1).
클라이언트로부터의 작업 데이터의 수신이 지정된 시간 내에, 예컨대, 본 실시예에 있어서 30 초 이내에 시작되는지 여부가 판별된다. 수신이 시작되지 않은 것으로 판정되면(단계 8-8-2에서 "예"), 작업이 포기된다(단계 8-10). 수신이 시작되면, 작업이 포기되지 않고, 장치는 단계 8-8-1에서 수신을 대기한다(단계 8-8-2에서 "아니오").
작업 명령, 작업 속성, 및 작업 데이터를 수신한 프린터는, 프린터 제어부에서 작업 명령과 작업 속성을 분석한 후, 인쇄 작업을 프린터 컨트롤러에 전송하여 인쇄를 실행한다.
본 발명의 프록시 서버(300)는 단계 2-2 내지 2-4의 전술한 처리들을 반복적으로 실행하여, 네트워크 프린터의 운용 상황을 주기적으로 갱신하고, 갱신된 정보에 기초하여 프로토콜 변환 처리를 실행한다.
프록시 서버(300)의 프로토콜 변환 처리부(16)가 단계 2-5의 전원 차단으로 인하여 프로토콜 변환 처리를 중단하는 경우, 프로토콜 변환 처리부(16)는 "UPnP 장치 아키텍쳐 v1.0"에 명시된 통지 수단에 기초하여 기록 장치 제어부(15)를 통해 모든 관리 테이블들을 판독하고, UPnP 프로토콜 처리부(14)를 통해 관리 테이블내에 기록된 모든 프린터들에 대하여 Notify 패킷을 발행하여, 네트워크 상에서 그러한 프린터들은 서비스를 중단하였음을 통지한다(단계 2-6). 단계 2-5에서 프로토콜 변환 처리가 중단되지 않은 경우, 처리 루틴은 단계 2-2로 복귀된다.
전술한 바와 같이, 타겟으로서 복수의 프로토콜을 사용하는 장치들에 대한 프로토콜 변환 제어를 하게 하는 제어 장치의 예로서, 프록시 서버(300)에서는, 제1 프로토콜의 예로서 UPnP의 SSDP를 사용하는 장치를 검색하는 검색 수단(도 3의 3-1 내지 3-2); 제2 프로토콜의 예로서 SNMP의 검색 패킷을 SSDP에 따라 장치가 통신하도록 프로토콜 변환하는 변환 수단(예컨대, 2-4 및 도 8의 처리); 검색 수단에 의해 검색된 장치가 SSDP에 대응하는지 여부를 인식하는 인식 수단(단계 6-3); 및 검색 수단에 의해 검색된 장치가 SSDP에 대응하는 것으로 인식 수단에 의해 인식된 장치에 대하여 SSDP로의 프로토콜 변환을 실행하지 않도록 변환 수단을 제어하는 제어 수단(단계 6-4)을 포함한다.
프린터가 네트워크 장치인 실시예가 설명되었지만, 네트워크 지원 장치는 하드 디스크 등의 저장 장치, 스캐너, 복사기, 이들의 복합 기능을 갖는 장치 중 임의의 것일 수 있다. 이러한 장치는, 통신 기능을 통해 속성 정보가 교환 될 수 있고, 작업이 프록시 서버와 송수신 될 수 있는 한 그러한 장치들 중 임의의 것으로 실현될 수 있다. 이러한 경우, 프록시 서버와 네트워크 지원 장치 간의 통신 프로토콜은 표준화된 프로토콜, 범용 프로토콜, 및 배포업체에 고유한 프로토콜 중 임의의 것에 의해 마찬가지로 구현될 수 있다.
일례로서 네트워크 지원 장치에 대하여 본 실시예를 나타내었지만, USB, IEEE1394, 병렬 연결, 등에 따른 로컬 연결에 의해 이루어지는 통신으로 구현될 수도 있다.
본 실시예에서 프록시 서버는 네트워크 상에서 독립적인 형태로 존재하지만, 이러한 프록시 서버의 기능은 네트워크 지원 장치 내에서 물리적으로 또는 논리적으로 구현되는 경우에도 실현될 수 있다.
본 실시예에서 프록시 서버에 의해 제공되는 프로토콜 변환의 조합으로서, Microsoft사의 UPnP, 네트워크 지원 프린터에서 구현되는 SNMP, 및 프린터 프로토콜의 예가 나타내어져 있지만, Apple Computer에서 제안된 "Rendezvous", JBMIA에 의해 제안된 "BMLinkS", 등의 프로토콜의 경우에도 프로토콜 변환이 실현될 수 있다. 장치들의 검색 및 제어가 통합된 프로토콜의 경우 뿐만 아니라, "Service Location Protocol(SLP)", "Multicast DNS Service Discovery", 등과 같이 장치에 의해 제공되는 서비스들을 검색하는 프로토콜, 및 "Web Service"와 같이, XML/SOAP에 기초한 "Remote Procedure Call(RPC)" 포맷에 의한 장치 제어를 종래의 제어 프로토콜로 변환하기 위하여 프로토콜 변환이 또한 사용될 수 있다.
프록시 서버들 사이의 정보 통지 프로토콜로서 HTTP/TCP/UDP/IP 프로토콜이 사용되는 예에 대하여 실시예를 나타내었지만, 본 발명은 전달 수단에 의존하지 않고, 양방향 통신을 할 수 있는 한, 또 다른 범용 프로토콜 또는 독자의 프로토콜을 사용하는 경우에도 실현될 수 있다.
본 실시예에 의해 해결되어야 할 또 다른 측면으로서, 각각 동일한 프로토콜에 대응하는 N 개의 프록시, 예컨대, 각각 프로토콜 A를 프로토콜 B로 변환하기 위한 N 개의 프록시가 네트워크 상에서 동작하는 경우, 하나의 네트워크 장치가 N 개의 프록시에 의해 프록시 제어되어, 프로토콜 B를 사용하는 네트워크 클라이언트에 대하여, 동일한 네트워크 장치 임에도 불구하고, 네트워크 상에서 상이한 N 개의 네트워크 장치들이 동작하는 것처럼 처리가 실행되어, 이를 사용하는 사용자에게 혼동을 유발할 수 있는 가능성이 있다는 문제점이 있다.
일반적으로, 프록시가 프로토콜의 프록시 처리를 실행할 수 있는 장치들의 수에는 제한이 있다. 예컨대, 프로토콜 A를 프로토콜 B로 변환하기 위하여 두 개의 프록시(1 및 2)가 네트워크 상에서 동작하는 상태에서, 프록시 1의 프록시 변환 처리를 수행하는 장치의 수가 M이고, 프록시 2의 프록시 변환 처리를 수행하는 장치들의 수가 N이라면(M>N), 프록시 1과 프록시 2가 동일한 네트워크 장치에 대하여 서로 프로토콜 변환 처리를 실행할 가능성이 있다. 두 개의 프록시에 의해 (M+N)개의 네트워크 장치들의 프로토콜 변환 처리가 실행될 수 있다는 사실에도 불구하고, M 개의 네트워크 장치들까지만 처리가 실행될 수 있는 경우가 있다. 이러한 경우, 두 개의 프록시는 N개의 네트워크 장치들에 대하여 중복된 처리를 실행하며, 전술한 바와 같이, 중복된 처리는 마치 2xN 개의 상이한 네트워크 장치들이 존재하는 것처럼 처리된다.
이하, 도면을 참조하여 본 발명의 바람직한 실시예를 설명한다. 본 실시예에 개시되는 프로토콜들, 버젼들, 어드레스들, 수치값들, 등은 달리 지정하지 않는 않는 한 본 발명의 범주를 제한하지 않는다.
이하, 본 발명에 따른 서비스 제공 시스템의 일실시예로서 프로토콜 변환 시스템을 설명한다. 도 9는 본 발명의 일실시예에 따른 인쇄 시스템을 나타낸 블록도이다.
Microsoft사의 "Windows(등록 상표)", Apple Computer의 "Mac OS(등록 상표)" 등의 범용 운용체제 및 운영 체제에서 실행될 수 있는 범용 어플리케이션들이 클라이언트(9100)에 장착되어 있다. 본 실시예에서 나타낸 OS(901)의 경우, 네트워크 상의 장치들의 발견, 제어, 및 상태 취득, 등이 XML/SOAP를 사용하는 UPnP 프로토콜(902)을 사용하여 구현된다. 예컨대, 어플리케이션 소프트웨어로서 워드 프로세서(904)에 의해 형성된 문서는 프린터 드라이버(903)에 의해 인쇄 가능한 데이터로 변환되며, UPnP 프로토콜(902)를 사용하여 UPnP 프로토콜(902)에 의해 검색 및 발견된 UPnP 프로토콜 해당 프린터에 인쇄 작업이 발행된다.
네트워크 통신 장치, 즉 본 실시예에서는 네트워크 지원 프린터(9200)는 통신 기능으로 TCP/UDP/IP 프로토콜 스택(905)을 갖는다. 프로토콜 스택에 SNMP 처리부(906)가 구비된다. 프로토콜 스택(905)에는 인쇄 프로토콜 처리부(907)가 구비되어, 클라이언트에 의해 발행된 인쇄 요청을 분석하고, 인쇄 요청을 프린터 컨트롤러(908)에 송신하는 기능을 갖는다.
프린터는 UPnP 프로토콜 처리부를 갖지 않으며, UPnP 프로토콜을 사용하는 장치 검색 요청과 클라이언트(9100)에 의해 발행되는 UPnP 인쇄 작업 요청에 대하여 단독으로 응답할 수 없다.
프록시 서버(9300) 또한 마찬가지로 통신 기능으로서 TCP/UDP/IP 프로토콜 스택(909)을 갖는다. 프로토콜 스택에는 HTTP 처리부(9010)가 제공되어, HTTP 요청에 대한 분석 및 응답 처리가 실행된다.
프로토콜 스택(909)에 SNMP 처리부(9011)가 제공된다. UPnP 프로토콜 처리 부를 갖지 않는 네트워크 지원 프린터(200)에 대한 검색과 정보의 취득이 이러한 프로토콜에 의해 실행된다.
프로토콜 스택(909)에 인쇄 프로토콜 처리부(9012)가 제공되며, UPnP 프로토콜 처리부를 갖지 않는 네트워크 지원 프린터(9200)에 대한 인쇄 작업의 발행은 인쇄 프로토콜 처리부(9012)에 의해 실행된다.
HTTP(9010)의 상부층에는 SOAP 처리부(9013)가 제공된다. UPnP 프로토콜 처리부(9014)와 프로토콜 변환 처리부(9016)는 SOAP 처리부(9013)를 통해, 각각 클라이언트(9100) 및 존재하는 경우 네트워크 상의 또 다른 프록시 서버와 XML로 기술된 데이터의 양방향 통신을 구현한다.
프로토콜 변환 처리부(9016)는 SNMP 처리부(9011)의 상부층, SOAP 처리부(9013), UPnP 처리부(9014), 인쇄 프로토콜 처리부(9012), 및 기록 장치 제어부(9015)에 위치하여, 이하의 처리들을 실행한다. 즉, UPnP 프로토콜에서 사용되는 각종 XML 문서들이 작성된 후, SNMP 처리부(9011)를 통해 취득된 네트워크 지원 프린터의 정보가 기록 장치 제어부(9015)에 의해 제어되는 기록 장치에 기록되거나, 또는 UPnP 프로토콜로부터의 요청이 있는 경우, 해당 관리 테이블에 기록된 XML 문서가 기록 장치 제어부(9015)를 통해 판독되어, UPnP 프로토콜 처리부(9014) 등에 전송된다.
UPnP에 의한 인쇄 작업에 대한 요청이 수신되는 경우, 프로토콜 변환 처리부(9016)는 SOAP 처리부(9013)을 통해 작업 명령과 작업 속성 정보를 취득하고, 그 내용을 출력이 지정되어 있는 프린터에 의해 지원되는 인쇄 프로토콜로 변환한 후, 그 작업을 지정된 프린터로 인쇄 프로토콜 처리부(9012)를 통해 전송한다.
프로토콜 변환 처리부(9016)는 SOAP 처리부(9013)를 통해 또 다른 프록시 서버로부터 발행된 Notify 요청의 세부 내용을 취득하여, 그 내용에 따른 처리를 실행한다.
프로토콜 변환 처리부(9016)는 프록시 서버(9300)에 의해 관리되는 관리 테이블을 제어부(9015)를 통해 기록 장치 제어부(9015)에 의해 제어되는 기록 장치에 기입 및 판독하기 위한 처리들을 실행한다.
마찬가지로, 프로토콜 변환 처리부(9016)는 네트워크 상에 존재하는 또 다른 프록시 서버에 의해 관리되는 관리 테이블을 취득하는 경우, 이를 제어부(9015)를 통해 기록 장치 제어부(9015)에 의해 제어되는 기록 장치에 판독 및 기입하기 위한 처리들을 실행한다.
이하, 도 10A 및 도 10B를 참조하여, 본 시스템의 제어의 흐름을 상세하게 설명한다. 도 10A 및 도 10B는, 프로토콜 변환을 수행하기 위한 프록시 서버의 중재 처리를 나타낸 플로우차트이다. 도 13은 활성화 된 프록시 서버가 활성화 직후에 프록시 서버로부터 Notify 패킷을 수신한 경우의 처리를 나타낸 플로우차트이다. 플루우차트에 도시된 처리에 의해, 작업 모드인 프록시 서버의 수가 네트워크 상에서 하나가 되는 것을 보장하도록 프록시 서버 각각이 제어된다. 본 실시예에서, 작업 모드인 프록시 서버들만이 새롭게 추가된 장치의 프로토콜 처리를 새롭게 수용한다. 따라서, 복수의 서버들이 네트워크 상에 랜덤하게 존재하고, 아무런 순서없이 프로토콜 변환 처리를 수행하는 상황을 방지할 수 있다.
프록시 서버가 활성화되는 때에, 도 10A 및 도 10b의 처리 루틴이 시작된다. 이 처리 루틴에 따르면, 새롭게 활성화되는 프록시 서버(9300)는 네트워크 상에서 또 다른 프록시 서버(도시 생략)가 이미 활성화되었는지 여부를 판별한다.
프록시 서버(9300)의 프로토콜 변환 처리부(9016)는 활성화 후에 기록 장치 제어부(9015)를 제어하여, 프로토콜 변환 처리를 이미 수행한 네트워크 장치의 정보를 기록한 관리 테이블의 내용을 클리어시키고 초기화시킨다(단계 10-1). 이하의 처리 단계에서 관리 테이블의 세부 내용을 설명한다. 이어서, 네트워크에 클라이언트가 참여하여 서비스를 개시하는 경우, 이 네트워크 상에 존재하는 다른 프록시 서버들로 Notify 패킷이 발행된다(단계 10-2).
이 때, 도 14에 도시된 포맷에서 HTTPNotify 요청은 멀티캐스트 어드레스 239.255.255.250 및 포트 번호 1900으로 HTTP 패킷으로서 발행된다.
본 실시예에서, 프록시 서버의 상태 정보, 프록시 서버에 의해 지원되는 프로토콜 변환 처리의 명칭, 프록시 서버의 URL, 물리 어드레스, 및 관리 테이블의 저장 목적지 URL이 XML 포맷으로 HTTPNotify 요청의 엔티티 바디(entity body)에 기재되어 통지된다.
도면에 있어서,
<status>: 프록시 서버의 동작 상태를 나타냄. 활성화 되면, WakeUP이 기재됨.
<protocol>: 프록시 서버에 의해 변환될 수 있는 프로토콜을 나타냄. UPnP, BMLinkS, Rendezvous, 등의 프로토콜 명칭이 기재됨. 본 실시예에서, 일례로서 Microsoft 사의 UPnP가 기재됨.
<ProxyURL>: 프록시 서버의 IP 어드레스가 URL 포맷으로 기재됨.
<ProxyMAC>: 프록시 서버의 물리 어드레스(MAC)가 기재됨.
<TableURL>: 프록시 서버에 의해 관리되는 관리 테이블의 저장 어드레스가 URL 포맷으로 기재됨.
도 13의 플로우차트는 네트워크 상에 이미 존재하는 다른 프록시 서버들이 프록시 서버(9300)로부터 Notify 패킷을 수신한 경우의 제어 흐름을 나타낸다. 프록시 서버(9300) 이외에 프록시 서버들이 네트워크 상에 존재하여, 프로토콜 변환 처리를 이미 수행한 경우에는, HTTP(9010)에서 HTTPNotify 요청(300)이 수신된 후, SOAP 처리부(9013)에서 그 요청의 엔티티 바디(301)의 분석이 수행되고, Notify 패킷의 송신원 측의 프록시 서버에 의한 변환의 타겟으로서의 프로토콜이 Notify 패킷을 수신한 프록시 서버에 의한 변환의 타겟으로서의 프로토콜과 일치하는지 단계 13-1에서 판별된다.
SOAP 처리부(9013)는 <protocol>의 내용을 체크한다. 단계 13-1에서 해당 프로토콜의 명칭이 자체에 제공되는 프로토콜 변환 처리와 일치하지 않는 것으로 판정되는 경우, SOAP 처리부(9013)는 Notify 요청을 무시한다.
단계 13-1에서 해당 프로토콜의 명칭이 자체에서 제공되는 프로토콜 변환 처리와 일치하는 것으로 판정되는 경우, 단계 13-3으로 진행한다. SOAP 처리부(9013)는 <status> 태그의 내용을 체크하여, 그 성분이 WakeUP 인지 여부를 단계 13-3에서 판별한다.
단계 13-3에서 그 성분이 WakeUP인 것으로 판정되는 경우, 단계 13-4로 진행한다. 프로토콜 변환 처리부(9016)는 기록 장치 제어부(9015)를 통해 관리 테이블을 판독하고, 현재 프로토콜 변환 처리부(9016) 자체에 의해 수행되고 있는 프로토콜 변환 처리의 상태가 (프로토콜 변환 처리가 가능한 장치들의 수) = (프로토콜 변환 처리가 수행중인 장치들의 수) 인지 여부를 판별한다. 단계 13-4에서 서버가 프로토콜 변환 처리가 더 이상 새롭게 제공될 수 없는 상태인 것으로 판정되는 경우, 단계 13-9로 진행한다. 도 15에 도시된 포맷의 HTTP 응답(400)이 유니캐스트 방식으로 HTTPNotify 요청을 발행한 프록시 서버(9300)에 발행된다. 이 때, SOAP 처리부(9013)는 HTTP 응답(400)의 엔티티 바디로서 XML-포맷의 일자의 이하의 정보를 구성하는 것으로 가정하며, 네트워크 인터페이스(도시 생략)는 프록시 서버(9300)의 TCP/UDP/IP 프로토콜 스택을 통해 제어되어, 이러한 데이터가 통지된다. "FULL"은 프록시 서버의 관리 서버가 가득 찬 상태이며, 프록시 서버의 프로토콜 변환 처리의 타겟으로서의 장치들의 수가 최대수에 도달하였음을 지칭한다.
이하, 도 15의 각 레이블(label)을 설명한다.
<status>: 프록시 서버의 작동 상태를 나타내는 레이블임(태그 또는 디스크립터(descriptor)와 같은 정보가 식별될 수 있는 한 사용될 수 있음). 이러한 경우, FULL, 즉 변환 처리가 더 이상 제공되지 않는 상태를 통지하기 위하여 사용됨.
<protocol>: 프록시 서버에 의해 변환 가능한 프로토콜을 나타냄. UPnP, BMLinkS, Rendezvous, 등의 프로토콜 명칭이 기재됨. 본 실시예에서, Microsoft사의 UPnP가 일례로서 기재됨.
<ProxyURL>: 프록시 서버의 IP 어드레스가 URL 포맷으로 기재됨.
<ProxyMAC>: 프록시 서버의 물리 어드레스(MAC)가 기재됨.
<TableURL>: 프록시 서버에 의해 관리되는 관리 테이블의 저장 어드레스가 URL 포맷으로 기재됨.
현재 서버 자체에 의해 수행중인 프로토콜 변환 처리의 상태가, 프로토콜 변환 처리가 가능한 장치 수가 프로토콜 변환 처리가 수행중인 장치 수 보다 크다는 것을 나타내는 경우, 즉, 서버가 프로토콜 변환 처리가 새롭게 제공될 수 있는 상태에 존재하는 경우, 단계 13-5으로 진행한다. 도 23에 나타낸 포맷의 HTTP 응답(400)이 유니캐스트 방식으로 HTTPNotify 요청을 발행한 프록시 서버(9300)에 발행된다. 이 때, HTTP 요청(400)의 엔티티 바디로서 다음의 정보가 XML 포맷으로 기재되어 통지된다.
이 경우,
<status>: 프록시 서버의 작동 상태를 나타냄. 이 경우, WORKING이 통지됨. 즉, 다른 프로토콜 변환 프록시 서버들이 작동할 필요가 없음을 통지함.
<protocol>: 프록시 서버에 의해 변환될 수 있는 프로토콜을 나타냄. UPnP, BMLinkS, Rendezvous 등의 프로토콜 명칭이 기재됨. 본 실시예에서, Microsoft 사의 UPnP가 일례로서 기재됨.
<ProxyURL>: 프록시 서버의 IP 어드레스가 URL 포맷으로 기재됨.
<ProxyMAC>: 프록시 서버의 물리 어드레스(MAC)가 기재됨.
<TableURL>: 프록시 서버에 의해 관리되는 관리 테이블의 저장 어드레스가 URL 포맷으로 기재됨.
단계 13-3에서 그 성분이 WakeUP이 아니라고 판정되는 경우, 단계 13-6으로 진행하여, 프록시 서버가 셧다운 된다는 것을 나타내는 Notify 패킷이 ByeBye 패킷인지 여부가 판별된다. 단계 13-6에서 ByeBye 패킷이 아닌 경우, 처리 루틴이 종료된다. ByeBye 패킷으로 판정되는 경우, 단계 13-7로 진행한다. 단계 13-7에서는, ByeBye 패킷의 송신원 측의 프록시 서버로부터 관리 테이블을 이미 취득하였는지 여부가 판별된다. 이미 취득하였다면, 관리 테이블이 삭제되고, 처리 루틴이 종료된다. 취득하지 않았다면, 처리 루틴이 종료된다.
도 10A 및 도 10B의 플로우차트를 다시 참조하여, 새롭게 활성화 된 프록시 서버(9300)측의 처리들을 설명한다. Notify 패킷이 발행된 후, 소정의 지정된 시간 내에, 예컨대 본 실시예에서 30초 이내에 응답이 있는 경우, 프로토콜 변환 처리부(9016)는 모든 응답에 따라서 응답 패킷의 엔티티 바디의 분석을 실행한다.
SOAP 처리부(9013)의 분석 처리의 결과, 엔티티 바디의 <status> 태그 성분의 기재가 적어도 하나의 장치가 작업중임(WORKING)을 나타내는 상태의 응답이 반송되었는지 여부가 판별된다 (단계 10-4).
도 13과 관련하여 이미 설명한 바와 같이, 외부 프록시 서버로부터 수신된 Notify 패킷은, "Status = FULL" 또는 "Status = WORKING" 이다.
단계 10-4에서 "예(YES)"인 경우, 즉 "Status = WORKING"인 경우, 서버(9300) 자체가 서비스를 시작하지 않더라도, 네트워크 상에서 이미 동작 모드인 프록시 서버에 의해 처리가 실행될 수 있음이 판정된다. 이러한 경우, 프록시 서버 (9300)의 프로토콜 변환 처리부는 수면 모드(sleep mode)로 절환되며(단계 10-5), 또 다른 프록시로부터 Notify 메세지를 수신할 때까지 수면 모드에 있다가, 대기 모드로 진입한다(단계 10-6). 단계 10-6에서 Notify 패킷이 수신된 경우, 그 후에는 프로토콜 변환 처리가 수행되지 않는다. 랜덤 수가 생성되고, 랜덤 수의 값에 해당하는 시간이 경과한 후(단계 10-7), WakeUP 패킷이 다시 다른 프록시 서버에 발행된다(단계 10-2).
SOAP 처리부(9013)의 분석 처리의 결과, 단계 10-3에서 수신하였던 외부 프록시 서버로부터의 응답의 엔티티 바디 내의 <status> 태그의 성분의 기재가 모두 FULL 인 상태를 나타내거나, WORKING의 응답이 없는 것을 나타내는 것으로 SOAP 처리부(9013)에서 판정하는 경우, SOAP 처리부(9013)는 네트워크 상에 현재 작동중인 프록시 서버가 존재할지라도, 작동중인 프록시 서버가 새로운 서비스를 더 이상 제공할 수 없다고 판정한다. 즉, 단계 10-4에서 "status=WORKING"인 다른 프록시 서버로부터 적어도 하나의 응답이 반송된 것으로 판정되었다면, 이는 "status=FULL"임을 의미한다.
이러한 경우, 프록시 서버(9300)의 프로토콜 변환 처리부(9016)는 "status=FULL"의 응답을 전송한 모든 프록시들로부터 관리 테이블을 취득하기 위한 요청을 한다(단계 10-8). 즉, HTTP 처리부(9010)에 의해 HTTPGet 요청 <TableURL> 에 기재된 URL로 발행되어, FULL 상태인 프록시들로부터 관리 테이블을 취득한다.
이어서, 단계 10-10에서 취득이 허용되는지 여부가 판별된다. 취득이 허용되지 않는다면, 단계 10-5로 진행한다. 취득이 허용된다면, 단계 10-9로 진행한 다. 이어서, 취득된 관리 테이블들이 기록 장치 제어부(9015)를 통해 프록시 서버(9300)의 기록 장치에 기록된다(단계 10-9).
도시되어 있지는 않지만, 외부 프록시 서버로부터 아무런 응답이 없다면, 처리 루틴은 아무런 프록시가 존재하지 않는다는 것을 통지하기 위한 오류 처리로 진행할 수 있다.
취득된 관리 테이블에 기록된 프린터 장치는 FULL 상태인 프록시에 의해 프로토콜 변환 처리를 수행하고 있다. 따라서, 테이블에 기록된 프린터 장치에 대하여, 프록시 서버(9300)의 CPU는 프로토콜 변환 처리를 수행하지 않도록 프로토콜 변환 처리부(9016)를 제어한다.
그러므로, 본 발명에 따르면, 복수의 프록시 서버가 중복적으로 동일한 네트워크 통신장치, 본 발명에서는 동일한 네트워크 통신 프린터에 대하여 프로토콜 변환 처리를 수행하는 상황을 방지할 수 있다.
네트워크 상에서 FULL 상태의 취득 허가를 수신한 다른 프록시 서버는, 관리 테이블 취득 요청에 응답하여 WakeUP 상태로 절환한 프록시 서버 자체에 의해 관리되는 관리 테이블만을 전송하도록 구현된다. 복수의 프록시가 존재하는 경우, 그들 중 하나에만 관리 테이블이 전송된다. 관리 테이블의 전송을 일단 수행한 프록시 서버의 CPU는 관리 테이블 취득 요청에 응답하지 않도록 후속하여 제어한다. 도 12A 및 도 12B를 참조하여 이러한 처리를 설명한다.
즉, 본 발명에 따르면, WakeUP 상태로부터 프로토콜 변환 처리로 절환할 수 있는 프록시 서버의 수는 하나로 제한되며, 동시에, WakeUP 상태인 복수의 프록시 서버가 동작가능하게 되는 것이 방지된다.
즉, 도 12A 및 도 12B의 플로우차트의 단계 12-4에서 관리 테이블 전송 요청이 WakeUP 상태로 절환된 프록시 서버로부터 수신되는 경우, 프록시 서버(9300)의 프로토콜 변환 처리부(9016)는 테이블이 잠겨져 있는지 여부를 판별한다. 잠겨져 있지 않다면, 관리 테이블 전송 요청에 응답하여 관리 테이블이 전송되며(단계 12-16), 그 후, 관리 테이블이 잠겨 진다(단계 12-17).
전술한 바와 같이, 테이블을 능동적으로 배포할 수 있는 잠겨지지 않은 프록시 서버들의 수는 장치 당 하나로 제한되도록 제어가 이루어진다.
도 10A 및 도 10B를 참조하면, 관리 테이블이 취득될 수 없다면(단계 10-10), 프록시 서버(9300)의 프로토콜 변환 처리부(9016)는 수면 모드로 절환되며(단계 10-5), 또 다른 프록시로부터 Notify 메세지를 수신할 때까지 계속 수면 모드로 되고, 프로토콜 변환 처리를 실행하지 않는다(단계 10-6).
관리 테이블의 취득이 허용되어, 단계 10-10에서 취득이 완료되면, 프록시 서버(9300)의 프로토콜 변환 처리부(9016)는 단계 10-12에서 프린터 정보를 취득하기 시작한다.
단계 10-3에서, 소정의 시간내에, 예컨대 본 실시예에서 30초 내에, 아무런 응답이 없다면, 프록시 서버(9300)의 프로토콜 변환 처리부(9016)는 단계 10-9로 진행한다.
도 11A 및 도 11B는 프록시 서버(9300)의 프린터 정보를 취득하기 위한 제어에 대한 흐름을 나타낸다. 프록시 서버(9300)의 프로토콜 변환 처리부(9016)는, 네트워크 상에 존재하는 프린터들의 프린터 정보를 취득하기 위하여, SNMP 처리부(9011)부터 이하의 MIB 객체에 대한 패킷 포맷의 SNMP Get 요청을 브로드캐스트 한다(단계 11-1).
PrintMakerAndModel: 프린터 배포업체/모델 명칭
PrinterName: 프린터 명칭
PrinterLocation: 프린터 설정 위치
IPAddress: 프린터 IP 어드레스
MACAddress: 프린터 MAC 어드레스
SupportedPDL: 지원되는 페이지 기술 언어
SupportedPrinterProtocol: 지원되는 인쇄 프로토콜
SNMP Get 요청을 수신한 네트워크 지원 프린터(9200)는 SNMP 처리부(9011)의 각 객체에 해당하는 정보를 생성한 후, 유니캐스트 방식으로 프록시 서버(9300)에 대한 SNMP 응답으로서의 응답을 전송한다.
단계 11-2에서 각 네트워크 통신 프린터로부터 응답이 수신되는 경우, 프록시 서버(9300)의 프로토콜 변환 처리부(9016)는 각 응답의 내용을 기록 장치에 이미 등록되어 있는 관리 테이블의 내용과 비교한다(단계 11-3). 단계 11-2에서 아무런 응답이 수신되지 않으면, 처리 루틴이 종료한다.
이 때, 관리 테이블이 가득차게 되면, 두 종류의 상태가 존재한다. 먼저, 장치에 의해 새롭게 응답이 이루어지는 경우, 이 때 이러한 장치를 포함하는 한편, 처음으로 관리 테이블이 가득 차게 되는 상태가 있다. 두 번째로, 관리 테이블이 이미 가득 차 있고, 또 다른 장치로부터의 응답이 인식되는 상태가 있다. 본 실시예에 있어서, 프록시 서버의 두 번째 FULL 상태는 "status = FULL mode status"로 구별된다.
프로토콜 변환을 이미 수행한 프린터의 존재 여부는, 도 10A 및 도 10B에서 언급한 단계 10-9에서 "status = FULL mode"인 프록시로부터 취득된 관리 테이블을 이미 취득된 모든 관리 테이블들과 비교함으로써 판별된다(단계 11-4).
프로토콜 변환 처리를 수행하지 않은 네트워크 프린터들이 존재하는 것으로 판정되면, 프로토콜 변환 처리를 수행하지 않은 프린터들이 검출되고, 단계 11-8로 진행한다.
단계 11-8에서, 프록시 서버(9300)에 의해 관리되는 관리 테이블이 가득 찬 것으로 판정되면, 즉, 프로토콜 변환 처리를 수행중인 프린터의 수가 프록시 서버(9300)의 프로토콜 변환 처리부(9016)에서 프로토콜 변환 처리를 수행할 수 있는 프린터 장치의 수와 같거나 이미 도달되어 있다면, 단계 11-7로 진행한다.
이어서, 전술한 단계 11-4에서 검출된 장치의 상태를 FULL 모드로 설정하였는지 여부가 판별된다(단계 11-7). 단계 11-7에서 검출된 장치의 상태가 FULL 모드가 아닌 것으로 판별되는 경우, 프록시 서버(9300)의 프로토콜 변환 처리부(9016)는 FULL 모드로 상태를 절환한다(단계 11-5). 그 후, 도 24에 도시된 포맷의 HTTPNotify 요청이 멀티캐스트 어드레스 239.255.255.250 및 포트 번호 1900으로 발행된다(단계 11-6). 이 때, 전술한 도 7에 나타낸 정보가 HTTP 요청의 엔티티 바디로 통지된다. Notify 패킷에 의해서, 네트워크 상에 존재하는 프록시 서버 (9300) 이외의 프록시 서버들은 프록시 서버(9300)가 FULL 상태로 절환되었음을 통지 받는다. 즉, 프로토콜 변환 처리부(9016)가 작동하기 시작한 후에 맨 처음 관리 테이블이 FULL이 되는 때에만, Notify 패킷이 발행된다.
단계 11-8에서, 프록시 서버(9300)의 프로토콜 변환 처리부(9016)는 현재 프로토콜 변환 처리를 수행중인 프린터의 수가 프로토콜 변환 처리를 수행할 수 있는 프린터 장치 수 보다 작은지, 즉, 새롭게 검출된 프린터들이 프로토콜 변환 처리를 수행할 수 있는지 여부를 판별한다.
단계 11-8에서 프린터들이 프로토콜 변환 처리를 수행할 수 있다고 판정되면, 단계 11-7로 진행하여, 상태가 이미 FULL 모드 인지 연부를 판별한다. FULL 모드이면, 검출된 프린터들이 프록시 서버에 의해 조작된 적이 없는 새로운 장치들인지 여부가 판별된다(단계 11-15).
새로운 장치들인 것으로 판정되면, 단계 11-11로 진행한다. 새로운 장치들이 아닌 것으로 판정되면, 과거에 프록시 서버에 의해 조작된 적이 있는 장치들은 대기 모드, 휴면(deep sleep) 모드, 수면(sleep) 모드, 오프라인, 중단 모드, 등으로부터 복귀되어, 다시 프로토콜 변환 처리가 요구되게 된다는 것을 의미한다. 따라서, 단계 11-9로 진행한다. 단계 11-9에서는, 프록시 서버(9300)의 프로토콜 변환 처리부(9016)가 기록 장치 제어부(9015)를 통해 갱신된 관리 테이블을 기록 장치에 기록한 후, 관리 테이블에 새롭게 등록된 프린터들에 대하여 취득된 정보에 기초하여 "UPnP 장치 아키텍쳐 v1.0"에 명시된 "장치 기술 문서"를 생성하고, 이를 기록 장치 제어부(9015)를 통해 기록 장치에 기록한다(단계 11-9). 이어서, 단계 11-10에서, "UPnP 장치 아키텍쳐 v1.0"에 명시된 통지 수단에 기초하여 UPnP 처리부(9014)에 의해, 관리 테이블에 기록된 모든 프린터들에 대하여 Notify 패킷이 발행되어, 그러한 프린터들이 네트워크 상에서 서비스를 실행하고 있음을 통지한다.
단계 11-15에서 프로토콜 변환을 중단하였던 네트워크 프린터들이 검출되는 경우, 단계 11-9로 진행한다. "UPnP 장치 아키텍쳐 v1.0"에 명시된 "장치 기술 문서"가 생성되어, 기록 장치 제어부(9015)를 통해 기록 장치에 기록된다. 이어서, 단계 11-10에서, "UPnP 장치 아키텍쳐 v1.0"에 명시된 통지 수단에 기초하여 UPnP 처리부(9014)에 의해 관리 테이블에 기록된 모든 프린터에 대하여 Notify 패킷이 발행되어, 그러한 프린터들이 네트워크 상에서 서비스를 실행하고 있음을 통지한다.
전술한 각각의 처리에 이어서, 단계 11-11에서, 자신의 관리 테이블에 이미 기록된 프린터임에도 불구하고, 프록시 서버(9300)에 의해 발행된 SNMP Get 요청에 응답하여 아무런 응답이 취득되지 않는 경우, 프린터로부터 응답이 취득될 수 있는지 여부가 판별된다. 단계 11-11에서 아무런 응답이 취득되지 않으면, 상태가 FULL 모드인지 여부가 판별된다(단계 11-14). 단계 11-14에서 상태가 FULL 모드가 아닌 것으로 판정되면, 프록시 서버(9300)의 프로토콜 변환 처리부(9016)는 프린터 정보와 "장치 기술 문서"를 관리 테이블에서 삭제하고(단계 11-12), 단계 11-13으로 진행한다.
단계 11-13에서는, 프록시 서버(9300)의 프로토콜 변환 처리부(9016)가 기록 장치 제어부(9015)를 통해 기록 장치에 갱신된 관리 테이블을 기록한 후에, "UPnP 장치 아키텍쳐 v1.0"에 명시된 통지 수단에 기초하여 UPnP 처리부(9014)에 의해 관리 테이블로부터 삭제된 모든 프린터들에 대하여 Notify 패킷을 발행하여, 그러한 프린터들은 네트워크 상에서 서비스를 중단하였음을 통지한다.
단계 11-14에서 프록시 서버(9300)의 프로토콜 변환 처리부(9016)가 FULL 모드로 상태가 절환되었음을 판정하였다면, 관리 테이블에서 해당 프린터 정보가 삭제되지 않는다. 프록시 서버(9300)의 프로토콜 변환 처리부(9016)는 "UPnP 장치 아키텍쳐 v1.0"에 명시된 통지 수단에 기초하여 UPnP 처리부(9014)에 의해 아무런 응답이 없는 모든 네트워크 프린터에 대하여 Notify 패킷을 발행하여, 그 프린터들은 네트워크 상에서 서비스를 중단하였음을 통지하고(단계 11-13), 처리 루틴을 끝낸다.
본 발명에 있어서, 도 25에 도시된 바와 같이, 앞서 취득되어 기술된 SNMP 객체의 내용이 XML로 기술되는 텍스트 파일의 포맷으로 관리 테이블이 관리된다. 도 25에는 프린터의 테이블이 정의된다. 프린터 태그 <Printer>와 </Printer> 사이의 부분에 각 프린터가 정의된다. 도면에서는, 태그 사이에 기술된 바와 같이, 프린터 명칭, 설정 위치, IP 어드레스, MAC 어드레스, 해당 언어, 지원되는 인쇄 프로토콜 등이 정의된다. 복수의 프린터에서 정보가 취득되는 경우, 마찬가지로, 복수의 프린터의 정보가 *** 로 표시된 부분에 기입되어 관리될 수 있다.
프린터 정보 취득 처리가 완료되면, 프록시 서버(9300)의 프로토콜 변환 처리부(9016)가 단계 10-13의 프로토콜 변환 처리를 시작한다.
도 12A 및 도 12B의 도면에서는 프로토콜 변환 처리를 위한 흐름을 나타낸 다.
프록시 서버(9300)의 프로토콜 변환 처리부(9016)가 UPnP 프로토콜 처리부(9014)로부터 "UPnP 장치 아키텍쳐 v1.0"에 명시되어 클라이언트로부터 발행되는 장치 검색 프로토콜 "SSDP" 패킷의 수신 통지를 수신하는 경우, 기록 장치 제어부(9015)를 통해 프록시 서버(9300)의 프로토콜 변환 처리부(9016)에 의해 관리되는 관리 테이블이 검색되고, SSDP 응답으로서 UPnP 프로토콜 처리부(9014)를 통해 SSDP 패킷의 검색 조건에 해당하는 프린터의 "장치 기술 문서"가 반송되는 URL이 검색된다(단계 12-2).
UPnP 프로토콜 처리부(9014)로부터의 "장치 기술 문서"의 취득 요청이 이러한 URL을 취득한 클라이언트 장치로부터의 HTTPGet 요청에 의해 수신되는 경우(단계 12-3), 기록 장치 제어부(9015)를 통해 프록시 서버(9300)의 프로토콜 변환 처리부(9016)에 의해 관리되는 관리 테이블이 검색되고, 지정된 URL에 기록된 "장치 기술 문서"가 판독된 후, UPnP 프로토콜 처리부(9014)를 통해 반송된다(단계 12-4).
"UPnP 장치 아키텍쳐 v1.0"에 명시된 제어 수단에 기초하여, "장치 기술 문서"를 취득한 클라이언트 장치로부터 인쇄 작업이 발행된다. 이러한 경우, 작업 명령과 작업 아키텍쳐는 XML 포맷으로 기술되어 있으므로, 프록시 서버(9300)의 프로토콜 변환 처리부(9016)가 UPnP 프로토콜 처리부(9014)를 통해 인쇄 작업을 수신하면(단계 12-5), 프로토콜 변환 처리부(9014)는 그 명령과 작업 속성을 SOAP 처리부(9013)에서 분석한 후, 기록 장치 제어부(9015)를 통해 출력이 지정된 프린터에 해당하는 관리 테이블 정보내에서 지원되는 인쇄 프로토콜과 IP 어드레스를 취득하고, 수신된 명령과 속성 정보를 그러한 인쇄 프로토콜로 변환한다(단계 12-6). 그 후, 변환후의 정보가 출력이 지정된 프린터의 IP 어드레스에 전송된다(단계 12-7). 이어서, 인쇄 작업을 발행한 클라이언트는 작업 데이터, 본 경우에 있어서 PDL을 프록시 서버(9300)에 "UPnP 장치 아키텍쳐 V1.0"에 명시된 제어 수단에 기초한 HTTPPost 명령을 사용하여 전송한다. 작업 데이터를 수신한 프록시 서버(9300)의 프로토콜 변환 처리부(9016)는 수신된 작업 데이터를 지정된 프린터에 의해 지원되는 인쇄 프로토콜로 변환하고(단계 12-9-1), 작업 데이터를 앞서 취득한 프린터의 IP 어드레스에 전술한 방법과 마찬가지의 방법으로 전송한다(단계 12-9-2).
소정의 시간내에, 예컨대, 본 실시예에서 30초 이내에 작업 데이터의 수신이 클라이언트로부터 시작되지 않으면(단계 12-10), 작업이 포기된다(단계 12-11).
작업 명령, 작업 속성, 및 작업 데이터를 수신한 프린터는 인쇄 제어부에 의해 작업 명령과 작업 속성을 분석한 후, 인쇄 작업을 프린터 컨트롤러에 전송하고, 인쇄를 수행한다.
본 발명의 프록시 서버(9300)는 반복적으로 전술한 처리들을 수행하여 네트워크 프린터의 작동 상태를 주기적으로 갱신하고, 갱신된 정보에 따라서 프로토콜 변환 처리를 수행한다.
프록시 서버(9300)의 프로토콜 변환 처리부(9016)가 단계 10-14의 전원 차단으로 인하여 프로토콜 변환 처리를 중단하는 경우, 프로토콜 변환 처리부(9016)는 "UPnP 장치 아키텍쳐 v1.0"에 명시된 통지 수단에 기초하여 기록 장치 제어부 (9015)를 통해 모든 관리 테이블을 판독하고, UPnP 프로토콜 처리부(9014)를 통해 관리 테이블에 기록된 모든 프린터에 대하여 Notify 패킷을 발행하여, 그 프린터들은 네트워크 상에서 서비스를 중단하였음을 통지한다(단계 10-15). UPnP 프로토콜에 의한 통지 처리 수행후, 프로토콜 변환 처리부(9016)는 도 11에 도시된 포맷으로 멀티캐스트 어드레스 239.255.255.250 및 포트 번호 1900으로 HTTPNotify 요청을 발행한다(단계 10-16). 이 때, 이하의 정보가 XML 포맷으로 기재되어, HTTP 요청의 엔티티 바디(entity body)로서 통지된다.
도면에 있어서,
<status>: 프록시 서버의 작동 상태를 나타냄. 이 경우, ByeBye, 즉 프로토콜 변환 처리의 중단이 통지됨.
<protocol>: 프록시 서버에 의해 변환될 수 있는 프로토콜을 나타냄. UPnP, BMLinkS, Rendezvous 등의 프로토콜 명칭이 기재됨. 본 실시예에서, Microsoft 사의 UPnP가 일례로서 기재됨.
<ProxyURL>: 프록시 서버의 IP 어드레스가 URL 포맷으로 기재됨.
<ProxyMAC>: 프록시 서버의 물리 어드레스(MAC)가 기재됨.
<TableURL>: 프록시 서버에 의해 관리되는 관리 테이블에 저장 어드레스가 URL 포맷으로 기재됨.
상기 처리들을 수행함으로써, 프록시 서버(9300)는 네트워크 상에서 동작하는 또 다른 프록시 서버에 프로토콜 변환 처리가 중단되었음을 통지한다.
도 13의 플로우차트의 단계 13-6에서, 프록시 서버(9300)의 프로토콜 변환 처리부(9016)가 네트워크 상에서 동작하고 있던 또 다른 프록시 서버로부터 프로토콜 변환 처리의 중단을 나타내는 Notify 패킷을 수신한 경우, SOAP 처리부(9013)에서 패킷의 엔티티 바디가 분석되어, Notify 패킷을 발행한 프록시 서버로부터 관리 테이블이 취득되었는지 여부가 판별된다. 단계 13-7에서 관리 테이블이 취득된 경우, 이 관리 테이블은 기록 장치 제어부(9015)를 통해 삭제된다(단계 13-8).
즉, ByeBye 를 발행한 프록시 서버가 프로토콜 변환 처리를 제공하였던 프린터의 변환 처리는, 현재 진행 모드에 있는 프록시 서버(9300)에 인계된다.
도 10A 및 도 10B의 플로우차트의 단계 10-5에서 수면 모드로 절환된 프록시 서버(9300)의 프로토콜 변환 처리부(9016)는, 또 다른 프록시 서버로부터 발행되는 Notify 패킷을 모니터링한다. SOAP 처리부(9013)를 통해 수신되는 Notify 패킷의 엔티티 바디 내에서 <status>의 성분이 ByeBye 또는 FULL 인 패킷이 하나라도 존재하면, 프로토콜 변환 처리부(9016)는 소정의 알고리즘에 따라 1 내지 30의 정수 중 랜덤 수를 생성한 후, 생성된 랜덤 수의 값과 등가인 몇 초 동안을 대기한다. 그 후, 단계 10-7 및 10-2의 Notify 패킷 발행 처리가 실행된다.
전술한 바와 같이, 복수 종류의 프로토콜이 혼재하는 네트워크 시스템에서 프로토콜 변환 처리를 실행하는 제어 장치의 일례로서의 프록시 서버(9300)는, 네트워크에 검색 요청을 멀티캐스팅하여, 활성화 시에 네트워크 상에 또 다른 프록시 서버(도시 생략)가 존재하는지 여부를 검색하는 검색 수단(도 10A 및 도 10B의 단계 10-3 및 10-4에 나타낸 바와 같이, 프록시 서버(9300)의 CPU가 메모리에 저장된 제어 프로그램을 수행하는 방법에 의해 구현되는 기능); 검색 수단에 의해 네트 워크 상에서 또 다른 프로토콜 변환 장치가 검색되는 경우, 검색된 프로토콜 변환 장치가 프로토콜 변환을 실행할 수 있는지 또는 실행하였는지 여부를 판별하는 판별 수단(단계 10-4); 및 검색된 프로토콜 변환 장치가 프로토콜 변환 처리를 실행할 수 없거나 실행하지 않는 것으로 판별 수단에 의해 판정되는 경우, 프로토콜 변환 처리의 일례로서 단계 10-13을 활성화하는 활성화 수단(예컨대, 도 9의 UPnP 프로토콜 처리부(9014) 자체는 단계 10-13을 활성화하여 실행할 수 있거나, 또는 검색 어플리케이션(도시 생략) 또는 OS로부터 처리 단계가 활성화 될 수도 있음)을 구비한다.
프린터가 네트워크 장치인 것으로 가정하고 본 실시예를 나타내었지만, 하드 디스크 등의 저장장치, 스캐너, 복사기, 및 통신 기능을 통해 프록시 서버와 속성 정보를 교환할 수 있는 이들의 복합기능을 갖는 장치 중 임의의 경우에 있어서 네트워크 지원 장치가 실현되어, 작업을 송수신할 수 있다.
이러한 경우, 프록시 서버와 네트워크 지원 장치와의 통신 프로토콜 또한 표준화된 프로토콜 또는 일반적인 프로토콜 또는 배포업체에 고유한 프로토콜에 의해 마찬가지로 구현될 수 있다.
일례로서 네트워크 지원 장치가 사용되는 것을 가정하여 본 실시예를 나타내었지만, USB, IEEE 1394, 병렬 연결 등의 로컬 연결에 의해 이루어지는 통신에 의해 장치와 프록시 서버 사이의 통신이 실현될 수도 있다.
본 실시예에서는 네트워크 상에 프록시 서버가 독립적으로 존재하지만, 이러한 프록시 서버 기능이 네트워크 지원 장치에서 물리적으로 또는 논리적으로 구현 되는 경우에도 실현될 수도 있다.
본 실시예에서는 프록시 서버에 의해 제공되는 프토토콜 변환의 조합으로서 Microsoft사의 "UPnP", 네크워크 지원 프린터에서 구현되는 SNMP, 및 인쇄 프로토콜이 예를 나타내었지만, Apple Computer의 "Rendezvous", JBMIA의 "BMLinkS"와 같은 프로토콜의 경우에도 프로토콜 변환이 실현될 수도 있다. 장치의 검색 및 제어가 통합된 프로토콜의 경우 뿐만 아니라, "SLP(Service Location Protocol)", "Multicast DNS Service Discovery" 등의 장치에 의해 제공되는 서비스의 검색을 위한 프로토콜, 및 XML/SOAP에 기초하여 "RPC(Remote Procedure Call)" 포맷에서 장치 제어를 종래의 제어 프로토콜로 변환하기 위한 "Web Service" 등의 프로토콜의 경우에도 프로토콜 변환이 사용될 수 있다.
본 실시예에서, HTTP에 의해 Notify 패킷이 발행되는 경우, XML 포맷으로 추가의 정보가 이러한 패킷의 엔티티에 기술되고, 그 결과의 패킷이 전송된다. 그러나, 엔티티의 기재는 이진 데이터를 사용한 기재에 의해 실현될 수도 있다. 또한, HTTP 헤더(header)를 새롭게 정의하고, 이러한 헤더를 사용한 형태에서 통지 수단을 사용하여 실현될 수도 있다.
프록시 서버들 사이의 정보 통지 프로토콜로서 HTTP/TCP/UDP/IP 프로토콜이 사용되는 예에 대하여 본 실시예를 나타내었지만, 본 발명은 전달 수단에 의존하지 않으며, 양방향을 통신을 구현할 수 있는 한, 또 다른 범용 프로토콜 또는 원래의 프로토콜을 사용하는 경우에도 구현될 수도 있다.
전술한 바와 같이, 본 실시예의 일 양태로서 이하의 기능들이 제공된다: 즉 , 동일한 프로토콜 변환 기능을 갖는 프로토콜 변환 장치들이 동일 통신선상에서 동작 가능한 모드에 있는 경우, 프로토콜 변환 처리 장치는 프로토콜 변환 처리 장치들의 상태를 자동적으로 취득하여 프로토콜 변환 처리의 대기 또는 실행을 판별할 수 있으며, 프로토콜 변환 처리가 실행되는 경우, 프로토콜 변환을 실행한 정보 처리 장치들의 정보가 이미 동일한 프로토콜 변환 처리를 실행한 프로토콜 변환 처리 장치들로부터 취득되어, 그러한 정보 처리 장치들로는 프로토콜 변환이 수행되지 않는다. 따라서, 동일한 프로토콜 변환 처리를 제공하는 프로토콜 변환 처리 장치들 중에서, 동일한 정보 변환 장치에 대하여 중복적으로 프로토콜 변환 처리가 수행되는 상황을 방지할 수 있다.
또한, 본 발명의 또 다른 양태에 따르면, 네트워크 상에서 정보 처리 장치를 사용하는 사용자들(네트워크 관리자를 포함)이 특별히 설정, 제어 등에 관여하지 않아도, 본 발명이 적용되는 프로토콜 변환 처리 장치는 그러한 처리들을 자동적을 수행하여 프로토콜 변환 처리 장치의 변환 능력이 최대한으로 사용된다.
(제3 실시예)
이하, 도면을 참조하여, 본 발명의 바람직한 실시예를 일례로서 상세하게 설명한다. 전술한 바와 마찬가지의 방법으로, 본 실시예에 개시된 프로토콜, 버젼, 어드레스, 수치값 등은 달리 정하지 않는 한 본 발명의 범주를 제한하지 않는다.
이하, 본 발명에 따른 서비스 제공 시스템의 일실시예로서 프로토콜 변환 시스템을 설명한다. 도 16은 본 발명의 실시예에 따른 인쇄 시스템의 구성을 나타낸 블록도이다.
Microsoft 사의 "Windows(등록상표)", Apple Computer 사의 MacOS(등록상표) 등의 범용 운영체제와 운영체제에서 실행될 수 있는 일반적인 웹 브라우저, 어플리케이션 소프트웨어 등이 클라이언트(16100)에 장착되어 있다.
본 실시예에 나타낸 "Windows(등록상표)" OS(161)의 경우, 네트워크 상의 장치들의 발견, 제어, 상태의 취득 등은 "XML/SOAP"를 사용하는 "UPnP" 프로토콜(162)을 사용하여 실현된다. UPnP 수행 장치에서 취득되는 HTML로 기재된 프리젠테이션 문서는 웹 브라우저(163)에 의해 표시되며, 예컨대 웹 브라우저에 장착된 스크립트 등을 사용하여, 어플리케이션 소프트웨어로서 워드 프로세서(164)에 의해 생성된 문서가 인쇄 속성 정보와 함께 프리젠테이션 문서가 전송된 UPnP 프로토콜 대응 프린터에 전송된다.
네트워크 통신 장치, 본 실시예에서는 네트워크 지원 프린터(16200)는 통신 기능으로서 TCP/UDP/IP 프로토콜 스택(165)을 갖는다. 프로토콜 스택(165)에는 SNMP 처리부(166)가 제공된다. 프로토콜 스택(165)에는 인쇄 프로토콜 처리부(167)가 구비되며, 클라이언트에 의해 발행된 인쇄 요청을 분석하고, 인쇄 요청을 프린터 컨트롤러(168)에 송신하는 기능을 갖는다.
프린터는 UPnP 프로토콜 처리부를 갖지 않으며, UPnP 프로토콜을 사용한 장치 검색 요청과 클라이언트(16100)에 의해 발행되는 UPnP 인쇄 작업 요청에 독자적으로 응답할 수 없다.
마찬가지로, 프록시 서버(16300)는 또한 통신 기능으로서 TCP/UDP/IP 프로토콜 스택(1609)을 갖는다. 이 프로토콜 스택에는 HTTP(1610)가 제공되며, HTTP 요 청에 대한 분석과 응답 처리가 실행된다.
프로토콜 스택(1609)에는 SNMP 처리부(1611)가 제공된다. UPnP 프로토콜 처리부를 갖지 않는 네트워크 지원 프린터(16200)의 검색과 정보의 취득은 상기 프로토콜에 의해 실행된다.
프로토콜 스택(1609)에는 인쇄 프로토콜 처리부(1612)가 제공된다. 인쇄 프로토콜 처리부(1612)에서는 UPnP 프로토콜 처리부를 갖지 않는 네트워크 지원 프린터(16200)에 대한 인쇄 작업의 발행이 실행된다.
HTTP(1610)의 상부층에는 SOAP 처리부(1613)가 제공된다. 네크워크 상에 UPnP 프로토콜 처리부(1614)와 프로토콜 변환 처리부(1616)가 각각 존재하는 경우, 및 네트워크 상에 복수의 클라이언트(16100) 및 복수의 프록시 서버가 각각 존재하는 경우에는, SOAP 처리부(1613)를 통해 XML로 기술된 데이터의 양방향 통신이 구현된다.
SNMP 처리부(1611)의 상부층, SOAP 처리부(1613), UPnP 처리부(1614), 인쇄 프로토콜 처리부(1612), 기록 장치 제어부(1615), XML 생성부(1617), 및 HTML 생성부(1618)에 프로토콜 변환 처리부(1616)가 위치되어, 이하의 처리들을 실행한다. 즉, UPnP 프로토콜에서 사용되는 각종 XML 문서들이 XML 생성부(1617)에 의해 생성되고, UPnP 프로토콜에서 사용되는 프리젠테이션 문서가 HTML 생성부(1618)에서 생성된 후에, SNMP 처리부(1611)를 통해 취득된 네트워크 지원 프린터의 정보가 기록 장치 제어부(1615)에 의해 제어되는 기록 장치에 기록되거나, 또는 UPnP 프로토콜로부터의 요청이 있는 경우, 해당 관리 테이블에 기록된 프리젠테이션 문서와 XML 문서가 기록 장치 제어부(1625)를 통해 판독되어, UPnP 프로토콜 처리부(1614) 등에 전송된다.
UPnP 프로토콜에 의한 인쇄 작업에 대한 요청이 수신되는 경우, 프로토콜 변환 처리부(1616)는 작업 명령과 작업 속성 정보를 SOAP 처리부(1613)를 통해 취득하고, 그 내용을 출력으로 지정된 프린터에 의해 지원되는 인쇄 프로토콜로 변환한 후, 인쇄 프로토콜 처리부(1612)를 통해 지정된 프린터에 작업을 전송한다. 이 때, 작업 속성이 분석되어, 수신된 작업 데이터의 형식이 지정된 프린터에 의해 지원되지 않는 데이터 형식인 경우, 파일 변환 처리부(1619)는 그 데이터를 지정된 프린터에 의해 지원되는 인쇄가능한 데이터로 변환한 후, 인쇄 프로토콜 처리부(1612)를 통해 지정된 프린터에 그 작업을 전송한다.
프로토콜 변환 처리부(1616)는, 제어부(1615)를 통해 프록시 서버(16300)에 의해 관리되는 관리 테이블을 기록 장치 제어부(1615)에 의해 제어되는 기록 장치에 판독 및 기입하는 처리들을 실행한다.
마찬가지로, 프로토콜 변환 처리부(1616)가 네트워크 상에 존재하는 또 다른 프록시 서버에 의해 관리되는 관리 테이블을 취득하는 경우, 제어부(1615)를 통해 이를 기록 장치 제어부(1615)에 의해 제어되는 기록 장치에 기입 및 판독하기 위한 처리들을 실행한다.
이하, 도 17의 플로우차트를 참조하여 본 시스템의 제어 흐름을 설명한다.
프록시 서버(16300)의 프로토콜 변환 처리부(1616)가 활성화 된 후, 기록 장치 제어부(1615)를 통해 프로토콜 변환 처리를 수행한 네트워크 장치의 정보가 기 록된 관리 테이블의 내용을 클리어시킨다(단계 17-1). 관리 테이블의 세부 사항은 이하의 처리들에서 상세하게 설명한다.
이어서, 클라이언트가 네크워크에 참여하여 서비스를 시작하는 경우, 이 네크워크 상에 존재하는 네트워크 통신 프린터를 검색하기 위하여, 처리 루틴은 단계 17-2로 진행하여, 프린터 정보의 취득이 시작된다.
도 18의 플로우차트는 프린터 정보를 취득하기 위한 제어의 흐름을 나타낸다.
프록시 서버(16300)의 프로토콜 변환 처리부(1616)는 네트워크 상에 존재하는 프린터들의 프린터 정보를 취득하기 위하여 SNMP 처리부(1611)로부터 다음의 MIB 객체에 SNMP Get 요청을 브로드캐스트한다(단계 18-1). 단계 18-1-2에서, 응답이 수신되었는지 여부가 판별된다. 단계 18-1-2에서 응답이 수신되었으면, 단계 18-2로 진행한다. 단계 18-1-2에서 응답이 수신되지 않으면, 단계 18-8로 진행한다.
PrinterMakerAndModel: 프린터 배포업체/모델 명칭
PrinterName: 프린터 명칭
PrinterLocation: 프린터 설정 위치
IPAddress: 프린터 IP 어드레스
MACAddress: 프린터 MAC 어드레스
SupportedPDL: 지원되는 페이지 기술 언어
SupportedPrinterProtocol: 지원되는 인쇄 프로토콜
단계 18-1에서, 프록시 서버에 의해 발행된 SNMP Get 요청을 수신한 네크워크 지원 프린터(16200)는 SNMP 처리부(1611)의 각 객체에 해당하는 정보를 생성한 후, 유니캐스트 방식으로 프록시 서버(16300)에 대하여 SNMP 응답으로서의 응답을 전송한다.
단계 18-1-2에서 각각의 네트워크 지원 프린터로부터 응답을 수신한 프록시 서버(16300)의 프로토콜 변환 처리부(1616)는, 각 응답의 내용을 기록 장치에 이미 등록되어 있는 관리 테이블의 내용과 비교한다(단계 18-2). 이어서, 프로토콜 변환 처리부(1616)는 프린터가 이미 프로토콜 변환을 수행한 프린터인지 여부를 판별한다(단계 18-3). 단계 18-3에서 프린터가 프로토콜 변환 처리를 수행한 프린터인 것으로 판정하는 경우, 처리 루틴이 종료된다.
단계 18-3에서 프린터가 프로토콜 변환을 수행하지 않은 프린터인 것으로 판정하는 경우, 즉, 새로 발견된 프린터인 경우, 프록시 서버(16300)의 프로토콜 변환 처리부(1616)는 SNMP Get 요청의 응답으로서 취득한 정보를 관리 테이블에 추가하고, 이를 갱신하여, 기록장치 제어부(1615)를 통해 기록 장치에 기록한다(단계 18-4).
이어서, 관리 테이블에 새로 등록된 프린터에 대하여, 취득된 정보에 기초하여 XML 생성부(1617)에 의해 "UPnP 장치 아키텍쳐 v1.0"에 명시된 "장치 기술 문서"가 생성되고, 생성된 문서는 기록 장치 제어부(1615)를 통해 기록 장치에 기록되고(단계 18-5), HTML에 기술된 프리젠테이션 문서가 HTML 생성부(1618)에 생성된다. 프리젠테이션 문서를 생성하는데 필요한 아이콘, 이미지 데이터, 등은 기록 장치에 기록되어 있다. HTML 생성부(1618)는 기록 장치 제어부(1615)를 통해 필요한 정보를 취득한다. HTML 생성부(1618)에 의해 생성된 프리젠테이션 문서는 기록 장치 제어부(1615)를 통해 기록 장치에 기록된다(단계 18-6).
단계 18-7에서는, "UPnP 장치 아키텍쳐 v1.0"에 명시된 통지 수단에 기초하여, 관리 테이블내에 기록된 모든 프린터에 대한 통지 패킷이 UPnP 프로토콜 처리부(1614)에 의해 발행되어, 네트워크 상에서 그러한 프린터들이 서비스를 실행하고 있음을 통지한다.
프록시 서버(16300)에 의해 발행된 SNMP Get 요청에 대하여 아무런 응답이 취득되지 않으면, 단계 18-8로 진행한다. 단계 18-8에서, 자신만의 관리 테이블에 이미 등록된 프린터가 존재하는지 여부가 판별된다. 단계 18-8-1에서, 프린터가 이미 등록된 프린터인지 여부가 판별된다. 단계 18-8-1에서 등록된 프린터가 존재하는 것으로 판정되면, 프록시 서버(16300)의 프린토콜 변환 처리부(1616)는 관리 테이블에서 프린터 정보를 삭제하고 이를 갱신한다(단계 18-9). 이어서, "장치 기술 문서"의 삭제(단계 18-10) 및 프리젠테이션 문서의 삭제(단계 18-11)가 실행된다.
프록시 서버(16300)의 프로토콜 변환 처리부(1616)는 갱신된 관리 테이블을 기록 장치 제어부(1615)를 통해 기록 장치에 기록한다. 그 후, 프로토콜 변환 처리부는 "UPnP 장치 아키텍쳐 v1.0"에 명시된 통지 수단에 기초하여 UPnP 처리부(1614)로부터의 관리 테이블에서 삭제된 모든 프린터들에 대하여 Notify 패킷을 발행하여, 그러한 프린터들은 네트워크 상에서 서비스를 중단하였음을 통지한다(단계 18-12).
본 발명에 있어서, 도 26에 나타낸 바와 같이, 전술한 취득된 SNMP 객체의 내용이 XML로 기재된 텍스트 파일의 포맷으로 관리 테이블이 관리된다.
도 18에 나타낸 전술한 처리는 도 17의 프린터 정보 취득 처리에 해당한다. 도 17로 돌아가서, 프린터 정보 취득 처리의 완료 후에, 프록시 서버(16300)의 프로토콜 변환 처리부(1616)는 프로토콜 변환 처리를 시작한다(단계 17-3).
도 20A 및 도 20B를 사용하여 이하에서 상세한 처리를 나타낸다. 도 20A 및 도 20B의 플로우차트는 프로토콜 변환 처리의 흐름을 나타낸다. 프록시 서버(16300)의 프로토콜 변환 처리부(1616)는, 클라이언트에 의해 발행된 장치 검색 프로토콜 "SSDP" 패킷의 수신 통지가 UPnP 프로토콜 처리부(1614)로부터 수신되었는지, 그리고 "UPnP 장치 아키텍쳐 v1.0"에 명시되었는지 여부를 판별한다(단계 20-1). 단계 20-1에서 수신된 것으로 판정되면, 단계 20-2로 진행한다. 수신되지 않은 것으로 판정되면, 단계 20-3으로 진행한다.
단계 20-2에서는, 프록시 서버(16300)의 프로토콜 변환 처리부(1616)에 의해 관리되는 관리 테이블이 기록 장치 제어부(1615)를 통해 검색된다. SSDP 패킷의 검색 조건에 해당하는 프린터의 "장치 기술 문서"가 기록된 URL이 UPnP 프로토콜 처리부(1614)를 통해 SSDP 응답으로 반송되고(단계 20-2), 단계 8-3으로 진행한다.
"장치 기술 문서"를 획득하기 위한 요청이 UPnP 프로토콜 처리부(1614)를 통해 이러한 URL을 취득한 클라이언트 장치로부터의 HTTPGet 요청에 의해 수신되었는지 여부가 판별된다(단계 20-3). 단계 20-3에서 취득 요청이 수신된 것으로 판정 되면, 프록시 서버(16300)의 프로토콜 변환 처리부(1616)에 의해 관리되는 관리 테이블이 기록 장치 제어부(1615)를 통해 검색된다. 지정된 URL에 기록된 "장치 기술 문서"가 판독된 후, UPnP 프로토콜 처리부(1614)를 통해 반송되며(단계 20-4), 단계 20-5로 진행한다. 단계 20-3에서 취득 요청이 수신되지 않은 것으로 판정되면, 단계 20-5로 진행한다.
단계 18-6에서 형성된 프리젠테이션 문서의 저장 목적지는 "장치 기술 문서"에 URL로 기록되어 있다. 프리젠테이션 문서의 취득 요청이 UPnP 프로토콜 처리부(1614)로부터 클라이언트 장치로부터의 HTTPGet 요청에 의해 수신되었는지 여부가 판별된다(단계 20-5). 프리젠테이션 문서의 취득 요청이 수신된 것으로 판별되면, 단계 20-6으로 진행한다. 단계 20-6에서는, 프록시 서버(16300)의 프로토콜 변환 처리부(1616)에 의해 관리되는 관리 테이블이 기록 장치 제어부(1615)를 통해 검색된다. 지정된 URL에 기록된 프리젠테이션 문서가 판독된 후, UPnP 프로토콜 처리부(1614)를 통해 반송된다. 프리젠테이션 문서의 취득 요청이 수신되지 않는 것으로 결정되면, 단계 20-7로 진행한다.
본 실시예에 나타낸 클라이언트(16100)의 경우, 운영체제가 UPnP 프로토콜에 해당한다. 단계 20-6에서 프록시 서버(16300)로부터의 프리젠테이션 문서의 수신의 완료 후, 웹 브라우져가 자동적으로 활성화되고, 수신된 프리젠테이션 문서가 표시된다.
도 21은 클라이언트(16100)의 디스플레이 상에 표시되는 프리젠테이션 문서의 내용을 나타낸다. 이 디스플레이를 눈으로 확인하여, 클라이언트(16100)를 사 용하는 사용자는 표시 내용을 통해 네트워크 지원 프린터(16200)에 대한 장치 명칭, 모델 명칭, IP 어드레스, 옵션의 구현 상태, 등의 정보를 시각적으로 확인할 수 있다.
상기 디스플레이의 "문서 인쇄"가 클릭되면, 디스플레이는 도 22에 나타낸 페이지로 절환된다. 네트워크 지원 프린터(16200)에 대하여, 이하의 작업 속성이 지정될 수 있다. 출력될 파일의 지정: Print File, 출력 카피의 수: Copy, 출력 용지 사이즈: Media Size, 페이지 레이아웃: N-Up, 양면/단면 인쇄의 지정: Two-side printing, 인쇄 품질: Print Quality, 방향: Orientation, 등. 그러한 속성 정보의 설정 완료후, Print 버튼을 클림함으로써, 프리젠테이션 문서에 기술된 스크립트는 "UPnP 장치 아키텍쳐 v1.0"에 명시된 스키마에 따라서 SOAP 밀봉(envelope)을 형성한 후, 프록시(16300)에 대하여 HTTPPost 요청이 발행된다.
프록시 서버(16300)의 프로토콜 변환 처리부(1616)가 UPnP 프로토콜 처리부(1614)를 통해 요청을 수신한 경우(단계 20-7), 프로토콜 변환 처리부(1616)는 SOAP 처리부의 작업 속성과 명령을 분석한 후, 기록 장치 제어부(1615)를 통해 출력이 지정된 프린터에 해당하는 관리 테이블의 정보 내의 IP 어드레스와 지원되는 인쇄 프로토콜을 취득하고, 수신된 명령과 수신된 속성 정보를 인쇄 프로토콜로 변환한다(단계 20-8). 그 후, 변환 후의 정보가 출력이 지정된 프린터의 IP 어드레스에 전송된다(단계 20-9).
인쇄 작업을 발행한 클라이언트는 이어서 작업 데이터를 프록시 서버(16300)에 "UPnP 장치 아키텍쳐 v1.0"에 명시된 제어 수단에 기초한 HTTPPost 명령을 사용 하여 전송한다. 작업 데이터를 수신한 프록시 서버(16300)의 프로토콜 변환 처리부(1616)는 수신 데이터의 데이터 타입을 분석한다. 데이터 타입이 단계 18-4에서 취득된 관리 테이블에 기록된 "SupportedPDL: 지원되는 페이지 기술 언어"와 일치하는 경우, 전술한 단계와 마찬가지의 방법으로, 수신된 작업 데이터는 지정 프린터에 의해 지원되는 인쇄 프로토콜로 변환되고(단계 20-10), 작업 데이터는 앞서 취득되었던 프린터 IP 어드레스에 전송된다(단계 20-11).
단계 20-9-1에서 UPnP 작업 데이터가 수신되었는지 여부가 판별된다. 단계 20-9-1에서 UPnP 작업 데이터가 수신된 것으로 판정되면, 단계 20-9-2로 진행한다. 단계 20-9-2에서, 수신 데이터의 테이터 타입의 분석 결과, 단계 18-4에서 취득된 관리 테이블에 기록된 "SupportedPDL: 지원되는 페이지 기술 언어"와 일치하지 않는 것으로 판정되면, 프로토콜 변환 처리부(1616)는 수신된 데이터를 단계 20-12에서 파일 변환 처리부(1619)의 취득된 프린터 PDL 데이터로 변환한 후, 지정된 프린터에 의해 지원되는 인쇄 프로토콜로 변환한다(단계 20-10). 이어서, 앞서 취득된 프린터 IP 어드레스로 변환후의 작업 데이터가 전송되고(단계 20-11), 처리 루틴이 종료된다.
수신 데이터의 데이터 타입 분석의 결과, 단계 18-4에서 취득된 관리 정보에 기록된 "SupportedPDL: 지원되는 페이지 기술 언어"와 일치하는 것으로 단계 20-9-2에서 판정되면, 처리 루틴은 단계 20-10으로 진행하고, 마찬가지로 단계 20-11의 처리로 진행한다. 처리 루틴은 종료된다.
단계 20-9-1에서 작업 데이터가 수신되지 않고, 또한 단계 20-11-1에서 소정 의 시간이 경과된 것으로 판정되는 경우, 본 실시예에서는 30초 이내에 작업 데이터의 수신이 클라이언트에 의해 시작되지 않으면, 작업이 포기된다(단계 20-13).
작업 명령, 속성, 및 작업 데이터를 수신한 프린터는, 인쇄 제어부의 작업 속성과 작업 명령을 분석한 후, 인쇄 작업을 프린터 컨트롤러에 전송하고, 인쇄를 실행한다.
본 발명의 프록시 서버(16300)는 전술한 단계 17-2와 17-3의 처리들을 반복적으로 수행하여, 네크워크 프린터의 작동 모드를 주기적으로 갱신하고, 갱신된 정보에 따라 프로토콜 변환 처리를 수행한다.
단계 17-4에서, 프록시 서버(16300)의 프로토콜 변환 처리부(1616)가 전원 차단으로 인하여 프로토콜 변환 처리를 중단하는지 여부가 판별된다. 단계 17-4에서 프로토콜 변환 처리를 중단하는 것으로 판정되면, 프로토콜 변환 처리부(1616)는 "UPnP 장치 아키텍쳐 v1.0"에 명시된 통지 수단에 기초하여 기록 장치 제어부(1615)를 통해 모든 관리 테이블을 판독하고, UPnP 프로토콜 처리부(1614)를 통해 관리 테이블에 기록된 모든 프린터에 대하여 Notify 패킷을 발행하여, 그러한 프린터들이 네트워크 상에서 서비스를 중단하였음을 통지한다(단계 17-5).
단계 17-4에서, 프로토콜 변환 처리를 중단하지 않는 것으로 결정되면, 처리 루틴은 프린터 정보 취득 처리로 복귀된다(단계 17-2).
프린터가 네트워크 장치인 것으로 가정하여 본 실시예를 나타내었지만, 하드 디스크 등의 저장장치, 복사기, 및 통신 기능을 통해 프록시 서버와 속성 정보를 교환하고 작업을 송수신 가능한 복합기능을 갖는 장치의 경우에도 네트워크 지원 장치가 실현될 수 있다.
이러한 경우 프록시 서버와 네트워크 지원 장치 간의 통신 프로토콜은 또한 표준화된 프로토콜, 일반적인 프로토콜, 또는 배포업체에 고유한 프로토콜에 의해 마찬가지로 실현될 수 있다.
일례로서 네트워크 지원 장치가 사용되는 것으로 가정하여 본 실시예를 나타내었지만, 장치와 프록시 서버와의 통신은 USB, IEEE1394, 병렬 연결, 등에 따라서 로컬 연결에 의해 이루어지는 통신에 의해서 실현될 수도 있다.
본 실시예에서 네트워크 상에서 프록시 서버는 독립적인 형태로 존재하지만, 네트워크 지원 장치에서 물리적으로 또는 논리적으로 구현되는 경우에도 이러한 프록시 서버 기능이 구현될 수도 있다. 마찬가지로, 이러한 프록시 서버 기능은 네트워크 클라이언트 장치에서 논리적으로 또는 물리적으로 구현되는 경우에도 실현될 수 있다.
본 실시예에서 프록시 서버에 의해 제공되는 프로토콜 변환의 조합으로서, Microsoft 사의 "UPnP", 네트워크 지원 프린터에 의해 구현되는 SNMP, 및 인쇄 프린터의 예를 나타내었지만, Apple Computer 사의 "Rendezvous", JBMIA의 "BMLinkS" 등의 프로토콜의 경우에도 프로토콜 변환이 실현될 수 있다. 프로토콜 변환은 또한, 장치의 검색과 제어가 통합된 프로토콜의 경우 뿐만 아니라, "SLP(Service Location Protocol)", "Multicast DNS Service Discovery", 등의 장치에 의해 제공되는 서비스에 대한 검색을 위한 프로토콜 및 XML/SOAP 에 기초하여 "RPC" 포맷을 종래의 제어 프로토콜로 변환하기 위한 "Web Service" 등의 프로토콜의 경우에도 사용될 수 있다.
또한, 프록시 서버 사이의 정보 통지 프로토콜로서 HTTP/TCP/UDP/IP 프로토콜이 사용되는 예에 대하여 본 실시예를 나타내었지만, 본 발명은 전달 수단에 의존하지 않으며, 양방향 통신을 할 수 있는 한 다른 범용 프로토콜 또는 고유 프로토콜을 사용하는 경우에도 실현될 수 있다.
(기타의 실시예)
본 실시예에서 도면에서 나타낸 처리들은, 외부로부터 장착되는 프로그램에 따라서 클라이언트, 프록시 서버, 및 프린터에 각각 제공되는 CPU들에 의해서 실행된다. 이러한 경우, 본 발명은 또한 CD-ROM, 플래시 메모리, FD 등의 저장 매체 또는 네트워크를 통한 외부 저장매체로부터 공급되는 프로그램을 포함하는 정보 그룹의 경우에도 적용된다.
물론, 본 발명의 목적은 전술한 실시예들의 기능을 실현하는 소프트웨어의 프로그램 코드들이 전술한 바와 같이 기록되는 기록 매체가 시스템 또는 장치에 공급되거나 외부 서버로부터 다운로드 되어, 시스템 또는 장치의 컴퓨터(CPU 또는 MPU)가 저장 매체에 저장된 프로그램 코드를 판독하여 실행하는 방법에 의해서도 달성된다.
이러한 경우, 저장 매체로부터 판독된 프로그램 코드 자체는 본 발명의 신규한 기능들을 실현한다. 프로그램 코드가 기록된 기록 매체는 본 발명을 구성한다. 프로그램 코드를 공급하기 위한 기록 매체로서, 예컨대, 플로피 디스크, 하드 디스크, 광 디스크, 광자기 디스크, DVD, CD-ROM, 자기 테이프, 비휘발성 메모리 카드, ROM, EEPOM, 등이 사용될 수 있다.
물론, 본 발명은 컴퓨터가 판독된 프로그램 코드을 실행하여, 전술한 실시예들의 기능들이 실현되는 경우 뿐만 아니라, 컴퓨터 상에서 동작하는 운영 체제(OS) 등이 실제 처리들의 일부 또는 모두를 실행하고, 전술한 실시예의 기능들이 프로그램 코드의 명령에 기초하여 그러한 처리들에 의해 실현되는 경우도 포함한다. 또한, 물론, 본 발명은 기록 매체로부터 판독된 프로그램 코드가 컴퓨터에 삽입된 기능 확장 보드 또는 컴퓨터에 연결된 기능 확장 유닛에 제공된 메모리에 기입된 후, 기능 확장 보드 또는 기능 확장 유닛에 대하여 제공된 CPU 등이 실제 처리의 전체 또는 일부를 실행하여, 전술한 실시예의 기능들이 프로그램 코드의 명령에 기초하여 그러한 처리들에 의해 실현되는 경우를 포함한다.
전술한 바와 같이, 본 발명의 제1 양태에 따르면, 복수의 프로토콜에 해당하는 장치가 다른 장치들 사이에 혼재하여 프로토콜 변환 처리가 실행되는 경우, 장치가 네크워크를 검색하면, 프로토콜 A에 의해 검색된 장치와 프로토콜 B에 의해 검색된 장치가 매우 조화된 방법으로 적절하게 인식될 수 있다.
본 발명의 제2 양태에 따르면, 복수의 프록시 서버들이 활성화되는 경우에도, 프록시 서버들은 적절하게 서로 중재하여, 장치들의 프로토콜 변환을 적절하게 실행하고, 장치들의 관리가 적절하게 이루어질 수 있다.

Claims (19)

  1. 복수 종류의 프로토콜이 혼재하는 네트워크 시스템에서 프로토콜 변환 처리를 실행하는 제어 장치로서,
    네트워크 상에서 소정의 프로토콜 처리를 실행하는 다른 프로토콜 변환 장치를 검색하기 위한 검색 요청을 상기 네트워크 상에 발행하고, 활성화 시에 검색 처리를 실행하는 검색 수단;
    상기 검색 수단에 의해, 상기 네트워크 상에서 상기 다른 프로토콜 변환 장치가 검색된 경우, 상기 검색된 프로토콜 변환 장치가 프로토콜 변환 처리를 실행할 수 있는지 또는 상기 검색된 프로토콜 변환 장치가 프로토콜 변환 처리를 실행하였는지를 인식하는 인식 수단;
    상기 인식 수단에 의해, 상기 검색된 프로토콜 변환 장치가 프로토콜 변환 처리를 실행할 수 없거나 또는 프로토콜 변환 처리를 실행하지 않는 것으로 인식된 경우, 프로토콜 변환 처리를 활성화시키는 활성화 수단;
    프로토콜 변환 처리 타겟으로서의 장치들을 관리하는 관리 수단; 및
    상기 인식 수단에 의해, 상기 검색된 프로토콜 변환 장치가 프로토콜 변환 처리를 실행할 수 없는 것으로 인식된 경우에는, 상기 관리 수단이 관리하는 프로토콜 처리 타겟으로서의 장치의 수가 미리 설정된 최대수를 넘는지 여부를 판별하는 판별 수단
    을 구비하며,
    상기 판별 수단에 의해, 상기 관리 수단이 관리하는 프로토콜 처리 타겟으로서의 장치의 수가, 미리 설정된 최대수를 넘지 않는 것으로 판별된 경우, 상기 활성화 수단은 상기 프로토콜 변환 처리를 활성화시키는 제어 장치.
  2. 제1항에 있어서,
    상기 검색된 프로토콜 변환 장치가 프로토콜 변환 처리를 실행할 수 있는지 여부는, 상기 프로토콜 변환 장치에 의해 처리될 수 있는 프로토콜 변환 처리의 수에 기초하여 상기 인식 수단에 의해 인식되는 제어 장치.
  3. 제1항에 있어서,
    상기 인식 수단에 의해 상기 검색된 프로토콜 변환 장치가 프로토콜 변환 처리를 실행할 수 있다고 인식되는 경우, 작동 모드가 수면 모드(sleep mode)로 절환되는 제어 장치.
  4. 삭제
  5. 제1항에 있어서,
    상기 판별 수단에 의해, 상기 관리 수단이 관리하는 프로토콜 처리 타겟으로서의 장치의 수가 미리 설정된 최대수를 넘는 것으로 판별된 경우에는, 수면 모드로의 절환을 나타내는 패킷이 네트워크 장치들에 멀티캐스트되는 제어 장치.
  6. 복수 종류의 프로토콜이 혼재하는 네트워크 시스템에서 프로토콜 변환 처리를 실행하는 제어 방법으로서,
    네트워크 상에서 소정의 프로토콜 처리를 실행하는 다른 프로토콜 변환 장치를 검색하기 위한 검색 요청을 상기 네트워크 상에 발행하고, 활성화 시에 검색 처리를 실행하는 검색 단계;
    상기 검색 단계에서, 상기 네트워크 상에서 상기 다른 프로토콜 변환 장치가 검색된 경우, 상기 검색된 프로토콜 변환 장치가 프로토콜 변환 처리를 실행할 수 있는지 또는 상기 검색된 프로토콜 변환 장치가 프로토콜 변환 처리를 실행하였는지를 인식하는 인식 단계;
    상기 인식 단계에서, 상기 검색된 프로토콜 변환 장치가 프로토콜 변환 처리를 실행할 수 없거나 또는 프로토콜 변환 처리를 실행하지 않는 것으로 인식된 경우, 프로토콜 변환 처리를 활성화시키는 활성화 단계;
    프로토콜 변환 처리 타겟으로서의 장치들을 관리하는 관리 단계; 및
    상기 인식 단계에서, 상기 검색된 프로토콜 변환 장치가 프로토콜 변환 처리를 실행할 수 없는 것으로 인식된 경우에는, 상기 관리 단계에서 관리되는 프로토콜 처리 타겟으로서의 장치의 수가 미리 설정된 최대수를 넘는지 여부를 판별하는 판별 단계
    를 구비하며,
    상기 판별 단계에서, 상기 관리 단계에서 관리되는 프로토콜 처리 타겟으로서의 장치의 수가, 미리 설정된 최대수를 넘지 않는 것으로 판별된 경우, 상기 활성화 단계에서 상기 프로토콜 변환 처리가 활성화되는 제어 방법.
  7. 제6항에 있어서,
    상기 인식 단계에서, 상기 프로토콜 변환 장치에 의해 처리될 수 있는 프로토콜 변환 처리의 수에 기초하여, 상기 검색된 프로토콜 변환 장치가 프로토콜 변환 처리를 실행할 수 있는지의 여부가 인식되는 제어 방법.
  8. 제6항에 있어서,
    상기 검색된 프로토콜 변환 장치가 프로토콜 변환 처리를 실행할 수 있는 것으로 상기 인식 단계에서 인식되는 경우, 동작 모드가 수면 모드(sleep mode)로 절환되는 제어 방법.
  9. 삭제
  10. 제6항에 있어서,
    상기 판별 단계에서, 상기 관리 단계에서 관리되는 프로토콜 처리 타겟으로서의 장치의 수가 미리 설정된 최대수를 넘는 것으로 판별된 경우에는, 수면 모드로의 절환을 나타내는 패킷이 네트워크 장치들에 멀티캐스트되는 제어 방법.
  11. 복수 종류의 프로토콜이 혼재하는 네트워크 시스템에서 프로토콜 변환 처리를 실행하는 제어 방법의 제어 프로그램을 기록한 컴퓨터 판독가능한 기록 매체로서,
    상기 제어 프로그램은,
    네트워크 상에서 소정의 프로토콜 처리를 실행하는 다른 프로토콜 변환 장치를 검색하기 위한 검색 요청을 상기 네트워크 상에 발행하고, 활성화 시에 검색 처리를 실행하는 검색 단계;
    상기 검색 단계에서, 상기 네트워크 상에서 상기 다른 프로토콜 변환 장치가 검색된 경우, 상기 검색된 프로토콜 변환 장치가 프로토콜 변환 처리를 실행할 수 있는지 또는 상기 검색된 프로토콜 변환 장치가 프로토콜 변환 처리를 실행하였는지를 인식하는 인식 단계;
    상기 인식 단계에서, 상기 검색된 프로토콜 변환 장치가 프로토콜 변환 처리를 실행할 수 없거나 또는 프로토콜 변환 처리를 실행하지 않는 것으로 인식된 경우, 프로토콜 변환 처리를 활성화시키는 활성화 단계;
    프로토콜 변환 처리 타겟으로서의 장치들을 관리하는 관리 단계; 및
    상기 인식 단계에서, 상기 검색된 프로토콜 변환 장치가 프로토콜 변환 처리를 실행할 수 없는 것으로 인식된 경우에는, 상기 관리 단계에서 관리되는 프로토콜 처리 타겟으로서의 장치의 수가 미리 설정된 최대수를 넘는지 여부를 판별하는 판별 단계
    를 컴퓨터에 실행시키며,
    상기 판별 단계에서, 상기 관리 단계에서 관리되는 프로토콜 처리 타겟으로서의 장치의 수가, 상기 미리 설정된 최대수를 넘지 않는 것으로 판별된 경우, 상기 활성화 단계에서 상기 프로토콜 변환 처리가 활성화되는 컴퓨터 판독가능한 기록 매체.
  12. 복수의 프로토콜을 사용하고 있는 장치를 포함하는 장치를 대상으로 프로토콜 변환 제어를 행하는 제어 방법으로서,
    소정의 장치로부터의 제2 프로토콜에 따르는 통신 내용을, 제1 프로토콜에 따른 통신 내용으로 프로토콜 변환을 행하는 변환 단계;
    상기 소정의 장치가 상기 제1 프로토콜을 지원하는지를 인식하는 인식 단계; 및
    상기 소정의 장치가 제1 프로토콜을 지원하는 것으로 상기 인식 단계에서 인식된 장치에 대해서는, 상기 제2 프로토콜에 따르는 통신 내용을 제1 프로토콜도 따르는 통신 내용으로 프로토콜 변환하는 것은 행하지 않도록 상기 변환 단계를 제어하는 제어 단계
    를 포함하는 제어 방법.
  13. 제12항에 있어서,
    장치를 검색하기 위한 검색 요청을 취득하는 취득 단계;
    테이블을 사용하여 프로토콜 변환 타겟으로서의 장치들의 리스트를 관리하는 관리 단계; 및
    상기 취득 단계에서 취득된 상기 검색 요청에 의해 검색된 장치가 상기 관리 단계에서 관리되는 테이블에 등록되어 있는지 여부를 인식하는 인식 단계를 더 포함하며,
    상기 관리 단계에서 관리되는 테이블에 상기 장치가 등록되어 있는 것으로 상기 인식 단계에서 인식되는 경우, 상기 장치는 상기 제1 프로토콜을 지원하는 것으로 상기 인식 단계에서 인식되는 제어 방법.
  14. 복수의 프로토콜을 사용하는 장치를 포함하는 장치를 대상으로 프로토콜 변환 제어를 행하는 제어 장치로서,
    소정의 장치로부터의 제2 프로토콜에 따르는 통신 내용을, 제1 프로토콜에 따른 통신 내용으로 프로토콜 변환을 행하는 변환 수단;
    상기 소정의 장치가 제1 프로토콜을 지원하는지를 인식하는 인식 수단; 및
    상기 소정의 장치가 상기 제1 프로토콜을 지원하는 것으로 상기 인식 수단에 의해 인식된 장치에 대해서는, 상기 제2 프로토콜에 따르는 통신 내용을 제1 프로토콜도 따르는 통신 내용으로 프로토콜 변환하는 것은 행하지 않도록 상기 변환 수단을 제어하는 제어 수단
    을 포함하는 제어 장치.
  15. 제14항에 있어서,
    장치를 검색하기 위한 검색 요청을 취득하는 취득 수단;
    테이블을 사용하여 프로토콜 변환 타겟으로서의 장치들의 리스트를 관리하는 관리 수단;
    상기 관리 수단에 의해 관리되는 테이블에 상기 취득 수단에 의해 취득된 상기 검색 요청에 의해 검색된 장치가 등록되어 있는지 여부를 인식하는 인식 수단을 더 포함하며,
    상기 관리 수단에 의해 관리되는 테이블에 상기 장치가 등록된 것으로 상기 인식 수단에 의해 인식되는 경우, 상기 장치는 상기 제1 프로토콜을 지원하는 것으로 상기 인식 수단에 의해 인식되는 제어 장치.
  16. 복수의 프로토콜을 사용하는 장치를 포함하는 장치를 대상으로 프로토콜 변환 제어를 행하는 처리를 컴퓨터에 실행시키는 제어 프로그램을 기록한 컴퓨터 판독가능한 기록 매체로서,
    상기 제어 프로그램은,
    소정의 장치로부터의 제2 프로토콜에 따르는 통신 내용을, 제1 프로토콜에 따른 통신 내용으로 프로토콜 변환을 행하는 변환 단계;
    상기 소정의 장치가 제1 프로토콜을 지원하는지를 인식하는 인식 단계; 및
    상기 소정의 장치가 상기 제1 프로토콜을 지원하는 것으로 상기 인식 단계에서 인식된 장치에 대해서는, 상기 제2 프로토콜에 따르는 통신 내용을 제1 프로토콜도 따르는 통신 내용으로 프로토콜 변환하는 것은 행하지 않도록 상기 변환 단계를 제어하는 제어 단계
    를 컴퓨터에 실행시키는 컴퓨터 판독가능한 기록 매체.
  17. 삭제
  18. 삭제
  19. 삭제
KR1020057021489A 2003-05-12 2004-05-12 프로토콜 변환 처리를 실행하는 장치, 방법, 및 기록 매체 KR100779790B1 (ko)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
JP2003132831A JP4401679B2 (ja) 2003-05-12 2003-05-12 制御装置、制御プログラム、制御方法
JPJP-P-2003-00132831 2003-05-12

Publications (2)

Publication Number Publication Date
KR20060021840A KR20060021840A (ko) 2006-03-08
KR100779790B1 true KR100779790B1 (ko) 2007-11-27

Family

ID=33432177

Family Applications (1)

Application Number Title Priority Date Filing Date
KR1020057021489A KR100779790B1 (ko) 2003-05-12 2004-05-12 프로토콜 변환 처리를 실행하는 장치, 방법, 및 기록 매체

Country Status (6)

Country Link
US (1) US7895361B2 (ko)
EP (1) EP1623328A4 (ko)
JP (1) JP4401679B2 (ko)
KR (1) KR100779790B1 (ko)
CN (1) CN100421094C (ko)
WO (1) WO2004100001A1 (ko)

Families Citing this family (30)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP4645164B2 (ja) * 2004-11-12 2011-03-09 セイコーエプソン株式会社 ネットワーク型プラグアンドプレイに対応したネットワーク装置の制御
JP4677270B2 (ja) 2005-04-08 2011-04-27 キヤノン株式会社 通信装置及び制御方法
US7499931B2 (en) * 2005-05-09 2009-03-03 International Business Machines Corporation Method and apparatus for approximate projection of XML documents
US20060259602A1 (en) * 2005-05-12 2006-11-16 Randall Stewart Method and apparatus for transport level server advertisement and discovery
JP5021184B2 (ja) * 2005-06-09 2012-09-05 富士通株式会社 機器情報提供装置および機器情報提供方法
JP4838564B2 (ja) * 2005-10-06 2011-12-14 キヤノン株式会社 ネットワークデバイス、その制御方法およびプログラム
US20070162662A1 (en) * 2005-12-23 2007-07-12 Duggan Brian J Methods and apparatuses for dynamically switching network protocols for use in a printing device
KR100714708B1 (ko) * 2006-01-12 2007-05-04 삼성전자주식회사 홈 네트워크에서 디바이스 간 호환성을 지원하는 미들웨어장치 및 그 방법
JP4508114B2 (ja) * 2006-01-12 2010-07-21 セイコーエプソン株式会社 ネットワーク型プラグアンドプレイに対応したネットワーク中継制御
JP4760415B2 (ja) 2006-02-06 2011-08-31 セイコーエプソン株式会社 コンピュータのデバイスドライバ実現方法
JP4995586B2 (ja) * 2006-03-01 2012-08-08 株式会社リコー プリンタ装置
JP4869033B2 (ja) * 2006-11-13 2012-02-01 キヤノン株式会社 ネットワークデバイス、ネットワークデバイス管理装置、ネットワークデバイスの制御方法、ネットワークデバイス管理方法、プログラム、記憶媒体
US8321546B2 (en) * 2007-01-10 2012-11-27 Ricoh Company, Ltd. Integrating discovery functionality within a device and facility manager
US20090059272A1 (en) * 2007-08-31 2009-03-05 Mitsugu Matsushita Printer auto installation
US8453164B2 (en) * 2007-09-27 2013-05-28 Ricoh Company, Ltd. Method and apparatus for reduction of event notification within a web service application of a multi-functional peripheral
JP5264161B2 (ja) * 2007-12-21 2013-08-14 キヤノン株式会社 情報処理装置、デバイス、情報処理装置の制御方法、及びコンピュータプログラム
US8155019B2 (en) 2008-01-07 2012-04-10 Canon Kabushiki Kaisha Information processing apparatus, device information display method, and computer-readable storage medium
JP5132417B2 (ja) * 2008-05-13 2013-01-30 キヤノン株式会社 データ処理装置、データ処理方法、及びコンピュータプログラム
US8560713B2 (en) * 2008-07-31 2013-10-15 Sap Ag Method and system for mediating enterprise service access for smart devices
JP5113095B2 (ja) * 2009-01-20 2013-01-09 株式会社リコー ネットワーク設定通知装置、ネットワーク設定方法、プログラムおよび記録媒体
US9247007B2 (en) * 2009-04-23 2016-01-26 Disney Enterprises, Inc. System and method for providing a peripheral control interface for extending media device functions
US8296358B2 (en) * 2009-05-14 2012-10-23 Hewlett-Packard Development Company, L.P. Method and system for journaling data updates in a distributed file system
US9043409B2 (en) * 2009-06-11 2015-05-26 Qualcomm Incorporated Methods and apparatus for a plug-in model for publishing structured meta-data based discovery
JP5600925B2 (ja) * 2009-11-20 2014-10-08 株式会社リコー サーバ装置、プリントシステム、プログラムおよび記録媒体
JP5665582B2 (ja) 2011-02-08 2015-02-04 キヤノン株式会社 画像形成装置、画像形成装置の制御方法、およびそのプログラム
JP6056640B2 (ja) * 2013-05-07 2017-01-11 富士通株式会社 通信装置，管理装置，処理方法，および処理プログラム
CN105450589B (zh) * 2014-07-31 2018-12-14 阿里巴巴集团控股有限公司 远程调用方法及系统
JP2018129714A (ja) * 2017-02-09 2018-08-16 株式会社東芝 プログラム及び情報処理装置
CN109981670B (zh) * 2019-04-02 2023-05-09 南京先维信息技术有限公司 一种区块链系统中的智能加密模组
CN110647411A (zh) * 2019-10-10 2020-01-03 广州趣丸网络科技有限公司 服务请求的处理方法及装置

Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JPH06332868A (ja) * 1993-05-21 1994-12-02 Matsushita Electric Ind Co Ltd システム多重化装置
JP2002196990A (ja) * 2000-12-27 2002-07-12 Kddi Corp サービス発見プロトコル変換ゲートウェイ
JP2003006133A (ja) * 2001-04-19 2003-01-10 Canon Inc 情報処理方法および制御プログラムおよび情報処理装置および周辺装置および応答方法および代理応答装置およびネットワークシステム

Family Cites Families (12)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5455851A (en) * 1993-07-02 1995-10-03 Executone Information Systems, Inc. System for identifying object locations
US6292202B1 (en) 1993-07-29 2001-09-18 Canon Kabushiki Kaisha Image processing method and apparatus for hardware processing image data received from a device using software processing
US6886035B2 (en) * 1996-08-02 2005-04-26 Hewlett-Packard Development Company, L.P. Dynamic load balancing of a network of client and server computer
US5848415A (en) * 1996-12-18 1998-12-08 Unisys Corporation Selective multiple protocol transport and dynamic format conversion in a multi-user network
DE60028874T2 (de) * 1999-07-06 2006-11-09 Canon K.K. System zum Suchen eines Gerätes im Netzwerk
JP2001268248A (ja) * 2000-03-21 2001-09-28 Fujitsu Ltd ネットワーク電話システム
JP2002245018A (ja) 2001-02-15 2002-08-30 Nippon Telegr & Teleph Corp <Ntt> 負荷分散システム
EP1259037A1 (en) * 2001-05-18 2002-11-20 TELEFONAKTIEBOLAGET L M ERICSSON (publ) Method and devices for the interworking of nodes
EP1330100B1 (en) 2002-01-21 2008-07-30 Canon Kabushiki Kaisha Service providing system
US7443862B2 (en) 2002-01-22 2008-10-28 Canon Kabushiki Kaisha Apparatus connected to network, and address determination program and method
JP4051958B2 (ja) * 2002-02-25 2008-02-27 幸雄 米田 バイオリアクターを備えた温室
JP3715954B2 (ja) 2002-07-12 2005-11-16 キヤノン株式会社 情報処理装置、情報処理方法、制御プログラム、ネットワークシステム

Patent Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JPH06332868A (ja) * 1993-05-21 1994-12-02 Matsushita Electric Ind Co Ltd システム多重化装置
JP2002196990A (ja) * 2000-12-27 2002-07-12 Kddi Corp サービス発見プロトコル変換ゲートウェイ
JP2003006133A (ja) * 2001-04-19 2003-01-10 Canon Inc 情報処理方法および制御プログラムおよび情報処理装置および周辺装置および応答方法および代理応答装置およびネットワークシステム

Also Published As

Publication number Publication date
CN100421094C (zh) 2008-09-24
KR20060021840A (ko) 2006-03-08
EP1623328A4 (en) 2012-03-14
US20060184510A1 (en) 2006-08-17
CN1788258A (zh) 2006-06-14
EP1623328A1 (en) 2006-02-08
WO2004100001A1 (en) 2004-11-18
US7895361B2 (en) 2011-02-22
JP4401679B2 (ja) 2010-01-20
JP2004334751A (ja) 2004-11-25

Similar Documents

Publication Publication Date Title
KR100779790B1 (ko) 프로토콜 변환 처리를 실행하는 장치, 방법, 및 기록 매체
KR100886074B1 (ko) 네트워크 서비스 시스템, 서비스 대행 처리 방법, 및 그 프로그램을 저장한 컴퓨터 판독가능 기억 매체
US8205212B2 (en) Information processing apparatus, information processing method, alternate response apparatus, response method, control program, and network system
JP4416563B2 (ja) ネットワークデバイス管理装置及びその制御方法、並びに、コンピュータプログラム及びコンピュータ可読記憶媒体
US9081526B2 (en) Peripheral device control system and method
JP3915797B2 (ja) プラグアンドプレイ機能を有するフレームワークおよびその再構成方法
US20070136485A1 (en) Information processing apparatus
JP2007122376A (ja) ネットワークプリントシステム及びネットワーク周辺装置及び情報処理装置とプログラム
US20110167151A1 (en) Event proxy notification apparatus and method of controlling the same and program
US8291089B2 (en) Image processing device, control method therefor, and program
JP4827943B2 (ja) 情報処理装置、ネットワークシステム、クライアント装置、情報処理方法、及び記憶媒体
JP4912093B2 (ja) 情報処理方法、情報処理装置、プログラム及び記憶媒体
JP2009020916A (ja) 制御装置、制御プログラム、制御方法
JP4378372B2 (ja) 情報処理方法、情報処理装置、及び記憶媒体
KR20080082385A (ko) 액션 처리 방법, 피제어 장치의 제어 방법, 피제어 장치 및제어 포인트

Legal Events

Date Code Title Description
A201 Request for examination
E902 Notification of reason for refusal
E701 Decision to grant or registration of patent right
GRNT Written decision to grant
G170 Re-publication after modification of scope of protection [patent]
FPAY Annual fee payment

Payment date: 20121023

Year of fee payment: 6

FPAY Annual fee payment

Payment date: 20131029

Year of fee payment: 7

FPAY Annual fee payment

Payment date: 20141028

Year of fee payment: 8

FPAY Annual fee payment

Payment date: 20151023

Year of fee payment: 9