JP2017167845A - 通信装置、通信システム、通信方法およびプログラム - Google Patents

Abstract

【課題】通信装置の通信量およびメモリ消費を低減する。【解決手段】本発明の実施形態として通信装置は、ネットワークを介して、制御装置および処理装置のそれぞれと通信可能な通信装置であって、生成部と、制御部とを備える。前記生成部は、前記制御装置から前記処理装置が実行する処理の内容を指定した第１要求を受信した場合に、前記処理装置に対し前記処理の実行を指示する情報と、前記処理に関連する第１期限とを含むジョブを生成する。前記制御部は、前記ジョブの複数の状態間の遷移を制御する。前記制御部は、前記処理装置または前記制御装置から前記ジョブに対する第２要求を受信した場合に、前記第１期限と、前記ジョブの前記状態に基づいて、前記第２要求の実行を制御する。【選択図】図１

Description

本発明の実施形態は、通信装置、通信システム、通信方法およびプログラムに関する。

Ｗｅｂクライアントからジョブ実行要求を受け付けるジョブ管理サーバが知られている。ジョブ管理サーバは、複合機のＷｅｂブラウザを操作してアプリケーションから発行されたジョブや、モバイル端末等からの要求に基づいて発行されたジョブの実行要求を受け付ける。この際、ジョブ管理サーバは、アプリケーションから発行されたジョブを優先的に実行し、モバイル端末等からの要求に基づいて発行されたジョブの割り込みを排他する。

この技術は、ジョブの排他制御および優先制御に関するものであり、ジョブの要求元に応じた制御は行っているが、ジョブのライフサイクル（有効期限）制御など、ジョブの種類に依存した制御を行っていない。つまり、この技術は、ジョブのライフサイクルに関して、ジョブの種類に依存しない画一的なライフサイクルを想定しているものと考えられる。

これは、昨今IoT（Internet of Things）の文脈で注目されているプロトコルであるＭＱＴＴ等のメッセージキューにおいても同様である。メッセージキュー自体に、ジョブ種別の粒度でのタイムアウト管理機構がない。

様々なライフサイクルを持つジョブが混在する場合、画一的なライフサイクル制御は、サーバ側に、無駄なリソース消費を引き起こす。具体的には、テレビのチャネル変更のような即時処理が必要で、かつ即時処理されなければ破棄されてよいジョブと、テレビの録画予約のような比較的長い時間、実行までの猶予があるジョブとが混在する場合がある。後者の実行までの猶予があるジョブに合わせたタイムアウトを設定すると、前者の即時処理されなければ破棄されてよいジョブが、メモリ消費を招き、ジョブの実行装置との通信に係るコストを増大させる。

特開2014-153891号公報

本発明の実施形態は、通信量およびメモリ消費の少なくとも一方を低減するようにした通信装置、通信方法およびプログラムを提供する。

本発明の実施形態として通信装置は、ネットワークを介して、制御装置および処理装置のそれぞれと通信可能な通信装置であって、生成部と、制御部とを備える。前記生成部は、前記制御装置から前記処理装置が実行する処理の内容を指定した第１要求を受信した場合に、前記処理装置に対し前記処理の実行を指示する情報と、前記処理に関連する第１期限とを含むジョブを生成する。前記制御部は、前記ジョブの複数の状態間の遷移を制御する。前記制御部は、前記処理装置または前記制御装置から前記ジョブに対する第２要求を受信した場合に、前記第１期限と、前記ジョブの前記状態に基づいて、前記第２要求の実行を制御する。

本発明の実施形態に関わる通信システムの構成図。 ジョブ生成要求の例を示す図。 ジョブ生成応答の例を示す図。 データベースの例を示す図。 データベースの例を示す図。 データベースの例を示す図。 データベースの例を示す図。 ジョブ配送装置がジョブ生成要求を受信したときの動作のフローチャートを示す図。 状態遷移図の例を示す図。 ジョブ一覧取得応答の例を示す図。 ジョブ取得応答の例を示す図。 処理結果登録要求の例を示す図。 処理結果登録応答の例を示す図。 ジョブ結果検収要求の例を示す図。 検収応答の例を示す図。 ジョブ生成応答に接続先URLをマージした例を示す図。 本実施形態に係る具体的なシーケンスの例を示す図。 図１４に続くシーケンスを示す図。

以下、図面を参照しながら、本発明の実施形態について説明する。

図１は、本発明の実施形態に関わる通信システムの構成図である。本通信システムは、本実施形態に係る通信装置であるジョブ配送装置１０１と、制御装置２０１と、ジョブ処理装置３０１（処理装置）とを備える。ジョブ配送装置１０１と、制御装置２０１と、ジョブ処理装置３０１は、ネットワーク４０１を介して接続されている。

制御装置２０１は、ジョブ処理装置３０１が実行する処理の内容を指定した要求（ジョブ生成要求）を発行する。制御装置２０１は、典型的には、スマートフォンまたはタブレットといった携帯端末に搭載されている。制御装置２０１の当該ジョブ生成要求の発行に関わる動作は、当該装置上で動作するアプリケーションにより実現される。アプリケーションは、本装置のユーザによる指示を受けて、動作を行ってもよい。ユーザによる指示は、装置が備えるタッチパネル、キーボード、マウス等の入力インタフェースを介して入力される。

ジョブ配送装置１０１は、制御装置２０１のジョブ生成要求を受けて、ジョブ処理装置３０１に当該処理の実行を指示する情報（実行指示情報）および期限（処理の実行期限など）を含むジョブを生成する。ジョブ配送装置１０１は、生成したジョブをリストまたはデータベースで管理する。ジョブ配送装置１０１は、所定の状態遷移図に基づき、ジョブの複数の状態および状態間の遷移を管理する。ジョブ配送装置１０１は、期限と、前記ジョブの状態に基づいて、制御装置２０１またはジョブ処理装置３０１から受信する要求の実行を制御する。例えば、ジョブの状態に応じて、制御装置２０１またはジョブ処理装置３０１から、受け付け可能な要求の種類が定められている。ジョブ配送装置１０１は、ジョブがある状態のときに、特定の要求を受け付け、実行することで、ジョブの状態を遷移させる。また、期限が過ぎることで、状態を遷移させることもある。ジョブ配送装置１０１の詳細は後述する。

ジョブ処理装置３０１は、ジョブ配送装置２０１からジョブを取得し、ジョブに含まれる実行指示情報に応じて、指示された動作を行う。ジョブ処理装置３０１は、典型的には、テレビ等のデジタル機器、白物家電、住宅設備、工場設備、センサー‥アクチュエータなどの省リソースデバイスなどに搭載されている。なお、ジョブ処理装置３０１が機器内に組み込まれるのではなく、ネットワークを介して当該機器と接続されてもよい。

ネットワーク４０１は、制御装置２０１とジョブ配送装置１０１間の通信を実現し、ジョブ配送装置１０１とジョブ処理装置３０１間の通信を可能にする。例えば、制御装置２０１が携帯網（3G、LTE（登録商標）、WiMAX（登録商標）等）に接続され、ジョブ配送装置１０１がクラウドサービス内のイントラネットに接続され、ジョブ処理装置３０１が宅内ローカルネット（Ethernet（登録商標）、Wi-Fi（登録商標）等）に接続される場合を想定する。この場合、ネットワーク４０１は、これらの携帯網、イントラネット、ローカルネットと、これらと接続される広域網（インターネット）とにより構成される。これにより、ジョブ配送装置１０１と、制御装置２０１と、ジョブ処理装置３０１が、ネットワーク４０１を介して、相互通信できる。このようにネットワーク４０１は、複数種類のネットワークで構成される。ネットワーク４０１上には、実際には、ブロードバンドルータ、各ネットワークをつなぐゲートウェイ装置が存在し得るが、これらの図示は省略されている。

