JP7081257B2 - 情報処理装置及び情報処理プログラム - Google Patents

Description

本開示は、通常モードとスリープモードとを選択的に実行可能な情報処理装置及び情報処理プログラムに関する。

メインコントローラーとサブコントローラーとを有する情報処理装置において、スリープモード時に、サブコントローラーが、ネットワークに接続された外部機器から受信したクエリに応答（所謂、代理応答proxy response）する技術が知られている（特許文献１）。

特開２０１０－０９４９２５号公報

スリープモード時に、サブコントローラーが応答できないタイプのクエリを受信すると、サブコントローラーは、メインコントローラーに復帰（ウェイクアップ）を要求し、メインコントローラーにクエリを転送する。メインコントローラーは、スリープモードから通常モードに復帰し、クエリに応答する。サブコントローラーが応答できるか否か判断できないタイプのクエリを受信したときも同様である。

情報処理装置の省エネルギーの観点から、スリープモード時に通常モードに復帰することなく、サブコントローラーがより多くのタイプのクエリに対して応答することが望ましい。

本開示の一形態に係る情報処理装置は、
mDNS（Multicast Domain Name System）プロトコルに基づく名前解決クエリに対するリスポンスを生成するのに用いられる名前解決ＲＲ（Resource Record）を含む代理応答データベースを記憶するサブメモリーと、サブプロセッサーとを有するサブコントローラーと、
前記mDNSプロトコルに基づくサービスディスカバリクエリに対するリスポンスを生成するのに用いられるサービスディスカバリＲＲを記憶するメインメモリーと、メインプロセッサーとを有し、スリープモードに移行及び前記スリープモードから復帰するときに前記サブプロセッサーに通知するメインコントローラーと、
ネットワークに接続された外部機器と通信可能な通信インターフェースと
を具備し、
前記スリープモード時に、前記サブプロセッサーは、
mDNSクエリを前記通信インターフェースを介して前記外部機器から受信すると、
前記mDNSクエリがサービスディスカバリクエリであるか否かを判断し、
前記mDNSクエリがサービスディスカバリクエリでないと判断すると、
前記mDNSクエリを名前解決クエリと判断し、前記名前解決ＲＲに基づき前記リスポンスを生成し、前記リスポンスを前記通信インターフェースを介して前記外部機器に送信する。

サブコントローラーは、スリープモード時にmDNSクエリパケットを受信した場合、サービスディスカバリクエリでなければ（名前解決クエリであれば）、通常モードに復帰せずスリープモードのまま応答する。これにより、スリープモードから通常モードに復帰する機会が減り、サブコントローラーが代理応答する機会が増えるので、省エネルギー性能が向上する。

前記サブプロセッサーは、
前記mDNSクエリに記述された情報の一部に基づき、前記mDNSクエリがサービスディスカバリクエリか否かを判断する。

具体的には、以下の通りである。

前記サブプロセッサーは、
前記mDNSクエリに記述されたQNAME（名前）の一部に記述された情報と、QTYPE（種別）に記述された情報とに基づき、前記mDNSクエリがサービスディスカバリクエリか否かを判断する。

より具体的には、以下の通りである。

前記サブプロセッサーは、
前記mDNSクエリにおいて、
（１）前記QNAMEの末尾が「_udp.local」、前記QTYPEが「PTR」、
（２）前記QNAMEの末尾が「_tcp.local」、前記QTYPEが「PTR」、
（３）前記QNAMEの先頭がデバイス名、前記QNAMEの末尾が「_tcp.local」、又は
（４）前記QNAMEの先頭がデバイス名、前記QNAMEの末尾が「_udp.local」
と判断すると、前記mDNSクエリがサービスディスカバリクエリであると判断する。

この方法により、サブプロセッサーは、mDNSクエリパケットがサービスディスカバリクエリパケットか否かを確実に判断できる。

前記サブメモリーは、さらに、前記情報処理装置がサポートしないサービスを登録した非サポートサービスデータベースを記憶し、
前記サブプロセッサーは、
前記mDNSクエリがサービスディスカバリクエリであると判断すると、
前記mDNSクエリに記述されたサービスが、前記非サポートサービスデータベースに登録されているか否かを判断し、
前記mDNSクエリに記述された前記サービスが、前記非サポートサービスデータベースに登録されていないと判断すると、
前記メインプロセッサーに、前記スリープモードからの復帰を要求し、
前記メインプロセッサーに、前記mDNSクエリを転送する。

サブコントローラーは、スリープモード時にmDNSクエリパケットを受信した場合、サービスディスカバリクエリであり、且つ、mDNSクエリに記述されたサービスが、非サポートサービスデータベースに登録されていない場合に限り、スリープモードから通常モードに復帰する。これにより、スリープモードから通常モードに復帰する機会が減り、サブコントローラーが代理応答する機会が増えるので、省エネルギー性能が向上する。

前記メインプロセッサーは、
前記サブプロセッサーからの前記要求に応じて前記スリープモードから復帰し、
前記サブプロセッサーから前記サービスディスカバリクエリである前記mDNSクエリを受信し、
前記mDNSクエリに記述された前記サービスが、前記情報処理装置がサポートするサービスか否かを判断し、
前記mDNSクエリに記述された前記サービスが、前記情報処理装置がサポートしないサービスであると判断すると、
前記mDNSクエリに記述された前記サービスを、前記非サポートサービスデータベースに登録する
情報処理装置。

これにより、次回、スリープモード時にサブコントローラーが同じmDNSクエリを受信した場合、mDNSクエリに記述されたサービスは非サポートサービスデータベースに登録されているので、サブコントローラーは、メインコントローラーを復帰させる必要が無い。これにより、スリープモードから通常モードに復帰する機会が時間を追うごとに減っていくので、省エネルギー性能が時間を追うごとに向上していく。

前記非サポートサービスデータベースは、前記情報処理装置がサポートしないサービスのNAME（名前）及びTYPE（種別）を登録し、
前記サブプロセッサーは、
前記mDNSクエリに記述されたQNAME（名前）及びQTYPE（種別）の組み合わせが、前記非サポートサービスデータベースに登録されているか否かに基づき、前記mDNSクエリに記述されたサービスが、前記非サポートサービスデータベースに登録されているか否かを判断する。

この方法により、サブプロセッサーは、mDNSクエリに記述されたサービスが、非サポートサービスデータベースに登録されているか否かを確実に判断できる。

前記サブプロセッサーは、
前記mDNSクエリに記述されたサービスが、前記非サポートサービスデータベースに登録されていると判断すると、前記mDNSクエリを破棄する。

これにより、サブコントローラーは、メインコントローラーを復帰させる必要が無いので、省エネルギー性能が向上する。

