特許 7338435 通信装置、及び、通信装置のためのコンピュータプログラム

(19)【発行国】日本国特許庁(JP)

(12)【公報種別】特許公報(B2)

(11)【特許番号】

(24)【登録日】2023-08-28

(45)【発行日】2023-09-05

(54)【発明の名称】通信装置、及び、通信装置のためのコンピュータプログラム

(51)【国際特許分類】

   H04L 67/145 20220101AFI20230829BHJP

   H04L 43/10 20220101ALI20230829BHJP

   H04L 67/02 20220101ALI20230829BHJP

【ＦＩ】

H04L67/145

H04L43/10

H04L67/02

【請求項の数】 8

(21)【出願番号】P 2019217164

(22)【出願日】2019-11-29

(65)【公開番号】P2021086545

(43)【公開日】2021-06-03

【審査請求日】2022-11-18

(73)【特許権者】

【識別番号】000005267

【氏名又は名称】ブラザー工業株式会社

(74)【代理人】

【識別番号】110000110

【氏名又は名称】弁理士法人 快友国際特許事務所

(72)【発明者】

【氏名】井上 卓弥

【審査官】前田 健人

(56)【参考文献】

【文献】国際公開第２０１３／１４５５１６（ＷＯ，Ａ１）

【文献】特開２０１６－１８１８７７（ＪＰ，Ａ）

(58)【調査した分野】(Int.Cl.，ＤＢ名)

Ｈ０４Ｌ ４３／１０

Ｈ０４Ｌ ６７／０２

Ｈ０４Ｌ ６７／１４５

Ｈ０４Ｌ ６９／００

(57)【特許請求の範囲】

【請求項1】

通信装置であって、
通信インターフェースと、
前記通信インターフェースを介して、ＨＴＴＰ（Hypertext Transfer Protocolの略）に準じたセッションをインターネット上の対象サーバと確立する確立部と、
前記セッションが確立された後に、前記通信インターフェースを介して、通信確認を繰り返し実行する通信確認部であって、前記通信確認は、前記通信装置が確認信号を前記対象サーバに送信すること、及び、前記通信装置が前記対象サーバから前記確認信号に対する応答信号を受信すること、を含む、前記通信確認部と、
前記対象サーバが前記通信装置から前記確認信号を受信してから前記応答信号を前記通信装置に送信するまでの時間である待機時間を調整する調整部と、を備え、
前記調整部は、
前記通信装置と前記対象サーバとの間の通信においてプロキシサーバが利用される場合に、前記待機時間として第１の時間を利用すべきことを前記対象サーバに指示し、
前記通信装置と前記対象サーバとの間の通信において前記プロキシサーバが利用されない場合に、前記待機時間として前記第１の時間より長い第２の時間を利用すべきことを前記対象サーバに指示する、
通信装置。

【請求項2】

前記通信装置の状態は、前記プロキシサーバが利用される第１の状態と、前記プロキシサーバが利用されない第２の状態と、のうちのいずれかの状態に変更可能であり、
前記セッションが確立された後に、前記通信装置の状態が変更される場合に、前記セッションは切断され、
前記確立部は、前記セッションが切断された後に、前記通信インターフェースを介して、前記ＨＴＴＰに準じた前記セッションを前記対象サーバと再び確立し、
前記調整部は、
前記通信装置の状態が前記第２の状態から前記第１の状態に変更されて、前記セッションが再び確立される場合に、前記待機時間を前記第１の時間に調整し、
前記通信装置の状態が前記第１の状態から前記第２の状態に変更されて、前記セッションが再び確立される場合に、前記待機時間を前記第２の時間に調整する、請求項１に記載の通信装置。

【請求項3】

前記通信装置は、さらに、
前記通信確認が成功する場合に、前記待機時間を延長する延長部と、
前記通信確認が失敗する場合に、前記待機時間を短縮する短縮部と、
を備える、請求項１又は２に記載の通信装置。

【請求項4】

前記短縮部は、
前記対象サーバから前記確認信号に対する前記応答信号を受信することなく、前記確認信号を前記対象サーバに送信してから所定時間が経過することに起因して、前記通信確認が失敗する場合に、前記待機時間を短縮し、
前記確認信号を前記対象サーバに送信してから前記所定時間が経過する前に、前記応答信号とは異なる信号が前記対象サーバから受信されることに起因して、前記通信確認が失敗する場合に、前記待機時間を短縮しない、請求項３に記載の通信装置。

【請求項5】

前記延長部は、
前記通信装置と前記対象サーバとの間の通信において前記プロキシサーバが利用される場合に、第１の値を上限値として、前記待機時間を延長し、
前記通信装置と前記対象サーバとの間の通信において前記プロキシサーバが利用されない場合に、前記第１の値より長い第２の値を上限値として、前記待機時間を延長する、請求項３又は４に記載の通信装置。

【請求項6】

前記通信装置は、さらに、
前記通信確認が失敗した際の前記待機時間をメモリに記憶する記憶制御部を備え、
前記延長部は、前記メモリに記憶されている前記待機時間を上限値として、前記待機時間を延長する、請求項３から５のいずれか一項に記載の通信装置。

【請求項7】

前記セッションは、ＸＭＰＰ（eXtensible Messaging and Presence Protocolの略） ｏｖｅｒ ＢＯＳＨ（Bidirectional-streams Over Synchronous HTTPの略）に従ったセッションである、請求項１から６のいずれか一項に記載の通信装置。

【請求項8】

通信装置のためのコンピュータプログラムであって、
前記通信装置は、通信インターフェースを備え、
前記コンピュータプログラムは、前記通信装置のコンピュータを、以下の各部、即ち、
前記通信インターフェースを介して、ＨＴＴＰ（Hypertext Transfer Protocolの略）に準じたセッションをインターネット上の対象サーバと確立する確立部と、
前記セッションが確立された後に、前記通信インターフェースを介して、通信確認を繰り返し実行する通信確認部であって、前記通信確認は、前記通信装置が確認信号を前記対象サーバに送信すること、及び、前記通信装置が前記対象サーバから前記確認信号に対する応答信号を受信すること、を含む、前記通信確認部と、
前記対象サーバが前記通信装置から前記確認信号を受信してから前記応答信号を前記通信装置に送信するまでの時間である待機時間を調整する調整部と、として機能させ、
前記調整部は、
前記通信装置と前記対象サーバとの間の通信においてプロキシサーバが利用される場合に、前記待機時間として第１の時間を利用すべきことを前記対象サーバに指示し、
前記通信装置と前記対象サーバとの間の通信において前記プロキシサーバが利用されない場合に、前記待機時間として前記第１の時間より長い第２の時間を利用すべきことを前記対象サーバに指示する、
コンピュータプログラム。

【発明の詳細な説明】

【技術分野】

【0001】

本明細書では、サーバとのセッションを確立する通信装置に関する技術を開示する。

【背景技術】

【0002】

特許文献１には、サーバとのセッションを確立するＭＦＰが開示されている。ＭＦＰは、セッションが確立された後に、パケットをサーバに定期的に送信する。セッションが維持されている場合には、ＭＦＰは、サーバから当該パケットに対する応答を受信する。ＭＦＰは、パケットの送信間隔をルータのファイヤウォール機能におけるセッションタイムアウト時間以内に調整する。

【先行技術文献】

【特許文献】

【0003】

【文献】特開２０１６－１８１８７７号公報

【発明の概要】

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

【0004】

ＭＦＰとサーバとの間にプロキシサーバが存在する場合がある。上記の技術では、プロキシサーバについて何ら考慮されていない。

【0005】

本明細書では、プロキシサーバが存在するのか否かを考慮して、対象サーバとの通信確認を適切に実行するための技術を提供する。

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

【0006】