上述のネットワーク構成は、あくまで一例である。制御装置２０１は、ジョブ処理装置３０１と同様、宅内ネットワークに接続されていてもよい。ジョブ処理装置３０１が、3G通信モジュールを備え、携帯網など介して直接、インターネットに接続されてもよい。ジョブ配送装置１０１が、パブリッククラウドに設置されてもよい。３者（ジョブ配送装置１０１、制御装置２０１、ジョブ処理装置３０１）が１つのクローズドなネットワーク上に配置される構成も考えられる。

ジョブ配送装置１０１は、一般的な計算機（CPU、メモリ、ストレージ等）で構成される。ジョブ配送装置１０１、サーバソフトウェアによりその機能が実現されるサーバ装置でもよい。仮想マシン上で動作するソフトウェアにより、ジョブ配送装置１０１の機能が実現されてもよい。ジョブ配送装置１０１は、典型的には、HTTP（Hypertext Transfer Protocol）を利用するWebサーバである。ただし、通信プロトコルは、CoAP（Constrained Application Protocol）など、同等機能を実現できるものであれば、なんでも良い。

ジョブ配送装置１０１は、通信部１１１、生成部１１２と、提供部１１３と、更新部１１４と、削除部１１５と、管理部１１６と、制御部１１７と、通知部１１８と、記憶部１１９とを備える。要素１１１〜１１８は、ＣＰＵ等のプロセッサまたは専用回路のような、任意の回路によって実現されてもよい。当該回路は、集積回路でもよい。要素１１１〜１１８を実装する回路は、互いに物理的に異なる回路でもよいし、それらの幾つかが物理的に同じ回路でもよい。

通信部１１１は、ネットワーク４０１と通信を行うための通信インタフェースと、OS（Operating System）の通信プロトコル処理層と、ジョブ配送に係る通信を実現する通信プロトコル処理層とを備える。通信インタフェースは、接続先のネットワーク４０１の種類に応じたデータリンク層および物理層の処理を行う。接続先のネットワーク４０１が無線ＬＡＮであれば、通信インタフェースは、無線ＬＡＮのＭＡＣ層および物理層の処理を行う。OSの通信プロトコル処理層の例として、TCP/IPまたはUDP/IP等がある。ジョブ配送に係る通信プロトコル処理層の例として、HTTPまたはHTTPS等がある。

通信部１１１は、一例として、１つのネットワークボード上にその機能がすべて搭載されてもよい。あるいは、通信インタフェースがネットワークボードで実現され、ＯＳおよびジョブ配送に係る通信プロトコル処理層が、バス等に接続されたＣＰＵの動作により実現されてもよい。あるいは、通信インタフェースと、ＯＳの通信プロトコル処理がネットワークボード上で実現され、ジョブ配送に係る通信プロトコル処理が、バス等に接続されたＣＰＵの動作により実現されてもよい。

通信部１１１は、ネットワーク４０１を介して、制御装置２０１からジョブ生成要求を受信する。ジョブ生成要求は、ジョブの生成に必要な制御依頼情報を含む。ジョブ生成要求の例を図２（Ａ）および図２（Ｂ）に示す。図２（Ａ）は、ジョブ処理装置３０１に実行させる処理の内容として、機器（ここではテレビを想定）の電源をオンにすることを指示している。

図２（Ｂ）は、ジョブ生成要求の他の例として、ジョブ実行期限（以下、実行期限）およびジョブ処理結果閲覧期限（以下、閲覧期限）等の期限情報が含まれる例を示す。requestExpiredIn属性は、ジョブの実行期限を示す。responseExpiredIn属性は、ジョブの処理結果等の実行状況が、本装置に登録されてから、参照可能な期限（すなわち処理結果等の実行状況を表す情報を提供可能な期限）を表す。図２（Ｂ）の１行目は図２（Ａ）と同様である。２行目は、ジョブ処理装置３０１でジョブが１時間（３６００秒）以内に処理されなければジョブを無効化することを示す。また、２行目は、ジョブ処理装置３０１のジョブの処理結果を、処理完了から１０時間（３６０００秒）は、参照可能の状態で残しておき、１０時間を過ぎたら、無効化することを示している。無効化は、当該ジョブそのものを削除する場合、内部的にはジョブの情報を残しておき外部からは見えなくする場合の少なくともいずれか一方含む。

HTTPプロトコルの場合、ジョブ生成要求メッセージのリクエストラインは、例えば、“POST /v1/devices/:device_id/jobs”のように記述される。“:device_id”は、ジョブ処理装置３０１の識別情報（ＩＤ）である。なお、このリクエストラインの例は、あくまでREST記法に則った一例であり、この表記に限定されるわけではない。また、メッセージのボディラインには、図２（Ａ）または図２（Ｂ）に示したような記述を有する制御依頼情報を設定する。

生成部１１２は、通信部１１１を介してジョブ生成要求（図２参照）を受信し、ジョブ生成要求に基づき、以下の項目を含むジョブを生成する。
（１）ジョブのＩＤ
（２）ジョブの実行先であるジョブ処理装置３０１のＩＤ
（３）要求元である制御装置２０１のＩＤ
（４）ジョブ処理装置３０１に実行させる処理の内容
（５）ジョブが生成された時刻のタイムスタンプ
（６）期限情報（実行期限、閲覧期限など）

一例として、（２）、（３）および（４）の組は、ジョブ処理装置３０１に処理の実行を指示する情報（実行指示情報）に対応する。実行指示情報に、他の項目、例えば（１）、（５）、または（６）の少なくとも１つ、またはここに列挙されていない項目が含まれても良い。

生成部１１２は、ジョブを生成したら、ジョブ生成応答を、制御装置２０１に送信する。ジョブ生成応答には、生成されたジョブの全部の情報または一部が含まれる。ジョブ生成応答の例を図３に示す。

“id”はジョブＩＤである。”requesterId”は、制御装置２０１（requester）のＩＤ、すなわちユーザＩＤである。”responderId”はジョブ処理装置３０１のＩＤである。”request”は、ジョブ処理装置３０１に実行させる処理の内容である。 “requestExpiredIn”は、ジョブの実行期限である。“responseExpiredIn”は閲覧期限である。“createdAt”はジョブが生成された時刻のタイムスタンプである。

図示の例では、ジョブＩＤが“123456789000”、制御装置２０１のＩＤが“ａｌｉｃｅ”、ジョブ処理装置３０１のＩＤが“0724517763699939”である。要求する処理の内容が、機器の電源をオンにすること（“ｐｏｗｅｒ”：“ｏｎ”）である。実行期限は１時間（３６００秒）である。閲覧期限も１時間（３６００秒）である。ジョブの生成時刻のタイムスタンプ（createdAt）は、“2015-01-01T00:00:00”である。実行期限の起点は、一例として、このタイムスタンプである。閲覧期限の起点は、ジョブの実行が完了した時刻（後述）を想定するが、閲覧期限の起点を、タイムスタンプ（createdAt）としてもよい。

