図面 (/)

技術 情報処理装置及び情報処理プログラム

出願人 京セラドキュメントソリューションズ株式会社
発明者 相場雅彰
出願日 2018年3月27日 (2年10ヶ月経過) 出願番号 2018-059506
公開日 2019年4月11日 (1年10ヶ月経過) 公開番号 2019-057906
状態 未査定
技術分野 通信制御 ファクシミリ一般 付属装置、全体制御
主要キーワード サブコントローラー メインプロセッサー 中位層 低スペック ポート番 リスポンス 省エネルギー性能 非サポート
関連する未来課題
重要な関連分野

この項目の情報は公開日時点(2019年4月11日)のものです。
また、この項目は機械的に抽出しているため、正しく解析できていない場合があります

図面 (10)

課題

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

解決手段

情報処理装置のサブコントローラーは、mDNSプロトコルに基づく名前解決クエリに対するリスポンスを生成するのに用いられる名前解決RRを持つ。メインコントローラーは、mDNSプロトコルに基づくサービスディスカバリクエリに対するリスポンスを生成するのに用いられるサービスディスカバリRRを持つ。スリープモード時に、サブコントローラーは、mDNSクエリ通信インターフェースを介して外部機器から受信すると、mDNSクエリがサービスディスカバリクエリであるか否かを判断し、mDNSクエリがサービスディスカバリクエリでないと判断すると、mDNSクエリを名前解決クエリと判断し、名前解決RRに基づきリスポンスを生成し、リスポンスを通信インターフェースを介して外部機器に送信する。

概要

背景

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

概要

スリープモード時に通常モードに復帰することなく、サブコントローラーがより多くのタイプのクエリに対して応答する。情報処理装置のサブコントローラーは、mDNSプロトコルに基づく名前解決クエリに対するリスポンスを生成するのに用いられる名前解決RRを持つ。メインコントローラーは、mDNSプロトコルに基づくサービスディスカバリクエリに対するリスポンスを生成するのに用いられるサービスディスカバリRRを持つ。スリープモード時に、サブコントローラーは、mDNSクエリ通信インターフェースを介して外部機器から受信すると、mDNSクエリがサービスディスカバリクエリであるか否かを判断し、mDNSクエリがサービスディスカバリクエリでないと判断すると、mDNSクエリを名前解決クエリと判断し、名前解決RRに基づきリスポンスを生成し、リスポンスを通信インターフェースを介して外部機器に送信する。

目的

効果

実績

技術文献被引用数
0件
牽制数
0件

この技術が所属する分野

(分野番号表示ON)※整理標準化データをもとに当社作成

ライセンス契約や譲渡などの可能性がある特許掲載中! 開放特許随時追加・更新中 詳しくはこちら

請求項1

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

請求項2

請求項1に記載の情報処理装置であって、前記サブプロセッサーは、前記mDNSクエリに記述された情報の一部に基づき、前記mDNSクエリがサービスディスカバリクエリか否かを判断する情報処理装置。

請求項3

請求項2に記載の情報処理装置であって、前記サブプロセッサーは、前記mDNSクエリに記述されたQNAME(名前)の一部に記述された情報と、QTYPE(種別)に記述された情報とに基づき、前記mDNSクエリがサービスディスカバリクエリか否かを判断する情報処理装置。

請求項4

請求項3に記載の情報処理装置であって、前記サブプロセッサーは、前記mDNSクエリにおいて、(1)前記QNAMEの末尾が「_udp.local」、前記QTYPEが「PTR」、(2)前記QNAMEの末尾が「_tcp.local」、前記QTYPEが「PTR」、(3)前記QNAMEの先頭デバイス名、前記QNAMEの末尾が「_tcp.local」、又は(4)前記QNAMEの先頭がデバイス名、前記QNAMEの末尾が「_udp.local」と判断すると、前記mDNSクエリがサービスディスカバリクエリであると判断する情報処理装置。

請求項5

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

請求項6

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

請求項7

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

請求項8