本明細書によって開示される通信装置は、通信インターフェースと、前記通信インターフェースを介して、ＨＴＴＰ（Hypertext Transfer Protocolの略）に準じたセッションをインターネット上の対象サーバと確立する確立部と、前記セッションが確立された後に、前記通信インターフェースを介して、通信確認を繰り返し実行する通信確認部であって、前記通信確認は、前記通信装置が確認信号を前記対象サーバに送信すること、及び、前記通信装置が前記対象サーバから前記確認信号に対する応答信号を受信すること、を含む、前記通信確認部と、前記対象サーバが前記通信装置から前記確認信号を受信してから前記応答信号を前記通信装置に送信するまでの時間である待機時間を調整する調整部と、を備え、前記調整部は、前記通信装置と前記対象サーバとの間の通信においてプロキシサーバが利用される場合に、前記待機時間として第１の時間を利用すべきことを前記対象サーバに指示し、前記通信装置と前記対象サーバとの間の通信において前記プロキシサーバが利用されない場合に、前記待機時間として前記第１の時間より長い第２の時間を利用すべきことを前記対象サーバに指示する。

【0007】

上記の構成によれば、サーバにおける確認信号の受信から応答信号の送信までの待機時間は、プロキシサーバが利用される場合に、比較的短い第１の時間に調整される。通信装置とサーバとの間にプロキシサーバが存在する場合には、通信装置とサーバとの間にプロキシサーバが存在しない場合と比較して、確認信号又は応答信号が遅延する可能性が高い。待機時間を短く調整することで、確認信号又は応答信号の遅延に起因して、通信確認が失敗することを抑制することができる。また、待機時間は、プロキシサーバが利用されない場合に、比較的長い第２の時間に調整される。通信装置とサーバとの間にプロキシサーバが存在しない場合には、通信装置とサーバとの間にプロキシサーバが存在する場合と比較して、確認信号又は応答信号が遅延する可能性が低い。待機時間を長く調整することで、所定の期間（例えば１日）内における通信確認の回数を少なくすることができる。以上より、プロキシサーバが存在するのか否かを考慮して、通信確認を適切に実行することができる。

【0008】

上記の通信装置を実現するための制御方法、コンピュータプログラム、及び、当該コンピュータプログラムを格納するコンピュータ読取可能記録媒体も、新規で有用である。

【図面の簡単な説明】

【0009】

【図1】通信システムの構成を示す。

【図2】比較例の処理のシーケンス図を示す。

【図3】第１実施例のプリンタの処理のフローチャートを示す。

【図4】プロキシサーバが利用されないケースＡ１を示す。

【図5】プロキシサーバが利用されるケースＡ２を示す。

【図6】第２実施例のプリンタの処理のフローチャートを示す。

【図7】プロキシサーバが利用されるケースＢを示す。

【図8】図７の続きを示す。

【発明を実施するための形態】

【0010】

（第１実施例）
（通信システム２の構成；図１）
図１に示されるように、通信システム２は、プリンタ１０と、サービス提供サーバ１００と、プロキシサーバ２００と、を備える。なお、以下では、サービス提供サーバのことを「ＳＰサーバ」と呼ぶ。

【0011】

プリンタ１０及びプロキシサーバ２００は、ＬＡＮ（Local Area Networkの略）４に接続されている。プロキシサーバ２００は、インターネット８に接続されている。また、ＳＰサーバ１００は、インターネット８に接続されている。プリンタ１０は、プロキシサーバ２００及びインターネット８を介して、ＳＰサーバ１００と通信可能である。

【0012】

プロキシサーバ２００は、ＬＡＮ４の管理者によって、ＬＡＮ４上に設置される。プロキシサーバ２００は、ＬＡＮ４に所属している装置（例えばプリンタ１０）とインターネット８との間の通信を仲介する。プリンタ１０は、プロキシサーバ２００を利用しなくても、例えば、単純なルータを利用して、インターネット８上の装置（例えばＳＰサーバ１００）との通信を実行可能である。プロキシサーバ２００を利用する利点は、以下の通りである。例えば、インターネット８上の装置は、プロキシサーバ２００を介して、ＬＡＮ４上の装置（例えばプリンタ１０）との通信を実行していたとしても、通信先がＬＡＮ４上のいずれの装置であるのかを特定することができない。従って、インターネット８上の装置側から見た場合に、匿名性が高まる。また、プロキシサーバ２００がインターネット８に関する情報をキャッシュすることによって、ＬＡＮ４上の装置がインターネット８を介した通信を実行する際に、高速な通信が可能となる。

【0013】

ＳＰサーバ１００は、プリンタ１０に関係するサービスをプリンタ１０のユーザに提供するためのサーバである。ＳＰサーバ１００は、ユーザにサービスを提供するために、後述するＨＴＴＰセッションを利用して、プリンタ１０の稼働状態を示す状態情報を要求する情報要求をプリンタ１０に送信し、プリンタ１０から状態情報を受信する。そして、ＳＰサーバ１００は、受信済みの状態情報を利用して、サービスを提供するための処理を実行する。サービスは、例えば、カートリッジを発送する発送サービスである。この場合、状態情報は、プリンタ１０のインクカートリッジの残量を示す残量情報を含む。ＳＰサーバ１００は、例えば、プリンタ１０から受信した残量情報によって示される残量が所定の閾値以下であると判断する場合に、プリンタ１０に装着されるべき新たなカートリッジを発送するための発送処理（例えば作業員への通知）を実行する。他の例として、サービスは、プリンタ１０の仕様状況（例えば印刷枚数）に応じた課金等によりプリンタ１０をユーザにリースするサービス、プリンタ１０のメンテナンスをユーザに提供するサービス、電子メールを利用した印刷であるメール印刷をユーザに提供するサービス等であってもよい。ここで、メール印刷では、ＳＰサーバ１００は、外部から画像データを含む電子メールを受信する場合に、後述するＨＴＴＰセッションを利用して、電子メールを受信したことを示す通知をプリンタ１０に送信する。そして、ＳＰサーバ１００は、プリンタ１０から当該通知に対する応答を受信する場合に、電子メール内の画像データをプリンタ１０に送信する。これにより、プリンタ１０は、当該画像データに従った印刷を実行し、メール印刷が実現される。

【0014】

（プリンタ１０の構成）
プリンタ１０は、印刷機能を備える装置である。プリンタ１０は、ＬＡＮインターフェース１２と、制御部３０と、を備える。各部１２、３０は、バス線（符号省略）に接続されている。なお、以下では、インターフェースのことを「Ｉ／Ｆ」と記載する。ＬＡＮＩ／Ｆ１２は、ＬＡＮ４を介した通信を実行するためのＩ／Ｆであり、ＬＡＮ４に接続されている。制御部３０は、ＣＰＵ３２と、メモリ３４と、を備える。ＣＰＵ３２は、メモリ３４に記憶されているプログラム４０に従って、様々な処理を実行する。メモリ３４は、揮発性メモリ、不揮発性メモリ等によって構成される。メモリ３４は、さらに、接続情報４２と、プロキシ設定情報４４と、を記憶する。

【0015】

接続情報４２は、インターネット８上のＳＰサーバ１００とプリンタ１０との間に、ＨＴＴＰ（Hypertext Transfer Protocolの略）に準じたＨＴＴＰセッションを確立するための情報である。ＨＴＴＰセッションは、いわゆる常時通信が可能なセッションであり、プリンタ１０の電源が切断されるまで確立され続けるセッションである。ＳＰサーバ１００は、ＨＴＴＰセッションを利用すれば、プリンタ１０から要求を受信しなくても、プリンタ１０が所属するＬＡＮ４のファイヤウォールを越えて、プリンタ１０に要求（例えば、上記の情報要求）を送信することができる。ＨＴＴＰセッションは、例えば、ＸＭＰＰ（eXtensible Messaging and Presence Protocolの略） ｏｖｅｒ ＢＯＳＨ（Bidirectional-streams Over Synchronous HTTPの略）に従ったセッションである。なお、ＨＴＴＰセッションは、ＸＭＰＰ ｏｖｅｒ ＢＯＳＨに従ったセッションに限らず、ＨＴＴＰに準じた他のプロトコル（例えばＷｅｂＳｏｃｋｅｔ）に従ったセッションであってもよい。