図３のジョブ生成応答の例は、あくまで一例であり、一部の項目がなかったり、他の項目が含まれても良い。例えば、実行期限の代わりに、ジョブの実行時刻、またはジョブ実行の時間範囲が指定されてもよい。あるいは、即時実行が指定されてもよい。実行時刻が指定された場合、その時刻に処理を実行することを意味する。時間範囲が指定された場合、この範囲内の任意の時刻で処理を実行することを意味する。即時実行は、生成されたジョブを即時に実行（ジョブ処理装置３０１に即時に送信）することを意味する。なお、後述するように、この場合、ジョブ処理装置３０１とジョブ配送装置１０１とでプッシュ型の通知が可能なようにコネクションを設定しておく必要がある。実行期限が０（無し）の場合を、即時実行と扱ってもよい。

生成部１１２は、ジョブ生成要求に期限（実行期限および閲覧期限等）の要求値が含まれる場合は、当該要求値に基づき、期限を決定する。一例として、ジョブ生成要求で要求された値をそのまま期限として用いる。ただし、ジョブ生成要求で指定された期限の値が、事前に定めた上限値を越える場合、または下限値を下回る場合は、上限値または下限値を期限として設定してもよい。

例えば、閲覧期限の上限値が１時間であり、ジョブ生成要求で要求された閲覧期限の要求値が１０時間であれば、１０時間を１時間に短縮し、これを閲覧期限とする。図３に示した例では、閲覧期限が１時間に設定されている。

ジョブ生成要求に期限が含まれていない場合は、期限としてデフォルト値を設定してもよい。例えば期限の上限値または下限値を設定してもよい。あるいは、上限値と下限値との中央値を設定してもよい。なお、処理の種類に応じて、期限の上限値および下限値（あるいは期限のデフォルト値）は異なってよい。つまり、処理の種類に応じて、期限の値を変えても良い。例えば、ＴＶの録画データの消去を要求する処理であれば、実行期限を２４時間などと長くし、チャネル切り替えを要求する指示であれば、実行期限を例えば３０秒などと短くする。

なお、制御装置２０１のＩＤである“alice”は、これがジョブ生成要求に含まれている場合は、当該要求から抽出して用いてもよい。または、ジョブ配送装置１０１が、ジョブ生成要求のメッセージの送信元のアドレスから”alice”を特定してもよい。この場合、制御装置２０１のアドレスとＩＤとを対応づけた対応データを、ジョブ配送装置が備えているものとする。また、タイムスタンプ（createdAt）は、本装置が内部に備える時計から取得してもよいし、ネットワーク４０１を介して、時刻サーバから取得してもよい。タイムスタンプは、一例として、ジョブが実際に生成された時刻、ジョブ生成要求を受信した時刻、あるいは、その他の時刻を用いてもかまわない。

生成部１１２は、生成したジョブを、記憶部１１９のデータベースに登録する。記憶部１１９は、ＤＲＡＭ、ＳＲＡＭ、ＮＡＮＤ、ＭＲＡＭまたはＦＲＡＭ等のメモリでもよいし、ハードディスクまたはＳＳＤ等のハードウェア記憶デバイスでもよい。記憶部１１９は、本装置に内蔵されたものでも、外付けされたものでもよい。また、記憶部１１９は、任意のネットワーク４０１を介して本装置に接続されたサーバでもよい。データベースの例を図４に示す。１つの行（横列）が１つのジョブに対応する。当該１つの行における全てのセルに最初から値が入っている必要は無く、処理の段階に応じて、値が追加されていく。例えば１行目は、図２（Ｂ）の場合に対応する。ジョブが生成された時点では、ジョブＩＤ、ユーザＩＤ、ジョブ処理装置ＩＤ、処理内容、ジョブ状態、実行期限、閲覧期限、ジョブ生成時刻が設定される。これら以外のセルは、現時点では、空白になっている（図４では当該セルが空白の場合が示される）。ジョブ状態は、後述するように、この時点では生成状態（”created”）（後述する図６参照）が設定される。データベースにおける各ジョブは、例えば生成された順に並べられている。

ジョブ処理装置３０１に送信するジョブ生成応答は、生成したジョブの全体を含んでもよいし、ジョブの一部の情報のみを含んでもよい。例えばジョブＩＤと、期限情報のみを含んでもよい。

ジョブ配送装置１０１からジョブ生成応答を受信した制御装置２０１は、ジョブの内容を確認することで、ジョブ生成要求がジョブ配送装置１０１で正常に処理されて、ジョブが登録されたことを確認できる。また、制御装置２０１が実行期限および閲覧期限等を指定した場合に、これらの期限がジョブ配送装置１０１で変更されたか等も確認できる。制御装置２０１は、ジョブ配送装置との間で送受信する情報を、画面に表示して、装置のユーザに確認させてもよい。ユーザは、適宜、制御装置２０１に指示を入力して、所望の動作を行わせることができる。

図２または図３の例では、期限を相対時間(秒)で表現しているが、時刻などの絶対値で表現するバリエーションもありえる。例えば２０ＸＸ年Ｙ月Ｘ日ＡＡ時ＢＢ分ＣＣ秒から、２０ＸＸ年Ｙ月Ｘ日ＤＤ時ＥＥ分ＦＦ秒までのように表現してもよい。

図５は、ジョブ配送装置１０１がジョブ生成要求を受信したときの動作のフローチャートを示す。ここではジョブ生成要求に期限（実行期限、閲覧期限等）が指定されている場合の例を示す。

生成部１１２は、通信部１１１を介して、制御装置２０１から、ジョブ生成要求を受信すると（Ｓ１０１）、ジョブ生成要求から制御依頼情報を取得する（Ｓ１０２）。ジョブ制御依頼情報の例として、ジョブ処理装置３０１が実行する処理の内容（TVのオンなど）および、期限（実行期限、閲覧期限等）がある。

当該依頼された期限が上限値以下か、または下限値以上かを判断する（Ｓ１０３）。依頼された期限が、上限値以下、または下限値以上の場合は、期限（実行期限、閲覧期限等）として、依頼された期限の値を採用する。採用した値を期限として設定したジョブを生成する（Ｓ１０５）。生成部１１２は、生成したジョブを、記憶部１１９のデータベースに登録する。

一方、依頼された期限が、上限値より大きい場合、または下限値より小さい場合は、上限値または下限値を、期限に決定する。当該期限を設定したジョブを生成する（Ｓ１０４）。生成部１１２は、生成したジョブを、記憶部１１９のデータベースに登録する。

生成部１１２は、生成したジョブの全部の情報または一部を含むジョブ生成応答を、通信部１１１を介して、制御装置２０１に送信する（Ｓ１０６）。

この後、ジョブ配送装置１０１は、提供部１１３、管理部１１６、制御部１１７、更新部１１４、削除部１１５、通知部１１８を用いて、ジョブの制御および管理を行う（Ｓ１０７）。以下、提供部１１３、管理部１１６、制御部１１７、更新部１１４、削除部１１５、通知部１１８の詳細を説明する。

図６は、ジョブの状態遷移図を示す。制御部１１７は、この状態遷移図に基づき、ジョブの複数の状態および状態間の遷移を制御する。制御部１１７は、各状態で、制御装置２０１またはジョブ処理装置３０１からの要求の実行を制御する。

図６の状態遷移図は、ジョブの複数の状態と、複数の状態遷移とを含む。ジョブの状態として、生成済状態“created”, 割当済状態“assigned”, 実行済状態“executed”, 検収済状態“confirmed”, 実行期限徒過状態executionExpired”、削除状態”removed”が定義される。生成部１１２でジョブが生成された時、制御部１１７は、ジョブの状態として、”created”を設定する。

