JP2019082953A

JP2019082953A - 通信装置、通信方法、及びプログラム

Info

Publication number: JP2019082953A
Application number: JP2017211154A
Authority: JP
Inventors: 健介安間; Kensuke Yasuma; 和矢谷口; Kazuya Taniguchi
Original assignee: Canon Inc
Current assignee: Canon Inc
Priority date: 2017-10-31
Filing date: 2017-10-31
Publication date: 2019-05-30
Anticipated expiration: 2037-10-31
Also published as: JP6942609B2

Abstract

【課題】サーバ装置から通信装置を介して複数のクライアント装置へデータを送信する場合に、送信先のクライアント装置へデータが送達されたことを通信装置がサーバ装置へ適切に通知できるようにする。【解決手段】サーバ装置１０４は、クライアント装置１０２及びクライアント装置１０３へ転送されるべきデータを中継装置１０１へ送信する。中継装置１０１は、サーバ装置１０４から受信したデータをクライアント装置１０２及びクライアント装置１０３へ転送する。そして中継装置１０１は、転送されたデータの受信が完了したことを示す確認応答をクライアント装置１０２とクライアント装置１０３の両方から受信した後に、データの送達確認の通知をサーバ装置１０４に送信する。【選択図】図３

Description

本発明は、サーバ装置から通信装置を介してクライアント装置へデータを送信する技術に関する。

近年、サーバ装置からクライアント装置へプッシュ型のデータ送信を行うプッシュサービスが考えられている。プッシュサービスにおいては、クライアント装置からサーバ装置へのリクエストのタイミングによらずに、サーバ装置からクライアント装置へイベントの発生などを通知するためのデータが送信される。ＩＥＴＦ（ＩｎｔｅｒｎｅｔＥｎｇｉｎｅｅｒｉｎｇＴａｓｋＦｏｒｃｅ）においては、Ｗｅｂ技術を用いたプッシュサービスの実現の方式としてＷｅｂＰｕｓｈプロトコルが提案されている。

ＷｅｂＰｕｓｈプロトコルに従う通信においては、サーバ装置（ＡＳ：ＡｐｐｌｉｃａｔｉｏｎＳｅｒｖｅｒ）から送信されたデータを通信装置（ＰＳ：ＰｕｓｈＳｅｒｖｉｃｅ）がクライアント装置（ＵＡ：ＵｓｅｒＡｇｅｎｔ）へ転送する。これにより、ＡＳからＵＡへのプッシュ型のデータ送信が実現される。また、ＰＳからＵＡへデータが送達された際に、ＰＳは送達の確認を通知するメッセージ（レシート）をＡＳへ送信する。

一方、特許文献１には、サーバ装置が複数のクライアント装置に接続され、各クライアント装置にデータをプッシュすることが開示されている。

特開２０１２−８３９２４号公報

従来技術では、サーバ装置から通信装置を介して複数のクライアント装置へデータが送信される場合に、送信先のクライアント装置へデータが送達されたことを通信装置がサーバ装置へ適切に通知する方法が考えられていなかった。例えば、ＷｅｂＰｕｓｈプロトコルに従う通信において、ＡＳからＰＳを介して複数のＵＡにデータを送信する場合を考える。この場合に、データが何れかのＵＡへ最初に送達された際にのみＰＳからＡＳへレシートが送信されると、ＡＳはすべてのＵＡへデータが送達されたかを判断するのが困難である。

本発明は上記課題に鑑み、サーバ装置から通信装置を介して複数のクライアント装置へデータを送信する場合に、送信先のクライアント装置へデータが送達されたことを通信装置がサーバ装置へ適切に通知できるようにすることを目的とする。

上記の課題を解決するため、本発明に係る通信装置は、例えば以下の構成を有する。すなわち、サーバ装置からデータを受信する第１受信手段と、前記第１受信手段により受信される前記データをクライアント装置へ送信する第１送信手段と、前記第１送信手段により送信された前記データがクライアント装置により受信されたことを示す確認応答を当該クライアント装置から受信する第２受信手段と、前記第１送信手段により前記データが複数のクライアント装置へ送信される場合に、前記第２受信手段が前記複数のクライアント装置から前記確認応答を受信した後に、前記データの送達確認の通知を前記サーバ装置に送信する第２送信手段とを有する。

本発明によれば、サーバ装置から通信装置を介して複数のクライアント装置へデータを送信する場合に、送信先のクライアント装置へデータが送達されたことを通信装置がサーバ装置へ適切に通知できるようになる。

通信システム１００の構成例を示す図である。中継装置１０１のハードウェア構成例を示す図である。通信システム１００の動作シーケンスの例を示す図である。中継装置１０１による識別子の生成に関する動作について説明するためのフローチャートである。中継装置１０１による転送要求の受信に関する動作について説明するためのフローチャートである。中継装置１０１によるプッシュメッセージとレシートの送信に関する動作について説明するためのフローチャートである。クライアント装置１０２による識別子の受信と送信に関する動作について説明するためのフローチャートである。クライアント装置１０３による識別子の取得に関する動作について説明するためのフローチャートである。クライアント装置１０２によるプッシュメッセージの受信に関する動作について説明するためのフローチャートである。サーバ装置１０４によるメッセージの送信に関する動作について説明するためのフローチャートである。中継装置１０１によるレシート送信のための前処理に関する動作について説明するためのフローチャートである。中継装置１０１により管理されるリストの例を示す図である。

［実施例１］
［システム構成］
以下、本発明の実施形態について、図面を参照して説明する。図１は、本実施形態に係る通信システム１００の構成を示す図である。本実施形態の通信システム１００は、中継装置１０１、クライアント装置１０２、クライアント装置１０３、及びサーバ装置１０４を有する。クライアント装置１０２及びクライアント装置１０３は中継装置１０１を介してサーバ装置１０４と有線または無線で接続され、相互に通信を行って、例えば静止画や動画等のコンテンツデータやイベント通知コマンドなどを送受信する。なお、図１に示す通信システム１００内には２台のクライアント装置が存在するが、中継装置１０１に接続されるクライアント装置の数はこれに限らず、３台以上であってもよい。また、中継装置１０１に接続されるサーバ装置１０４も、２台以上であってもよい。

本実施形態において、クライアント装置１０２とクライアント装置１０３はＨＴＴＰ／２（ＨｙｐｅｒｔｅｘｔＴｒａｎｓｆｅｒＰｒｏｔｏｃｏｌｖｅｒｓｉｏｎ２）において規定されるクライアントとして動作する。一方、中継装置１０１はＨＴＴＰ／２において規定されるサーバとして動作する。即ち、クライアント装置１０２及びクライアント装置１０３は中継装置１０１にＨＴＴＰリクエストを送信し、中継装置１０１は受信したＨＴＴＰリクエストに応じてクライアント装置１０２及びクライアント装置１０３にＨＴＴＰレスポンスを送信する。

サーバ装置１０４は、クライアント装置１０２及びクライアント装置１０３に対して、中継装置１０１を介してデータを送信することによりプッシュサービスを提供する。プッシュサービスの実現のために、中継装置１０１からクライアント装置１０２及びクライアント装置１０３へのデータの転送には、例えばＨＴＴＰ／２の機能としてのサーバープッシュなどプッシュ型のデータ送信方法が用いられる。なお、サーバ装置１０４は中継装置１０１との通信においては、ＨＴＴＰ／１．１（ＨｙｐｅｒｔｅｘｔＴｒａｎｓｆｅｒＰｒｏｔｏｃｏｌｖｅｒｓｉｏｎ１．１）において規定されるクライアントとして動作する。そして中継装置１０１は、サーバ装置１０４との通信においてＨＴＴＰ／１．１において規定されるサーバとして動作する。具体的には、サーバ装置１０４は中継装置１０１にＰＯＳＴメソッドなどのリクエストを送信し、プッシュによる送信の対象となるデータを中継装置１０１にアップロードする。