本開示の一形態に係る情報処理プログラムは、
mDNS（Multicast Domain Name System）プロトコルに基づく名前解決クエリに対するリスポンスを生成するのに用いられる名前解決ＲＲ（Resource Record）を含む代理応答データベースを記憶するサブメモリーと、サブプロセッサーとを有するサブコントローラー、前記mDNSプロトコルに基づくサービスディスカバリクエリに対するリスポンスを生成するのに用いられるサービスディスカバリＲＲを記憶するメインメモリーと、メインプロセッサーとを有し、スリープモードに移行及び前記スリープモードから復帰するときに前記サブプロセッサーに通知するメインコントローラー、及びネットワークに接続された外部機器と通信可能な通信インターフェースとを備える情報処理装置の前記サブプロセッサーを、
前記メインコントローラーがスリープモード時に、
mDNSクエリを前記通信インターフェースを介して前記外部機器から受信させ、
前記mDNSクエリがサービスディスカバリクエリであるか否かを判断させ、
前記mDNSクエリがサービスディスカバリクエリでないと判断すると、
前記mDNSクエリを名前解決クエリと判断し、前記名前解決ＲＲに基づき前記リスポンスを生成し、前記リスポンスを前記通信インターフェースを介して前記外部機器に送信させる。

本開示によれば、スリープモード時に通常モードに復帰することなく、サブコントローラーがより多くのタイプのクエリに対して応答することができる。

なお、ここに記載された効果は必ずしも限定されるものではなく、本開示中に記載されたいずれかの効果であってもよい。

サービスディスカバリのためのmDNSクエリ及びリスポンスの例を示す。 サービスディスカバリＲＲの一例を示す。 名前解決のためのmDNSクエリ及びリスポンスの例を示す。 名前解決ＲＲの一例を示す。 本開示の一実施形態に係る情報処理装置の構成を示す。 mDNS代理応答プログラムのフローを示す。 代理応答データベースの一例を示す。 非サポートサービスデータべースの一例を示す。 サービスディスカバリプログラムのフローを示す。

以下、図面を参照しながら、まず（Ｉ）本開示の実施形態の前提となるmDNS（Multicast Domain Name System）プロトコルを説明し、次に（ＩＩ）本開示の実施形態を説明する。

Ｉ．mDNSプロトコル
１．概要
ｉＰｈｏｎｅ（登録商標）やｉＰａｄ（登録商標）などのＡｐｐｌｅ（登録商標）製デバイスは、mDNSプロトコルを用いて、サービスディスカバリ（DNS-SD、DNS based Service Discovery）と、名前解決とを行う。

サービスディスカバリは、機器がサポートするサービス（機能）の種別、通信ポート、プリントフォーマット等の情報を取得するためのプロトコルである。問い合わせ元の機器は、ネットワークに接続された複数の機器に、mDNSサービスディスカバリクエリをマルチキャストする。mDNSサービスディスカバリクエリを受信した機器は、応答すべきと判断すると、リスポンスパケットを生成し、問い合わせ元の機器に送信する。

名前解決は、ホスト名に基づき機器のIPアドレスを取得（正引き）したり、IPアドレスに基づき機器のホスト名を取得（逆引き）したりするためのプロトコルである。問い合わせ元の機器は、ネットワークに接続された複数の機器に、mDNS名前解決クエリをマルチキャストする。mDNS名前解決クエリを受信した機器は、応答すべきと判断すると、リスポンスパケットを生成し、問い合わせ元の機器に送信する。

２．mDNSプロトコルのサービスディスカバリ
典型的なサービスディスカバリのためのmDNSクエリ及びリスポンスを説明する。

図１は、サービスディスカバリのためのmDNSクエリ及びリスポンスの例を示す。
問い合わせ元の機器（以下、第１の機器と称する）３０が、第１のmDNSクエリパケット３１Ａを生成する。第１のmDNSクエリパケット３１Ａは、QNAME（名前）３２Ａと、QTYPE（種別）３３Ａとを含む。QNAME３２Ａには、問い合わせの対象であるサービスの種類が記述される。本例では、QNAME３２Ａに「_printer._tcp.local」（ローカルなプリンターでの印刷）が記述される。QTYPE３３Ａに「PTR」（Pointer）が記述される。「PTR」は、NAMEを指し示すポインターである。第１の機器３０は、生成した第１のmDNSクエリパケット３１Ａを、マルチキャストする。問い合わせに応答する機器（以下、第２の機器と称する）４０は、第１のmDNSクエリパケット３１Ａを受信する。

図２は、サービスディスカバリＲＲ（Resource Record）の一例を示す。
第２の機器４０は、サービスディスカバリＲＲ１１０をローカルに記憶している。サービスディスカバリＲＲ１１０は、サービス情報１１１（上位層）、デバイス名情報１１２（中位層）及びサービス詳細情報１１３（下位層）を含む階層構造のデータベースである。本例では、第２の機器４０は、画像形成装置（ＭＦＰ（Multifnction Peripheral））とする。

サービス情報１１１は、第２の機器４０がサポートするサービスの一覧である。本例では、サービス情報１１１は、「_printer._tcp.local」１１１Ａ（ローカルなプリンターでの印刷）、「_ipp._tcp.local」１１１Ｂ（Internet Printing Protocol、インターネットを介したリモートでの印刷）及び「_http_tcp.local」１１１Ｃ（Ｗｅｂサーバー）等のサービスを含む。

デバイス名情報１１２は、サービス情報１１１に含まれるサービスを実行するデバイスの名前である。デバイス名情報１１２の<DeviceName>には、実際には具体的なデバイス名が記述される。以下、具体的なデバイス名を「TaskalfaXXX」とする。

サービス詳細情報１１３は、デバイス名情報１１２に含まれる名前<DeviceName>のデバイスが実行するサービスの詳細情報である。「SRV」は、サービス情報（ポート番号）を意味する。「TXT」は、サービス付加情報（printフォーマット、adminURL等）を意味する。

第２の機器４０は、受信した第１のmDNSクエリパケット３１Ａから、QNAME３２Ａに記述された「_printer._tcp.local」と、QTYPE３３Ａに記述された「PTR」とを読み出す。第２の機器４０は、サービスディスカバリＲＲ１１０を参照し、サービス情報１１１から、QNAME３２Ａと完全一致する「_printer._tcp.local」１１１Ａを読み出す。第２の機器４０は、サービス情報「_printer._tcp.local」１１１Ａの直下の層であるデバイス名情報１１２から、QTYPE３３Ａ「PTR」に対応する「<DeviceName>._printer._tcp.local」１１２Ａ（本例では、「TaskalfaXXX._printer._tcp.local」）を読み出す。

第２の機器４０は、第１のmDNSリスポンスパケット４１Ａを生成する。第１のmDNSリスポンスパケット４１Ａは、第１のmDNSクエリパケット３１Ａに含まれるQNAME３２Ａと同じNAME４２Ａ「_printer._tcp.local」と、第１のmDNSクエリパケット３１Ａに含まれるQTYPE３３Ａと同じTYPE４３Ａ「PTR」と、DATA４４Ａとしてデバイス名情報１１２から読み出した「TaskalfaXXX._printer._tcp.local」１１２Ａとを含む。第２の機器４０は、生成した第１のmDNSリスポンスパケット４１Ａを、第１の機器３０に送信する。

第１の機器３０は、第２のmDNSクエリパケット３１Ｂ及び第３のmDNSクエリパケット３１Ｃをマルチキャストする。第２のmDNSクエリパケット３１Ｂにおいて、QNAME３２Ｂに「TaskalfaXXX._printer._tcp.local」が記述され、QTYPE３３Ｂに「SRV」が記述される。第３のmDNSクエリパケット３１Ｃにおいて、QNAME３２Ｃに「TaskalfaXXX._printer._tcp.local」が記述され、QTYPE３３Ｃに「TXT」が記述される。