【0016】

接続情報４２は、プリンタ１０を認証するための認証情報（例えばアクセストークン）を含む。接続情報４２は、ＳＰサーバ１００によって生成される。例えば、接続情報４２は、プリンタ１０においてサービスを開始するための指示が入力される場合に、ＳＰサーバ１００からプリンタ１０に送信されて、プリンタ１０のメモリ３４に記憶される。そして、プリンタ１０は、メモリ３４内の接続情報４２を利用した通信をＳＰサーバ１００と実行する。これにより、ＳＰサーバ１００によってプリンタ１０が認証されて、プリンタ１０とＳＰサーバ１００との間にＨＴＴＰセッションが確立される。

【0017】

プロキシ設定情報４４は、プロキシサーバ２００を利用することを示す「ＯＮ」と、プロキシサーバ２００を利用しないことを示す「ＯＦＦ」と、のうちのいずれかの値を示す。プロキシ設定情報４４は、デフォルトでは「ＯＦＦ」を示す。プロキシ設定情報４４は、ユーザによって入力される。例えば、プロキシ設定情報４４として「ＯＮ」が入力される場合には、プロキシサーバ２００のアドレスと、プロキシサーバ２００との通信に利用されるポート番号と、が入力される。

【0018】

（比較例；図２）
実施例の処理を説明する前に、図２を参照して、比較例の処理を説明する。比較例のプリンタ９００は、プログラム４０とは異なるプログラムがメモリ３４に記憶されている点を除いて、実施例のプリンタ１０と同様である。図２の初期状態では、プリンタ９００のプロキシ設定情報４４は「ＯＮ」を示す。

【0019】

Ｔ１０では、プリンタ９００は、プリンタ９００においてサービスを開始するための指示が入力される場合に、ＳＰサーバ１００から接続情報４２（例えばアクセストークン）を受信して、当該接続情報４２をメモリ３４に記憶する。なお、プリンタ９００は、ＳＰサーバ１００から接続情報４２を受信した後にＨＴＴＰセッションを再び確立する場合に、ＳＰサーバ１００から接続情報４２を受信せずに、メモリ３４内の接続情報４２を利用して、ＨＴＴＰセッションを確立する。

【0020】

Ｔ２０Ａ、Ｔ２０Ｂでは、プリンタ９００は、メモリ３４内の接続情報４２を利用して、ＳＰサーバ１００との間にプロキシサーバ２００を介したＨＴＴＰセッションを確立する。具体的には、プリンタ９００とプロキシサーバ２００の間、及び、プロキシサーバ２００とＳＰサーバ１００の間に、ＨＴＴＰセッションが確立される。ＨＴＴＰセッションでは、通信障害を確認するための通信確認が繰り返し実行される。通信確認は、ＨＴＴＰセッションを確立する一方の装置（例えばプリンタ９００）が、ＨＴＴＰセッションを確立する他方の装置（例えばＳＰサーバ１００）にＫｅｅｐ Ａｌｉｖｅ信号を送信することと、一方の装置が、他方の装置から当該Ｋｅｅｐ Ａｌｉｖｅ信号に対する応答信号（以下では、「Ｋｅｅｐ Ａｌｉｖｅ応答」と記載）を受信することと、を含む。例えば、プリンタ９００では、ＴＣＰ（Transmission Control Protocolの略）に従った通信におけるタイムアウトの時間（例えば「５ｍｉｎ」）が設定されている。ここで「タイムアウト」は、例えば、いわゆるＴＣＰタイムアウトである。ＴＣＰタイムアウトは、ＴＣＰに従ったセッションの確立を維持可能な時間である。一般的に、ＴＣＰに従ったセッションが確立された後に、一方の装置が他方の装置から何ら信号を受信することなく、当該セッションの確立からＴＣＰタイムアウトの時間が経過する場合に、当該セッションは切断される。Ｋｅｅｐ Ａｌｉｖｅ信号の送信からタイムアウトの時間の経過前にＫｅｅｐ Ａｌｉｖｅ応答が受信される場合には、通信障害が発生していないと判断され、通信確認が成功する。一方、Ｋｅｅｐ Ａｌｉｖｅ信号の送信からタイムアウトの時間が経過するまでに、Ｋｅｅｐ Ａｌｉｖｅ応答が受信されない場合には、通信障害が発生していると判断され、通信確認が失敗する。通信確認が失敗する場合には、ＨＴＴＰセッションが切断される。なお、ＨＴＴＰセッションが切断されると、プリンタ９００は、ＳＰサーバ１００との間にＨＴＴＰセッションを再び確立することを試行する。

【0021】

ＨＴＴＰセッションでは、Ｋｅｅｐ Ａｌｉｖｅ信号の送信先である他方の装置がＫｅｅｐ Ａｌｉｖｅ信号を受信してから他方の装置がＫｅｅｐ Ａｌｉｖｅ応答を送信するまでの時間である待機時間を調整するためのＮｅｇｏｔｉａｔｉｏｎが実行される。Ｎｅｇｏｔｉａｔｉｏｎは、Ｋｅｅｐ Ａｌｉｖｅ信号の送信元である一方の装置が待機時間を他方の装置に指示することを含む。

【0022】

本比較例では、プリンタ９００は、Ｔ２０Ａ及びＴ２０Ｂにおいて、ＳＰサーバ１００とのＨＴＴＰセッションを確立すると、Ｔ２２Ａ～Ｔ２６Ｂにおいて、待機時間「３ｍｉｎ」を指示することを含むＮｅｇｏｔｉａｔｉｏｎをＳＰサーバ１００と実行する。具体的には、プリンタ９００は、Ｔ２２Ａにおいて、待機時間「３ｍｉｎ」を含むＮｅｇｏｔｉａｔｉｏｎ信号をプロキシサーバ２００に送信し、Ｔ２２Ｂにおいて、プロキシサーバ２００は、当該Ｎｅｇｏｔｉａｔｉｏｎ信号をＳＰサーバ１００に送信する。Ｎｅｇｏｔｉａｔｉｏｎ信号は、待機時間をＳＰサーバ１００に指示するための信号である。これにより、ＳＰサーバ１００は、Ｔ２４において、Ｎｅｇｏｔｉａｔｉｏｎ信号に従って、待機時間「３ｍｉｎ」を決定する。そして、ＳＰサーバ１００は、Ｔ２６Ａにおいて、決定済みの待機時間「３ｍｉｎ」を含むＮｅｇｏｔｉａｔｉｏｎ応答をプロキシサーバ２００に送信し、Ｔ２６Ｂにおいて、プロキシサーバ２００は、当該Ｎｅｇｏｔｉａｔｉｏｎ応答をプリンタ９００に送信する。Ｎｅｇｏｔｉａｔｉｏｎ応答は、Ｎｅｇｏｔｉａｔｉｏｎ信号の応答である。

【0023】

プリンタ９００は、ＳＰサーバ１００とのＮｅｇｏｔｉａｔｉｏｎを実行した後に、Ｋｅｅｐ Ａｌｉｖｅ信号のＳＰサーバ１００への送信を開始する。ここで、本比較例では、プリンタ９００のプロキシ設定情報４４は「ＯＮ」を示すので、プリンタ９００は、Ｔ３０Ａにおいて、ＬＡＮ４を介して、Ｋｅｅｐ Ａｌｉｖｅ信号をプロキシサーバ２００に送信する。

【0024】

プロキシサーバ２００は、Ｔ３０Ａにおいて、プリンタ９００からＫｅｅｐ Ａｌｉｖｅ信号を受信すると、Ｔ３０Ｂにおいて、Ｋｅｅｐ Ａｌｉｖｅ信号をＳＰサーバ１００に送信する。