請求項5乃至7の何れか一項に記載の情報処理装置であって、前記サブプロセッサーは、前記mDNSクエリに記述されたサービスが、前記非サポートサービスデータベースに登録されていると判断すると、前記mDNSクエリを破棄する情報処理装置。

請求項9

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

技術分野

0001

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

背景技術

0002

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

先行技術

0003

特開2010−094925号公報

発明が解決しようとする課題

0004

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

0005

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

課題を解決するための手段

0006

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

0007

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

0008

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

0009

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

0010

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

0011

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

0012

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

0013

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

0014

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

0015

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

0016

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

0017

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

0018

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

0019

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

0020

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

0021

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

0022

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

発明の効果

0023

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

0024

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

図面の簡単な説明

0025

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

実施例

0026

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

0027

I.mDNSプロトコル
1.概要
iPhone(登録商標)やiPad(登録商標)などのApple(登録商標)製デバイスは、mDNSプロトコルを用いて、サービスディスカバリ(DNS-SD、DNS based Service Discovery)と、名前解決とを行う。

0028

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

0029

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

0030

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

0031

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

0032

図2は、サービスディスカバリRR(Resource Record)の一例を示す。
第2の機器40は、サービスディスカバリRR110をローカルに記憶している。サービスディスカバリRR110は、サービス情報111(上位層)、デバイス名情報112(中位層)及びサービス詳細情報113(下位層)を含む階層構造データベースである。本例では、第2の機器40は、画像形成装置MFP(Multifnction Peripheral))とする。

0033

サービス情報111は、第2の機器40がサポートするサービスの一覧である。本例では、サービス情報111は、「_printer._tcp.local」111A(ローカルなプリンターでの印刷)、「_ipp._tcp.local」111B(Internet Printing Protocol、インターネットを介したリモートでの印刷)及び「_http_tcp.local」111C(Webサーバー)等のサービスを含む。

0034

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

0035

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

0036

第2の機器40は、受信した第1のmDNSクエリパケット31Aから、QNAME32Aに記述された「_printer._tcp.local」と、QTYPE33Aに記述された「PTR」とを読み出す。第2の機器40は、サービスディスカバリRR110を参照し、サービス情報111から、QNAME32Aと完全一致する「_printer._tcp.local」111Aを読み出す。第2の機器40は、サービス情報「_printer._tcp.local」111Aの直下の層であるデバイス名情報112から、QTYPE33A「PTR」に対応する「._printer._tcp.local」112A(本例では、「TaskalfaXXX._printer._tcp.local」)を読み出す。

0037

第2の機器40は、第1のmDNSリスポンスパケット41Aを生成する。第1のmDNSリスポンスパケット41Aは、第1のmDNSクエリパケット31Aに含まれるQNAME32Aと同じNAME42A「_printer._tcp.local」と、第1のmDNSクエリパケット31Aに含まれるQTYPE33Aと同じTYPE43A「PTR」と、DATA44Aとしてデバイス名情報112から読み出した「TaskalfaXXX._printer._tcp.local」112Aとを含む。第2の機器40は、生成した第1のmDNSリスポンスパケット41Aを、第1の機器30に送信する。

0038

第1の機器30は、第2のmDNSクエリパケット31B及び第3のmDNSクエリパケット31Cをマルチキャストする。第2のmDNSクエリパケット31Bにおいて、QNAME32Bに「TaskalfaXXX._printer._tcp.local」が記述され、QTYPE33Bに「SRV」が記述される。第3のmDNSクエリパケット31Cにおいて、QNAME32Cに「TaskalfaXXX._printer._tcp.local」が記述され、QTYPE33Cに「TXT」が記述される。

0039

第2の機器40は、受信した第2のmDNSクエリパケット31Bから、QNAME32Bに記述された「TaskalfaXXX._printer._tcp.local」と、QTYPE33Bに記述された「SRV」とを読み出す。第2の機器40は、サービスディスカバリRR110を参照し、デバイス名情報112から、QNAME32Bと完全一致する「._printer._tcp.local」112A(本例では、「TaskalfaXXX._printer._tcp.local」)を読み出す。第2の機器40は、デバイス名情報「._printer._tcp.local」112A(本例では、「TaskalfaXXX._printer._tcp.local」)の直下の層であるサービス詳細情報113から、QTYPE33B「SRV」に対応する「ポート番号等」113Bを読み出す。