中継装置１０１は具体的には、ＰＣ、ネットワークスイッチ、及びルータなどの通信装置である。クライアント装置１０２及びクライアント装置１０３は具体的には、デジタルカメラ、ネットワークカメラ、プリンタ、複合機、テレビ、プロジェクタ、携帯電話、スマートフォン、及びＰＣなどのクライアント装置である。また、サーバ装置１０４の具体例も、クライアント装置１０２及びクライアント装置１０３と同様である。ただし、通信システム１００内の各装置の形態はこれらに限定されない。

クライアント装置１０２、クライアント装置１０３、及びサーバ装置１０４と中継装置１０１とは、例えばＬＡＮ（ＬｏｃａｌＡｒｅａＮｅｔｗｏｒｋ）やＷＡＮ（ＷｉｄｅＡｒｅａＮｅｔｗｏｒｋ）、又はそれらの組み合わせにより接続される。ＬＡＮとしては、Ｅｔｈｅｒｎｅｔ（登録商標）に則った有線ＬＡＮや、ＩＥＥＥ（ＩｎｓｔｉｔｕｔｅｏｆＥｌｅｃｔｒｉｃａｌａｎｄＥｌｅｃｔｒｏｎｉｃｓＥｎｇｉｎｅｅｒｓ）８０２．１１シリーズに則った無線ＬＡＮなどが用いられる。ＷＡＮとしては、例えばインターネットなどが用いられる。また、Ｂｌｕｅｔｏｏｔｈ（登録商標）やＺｉｇｂｅｅ（登録商標）など他の通信方式に基づいて接続されてもよい。

クライアント装置１０２とクライアント装置１０３との間、及びクライアント装置１０２とサーバ装置１０４との間でもデータのやり取りが行われる。本実施形態ではこのデータのやり取りがＬＡＮやＷＡＮを介した通信により行われる場合を中心に説明するが、データのやり取りの方法はこれに限らない。例えば、一方の装置に表示させた画像やＱＲコード（登録商標）を他方の装置により読み取ることでデータをやり取りしてもよいし、一方の装置に表示された情報をユーザが他方の装置に入力してもよい。また、クライアント装置１０２やサーバ装置１０４などが不図示の情報管理装置に対するデータの登録、削除、及び更新などを行うことにより、情報管理装置を介したデータのやり取りが行われてもよい。情報管理装置は、例えば、クラウド上やサーバ上で管理されるソフトウェアであってもよい。情報管理装置を介したデータのやり取りが行われる場合には、情報管理装置にアクセスするための識別子や鍵情報がクライアント装置１０２とサーバ装置１０４との間でやり取りされてもよい。

本実施形態において、中継装置１０１はＷｅｂＰｕｓｈプロトコルにおいて規定されるＰＳ（ＰｕｓｈＳｅｒｖｉｃｅ）の機能を持つ。また、クライアント装置１０２とクライアント装置１０３はＷｅｂＰｕｓｈプロトコルにおいて規定されるＵＡ（ＵｓｅｒＡｇｅｎｔ）の機能を持つ。そして、サーバ装置１０４はＷｅｂＰｕｓｈプロトコルにおいて規定されるＡＳ（ＡｐｐｌｉｃａｔｉｏｎＳｅｒｖｉｃｅ）の機能を持つ。

通信システム１００の基本的な動作としては、以下のようになる。すなわち、クライアント装置１０２及びクライアント装置１０３が中継装置１０１にデータの転送要求を行い、サーバ装置１０４が中継装置１０１へプッシュによる送信の対象となるデータを送信する。そして中継装置１０１が、サーバ装置１０４からのデータの受信に応じたタイミングで、転送要求を行った中継装置へ当該データを転送する。また中継装置１０１は、転送したデータを受信したことを示す確認応答をクライアント装置１０２及びクライアント装置１０３から受け取ると、送達確認の通知をサーバ装置１０４に送信する。本実施形態において、送達確認の通知はＷｅｂＰｕｓｈプロトコルにおいて規定されるプッシュメッセージレシート（以降、レシート）として送信されるものとする。ただし通知の形式はこれに限定されず、データが正しくクライアント装置に送達されたことをサーバ装置１０４が知ることができる方法で通知が行われればよい。各装置の詳細な動作については後述する。

通信システム１００の具体的な例としては、以下のようなものがある。クライアント装置１０２はスマートフォンであり、サーバ装置１０４はネットワークカメラである。クライアント装置１０２は中継装置１０１に転送要求を行い、サーバ装置１０４からの撮影画像の送信を待ち受ける。サーバ装置１０４は、カメラにより監視エリアを撮影し、監視エリアにおける異常を検知した場合に撮影画像を中継装置１０１に送信する。そして中継装置１０１は、サーバ装置１０４から送信された撮影画像をクライアント装置１０２に転送する。これにより、クライアント装置１０２のユーザは、監視エリアにおいて検知された異常を知り、監視エリアの撮影画像を確認することができる。

ここで、中継装置１０１からのデータの転送先がクライアント装置１０２だけである場合、中継装置１０１はクライアント装置１０２から確認応答を受け取った際にサーバ装置１０４にレシートを送信すればよい。一方、中継装置１０１からのデータの転送先がクライアント装置１０２とクライアント装置１０３のように複数である場合も考えられる。この場合には、中継装置１０１が最初に確認応答を受け取った際にのみサーバ装置１０４にレシートを送信すると、すべての転送先にデータが送達されたか否かをサーバ装置１０４が判断するのは困難である。そこで、本実施形態においては、中継装置１０１が複数の転送先から確認応答を受け取った後でサーバ装置１０４に送達確認の通知を送信することで、当該複数の転送先へデータが送達されたことをサーバ装置１０４が判断できるようにする。

また、中継装置１０１が複数のクライアント装置のそれぞれから確認応答を受信するたびにサーバ装置１０４に同様のレシートを送信することも考えられる。ただしこの場合にも、中継装置１０１が管理している転送先のクライアント装置の数をサーバ装置１０４が把握していないと、すべての転送先へデータが送達されたかをサーバ装置１０４が判断するのは困難である。そこで、本実施形態で説明するように、中継装置１０１が複数の転送先から確認応答を受信した後に特定の送達確認の通知をサーバ装置１０４に送信することで、当該複数の転送先へデータが送達されたかをサーバ装置１０４が判断することを容易にできる。

そしてサーバ装置１０４は、中継装置１０１から送達確認の通知を受信すると、例えばクライアント装置１０２及びクライアント装置１０３へ送信すべき次のデータを中継装置１０１へ送信する。一方、中継装置１０１から所定期間内に送達確認の通知を受信しなかった場合や、中継装置１０１からエラーレスポンスを受信した場合には、データの再送などのエラー処理を行う。また、データの送達に失敗した原因がエラーレスポンスと共に中継装置１０１からサーバ装置１０４へ通知されるような場合には、サーバ装置１０４は、通知された失敗の原因が解消されるように送信データの種別やサイズなどを制御してもよい。

［装置構成］
図２は、中継装置１０１のハードウェア構成を示すブロック図である。なお、クライアント装置１０２、クライアント装置１０３、及びサーバ装置１０４も、中継装置１０１と同様の構成である。中継装置１０１は、ＣＰＵ２０１、ＲＯＭ２０２、ＲＡＭ２０３、補助記憶装置２０４、表示部２０５、操作部２０６、通信部２０７、及びバス２０８を有する。

ＣＰＵ２０１は、ＲＯＭ２０２やＲＡＭ２０３に格納されているコンピュータプログラムやデータを用いて中継装置１０１の全体を制御する。ＲＯＭ２０２は、変更を必要としないプログラムやパラメータを格納する。ＲＡＭ２０３は、補助記憶装置２０４から供給されるプログラムやデータ、及び通信部２０７を介して外部から供給されるデータなどを一時記憶する。補助記憶装置２０４は、例えばハードディスクドライブ等で構成され、静止画や動画などのコンテンツデータを記憶する。