【0025】

ＳＰサーバ１００は、Ｔ３０Ｂにおいて、インターネット８を介して、プロキシサーバ２００からＫｅｅｐ Ａｌｉｖｅ信号を受信する。そして、ＳＰサーバ１００は、Ｋｅｅｐ Ａｌｉｖｅ信号の受信から待機時間「３ｍｉｎ」が経過した後に、Ｔ３２Ａにおいて、インターネット８を介して、Ｋｅｅｐ Ａｌｉｖｅ応答をプロキシサーバ２００に送信する。

【0026】

上記したように、プロキシサーバ２００は、単純なルータと比較して、様々の機能を有する。このため、プロキシサーバ２００の内部処理の時間等の影響を受けて、プロキシサーバ２００を利用する場合にＳＰサーバ１００がＫｅｅｐ Ａｌｉｖｅ信号を受信するタイミングは、プロキシサーバ２００を利用しない場合にＳＰサーバ１００がＫｅｅｐ Ａｌｉｖｅ信号を受信するタイミングと比較して、遅くなる可能性が高い。本比較例では、プロキシサーバ２００がＳＰサーバ１００からＫｅｅｐ Ａｌｉｖｅ応答を受信したＴ３２Ａのタイミングは、プリンタ９００においてＴ３０ＡのＫｅｅｐ Ａｌｉｖｅ信号の送信からタイムアウトの時間「５ｍｉｎ」が経過内である。しかし、Ｋｅｅｐ Ａｌｉｖｅ信号が遅延する結果、プロキシサーバ２００は、Ｋｅｅｐ Ａｌｉｖｅ応答をタイムアウトの時間「５ｍｉｎ」の経過前にプリンタ９００に送信することができない。このため、通信確認が失敗する。この結果、ＨＴＴＰセッションが切断される。

【0027】

上記のようにプロキシサーバ２００が利用される場合には、Ｋｅｅｐ Ａｌｉｖｅ信号又はＫｅｅｐ Ａｌｉｖｅ応答が遅延する可能性がある。この場合、プリンタ９００とＳＰサーバ１００との間に通信障害が発生していないにも関わらず、タイムアウトの時間の経過に起因して、通信確認が失敗する。通信障害が発生していないにも関わらず、ＨＴＴＰセッションが不必要に切断される可能性がある。本実施例は、ＨＴＴＰセッションにおける両装置の間にプロキシサーバ２００が存在するのか否か（即ちプロキシサーバ２００が利用されるのか否か）を考慮して、通信確認を適切に実行することを実現する。

【0028】

（プリンタの処理；図３）
図３を参照して、本実施例のプリンタ１０が実行する処理について説明する。図３の処理は、プリンタ１０が接続情報４２をメモリ３４に記憶すること（即ち、サービスを開始するための指示が入力されること）、メモリ３４に接続情報４２に記憶されている状況において、プリンタ１０の電源がＯＮされること、及び、プロキシ設定情報４４を変更する操作がユーザによって行われたこと、のいずれかをトリガとして開始される。図３の処理は、プリンタ１０の電源がＯＦＦされると終了する。

【0029】

Ｓ１０では、ＣＰＵ３２は、図３の処理のトリガが特定のトリガであるのか否かを判断する。ここで、特定のトリガは、プリンタ１０が接続情報４２をメモリ３４に記憶すること、プロキシ設定情報４４を変更する操作がユーザによって行われたことの、いずれかである。ＣＰＵ３２は、図３の処理のトリガが特定のトリガであると判断する場合（Ｓ１０でＹＥＳ）に、Ｓ２０に進む。

【0030】

Ｓ２０では、ＣＰＵ３２は、現在のプロキシ設定情報４４が「ＯＮ」であるのか否かを判断する。ＣＰＵ３２は、現在のプロキシ設定情報４４が「ＯＮ」であると判断する場合（Ｓ２０でＹＥＳ）に、Ｓ２２において、ＮｅｇｏｔｉａｔｉｏｎにおいてＳＰサーバ１００に指示すべき待機時間として第１の時間（例えば「１ｍｉｎ」）を決定する。そして、ＣＰＵ３２は、第１の時間を後述するＳ３０の記憶値としてメモリ３４に記憶する。

【0031】

また、ＣＰＵ３２は、現在のプロキシ設定情報４４が「ＯＦＦ」であると判断する場合（Ｓ２０でＮＯ）に、Ｓ２４において、待機時間として上記の第１の時間より長い第２の時間（例えば「３ｍｉｎ」）を決定する。そして、ＣＰＵ３２は、第２の時間を後述するＳ３０の記憶値としてメモリ３４に記憶する。

【0032】

また、ＣＰＵ３２は、図３の処理のトリガが特定のトリガでない、即ち、図３の処理のトリガがメモリ３４に接続情報４２に記憶されている状況において、プリンタ１０の電源がＯＮされることであると判断する場合（Ｓ１０でＮＯ）に、Ｓ３０において、待機時間として記憶値を決定する。Ｓ２２、Ｓ２４、及び、Ｓ３０のいずれかの処理が終了すると、Ｓ４０の処理が実行される。

【0033】

Ｓ４０では、ＣＰＵ３２は、ＬＡＮＩ／Ｆ１２を介して、メモリ３４内の接続情報４２を利用して、ＨＴＴＰセッションをＳＰサーバ１００と確立する。そして、ＣＰＵ３２は、Ｓ２２、Ｓ２４、及び、Ｓ３０のいずれかの処理によって決定された待機時間をＳＰサーバ１００に指示することを含むＮｅｇｏｔｉａｔｉｏｎをＳＰサーバ１００と実行する。

【0034】

Ｓ４２では、ＣＰＵ３２は、ＬＡＮＩ／Ｆ１２を介して、Ｋｅｅｐ Ａｌｉｖｅ信号をＳＰサーバ１００に送信する。

【0035】

Ｓ４４では、ＣＰＵ３２は、Ｋｅｅｐ Ａｌｉｖｅ信号の送信が成功したのか否かを判断する。例えば、ＣＰＵ３２は、ＬＡＮ４とインターネット８との通信を仲介する仲介装置（例えばプロキシサーバ２００、単純なルータ等）からＫｅｅｐ Ａｌｉｖｅ信号を受信したことを示す受信通知を受信することができる場合には、Ｋｅｅｐ Ａｌｉｖｅ信号の送信が成功したと判断する。一方、ＣＰＵ３２は、仲介装置の電源がＯＦＦされている等の原因によって、仲介装置から受信通知を受信することができない場合には、Ｋｅｅｐ Ａｌｉｖｅ信号の送信が失敗したと判断する。ＣＰＵ３２は、Ｋｅｅｐ Ａｌｉｖｅ信号の送信が成功したと判断する場合（Ｓ４４でＹＥＳ）に、Ｓ４６に進み、Ｋｅｅｐ Ａｌｉｖｅ信号の送信が失敗したと判断する場合（Ｓ４４でＮＯ）に、Ｓ４０に戻る。Ｋｅｅｐ Ａｌｉｖｅ信号の送信が失敗する場合には、仲介装置の電源がＯＦＦされている等の原因によって、ＨＴＴＰセッションが切断されているので、ＣＰＵ３２は、Ｓ４０において、ＨＴＴＰセッションの再確立を試行する。

【0036】