0040

第2の機器40は、第2のmDNSリスポンスパケット41Bを生成する。第2のmDNSリスポンスパケット41Bは、第2のmDNSクエリパケット31Bに含まれるQNAME32Bと同じNAME42B「TaskalfaXXX._printer._tcp.local」と、第2のmDNSクエリパケット31Bに含まれるQTYPE33Bと同じTYPE43B「SRV」と、DATA44Bとしてサービス詳細情報113から読み出した「ポート番号等」113Bを含む。

0041

第2の機器40は、受信した第3のmDNSクエリパケット31Cから、QNAME32Cに記述された「TaskalfaXXX._printer._tcp.local」と、QTYPE33Cに記述された「TXT」とを読み出す。第2の機器40は、サービスディスカバリRR110を参照し、デバイス名情報112から、QNAME32Cと完全一致する「._printer._tcp.local」112A(本例では、「TaskalfaXXX._printer._tcp.local」)を読み出す。第2の機器40は、デバイス名情報「._printer._tcp.local」112A(本例では、「TaskalfaXXX._printer._tcp.local」)の直下の層であるサービス詳細情報113から、QTYPE33C「TXT」に対応する「printフォーマットなど」113Cを読み出す。

0042

第2の機器40は、第3のmDNSリスポンスパケット41Cを生成する。第3のmDNSリスポンスパケット41Cは、第3のmDNSクエリパケット31Cに含まれるQNAME32Cと同じNAME42C「TaskalfaXXX._printer._tcp.local」と、第3のmDNSクエリパケット31Cに含まれるQTYPE33Cと同じTYPE43C「TXT」と、DATA44Cとしてサービス詳細情報113から読み出した「printフォーマットなど」113Cを含む。第2の機器40は、生成した第2のmDNSリスポンスパケット41B及び第3のmDNSリスポンスパケット41Cを、第1の機器30に送信する。

0043

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

0044

(1)例1
問い合わせ元の機器(以下、第1の機器と称する)50が、第1のmDNSクエリパケット51Aを生成する。第1のmDNSクエリパケット51Aは、QNAME(名前)52Aと、QTYPE(種別)53Aとを含む。QNAME52Aには、問い合わせの対象であるホスト名が記述される。本例では、QNAME52Aに「.local」として「KM123456.local」が記述される。QTYPE53Aに「A」が記述される。「A」は、IPv4名前解決を意味する。第1の機器50は、生成した第1のmDNSクエリパケット51Aを、マルチキャストする。問い合わせに応答する機器(以下、第2の機器と称する)60は、第1のmDNSクエリパケット51Aを受信する。

0045

図4は、名前解決RRの一例を示す。
第2の機器60は、名前解決RR210をローカルに記憶している。本例では、名前解決RR210は、第1のレコード211、第2のレコード212及び複数の第3のレコード213を有する。

0046

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

0047

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

0048

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

0049

第2の機器60は、受信した第1のmDNSクエリパケット51Aから、QNAME52Aに記述された「KM123456.local」と、QTYPE53Aに記述された「A」とを読み出す。第2の機器60は、名前解決RR210を参照し、第1のレコード211から、QNAME52Aと完全一致する「KM123456.local」に関連付けられたQTYPE53A「A」に対応するIPv4アドレス(本例では、「192.168.0.1」)212Aを読み出す。

0050

第2の機器60は、第1のmDNSリスポンスパケット61Aを生成する。第1のmDNSリスポンスパケット61Aは、第1のmDNSクエリパケット51Aに含まれるQNAME52Aと同じNAME62A「KM123456.local」と、第1のmDNSクエリパケット51Aに含まれるQTYPE53Aと同じTYPE63A「A」と、DATA64Aとして第1のレコード211から読み出したIPv4アドレス「192.168.0.1」212Aを含む。第2の機器60は、生成した第1のmDNSリスポンスパケット61Aを、第1の機器50に送信する。