各状態では、制御装置２０１またはジョブ処理装置３０１から受け付け可能な要求が制限されている（排他制御）。ある状態から、別の状態への遷移は、当該ある状態で、該当する要求を実行することで行われる。また、ある状態のときに、所定の期限（実行期限、閲覧期限等）が過ぎることで、状態遷移が行われる場合もある。

制御部１１７は、提供部１１３、更新部１１４、削除部１１５、通知部１１８と連携して、図６に示した状態遷移図に従って、ジョブ状態の遷移を制御する。

図において、”requester”は、制御装置２０１、”responder”は、ジョブ処理装置３０１を示す。”GET”は取得要求、”PUT”は更新要求、”DELETE”は削除要求を表す。図における状態間を結ぶ実線は、制御装置２０１またはジョブ処理装置３０１からの要求が実行されたときに行われる状態遷移を表す。破線は、期限が過ぎた場合、または一定時間が経過した場合に生じる状態遷移を表す。

提供部１１３、更新部１１４、削除部１１５は、制御装置２０１またはジョブ処理装置３０１から要求を受けた場合は、制御部１１７を介して、当該要求を実行できるかを判断する。制御部１１７は、該当するジョブの状態に基づき、当該要求を実行できるかを判断する。実行できる場合は、当該要求を実行するように、提供部１１３、更新部１１４，削除部１１５を制御する。実行できない場合は、エラー応答を送信する。エラー応答の例として、HTTPプロトコルの場合は、409(Conflict)または405(Method Not Allowed)などがある。提供部１１３は取得要求、更新部１１４は更新要求、削除部１１５は削除要求を処理する。

提供部１１３は、ジョブ状態が”created”、”assigned”、”executed”, “confirmed”、または”executionExpired”のときに、制御装置２０１から、ジョブIDを含むジョブ取得要求を受け付け可能である。またはジョブ状態が”assigned”、”executed”, “confirmed”、または”executionExpired”のときに、ジョブ処理装置３０１から、ジョブIDを含むジョブ取得要求を受け付け可能である。なお、”executionExpired”のジョブ状態を持つジョブに関しては、“removed”状態と同様に、ジョブ取得要求の応答に当該ジョブの情報を含めない実現形態を取ってもよい。

提供部１１３は、ジョブIDを含むジョブ取得要求に応じて、ジョブを記憶部１１９からジョブを取得し、取得したジョブを含む応答（ジョブ取得応答）を送信する。ＨＴＴＰの場合、制御装置２０１から送信するジョブ取得要求のリクエストラインは、例えばGET /v1/devices/:device_id/jobs/:job_idである。ジョブ処理装置３０１から送信するジョブ取得要求のリクエストラインは、例えばGET /v1/self/jobs/:job_idである。なお、ジョブ取得応答に含めるジョブは、ジョブの全情報でも一部の情報でもよい。また、ジョブ取得要求を実行するときの状態に応じて、ジョブ取得応答に含める情報の内容を代えてもよい。

また、提供部１１３は、特定のジョブIDの指定を含まないジョブ取得要求（ジョブ一覧取得要求と呼ぶ）を受け付け可能である。ジョブ一覧取得要求は、範囲（取得開始インデックスと件数）を含んでもよいし、フィルタ条件を含んでも良いし、これらの両方を含んでもよい。例えばフィルタ条件として、ジョブIDの範囲、装置IDなどを指定してもよい。あるいは、制御部１１３は、暗黙的に、制御装置２０１またはジョブ処理装置３０１に対するすべてのジョブを、応答してもよい。また、ジョブ処理装置３０１が、まだ取得していないジョブのみの応答を要求してもよい。最大応答件数が定まっている場合は、複数回、ジョブ一覧取得要求を送信することで、複数回にわけて応答（ジョブ一覧取得応答）を受信してもよい。

ＨＴＴＰの場合、制御装置２０１が送信するジョブ一覧取得要求のリクエストラインは、例えば、GET /v1/devices/:device_id/jobsである。ジョブ処理装置３０１が送信するジョブ一覧取得要求のリクエストラインは、例えばGET /v1/self/jobsである。

ジョブ取得要求またはジョブ一覧取得要求のリクエストラインには、ジョブ処理装置３０１のＩＤ、制御装置２０１のＩＤ、制御装置２０１のユーザのＩＤいずれかのＩＤが設定されてもよい。これらはリクエストラインのパラメータとして設定されてもよい。または、当該ＩＤを、リクエストラインではなく、ヘッダラインに追加してもよい。

ジョブ一覧取得応答に含めるジョブの情報は、ジョブＩＤを指定した場合のジョブ取得応答に含めるジョブの情報と異なってもよい。例えば、ジョブ一覧取得応答の場合、ジョブの情報をサマライズしたもの（すなわちジョブに含まれる情報の一部）を含めてもよい。サマライズした情報の例として、例えば、ジョブＩＤだけを含むものであってよいし、ジョブＩＤとジョブ状態のみを含む情報であってよい。その他、ジョブＩＤと、タイムスタンプと期限情報のみを含む情報であってよい。この場合の情報の例を図７に示す。２つのジョブについて、それぞれサマライズした情報が含まれている。

ジョブ配送装置１０１で生成したジョブが、はじめてジョブ処理装置３０１に取得される場合として、ジョブ処理装置３０１からジョブ一覧取得要求を受け付けた場合がある。ジョブ処理装置３０１がまだ取得していないジョブのみを要求したい場合は、この旨を指定したジョブ一覧取得要求を送信すればよい。別の方法として、提供部１１３が、生成部１１２でジョブが生成された時点で、ジョブ処理装置３０１に、当該ジョブを通知（プッシュ型の通知）する方法も可能である。この場合、通知部１１８は、事前にジョブ処理装置３０１と通知用の接続を確立しておく。なお、後述するように通知部１１８は、ジョブ処理装置３０１または制御装置２０１またはこれらの両方とそれぞれ通知用の接続を確立および維持することで、プッシュ型の通知を可能にする。通知部１１８の詳細は後述する。

提供部１１３は、ジョブ処理装置３０１に対して初めて提供するジョブについては、当該ジョブを提供するときに、制御部１１７を介して、その状態を、“created”から、”assgined”に変更する。図６に示されるように、状態が”created”のときに、ジョブ処理装置３０１(responder)から、取得要求（responder GET）を受けて実行すると、制御部１１７は、ジョブの状態を、”assigned”に遷移させる。

提供部１１３または制御部１１７は、ジョブの状態が”assgined”に変更された時刻、すなわちジョブをジョブ処理装置３０１に割り当てた時刻のタイムスタンプを、ジョブに設定する。具体的に、図４Ｂに示すように、データベースにおける当該ジョブを更新する。ジョブの状態が”assigned”に変更されている。また、割当時刻のタイムスタンプが追加されている。ジョブ処理装置３０１には、このタイムスタンプを設定したジョブを応答する。図８に、ジョブ取得応答の例を示す。図３の情報に対して、タイムスタンプ（”assignedAt”）が追加されている。

なお、ジョブ一覧取得要求に応じてジョブの割り当てを行う構成も可能である。この場合は、ジョブIDを指定したジョブ取得要求と同様に状態を“created”から、”assgined”に変更するとともに、タイムスタンプ（”assignedAt”）を設定してもよい。ジョブ一覧取得応答には、タイムスタンプ（”assignedAt”）を含めてよい。