Ｓ４６では、ＣＰＵ３２は、ＬＡＮＩ／Ｆ１２を介して、ＳＰサーバ１００からＳ４２のＫｅｅｐ Ａｌｉｖｅ信号に対するＫｅｅｐ Ａｌｉｖｅ応答を受信したのか否かを判断する。例えば、ＣＰＵ３２は、Ｓ４２のＫｅｅｐ Ａｌｉｖｅ信号の送信からタイムアウトの時間（例えば「５ｍｉｎ」）が経過する前にＳＰサーバ１００からＫｅｅｐ Ａｌｉｖｅ応答を受信する場合に、Ｓ４６でＹＥＳと判断して、Ｓ４２に進み、再び、Ｋｅｅｐ Ａｌｉｖｅ信号をＳＰサーバ１００に送信する。一方、ＣＰＵ３２は、ＳＰサーバ１００からＫｅｅｐ Ａｌｉｖｅ応答を受信しない場合（例えば、ＳＰサーバ１００からＫｅｅｐ Ａｌｉｖｅ応答が受信されることなく、Ｓ４２のＫｅｅｐ Ａｌｉｖｅ信号の送信からタイムアウトの時間が経過する場合、又は、タイムアウトの時間が経過するまでにＫｅｅｐ Ａｌｉｖｅ応答とは異なる信号がＳＰサーバ１００から受信される場合）に、Ｓ４６でＮＯと判断して、Ｓ４０に戻る。Ｓ４６でＮＯと判断される場合には、通信確認の失敗によってＨＴＴＰセッションが切断されるので、ＣＰＵ３２は、Ｓ４０において、ＨＴＴＰセッションの再確立を試行する。

【0037】

（プロキシサーバが利用されないケースＡ１；図４）
図４を参照して、プロキシサーバが利用されない状況において、図３の処理によって実現される具体的なケースＡ１を説明する。図４の初期状態では、プロキシ設定情報４４は「ＯＦＦ」を示す。なお、以下では、各デバイスの各ＣＰＵ（例えばプリンタ１０のＣＰＵ３２等）が実行する処理について、理解の容易さの観点から、各ＣＰＵを主体として記載せずに、各デバイス（例えばプリンタ１０等）を主体として記載する。また、以下では、プリンタ１０とＳＰサーバ１００との間では、ＬＡＮ４及びインターネット８を介して、通信が実行される。ただし、以下では、特に言及しない限り、「ＬＡＮ４を介して」及び「インターネット８を介して」という説明を省略する。

【0038】

プリンタ１０は、Ｔ１００において、サービスを開始するための指示が入力される場合に、ＳＰサーバ１００から接続情報４２を受信して、当該接続情報４２をメモリ３４に記憶する（図３のＳ１０でＹＥＳ）。

【0039】

Ｔ１０２では、プリンタ１０は、現在のプロキシ設定情報４４が「ＯＦＦ」であると判断する（Ｓ２０でＮＯ）。そして、Ｔ１１０では、プリンタ１０は、待機時間として第２の時間「３ｍｉｎ」を決定する（Ｓ２４）。

【0040】

Ｔ１２０では、プリンタ１０は、メモリ３４内の接続情報４２を利用して、ＨＴＴＰセッションをＳＰサーバ１００と確立する（Ｓ４０）。

【0041】

Ｔ１２２では、プリンタ１０は、待機時間「３ｍｉｎ」を含むＮｅｇｏｔｉａｔｉｏｎ信号をＳＰサーバ１００に送信する（Ｓ４０）。これにより、ＳＰサーバ１００は、Ｔ１２４において、Ｎｅｇｏｔｉａｔｉｏｎ信号に従って、待機時間「３ｍｉｎ」を決定する。そして、ＳＰサーバ１００は、Ｔ１２６において、決定済みの待機時間「３ｍｉｎ」を含むＮｅｇｏｔｉａｔｉｏｎ応答をプリンタ９００に送信する。

【0042】

続いて、プリンタ１０は、Ｔ１３０において、Ｋｅｅｐ Ａｌｉｖｅ信号をＳＰサーバ１００に送信する（Ｓ４２）。本ケースでは、プリンタ１０とＳＰサーバ１００との間に存在する仲介装置（図示省略、例えば単純なルータ）が正常に動作している。このため、Ｋｅｅｐ Ａｌｉｖｅ信号の送信が成功し（Ｓ４４でＹＥＳ）、ＳＰサーバ１００は、Ｔ１３０において、プリンタ１０からＫｅｅｐ Ａｌｉｖｅ信号を受信する。

【0043】

ＳＰサーバ１００は、Ｔ１３２において、Ｋｅｅｐ Ａｌｉｖｅ信号の受信から待機時間「３ｍｉｎ」が経過した後に、Ｋｅｅｐ Ａｌｉｖｅ応答をプリンタ１０に送信する。本ケースでは、プロキシサーバ２００が利用されず、単純なルータ等が利用されるので、Ｋｅｅｐ Ａｌｉｖｅ信号又はＫｅｅｐ Ａｌｉｖｅ応答が遅延する可能性が低い。このため、プリンタ１０は、タイムアウトの時間「５ｍｉｎ」が経過する前に、ＳＰサーバ１００からＫｅｅｐ Ａｌｉｖｅ応答を受信する。

【0044】

プリンタ１０は、Ｔ１３２において、ＳＰサーバ１００からＫｅｅｐ Ａｌｉｖｅ応答を受信したと判断し（Ｓ４６でＹＥＳ）、Ｔ１５０において、Ｋｅｅｐ Ａｌｉｖｅ信号をＳＰサーバ１００に再び送信する。Ｔ１５２は、Ｔ１３２と同様である。即ち、プリンタ１０は、通信確認を繰り返し実行し、各通信確認は成功する。

【0045】

プロキシサーバ２００が利用されない本ケースでは、待機時間は、比較的長い第２の時間「３ｍｉｎ」に調整される。プロキシサーバ２００が利用されない場合には、プロキシサーバ２００が利用される場合と比較して、Ｋｅｅｐ Ａｌｉｖｅ信号又はＫｅｅｐ Ａｌｉｖｅ応答が遅延する可能性が低い。待機時間を長く調整することで、所定の期間（例えば１日）内における通信確認の回数を少なくすることができる。

【0046】

（プロキシサーバが存在するケースＡ２；図５）
図５を参照して、プロキシサーバが利用される状況において、図３の処理によって実現される具体的なケースＡ２を説明する。ケースＡ２は、ケースＡ１の続きである。

【0047】

Ｔ２００では、プリンタ１０は、プロキシ設定情報４４を変更する操作がユーザによって行われることに応じて、プロキシ設定情報４４を「ＯＦＦ」から「ＯＮ」に変更する。ここで、プロキシ設定情報４４が変更されると、ＨＴＴＰセッションは切断される。

【0048】

Ｔ２０４では、プリンタ１０は、現在のプロキシ設定情報４４が「ＯＮ」であると判断する（Ｓ２０でＹＥＳ）。そして、Ｔ２１０では、プリンタ１０は、待機時間として第１の時間「１ｍｉｎ」を決定する（Ｓ２２）。

【0049】

Ｔ２２０では、プリンタ１０は、メモリ３４内の接続情報４２を利用して、プロキシサーバ２００を介したＨＴＴＰセッションをＳＰサーバ１００と再び確立する（Ｓ４０）。

【0050】

Ｔ２２２では、プリンタ１０は、プロキシサーバ２００を介して、待機時間「１ｍｉｎ」を含むＮｅｇｏｔｉａｔｉｏｎ信号をＳＰサーバ１００に送信する（Ｓ４０）。これにより、ＳＰサーバ１００は、Ｔ２２４において、Ｎｅｇｏｔｉａｔｉｏｎ信号に従って、待機時間「１ｍｉｎ」を決定する。そして、ＳＰサーバ１００は、プロキシサーバ２００を介して、決定済みの待機時間「１ｍｉｎ」を含むＮｅｇｏｔｉａｔｉｏｎ応答をプリンタ１０に送信する。

【0051】

続いて、プリンタ１０は、Ｔ２３０Ａにおいて、Ｋｅｅｐ Ａｌｉｖｅ信号をプロキシサーバ２００に送信する。これにより、プロキシサーバ２００は、Ｔ２３０Ｂにおいて、Ｋｅｅｐ Ａｌｉｖｅ信号をＳＰサーバ１００に送信する。