0051

(2)例2
第1の機器50は、第2のmDNSクエリパケット51Bをマルチキャストする。第2のmDNSクエリパケット51Bにおいて、QNAME52Bに「1.0.168.192.in-addr.arpa」が記述される。QTYPE53Bに「PTR」が記述される。

0052

第2の機器60は、受信した第2のmDNSクエリパケット51Bから、QNAME52Bに記述された「1.0.168.192.in-addr.arpa」と、QTYPE53Bに記述された「PTR」とを読み出す。第2の機器60は、名前解決RR210を参照し、第2のレコード212から、QNAME52Bと完全一致する「1.0.168.192.in-addr.arpa」に関連付けられたQTYPE53B「PTR」に対応するホスト名(本例では、「KM123456.local」)212Bを読み出す。

0053

第2の機器60は、第2のmDNSリスポンスパケット61Bを生成する。第2のmDNSリスポンスパケット61Bは、第2のmDNSクエリパケット51Bに含まれるQNAME52Bと同じNAME62B「1.0.168.192.in-addr.arpa」と、第2のmDNSクエリパケット51Bに含まれるQTYPE53Bと同じTYPE63B「PTR」と、DATA64Bとして第2のレコード212から読み出したホスト名「KM123456.local」212Bを含む。第2の機器60は、生成した第2のmDNSリスポンスパケット61Bを、第1の機器50に送信する。

0054

(3)例3
第1の機器50は、第3のmDNSクエリパケット51Cをマルチキャストする。第3のmDNSクエリパケット51Cにおいて、QNAME52Cに「KM123456.local」が記述される。QTYPE53Cに「AAAA」が記述される。

0055

第2の機器60は、受信した第3のmDNSクエリパケット51Cから、QNAME52Cに記述された「KM123456.local」と、QTYPE53Cに記述された「AAAA」とを読み出す。第2の機器60は、名前解決RR210を参照し、第1のレコード211から、QNAME52Cと完全一致する「KM123456.local」に関連付けられたQTYPE53C「AAAA」に対応するIPv6アドレス(本例では、「2001::1」、「fe80::1」)211C及び211Dを読み出す。

0056

第2の機器60は、第3のmDNSリスポンスパケット61Cを生成する。第3のmDNSリスポンスパケット61Cは、第3のmDNSクエリパケット51Cに含まれるQNAME52Cと同じNAME62C「KM123456.local」と、第3のmDNSクエリパケット51Cに含まれるQTYPE53Cと同じTYPE63C「AAAA」と、DATA64Cとして第1のレコード211から読み出したIPv6アドレス「2001::1」211Cを含む。

0057

第2の機器60は、第4のmDNSリスポンスパケット61Dを生成する。第4のmDNSリスポンスパケット61Dは、第3のmDNSクエリパケット51Cに含まれるQNAME52Cと同じNAME62D「KM123456.local」と、第3のmDNSクエリパケット51Cに含まれるQTYPE53Cと同じTYPE63D「AAAA」と、DATA64Dとして第1のレコード211から読み出したIPv6アドレス「fe80::1」211Dを含む。第2の機器60は、生成した第3のmDNSリスポンスパケット61C及び第4のmDNSリスポンスパケット61Dを、第1の機器50に送信する。

0058

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

0059

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

0060

II.実施形態
1.情報処理装置の構成
図5は、本開示の一実施形態に係る情報処理装置の構成を示す。

0061

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

0062

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

0063

メインコントローラー100は、通常モード時に各種処理を実行する。メインコントローラー100は、メインプロセッサー(CPU、Central Processing Unit)101、メインROM(Read Only Memory)102、メインRAM(Random Access Memory)103(メインメモリー)及び専用のハードウェア回路等を有する。情報処理装置10が画像形成装置である場合、メインコントローラー100には、イメージスキャナー、プリンター、画像メモリー表示装置操作装置不揮発性記憶装置(HDD(Hard Disk Drive)等)が接続される(図示及び説明を省略)。メインコントローラー100は、これらのハードウェア(図示せず)、通信インターフェース300及びスイッチャー400を制御する。