図６に示されるように、ジョブ状態が”assgined”のときは、制御装置２０１から取得要求（requester GET）を受け付け可能である。また、ジョブ処理装置３０１から取得要求（responder GET）、および更新要求（responder PUT）を受け付け、および実行可能である。

更新部１１４は、状態が”assigned”のときにジョブ処理装置３０１から、ジョブIDを含むジョブ更新要求（responder PUT）（後述する処理結果登録要求）を受け付けた場合、制御部１１７を介して、該当ジョブの状態を”executed”に更新する。また、状態が”executed”のときに制御装置２０１から、ジョブIDを含むジョブ更新要求（requester PUT）（後述する検収要求）を受け付けた場合、検査の後、該当ジョブの状態を”confirmed”更新する。

ここで、ジョブ処理装置３０１が送信するジョブ更新要求のリクエストラインは、例えば、PATCH /v1/self/jobs/:job_idである。制御装置２０１が送信するジョブ更新要求のリクエストラインは、例えばPATCH /v1/devices/:device_id/jobs/:job_idである。これは、前述したようにREST記法に則った場合の例であり、他のメソッドPUTまたはPOSTなどを使って代替してもよい。更新の具体的な内容は、リクエストラインにパラメータとして設定してもよいし、メッセージのボディ部ラインに設定してもよいし、これらの両方に設定してもよい。

更新部１１４は、状態が”assigned”のときに、ジョブ更新要求として、ジョブ処理装置３０１から処理結果登録要求を受信したら、当該処理結果登録要求を実行する。

図９に処理結果登録要求の例を示す。”response”属性では、処理の実行状況（”status”）は、実行済み（あるいは実行開始されている）”done”であることを示している。”finished”属性は、完了属性であり、ジョブの処理が完了したか否かを表す。“true”は、ジョブの処理が完了したことを表す。”false”の場合は、まだ完了していないことを表す。例えばＤＶＤデータのダビングの場合に、ダビングが開始されたが、まだ完了していないことなどを表現できる。ダビングの全体の処理のどれくらいの割合まで完了したかを示す情報を、”response”属性に追加してもよい。図６の例では、”finished”属性が”true”の場合のみ、”executed”に状態が遷移する例が示されている。

なお、”finished”属性を設けない構成も可能である。この場合、ジョブの処理が開始されてはいるものの、ジョブの処理が完了していない場合は、”status”を”undone“とすればよい。この場合、更新部１１４は、ジョブの状態を”assigned”に維持してもよい。この際、何パーセントまで処理が完了したかの追加情報を”response”属性に追加してもよい。他の実現形態としては、処理結果登録要求の中のジョブ情報の”response”属性と同階層の属性として”status”属性を設け、これに”executed”を設定して、処理結果登録要求を送信した場合に、ジョブの処理が完了したとみなしてもよい（この場合、実行開始されている場合は”done”としてもよい）。何もつけない場合には、ジョブの状態を、”assigned”に維持するようにしてもよい。

更新部１１４は、処理結果登録要求の実行により、記憶部１１９のデータベースにおける該当するジョブを更新する。具体的に、図４Ｃに示すように、データベースにおける当該ジョブを更新する。

ジョブの状態が”executed”に変更されている。また、処理結果登録要求に含まれていた情報（”response”属性の”done”と、”finish”属性の”true”）が追加されている。また、ジョブの実行時刻（完了時刻）のタイムスタンプが追加されている。”finished”属性が”true”の場合、タイムスタンプ（“executedAt”属性）が入る。“false”の場合（処理が完了していない場合）は、タイムスタンプは入らなくてもよいし、開始時刻や完了予定時刻など、別の時刻が入ってよい。

また、例えば１０％、２０％など、一定の段階に達するごとに、ジョブ処理装置３０１が処理結果登録要求を送信して、現在の処理実行の過程をジョブに反映するようにしてもよい。この場合、”status”として、”done”と”undone”以外に処理の段階を表す値を設け、当該段階に応じた値を”実行状況”の列に設定してもよい。

実行時刻は、例えば更新部１１４が”finished”属性が”true”の処理結果登録要求を受け付けた時刻を用いてもよい。または、処理結果登録要求に当該時刻を含め、これを用いてもよい。

また、確認コード（confirmation code）が設定されている。この確認コードは、制御装置２０１がジョブの検収を行うために用いる。更新部１１４は、この確認コードを生成する。確認コードの生成方法は、一例として、ジョブに含まれる１つまたは複数の項目の値のハッシュ値を計算することなどがある。確認コードの発行後に、ジョブの一部に更新があった場合は、確認コードもその都度更新する。確認コードの具体例として、”response”属性の値（”done”等）のハッシュ値などを、用いてもよいし、前状態の確認コードと異なるように生成した単なる乱数であってもよい。確認コードは、制御装置２０１がジョブを検収する場合に、検収対象となったジョブが更新されていないことを確認するために用いられる。図４（Ｃ）例では、確認コードの値は、“xd1a3fap5i6f”である。

更新部１１４は、処理結果登録要求の実行後、ジョブを含む応答（処理結果登録応答）を、ジョブ処理装置３０１に送信する。処理結果登録応答の例を図１０に示す。図４（Ｃ）で更新された内容が追加されている。すなわち、処理結果登録要求に含まれていた情報（”response”属性の”done”と、”finish”属性の”true”）が追加されている。また、”executedAt”属性と、“confirmationCode”属性が追加されている。”executedAt”属性は、ジョブの実行時刻（完了時刻）のタイムスタンプを示す。“confirmationCode”属性は、確認コードを示す。確認コードの他の実現形態としては、提供部１１３がHTTPのレスポンスヘッダのETagに確認コードを設定して、制御装置２０１およびジョブ処理装置３０１に渡し、一方、制御装置２０１およびジョブ処理装置３０１は、HTTPのリクエストヘッダのIf-Matchに確認コードを設定して、更新部１１４、あるいは、削除部１１５に渡すようにしてもよい。

図１０のような処理結果登録応答がジョブ処理装置３０１に送信された後に、制御装置２０１からジョブ取得要求または一覧取得要求を受けた場合は、（フィルタ条件で除外されていない限り）確認コードが設定されたジョブを含む応答を送信する。この応答は、ジョブ取得応答、またはジョブ一覧取得応答である。

更新部１１４は、制御装置２０１から、ジョブ更新要求として、ジョブ処理結果検収要求（以下、検収要求）を受け付ける。更新部１１４は、検査に成功すると、制御部１１７を介して、データベースにおけるジョブの状態を“executed”から、検収済状態（”confirmed”）に更新する。また、検収時刻を設定する。このときのデータベースの状態を図４Ｄに示す。

図１１に、検収要求の例を示す。検収要求には、検収対象となるジョブの確認コードが含まれている。ＨＴＴＰの場合、この確認コードが、メッセージのボディ部ラインに設定される。あるいは確認コードが、リクエストラインにパラメータとして設定されてもよい。

更新部１１４は、検収要求に含まれる確認コードと、該当するジョブに含まれる確認コードが一致するかを検査する。一致する場合に、検査に成功したとして、制御部１１７を介して、当該ジョブの状態を、“executed”から、検収済状態（”confirmed”）に更新する。また、更新部１１４または制御部１１７は、検収時刻のタイムスタンプ（”confirmedAt”属性）を、ジョブに設定する（すなわちデータベースにおけるジョブを更新する）。制御部１１７は、ジョブの状態が”confirmed”に更新されたら、更新後のジョブを含む検収応答を制御装置２０１に送信するよう制御する。検収応答の例を図１２に示す。図１０の処理結果登録応答と比較すると、検収時刻のタイムスタンプ（”confirmedAt”属性）が新たに追加されている。なお、検査に失敗した場合は、更新部１１４はその旨のエラー応答を返す。