第２の機器４０は、受信した第２のmDNSクエリパケット３１Ｂから、QNAME３２Ｂに記述された「TaskalfaXXX._printer._tcp.local」と、QTYPE３３Ｂに記述された「SRV」とを読み出す。第２の機器４０は、サービスディスカバリＲＲ１１０を参照し、デバイス名情報１１２から、QNAME３２Ｂと完全一致する「<DeviceName>._printer._tcp.local」１１２Ａ（本例では、「TaskalfaXXX._printer._tcp.local」）を読み出す。第２の機器４０は、デバイス名情報「<DeviceName>._printer._tcp.local」１１２Ａ（本例では、「TaskalfaXXX._printer._tcp.local」）の直下の層であるサービス詳細情報１１３から、QTYPE３３Ｂ「SRV」に対応する「ポート番号等」１１３Ｂを読み出す。

第２の機器４０は、第２のmDNSリスポンスパケット４１Ｂを生成する。第２のmDNSリスポンスパケット４１Ｂは、第２のmDNSクエリパケット３１Ｂに含まれるQNAME３２Ｂと同じNAME４２Ｂ「TaskalfaXXX._printer._tcp.local」と、第２のmDNSクエリパケット３１Ｂに含まれるQTYPE３３Ｂと同じTYPE４３Ｂ「SRV」と、DATA４４Ｂとしてサービス詳細情報１１３から読み出した「ポート番号等」１１３Ｂを含む。

第２の機器４０は、受信した第３のmDNSクエリパケット３１Ｃから、QNAME３２Ｃに記述された「TaskalfaXXX._printer._tcp.local」と、QTYPE３３Ｃに記述された「TXT」とを読み出す。第２の機器４０は、サービスディスカバリＲＲ１１０を参照し、デバイス名情報１１２から、QNAME３２Ｃと完全一致する「<DeviceName>._printer._tcp.local」１１２Ａ（本例では、「TaskalfaXXX._printer._tcp.local」）を読み出す。第２の機器４０は、デバイス名情報「<DeviceName>._printer._tcp.local」１１２Ａ（本例では、「TaskalfaXXX._printer._tcp.local」）の直下の層であるサービス詳細情報１１３から、QTYPE３３Ｃ「TXT」に対応する「printフォーマットなど」１１３Ｃを読み出す。

第２の機器４０は、第３のmDNSリスポンスパケット４１Ｃを生成する。第３のmDNSリスポンスパケット４１Ｃは、第３のmDNSクエリパケット３１Ｃに含まれるQNAME３２Ｃと同じNAME４２Ｃ「TaskalfaXXX._printer._tcp.local」と、第３のmDNSクエリパケット３１Ｃに含まれるQTYPE３３Ｃと同じTYPE４３Ｃ「TXT」と、DATA４４Ｃとしてサービス詳細情報１１３から読み出した「printフォーマットなど」１１３Ｃを含む。第２の機器４０は、生成した第２のmDNSリスポンスパケット４１Ｂ及び第３のmDNSリスポンスパケット４１Ｃを、第１の機器３０に送信する。

３．mDNSプロトコルの名前解決
図３は、名前解決のためのmDNSクエリ及びリスポンスの例を示す。

（１）例１
問い合わせ元の機器（以下、第１の機器と称する）５０が、第１のmDNSクエリパケット５１Ａを生成する。第１のmDNSクエリパケット５１Ａは、QNAME（名前）５２Ａと、QTYPE（種別）５３Ａとを含む。QNAME５２Ａには、問い合わせの対象であるホスト名が記述される。本例では、QNAME５２Ａに「<HostName>.local」として「KM123456.local」が記述される。QTYPE５３Ａに「A」が記述される。「A」は、IPv4名前解決を意味する。第１の機器５０は、生成した第１のmDNSクエリパケット５１Ａを、マルチキャストする。問い合わせに応答する機器（以下、第２の機器と称する）６０は、第１のmDNSクエリパケット５１Ａを受信する。

図４は、名前解決ＲＲの一例を示す。
第２の機器６０は、名前解決ＲＲ２１０をローカルに記憶している。本例では、名前解決ＲＲ２１０は、第１のレコード２１１、第２のレコード２１２及び複数の第３のレコード２１３を有する。

第１のレコード２１１は、ホスト名からIPアドレス（IPv4アドレス、IPv6アドレス）を解決（正引き）するのに用いられる。言い換えれば、名前解決クエリで「<HostName>.local」について「A」（IPv4名前解決を意味する）を問い合わせられた場合、第１のレコード２１１に「A」として記述されたIPv4アドレスを応答する。同様に、名前解決クエリで「<HostName>.local」について「AAAA」（IPv6名前解決を意味する）を問い合わせられた場合、第１のレコード２１１に「AAAA」として記述されたIPv6アドレス（複数）を応答する。<HostName>には、実際には具体的なホスト名が記述される。本例では第２の機器６０の<HostName>を「KM123456」とする。「IPv4アドレス」には、実際には具体的なアドレスが記述される。本例では第２の機器６０のIPv4アドレスを「192.168.0.1」とする。「IPv6アドレス[0]」及び「IPv6アドレス[1]」には、実際には具体的なIPv6アドレスが記述される。本例では第２の機器６０の「IPv6アドレス[0]」を「2001::1」、「IPv6アドレス[1]」を「fe80::1」とする。

第２のレコード２１２は、IPアドレス（IPv4アドレス）からホスト名を解決（逆引き）するのに用いられる。言い換えれば、名前解決クエリで「<IPv4addr>.in-addr.arpa」について「PTR」（NAMEを指し示す）を問い合わせられた場合、第２のレコード２１２に「PTR」として記述されたホスト名「<HostName>.local」を応答する。<IPv4addr>には、実際には具体的なIPv4アドレスが逆順で記述される。例えば、第２の機器６０のIPv4アドレスが「192.168.0.1」の場合、第２のレコード２１２の<IPv4addr>には、「1.0.168.192」が記述される。

各第３のレコード２１３は、IPアドレス（IPv6アドレス）からホスト名を解決（逆引き）するのに用いられる。言い換えれば、名前解決クエリで「<IPv6addr[0]>.in-addr.arpa」について「PTR」（NAMEを指し示す）を問い合わせられた場合、第３のレコード２１３に「PTR」として記述されたホスト名「<HostName>.local」を応答する。<IPv6addr[0]>又は<IPv6addr[1]>には、実際には具体的なIPv6アドレスが記述される。本例では第２の機器６０の<IPv6addr[0]>を「2001::1」、<IPv6addr[1]>を「fe80::1」とする。IPv6アドレスの数と同じ数だけ、第３のレコード２１３がある。

第２の機器６０は、受信した第１のmDNSクエリパケット５１Ａから、QNAME５２Ａに記述された「KM123456.local」と、QTYPE５３Ａに記述された「A」とを読み出す。第２の機器６０は、名前解決ＲＲ２１０を参照し、第１のレコード２１１から、QNAME５２Ａと完全一致する「KM123456.local」に関連付けられたQTYPE５３Ａ「A」に対応するIPv4アドレス（本例では、「192.168.0.1」）２１２Ａを読み出す。