【0052】

ＳＰサーバ１００は、Ｔ２３０Ｂにおいて、プロキシサーバ２００からＫｅｅｐ Ａｌｉｖｅ信号を受信する。そして、ＳＰサーバ１００は、Ｋｅｅｐ Ａｌｉｖｅ信号の受信から待機時間「１ｍｉｎ」が経過した後に、Ｔ２３２Ａにおいて、インターネット８を介して、Ｋｅｅｐ Ａｌｉｖｅ応答をプロキシサーバ２００に送信する。

【0053】

本ケースの待機時間「１ｍｉｎ」は、図３の比較例の待機時間「３ｍｉｎ」より短い。このため、Ｔ２３２Ａでは、プロキシサーバ２００は、タイムアウトの時間「５ｍｉｎ」の経過前にＳＰサーバ１００からＫｅｅｐ Ａｌｉｖｅ応答を受信し、Ｔ２３２Ｂでは、プリンタ１０は、タイムアウトの時間「５ｍｉｎ」の経過前にプロキシサーバ２００からＫｅｅｐ Ａｌｉｖｅ応答を受信する。即ち、通信確認が成功する。

【0054】

プリンタ１０は、Ｔ２３２Ｂにおいて、ＳＰサーバ１００からＫｅｅｐ Ａｌｉｖｅ応答を受信したと判断し（Ｓ４６でＹＥＳ）、Ｔ２５０Ａにおいて、Ｋｅｅｐ Ａｌｉｖｅ信号をプロキシサーバ２００に再び送信する。Ｔ２５０Ｂ～Ｔ２５２Ｂは、Ｔ２３０Ｂ～Ｔ２３２Ｂと同様である。即ち、プリンタ１０は、通信確認を繰り返し実行し、各通信確認は成功する。

【0055】

プロキシサーバ２００が利用される本ケースでは、待機時間は、比較的短い第１の時間「１ｍｉｎ」に調整される。図３の比較例で説明したように、プロキシサーバ２００が利用される場合には、Ｋｅｅｐ Ａｌｉｖｅ信号又はＫｅｅｐ Ａｌｉｖｅ応答が遅延する可能性が高い。待機時間を短く調整することで、本ケースに示すように、Ｋｅｅｐ Ａｌｉｖｅ信号又はＫｅｅｐ Ａｌｉｖｅ応答の遅延に起因して、通信確認が失敗することを抑制することができる。

【0056】

（本実施例の効果）
本実施例の構成によれば、プリンタ１０は、プロキシサーバ２００が利用される場合（図３のＳ２０でＹＥＳ）に、待機時間を比較的短い第１の時間「１ｍｉｎ」に決定し（Ｓ２２）、プロキシサーバ２００が利用されない場合（Ｓ２０でＮＯ）に、待機時間を比較的長い第２の時間「３ｍｉｎ」に決定する（Ｓ２４）。即ち、プロキシサーバ２００が利用されるのか否かを考慮して、通信確認を適切に実行することができる。

【0057】

また、プリンタ１０は、プロキシ設定情報４４を変更する操作がユーザによって行われる場合（Ｓ１０でＹＥＳ）にも、変更後のプロキシ設定情報４４に応じて、待機時間を調整する（Ｓ２２又はＳ２４）。例えば、プロキシ設定情報４４が変更された後でも変更前のプロキシ設定情報４４に応じた待機時間が維持される比較例が想定される。この比較例では、プロキシ設定情報４４が「ＯＮ」に変更される場合でも比較的長い待機時間（例えば「３ｍｉｎ」）に維持されて、図３と同様に、通信確認が失敗する場合がある。さらに、この比較例では、プロキシ設定情報４４が「ＯＦＦ」に変更される場合でも比較的短い待機時間（例えば「１ｍｉｎ」）に維持されて、所定の期間（例えば１日）内における通信確認の回数が不必要に多くなる場合がある。これに対して、本実施例では、プロキシ設定情報４４が変更される場合でも、通信確認を適切に実行することができる。

【0058】

（対応関係）
プリンタ１０、ＬＡＮＩ／Ｆ１２が、それぞれ、「通信装置」、「通信インターフェース」の一例である。プロキシサーバ２００が、「プロキシサーバ」の一例である。ＳＰサーバ１００が、「対象サーバ」の一例である。ＸＭＰＰ ｏｖｅｒ ＢＯＳＨに従ったＨＴＴＰセッションが、「セッション」の一例である。Ｋｅｅｐ Ａｌｉｖｅ信号、Ｋｅｅｐ Ａｌｉｖｅ応答が、それぞれ、「確認信号」、「応答信号」の一例である。Ｓ２２の第１の時間「１ｍｉｎ」、Ｓ２４の第２の時間「３ｍｉｎ」が、それぞれ、「第１の時間」、「第２の時間」の一例である。

【0059】

図３のＳ４２～Ｓ４６が、通信確認部によって実現される処理の一例である。Ｓ４０のＨＴＴＰセッションの確立、Ｓ４０のＮｅｇｏｔｉａｔｉｏｎの実行が、それぞれ、「確立部」、「調整部」によって実現される処理の一例である。

【0060】

（第２実施例）
（プリンタの処理；図６）
本実施例は、プリンタ１０の処理において待機時間を延長又は短縮する処理が追加される点を除いて、第１実施例と同様である。

【0061】

Ｓ５０、Ｓ６０は、図３のＳ１０、Ｓ２０と同様である。ＣＰＵ３２は、現在のプロキシ設定情報４４が「ＯＮ」であると判断する場合（Ｓ６０でＹＥＳ）に、Ｓ６２及びＳ６３の処理を実行する。Ｓ６２は、図３のＳ２２と同様である。Ｓ６３では、ＣＰＵ３２は、待機時間として採用可能な時間の上限値として第１の値（例えば「４ｍｉｎ」）を決定する。そして、ＣＰＵ３２は、決定済みの上限値をメモリ３４に記憶する。ここで、上限値は、ＴＣＰタイムアウトの時間よりも短い時間である。

【0062】

また、ＣＰＵ３２は、現在のプロキシ設定情報４４が「ＯＦＦ」であると判断する場合（Ｓ６０でＮＯ）に、Ｓ６４及びＳ６５の処理を実行する。Ｓ６４は、図３のＳ２４と同様である。Ｓ６５では、ＣＰＵ３２は、待機時間として採用可能な時間の上限値として第１の値よりも長い第２の値（例えば「４．５ｍｉｎ」）を決定する。そして、ＣＰＵ３２は、決定済みの上限値をメモリ３４に記憶する。プロキシ設定情報４４が「ＯＦＦ」である場合、即ち、プロキシサーバ２００が利用されない場合に、上限値を比較的長くすることによって、所定の期間（例えば１日）内における通信確認の回数を可能な限り少なくすることができる。なお、変形例として、ＣＰＵ３２は、現在のプロキシ設定情報４４が「ＯＮ」であると判断する場合（Ｓ６０でＹＥＳ）に、さらに、タイムアウトとして第３の値（例えば「５ｍｉｎ」）を決定し、現在のプロキシ設定情報４４が「ＯＦＦ」であると判断する場合（Ｓ６０でＮＯ）に、さらに、タイムアウトとして第３の値より長い第４の値（例えば「６ｍｉｎ」）を決定してもよい。

【0063】

また、ＣＰＵ３２は、図３の処理のトリガが、メモリ３４に接続情報４２に記憶されている状況において、プリンタ１０の電源がＯＮされることであると判断する場合（Ｓ５０でＮＯ）に、Ｓ７０及びＳ７２に進む。Ｓ７０は、図３のＳ３０と同様である。Ｓ７２では、ＣＰＵ３２は、後述するＳ９２で決定された新しい上限値をリセットする。具体的には、ＣＰＵ３２は、プロキシ設定情報４４が「ＯＮ」である場合には、上限値として第１の値（Ｓ６３参照）を決定し、プロキシ設定情報４４が「ＯＦＦ」である場合には、上限値として第２の値（Ｓ６５参照）を決定する。Ｓ６３、Ｓ６５、及び、Ｓ７２のいずれかの処理が終了すると、Ｓ８０の処理が実行される。