表示部２０５は、例えば液晶ディスプレイやＬＥＤ等で構成され、ユーザが中継装置１０１を操作するためのＧＵＩ（ＧｒａｐｈｉｃａｌＵｓｅｒＩｎｔｅｒｆａｃｅ）やエラー情報などを表示する。操作部２０６は、例えばキーボードやマウス、タッチパネル等で構成され、ユーザによる操作を受けて各種の指示をＣＰＵ２０１に入力する。通信部２０７は、クライアント装置１０２やクライアント装置１０３、サーバ装置１０４などの外部の装置と通信を行う。中継装置１０１が外部の装置と有線で接続される場合には、例えばＬＡＮケーブル等が通信部２０７に接続される。また、中継装置１０１が外部の装置と無線通信する機能を有する場合、通信部２０７はアンテナ等を備える。バス２０８は、中継装置１０１の各部を繋いで情報を伝達する。

なお、本実施形態ではＣＰＵ２０１がプログラムを実行することで通信部２０７を介した中継装置１０１と外部の装置との通信を制御するが、中継装置１０１と外部の装置との通信の少なくとも一部を通信部２０７がハードウェア処理により制御してもよい。また、本実施形態では表示部２０５と操作部２０６は中継装置１０１の内部に存在するが、表示部２０５及び操作部２０６の少なくとも一方が中継装置１０１の外部に別の装置として存在していてもよい。この場合、ＣＰＵ２０１が、表示部２０５を制御する表示制御部、及び操作部２０６を制御する操作制御部として動作する。

［通信シーケンス］
以下、本実施形態における通信システム１００内における通信のシーケンスについて、詳細に説明する。図３は、サーバ装置１０４が中継装置１０１を介してクライアント装置１０２及びクライアント装置１０３にデータをプッシュにより送信する際のシーケンスである。図３に示すシーケンスは、クライアント装置１０２、クライアント装置１０３、及びサーバ装置１０４のそれぞれと中継装置１０１との間の接続が確立されたタイミングで開始される。ただし、図３の処理の開始タイミングは上記タイミングに限定されない。図３に示す各通信処理は、通信システム１００内の各装置のＣＰＵ２０１が通信部２０７などを制御することで実行される。

Ｍ１３０１において、クライアント装置１０２は中継装置１０１にサブスクライブ（識別子の情報要求）を行う。中継装置１０１はクライアント装置１０２からのサブスクライブを受け付け、ＷｅｂＰｕｓｈプロトコルにおいて規定されるプッシュＵＲＩとそれに対応するプッシュメッセージサブスクリプションＵＲＩ（以降、サブスクリプションＵＲＩ）を生成する。生成されたプッシュＵＲＩとサブスクリプションＵＲＩは、図１２（ａ）に示す識別子リストのような形式で中継装置１０１のＲＡＭ２０３に保存される。

プッシュＵＲＩ及びサブスクリプションＵＲＩは、中継装置１０１がサーバ装置１０４から送信されるデータの転送先を特定するために用いる識別子であり、要求に応じて中継装置１０１により生成（発行）される発行情報である。なお、これらの識別子はサブスクライブに応じて生成されるものに限らず、予め中継装置１０１が保持していた識別子の中からサブスクライブに応じて決定されたものであってもよい。本実施形態では識別子をＵＲＩ（ＵｎｉｆｏｒｍＲｅｓｏｕｒｃｅＩｄｅｎｔｉｆｅｒ）としているが、ＵＵＩＤ（ＵｎｉｖｅｒｓａｌｌｙＵｎｉｑｕｅＩｄｅｔｉｆｅｒ）のような他の形態の識別子であってもよい。また、本実施形態ではプッシュＵＲＩとサブスクリプションＵＲＩという２種類の情報が用いられる場合を中心に説明するが、これに限らず、１種類の情報を用いて転送対象のデータや転送先が特定されてもよい。すなわち、以下の説明におけるプッシュＵＲＩとサブスクリプションＵＲＩとが同一の情報であってもよい。

本実施形態では、サブスクライブがＨＴＴＰ／１．１のＰＯＳＴメソッドを用いて行われるものとするが、例えばＧＥＴメソッドの様な別メソッドが用いられてもよいし、ＦＴＰやＷｅｂｓｏｃｋｅｔなどの他通信規格に従う通信が用いられても良い。また本実施形態では、プッシュＵＲＩとサブスクリプションＵＲＩという２つの識別子がクライアント装置１０２からのサブスクライブに応じて中継装置１０１により生成される場合について説明するが、これに限らない。例えば、プッシュＵＲＩのみが生成されてもよいし、プッシュＵＲＩとサブスクリプションＵＲＩに加えてＷｅｂｐｕｓｈプロトコルにおいて規定されるプッシュメッセージサブスクリプション・セットＵＲＩが生成されてもよい。

Ｍ１３０２において、中継装置１０１は、Ｍ１３０１におけるクライアント装置１０２からの要求に応じて、Ｍ１３０１で生成されたプッシュＵＲＩとサブスクリプションＵＲＩを含むレスポンスを送信する。クライアント装置１０２はレスポンスを受信し、受信したレスポンスに含まれるプッシュＵＲＩとサブスクリプションＵＲＩをＲＡＭ２０３などに保存する。本実施形態ではこのレスポンスにおけるステータスコードを２０１Ｃｒｅａｔｅｄとしているが、これに限らなくてもよい。

Ｍ１３０３において、クライアント装置１０２はクライアント装置１０３に、Ｍ１３０２で受信したプッシュＵＲＩとサブスクリプションＵＲＩを送信する。クライアント装置１０３はプッシュＵＲＩとサブスクリプションＵＲＩを受信し、プッシュＵＲＩとサブスクリプションＵＲＩをＲＡＭ２０３などに保存する。

Ｍ１３０４において、クライアント装置１０２はサーバ装置１０４にプッシュＵＲＩを送信する。サーバ装置１０４はプッシュＵＲＩを受信し、プッシュＵＲＩをＲＡＭ２０３などに保存する。なお、図３の例ではＨＴＴＰ／１．１に従う通信を用いてクライアント装置１０２からサーバ装置１０４へのプッシュＵＲＩの受け渡しを行っているが、すでに説明した通り、データの受け渡しの方法はこれに限定されない。例えば、サーバ装置１０４はプッシュＵＲＩを他の通信プロトコルを用いて受信してもよいし、クライアント装置１０２の表示部２０５に表示された画像やＱＲコードを用いて受信してもよいし、情報管理装置を介して受信してもよい。また、ユーザがサーバ装置１０４の操作部２０６を操作してプッシュＵＲＩを入力してもよい。なお、Ｍ１３０３におけるデータの受け渡しについても同様である。

Ｍ１３０５において、クライアント装置１０２は中継装置１０１に、Ｍ１３０２で中継装置１０１から受信したサブスクリプションＵＲＩを含む転送要求を送信する。この転送要求の送信により、クライアント装置１０２は、中継装置１０１によるプッシュ型のデータ送信を要求する。中継装置１０１は転送要求を受信し、受信した転送要求に含まれるサブスクリプションＵＲＩがＲＡＭ２０３内の識別子リストに保存済みのサブスクリプションＵＲＩと合致することを確認する。そして中継装置１０１は、そのサブスクリプションＵＲＩに対応するプッシュＵＲＩと、転送要求の送信元であるクライアント装置１０２のデバイス情報とを、図１２（ｂ）に示すプッシュ配信リストのような形式でＲＡＭ２０３に保存する。Ｍ１３０６において、クライアント装置１０３は中継装置１０１に、Ｍ１３０３でクライアント装置１０２から受信したサブスクリプションＵＲＩを含む転送要求を送信する。中継装置１０１はＭ１３０５の処理と同様に、転送要求を受信し、プッシュＵＲＩとデバイス情報をプッシュ配信リストに保存する。