第２の機器６０は、第１のmDNSリスポンスパケット６１Ａを生成する。第１のmDNSリスポンスパケット６１Ａは、第１のmDNSクエリパケット５１Ａに含まれるQNAME５２Ａと同じNAME６２Ａ「KM123456.local」と、第１のmDNSクエリパケット５１Ａに含まれるQTYPE５３Ａと同じTYPE６３Ａ「A」と、DATA６４Ａとして第１のレコード２１１から読み出したIPv4アドレス「192.168.0.1」２１２Ａを含む。第２の機器６０は、生成した第１のmDNSリスポンスパケット６１Ａを、第１の機器５０に送信する。

（２）例２
第１の機器５０は、第２のmDNSクエリパケット５１Ｂをマルチキャストする。第２のmDNSクエリパケット５１Ｂにおいて、QNAME５２Ｂに「1.0.168.192.in-addr.arpa」が記述される。QTYPE５３Ｂに「PTR」が記述される。

第２の機器６０は、受信した第２のmDNSクエリパケット５１Ｂから、QNAME５２Ｂに記述された「1.0.168.192.in-addr.arpa」と、QTYPE５３Ｂに記述された「PTR」とを読み出す。第２の機器６０は、名前解決ＲＲ２１０を参照し、第２のレコード２１２から、QNAME５２Ｂと完全一致する「1.0.168.192.in-addr.arpa」に関連付けられたQTYPE５３Ｂ「PTR」に対応するホスト名（本例では、「KM123456.local」）２１２Ｂを読み出す。

第２の機器６０は、第２のmDNSリスポンスパケット６１Ｂを生成する。第２のmDNSリスポンスパケット６１Ｂは、第２のmDNSクエリパケット５１Ｂに含まれるQNAME５２Ｂと同じNAME６２Ｂ「1.0.168.192.in-addr.arpa」と、第２のmDNSクエリパケット５１Ｂに含まれるQTYPE５３Ｂと同じTYPE６３Ｂ「PTR」と、DATA６４Ｂとして第２のレコード２１２から読み出したホスト名「KM123456.local」２１２Ｂを含む。第２の機器６０は、生成した第２のmDNSリスポンスパケット６１Ｂを、第１の機器５０に送信する。

（３）例３
第１の機器５０は、第３のmDNSクエリパケット５１Ｃをマルチキャストする。第３のmDNSクエリパケット５１Ｃにおいて、QNAME５２Ｃに「KM123456.local」が記述される。QTYPE５３Ｃに「AAAA」が記述される。

第２の機器６０は、受信した第３のmDNSクエリパケット５１Ｃから、QNAME５２Ｃに記述された「KM123456.local」と、QTYPE５３Ｃに記述された「AAAA」とを読み出す。第２の機器６０は、名前解決ＲＲ２１０を参照し、第１のレコード２１１から、QNAME５２Ｃと完全一致する「KM123456.local」に関連付けられたQTYPE５３Ｃ「AAAA」に対応するIPv6アドレス（本例では、「2001::1」、「fe80::1」）２１１Ｃ及び２１１Ｄを読み出す。

第２の機器６０は、第３のmDNSリスポンスパケット６１Ｃを生成する。第３のmDNSリスポンスパケット６１Ｃは、第３のmDNSクエリパケット５１Ｃに含まれるQNAME５２Ｃと同じNAME６２Ｃ「KM123456.local」と、第３のmDNSクエリパケット５１Ｃに含まれるQTYPE５３Ｃと同じTYPE６３Ｃ「AAAA」と、DATA６４Ｃとして第１のレコード２１１から読み出したIPv6アドレス「2001::1」２１１Ｃを含む。

第２の機器６０は、第４のmDNSリスポンスパケット６１Ｄを生成する。第４のmDNSリスポンスパケット６１Ｄは、第３のmDNSクエリパケット５１Ｃに含まれるQNAME５２Ｃと同じNAME６２Ｄ「KM123456.local」と、第３のmDNSクエリパケット５１Ｃに含まれるQTYPE５３Ｃと同じTYPE６３Ｄ「AAAA」と、DATA６４Ｄとして第１のレコード２１１から読み出したIPv6アドレス「fe80::1」２１１Ｄを含む。第２の機器６０は、生成した第３のmDNSリスポンスパケット６１Ｃ及び第４のmDNSリスポンスパケット６１Ｄを、第１の機器５０に送信する。

４．小括
多くの電子機器は、省エネルギーのため、通常モードと、スリープモード（メインコントローラーの電源をオフし、サブコントローラーが応答（代理応答）する）とを選択的に実行可能である。そのような電子機器において、スリープモード時にサブコントローラーがmDNSクエリパケットを受信した場合、典型的には、常に、通常モードに復帰した上でメインコントローラーが処理及び応答する。ＲＲのデータ量が大きく（図２及び図４参照）、リスポンスパケットを生成するための処理も複雑（図１及び図３参照）である故、低スペックのサブコントローラーでは処理できないためである。

しかしながら、省エネルギー性能を上げるには、スリープモード時にサブコントローラーがmDNSクエリパケットを受信した場合、可能な限り、通常モードに復帰せずスリープモードのままサブコントローラーが応答（代理応答）することが望ましい。そこで、以下の実施形態によれば、スリープモード時にサブコントローラーがmDNSクエリパケットを受信した場合、特定の条件下において、通常モードに復帰せずスリープモードのまま、サブコントローラーが応答（代理応答）する。

ＩＩ．実施形態
１．情報処理装置の構成
図５は、本開示の一実施形態に係る情報処理装置の構成を示す。

情報処理装置１０は、画像形成装置（ＭＦＰ等）又はパーソナルコンピューター（デスクトップ、ラップトップ、タブレット、スマートフォン、ウェアラブル等の各タイプを含む）等である。

情報処理装置１０は、互いにバスで接続された、メインコントローラー１００、サブコントローラー２００、通信インターフェース３００及びスイッチャー４００を有する。

メインコントローラー１００は、通常モード時に各種処理を実行する。メインコントローラー１００は、メインプロセッサー（ＣＰＵ、Central Processing Unit）１０１、メインＲＯＭ（Read Only Memory）１０２、メインＲＡＭ（Random Access Memory）１０３（メインメモリー）及び専用のハードウェア回路等を有する。情報処理装置１０が画像形成装置である場合、メインコントローラー１００には、イメージスキャナー、プリンター、画像メモリー、表示装置、操作装置、不揮発性の記憶装置（ＨＤＤ（Hard Disk Drive）等）が接続される（図示及び説明を省略）。メインコントローラー１００は、これらのハードウェア（図示せず）、通信インターフェース３００及びスイッチャー４００を制御する。

メインプロセッサー１０１は、メインＲＯＭ１０２が記憶する各種プログラム（サービスディスカバリプログラム１２０を含む）をメインＲＡＭ１０３にロードして実行する。メインプロセッサー１０１は、特定の条件（ユーザーの操作やネットワークを介した情報の受信が一定時間無いなど）で、通常モードからスリープモードに移行する。通常モードはメインコントローラー１００の電源（図示せず）がオンの状態であり、スリープモードはメインコントローラー１００の電源がオフの状態である。メインプロセッサー１０１は、通常モードからスリープモードに移行するときと、スリープモードから通常モードに復帰するときとに、サブコントローラー２００のサブプロセッサー２０１と、スイッチャー４００とに通知する。