一方、制御装置２０１は、ジョブ配送装置１０１にジョブ取得要求等を送信して、ジョブを取得し、取得したジョブに含まれる確認コード（confirmationCode属性の値）を把握する。確認コードを含む検収要求を、ジョブ配送装置１０１に送信する。

更新部１１４は、上述したように、検収要求に含まれる確認コードが、検収対象のジョブに含まれる確認コードと一致するかを検査し、一致する場合、制御装置２０１にジョブを送信した後に、当該ジョブが更新されていない（すなわち検収は成功）と判断する。この場合、ジョブの状態を、“executed”から、検収済状態（”confirmed”）に更新する。

制御部１１７は、”confirmed”に遷移した一定時間後に、当該ジョブをデータベースから削除してもよい。この状態を”removed”と図６では表現している。ジョブをデータベースから完全にジョブを削除してもよいし、データベースに”removed”を登録することで削除を表現してもよい。”removed”のジョブは、その後、いつでも消去できる対象として扱ってもよい。”removed”を設定することで、削除されたジョブの履歴を残すことができる。データベースの領域が不足した場合は、”removed”のジョブを消去してもよい。”removed”のジョブは、制御装置２０１またはジョブ処理装置３０１からは認識できないものとする。つまり、ジョブ取得要求等を受けた場合も、”removed”のジョブは応答しない。

なお、更新部１１４は、ジョブ状態が”created”のときに、制御装置２０１から更新要求を受け付けることも可能である（図６参照）。例えば、実行期限を変更したい場合、ジョブ処理装置３０１に実行させる処理の内容を変更したい場合などは、その旨を指示した更新要求を制御装置２０１から送信する。更新部１１４は、当該更新要求に基づき、該当するジョブを更新する。

削除部１１５は、制御装置２０１から、ジョブIDを含むジョブ削除要求を受けて、該当ジョブをデータベースから削除する。HTTPプロトコルの場合、ジョブ削除要求のメッセージのリクエストラインは、例えばDELETE /v1/devices/:device_id/jobs/:job_idのように記述される。図６に示されるように、状態が”created”、”executed”、または、”confirmed”のときに、ジョブ削除要求を受け付け可能である。”executed”のときは、ジョブ削除要求を受け付け不可にしてもよい。なお、他の実現形態として、制御装置２０１からのジョブ取得要求、あるいは、（ジョブの”response”属性を応答に含む）ジョブ一覧取得要求の受信時に、提供部１１３が、”executed”状態のジョブを応答に含めると同時に（削除部１１５を介して）該当ジョブを削除するようにしてもよい。このとき、取得と同時に削除するか否かを、ジョブ取得要求のパラメータとして指定させるようにしてもよいし、ジョブ生成要求の時点で、”executed”状態のジョブの削除方式として指定させるようにしてもよいし、ジョブ配送装置１０１の動作属性として予め設定できるようにしてもよい。

管理部１１６は、生成部１１２によって生成されたジョブについて、当該ジョブに設定されている各種期限を管理する。制御部１１７は、図６に示されるように、状態が”created”、または”assgined”、のときに、実行期限が過ぎたことを、管理部１１６を介して検出すると、ジョブの状態を、”executionExpired”に遷移させる。

状態が”executionExpired”のとき、制御装置２０１またはジョブ処理装置３０１から、ジョブ取得命令を受け付けてもよい。このとき、提供部１１３は、管理部１１６を介して、制御装置２０１またはジョブ処理装置３０１に返す応答は、ジョブは無効であることを示す情報を含むものとする。これにより、ジョブ処理装置３０１が処理を実行することを防止できる。または実行期限を応答に含め、ジョブ処理装置３０１が、実行期限が過ぎていることを検出して、処理の実行を防いでもよい。この場合、期限が過ぎた実行期限を含む応答は、ジョブは無効であることを示す情報を含んでいるといえる。他の実現形態としては、”executionExpired”のときは、そもそもジョブ取得命令を受け付けない（例えば、HTTPの404 Not Found等を返す）ようにしてもよい。このとき、期限切れのジョブを応答しないようにするために、提供部１１３が、ジョブ取得要求を受け、該当ジョブを提供するときに、都度（管理部１１６を介して）実行期限および閲覧期限を確認するようにし、期限を過ぎていた場合には、該当ジョブの状態を”removed”に遷移させるようにしてもよい。

また、状態が”executionExpired”または”executed”のときに、閲覧期限が過ぎたことを管理部１１６が検知すると、管理部１１６は、制御部１１７を介して、当該ジョブの状態を”removed”に遷移させる。そして、管理部１１６または制御部１１７は、”removed”に遷移させたそのジョブを、記憶部１１９のデータベースから削除する。なお、”executionExipred”のときに、削除部１１５が、制御装置２０１から削除要求を受け付けた場合も、削除部１１５は、制御部１１７を介して、当該ジョブを記憶部１１９のデータベースから削除する（図６参照）。

ジョブを削除する方法として、前述したのと同様に、ジョブそのものをデータベースから完全に消去してもよいし、”removed”をデータベースに設定することで削除を表現してもよい。

上述したジョブの各状態の性質について簡単にまとめると以下のようになる。“created”は、主として制御装置２０１からジョブの更新または削除が可能な状態であるといえる。”assigned”は、主としてジョブ処理装置３０１が排他制御権を持った状態といえる。”executed”は、制御装置２０１のみが検収や削除のための排他制御権を持った状態といえる。”confirmed”は、制御装置２０１およびジョブ処理装置３０１双方からの処理結果の更新をブロックするとともに、制御装置２０１が最終結果を確認した状態といえる。

通知部１１８は、クライアント（制御装置２０１およびジョブ処理装置３０１）と通知用接続を設定し、ジョブの生成または更新等があった場合に、制御装置２０１またはジョブ処理装置３０１に自発的に通知を行う。具体的に、生成部１１２でジョブが生成された際に、ジョブの生成をジョブ処理装置３０１に通知する（例えばジョブ取得応答と同様の内容を含む）。ジョブ処理装置３０１の更新要求に応じて行ったジョブの更新を、制御装置２０１に通知する。あるいは、制御装置２０１の更新要求に応じて行ったジョブの更新を、ジョブ処理装置３０１に通知する。この通知は、ジョブ処理装置３０１または制御装置２０１からの取得要求を受けることなく、自発的に行う（プッシュ型の通知あるいは非同期の通知）。これにより、状態変化をタイムリーに通知することができる。なお、通知部１１８は必須ではなく、通知部１１８を備えない構成も可能である。この場合、これまで述べてきたような、要求を受けて、応答を返すシーケンスを実行すればよい。

接続の確立には、WebSocketまたはHTTP Cometなど、非同期通知を実現する通信プロトコルを利用すればよい。その他、MQTTなどのPub/Subプロトコルを用いてもよい。

このような非同期通知を実現する具体的な動作例として、通知部１１８は、通知用接続の確立要求をクライアント（制御装置２０１およびジョブ処理装置３０１）から受け付け、クライアントとの間にそれぞれ接続（コネクション）を確立する。通知部１１８が、クライアントから通知用接続の確立要求を直接受け付けて、コネクションを確立するようにしてもよい。