すなわち、Ｍ１３０５及びＭ１３０６において中継装置１０１は、同一のサブスクリプションＵＲＩを含む２つの転送要求を、クライアント装置１０２とクライアント装置１０３の２つの装置から受信する。そして、中継装置１０１が保持するプッシュ配信リストにおいては、図１２（ｂ）に示すように、同一のプッシュＵＲＩに複数のデバイス情報が対応付けられる。

Ｍ１３０７において、サーバ装置１０４は中継装置１０１に対して、以降にサーバ装置１０４から送信されるデータ（例えばＭ１３１１において送信される配信メッセージ）に対応する送達確認の通知を行うことを要求する。Ｍ１３０８において、中継装置１０１は、Ｍ１３０７において受け付けた通知要求に応じてレシートサブスクリプションＵＲＩとプッシュメッセージＵＲＩを生成する。そして中継装置１０１は、通知要求に対するレスポンスとして、生成したレシートサブスクリプションＵＲＩとプッシュメッセージＵＲＩを、ＨＴＴＰのステータスコード（例えば２００Ａｃｃｅｐｔｅｄ）と共にサーバ装置１０４へ送信する。ただし、通知要求に対するレスポンスとして中継装置１０１からサーバ装置１０４へ送信される情報はこれらに限らず、プッシュメッセージＵＲＩのみが送信されてもよいし、別の識別子が送信されてもよい。なお、中継装置１０１は、送達確認の通知を行うことを拒否する場合には、別のステータスコード（例えば４００や４０４など）を送信する。

Ｍ１３０９において、サーバ装置１０４は、レシートをプッシュ型のデータ送信により中継装置１０１から受け取るためのレシート要求を行う。このレシート要求は、例えばＨＴＴＰのＧＥＴメソッドによりサーバ装置１０４から中継装置１０１へ送信され、レシートにより送達を確認する対象となるデータに対応するプッシュＵＲＩがレシート要求に含まれる。また、サーバ装置１０４から送信されるレシート要求には、Ｍ１３０８において中継装置１０１から取得したレシートサブスクリプションＵＲＩと、プッシュポリシーとが含まれる。プッシュポリシーは、中継装置１０１がサーバ装置１０４から受信したデータの転送先とすべきクライアント装置の数などを指定するための指定情報である。プッシュポリシーは例えばレシート要求のＨＴＴＰヘッダのフィールドにＰＵＳＨ−ＭＯＤＥ：ａｌｌといった形で記載されていてもよいし、ボディ部分に記載されていてもよい。ここで、ＰＵＳＨ−ＭＯＤＥはプッシュの方式を示すための拡張ＨＴＴＰヘッダであり、ａｌｌはサブスクライブしている全てのクライアント装置にデータをプッシュすることを示している。

中継装置１０１はサーバ装置１０４からレシート要求を受信すると、図１２（ｃ）に示すようなプッシュポリシーリストを生成する。レシート要求に含まれるプッシュＵＲＩをキーとして、レシート要求の送信元であるサーバ装置１０４のデバイス情報、レシート要求に含まれるレシートサブスクリプションＵＲＩ、及びプッシュポリシーが同一エントリとして対応付けられてリストに保存される。また、Ｍ１３０８において当該レシートサブスクリプションＵＲＩと共に生成されたプッシュメッセージＵＲＩも同一エントリに保存される。プッシュポリシーの詳細については後縦する。

Ｍ１３１０において、中継装置１０１はサーバ装置１０４に、Ｍ１３０９において受信したレシート要求に含まれるレシートサブスクリプションＵＲＩに対応するプッシュＵＲＩを含むプッシュ予約を送信する。プッシュ予約の送信により、後にレシートがサーバ装置１０４へプッシュされることが通知される。図３の例では、ストリーム番号が８２のストリームを用いてレシートをプッシュすることを予約するためのＰＵＳＨ＿ＰＲＯＭＩＳＥフレームが、ストリーム番号が１３のストリームを用いて送信される。ストリームやＰＵＳＨ＿ＰＲＯＭＩＳＥフレームは、ＨＴＴＰ／２に従う通信において使用されることが標準規格で規定されている。

Ｍ１３１１において、サーバ装置１０４は中継装置１０１に、Ｍ１３０４でクライアント装置１０２から受信したプッシュＵＲＩを含む配信メッセージを送信する。中継装置１０１はサーバ装置１０４からプッシュＵＲＩを含む配信メッセージを受信し、受信した配信メッセージに含まれるプッシュＵＲＩがＲＡＭ２０３内の識別子リストに保存済みのプッシュＵＲＩと合致することを確認する。合致する場合の当該配信メッセージは、当該プッシュＵＲＩと対応するサブスクリプションＵＲＩを含む転送要求の送信元であるクライアント装置へ転送すべきデータである。Ｍ１３１２において、中継装置１０１はサーバ装置１０４に、プッシュのリクエストを受け付けたことを示す配信レスポンスを送信し、サーバ装置１０４は配信レスポンスを受信する。

Ｍ１３１３において、中継装置１０１は、ＲＡＭ２０３に保存されているプッシュ配信リストから、Ｍ１３１１で受信した配信メッセージに含まれるプッシュＵＲＩに対応するデバイス情報を検索する。そして中継装置１０１は、該当したデバイス情報から特定されるクライアント装置１０２に、そのプッシュＵＲＩを含むプッシュ予約を送信する。プッシュ予約の送信により、後にメッセージがプッシュ通知により送信されることが送信先に通知される。クライアント装置１０２はプッシュ予約を受信し、中継装置１０１からプッシュメッセージを受信するまで待機する。

Ｍ１３１４において、中継装置１０１はクライアント装置１０２にプッシュメッセージを送信する。クライアント装置１０２はプッシュメッセージを受信する。このプッシュメッセージは、Ｍ１３０５における転送要求に応じて中継装置１０１からクライアント装置１０２へプッシュにより送信されるメッセージである。すなわち、クライアント装置１０２からのリクエストに依存しないタイミングで中継装置１０１からプッシュメッセージが送信される。ただし、Ｍ１３１４におけるプッシュ型のデータ送信の代わりに、中継装置１０１はクライアント装置１０２からのリクエストを待ってメッセージを送信してもよい。

ここで中継装置１０１から送信されるプッシュメッセージは、Ｓ１３１１においてサーバ装置１０４から送信された配信メッセージに応じた情報である。またこのプッシュメッセージは、配信メッセージに含まれるプッシュＵＲＩに対応するサブスクリプションＵＲＩを含むＭ１３０５における転送要求に応じて中継装置１０１により転送される情報でもある。なお、配信メッセージとプッシュメッセージは同一のデータを含んでいてもよいし、異なるデータを含んでいてもよい。Ｍ１３１５において、クライアント装置１０２は中継装置１０１に、プッシュメッセージを受信したことを示す確認応答としてのプッシュレスポンスを送信する。中継装置１０１はプッシュレスポンスを受信する。

Ｍ１３１６において、中継装置１０１はサーバ装置１０４に、Ｍ１３１０において予約されたストリームを用いてステータスコードが１００ＣＯＮＴＩＮＵＥのレシートをプッシュ型のデータ送信により送信する。ここで送信されるステータスコードが１００ＣＯＮＴＩＮＵＥのレシートは、プッシュメッセージが転送先であるクライアント装置１０２及びクライアント装置１０３のうちの一方にのみ送達されたことを示す暫定応答である。ここで送信されるレシートには、プッシュメッセージが送達されたクライアント装置１０２を特定するための情報などが含まれてもよい。これにより、サーバ装置１０４はどのクライアント装置へデータが送達されたかを把握することができる。