メインＲＯＭ１０２は、サービスディスカバリプログラム１２０を記憶する。サービスディスカバリプログラム１２０は、mDNSプロトコルに基づくサービスディスカバリクエリに対して応答する（図１と同様の方法）ためのプログラムである。

メインＲＡＭ１０３（メインメモリー）は、サービスディスカバリＲＲ１１０を記憶する。サービスディスカバリＲＲ１１０（図２と同様の構造）は、メインプロセッサー１０１がサービスディスカバリプログラム１２０を実行する際に参照するデータベースである。例えば、メインプロセッサー１０１は、通常モードからスリープモードに移行するタイミングで、サービスディスカバリＲＲ１１０を生成してメインＲＡＭ１０３に書き込めばよい。

サブコントローラー２００は、スリープモード時に、ネットワークＮから受信したクエリに対して応答（所謂、代理応答）する。サブコントローラー２００は、サブプロセッサー（ＣＰＵ）２０１、サブＲＯＭ２０２、サブＲＡＭ２０３（サブメモリー）及び専用のハードウェア回路等を有する。サブコントローラー２００の各デバイスは、メインコントローラー１００の各デバイスに比べてプアなスペックであり、低消費電力で動作する。

サブプロセッサー２０１は、メインプロセッサー１０１から、通常モードからスリープモードに移行した通知を受ける。スリープモード時に、サブプロセッサー２０１は、サブＲＯＭ２０２が記憶する各種代理応答プログラム（mDNS代理応答プログラム２２０を含む）をサブＲＡＭ２０３にロードして実行する。サブプロセッサー２０１は、受信したクエリがサブプロセッサー２０１が応答（代理応答）できないタイプのクエリや、応答（代理応答）できないタイプのクエリであれば、メインプロセッサー１０１に、スリープモードから通常モードへの復帰を要求し、クエリを転送する。

サブＲＯＭ２０２は、mDNS代理応答プログラム２２０を記憶する。mDNS代理応答プログラム２２０は、mDNSプロトコルに基づく名前解決クエリに対して応答する（図３と同様の方法）ためのプログラムである。

サブＲＡＭ２０３（サブメモリー）は、代理応答データベース２３０と、非サポートサービスデータべース２４０とを記憶する。例えば、メインプロセッサー１０１は、通常モードからスリープモードに移行するタイミングで、代理応答データベース２３０と、非サポートサービスデータべース２４０とを生成してサブＲＡＭ２０３に書き込めばよい。

図７は、代理応答データベースの一例を示す。

代理応答データベース２３０は、サブプロセッサー２０１が代理応答（mDNSプロトコル及び他のプロトコル）を実行する際に、クエリに対するリスポンスを生成するのに参照するデータベースである。代理応答データベース２３０は、名前解決ＲＲ２１０（図４）が記憶するデータを含む。名前解決ＲＲ２１０が記憶するデータは、サブプロセッサー２０１がmDNS代理応答プログラム２２０を実行する際に参照するデータである。言い換えれば、代理応答データベース２３０は、名前解決ＲＲ２１０（図４）をデータベースの構造で記憶する。具体的には、代理応答データベース２３０は、NAME２３１、TYPE２３２及びRDATA２３３の組み合わせを登録する。

図８は、非サポートサービスデータべースの一例を示す。

非サポートサービスデータべース２４０は、情報処理装置１０がサポートしないサービスを登録したデータベースである。具体的には、非サポートサービスデータべース２４０は、NAME２４１及びTYPE２４２の組み合わせを登録する。

通信インターフェース３００は、ネットワークＮに接続された外部機器と通信可能である。通信インターフェース３００は、Ethernet（登録商標）等のインターフェースにおいて、論理信号を実際の電気的な信号に変換する物理層（Physical Layer）のインターフェースである。通信インターフェース３００は、ネットワークＮから受信したEthernet（登録商標）フレームやパケット等のデータ（以下、「パケット」と呼ぶ。）を、スイッチャー４００を介してメインコントローラー１００又はサブコントローラー２００へ出力する。通信インターフェース３００は、スイッチャー４００を介してメインコントローラー１００又はサブコントローラー２００から出力されたパケットを、ネットワークＮへ送信する。

スイッチャー４００は、通常モードからスリープモードに移行するときと、スリープモードから通常モードに復帰するときとに、メインプロセッサー１０１から、通知を取得する。スイッチャー４００は、通常モードのとき、通信インターフェース３００がネットワークＮから受信したパケットをメインコントローラー１００へ出力し、メインコントローラー１００から取得したパケットを通信インターフェース３００へ出力する。スイッチャー４００は、スリープモードのとき、通信インターフェース３００がネットワークＮから受信したパケットをサブコントローラー２００へ出力し、サブコントローラー２００から取得したパケットを通信インターフェース３００へ出力する。

２．mDNS代理応答プログラムのフロー
図６は、mDNS代理応答プログラムのフローを示す。

サブプロセッサー２０１は、スリープモード時にmDNS代理応答プログラム２２０を実行するとき、以下のフローで処理を実行する。

スリープモード時に、サブプロセッサー２０１は、mDNSクエリパケットを通信インターフェース３００を介して外部機器（図示せず）から受信する（ステップＳ１０１）。

サブプロセッサー２０１は、受信したmDNSクエリパケットがサービスディスカバリクエリパケットであるか否かを判断する（ステップＳ１０２）。具体的には、サブプロセッサー２０１は、mDNSクエリパケットに記述された情報の一部に基づき、mDNSクエリパケットがサービスディスカバリクエリパケットか否かを判断する。より具体的には、サブプロセッサー２０１は、mDNSクエリパケットに記述されたQNAME（名前）の一部に記述された情報と、QTYPE（種別）に記述された情報とに基づき、mDNSクエリパケットがサービスディスカバリクエリパケットか否かを判断する。

さらに具体的には、サブプロセッサー２０１は、mDNSクエリパケットにおいて、
（１）QNAMEの末尾が「_udp.local」、QTYPEが「PTR」、
（２）QNAMEの末尾が「_tcp.local」、QTYPEが「PTR」、
（３）QNAMEの先頭がデバイス名、QNAMEの末尾が「_tcp.local」、又は
（４）QNAMEの先頭がデバイス名、QNAMEの末尾が「_udp.local」
と判断すると、mDNSクエリパケットがサービスディスカバリクエリパケットであると判断する。

一般的に、mDNSクエリパケットを受信すると、mDNSクエリパケットに含まれるQNAME及びQTYPEと、電子機器が持つＲＲのNAME及びTYPEとが完全一致するか否かを判断し、完全一致すると、mDNSリスポンスパケットを生成及び送信する。言い換えれば、一般的には、mDNSクエリパケットの一部に記述された情報だけを抽出することは無いし、それに基づき何かを判断することも無い。これに対して、本実施形態では、mDNSクエリパケットに記述されたQNAMEの一部に記述された情報と、QTYPEに記述された情報とに基づき、mDNSクエリパケットがサービスディスカバリクエリパケットか否かを判断する。この方法により、サブプロセッサー２０１は、mDNSクエリパケットがサービスディスカバリクエリパケットか否かを確実に判断できる。