0064

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

0065

メインROM102は、サービスディスカバリプログラム120を記憶する。サービスディスカバリプログラム120は、mDNSプロトコルに基づくサービスディスカバリクエリに対して応答する(図1と同様の方法)ためのプログラムである。

0066

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

0067

サブコントローラー200は、スリープモード時に、ネットワークNから受信したクエリに対して応答(所謂、代理応答)する。サブコントローラー200は、サブプロセッサー(CPU)201、サブROM202、サブRAM203(サブメモリー)及び専用のハードウェア回路等を有する。サブコントローラー200の各デバイスは、メインコントローラー100の各デバイスに比べてプアなスペックであり、低消費電力で動作する。

0068

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

0069

サブROM202は、mDNS代理応答プログラム220を記憶する。mDNS代理応答プログラム220は、mDNSプロトコルに基づく名前解決クエリに対して応答する(図3と同様の方法)ためのプログラムである。

0070

サブRAM203(サブメモリー)は、代理応答データベース230と、非サポートサービスデータべース240とを記憶する。例えば、メインプロセッサー101は、通常モードからスリープモードに移行するタイミングで、代理応答データベース230と、非サポートサービスデータべース240とを生成してサブRAM203に書き込めばよい。

0071

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

0072

代理応答データベース230は、サブプロセッサー201が代理応答(mDNSプロトコル及び他のプロトコル)を実行する際に、クエリに対するリスポンスを生成するのに参照するデータベースである。代理応答データベース230は、名前解決RR210(図4)が記憶するデータを含む。名前解決RR210が記憶するデータは、サブプロセッサー201がmDNS代理応答プログラム220を実行する際に参照するデータである。言い換えれば、代理応答データベース230は、名前解決RR210(図4)をデータベースの構造で記憶する。具体的には、代理応答データベース230は、NAME231、TYPE232及びRDATA233の組み合わせを登録する。

0073

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

0074

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

0075

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

0076

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

0077

2.mDNS代理応答プログラムのフロー
図6は、mDNS代理応答プログラムのフローを示す。

0078

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

0079

スリープモード時に、サブプロセッサー201は、mDNSクエリパケットを通信インターフェース300を介して外部機器(図示せず)から受信する(ステップS101)。

0080

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

0081

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

0082

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

0083

図1を参照し、一例として、第1のmDNSクエリパケット31Aは、QNAME32Aの末尾が「_tcp.local」、QTYPE33Aが「PTR」であるから、条件(2)に該当する。このため、サブプロセッサー201は、第1のmDNSクエリパケット31Aがサービスディスカバリクエリパケットであると判断する。別の例として、第2のmDNSクエリパケット31Bは、QNAME32Bの先頭がデバイス名「TaskalfaXXX」、QNAMEの末尾32Bが「_tcp.local」であるから、条件(3)に該当する。このため、サブプロセッサー201は、第2のmDNSクエリパケット31Bがサービスディスカバリクエリパケットであると判断する。第3のmDNSクエリパケット31Cも同様である。

0084

一方、図3を参照し、第1のmDNSクエリパケット51A、51B及び51Cは何れも、条件(1)、(2)、(3)及び(4)に該当しない。このため、サブプロセッサー201は、第1のmDNSクエリパケット51A、51B及び51Cは何れも、サービスディスカバリクエリパケットでないと判断する。

0085

再び図6を参照し、サブプロセッサー201は、mDNSクエリパケットがサービスディスカバリクエリパケットでないと判断する(ステップS102、NO)。すると、サブプロセッサー201は、mDNSクエリパケットを名前解決クエリパケットと判断する。サブプロセッサー201は、mDNSクエリパケットに含まれるQNAME及びQTYPEと、名前解決RR210に含まれるNAME及びTYPEとが完全に一致すると(ステップS103、YES)、mDNSリスポンスパケットを生成する(図3と同様の方法)(ステップS104)。サブプロセッサー201は、通信インターフェース300を介して外部機器に、mDNSリスポンスパケットを送信する(ステップS105)。