【0064】

Ｓ８０～Ｓ８６は、図３のＳ４０～Ｓ４６と同様である。ＣＰＵ３２は、ＳＰサーバ１００からＫｅｅｐ Ａｌｉｖｅ応答を受信しないと判断する場合（Ｓ８６でＮＯ）に、Ｓ９０に進む。

【0065】

Ｓ９０では、ＣＰＵ３２は、ＳＰサーバ１００から何ら信号が受信されることなく、Ｓ８２のＫｅｅｐ Ａｌｉｖｅ信号の送信からタイムアウトの時間が経過することに起因して、ＳＰサーバ１００からＫｅｅｐ Ａｌｉｖｅ応答を受信しないと判断したのか否かを判断する。ＣＰＵ３２は、タイムアウト時間の経過に起因すると判断する場合（Ｓ９０でＹＥＳ）に、Ｓ９２に進む。

【0066】

Ｓ９２では、メモリ３４内の上限値に代えて、現在の待機時間を新しい上限値に決定する。そして、ＣＰＵ３２は、新しい上限値をメモリ３４に記憶する。通信確認の失敗の原因がタイムアウト時間の経過であると判断される状況において、現在の待機時間を再び待機時間として採用すると、タイムアウト時間の経過により通信確認が再び失敗する可能性が高い。通信確認の失敗の原因がタイムアウト時間の経過であると判断された場合の待機時間を上限値に決定することによって、タイムアウト時間の経過により通信確認が再び失敗することを抑制することができる。

【0067】

続いて、Ｓ９４では、ＣＰＵ３２は、待機時間を短縮する。具体的には、ＣＰＵ３２は、現在の待機時間に代えて、現在の待機時間から所定の時間（例えば「０．５ｍｉｎ」）を減算した値を新しい待機時間に決定する。Ｓ９４が終了すると、ＣＰＵ３２は、Ｓ８０に戻り、ＨＴＴＰセッションの再確立を試行する。

【0068】

また、ＣＰＵ３２は、タイムアウトの時間が経過するまでにＫｅｅｐ Ａｌｉｖｅ応答とは異なる信号がＳＰサーバ１００から受信されることに起因すると判断する場合（Ｓ９０でＮＯ）に、Ｓ９２及びＳ９４の処理をスキップして、Ｓ８０に戻る。ここで、上記の異なる信号は、例えば、メンテナンス等の原因によりＳＰサーバ１００がＫｅｅｐ Ａｌｉｖｅ応答を送信不可能であることを示す信号である。例えば、Ｓ９０の判断を実行せずに、通信確認が失敗するいずれの場合でも待機時間を短縮する比較例が構成される。この比較例では、タイムアウトの時間の経過が原因で待機時間を短縮する場合には、待機時間を短縮してタイムアウトの時間が経過することを抑制することができるものの、タイムアウトの時間の経過以外の原因で待機時間を短縮する場合には、当該原因を解消することができないにも関わらず、待機時間を不必要に短縮することになる。これに対して、Ｓ９０の判断を実行することによって、待機時間が不必要に短縮されることを抑制することができる。この結果、所定の期間（例えば１日）内における通信確認の回数が不必要に多くなることを抑制することができる。

【0069】

また、ＣＰＵ３２は、ＳＰサーバ１００からＫｅｅｐ Ａｌｉｖｅ応答を受信すると判断する場合（Ｓ８６でＹＥＳ）に、Ｓ１００に進む。Ｓ１００では、ＣＰＵ３２は、Ｓ８０でＨＴＴＰセッションが確立された後にＨＴＴＰセッションが一度も切断されることなくＫｅｅｐ Ａｌｉｖｅ応答を初めて受信したのか否かを判断する。ＣＰＵ３２は、Ｋｅｅｐ Ａｌｉｖｅ応答を初めて受信したと判断する場合（Ｓ１００でＹＥＳ）に、Ｓ１１０に進む。

【0070】

Ｓ１１０では、ＣＰＵ３２は、記憶値を延長する。具体的には、ＣＰＵ３２は、現在の記憶値に代えて、所定の時間（例えば「１ｍｉｎ」）を現在の記憶値に加算した値を新しい記憶値としてメモリ３４に記憶する。記憶値を延長することによって、図６の処理がプリンタ１０の電源ＯＦＦにより終了した後に、プリンタ１０の電源が再びＯＮされる場合に、ＣＰＵ３２は、Ｓ７０の処理を実行して、延長済みの記録値を待機時間として決定する。即ち、ＣＰＵ３２は、次回の電源ＯＮ時に適用すべき待機時間を延長する。なお、記憶値は、メモリ３４内の上限値を超えて延長されることはない。

【0071】

また、Ｋｅｅｐ Ａｌｉｖｅ応答を初めて受信していないと判断する場合（Ｓ１００でＮＯ）又はＳ１１０が終了する場合に、ＣＰＵ３２は、Ｓ８２に戻り、通信確認を再開する。なお、この場合には、ＳＰサーバ１００の待機時間は延長されない。即ち、Ｓ８０のＮｅｇｏｔｉａｔｉｏｎで決定された待機時間が維持される。

【0072】

（プロキシサーバが利用されるケースＢ；図７、図８）
図７、図８を参照して、プロキシサーバが利用される状況において、図６の処理によって実現される具体的なケースＢを説明する。本ケースでも、図５のＴ２００～Ｔ２１０と同様の処理が実行される。ここで、プリンタ１０は、第１の時間である待機時間「１ｍｉｎ」を記憶値として記憶する。そして、Ｔ３１２では、プリンタ１０は、上限値として第１の値「４ｍｉｎ」を決定する（図６のＳ６３）。そして、図５のＴ２２０～Ｔ２２６と同様のＴ３２０～Ｔ３２６の処理が実行され、ＳＰサーバ１００とのＨＴＴＰセッションが確立され、ＳＰサーバ１００の待機時間が「１ｍｉｎ」に決定される。

【0073】

Ｔ３３０Ａ～Ｔ３３２Ｂは、図５のＴ２３０Ａ～Ｔ２３２Ｂと同様である。Ｔ３３４では、プリンタ１０は、Ｔ３２０でＨＴＴＰセッションが確立された後にＨＴＴＰセッションが一度も切断されることなくＫｅｅｐ Ａｌｉｖｅ応答を初めて受信したと判断する（Ｓ１００でＹＥＳ）。Ｔ３３８では、プリンタ１０は、記憶値を「１ｍｉｎ」から「２ｍｉｎ」に延長する（Ｓ１１０）。

【0074】

Ｔ３４０Ａ～Ｔ３４２Ｂは、図７のＴ３３０Ａ～Ｔ３３２Ｂと同様である。即ち、ＳＰサーバ１００の待機時間は「１ｍｉｎ」に維持される。Ｔ３４４では、プリンタ１０は、Ｋｅｅｐ Ａｌｉｖｅ応答を初めて受信していないと判断し（Ｓ１００でＮＯ）、通信確認を繰り返す。

【0075】

Ｔ３４７では、プリンタ１０は、ユーザから電源をＯＦＦするための操作を受け付ける。この結果、確立済みのＨＴＴＰセッションが切断される。

【0076】

続いて図８に示すように、プリンタ１０は、Ｔ３４８において、ユーザから電源をＯＮするための操作を受け付ける。そして、Ｔ３４９では、プリンタ１０は、待機時間として記憶値「２ｍｉｎ」を決定する（図６のＳ５０でＮＯ、Ｓ７０）。Ｔ３５０～Ｔ３５６は、待機時間が「２ｍｉｎ」である点を除いて、図７のＴ３２０～Ｔ３２６と同様である。即ち、ＳＰサーバ１００は、待機時間「２ｍｉｎ」を決定する。