Ｍ１３１７において、中継装置１０１はＭ１３１３と同様に、Ｍ１３１１で受信した配信メッセージに含まれるプッシュＵＲＩに対応するデバイス情報から特定されるクライアント装置１０３に、そのプッシュＵＲＩを含むプッシュ予約を送信する。クライアント装置１０３はプッシュ予約を受信し、中継装置１０１からプッシュメッセージを受信するまで待機する。

Ｍ１３１８において、中継装置１０１はクライアント装置１０３にプッシュメッセージを送信し、クライアント装置１０３はプッシュメッセージを受信する。ここで送信されるプッシュメッセージは、Ｓ１３１１においてサーバ装置１０４から送信された配信メッセージに応じた情報である。なお、Ｓ１３１８において送信されるプッシュメッセージとＭ１３１４において送信されるプッシュメッセージは同一であってもよいし、送信先に応じて異なるデータを含んでいてもよい。Ｍ１３１９において、クライアント装置１０３は中継装置１０１に確認応答としてのプッシュレスポンスを送信し、中継装置１０１はプッシュレスポンスを受信する。

Ｍ１３２０において、中継装置１０１はサーバ装置１０４に、Ｍ１３１０において予約されたストリームを用いてステータスコードが２０４ＮｏＣｏｎｔｅｎｔのレシートをプッシュ型のデータ送信により送信する。ここで送信されるステータスコードが２０４ＮｏＣｏｎｔｅｎｔのレシートは、プッシュメッセージが転送先であるクライアント装置１０２及びクライアント装置１０３の両方に送達されたことを示す送達確認通知である。ここで送信されるレシートには、プッシュメッセージが送達されたすべての転送先（クライアント装置１０２及びクライアント装置１０３）を特定するための情報などが含まれてもよい。これにより、サーバ装置１０４は最終的にどのクライアント装置へデータが送達されたかを把握することができる。

以上で通信システム１００における一連の通信が終了する。図３を用いて説明したシーケンスの要点をまとめると、以下のようになる。サーバ装置１０４は、クライアント装置１０２及びクライアント装置１０３へ転送されるべきデータを中継装置１０１へ送信する（Ｍ１３１１）。中継装置１０１は、サーバ装置１０４から受信したデータをクライアント装置１０２及びクライアント装置１０３へ転送する（Ｍ１３１４及びＭ１３１８）。そして中継装置１０１は、転送されたデータの受信が完了したことを示す確認応答をクライアント装置１０２とクライアント装置１０３の両方から受信した後に、データの送達確認の通知をサーバ装置１０４に送信する（Ｍ１３２０）。

このように、本実施形態の通信システム１００によれば、中継装置１０１がデータの転送先である複数のクライアント装置から確認応答を受信した後に、当該データの送達確認の通知がサーバ装置１０４へ送信される。これにより、すべての転送先にデータが送達されたかをサーバ装置１０４が判断できるようになる。

また中継装置１０１は、Ｍ１３１６のように、転送先である複数のクライアント装置のうちの一部のクライアント装置から確認応答を受信した後に、暫定応答をサーバ装置１０４へ送信してもよい。このように、送達確認の通知とは異なる通知である暫定応答を送信することで、一部の転送先にデータが送達されたことをサーバ装置１０４が判断できる。すなわち、暫定応答が送信された時点ではすべての転送先へのデータの送達は未完了であることをサーバ装置１０４が判断できる。なお、中継装置１０１は暫定応答を送信せずに送達確認の通知だけを送信してもよい。こうすることで、中継装置１０１が転送先から確認応答を受信するたびに暫定応答を送信する場合と比較して、中継装置１０１とサーバ装置１０４との間の通信量を低減することができる。

また、中継装置１０１は、暫定応答と送達確認の通知という２種類の通知を送信するものに限らず、データの転送先のクライアント装置の種別や送達が完了した転送先の数などに応じて、３種類以上の通知をサーバ装置１０４へ送信してもよい。また、中継装置１０１は、転送先のクライアント装置それぞれから確認応答を受信するたびに、同様の通知をサーバ装置１０４へ送信してもよい。図３の例で言えば、Ｍ１３１６で送信される暫定応答とＭ１３２０で送信される送達確認の通知とが同様のメッセージであってもよい。この方法でも、特にサーバ装置１０４が転送先のクライアント装置の数を把握している場合には、サーバ装置１０４は中継装置１０１から受信した通知の数を判定することで、転送先のクライアント装置すべてへデータが送達されたかを判断することができる。

サーバ装置１０４が転送先のクライアント装置の数を把握する方法としては、例えば中継装置１０１が、受信した転送要求の数をサーバ装置１０４へ送信してもよいし、クライアント装置から転送要求を受信するたびにサーバ装置１０４に通知を行ってもよい。そして、クライアント装置から中継装置１０１へアンサブスクライブ（転送要求の取り消し）が行われた際にも、その旨を中継装置１０１がサーバ装置１０４へ通知してもよい。また例えば、サーバ装置１０４がクライアント装置１０２からプッシュＵＲＩを取得する際に、クライアント装置１０２が識別子を共有する別のクライアント装置（図３の例におけるクライアント装置１０３）の数も併せて取得してもよい。

また、図３のシーケンスにおいては、中継装置１０１が受信した転送要求の送信元のすべて（クライアント装置１０２及びクライアント装置１０３）がデータの転送先となる場合を示した。ただしこれに限らず、中継装置１０１は転送要求の送信元のうちの一部にのみデータを転送してもよい。そして、中継装置１０１が転送要求の送信元のすべてにデータを転送するか一部にのみ転送するかを、サーバ装置１０４がプッシュポリシーにより指定してもよい。

例えば、図１２（ｃ）に示すプッシュポリシーリストにおいて、サーバ装置１０４対応するプッシュポリシーはａｌｌとなっている。この場合、中継装置１０１は、転送要求を行ったクライアント装置を図１２（ｂ）のプッシュ配信リストから検索し、該当するクライアント装置のすべてにプッシュメッセージを送信する。

一方、中継装置１０１が、サーバ装置１０４とは別のサーバ装置１０５から、プッシュポリシーとしてａｎｙが指定されたレシート要求を受信した場合を考える。この場合には、中継装置１０１は、サーバ装置１０５から送信されるデータについての転送要求を行ったクライアント装置のうち、何れか１つにのみプッシュメッセージを送信する。そして中継装置１０１は、プッシュメッセージの送信先のクライアント装置から確認応答を受信した後に、サーバ装置１０５に送達確認の通知を送信する。この方法によれば、転送要求を行った機器のうちの何れか１つにのみプッシュ通知が届けばよい場合に、プッシュメッセージに係る通信量や中継装置１０１の処理負荷を低減できる。例えば、同一のユーザが所有するスマートフォン、スマートウォッチ、タブレットといった複数の機器から転送要求が行われる場合に、そのうちの１つにプッシュ通知が届けば、ユーザがその通知を確認することができる。なおこの場合に、複数の機器に優先度を設定しておき、中継装置１０１は設定された優先度の高い機器にデータを転送してもよい。

また、プッシュポリシーの内容はこれらに限らず、例えば転送要求を行ったクライアント装置のうちデータの転送先とするクライアント装置の数を指定するものであってもよい。また例えば、転送要求を行った複数のクライアント装置にデータを転送し、転送先のクライアント装置のうちの一部のクライアント装置から中継装置１０１が確認応答を受信した後に送達確認の通知を送信することを指定するものであってもよい。そして中継装置１０１は、転送先である複数のクライアント装置すべてから確認応答を受信した後に送達確認の通知を送信するか、一部のクライアント装置から確認応答を受信した後に送達確認の通知を送信するかを、プッシュポリシーに基づいて決定してもよい。この場合、中継装置１０１は、プッシュポリシーに基づく決定に応じたタイミングで送達確認の通知をサーバ装置１０４に送信する。またサーバ装置１０４は、中継装置１０１が送達確認の通知の前に暫定応答を送信するか否かを指定してもよい。例えば、サーバ装置１０４はＭ１３０９におけるレシート要求のヘッダにＥｘｐｅｃｔ：１００−Ｃｏｎｔｉｎｕｅを含めることで暫定応答を要求してもよい。