0086

一方、サブプロセッサー201は、mDNSクエリパケットに含まれるQNAME及びQTYPEと、名前解決RR210に含まれるNAME及びTYPEとが完全に一致しなければ(ステップS103、NO)、mDNSクエリパケットを破棄する(ステップS106)。

0087

一方、サブプロセッサー201は、mDNSクエリパケットがサービスディスカバリクエリパケットであると判断する(ステップS102、YES)。すると、サブプロセッサー201は、mDNSクエリパケットに記述されたQNAME及びQTYPEの組み合わせが、非サポートサービスデータベース240のNAME241及びTYPE242として登録されているか否かを判断する。(ステップS109)。

0088

サブプロセッサー201は、mDNSクエリパケットに記述されたQNAME及びQTYPEの組み合わせが、非サポートサービスデータベース240に登録されていると判断する(ステップS109、YES)。この場合、サブプロセッサー201は、mDNSクエリパケットに記述されたサービスが、情報処理装置10がサポートしないサービスである。従って、サブプロセッサー201は、mDNSクエリパケットを破棄する(ステップS110)。

0089

一方、サブプロセッサー201は、DNSクエリパケットに記述されたQNAME及びQTYPEの組み合わせが、非サポートサービスデータベース240に登録されていないと判断する(ステップS109、NO)。この場合、サブプロセッサー201は、メインプロセッサー101に、スリープモードから通常モードへの復帰(ウェイクアップ)を要求する(ステップS107)。サブプロセッサー201は、メインプロセッサー101から、スリープモードから通常モードへの復帰の通知を受けると、メインプロセッサー101に、mDNSクエリパケットを転送する(ステップS108)。

0090

3.サービスディスカバリプログラムのフロー
図9は、サービスディスカバリプログラムのフローを示す。

0091

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

0092

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

0093

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

0094

さらに、メインプロセッサー101は、破棄したmDNSクエリパケットに含まれるQNAME及びQTYPEを、非サポートサービスデータベース240のNAME241及びTYPE242として登録する(ステップS206)。

0095

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

0096

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

0097

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

0098

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

0099

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

0100

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

0101

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

0102

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

0103

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

0104

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

0105

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

0106

10…情報処理装置
100…メインコントローラー
101…メインプロセッサー
102…メインROM
103…メインRAM
110…サービスディスカバリRR
120…サービスディスカバリプログラム
200…サブコントローラー
201…サブプロセッサー
202…サブROM
203…サブRAM
210…名前解決RR
220…mDNS代理応答プログラム
230…代理応答データベース
240…非サポートサービスデータべース
300…通信インターフェース
400…スイッチャー

ページトップへ

この技術を出願した法人

この技術を発明した人物

ページトップへ

関連する挑戦したい社会課題

関連する公募課題

ページトップへ

技術視点だけで見ていませんか?

この技術の活用可能性がある分野

分野別動向を把握したい方- 事業化視点で見る -

(分野番号表示ON)※整理標準化データをもとに当社作成

ページトップへ

おススメ サービス

おススメ astavisionコンテンツ

新着 最近 公開された関連が強い技術

この 技術と関連性が強い人物

関連性が強い人物一覧

この 技術と関連する社会課題

関連する挑戦したい社会課題一覧

この 技術と関連する公募課題

関連する公募課題一覧

astavision 新着記事

サイト情報について

本サービスは、国が公開している情報(公開特許公報、特許整理標準化データ等)を元に構成されています。出典元のデータには一部間違いやノイズがあり、情報の正確さについては保証致しかねます。また一時的に、各データの収録範囲や更新周期によって、一部の情報が正しく表示されないことがございます。当サイトの情報を元にした諸問題、不利益等について当方は何ら責任を負いかねることを予めご承知おきのほど宜しくお願い申し上げます。

主たる情報の出典

特許情報…特許整理標準化データ(XML編)、公開特許公報、特許公報、審決公報、Patent Map Guidance System データ