図１を参照し、一例として、第１のmDNSクエリパケット３１Ａは、QNAME３２Ａの末尾が「_tcp.local」、QTYPE３３Ａが「PTR」であるから、条件（２）に該当する。このため、サブプロセッサー２０１は、第１のmDNSクエリパケット３１Ａがサービスディスカバリクエリパケットであると判断する。別の例として、第２のmDNSクエリパケット３１Ｂは、QNAME３２Ｂの先頭がデバイス名「TaskalfaXXX」、QNAMEの末尾３２Ｂが「_tcp.local」であるから、条件（３）に該当する。このため、サブプロセッサー２０１は、第２のmDNSクエリパケット３１Ｂがサービスディスカバリクエリパケットであると判断する。第３のmDNSクエリパケット３１Ｃも同様である。

一方、図３を参照し、第１のmDNSクエリパケット５１Ａ、５１Ｂ及び５１Ｃは何れも、条件（１）、（２）、（３）及び（４）に該当しない。このため、サブプロセッサー２０１は、第１のmDNSクエリパケット５１Ａ、５１Ｂ及び５１Ｃは何れも、サービスディスカバリクエリパケットでないと判断する。

再び図６を参照し、サブプロセッサー２０１は、mDNSクエリパケットがサービスディスカバリクエリパケットでないと判断する（ステップＳ１０２、ＮＯ）。すると、サブプロセッサー２０１は、mDNSクエリパケットを名前解決クエリパケットと判断する。サブプロセッサー２０１は、mDNSクエリパケットに含まれるQNAME及びQTYPEと、名前解決ＲＲ２１０に含まれるNAME及びTYPEとが完全に一致すると（ステップＳ１０３、ＹＥＳ）、mDNSリスポンスパケットを生成する（図３と同様の方法）（ステップＳ１０４）。サブプロセッサー２０１は、通信インターフェース３００を介して外部機器に、mDNSリスポンスパケットを送信する（ステップＳ１０５）。

一方、サブプロセッサー２０１は、mDNSクエリパケットに含まれるQNAME及びQTYPEと、名前解決ＲＲ２１０に含まれるNAME及びTYPEとが完全に一致しなければ（ステップＳ１０３、ＮＯ）、mDNSクエリパケットを破棄する（ステップＳ１０６）。

一方、サブプロセッサー２０１は、mDNSクエリパケットがサービスディスカバリクエリパケットであると判断する（ステップＳ１０２、ＹＥＳ）。すると、サブプロセッサー２０１は、mDNSクエリパケットに記述されたQNAME及びQTYPEの組み合わせが、非サポートサービスデータベース２４０のNAME２４１及びTYPE２４２として登録されているか否かを判断する。（ステップＳ１０９）。

サブプロセッサー２０１は、mDNSクエリパケットに記述されたQNAME及びQTYPEの組み合わせが、非サポートサービスデータベース２４０に登録されていると判断する（ステップＳ１０９、ＹＥＳ）。この場合、サブプロセッサー２０１は、mDNSクエリパケットに記述されたサービスが、情報処理装置１０がサポートしないサービスである。従って、サブプロセッサー２０１は、mDNSクエリパケットを破棄する（ステップＳ１１０）。

一方、サブプロセッサー２０１は、DNSクエリパケットに記述されたQNAME及びQTYPEの組み合わせが、非サポートサービスデータベース２４０に登録されていないと判断する（ステップＳ１０９、ＮＯ）。この場合、サブプロセッサー２０１は、メインプロセッサー１０１に、スリープモードから通常モードへの復帰（ウェイクアップ）を要求する（ステップＳ１０７）。サブプロセッサー２０１は、メインプロセッサー１０１から、スリープモードから通常モードへの復帰の通知を受けると、メインプロセッサー１０１に、mDNSクエリパケットを転送する（ステップＳ１０８）。

３．サービスディスカバリプログラムのフロー
図９は、サービスディスカバリプログラムのフローを示す。

メインプロセッサー１０１は、サブプロセッサー２０１からの要求に応じてスリープモードから通常モードに復帰する。メインプロセッサー１０１は、サブプロセッサー２０１からmDNSクエリパケットを受信すると（ステップＳ２０１）、サービスディスカバリプログラム１２０を実行する。メインプロセッサー１０１は、サービスディスカバリＲＲ１１０を参照し、mDNSクエリに記述されたサービスが、情報処理装置１０がサポートするサービスか否かを判断する。具体的には、メインプロセッサー１０１は、mDNSクエリパケットに含まれるQNAME及びQTYPEと、サービスディスカバリＲＲ１１０に含まれるNAME及びTYPEとが完全に一致するものがあるか否かを判断する（ステップＳ２０２）。

メインプロセッサー１０１は、サービスディスカバリＲＲ１１０を参照し、mDNSクエリに記述されたサービスが、情報処理装置１０がサポートするサービスであると判断する。具体的には、メインプロセッサー１０１は、mDNSクエリパケットに含まれるQNAME及びQTYPEと、サービスディスカバリＲＲ１１０に含まれるNAME及びTYPEとが完全に一致するものがあると判断する（ステップＳ２０２、ＹＥＳ）。すると、メインプロセッサー１０１は、サービスディスカバリＲＲ１１０に基づきmDNSリスポンスパケットを生成する（図１と同様の方法）（ステップＳ２０３）。
メインプロセッサー１０１は、通信インターフェース３００を介して外部機器に、mDNSリスポンスパケットを送信する（ステップＳ２０４）。

一方、メインプロセッサー１０１は、サービスディスカバリＲＲ１１０を参照し、mDNSクエリに記述されたサービスが、情報処理装置１０がサポートしないサービスであると判断する。具体的には、メインプロセッサー１０１は、mDNSクエリパケットに含まれるQNAME及びQTYPEと、サービスディスカバリＲＲ１１０に含まれるNAME及びTYPEとが完全に一致するものが無いと判断する（ステップＳ２０２、ＮＯ）。すると、メインプロセッサー１０１は、mDNSクエリパケットを破棄する（ステップＳ２０５）。

さらに、メインプロセッサー１０１は、破棄したmDNSクエリパケットに含まれるQNAME及びQTYPEを、非サポートサービスデータベース２４０のNAME２４１及びTYPE２４２として登録する（ステップＳ２０６）。

４．まとめ
多くの電子機器は、省エネルギーのため、通常モードと、スリープモード（メインコントローラーの電源をオフし、サブコントローラーが応答（代理応答）する）とを選択的に実行可能である。そのような電子機器において、スリープモード時にサブコントローラーがmDNSクエリパケットを受信した場合、典型的には、常に、通常モードに復帰した上でメインコントローラーが処理及び応答する。ＲＲのデータ量が大きい（図２及び図４参照）故、低容量のサブＲＯＭには記憶できず、リスポンスパケットを生成するための処理も複雑（図１及び図３参照）である故、低スペックのサブコントローラーでは処理できないためである。

一方、mDNSはマルチキャスト通信であるため、例えば、オフィス内ＬＡＮ（Local Area Network）に多数の電子機器が接続されている場合、各電子機器は、他の電子機器に宛てたmDNSクエリパケットを頻繁に受信することがある。このため、メインコントローラーがスリープモードから通常モードに復帰するケースが、頻繁に生じるおそれがある。他の電子機器に宛てたmDNSクエリパケットを受信したにも拘わらず、サブコントローラーではそれを判断できない故である。省エネルギーの観点からは望ましくない。