また、中継装置１０１がどのクライアント装置へデータを転送するかの決定には、プッシュポリシー以外の情報も用いられてもよい。例えば、プッシュポリシーがａｎｙである場合に、中継装置１０１は、転送要求を行った複数のクライアント装置がデータを受信可能な状態であることを把握している場合には、上述のように何れかのクライアント装置にデータを送信する。一方、転送要求を行った複数のクライアント装置がデータを受信可能であるか不明である場合には、中継装置１０１は、複数のクライアント装置にデータを転送し、何れかのクライアント装置から確認要求を受信したことに応じて送達確認の通知を送信してもよい。これにより、クライアント装置の状態に応じたより適切なデータ転送処理が実現できる。

［装置の動作フロー］
次に、通信システム１００内の各装置の動作フローについて説明する。なお、図４から図１１を用いて以下で説明する処理は、各装置のＣＰＵ２０１がＲＯＭ２０２に格納されたプログラムをＲＡＭ２０３に展開して実行することで実現される。ただし、以下で説明する処理の少なくとも一部が、ＣＰＵ２０１とは異なる専用のハードウェアにより実現されてもよい。

図４は、中継装置１０１が識別子を生成する際の処理を説明するためのフローチャートである。図４に示す処理は、中継装置１０１がクライアント装置１０２もしくはクライアント装置１０３から識別子要求（サブスクライブ）を受信するタイミングで開始される。Ｓ５０１において、中継装置１０１は、クライアント装置１０２もしくはクライアント装置１０３から識別子要求を受信する。Ｓ５０２において、中継装置１０１は、識別子としてサブスクリプションＵＲＩとプッシュＵＲＩを生成する。Ｓ５０３において、中継装置１０１は、Ｓ５０１での識別子要求の送信元であるクライアント装置１０２もしくはクライアント装置１０３に識別子を送信する。Ｓ５０４において、中継装置１０１はＳ５０２で生成した識別子を図１２（ａ）に示すＲＡＭ２０３内の識別子リストに保存する。

図５は、中継装置１０１が転送要求を受信した際の処理を説明するためのフローチャートである。図５に示す処理は、中継装置がクライアント装置１０２もしくはクライアント装置１０３から転送要求を受信するタイミングで開始される。Ｓ６０１において、中継装置１０１は、クライアント装置１０２もしくはクライアント装置１０３から識別子を含む転送要求を受信する。Ｓ６０２において、中継装置１０１は、Ｓ６０１で受信した識別子とＳ５０４で識別子リストに保存した識別子を比較し、受信した識別子が識別子リストに含まれている場合はＳ６０３に進み、含まれていない場合はＳ６０４に進む。

Ｓ６０３において、中継装置１０１は、Ｓ６０１で受信した転送要求の送信元であるクライアント装置のデバイス情報を図１２（ｂ）に示すＲＡＭ２０３内のプッシュ配信リストに保存する。本実施形態におけるデバイス情報は、中継装置１０１がクライアント装置を一意に特定することができる情報である。具体的には、クライアント装置の機器ＩＤ、ＭＡＣアドレス、又はクライアント装置と中継装置との間のコネクションの識別情報などである。Ｓ６０４において、中継装置１０１は、Ｓ６０１での転送要求の送信元であるクライアント装置１０２もしくはクライアント装置１０３にエラーレスポンスを送信する。

図６は、中継装置１０１がクライアント装置１０２及びクライアント装置１０３にプッシュメッセージを送信する処理を説明するためのフローチャートである。図６に示す処理は、中継装置１０１がサーバ装置１０４から配信メッセージを受信するタイミングで開始される。Ｓ７０１において、中継装置１０１はサーバ装置１０４から識別子を含む配信メッセージを受信する。Ｓ７０２において、中継装置１０１は、Ｓ７０１で受信した識別子とＳ５０４で識別子リストに保存した識別子を比較し、受信した識別子が識別子リストに含まれている場合はＳ７０３に進み、含まれていない場合はＳ７０４に進む。

Ｓ７０３において、中継装置１０１は、図１２（ｃ）に示すプッシュポリシーリストから、Ｓ７０１において受信した配信メッセージのプッシュＵＲＩに対応するプッシュポリシーを確認する。そしてＳ７０５において、中継装置１０１はサーバ装置１０４に配信レスポンスを送信する。一方、Ｓ７０４においては、中継装置１０１はサーバ装置１０４にエラーレスポンスを送信し、図６の処理を終了する。

Ｓ７０６において、中継装置１０１はＳ７０３で確認したプッシュポリシーに応じて、プッシュメッセージの転送先を決定する。例えば、プッシュポリシーがａｌｌであり、中継装置１０１がＳ７０１で受信した配信メッセージに対応する転送要求を複数のクライアント装置から受信していた場合、当該複数のクライアント装置すべてが転送先として決定される。一方、プッシュポリシーがａｎｙだった場合、中継装置１０１は、受信した転送要求の送信元である複数のクライアント装置のうち何れか１つのクライアント装置を転送先として決定する。また、プッシュポリシーにより転送先の数が指定されている場合、指定に応じた数のクライアント装置が転送先として決定される。

Ｓ７０７において、中継装置１０１は、Ｓ６０３で保存したプッシュ配信リストにおいてＳ７０１で受信した識別子と対応するデバイス情報のうち、Ｓ７０５で決定された転送先それぞれについて、Ｓ７０８からＳ７１１の処理を行う。Ｓ７０８において、中継装置１０１は、対象のデバイス情報に対応するクライアント装置にプッシュ予約を送信する。Ｓ７０９において、中継装置１０１は、対象のデバイス情報に対応するクライアント装置にプッシュメッセージを送信する。Ｓ７１０において、中継装置１０１は、Ｓ７０９でのプッシュメッセージの転送先のクライアント装置からプッシュレスポンスを受信する。Ｓ７１１において、中継装置１０１はサーバ装置１０４に暫定応答（ＨＴＴＰ１００Ｃｏｎｔｉｎｕｅ）を送信する。この暫定応答には、例えばＦＱＤＮ（ＦｕｌｌｙＱｕａｌｉｆｉｅｄＤｏｍａｉｎＮａｍｅ）やＩＰアドレスその他の識別子を用いて、どのクライアント装置からプッシュレスポンスを受信したかの情報を含めてもよい。

Ｓ７０１で受信されたプッシュＵＲＩと対応する複数のデバイス情報が転送先として決定されている場合、Ｓ７０８からＳ７１１において中継装置１０１は、Ｓ７０１において受信した配信メッセージを転送先の決定に応じた複数のクライアント装置へ転送する。ここで、同一のプッシュＵＲＩと対応する複数のデバイス情報が転送先となっている場合とは、すなわち中継装置１０１が同一のサブスクリプションＵＲＩに基づく転送要求を転送先に決定された複数のクライアント装置から受信していた場合である。