または、通知部１１８が、一旦、通知用接続の確立要求（HTTPリクエスト等）を受信して、接続先URLをクライアントに応答し、クライアントが、改めて当該URLに接続することで、コネクションを確立する方法もある。または、接続先URLをジョブ生成応答またはジョブ取得応答にマージする方法も可能である。ジョブ生成応答に接続先URLをマージした例を図１３に示す。”subscriptionUrl”属性の値として、接続先URLが含まれている。接続先URLをマージする場合、クライアントからの通知用接続の確立要求は不要である。

このように、通知部１１８は、WebSocketプロトコル等をベースにした、メッセージリレーサーバの機能を備える。また、通知部１１８は、接続先URLを出力するWeb APIサーバの機能も備えることもできる。

図１４に、本実施形態に係る具体的なシーケンスの例を示す。図１５は、図１４に続くシーケンスを示す。この例では、ジョブ処理装置３０１のみが、通知部１１８と通知用接続を確立する。なお説明のため、通知部１１８と、記憶部１１９をジョブ配送装置１０１は別のブロックとして表示している。

ジョブ処理装置３０１が、ジョブ配送装置１０１の通知部１１８と通知用接続（この例ではＷｅｂＳｏｃｋｅｔ接続）を確立する（Ｓ３０１ａ、Ｓ３０１ｂ）。制御装置２０１が、ジョブ一覧取得要求を送信する（Ｓ３０２）。ジョブ配送装置１０１が、ジョブ一覧取得要求で指定された条件（例えばジョブ処理装置３０１のユーザＩＤを有するジョブを指定）を満たすジョブを、記憶部１１９のデータベースから取得する（Ｓ３０３、Ｓ３０４）。ジョブ配送装置１０１は、取得したジョブを含むジョブ一覧取得応答（図７参照）を返す（Ｓ３０５）。制御装置２０１は、取得したジョブ一覧を画面に表示するなどして、依頼中の処理の内容をユーザに確認させる。

制御装置２０１は、ユーザの指示等に基づき、ジョブ生成要求（図２参照）を生成して、ジョブ配送装置１０１に送信する（Ｓ３０６）。ジョブ配送装置１０１は、ジョブ生成要求に基づきジョブを生成して、記憶部１１９のデータベースに登録する（Ｓ３０７、Ｓ３０８）。ジョブ配送装置１０１は、ジョブの状態を”created”に設定する。ジョブ配送装置１０１は、当該生成したジョブを含むジョブ生成応答を、制御装置２０１に送信する（Ｓ３０９）。

また、ジョブ配送装置１０１は、ジョブの生成をジョブ処理装置３０１に通知するため、通知指示を通知部１１８に出力し（Ｓ３１０）、通知部１１８は、事前に確率した通知用接続を利用して、ジョブの生成をジョブ処理装置３０１に通知する（Ｓ３１１）。この通知には、例えばジョブＩＤが含まれ、ジョブ処理装置３０１に実行させる処理の内容は含まれない。

ジョブ処理装置３０１は、ジョブ配送装置１０１から通知されたジョブＩＤを含むジョブ取得要求を送信する（Ｓ３１２）。ジョブ配送装置１０１は、該当するジョブを更新する（Ｓ３１３、Ｓ３１４）。この際、ジョブの状態を”assigned”に変更する。更新後のジョブを含むジョブ取得応答（図８参照）を、ジョブ処理装置３０１に送信する（Ｓ３１５）。ジョブ処理装置３０１は、ジョブを解析することで、自装置に要求された処理の内容を把握する。例えば、自装置の搭載機器がテレビであり、ジョブの内容が実行期限までにテレビの電源をオンにすることであれば、当該実行期限が過ぎる前に、テレビの電源をオンにする。実行時刻から一定時間前（例えば１分前）に電源をオンにしてもよい。

ジョブ処理装置３０１は、ジョブで要求された処理の実行を完了すると、ジョブ配送装置１０１に処理結果登録要求（図９参照）を送信する（Ｓ３１６）。ジョブ配送装置１０１は、処理結果登録要求に基づき、処理の実行が完了したと判断し、該当するジョブを更新する（Ｓ３１７、Ｓ３１８）。この際、ジョブの状態を、”executed”に更新する。ジョブ配送装置１０１は、更新後のジョブを含む処理結果登録応答（図１０参照）を、ジョブ処理装置３０１に送信する（Ｓ３１９）。ジョブ処理装置３０１は、処理結果登録応答を確認することで、処理の実行の完了が、ジョブ配送装置１０１で登録されたことを確認できる（例えば、処理結果登録応答に確認コードまたは実行時刻が存在することで、これを確認できる）。

制御装置２０１は、ジョブ生成要求で指定した処理の実行が完了したかを確認するため、該当するジョブのＩＤを含むジョブ取得要求を送信する（Ｓ３２０）。ジョブ配送装置１０１は、ジョブ取得要求で指定されたジョブを記憶部１１９から取得する（Ｓ３２１、Ｓ３２２）。ジョブ配送装置１０１は、取得したジョブの全部または一部の情報を含むジョブ取得応答を、制御装置２０１に送信する（Ｓ３２３）。

制御装置２０１は、ジョブ取得応答を受信し、それに基づき処理の実行が完了したことを確認する（例えば”confirmedAt”属性の値で、これを確認する）。制御装置２０１は、ジョブ取得応答に含まれる確認コードを読み出して、当該確認コードを含む検収要求（図１１参照）を送信する（Ｓ３２４）。ジョブ配送装置１０１は、検収要求に係るジョブを記憶部１１９から読み出し、読み出したジョブに含まれる確認コードと、検収要求に含まれる確認コードが一致するかを確認する（Ｓ３２５、Ｓ３２６）。一致する場合に、検収を完了し、検収応答（図１２参照）を制御装置２０１に送信する（Ｓ３２７）。制御装置２０１は、検収応答を受信し、検収が無事完了したことを確認する。その旨を画面に表示してもよい。

なお、制御装置２０１は、ステップＳ３２３のジョブ取得応答に基づき、処理がまだ完了していないことを把握した場合、一定時間または任意の時間が経過した後、再度ジョブ取得要求を送信してもよい。

上述したシーケンスでは、ジョブ配送装置１０１とジョブ処理装置３０１間に通知用接続を確立したが、当該通知用接続を確立しないパターンも可能である。この場合は、ステップＳ３１２のジョブ取得要求の送信前に、ジョブ処理装置３０１からジョブ一覧取得要求を送信するステップが入る。

また、上述したシーケンスでは、ステップＳ３１１の通知では、ジョブの情報の一部（ジョブＩＤ等）を通知したが、ジョブの情報の全部を送信するパターンも可能である。この場合、ステップＳ３１１の通知を行った時点で、ジョブの状態を”assigned”に遷移させる。この場合、ステップＳ３１２〜Ｓ３１５は不要である。なお、ジョブの情報の全部ではなく、特定の一部の情報（ジョブＩＤ、処理の内容、期限等）を送信した場合にも同様のシーケンスが可能である。

上述したシーケンスでは、ジョブ配送装置１０１と制御装置２０１間に通知用接続は確立しなかったが、当該通知用接続を確立するパターンも可能である。この場合、ステップＳ３１６で処理結果登録要求を受信して、ジョブの更新を行ったら、更新後のジョブを通知すればよい。この場合、ステップＳ３２０〜Ｓ３２３は不要である。あるいは、更新後のジョブを通知するのではなく、ジョブＩＤのみを通知してもよい。この場合、制御装置２０１は、このジョブＩＤの通知を確認した後で、ステップＳ３２０を実行すればよい。