逆に、電子機器が、スリープモード時にmDNSクエリパケットを受信した場合、常に、サブコントローラーが、受信した全てのmDNSクエリパケットを処理して代理応答することが考えられる。このためには、サービスディスカバリＲＲ及び名前解決ＲＲを記憶できるようにサブＲＯＭの容量を上げ、サービスディスカバリクエリ及び名前解決クエリを適切に処理できるようにサブプロセッサー及びサブＲＡＭのスペックを上げなければならない。しかしながら、この方法では、情報処理工程の開発が増加し、コストも増加する。その上、サブコントローラーの消費電力が増えることから、省エネルギーの観点からも望ましくない。

ところで、上記のように、mDNSプロトコルにより、サービスディスカバリと、名前解決とを行うことができる。mDNSクエリに応答する際にはサービスディスカバリＲＲ、名前解決ＲＲが用いられる。サービスディスカバリＲＲ（図２）は、機器がサポートするサービスの数と同じ数だけのレコードを含み、さらに、サービス情報（上位層）、デバイス名情報（中位層）及びサービス詳細情報（下位層）を含む階層構造のデータベースである。一方、名前解決ＲＲ（図４）は、ホスト名とIPアドレス（IPv4アドレス、IPv6アドレス）とに関する情報しか持たない。言い換えれば、名前解決ＲＲのデータ量に比べて、サービスディスカバリＲＲのデータ量の方が、相対的に大きい。同様に、相対的にシンプルな名前解決ＲＲから応答すべきデータを抽出する処理（図３）に比べて、階層構造のサービスディスカバリＲＲから応答すべきデータを抽出する処理（図１）の方が、相対的に複雑である。

そこで、本実施形態によれば、メインコントローラー１００がサービスディスカバリＲＲ１１０を持ち、サブコントローラー２００は名前解決ＲＲ２１０を持つ。スリープモード時に、サブコントローラー２００がmDNSクエリを受信すると、mDNSクエリに記述された情報の一部に基づき、サービスディスカバリクエリであるか否かを判断する。サービスディスカバリクエリでなければ、サブコントローラー２００は、名前解決クエリと判断し、名前解決ＲＲ２１０に基づき応答（代理応答）する。一方、サービスディスカバリクエリであれば、サブコントローラー２００は、mDNSクエリに記述されたサービスが、非サポートサービスデータベースに登録されているか否かを判断する。非サポートサービスデータベースに登録されていれば、サブコントローラー２００は、mDNSクエリを破棄する。一方、非サポートサービスデータベース２４０に登録されていなければ、メインコントローラー１００に、スリープモードから通常モードへの復帰を要求し、メインコントローラー１００にmDNSクエリを転送する。メインコントローラー１００は、サービスディスカバリＲＲ１１０に基づき応答する。一方、メインコントローラー１００は、mDNSクエリに記述されたサービスが、情報処理装置１０がサポートしないサービスであると判断すると、mDNSクエリに記述されたサービスを、非サポートサービスデータベース２４０に登録する。

要するに、スリープモード時にサブコントローラー２００がmDNSクエリパケットを受信した場合、サービスディスカバリクエリでなければ、通常モードに復帰せずスリープモードのまま応答する。言い換えれば、サブコントローラー２００がmDNSクエリパケットを受信した場合、サービスディスカバリクエリであり、且つ、mDNSクエリに記述されたサービスが非サポートサービスデータベース２４０に登録されていない場合に限り、スリープモードから通常モードに復帰して、メインコントローラー１００が応答する。

これにより、スリープモードから通常モードに復帰する機会が減り、サブコントローラー２００が代理応答する機会が増えるので、省エネルギー性能が向上する。また、サブコントローラー２００のスペックを上げる必要もないため、サブコントローラー２００自体も低消費電力で動作し（省エネルギー）、コスト増も抑えられる。

さらに、復帰したメインコントローラー１００は、mDNSクエリに記述されたサービスが、情報処理装置１０がサポートしないサービスであると判断すると、mDNSクエリに記述されたサービス（情報処理装置１０がサポートしないサービス）を、非サポートサービスデータベース２４０に登録する。このため、次回、スリープモード時にサブコントローラー２００が同じmDNSクエリパケットを受信した場合、mDNSクエリに記述されたサービスは非サポートサービスデータベースに登録されているので、サブコントローラー２００は、mDNSクエリを破棄し、メインコントローラー１００を復帰させる必要が無い。これにより、スリープモードから通常モードに復帰する機会が時間を追うごとに減っていくので、省エネルギー性能が時間を追うごとに向上していく。

ところで、本実施形態のように、サブコントローラー２００が、サービスディスカバリＲＲ１１０を持たず、名前解決ＲＲ２１０のみを持つと仮定する。この場合、サブコントローラー２００は、受信したmDNSクエリが、自機器に宛てた名前解決クエリであるか否かを判断することは出来る。具体的には、サブコントローラー２００は、受信したmDNSクエリ（名前解決クエリ）のQNAME及びQTYPEのセットが、名前解決ＲＲ２１０に含まれる何れかのレコードのNAME及びTYPEのセットと完全一致すれば、自機器に宛てた名前解決クエリであると判断できる。しかしながら、受信したmDNSクエリ（名前解決クエリ）のQNAME及びQTYPEのセットが、名前解決ＲＲ２１０に含まれる何れかのレコードのNAME及びTYPEのセットと完全一致しないこともある。この場合、サブコントローラー２００は、受信したmDNSクエリが、自機器に宛てた名前解決クエリでないことは判断できるものの、他の電子機器に宛てた名前解決クエリなのか、あるいは、サービスディスカバリクエリなのか、判断できない。従って、サブコントローラー２００は、mDNSクエリが自機器に宛てた名前解決クエリでない場合は常に（即ち、サービスディスカバリクエリであるときに加えて、他の電子機器に宛てた名前解決クエリであるときも）、メインコントローラー１００に、スリープモードから通常モードへの復帰を要求し、メインコントローラー１００にmDNSクエリを転送しなければならない。

これに対して、本実施形態によれば、上記仮定と異なり、名前解決ＲＲ２１０のみを持つサブコントローラー２００は、受信したmDNSクエリが、自機器に宛てた名前解決クエリであるか、あるいは、それ以外か、を先ず判断するわけではない。サブコントローラー２００は、受信したmDNSクエリに記述された情報の一部に基づき、mDNSクエリがサービスディスカバリクエリか否かを先ず判断する。これにより、本実施形態によれば、サブコントローラー２００は、mDNSクエリがサービスディスカバリクエリでない（即ち名前解決クエリである）と判断すると、名前解決ＲＲ２１０を参照し、自機器に宛てた名前解決クエリであれば代理応答し、他の電子機器に宛てた名前解決クエリであれば破棄する。言い換えれば、サブコントローラー２００は、mDNSクエリがサービスディスカバリクエリであるときのみ、メインコントローラー１００に、スリープモードから通常モードへの復帰を要求し、メインコントローラー１００にmDNSクエリを転送する。従って、上記仮定（mDNSクエリがサービスディスカバリクエリであるときに加えて、他の電子機器に宛てた名前解決クエリであるときも、スリープモードから通常モードへ復帰）に比べて、スリープモードから通常モードへ復帰する機会を、減らすことができる。