すべての転送先についてＳ７０８からＳ７１１の処理が終了すると、Ｓ７１２において中継装置１０１は、すべての転送先にプッシュメッセージが送達されたことを示す送達確認通知をサーバ装置１０４に送信し、処理を終了する。また、中継装置１０１は、指定されたプッシュポリシーに合致したプッシュメッセージの送達に失敗した場合や、送達の完了前にタイムアウトした場合などには、Ｓ７１２において送達確認の通知に代えてエラーレスポンスを送信する。エラーレスポンスには、データが送達されたクライアント装置の識別情報や、データを送達できなかったクライアント装置の識別情報、データの送達に失敗した原因を示す情報などが含まれていてもよい。なお、Ｓ７１１における暫定応答の送信は、一部の転送先についてのみ行われてもよい。例えば、中継装置１０１は、複数の転送先から送信されるプッシュレスポンスのうち最後のプッシュレスポンスを受信した場合には、Ｓ７１１における暫定応答の送信を行わずに、Ｓ７１２における送達確認の通知の送信を行ってもよい。また、サーバ装置１０４が転送先のクライアント装置の数を把握している場合などには、中継装置１０１は、Ｓ７１２における送達確認の通知の送信を行わず、Ｓ７１１における暫定応答の送信のみを行ってもよい。

また、複数の転送先のうち一部（ｎ個）の転送先にプッシュメッセージが送達された場合に送達確認を通知するようにプッシュポリシーにより指定された場合には、中継装置１０１は、すべての転送先についてＳ７０８からＳ７１１までの処理を並列処理する。そして、Ｓ７１０で受信するプッシュレスポンスの数を確認し、ｎ個に達するとループを抜け、Ｓ７１２で送達確認の通知が送信される。プッシュポリシーにより転送先のクライアント装置が指定される場合においても、同様な処理を行うことでプッシュポリシーに応じたプッシュメッセージの送信が実現できる。

図７は、クライアント装置１０２が中継装置１０１から識別子を受信し、クライアント装置１０３及びサーバ装置１０４に識別子を送信する処理を説明するためのフローチャートである。図７に示す処理は、例えばクライアント装置１０２にユーザの操作などによって識別子要求の指示がなされたタイミングで開始される。ただし、図７に示す処理の開始タイミングは上記タイミングに限定されない。

Ｓ８０１において、クライアント装置１０２は中継装置１０１に識別子要求を送信する。Ｓ８０２において、クライアント装置１０２は中継装置１０１から識別子を受信する。Ｓ８０３において、クライアント装置１０２は自装置が有するＲＡＭ２０３内の識別子リストにＳ８０２で受信した識別子を保存する。Ｓ８０４において、クライアント装置１０２は、送信対象装置それぞれについてＳ８０５の処理を行う。本実施形態における送信対象装置はクライアント装置１０３及びサーバ装置１０４を指すが、これに限らない。例えば、識別子を管理するための情報管理装置（不図示）を送信対象装置とし、クライアント装置１０２は他の装置との間の識別子のやり取りを、情報管理装置を介して行ってもよい。Ｓ８０５において、クライアント装置１０２は送信対象装置に識別子を送信する。

図８は、クライアント装置１０３がクライアント装置１０２から識別子を取得する処理を説明するためのフローチャートである。図８に示す処理は、クライアント装置１０３がクライアント装置１０２から識別子を受信するタイミングで開始される。Ｓ９０１において、クライアント装置１０３はクライアント装置１０２から識別子を受信する。Ｓ９０２において、クライアント装置１０３は自装置が有するＲＡＭ２０３内の識別子リストにＳ９０１で受信した識別子を保存する。なお、サーバ装置１０４がクライアント装置１０２から識別子を取得する処理についても、図８を用いて説明した処理と同様である。

図９は、クライアント装置１０２が中継装置１０１からプッシュメッセージを受信する処理を説明するためのフローチャートである。図９に示す処理は、例えばクライアント装置１０２にユーザの操作などによって転送要求の指示がなされたタイミングで開始される。ただし、図１０に示す処理の開始タイミングは上記タイミングに限定されない。Ｓ１００１において、クライアント装置１０２は中継装置１０１に転送要求を送信する。Ｓ１００２において、クライアント装置１０２は中継装置１０１からの転送終了までＳ１００３からＳ１００６の処理を繰り返す。本実施形態において転送終了となる場合は、例えばクライアント装置１０２にユーザの操作などによってプッシュメッセージの受信を終了する指示がなされた場合や、クライアント装置１０２が中継装置１０１から転送終了を示すメッセージを受信した場合である。なお、転送終了の条件はこれに限らない。

Ｓ１００３において、クライアント装置１０２は中継装置１０１から識別子を含むプッシュ予約を受信する。Ｓ１００４において、クライアント装置１０２は中継装置１０１からプッシュメッセージを受信するまで待機する。Ｓ１００５において、クライアント装置１０２は中継装置１０１からプッシュメッセージを受信する。Ｓ１００６において、クライアント装置１０２は中継装置１０１にプッシュレスポンスを送信する。なお、クライアント装置１０３が中継装置１０１からプッシュメッセージを受信する処理についても、図９を用いて説明した処理と同様である。

図１０は、サーバ装置１０４が中継装置１０１に配信メッセージを送信する処理を説明するためのフローチャートである。図１０に示す処理は、例えばサーバ装置１０４にユーザの操作などによってデータ送信の指示がなされたタイミングや、サーバ装置１０４がセンサーなどにより所定のイベントを検知したタイミングで開始される。ただし、図１０に示す処理の開始タイミングは上記タイミングに限定されない。

Ｓ１１０１において、サーバ装置１０４は中継装置１０１に配信メッセージを送信する。Ｓ１１０２において、サーバ装置１０４は中継装置１０１から暫定応答を受信する。暫定応答は、配信メッセージが転送先のクライアント装置うちの一部に送達されたことを示す。これにより、サーバ装置１０４は各クライアント装置におけるメッセージの受信状況を把握することができる。Ｓ１１０３において、サーバ装置１０４は中継装置１０１から送達確認の通知を受信する。

図１１は、中継装置１０１がサーバ装置１０４へのレシートの送受信のために行う前処理を説明するためのフローチャートである。図１１に示す処理は、例えばサーバ装置１０４がクライアント装置１０２からプッシュＵＲＩを取得したタイミングで開始される。ただし、図１１に示す処理の開始タイミングは上記タイミングに限定されない。

Ｓ１２０１において、中継装置１０１はサーバ装置１０４から、送達確認の通知を要求するための通知要求を受信する。Ｓ１２０２において、中継装置１０１はサーバ装置１０４に、通知要求に対するレスポンスを送信する。Ｓ１２０３において、中継装置１０１はサーバ装置１０４から、送達確認の通知や暫定応答などを要求するためのレシート要求を受信する。Ｓ１２０４において、中継装置１０１はサーバ装置１０４に、プッシュ型のデータ送信によりレシートを送信するためのプッシュ予約を送信する。

［変形例］
上述した本実施形態については、その主旨を逸脱しない範囲で種々の変形が可能である。本実施形態においては、クライアント装置１０２とクライアント装置１０３の２台の装置が同一の識別子を用いて中継装置１０１からプッシュメッセージを受信する場合を中心に説明した。ただしこれに限らず、３台以上のクライアント装置が同一の識別子を用いて中継装置１０１からのプッシュメッセージを受信してもよい。また、クライアント装置１０２及びクライアント装置１０３は、複数のサーバ装置からプッシュされるデータを受信してもよい。この場合、サーバ装置ごとに異なる識別子が用いられてもよい。なお、本実施形態では送信される転送要求やデータに識別子が含まれているものとしたが、識別子に基づく転送要求やデータが送信されればよい。例えば、転送要求と識別子とを関連付けるデータが、当該転送要求とは別に送信されてもよい。