本実施形態では、処理の完了後に検収を行ったが、検収を行わない構成も可能である。制御装置２０１から送信するジョブ生成要求に、検収を必要とするか否かの情報を含めてもよい。ジョブ配送装置１０１は当該情報に従って、検収の動作の有無を決定してもよい。また、本実施形態では、検収後にジョブを削除したが、ジョブを削除しない構成も可能である。例えば閲覧期限まではジョブを残しておくことや、削除要求を受けるまでジョブを残しておいてもよい。

尚、上述した実施形態のジョブ配送装置、制御装置およびジョブ処理装置は、例えば、汎用のコンピュータ装置を基本ハードウェアとして用いることでも実現可能である。すなわち、上記のコンピュータ装置に搭載されたプロセッサにプログラムを実行させることにより実現出来る。このとき、各装置は、上記のプログラムをコンピュータ装置にあらかじめインストールすることで実現することや、各種の記憶媒体に記憶、あるいはネットワークを介して上記のプログラムを配布、このプログラムをコンピュータ装置に適宜インストールすることで実現が出来る。また、ジョブ配送装置の各記憶部は、上記のコンピュータ装置に内蔵あるいは外付けされたメモリ、ハードディスクもしくはＣＤ−Ｒ、ＣＤ−ＲＷ、ＤＶＤ−ＲＡＭ、ＤＶＤ−Ｒなどの記憶媒体などを適宜利用して実現することができる。

上記に、本発明の一実施形態を説明したが、これらの実施形態は、例として提示したものであり、発明の範囲を限定することは意図していない。これら新規な実施形態は、その他の様々な形態で実施されることが可能であり、発明の要旨を逸脱しない範囲で、種々の省略、置き換え、変更を行うことができる。これら実施形態やその変形は、発明の範囲や要旨に含まれるとともに、特許請求の範囲に記載された発明とその均等の範囲に含まれる。

１０１：ジョブ配送装置（通信装置）
１１１：通信部
１１２：生成部
１１３：提供部
１１４：更新部
１１５：削除部
１１６：管理部
１１７：制御部
１１８：通知部
１１９：記憶部
２０１：制御装置
３０１：ジョブ処理装置（処理装置）
４０１：ネットワーク

Claims (12)

1. ネットワークを介して、制御装置および処理装置のそれぞれと通信可能な通信装置であって、
   前記制御装置から前記処理装置が実行する処理の内容を指定した第１要求を受信した場合に、前記処理装置に対し前記処理の実行を指示する情報と、前記処理に関連する第１期限とを含むジョブを生成する生成部と、
   前記ジョブの複数の状態間の遷移を制御する制御部と、を備え、
   前記制御部は、前記処理装置または前記制御装置から前記ジョブに対する第２要求を受信した場合に、前記第１期限と、前記ジョブの前記状態に基づいて、前記第２要求の実行を制御する
   を備えた通信装置。
2. 前記第１要求は、前記第１期限の要求値を含み、
   前記要求値が上限値以下または下限値以上の場合は、前記第１期限を前記要求値に設定し、前記上限値より大きいもしくは前記下限値より小さい場合は、前記上限値以下の値または前記下限値以上の値に前記第１期限を設定する
   請求項１に記載の通信装置。
3. 前記生成部は、前記第１要求で指定された前記処理の種別に基づき、前記第１期限を決定する
   請求項１または２に記載の通信装置。
4. 前記制御部は、
   前記ジョブが生成されたとき、前記ジョブを第１状態に設定し、
   前記ジョブが前記第１状態のときに前記処理装置から前記第２要求である取得要求が受信された場合に、前記ジョブを含む第１応答を送信するよう制御し、前記ジョブを第２状態に設定し、
   前記ジョブが前記第１状態のときに前記制御装置から前記第２要求である更新要求が受信された場合、前記ジョブまたは前記第１期限またはこれらの両方を更新するよう制御し、前記ジョブが前記第２状態のときに前記更新要求が受信された場合に、前記更新要求を拒否するように制御する
   請求項１ないし３のいずれか一項に記載の通信装置。
5. 前記制御部は、前記ジョブが前記第２状態のときに、前記第２要求として前記処理装置から前記処理の実行状況を示す処理結果登録要求を受信したとき、前記ジョブを第３状態に設定し、
   前記ジョブが前記第３状態のときに、前記制御装置から前記第２要求として第２取得要求を受信した場合、前記処理の実行状況を含む第２応答を返すよう制御し、
   前記ジョブが前記第３状態のときに、前記制御装置から前記第２要求として前記処理の検収要求を受信した場合、前記ジョブを前記第４状態に設定し、
   前記ジョブが前記第４状態のときに、前記処理装置から再度、前記処理結果登録要求が受信された場合、前記処理結果登録要求を拒否するように制御する
   請求項４に記載の通信装置。
6. 前記ジョブが前記第１状態または前記第４状態のときに、前記第２要求として前記ジョブの削除要求を受信したとき、前記ジョブを削除するよう制御し、
   前記ジョブが前記第２状態または第３状態のときに前記削除要求が受信された場合、前記削除要求を拒否するように制御する
   請求項５に記載の通信装置。
7. 管理部を備え、
   前記第１期限は、前記実行状況を表す情報を提供可能な期限であり、
   前記管理部は、前記第１期限を過ぎた前記ジョブを特定し、前記ジョブを削除する、
   請求項１ないし５のいずれか一項に記載の通信装置。
8. 前記第１期限は、前記処理の実行期限であり、
   前記制御部は、前記第１期限が過ぎたとき、前記ジョブを第５状態に設定し、
   前記制御部は、前記ジョブが前記第５状態のときに、前記処理装置または前記制御装置から前記第２要求として第３取得要求を受信した場合、前記ジョブが無効であることを示す情報を含む第３応答を返すように制御する
   請求項１ないし６のいずれか一項に記載の通信装置。
9. 前記処理装置と通知用の接続を確立し、前記接続を維持する通知部を備え、
   前記生成部は、前記ジョブを生成したとき、前記接続を介して、前記ジョブまたは前記ジョブを識別するＩＤを前記処理装置に送信する
   請求項１ないし８のいずれか一項に記載の通信装置。
10. 請求項１ないし９のいずれか一項に係る前記通信装置と
    前記制御装置と、
    前記処理装置と
    を備えた通信システム。
11. ネットワークを介して、制御装置および処理装置のそれぞれと通信可能なコンピュータが実行する通信方法であって、
    前記制御装置から前記処理装置が実行する処理の内容を指定した第１要求を受信した場合に、前記処理装置に対し前記処理の実行を指示する情報と、前記処理に関連する第１期限とを含むジョブを生成するステップと、
    前記ジョブの複数の状態間の遷移を制御するステップと、
    前記処理装置または前記制御装置から前記ジョブに対する第２要求を受信した場合に、前記第１期限と、前記ジョブの前記状態に基づいて、前記第２要求の実行を制御するステップと
    を備えた通信方法。
12. 制御装置から、処理装置が実行する処理の内容を指定した第１要求を受信した場合に、前記処理装置に対し前記処理の実行を指示する情報と、前記処理に関連する第１期限とを含むジョブを生成するステップと、
    前記ジョブの複数の状態間の遷移を制御するステップと、
    前記処理装置または前記制御装置から前記ジョブに対する第２要求を受信した場合に、前記第１期限と、前記ジョブの前記状態に基づいて、前記第２要求の実行を制御するステップと
    をコンピュータに実行させるためのプログラム。

Images