本技術の実施形態について上に説明したが、本技術は上述の実施形態にのみ限定されるものではなく、本技術の要旨を逸脱しない範囲内において種々変更を加え得ることは勿論である。

１０…情報処理装置
１００…メインコントローラー
１０１…メインプロセッサー
１０２…メインＲＯＭ
１０３…メインＲＡＭ
１１０…サービスディスカバリＲＲ
１２０…サービスディスカバリプログラム
２００…サブコントローラー
２０１…サブプロセッサー
２０２…サブＲＯＭ
２０３…サブＲＡＭ
２１０…名前解決ＲＲ
２２０…mDNS代理応答プログラム
２３０…代理応答データベース
２４０…非サポートサービスデータべース
３００…通信インターフェース
４００…スイッチャー

Claims (8)

1. mDNS（Multicast Domain Name System）プロトコルに基づく名前解決クエリに対するリスポンスを生成するのに用いられる名前解決ＲＲ（Resource Record）を含む代理応答データベースと、情報処理装置がサポートしないサービスを登録した非サポートサービスデータベースとを記憶するサブメモリーと、サブプロセッサーとを有するサブコントローラーと、
   前記mDNSプロトコルに基づくサービスディスカバリクエリに対するリスポンスを生成するのに用いられるサービスディスカバリＲＲを記憶するメインメモリーと、メインプロセッサーとを有し、スリープモードに移行及び前記スリープモードから復帰するときに前記サブプロセッサーに通知するメインコントローラーと、
   ネットワークに接続された外部機器と通信可能な通信インターフェースと
   を具備し、
   前記スリープモード時に、前記サブプロセッサーは、
   mDNSクエリを前記通信インターフェースを介して前記外部機器から受信すると、
   前記mDNSクエリがサービスディスカバリクエリであるか否かを判断し、
   前記mDNSクエリがサービスディスカバリクエリであると判断すると、
   前記mDNSクエリに記述されたサービスが、前記非サポートサービスデータベースに登録されているか否かを判断し、
   前記mDNSクエリに記述された前記サービスが、前記非サポートサービスデータベースに登録されていないと判断すると、
   前記メインプロセッサーに、前記スリープモードからの復帰を要求し、
   前記メインプロセッサーに、前記mDNSクエリを転送し、
   前記mDNSクエリがサービスディスカバリクエリでないと判断すると、
   前記mDNSクエリを名前解決クエリと判断し、前記名前解決ＲＲに基づき前記リスポンスを生成し、前記リスポンスを前記通信インターフェースを介して前記外部機器に送信する
   情報処理装置。
2. 請求項１に記載の情報処理装置であって、
   前記サブプロセッサーは、
   前記mDNSクエリに記述された情報の一部に基づき、前記mDNSクエリがサービスディスカバリクエリか否かを判断する
   情報処理装置。
3. 請求項２に記載の情報処理装置であって、
   前記サブプロセッサーは、
   前記mDNSクエリに記述されたQNAME（名前）の一部に記述された情報と、QTYPE（種別）に記述された情報とに基づき、前記mDNSクエリがサービスディスカバリクエリか否かを判断する
   情報処理装置。
4. 請求項３に記載の情報処理装置であって、
   前記サブプロセッサーは、
   前記mDNSクエリにおいて、
   （１）前記QNAMEの末尾が「_udp.local」、前記QTYPEが「PTR」、
   （２）前記QNAMEの末尾が「_tcp.local」、前記QTYPEが「PTR」、
   （３）前記QNAMEの先頭がデバイス名、前記QNAMEの末尾が「_tcp.local」、又は
   （４）前記QNAMEの先頭がデバイス名、前記QNAMEの末尾が「_udp.local」
   と判断すると、前記mDNSクエリがサービスディスカバリクエリであると判断する
   情報処理装置。
5. 請求項１乃至４の何れか一項に記載の情報処理装置であって、
   前記メインプロセッサーは、
   前記サブプロセッサーからの前記要求に応じて前記スリープモードから復帰し、
   前記サブプロセッサーから前記サービスディスカバリクエリである前記mDNSクエリを受信し、
   前記mDNSクエリに記述された前記サービスが、前記情報処理装置がサポートするサービスか否かを判断し、
   前記mDNSクエリに記述された前記サービスが、前記情報処理装置がサポートしないサービスであると判断すると、
   前記mDNSクエリに記述された前記サービスを、前記非サポートサービスデータベースに登録する
   情報処理装置。
6. 請求項１乃至５の何れか一項に記載の情報処理装置であって、
   前記非サポートサービスデータベースは、前記情報処理装置がサポートしないサービスのNAME（名前）及びTYPE（種別）を登録し、
   前記サブプロセッサーは、
   前記mDNSクエリに記述されたQNAME（名前）及びQTYPE（種別）の組み合わせが、前記非サポートサービスデータベースに登録されているか否かに基づき、前記mDNSクエリに記述されたサービスが、前記非サポートサービスデータベースに登録されているか否かを判断する
   情報処理装置。
7. 請求項１乃至６の何れか一項に記載の情報処理装置であって、
   前記サブプロセッサーは、
   前記mDNSクエリに記述されたサービスが、前記非サポートサービスデータベースに登録されていると判断すると、前記mDNSクエリを破棄する
   情報処理装置。
8. mDNS（Multicast Domain Name System）プロトコルに基づく名前解決クエリに対するリスポンスを生成するのに用いられる名前解決ＲＲ（Resource Record）を含む代理応答データベースと、情報処理装置がサポートしないサービスを登録した非サポートサービスデータベースとを記憶するサブメモリーと、サブプロセッサーとを有するサブコントローラー、前記mDNSプロトコルに基づくサービスディスカバリクエリに対するリスポンスを生成するのに用いられるサービスディスカバリＲＲを記憶するメインメモリーと、メインプロセッサーとを有し、スリープモードに移行及び前記スリープモードから復帰するときに前記サブプロセッサーに通知するメインコントローラー、及びネットワークに接続された外部機器と通信可能な通信インターフェースを備える情報処理装置の前記サブプロセッサーに、
   前記メインコントローラーのスリープモード時に、
   mDNSクエリを前記通信インターフェースを介して前記外部機器から受信させ、
   前記mDNSクエリがサービスディスカバリクエリであるか否かを判断させ、
   前記mDNSクエリがサービスディスカバリクエリであると判断すると、
   前記mDNSクエリに記述されたサービスが、前記非サポートサービスデータベースに登録されているか否かを判断させ、
   前記mDNSクエリに記述された前記サービスが、前記非サポートサービスデータベースに登録されていないと判断すると、
   前記メインプロセッサーに、前記スリープモードからの復帰を要求させ、
   前記メインプロセッサーに、前記mDNSクエリを転送させ、
   前記mDNSクエリがサービスディスカバリクエリでないと判断すると、
   前記mDNSクエリを名前解決クエリと判断し、前記名前解決ＲＲに基づき前記リスポンスを生成し、前記リスポンスを前記通信インターフェースを介して前記外部機器に送信させる
   情報処理プログラム。

Images