また、本実施形態では、中継装置１０１とクライアント装置１０２やクライアント装置１０３との間の通信は、ＨＴＴＰ／２において規定されるコネクション及びストリームを使用して行われるものとした。一方、中継装置１０１とサーバ装置１０４との間の通信は、ＨＴＴＰ／１．１に従うものとした。ただし、通信システム１００内で行われる通信の方式はこれらに限定されない。例えば、中継装置１０１とサーバ装置１０４との間の通信もＨＴＴＰ／２に従う通信であってもよい。また、ＨＴＴＰ／１．１やＨＴＴＰ／２に限らず、ＷｅｂＳｏｃｋｅｔやＱＵＩＣ（ＱｕｉｃｋＵＤＰＩｎｔｅｒｎｅｔＣｏｎｎｅｃｔｉｏｎｓ）などの他の通信規格に従って通信が行われてもよい。この場合、各規格に応じた形式のメッセージや論理的な接続を使用して通信が行われる。また、本実施形態ではＷｅｂＰｕｓｈプロトコルに基づくプッシュ型のデータ送信が行われる例を説明したが、これに限らず、プッシュ通知を送受信するための他のプロトコルにも本実施形態を適用することができる。さらに、プッシュを用いないプロトコルにも適用可能である。

また、本実施形態においては、サーバ装置１０４が中継装置１０１へ送信するレシート要求にプッシュポリシーを含める場合を中心に説明した。これにより、中継装置１０１はサーバ装置１０４の要求に応じたデータの転送処理を行うことができる。なお、プッシュポリシーはサーバ装置１０４から中継装置１０１へ送信される配信メッセージに含まれていてもよいし、レシート要求や配信メッセージとは別に送信されてもよい。また、中継装置１０１やクライアント装置１０２などがプッシュポリシーを決定し、決定されたプッシュポリシーをサーバ装置１０４に通知してよい。さらに、複数装置間のネゴシエーションによってプッシュポリシーが決定されてもよい。また、クライアント装置１０２やクライアント装置１０３は、プッシュメッセージの受信ポリシーを決定し、この受信ポリシーに従って、中継装置１０１から送信されるプッシュメッセージを受信するか否かを判断してもよい。

＜その他の実施形態＞
本発明は、上述の実施形態の１以上の機能を実現するプログラムを、ネットワーク又は記憶媒体を介してシステム又は装置に供給し、そのシステム又は装置のコンピュータにおける１つ以上のプロセッサーがプログラムを読出し実行する処理でも実現可能である。また、１以上の機能を実現する回路（例えば、ＡＳＩＣ等）によっても実現可能である。また、そのプログラムをコンピュータにより読み取り可能な記録媒体に記録して提供してもよい。

１００通信システム
１０１中継装置
１０２クライアント装置
１０３クライアント装置
１０４サーバ装置

Claims

サーバ装置からデータを受信する第１受信手段と、
前記第１受信手段により受信される前記データをクライアント装置へ送信する第１送信手段と、
前記第１送信手段により送信された前記データがクライアント装置により受信されたことを示す確認応答を当該クライアント装置から受信する第２受信手段と、
前記第１送信手段により前記データが複数のクライアント装置へ送信される場合に、前記第２受信手段が前記複数のクライアント装置から前記確認応答を受信した後に、前記データの送達確認の通知を前記サーバ装置に送信する第２送信手段とを有することを特徴とする通信装置。
前記第２送信手段は、前記送達確認の通知をプッシュ型のデータ送信により前記サーバ装置へ送信することを特徴とする請求項１に記載の通信装置。
クライアント装置からデータの転送要求を受信する第３受信手段を有し、
前記第１送信手段は、前記第１受信手段により受信される前記データに対応する転送要求を前記第３受信手段が複数のクライアント装置から受信した場合に、当該複数のクライアント装置へ前記データを送信することを特徴とする請求項１又は２に記載の通信装置。
クライアント装置からデータの転送要求を受信する第３受信手段と、
前記第１受信手段により受信される前記データに対応する転送要求を前記第３受信手段が複数のクライアント装置から受信した場合に、当該複数のクライアント装置のうち前記データの送信先とすべきクライアント装置を決定する決定手段とを有し、
前記第１送信手段は、前記決定手段による決定に応じたクライアント装置へ前記データを送信することを特徴とする請求項１又は２に記載の通信装置。
前記第１受信手段により受信される前記データの送信先とすべきクライアント装置の数に関する指定情報を前記サーバ装置から受信する第４受信手段を有し、
前記決定手段は、前記データの送信先とすべきクライアント装置を、前記第４受信手段により受信される前記指定情報に基づいて決定することを特徴とする請求項４に記載の通信装置。
クライアント装置からの情報要求に応じて当該クライアント装置へ発行情報を送信する第３送信手段を有し、
前記第１送信手段は、前記第３送信手段により送信された発行情報であって前記第１受信手段により受信される前記データに対応する発行情報を含む転送要求を前記第３受信手段が複数のクライアント装置から受信した場合に、前記データを当該複数のクライアント装置のうちの１以上のクライアント装置へ送信することを特徴とする請求項３乃至５の何れか１項に記載の通信装置。
前記第３送信手段により送信される前記発行情報は、ＷｅｂＰｕｓｈプロトコルにおいて規定されるサブスクリプションＵＲＩであることを特徴とする請求項６に記載の通信装置。
前記第２送信手段により送信される前記送達確認の通知は、ＷｅｂＰｕｓｈプロトコルにおいて規定されるプッシュメッセージレシートであることを特徴とする請求項１乃至７の何れか１項に記載の通信装置。
前記第２送信手段は、前記第１送信手段により前記データが複数のクライアント装置へ送信される場合に、前記第２受信手段が前記複数のクライアント装置のうちの一部のクライアント装置から前記確認応答を受信した後に、前記複数のクライアント装置への前記データの送達が未完了であることを示す通知を前記サーバ装置に送信することを特徴とする請求項１乃至８の何れか１項に記載の通信装置。
前記第１送信手段により前記データが複数のクライアント装置へ送信される場合に、前記第２受信手段が前記複数のクライアント装置から前記確認応答を受信した後に前記送達確認の通知を送信するか、前記第２受信手段が前記複数のクライアント装置のうちの一部のクライアント装置から前記確認応答を受信した後に前記送達確認の通知を送信するかを決定する決定手段を有し、
前記第２送信手段は、前記決定手段による決定に応じたタイミングで前記送達確認の通知を前記サーバ装置に送信することを特徴とする請求項１乃至９の何れか１項に記載の通信装置。
前記決定手段は、前記第２受信手段が前記複数のクライアント装置から前記確認応答を受信した後に前記送達確認の通知を送信するか、前記第２受信手段が前記複数のクライアント装置のうちの一部のクライアント装置から前記確認応答を受信した後に前記送達確認の通知を送信するかを、前記サーバ装置から受信した情報に基づいて決定することを特徴とする請求項１０に記載の通信装置。
通信装置がサーバ装置からデータを受信する第１受信工程と、
前記第１受信工程において受信される前記データを前記通信装置からクライアント装置へ送信する第１送信工程と、
前記第１送信工程において送信された前記データがクライアント装置により受信されたことを示す確認応答を前記通信装置が当該クライアント装置から受信する第２受信工程と、
前記第１送信工程において前記データが複数のクライアント装置へ送信される場合に、前記第２受信工程において前記通信装置が前記複数のクライアント装置から前記確認応答を受信した後に、前記データの送達確認の通知を前記通信装置から前記サーバ装置へ送信する第２送信工程とを有することを特徴とする通信方法。
前記第２送信工程においては、前記送達確認の通知がプッシュ型のデータ送信により前記通信装置から前記サーバ装置へ送信されることを特徴とする請求項１２に記載の通信方法。
通信装置がクライアント装置からデータの転送要求を受信する第３受信工程を有し、
前記第１送信工程においては、前記第１受信工程において受信される前記データに対応する転送要求を前記第３受信工程において前記通信装置が複数のクライアント装置から受信した場合に、当該複数のクライアント装置へ前記データが送信されることを特徴とする請求項１２又は１３に記載の通信方法。
コンピュータを、請求項１乃至１１の何れか１項に記載の通信装置として動作させるためのプログラム。