【0077】

Ｔ３６０Ａ～Ｔ３６２Ａは、待機時間が「２ｍｉｎ」である点を除いて、Ｔ３３０Ａ～Ｔ３３２Ａと同様である。しかし、本ケースでは、待機時間が「２ｍｉｎ」に延長されたことに起因して、ＳＰサーバ１００からＫｅｅｐ Ａｌｉｖｅ応答が受信されることなく、Ｔ３６０ＡのＫｅｅｐ Ａｌｉｖｅ信号の送信からタイムアウトの時間「５ｍｉｎ」が経過する。

【0078】

Ｔ３６４では、プリンタ１０は、タイムアウト時間の経過に起因して、ＳＰサーバ１００からＫｅｅｐ Ａｌｉｖｅ応答を受信しないと判断する（図６のＳ８６でＮＯ、Ｓ９０でＹＥＳ）。そして、Ｔ３６６では、プリンタ１０は、メモリ内の上限値「４ｍｉｎ」に代えて、現在の待機時間「２ｍｉｎ」を新しい上限値に決定する（Ｓ９２）。

【0079】

Ｔ３６８では、プリンタ１０は、待機時間を「２ｍｉｎ」から「１．５ｍｉｎ」に短縮する。Ｔ３７０～Ｔ３７６は、待機時間が「１．５ｍｉｎ」である点を除いて、Ｔ３５０～Ｔ３５６と同様である。Ｔ３８０Ａ～Ｔ３８２Ｂは、待機時間が「１．５ｍｉｎ」である点を除いて、図７のＴ３３０Ａ～Ｔ３３２Ｂと同様である。即ち、通信確認が成功する。

【0080】

（本実施例の効果）
本実施例によれば、プリンタ１０は、通信確認が成功する場合（図６のＳ８６でＹＥＳ）に、待機時間を延長する（Ｓ１１０）。これにより、待機時間を延長しない比較例と比較して、所定の期間（例えば１日）内における通信確認の回数を少なくすることができる。また、プリンタ１０は、通信確認が失敗する場合（Ｓ８６でＮＯ）に、待機時間を短縮する（Ｓ９４）。これにより、待機時間を短縮しない比較例と比較して、タイムアウト時間の経過に起因して通信確認が再び失敗することを抑制することができる。

【0081】

特に、ケースＢによれば、プリンタ１０は、タイムアウトの時間の経過に起因して通信確認が失敗する可能性の高い実際の待機時間「２ｍｉｎ」を考慮して、所定の待機時間「１ｍｉｎ」より長い適切な待機時間「１．５ｍｉｎ」に決定することができる（図７のＴ３６８）。プロキシサーバ２００が利用される場合の待機時間を所定の「１ｍｉｎ」に維持する第１実施例と比較して、所定の期間（例えば１日）内における通信確認の回数を少なくすることができる。

【0082】

（対応関係）
プリンタ１０のメモリ３４が、「メモリ」の一例である。タイムアウトの時間「５ｍｉｎ」が、「所定時間」の一例である。図６のＳ６３の第１の値「４ｍｉｎ」、Ｓ６５の第２の値「５ｍｉｎ」が、それぞれ、「第１の値」、「第２の値」の一例である。

【0083】

以上、本発明の具体例を詳細に説明したが、これらは例示にすぎず、特許請求の範囲を限定するものではない。特許請求の範囲に記載の技術には以上に例示した具体例を様々に変形、変更したものが含まれる。上記の実施例の変形例を以下に列挙する。

【0084】

（変形例１）「通信装置」は、プリンタ１０に限らず、例えば、スキャナ、複合機、ＰＣ等の端末装置であってもよい。

【0085】

（変形例２）上記の各実施例では、プリンタ１０は、プロキシ設定情報４４が変更される場合（図３のＳ１０でＹＥＳ）に、待機時間を第１の時間及び第２の時間のいずれかに調整する（Ｓ２２、Ｓ２４、Ｓ４０）。これに代えて、プリンタ１０は、プロキシ設定情報４４が変更される場合に、待機時間を調整しなくてもよい。本変形例では、「前記通信装置の状態が前記第２の状態から前記第１の状態に変更されて、前記セッションが再び確立される場合に、前記待機時間を前記第１の時間に調整」することと、「前記通信装置の状態が前記第１の状態から前記第２の状態に変更されて、前記セッションが再び確立される場合に、前記待機時間を前記第２の時間に調整」することと、を省略可能である。

【0086】

（変形例３）上記の第２実施例では、プリンタ１０は、待機時間の延長（図６のＳ１１０）と、待機時間の短縮（Ｓ９４）の双方を実行する。これに代えて、プリンタ１０は、待機時間の延長と待機時間の短縮のいずれか一方を実行してもよい。

【0087】

（変形例４）上記の第２実施例における図６のＳ９０の判断は実行されなくてもよい。一般的に言えば、「所定時間が経過することに起因」する場合と「前記応答信号とは異なる信号が前記対象サーバから受信されることに起因」する場合の双方で、待機時間を短縮してもよい。

【0088】

（変形例５）上記の第２実施例では、プロキシ設定情報４４が「ＯＦＦ」である場合における待機時間の上限値が、プロキシ設定情報４４が「ＯＮ」である場合における待機時間の上限値よりも長い（図６のＳ６５）。これに代えて、プロキシ設定情報４４が「ＯＦＦ」である場合における上限値が、プロキシ設定情報４４が「ＯＮ」である場合における上限値と同じであってもよい。本変形例では、「第２の値」を省略可能である。

【0089】

（変形例６）上記の第２実施例における図６のＳ９２の処理は実行されなくてもよい。本変形例では、「記憶制御部」を省略可能である。

【0090】

（変形例７）図６のＳ１１０の処理（即ち記憶値を延長する処理）が、「延長部」によって実現される処理の一例である。これに代えて、プリンタ１０は、Ｓ１００でＹＥＳと判断される場合に、現在の待機時間に代えて、所定の時間（例えば「１ｍｉｎ」）を現在の待機時間に加算した値を新しい待機時間に決定してもよい。即ち、プリンタ１０は、現在の待機時間を延長してもよい。そして、プリンタ１０は、ＨＴＴＰセッションを切断し、メモリ３４内の接続情報４２を利用して、ＨＴＴＰセッションをＳＰサーバ１００と再び確立してもよい。そして、プリンタ１０は、延長済み待機時間をＳＰサーバ１００に指示することを含むＮｅｇｏｔｉａｔｉｏｎをＳＰサーバ１００と実行して、Ｓ８２に戻ってもよい。本変形例において、現在の待機時間を延長することが、「延長部」によって実現される処理の一例である。

【0091】

（変形例８）上記の各実施例では、図３～図７の各処理がソフトウェア（例えばプログラム４０）によって実現されるが、これらの各処理のうちの少なくとも１つが論理回路等のハードウェアによって実現されてもよい。

【0092】

また、本明細書または図面に説明した技術要素は、単独であるいは各種の組合せによって技術的有用性を発揮するものであり、出願時請求項記載の組合せに限定されるものではない。また、本明細書または図面に例示した技術は複数目的を同時に達成するものであり、そのうちの一つの目的を達成すること自体で技術的有用性を持つものである。

【符号の説明】

【0093】

２：通信システム、８：インターネット、１０：プリンタ、１２：ＬＡＮＩ／Ｆ、３０：制御部、３２：ＣＰＵ、３４：メモリ、４０：プログラム、４２：接続情報、４４：プロキシ設定情報、１００：ＳＰサーバ、２００：プロキシサーバ

【図1】

【図2】

【図3】

【図4】

【図5】

【図6】

【図7】

【図8】