(57)【要約】  ＧＵＩ装置１００で必要となるイベントリストをサービス装置３００に通知し、サービス装置３００は、イベントリストにＩＤを付与してＧＵＩ装置１００に応答する。サービス装置３００でイベントが発生した場合、サービス装置３００では、ＧＵＩ装置１００から通知されたイベントリストに基づいてイベント通知可否を判定する。ＧＵＩ装置はイベントをサービス装置３００に通知する場合、ＩＤが存在すればイベントリストの代わりにＩＤを送信する。
2014006669.tif 000002
【特許請求の範囲】
【請求項１】
イベント通知に基づき画面構築を行うＧＵＩ装置と、サービスを実行してイベントを発生するサービス装置とがネットワークを介して接続され、相互に通信を行う通信システムにおいて、
前記ＧＵＩ装置は、
前記イベントの一覧であるイベントリストと、当該イベントリストを一意に特定するＩＤを格納するＧＵＩ装置側イベントリスト記憶部と、
前記画面構築時に当該画面に必要なイベントリストを前記サービス装置に送信すると共に、当該送信前に、前記ＧＵＩ装置側イベントリスト記憶部を参照し、送信対象イベントリストと一致するイベントリストが存在する場合は、そのイベントリストを一意に特定するＩＤを取得し、前記送信対象イベントリストの代わりに当該ＩＤを前記サービス装置に送信するＧＵＩ装置側イベント処理部とを備え、
かつ、前記ＧＵＩ装置側イベント処理部は、前記イベントリストまたは前記ＩＤを前記サービス装置に送信した結果として得られる応答メッセージにＩＤが含まれる場合は、当該応答メッセージに含まれるＩＤと、前記サービス装置に対して送信したイベントリスト、または、その代わりにＩＤを送信したイベントリストとを１個の組として前記ＧＵＩ装置側イベントリスト記憶部に記憶させ、
前記サービス装置は、
前記イベントの一覧であるイベントリストと、当該イベントリストを一意に特定するＩＤを格納するサービス装置側イベントリスト記憶部と、
前記イベントリストと前記ＩＤとの関係を管理するＩＤ管理部と、
前記サービスを実行し、イベントを発生させるサービス処理部と、
前記ＧＵＩ装置から前記イベントリストを受信した場合、前記サービス装置側イベントリスト記憶部を参照し、前記受信したイベントリストと一致するイベントリストが存在する場合は、そのイベントリストを一意に特定するＩＤを取得し、当該ＩＤを前記ＧＵＩ装置への応答メッセージに含めて送信し、一方、前記サービス装置側イベントリスト記憶部を参照した結果、受信したイベントリストと一致するイベントリストが存在しない場合は、前記ＩＤ管理部から前記サービス装置側イベントリスト記憶部に登録されていないＩＤを取得して、当該取得したＩＤと前記受信したイベントリストとを１個の組として、前記サービス装置側イベントリスト記憶部に登録し、前記取得したＩＤを前記ＧＵＩ装置への応答メッセージに含めて送信し、前記ＧＵＩ装置からＩＤを受信した場合は、前記サービス装置側イベントリスト記憶部を参照し、前記受信したＩＤと一致するイベントリストが存在する場合は、受信したＩＤを前記ＧＵＩ装置への応答メッセージに含めて送信するイベント処理部とを備え、
かつ、前記サービス装置側イベント処理部は、前記サービス処理部のサービスによって発生するイベントに対して、当該イベントが含まれるイベントリストが前記ＧＵＩ装置への通知対象となっているかを判定し、通知対象となっている場合にのみ、前記イベントをＧＵＩ装置に通知することを特徴とする通信システム。
【請求項２】
サービス装置側イベント処理部は、
ＧＵＩ装置から受信したイベントリストと、当該イベントリストを一意に特定するＩＤの組をサービス装置側イベントリスト記憶部に登録する前に、当該サービス装置側イベントリスト記憶部に登録可能なデータサイズを超えるかを判定し、超える場合は、超えない状態になるように、前記サービス装置側イベントリスト記憶部に登録済みのイベントリストとＩＤとの組を削除し、その状態で、前記ＧＵＩ装置から受信したイベントリストと当該イベントリストを一意に特定するＩＤの組を前記サービス装置側イベントリスト記憶部に登録し、一方、削除したイベントリストを一意に特定するＩＤを前記ＧＵＩ装置への応答メッセージに含めて送信し、
ＧＵＩ装置側イベント処理部は、
イベントリストまたはＩＤを前記サービス装置に送信した結果として得られる応答メッセージに前記サービス装置側イベントリスト記憶部で削除されたＩＤが含まれる場合は、当該削除されたＩＤに対応したイベントリストをＧＵＩ装置側イベントリスト記憶部から削除することを特徴とする請求項１記載の通信システム。
【請求項３】
ＧＵＩ装置側イベント処理部は、
イベントリストまたはＩＤをサービス装置に送信した結果として得られる応答メッセージにＩＤが含まれる場合、ＧＵＩ装置側イベントリスト記憶部に登録可能なデータサイズを超えるかを判定し、超える場合は、超えない状態になるように、前記ＧＵＩ装置側イベントリスト記憶部に登録済みのイベントリストとＩＤとの組を削除し、その状態で、前記応答メッセージに含まれるＩＤと、ＧＵＩ装置が送信したイベントリスト、またはその代わりにＩＤを送信したイベントリストとを１個の組として、前記ＧＵＩ装置側イベントリスト記憶部に登録することを特徴とする請求項１記載の通信システム。
【請求項４】
ＧＵＩ装置側イベント処理部は、
ＧＵＩ装置側イベントリスト記憶部に登録されていないイベントリストをサービス装置に送信する場合、当該送信対象イベントリストと、前記ＧＵＩ装置側イベントリスト記憶部に登録済みのイベントリストとの差分を生成し、生成した差分を示す情報量が、前記送信対象イベントリストの情報量よりも小さい場合は、当該送信対象イベントリストの代わりに、前記生成した差分と、当該差分を生成するために用いたＧＵＩ装置側イベントリスト記憶部に登録済みのイベントリストを一意に特定するＩＤとをサービス装置に送信し、
サービス装置側イベント処理部は、
ＧＵＩ装置から前記ＩＤと前記差分を受信した場合、当該ＩＤを用いてサービス装置側イベントリスト記憶部からイベントリストを取得し、当該取得したイベントリストと前記差分を用いて新たなイベントリストを生成し、当該生成した新たなイベントリストを前記ＧＵＩ装置から受信したイベントリストに代えて処理を行うことを特徴とする請求項１記載の通信システム。
【請求項５】
ＧＵＩ装置側イベント処理部は、
サービス装置にイベントリストを送信する場合、各イベントに当該サービス装置からの通知間隔の情報を付加し、かつ、
前記サービス装置は、前記各イベントの通知間隔に対応したイベントキューを格納するイベント蓄積部を備え、
サービス装置側イベント処理部は、
サービス処理部のサービスによって発生するイベントが前記ＧＵＩ装置から通知されたイベントであった場合は、当該イベントの通知間隔に対応したイベントキューにそのイベントを格納すると共に、前記イベントキューの通知タイミングになった場合は、当該イベントキューに格納されているイベントを前記ＧＵＩ装置に通知することを特徴とする請求項１記載の通信システム。
【請求項６】
サービス装置側イベント処理部は、イベントキューにイベントを格納する際、既に同じイベントが格納されていた場合は、前記イベントの格納を行わないか、もしくは既に格納されていたイベントを削除してから前記イベントを格納することを特徴とする請求項５記載の通信システム。
【請求項７】
サービス装置側イベント処理部は、イベントがパラメータを有する場合、イベントキューに既に同じイベントが格納されているか否かの同一性判定を前記パラメータを含めて行うことを特徴とする請求項６記載の通信システム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、ＧＵＩ装置とサービス装置がネットワークを介して接続され、相互に通信することでＧＵＩ装置におけるグラフィックスを表示する通信システムに関する。
【背景技術】
【０００２】
従来の、ＧＵＩ（Ｇｒａｐｈｉｃａｌ  Ｕｓｅｒ  Ｉｎｔｅｒｆａｃｅ）を持つ組み込み機器では、各アプリケーションの挙動を既定するサービスロジックとＧＵＩを同一の機器に実装し、単体で独立した動作が可能な装置として構成されることが一般的である。
その一方で、サーバ・クライアントシステムのように、サーバにサービスロジック、クライアントにＧＵＩを実装し、それらがネットワーク経由で連携することにより、システムを構成する方法もある。【０００３】
近年の組み込み機器の処理能力の向上と、ネットワーク接続機能を持つことが一般的になってきていることにより、組み込み機器に上記のサーバ・クライアントシステムを適用し、ＧＵＩとサービスロジックをそれぞれ異なる機器に実装することが可能である。
このようなシステムでは、従来は同一機器内で行われていたＧＵＩとサービスロジック間の通信が、機器間の通信に置き換わる。機器間通信の処理能力は、同一機器内の通信の処理能力より低いことが一般的である。また、従来はサービスロジックで発生したイベントはすべてＧＵＩに通知し、ＧＵＩが受信したイベントの必要性を判断してＧＵＩへの反映を行っていた。機器内の通信が機器間の通信に置き換わると、通信に要する時間が長くなってしまうため、機器間の通信量及び通信頻度を削減することによるシステム全体の応答性能（例えばユーザがＧＵＩを操作してから、サービスロジックがその操作に対応する処理を行い、処理の結果をＧＵＩに反映させるまでの時間）の改善が必要となる。具体的には、不要なイベントをサービスロジックからＧＵＩに通知しないようにすることが望ましい。【０００４】
例えば、特許文献１では、イベント通知要求を行った通知先をリスナーに登録し、登録されたリスナーのみにイベントを通知することにより、不要なイベント通知の発生を回避している。また、特許文献２では、通知者プログラムがイベントを発生させたとき、要求者プログラムが通知マネージャに提示したイベントのみを要求者プログラムに通知することにより、不要なイベント通知の発生を回避している。このとき、通知パラメータとそれに対応する辞書を用いることにより、通知マネージャへ提示する１つ以上のイベントの指定に要する通信量を削減している。
【先行技術文献】
【特許文献】
【０００５】
【特許文献１】特開２００８−７７２１９号公報
【特許文献２】特表２００４−５３２４７９号公報
【発明の概要】
【発明が解決しようとする課題】
【０００６】
しかしながら、特許文献１に示されたような技術では、イベントを１つ受信すると、次のイベントを受信するためには再びイベント通知要求を行う必要がある。したがって、特許文献１の手法を、ＧＵＩとサービスロジックが異なる機器に実装されているシステムに適用すると、通信が頻繁に行われてしまうという課題があった。【０００７】
また、特許文献２に示された構成では、通知マネージャへの通知パラメータと辞書の対応関係が固定されている。イベントの種類が少ないシステムでは特許文献２の手法でも問題ないが、イベントの種類が多いシステムでは、辞書のサイズが大きくなってしまうという課題がある。さらに、サービスロジックは変更せずＧＵＩのみを変更するという場合を考えると、ＧＵＩの変更に伴いＧＵＩで必要とするイベントのパターンも変更される可能性があるが、特許文献２の手法では変更されたパターンが辞書にないとＧＵＩの変更に対応できないという課題があった。【０００８】
この発明は、上記のような課題を解決するためになされたもので、通信量を削減し、かつ、イベントのパターン変更にも柔軟に対処することのできる通信システムを得ることを目的とする。
【課題を解決するための手段】
【０００９】
この発明に係る通信システムは、イベント通知に基づき画面構築を行うＧＵＩ装置と、サービスを実行してイベントを発生するサービス装置とがネットワークを介して接続され、相互に通信を行う通信システムにおいて、ＧＵＩ装置は、イベントの一覧であるイベントリストと、イベントリストを一意に特定するＩＤを格納するＧＵＩ装置側イベントリスト記憶部と、画面構築時に画面に必要なイベントリストをサービス装置に送信すると共に、送信前に、ＧＵＩ装置側イベントリスト記憶部を参照し、送信対象イベントリストと一致するイベントリストが存在する場合は、そのイベントリストを一意に特定するＩＤを取得し、送信対象イベントリストの代わりにＩＤをサービス装置に送信するＧＵＩ装置側イベント処理部とを備え、かつ、ＧＵＩ装置側イベント処理部は、イベントリストまたはＩＤをサービス装置に送信した結果として得られる応答メッセージにＩＤが含まれる場合は、応答メッセージに含まれるＩＤと、サービス装置に対して送信したイベントリスト、または、その代わりにＩＤを送信したイベントリストとを１個の組としてＧＵＩ装置側イベントリスト記憶部に記憶させ、サービス装置は、イベントの一覧であるイベントリストと、イベントリストを一意に特定するＩＤを格納するサービス装置側イベントリスト記憶部と、イベントリストとＩＤとの関係を管理するＩＤ管理部と、サービスを実行し、イベントを発生させるサービス処理部と、ＧＵＩ装置からイベントリストを受信した場合、サービス装置側イベントリスト記憶部を参照し、受信したイベントリストと一致するイベントリストが存在する場合は、そのイベントリストを一意に特定するＩＤを取得し、ＩＤをＧＵＩ装置への応答メッセージに含めて送信し、一方、サービス装置側イベントリスト記憶部を参照した結果、受信したイベントリストと一致するイベントリストが存在しない場合は、ＩＤ管理部からサービス装置側イベントリスト記憶部に登録されていないＩＤを取得して、取得したＩＤと受信したイベントリストとを１個の組として、サービス装置側イベントリスト記憶部に登録し、取得したＩＤをＧＵＩ装置への応答メッセージに含めて送信し、ＧＵＩ装置からＩＤを受信した場合は、サービス装置側イベントリスト記憶部を参照し、受信したＩＤと一致するイベントリストが存在する場合は、受信したＩＤをＧＵＩ装置への応答メッセージに含めて送信するイベント処理部とを備え、かつ、サービス装置側イベント処理部は、サービス処理部のサービスによって発生するイベントに対して、イベントが含まれるイベントリストがＧＵＩ装置への通知対象となっているかを判定し、通知対象となっている場合にのみ、イベントをＧＵＩ装置に通知するようにしたものである。
【発明の効果】
【００１０】
この発明に係る通信システムは、ＧＵＩ装置で必要となるイベントリストをサービス装置に通知し、サービス装置は、通知されたイベントリストに基づいてＧＵＩ装置へのイベント通知可否を判定すると共に、イベントリストにＩＤを付与してＧＵＩ装置に応答し、ＧＵＩ装置はＩＤが存在する場合はイベントリストの代わりにＩＤを送信するようにしたので、通信量を削減することができると共に、イベントのパターン変更にも柔軟に対処することができる。
【図面の簡単な説明】
【００１１】
【図１】この発明の実施の形態１による通信システムを示す構成図である。
【図２】この発明の実施の形態１による通信システムのイベントリストを示す説明図である。
【図３】この発明の実施の形態１による通信システムのイベントリスト記憶部の記憶内容を示す説明図である。
【図４】この発明の実施の形態１による通信システムのイベントリスト登録時のＧＵＩ装置の動作を示すフローチャートである。
【図５】この発明の実施の形態１による通信システムのイベントリスト登録時のサービス装置の動作を示すフローチャートである。
【図６】この発明の実施の形態１による通信システムのイベント発生時のサービス装置の動作を示すフローチャートである。
【図７】この発明の実施の形態２による通信システムを示す構成図である。
【図８】この発明の実施の形態２による通信システムの応答メッセージに含まれる登録結果を示す説明図である。
【図９】この発明の実施の形態２による通信システムのイベントリスト登録時のＧＵＩ装置の動作を示すフローチャートである。
【図１０】この発明の実施の形態２による通信システムのイベントリスト登録時のサービス装置の動作を示すフローチャートである。
【図１１】この発明の実施の形態３による通信システムを示す構成図である。
【図１２】この発明の実施の形態３による通信システムのイベントリスト登録要求を示す説明図である。
【図１３】この発明の実施の形態３による通信システムのイベントリスト登録時のＧＵＩ装置の動作を示すフローチャートである。
【図１４】この発明の実施の形態３による通信システムのイベントリスト登録時のサービス装置の動作を示すフローチャートである。
【図１５】この発明の実施の形態４による通信システムを示す構成図である。
【図１６】この発明の実施の形態４による通信システムのイベント発生時のサービス装置の動作を示すフローチャートである。
【図１７】この発明の実施の形態４による通信システムのイベントリスト登録時のＧＵＩ装置の動作を示すフローチャートである。
【図１８】この発明の実施の形態４による通信システムのイベントリスト登録時のサービス装置の動作を示すフローチャートである。
【図１９】この発明の実施の形態４による通信システムのイベント発生時のサービス装置の動作を示すフローチャートである。
【図２０】この発明の実施の形態４による通信システムのイベントキューとタイマとの関係を示す説明図である。
【図２１】この発明の実施の形態４による通信システムのイベント発生時のサービス装置の他の動作を示すフローチャートである。
【図２２】この発明の実施の形態４による通信システムのイベント発生時のサービス装置のさらに他の動作を示すフローチャートである。
【発明を実施するための形態】
【００１２】
以下、この発明をより詳細に説明するために、この発明を実施するための形態について、添付の図面に従って説明する。
実施の形態１．
図１は、この発明の実施の形態１による通信システムを示す構成図である。
図１に示す通信システムは、ＧＵＩ装置１００とサービス装置３００とがネットワーク２００を介して接続された構成となっている。
【００１３】
ＧＵＩ装置１００は、表示部１０１、ＧＵＩロジック処理部１０２、要求処理部１０３、通信部１０４、イベント処理部（ＧＵＩ装置側イベント処理部）１０５、イベントリスト記憶部（ＧＵＩ装置側イベントリスト記憶部）１０６、インターフェース部１０７を備える。
【００１４】
表示部１０１は、例えば液晶ディスプレイなどの装置であり、ＧＵＩを表示する。ＧＵＩロジック処理部１０２は、表示部１０１に表示するＧＵＩを構築したり、インターフェース部１０７との入出力を担当したりする装置である。また、ＧＵＩロジック処理部１０２は、要求処理部１０３を介してサービス装置３００に要求を発行したり、イベント処理部１０５から通知されたイベントに基づき表示部１０１に表示するＧＵＩを変更したり、インターフェース部１０７を介してＧＵＩ以外の出力を行ったりする。要求処理部１０３は、ＧＵＩロジック処理部１０２から受けたサービス装置３００への要求を、通信部１０４を介した通信に適合するように変換する装置である。例えば、ＧＵＩロジック処理部１０２が要求処理部１０３に対して関数呼び出しを行い、ＧＵＩ装置１００とサービス装置３００がＨＴＴＰ（ＨｙｐｅｒＴｅｘｔ  Ｔｒａｎｓｆｅｒ  Ｐｒｏｔｏｃｏｌ）を用いて通信している場合（ＧＵＩ装置１００がクライアント、サービス装置３００がサーバとする）、ＧＵＩロジック処理部１０２からの関数呼び出しをＨＴＴＰリクエストに変換することに相当する。
【００１５】
通信部１０４は、ネットワーク２００を介したサービス装置３００とのデータ授受を担当する装置である。イベント処理部１０５は、ＧＵＩ装置１００におけるイベントに関する処理を担当する装置である。例えば、サービス装置３００に対するイベントリストの登録や、サービス装置３００から受信したイベントをＧＵＩロジック処理部１０２に渡すことである。イベントリストについては後述する。イベントリスト記憶部１０６は、イベント処理部１０５がサービス装置３００に登録したイベントリストと、そのイベントリストを一意に特定するためのＩＤの組を記憶するための装置である。インターフェース部１０７は、システムのユーザとのインタラクションを行うことを目的とした装置であり、例えばタッチパネル、スピーカなどが挙げられる。
【００１６】
サービス装置３００は、サービス処理部３０１、要求処理部３０４、通信部３０５、イベント処理部（サービス装置側イベント処理部）３０６、ＩＤ管理部３０７、イベントリスト記憶部（サービス装置側イベントリスト記憶部）３０８を備える。
サービス処理部３０１は、１つ以上のサービスを備える。図１では、２つのサービス（サービスＡ３０２、サービスＢ３０３）を備えている例を示している。なお、サービスとはそれぞれに固有の機能を提供するプログラムである。要求処理部３０４は、ＧＵＩ装置１００から受けた要求を、サービス処理部３０１に適合するように変換する装置である。例えば、ＧＵＩ装置１００とサービス装置３００がＨＴＴＰを用いて通信しており、サービス処理部３０１が各サービスで定義されているＡＰＩ（Ａｐｐｌｉｃａｔｉｏｎ  Ｐｒｏｇｒａｍｍｉｎｇ  Ｉｎｔｅｒｆａｃｅ）を公開している場合、ＨＴＴＰリクエストを解析して対応するＡＰＩを特定し、特定したＡＰＩを呼び出すことに相当する。通信部３０５は、ネットワーク２００を介したＧＵＩ装置１００とのデータ授受を担当する装置である。
【００１７】
イベント処理部３０６は、サービス装置３００におけるイベントに関する処理を担当する装置である。例えば、ＧＵＩ装置１００から要求されたイベントリストの登録を行ったり、サービス処理部３０１から発生したイベントを受け取りそのイベントをＧＵＩ装置１００に通知するか否かを判断したりする。ＩＤ管理部３０７は、ＧＵＩ装置１００から送信されたイベントリストを一意に特定するためのＩＤを決定するための装置である。また、ＩＤ管理部３０７は、イベントリスト記憶部３０８に記憶された内容を参照し、イベント処理部３０６から指定されたＩＤに対応するイベントリストを特定するという機能も担当する。イベントリスト記憶部３０８は、ＧＵＩ装置１００から送信されたイベントリストと、そのイベントリストを一意に特定するためのＩＤの組を記憶するための装置である。
【００１８】
図２は、この実施の形態におけるイベントリスト４００の構成を示す図である。イベントリスト４００は０個以上のイベント名を格納する。この実施の形態において、イベントはイベントの名称によりシステム内で一意に特定できるものとする。なお、イベントリスト４００の終端は、要素数もしくは終端を意味する要素により認識可能だが、図２では省略する。
【００１９】
図３は、この実施の形態におけるイベントリスト記憶部１０６及びイベントリスト記憶部３０８が記憶する内容を示す図である。記憶する内容は、ＩＤとイベントリストの組（イベントリスト４００ＡとＩＤ５００Ａ、イベントリスト４００ＢとＩＤ５００Ｂ）を一要素としており、図３では２個の要素が格納されている。
【００２０】
次に、ＧＵＩ装置１００及びサービス装置３００の動作について、図１、図２、図３、図４、図５、図６を用いて説明する。
図４は、この実施の形態におけるイベントリスト登録時のＧＵＩ装置１００の動作を示すフローチャートである。なお、イベントリストの登録は、ＧＵＩロジック処理部１０２において、例えば画面遷移などによる表示内容の変化が発生したときに、画面構築処理の一部として行われるものとする。画面遷移のトリガとしては、サービス装置３００からのイベント通知、またはインターフェース部１０７からの入力イベント通知等が挙げられる。
【００２１】
［ステップＳＴ１００］：ＧＵＩロジック処理部１０２は、画面遷移などの発生により、画面構築処理を開始する。
［ステップＳＴ１０１］：ＧＵＩロジック処理部１０２は、遷移後の画面で必要なイベントをイベント処理部１０５に提供する。イベント処理部１０５は、ＧＵＩロジック処理部１０２から提供された０個以上のイベントを用いてイベントリスト４００を作成し、イベント処理部１０５の内部に一時的に記憶する。なお、０個のイベント（＝イベント無し）でイベントリスト４００を作成する場合を含むのは、サービス装置３００からのイベントを必要としないサービスに対応するためである。
［ステップＳＴ１０２］：イベント処理部１０５は、ステップＳＴ１０１で一時的に記憶したイベントリスト４００を用いて、イベントリスト記憶部１０６にイベントリスト４００に一致する要素が登録されているか検索する。「未登録」の場合は、ステップＳＴ１０３に進む。「登録済」の場合は、該当する要素に記憶されているＩＤを取得し、ステップＳＴ１０４に進む。
［ステップＳＴ１０３］：イベント処理部１０５は、通信部１０４を介して、サービス装置３００にイベントリスト４００を送信する。例えばイベントリスト４００には４個のイベントが格納されているが、この個数は画面ごとに異なり、０個の場合もある。
【００２２】
［ステップＳＴ１０４］：イベント処理部１０５は、通信部１０４を介して、サービス装置３００にステップＳＴ１０２で得たＩＤを送信する。なお、サービス装置３００は、ＧＵＩ装置１００からのイベントリスト送信とＩＤ送信の区別が可能である。これは、送信データの書式（例えば、ＨＴＴＰリクエストのＵＲＩ（Ｕｎｉｆｏｒｍ  Ｒｅｓｏｕｒｃｅ  Ｉｄｅｎｔｉｆｉｅｒ）、もしくはＢＯＤＹに記述するテキストのフォーマット）を事前に決めておくことで実現できる。
［ステップＳＴ１０５］：通信部１０４は、ステップＳＴ１０３もしくはステップＳＴ１０４で実行した送信に対するサービス装置３００からの応答を待つ。応答を受信すると、通信部１０４はその応答をイベント処理部１０５に渡し、ステップＳＴ１０６に進む。
［ステップＳＴ１０６］：ステップＳＴ１０５で受信した応答には図３に示したＩＤが含まれており、イベント処理部１０５はＩＤが有効か否かを検査する。ＩＤが０、もしくは応答にＩＤが含まれていない場合は「無効なＩＤ」と判定し、ステップＳＴ１０８に進む。それ以外の場合は「有効なＩＤ」と判定し、ステップＳＴ１０７に進む。
【００２３】
［ステップＳＴ１０７］：イベント処理部１０５は、ステップＳＴ１０５で受信したＩＤとステップＳＴ１０１で内部に一時的に記憶したイベントリスト４００の組を、イベントリスト記憶部１０６に登録する。なお、ＩＤの値が一致する要素がイベントリスト記憶部１０６に存在する場合、その要素のイベントリスト部分を上書きする。
［ステップＳＴ１０８］：イベント処理部１０５は、内部に一時的に記憶していたイベントリスト４００を破棄すると共に、ＧＵＩロジック処理部１０２にイベントを渡す機能を有効にして、処理を終了する。なお、ＧＵＩロジック処理部１０２にイベントを渡す機能は、ステップＳＴ１００もしくは画面遷移の遷移元の終了処理などで適切に無効化されているものとする。また、ＧＵＩロジック処理部１０２にイベントを渡す機能が無効になっている期間に受信したイベントは、イベント処理部１０５内部で蓄積されるか、もしくはイベント処理部１０５にて破棄される。
【００２４】
図５は、この実施の形態におけるイベントリスト登録時のサービス装置３００の動作を示すフローチャートである。
［ステップＳＴ２００］：図４のステップＳＴ１０３もしくはステップＳＴ１０４でＧＵＩ装置１００が送信処理を行い、サービス装置３００の通信部３０５がそれを受信すると、サービス装置３００は処理を開始する。
［ステップＳＴ２０１］：通信部３０５はイベント処理部３０６に受信データを渡す。イベント処理部３０６は、受信データがＩＤかイベントリストのどちらであるかを判定する。ＩＤの場合は、イベント処理部３０６が受信データに含まれるＩＤをイベント処理部３０６の内部に一時的に記憶し、ステップＳＴ２０２に進む。イベントリストの場合は、イベント処理部３０６が受信データに含まれるイベントリストをイベント処理部３０６の内部に記憶し、ステップＳＴ２０３に進む。
【００２５】
［ステップＳＴ２０２］：イベント処理部３０６は、ＩＤ管理部３０７にステップＳＴ２０１で記憶したＩＤを渡し、検索を要求する。ＩＤ管理部３０７は、前記ＩＤを用いてイベントリスト記憶部３０８に一致する要素が登録されているか検索する。該当する要素を発見した場合、ＩＤ管理部３０７は「取得成功」と判定し、発見した要素に含まれるイベントリストをイベント処理部３０６に渡し、ステップＳＴ２０７に進む。該当する要素が見つからなかった場合、ＩＤ管理部３０７は「取得失敗」と判定し、判定結果をイベント処理部３０６に渡し、ステップＳＴ２０８に進む。
［ステップＳＴ２０３］：イベント処理部３０６は、ステップＳＴ２０１で記憶したイベントリストを用いてイベントリスト記憶部３０８を参照し、一致する要素が存在するか確認する。存在する場合、「該当あり」と判断し、ステップＳＴ２０４に進む。存在しない場合、「該当なし」と判断し、ステップＳＴ２０５に進む。
【００２６】
［ステップＳＴ２０４］：イベント処理部３０６は、イベントリスト記憶部３０８に存在した、ステップＳＴ２０１で記憶したイベントリストに一致する要素のＩＤを、イベント処理部３０６の内部に一時的に記憶し、ステップＳＴ２０７に進む。
［ステップＳＴ２０５］：イベント処理部３０６は、ＩＤ管理部３０７に対して、未使用のＩＤの取得を要求する。ＩＤ管理部３０７は、イベントリスト記憶部３０８を参照し、イベントリスト記憶部３０８に存在しないＩＤを決定し、決定したＩＤをイベント処理部３０６に渡す。
［ステップＳＴ２０６］：イベント処理部３０６は、ステップＳＴ２０５でＩＤ管理部３０７から渡されたＩＤと、ステップＳＴ２０１で記憶したイベントリストの組を、イベントリスト記憶部３０８に登録する。
【００２７】
［ステップＳＴ２０７］：イベント処理部３０６は、ステップＳＴ２０２を実行した場合は、ステップＳＴ２０２でイベントリスト記憶部３０８から取得したイベントリストを、イベント処理部３０６の内部に記憶する。なお、それ以外の場合はステップＳＴ２０１で記憶する動作を実行しているため、何もしない。
［ステップＳＴ２０８］：イベント処理部３０６は、通信部３０５を介して、応答メッセージをＧＵＩ装置１００に送信する。応答メッセージには、ステップＳＴ２０１で取得した、もしくはステップＳＴ２０４でＩＤ管理部３０７から渡された、もしくはステップＳＴ２０５でＩＤ管理部３０７から渡されたＩＤを格納する。ただし、ステップＳＴ２０２で「取得失敗」の場合は、無効なＩＤ（ステップＳＴ１０６に合わせると０）を格納する。
［ステップＳＴ２０９］：サービス装置３００は処理を終了する。
【００２８】
図６は、この実施の形態におけるイベント発生時のサービス装置３００の動作を示すフローチャートである。
［ステップＳＴ３００］：サービスＡ３０２もしくはサービスＢ３０３でイベントが発生し、サービス処理部３０１を介してイベント処理部３０６に前記イベントが渡されると、サービス装置３００は処理を開始する。
［ステップＳＴ３０１］：イベント処理部３０６は、サービス処理部３０１から渡されたイベントの名称に基づき、イベント処理部３０６の内部に記憶しているイベントリストに該当するイベントが存在するか確認する。存在する場合は、前記イベントを「通知対象」と判断し、ステップＳＴ３０２に進む。存在しない場合は、前記イベントを「通知対象外」と判断し、前記イベントを破棄して、ステップＳＴ３０３に進む。
［ステップＳＴ３０２］：イベント処理部３０６は、サービス処理部３０１から渡されたイベントを、通信部３０５を介してＧＵＩ装置１００に通知する。
［ステップＳＴ３０３］：サービス装置３００は処理を終了する。
【００２９】
この実施の形態において、サービス装置３００からのイベント通知が発生した場合、ＧＵＩ装置１００は、通信部１０４を介して前記イベントをイベント処理部１０５に渡し、イベント処理部１０５はこのイベントをＧＵＩロジック処理部１０２に渡す。これらの動作の詳細については省略する。
【００３０】
このように、実施の形態１のＧＵＩ装置１００は、ＧＵＩ装置１００が必要とするイベントの一覧（イベントリスト）をサービス装置３００に送信する前に、イベント処理部１０５がイベントリスト記憶部１０６に送信対象イベントリストを一意に特定するＩＤが存在するかを確認し、存在する場合はＩＤを送信する。また、サービス装置３００のイベント処理部３０６は、イベントリストを受信したときに、ＩＤ管理部３０７とイベントリスト記憶部３０８を用いて、イベントリスト記憶部３０８に前記イベントリストに一致する要素がない場合に、ＩＤ管理部３０７から未使用のＩＤを取得し、前記イベントリストと前記ＩＤの組をイベントリスト記憶部３０８に登録し、ＧＵＩ装置１００に前記ＩＤを送信する。また、ＧＵＩ装置１００のイベント処理部１０５は、サービス装置３００から受信したＩＤと、サービス装置に送信しようとしたイベントリストの組を、イベントリスト記憶部１０６に登録する。
【００３１】
また、サービス装置３００のサービス処理部３０１からイベント処理部３０６にイベントが渡されると、イベント処理部３０６は内部に記憶しているイベントリストを用いて、ＧＵＩ装置１００に前記イベントを通知するか否かを判断する。従って、ＧＵＩ装置１００にとって不要なイベントの通知を行わないため、ＧＵＩ装置１００からサービス装置３００への通信量を削減できるという効果がある。
【００３２】
また、イベントリスト記憶部１０６に送信対象イベントリストに該当する要素が存在する場合、イベントリストではなくＩＤをサービス装置３００に送信することで、イベント処理部３０６はＩＤを用いてイベントリストの設定が可能となるため、ＧＵＩ装置１００からサービス装置３００への通信量を削減できるという効果もある。すなわち、一般に、イベントリストのデータ量よりもＩＤのデータ量の方が小さいからである。さらに、サービス装置３００に予めイベントリストとＩＤの対応関係を準備していなくても通信量の削減が可能であるため、イベントリストとＩＤの対応関係の設計および実装に要する費用を削減できるといった効果もある。
【００３３】
また、上記説明ではＩＤの値が０の場合、もしくは応答にＩＤが含まれていない場合、無効なＩＤと判断していたが、他の方法を用いても構わない。
【００３４】
以上説明したように、実施の形態１の通信システムによれば、イベント通知に基づき画面構築を行うＧＵＩ装置と、サービスを実行してイベントを発生するサービス装置とがネットワークを介して接続され、相互に通信を行う通信システムにおいて、ＧＵＩ装置は、イベントの一覧であるイベントリストと、イベントリストを一意に特定するＩＤを格納するＧＵＩ装置側イベントリスト記憶部と、画面構築時に画面に必要なイベントリストをサービス装置に送信すると共に、送信前に、ＧＵＩ装置側イベントリスト記憶部を参照し、送信対象イベントリストと一致するイベントリストが存在する場合は、そのイベントリストを一意に特定するＩＤを取得し、送信対象イベントリストの代わりにＩＤをサービス装置に送信するＧＵＩ装置側イベント処理部とを備え、かつ、ＧＵＩ装置側イベント処理部は、イベントリストまたはＩＤをサービス装置に送信した結果として得られる応答メッセージにＩＤが含まれる場合は、応答メッセージに含まれるＩＤと、サービス装置に対して送信したイベントリスト、または、その代わりにＩＤを送信したイベントリストとを１個の組としてＧＵＩ装置側イベントリスト記憶部に記憶させ、サービス装置は、イベントの一覧であるイベントリストと、イベントリストを一意に特定するＩＤを格納するサービス装置側イベントリスト記憶部と、イベントリストとＩＤとの関係を管理するＩＤ管理部と、サービスを実行し、イベントを発生させるサービス処理部と、ＧＵＩ装置からイベントリストを受信した場合、サービス装置側イベントリスト記憶部を参照し、受信したイベントリストと一致するイベントリストが存在する場合は、そのイベントリストを一意に特定するＩＤを取得し、ＩＤをＧＵＩ装置への応答メッセージに含めて送信し、一方、サービス装置側イベントリスト記憶部を参照した結果、受信したイベントリストと一致するイベントリストが存在しない場合は、ＩＤ管理部からサービス装置側イベントリスト記憶部に登録されていないＩＤを取得して、取得したＩＤと受信したイベントリストとを１個の組として、サービス装置側イベントリスト記憶部に登録し、取得したＩＤをＧＵＩ装置への応答メッセージに含めて送信し、ＧＵＩ装置からＩＤを受信した場合は、サービス装置側イベントリスト記憶部を参照し、受信したＩＤと一致するイベントリストが存在する場合は、受信したＩＤをＧＵＩ装置への応答メッセージに含めて送信するイベント処理部とを備え、かつ、サービス装置側イベント処理部は、サービス処理部のサービスによって発生するイベントに対して、イベントが含まれるイベントリストがＧＵＩ装置への通知対象となっているかを判定し、通知対象となっている場合にのみ、イベントをＧＵＩ装置に通知するようにしたので、ＧＵＩ装置とサービス装置間の通信量を削減し、かつ、イベントのパターン変更にも柔軟に対処することができる。
【００３５】
実施の形態２．
実施の形態１では、イベントリスト記憶部１０６およびイベントリスト記憶部３０８に対するイベントリストとＩＤの組の登録について説明したが、実施の形態２では、イベントリスト記憶部３０８に設けられた記憶容量の制限に対応することで、サービス装置３００のリソース使用効率を改善するようにした例を説明する。
【００３６】
この発明の実施の形態２における通信システムの全体構成を図７に示す。
通信システムは、実施の形態１と同様に、ＧＵＩ装置１００ａとサービス装置３００ａがネットワーク２００を介して接続された構成となっている。
ＧＵＩ装置１００ａは、表示部１０１、ＧＵＩロジック処理部１０２、要求処理部１０３、通信部１０４、イベント処理部（ＧＵＩ装置側イベント処理部）１０５ａ、イベントリスト記憶部（ＧＵＩ装置側イベントリスト記憶部）１０６、インターフェース部１０７を備える。ここで、表示部１０１、ＧＵＩロジック処理部１０２、要求処理部１０３、通信部１０４、イベントリスト記憶部１０６、インターフェース部１０７については、実施の形態１と同様の構成であるため、ここでの説明は省略する。
【００３７】
イベント処理部１０５ａは、ＧＵＩ装置１００ａにおけるイベントに関する処理を担当する装置であり、実施の形態１におけるイベント処理部１０５に対して、イベントリスト記憶部１０６に対するイベントリストとＩＤの組で構成される要素を削除する機能を追加したものである。
【００３８】
サービス装置３００ａは、サービス処理部３０１、要求処理部３０４、通信部３０５、イベント処理部（サービス装置側イベント処理部）３０６ａ、ＩＤ管理部３０７、イベントリスト記憶部（サービス装置側イベントリスト記憶部）３０８を備える。ここで、サービス処理部３０１、要求処理部３０４、通信部３０５、ＩＤ管理部３０７については、実施の形態１と同様の構成であるため、ここでの説明は省略する。なお、イベントリスト記憶部３０８については、登録可能なデータサイズという情報が追加されているが、これについては図示しない。
【００３９】
イベント処理部３０６ａは、サービス装置３００ａにおけるイベントに関する処理を担当する装置であり、実施の形態１におけるイベント処理部３０６に対して、イベントリスト記憶部３０８に対するイベントリストとＩＤの組で構成される要素を削除する機能を追加したものである。
【００４０】
図８は、ＧＵＩ装置１００ａからのイベントリスト登録の要求に対して、サービス装置３００ａからＧＵＩ装置１００ａへ送信する応答メッセージに含まれる登録結果６００の構成を示した図である。登録結果６００は、登録したイベントリストを一意に特定するＩＤ５００と、削除したＩＤの列を格納する削除ＩＤリスト６１０を備える。例えば、図８では、削除ＩＤリスト６１０が２個のＩＤ（値は２０、３０）を格納している。なお、削除ＩＤリスト６１０の終端は、要素数もしくは終端を意味する要素により認識可能だが、図８では省略している。
【００４１】
次に、ＧＵＩ装置１００ａとサービス装置３００ａの動作について、図７、図８、図９、図１０を用いて説明する。
図９は、この実施の形態におけるイベントリスト登録時のＧＵＩ装置１００ａの動作を示すフローチャートである。
ステップＳＴ１００、ステップＳＴ１０１、ステップＳＴ１０２、ステップＳＴ１０３、ステップＳＴ１０４、ステップＳＴ１０５、ステップＳＴ１０６、ステップＳＴ１０７、ステップＳＴ１０８においては、ステップＳＴ１０５の次に実行するがステップＳＴ１０９に変更になることと、通信相手がサービス装置３００からサービス装置３００ａに変更になることを除き、実施の形態１におけるイベント処理部１０５と実施の形態２におけるイベント処理部１０５ａの動作に違いはない。そのため、ここではこれらステップの説明は省略する。
【００４２】
［ステップＳＴ１０９］：イベント処理部１０５ａは、ステップＳＴ１０５で受信した応答に含まれる削除ＩＤリスト６１０を先頭から順番に参照し、イベントリスト記憶部１０６から各ＩＤを含む要素を削除する。図８の例では、ＩＤが２０と３０の要素をイベントリスト記憶部１０６から削除することになる。また、イベント処理部１０５ａは、ＩＤリスト６１０の終端に到達すると、ステップＳＴ１０６に進む。
【００４３】
図１０は、この実施の形態におけるイベントリスト登録時のサービス装置３００ａの動作を示すフローチャートである。
ステップＳＴ２００、ステップＳＴ２０１、ステップＳＴ２０２、ステップＳＴ２０３、ステップＳＴ２０４、ステップＳＴ２０５、ステップＳＴ２０６、ステップＳＴ２０７、ステップＳＴ２０９においては、ステップＳＴ２０３の次にステップＳＴ２０５を実行する場合は、その前にステップＳＴ２１０を実行すること、およびステップＳＴ２０８の代わりにステップＳＴ２０８ａを実行することと、通信相手がＧＵＩ装置１００からＧＵＩ装置１００ａに変更になることを除き、実施の形態１におけるイベント処理部３０６と実施の形態２におけるイベント処理部３０６ａの動作に違いはない。そのため、ここではこれらステップの説明を省略する。
【００４４】
［ステップＳＴ２１０］：イベント処理部３０６ａは、（ア）ステップＳＴ２０１で記憶したイベントリストのサイズ＋ＩＤのサイズ、（イ）イベントリスト記憶部３０８に登録されている各要素のサイズ、（ウ）イベントリスト記憶部３０８に登録可能なデータサイズ、を用いて、（ア）＋（イ）＞（ウ）が成立する場合は、イベントリスト記憶部３０８に登録されている１個以上の要素を削除し、前記の不等式が成立しないようにする。削除する要素の選択基準としては、例えば、（ア）より大きいサイズの中で最小のもの、登録時刻が最も古いものから順番に、イベントリストやＩＤを用いた検索で該当した回数が少ないものから順番に、など様々なものが挙げられるが、目的を達成できるものであれば、任意の基準でよい。前記の不等式が成立しない状態になると、ステップＳＴ２０５に進む。
【００４５】
［ステップＳＴ２０８ａ］：イベント処理部３０６ａは、通信部３０５を介して応答メッセージをＧＵＩ装置１００に送信する。応答メッセージには、登録結果６００を格納する。ＩＤ５００には、ステップＳＴ２０１で取得した、もしくはステップＳＴ２０４でＩＤ管理部３０７から渡された、もしくはステップＳＴ２０５でＩＤ管理部３０７から渡されたＩＤを格納する。また、削除ＩＤリスト６１０には、ステップＳＴ２１０で削除した要素の０個以上のＩＤを格納する（０個の場合は、終端を意味する値のみを格納する）。ただし、ステップＳＴ２０２で「取得失敗」の場合は、ＩＤ５００には無効なＩＤを設定し、削除ＩＤリスト６１０は空にする。
【００４６】
この実施の形態におけるイベント発生時のサービス装置３００ａの動作は、実施の形態１と同様であるため、ここでは説明を省略する。
また、この実施の形態において、サービス装置３００ａからのイベント通知が発生した場合のＧＵＩ装置１００ａの動作については、実施の形態１と同様であるため、ここでは説明を省略する（ＧＵＩ装置１００、サービス装置３００、イベント処理部１０５は、それぞれＧＵＩ装置１００ａ、サービス装置３００ａ、イベント処理部１０５ａと読み替える）。
【００４７】
このように、実施の形態２のサービス装置３００ａは、新たなイベントリストをイベントリスト記憶部３０８に登録するとき、イベントリスト記憶部３０８に登録可能なデータサイズという制限を満たすように、イベントリスト記憶部３０８から要素を削除し、ＧＵＩ装置１００ａは、その削除結果として作成される削除ＩＤリスト６１０をサービス装置３００ａから受け取り、イベントリスト記憶部１０６から該当する要素を削除する。したがって、イベントリスト記憶部３０８に登録したデータのサイズが肥大化することにより発生し得るリソース不足（例えば、メモリ枯渇）を回避できるといった効果がある。また、イベントリスト記憶部３０８に登録したデータサイズに制限を設けることにより、イベントリスト記憶部３０８に対する処理に要する時間の上限を抑えることができるといった効果もある。さらに、ＧＵＩ装置１００ａにも削除した要素のＩＤを提供するため、ＧＵＩ装置１００ａから指定されたＩＤに対応する要素がイベントリスト記憶部３０８に存在しないといった現象が発生しなくなり、ＧＵＩ装置１００ａとサービス装置３００ａ間の無駄な通信を削減できるといった効果もある。
【００４８】
なお、この実施の形態では、サービス装置３００ａにおける、イベントリスト記憶部３０８に登録可能なデータサイズという制限への対応について説明したが、ＧＵＩ装置１００ａについても、同様の手順を適用することにより、イベントリスト記憶部１０６に登録可能なデータサイズという制限に対応可能である。すなわち、イベント処理部１０５ａは、イベントリストまたはＩＤをサービス装置３００ａに送信した結果として得られる応答メッセージにＩＤが含まれる場合、イベントリスト記憶部１０６に登録可能なデータサイズを超えるかを判定し、超える場合は、超えない状態になるように、イベントリスト記憶部１０６に登録済みのイベントリストとＩＤとの組を１個以上削除し、その状態で、応答メッセージに含まれるＩＤと、ＧＵＩ装置１００ａが送信したイベントリスト、またはその代わりにＩＤを送信したイベントリストとを１個の組として、イベントリスト記憶部１０６に登録するようにしてもよい。
【００４９】
以上説明したように、実施の形態２の通信システムによれば、サービス装置側イベント処理部は、ＧＵＩ装置から受信したイベントリストと、イベントリストを一意に特定するＩＤの組をサービス装置側イベントリスト記憶部に登録する前に、サービス装置側イベントリスト記憶部に登録可能なデータサイズを超えるかを判定し、超える場合は、超えない状態になるように、サービス装置側イベントリスト記憶部に登録済みのイベントリストとＩＤとの組を削除し、その状態で、ＧＵＩ装置から受信したイベントリストとイベントリストを一意に特定するＩＤの組をサービス装置側イベントリスト記憶部に登録し、一方、削除したイベントリストを一意に特定するＩＤをＧＵＩ装置への応答メッセージに含めて送信し、ＧＵＩ装置側イベント処理部は、イベントリストまたはＩＤをサービス装置に送信した結果として得られる応答メッセージにサービス装置側イベントリスト記憶部で削除されたＩＤが含まれる場合は、削除されたＩＤに対応したイベントリストをＧＵＩ装置側イベントリスト記憶部から削除するようにしたので、サービス装置側のリソース不足を抑制することができると共に、ＧＵＩ装置とサービス装置間の無駄な通信を削減することができる。
【００５０】
また、実施の形態２の通信システムによれば、ＧＵＩ装置側イベント処理部は、イベントリストまたはＩＤをサービス装置に送信した結果として得られる応答メッセージにＩＤが含まれる場合、ＧＵＩ装置側イベントリスト記憶部に登録可能なデータサイズを超えるかを判定し、超える場合は、超えない状態になるように、ＧＵＩ装置側イベントリスト記憶部に登録済みのイベントリストとＩＤとの組を削除し、その状態で、応答メッセージに含まれるＩＤと、ＧＵＩ装置が送信したイベントリスト、またはその代わりにＩＤを送信したイベントリストとを１個の組として、ＧＵＩ装置側イベントリスト記憶部に登録するようにしたので、ＧＵＩ装置側のリソース不足を抑制することができる。
【００５１】
実施の形態３．
実施の形態１や実施の形態２では、ＧＵＩ装置１００（ＧＵＩ装置１００ａ）からサービス装置３００（サービス装置３００ａ）に対してイベントリストの登録を要求する場合は、イベントリストそのものか、イベントリストを一意に特定するＩＤのいずれかを送信していた。ここで、送信対象のイベントリストと、イベントリスト記憶部１０６に登録されているイベントリストとの違いが少ない場合（例えばイベントを１個追加した）、イベントリスト全体を送信することは非効率である。そこで、実施の形態３では、登録済みのイベントリストとの差分を用いることで、イベントリストそのものを送信する場合よりも通信量を削減する。
【００５２】
この発明の実施の形態３におけるシステム全体の構成を図１１に示す。
システムはＧＵＩ装置１００ｂとサービス装置３００ｂがネットワーク２００を介して接続した構成となっている。
【００５３】
ＧＵＩ装置１００ｂは、表示部１０１、ＧＵＩロジック処理部１０２ｂ、要求処理部１０３、通信部１０４、イベント処理部（ＧＵＩ装置側イベント処理部）１０５ｂ、イベントリスト記憶部（ＧＵＩ装置側イベントリスト記憶部）１０６、インターフェース部１０７を備える。表示部１０１、ＧＵＩロジック処理部１０２ｂ、要求処理部１０３、通信部１０４、イベントリスト記憶部１０６、インターフェース部１０７については、実施の形態１と同様の構成であるため、ここでの説明は省略する。
【００５４】
イベント処理部１０５ｂは、ＧＵＩ装置１００ｂにおけるイベントに関する処理を担当する装置であり、実施の形態１におけるイベント処理部１０５に対して、ＩＤとイベントリストの差分を用いたイベントリストの登録をサービス装置３００ｂに要求する機能を追加したものである。
【００５５】
サービス装置３００ｂは、サービス処理部３０１、要求処理部３０４、通信部３０５、イベント処理部（サービス装置側イベント処理部）３０６ｂ、ＩＤ管理部３０７、イベントリスト記憶部（サービス装置側イベントリスト記憶部）３０８を備える。サービス処理部３０１、要求処理部３０４、通信部３０５、ＩＤ管理部３０７、イベントリスト記憶部３０８については、実施の形態１と同様の構成であるため、ここでの説明は省略する。
【００５６】
イベント処理部３０６ｂは、サービス装置３００ｂにおけるイベントに関する処理を担当する装置であり、実施の形態１におけるイベント処理部３０６に対して、ＩＤとイベントリストの差分を用いてイベントリストを登録する機能を追加したものである。
【００５７】
図１２は、ＧＵＩ装置１００ｂがＩＤとイベントリストの差分を用いてサービス装置３００ｂにイベントリストの登録を要求する場合に送信するイベントリスト登録要求７００の構成を示した図である。イベントリスト登録要求７００は、ＩＤ５００とイベント差分リスト７１０を備える。イベント差分リスト７１０は、操作種別７１１とイベント名７１２の組で構成される要素の列を備える。図１２では、（操作種別７１１ｘ、イベント名７１２ｘ）、（操作種別７１１ｙ、イベント名７１２ｙ）の２要素が格納されている。また、操作種別７１１ｘの「ＡＤＤ」は基準となるイベントリストにイベント名７１２ｘを追加すること、操作種別７１１ｙの「ＤＥＬ」は基準となるイベントリストからイベント名７１２ｙを削除することを意味する。なお、イベント差分リスト７１０の終端は、要素数もしくは終端を意味する要素により認識可能だが、図１２では省略している。
【００５８】
次に、ＧＵＩ装置１００ｂとサービス装置３００ｂの動作について、図３、図１１、図１２、図１３、図１４を用いて説明する。
図１３は、この実施の形態におけるイベントリスト登録時のＧＵＩ装置１００ｂの動作を示すフローチャートである。
ステップＳＴ１００、ステップＳＴ１０１、ステップＳＴ１０２、ステップＳＴ１０３、ステップＳＴ１０４、ステップＳＴ１０５、ステップＳＴ１０６、ステップＳＴ１０７、ステップＳＴ１０８においては、ステップＳＴ１０２で未登録と判断した場合の次の処理がステップＳＴ１１０に変更になることと、通信相手がサービス装置３００からサービス装置３００ｂに変更になることを除き、実施の形態１のイベント処理部１０５と実施の形態３のイベント処理部１０５ｂの動作に違いはない。そのため、ここではこれらステップの説明を省略する。
【００５９】
［ステップＳＴ１１０］：イベント処理部１０５ｂは、ステップＳＴ１０１で内部に一時的に記憶したイベントリストと、イベントリスト記憶部１０６に登録された各要素のイベントリストを用いて、イベント差分リスト７１０を生成し、その中で要素数が最も小さいものを選択する。同時に、イベント処理部１０５ｂは、前記イベント差分リスト７１０の生成に用いたイベントリストを一意に特定するＩＤを、イベントリスト記憶部１０６から取得する。例えば、図３のイベントリスト４００ＡとＩＤ５００Ａのみがイベントリスト記憶部１０６に登録されており、今回送信しようとしているイベントリストが「ＳｅｒｖｉｃｅＡ＿ＥｖｅｎｔＢ」「ＳｅｒｖｉｃｅＡ＿ＥｖｅｎｔＣ」「ＳｅｒｖｉｃｅＡ＿ＥｖｅｎｔＰ」「ＳｅｒｖｉｃｅＢ＿ＥｖｅｎｔＸ」という構成の場合、生成されるイベント差分リストは７１０のようになり、ＩＤ５００の値は１０となる。なお、イベント差分リスト７１０における操作種別７１１ｘの「ＡＤＤ」とイベント名７１２ｘの「ＳｅｒｖｉｃｅＡ＿ＥｖｅｎｔＰ」は、イベントリストに「ＳｅｒｖｉｃｅＡ＿ＥｖｅｎｔＰ」を追加することを示し、操作種別７１１ｙの「ＤＥＬ」とイベント名７１２ｙの「ＳｅｒｖｉｃｅＡ＿ＥｖｅｎｔＡ」は、イベントリストから「ＳｅｒｖｉｃｅＡ＿ＥｖｅｎｔＡ」を削除することを示している。
【００６０】
［ステップＳＴ１１１］：イベント処理部１０５ｂは、ステップＳＴ１０１で内部に一時的に記憶したイベントリストの情報量である要素数と、ステップＳＴ１１０で生成したイベント差分リスト７１０の情報量である要素数とを比較する。一時的に記憶したイベントリストの要素数の方が大きい場合は、「差分＜元のリスト」と判断し、ステップＳＴ１１２に進む。それ以外の場合は、「差分≧元のリスト」と判断し、ステップＳＴ１０３に進む。なお、イベントリスト記憶部１０６に何も登録されていない場合は、無条件でステップＳＴ１０３に進む。
【００６１】
［ステップＳＴ１１２］：イベント処理部１０５ｂは、ステップＳＴ１１０で得たイベント差分リスト７１０と、このイベント差分リスト７１０の生成に用いたイベントリストを一意に特定するＩＤとを用いて、イベントリスト登録要求７００を生成し、通信部１０４を介して、サービス装置３００にイベントリスト登録要求７００を送信する。
【００６２】
図１４は、この実施の形態におけるイベントリスト登録時のサービス装置３００ｂの動作を示すフローチャートである。
ステップＳＴ２００、ステップＳＴ２０２、ステップＳＴ２０４、ステップＳＴ２０５、ステップＳＴ２０６、ステップＳＴ２０７、ステップＳＴ２０９においては、通信相手がＧＵＩ装置１００からＧＵＩ装置１００ｂに変更になることを除いて、実施の形態１のイベント処理部３０６と実施の形態３のイベント処理部３０６ａの動作に違いはない。そのため、ここではこれらステップの説明を省略する。
【００６３】
［ステップＳＴ２０１ａ］：通信部３０５はイベント処理部３０６ｂに受信データを渡す。イベント処理部３０６ｂは、受信データの種類（ＩＤ、イベントリスト、ＩＤ＋差分）を判定する。ＩＤの場合は、イベント処理部３０６ｂが受信データに含まれるＩＤを記憶し、ステップＳＴ２０２に進む。イベントリストの場合は、イベント処理部３０６ｂが受信データに含まれるイベントリストを記憶し、ステップＳＴ２０３ａに進む。ＩＤ＋差分の場合は、ステップＳＴ２１１に進む。
【００６４】
［ステップＳＴ２１１］：イベント処理部３０６ｂは、ＩＤ管理部３０７に、受信データに含まれるＩＤを渡し、検索を要求する。ＩＤ管理部３０７は、前記ＩＤを用いて、イベントリスト記憶部３０８に一致する要素が登録されているか検索する。ここで、該当する要素を発見しなかった場合、イベント処理部３０６ｂは「生成失敗」と判断し、ステップＳＴ２０８ｂに進む。該当する要素を発見した場合、ＩＤ管理部３０７は、発見した要素に含まれるイベントリストをイベント処理部３０６ｂに渡し、イベント処理部３０６ｂは、前記イベントリストと、受信データ含まれるイベント差分リスト７１０を用いて、登録対象となるイベントリストを生成する。具体的には、ＩＤ管理部３０７から渡されたイベントリストに対して、操作種別７１１が「ＡＤＤ」となっている要素のイベント名７１２を追加し、操作種別７１１が「ＤＥＬ」となっている要素のイベント名７１２を削除する。その後、イベント処理部３０６ｂは、生成したイベントリストを内部に記憶し、「生成成功」と判断し、ステップＳＴ２０３ａに進む。
【００６５】
［ステップＳＴ２０３ａ］：イベント処理部３０６ｂは、ステップＳＴ２０１もしくはステップＳＴ２１１で記憶したイベントリストを用いてイベントリスト記憶部３０８を参照し、一致する要素が存在するか確認する。存在する場合、「該当あり」と判断し、ステップＳＴ２０４に進む。存在しない場合、「該当なし」と判断し、ステップＳＴ２０５に進む。
［ステップＳＴ２０８ｂ］：イベント処理部３０６ｂは、通信部３０５を介して、応答メッセージをＧＵＩ装置１００に送信する。応答メッセージには、ステップＳＴ２０１で取得した、もしくはステップＳＴ２０４でＩＤ管理部３０７から渡された、もしくはステップＳＴ２０５でＩＤ管理部３０７から渡されたＩＤを格納する。ただし、ステップＳＴ２０２で「取得失敗」の場合、もしくはステップＳＴ２１１で「生成失敗」の場合は、無効なＩＤを格納する。
【００６６】
この実施の形態におけるイベント発生時のサービス装置３００ｂの動作は、実施の形態１と同様であるため、ここでは説明を省略する。
【００６７】
また、この実施の形態において、サービス装置３００ｂからのイベント通知が発生した場合のＧＵＩ装置１００ｂの動作については、実施の形態１と同様であるため、ここでは説明を省略する（ＧＵＩ装置１００、サービス装置３００、イベント処理部１０５は、それぞれＧＵＩ装置１００ｂ、サービス装置３００ｂ、イベント処理部１０５ｂと読み替える）。
【００６８】
このように、実施の形態３のＧＵＩ装置１００ｂは、イベントリストをサービス装置３００ｂに送信する前に、イベントリスト記憶部１０６に登録されたイベントリストを用いて差分を生成し、差分のサイズが小さい場合、差分の生成に用いたイベントリストを一意に特定するＩＤと、生成した差分をサービス装置３００ｂに送信し、サービス装置３００ｂは、受信したＩＤと差分とイベントリスト記憶部３０８に格納されたイベントリストを用いて、登録対象のイベントリストを生成する。従って、イベントリストそのものを送信する場合より、通信量を削減できるといった効果がある。
【００６９】
また、この実施の形態の説明では、イベントリストの差分における要素数を基準に情報量が最小となるものを選択したが、例えばデータサイズを情報量の基準としても構わない。
【００７０】
なお、この実施の形態の説明では操作種別７１１に「ＡＤＤ」「ＤＥＬ」などの文字列を設定したが、数値で表現しても、この実施の形態により得られる効果は変わらない。
また、この実施の形態では、実施の形態１におけるＧＵＩ装置１００、サービス装置３００に対して追加した手順を説明したが、実施の形態２におけるＧＵＩ装置１００ａ、サービス装置３００ａに対しても同様の手順を追加することにより、この実施の形態の効果が得られることは言うまでもない。
【００７１】
以上説明したように、実施の形態３の通信システムによれば、ＧＵＩ装置側イベント処理部は、ＧＵＩ装置側イベントリスト記憶部に登録されていないイベントリストをサービス装置に送信する場合、送信対象イベントリストと、ＧＵＩ装置側イベントリスト記憶部に登録済みのイベントリストとの差分を生成し、生成した差分を示す情報量が、送信対象イベントリストの情報量よりも小さい場合は、送信対象イベントリストの代わりに、生成した差分と、差分を生成するために用いたＧＵＩ装置側イベントリスト記憶部に登録済みのイベントリストを一意に特定するＩＤとをサービス装置に送信し、サービス装置側イベント処理部は、ＧＵＩ装置からＩＤと差分を受信した場合、ＩＤを用いてサービス装置側イベントリスト記憶部からイベントリストを取得し、取得したイベントリストと差分を用いて新たなイベントリストを生成し、生成した新たなイベントリストをＧＵＩ装置から受信したイベントリストに代えて処理を行うようにしたので、さらにＧＵＩ装置とサービスサービス装置間の通信量を削減することができる。
【００７２】
実施の形態４．
実施の形態１〜３では、サービス装置３００（サービス装置３００ａ、サービス装置３００ｂ）で発生したイベントは、イベント処理部３０６（イベント処理部３０６ａ、イベント処理部３０６ｂ）における通知判定を行った後、直ぐにＧＵＩ装置１００（ＧＵＩ装置１００ａ、ＧＵＩ装置１００ｂ）に通知する動作としていた。イベントの発生周期や頻度は、発生元であるサービス装置の仕様により定められることが多いが、ＧＵＩ装置の仕様によっては、サービスの仕様によりも長い周期や少ない頻度の通知とすることが望ましい場合がある。しかし、ＧＵＩ装置の都合でサービス装置の仕様を変更することは望ましくない。そこで、実施の形態４では、ＧＵＩ装置からイベント毎に通知周期を設定する仕組みを追加することにより、サービス装置の仕様を変更することなく、通知周期を変更できるようにする。また、同じ通知周期のイベントをまとめて通知することで、サービス装置とＧＵＩ装置間の通信回数を削減する。
【００７３】
この発明の実施の形態４におけるシステム全体の構成を図１５に示す。
システムはＧＵＩ装置１００ｃとサービス装置３００ｃがネットワーク２００を介して接続した構成となっている。
【００７４】
ＧＵＩ装置１００ｃは、表示部１０１、ＧＵＩロジック処理部１０２ｃ、要求処理部１０３、通信部１０４、イベント処理部（ＧＵＩ装置側イベント処理部）１０５ｃ、イベントリスト記憶部１０６、インターフェース部１０７を備える。表示部１０１、要求処理部１０３、通信部１０４、イベントリスト記憶部１０６、インターフェース部１０７については、実施の形態１と同様の構成であるため、ここでの説明は省略する。
【００７５】
ＧＵＩロジック処理部１０２ｃは、表示部１０１に表示するＧＵＩを構築したり、インターフェース部１０７との入出力を担当したりする装置である。また、ＧＵＩロジック処理部１０２ｃは、要求処理部１０３を介してサービス装置３００に要求を発行したり、イベント処理部１０５ｃから通知されたイベントに基づき表示部１０１に表示するＧＵＩを変更したり、インターフェース部１０７を介してＧＵＩ以外の出力を行ったりする。ＧＵＩロジック処理部１０２ｃは、イベント処理部１０５ｃに対して、各画面に必要なイベントをイベント処理部１０５ｃに提供するとき、各イベントの通知周期も併せて提供する。
イベント処理部１０５ｃは、ＧＵＩ装置１００ｃにおけるイベントに関する処理を担当する装置であり、実施の形態１におけるイベント処理部１０５に対して、イベント毎の通知周期を設定する機能と、複数のイベントを含む通知に対応する機能を追加したものである。
【００７６】
サービス装置３００ｃは、サービス処理部３０１、要求処理部３０４、通信部３０５、イベント処理部（サービス装置側イベント処理部）３０６ｃ、ＩＤ管理部３０７、イベントリスト記憶部３０８、イベント蓄積部３０９を備える。サービス処理部３０１、要求処理部３０４、通信部３０５、ＩＤ管理部３０７については、実施の形態１と同様の構成であるため、ここでの説明は省略する。
イベント処理部３０６ｃは、サービス装置３００ｃにおけるイベントに関する処理を担当する装置であり、実施の形態１におけるイベント処理部３０６に対して、イベントの通知周期を設定する機能と、複数のイベントをまとめて通知する機能を追加したものである。イベント蓄積部３０９は、通知対象のイベントを一時的に記憶するための装置である。
【００７７】
図１６は、この実施の形態におけるイベントリスト８００の構成を示す図である。イベントリスト８００は、イベント名８１１と通知周期８１２の組を一要素とした場合、０個以上の要素を格納する。図１６の例では、（イベント名８１１ｐと通知周期８１２ｐの組）〜（イベント名８１１ｓと通知周期８１２ｓ）の組の４組が格納されている。なお、イベントリスト８００の終端は、要素数もしくは終端を意味する要素により認識可能だが、図１６では省略している。
【００７８】
次に、ＧＵＩ装置１００ｃとサービス装置３００ｃの動作について、図１５、図１６、図１７、図１８、図１９、図２０を用いて説明する。
図１７は、この実施の形態におけるイベントリスト登録時のＧＵＩ装置１００ｃの動作を示すフローチャートである。
ステップＳＴ１００、ステップＳＴ１０４、ステップＳＴ１０５、ステップＳＴ１０６、ステップＳＴ１０８においては、イベントリスト４００がイベントリスト８００に変更になることと、通信相手がサービス装置３００からサービス装置３００ｃに変更になることを除き、実施の形態１のイベント処理部１０５と実施の形態４のイベント処理部１０５ｃの動作に違いはない。そのため、ここでは実施の形態１と同様のステップについてはその説明を省略する。
【００７９】
［ステップＳＴ１０１ａ］：ＧＵＩロジック処理部１０２ｃは、遷移後の画面で必要なイベントと通知周期をイベント処理部１０５ｃに提供する。イベント処理部１０５ｃは、ＧＵＩロジック処理部１０２ｃから提供された０個以上のイベントと通知周期の組を用いてイベントリスト８００を作成し、内部に一時的に記憶する。
［ステップＳＴ１０２ａ］：イベント処理部１０５ｃは、ステップＳＴ１０１ａで内部に一時的に記憶したイベントリスト８００を用いて、イベントリスト記憶部１０６にイベントリスト８００に一致する要素が登録されているかを検索する。「未登録」の場合は、ステップＳＴ１０３ａに進む。「登録済」の場合は、該当する要素に記憶されているＩＤを取得し、ステップＳＴ１０４に進む。
［ステップＳＴ１０３ａ］：イベント処理部１０５ｃは、通信部１０４を介して、サービス装置３００ｃにイベントリスト８００を送信する。
［ステップＳＴ１０７ａ］：イベント処理部１０５ｃは、ステップＳＴ１０５で受信したＩＤとステップＳＴ１０１ａで内部に一時的に記憶したイベントリスト８００の組を、イベントリスト記憶部１０６に登録する。
【００８０】
図１８は、この実施の形態におけるイベントリスト登録時のサービス装置３００ｃの動作を示すフローチャートである。
ステップＳＴ２００、ステップＳＴ２０１、ステップＳＴ２０２、ステップＳＴ２０４、ステップＳＴ２０５、ステップＳＴ２０６、ステップＳＴ２０７、ステップＳＴ２０８、ステップＳＴ２０９においては、通信相手がＧＵＩ装置１００からＧＵＩ装置１００ｃに変更になることを除き、実施の形態１のイベント処理部３０６と実施の形態４のイベント処理部３０６ｃの動作に違いはない。そのため、ここではこれらのステップの説明を省略する。
【００８１】
［ステップＳＴ２０３ｂ］：イベント処理部３０６ｃは、ステップＳＴ２０１で記憶したイベントリストを用いてイベントリスト記憶部３０８を参照し、一致する要素が存在するか確認する。存在する場合、「該当あり」と判断し、ステップＳＴ２０４に進む。存在しない場合、「該当なし」と判断し、ステップＳＴ２０５に進む。なお、実施の形態１におけるステップＳＴ２０３との違いは、イベントリストの一致判定に、通知周期も用いることである。
［ステップＳＴ２１２］：イベント処理部３０６ｃは、まずイベント蓄積部３０９に存在するイベントキューをすべてクリアする。各イベントキューには通知周期を設定できる（後述する図２０に示す）が、その設定もクリアする。次に、イベント処理部３０６ｃは、内部に記憶したイベントリストの各要素の通知周期を参照し、イベント蓄積部３０９にその周期向けのイベントキューが存在するか確認し、存在しない場合はイベント蓄積部３０９にイベントキューを生成するか、もしくは通知周期が未設定のイベントキューに通知周期を設定する。なお、周期が０ｍｓの場合は、イベントキューへの蓄積は行わないため、イベントキューを生成しない。最後に、イベント処理部３０６ｃは、通知周期を設定したイベントキュー毎に、通知周期毎に発火する（通知周期毎に通知のためのトリガを発生させる）タイマを準備し、開始する。
【００８２】
図１９は、この実施の形態におけるイベント発生時のサービス装置３００ｃの動作を示すフローチャートである。
ステップＳＴ３００、ステップＳＴ３０１、ステップＳＴ３０２、ステップＳＴ３０３においては、ステップＳＴ３０１で「通知対象」と判断した場合に次の処理がステップＳＴ３０４になることと、通信相手がサービス装置３００からサービス装置３００ｃに変更になることを除き、実施の形態１のイベント処理部３０６と実施の形態４のイベント処理部３０６ｃの動作に違いはない。そのため、ここではこれらのステップの説明を省略する。
【００８３】
［ステップＳＴ３０４］：イベント処理部３０６ｃは、サービス処理部３０１から渡されたイベントの名称に基づき、内部に記憶しているイベントリストから、前記イベントの通知周期を取得し、０ｍｓの場合はステップＳＴ３０２に進む。０ｍｓ以外の場合、ステップＳＴ３０５に進む。
［ステップＳＴ３０５］：イベント処理部３０６ｃは、ステップＳＴ３０４で取得した周期を用いて、イベント蓄積部３０９から該当するイベントキューを特定し、サービス処理部３０１から渡されたイベントを格納する。
【００８４】
図２０は、イベントキューとタイマとの関係を示す説明図である。
図示例では、イベントキュー３１０ａには、ＳｅｒｖｉｃｅＢ＿ＥｖｅｎｔＸが２個格納され、イベントキュー３１０ｂには、ＳｅｒｖｉｃｅＡ＿ＥｖｅｎｔＣが２個、ＳｅｒｖｉｃｅＡ＿ＥｖｅｎｔＡが１個格納されている。また、イベントキュー３１０ａは２００ｍｓ毎に発火するタイマ３１１ａが、イベントキュー３１０ｂには１００ｍｓ毎に発火するタイマ３１１ｂがそれぞれ対応付けられている。
【００８５】
このようにイベントキューとタイマが関連付けられた状態で、いずれかのタイマが発火した場合、イベント処理部３０６ｃは、発火したタイマに対応するイベントキューからイベントをすべて取り出し、通信部３０５を介してＧＵＩ装置１００ｃに通知する。その後、イベントキューに設定された周期を用いて、タイマを開始する。すなわち、タイマは発火が終了するとその後は動作を行わないため、再度タイマを開始させ、イベントキューからイベントを取り出し通知するという動作を周期的に行う。なお、イベントキュー３１０が空の場合は、通知を行わない。これらの動作については図示しない。
【００８６】
サービス装置３００ｃから複数のイベントが通知され、このような複数のイベントが含まれた通知がＧＵＩ装置１００ｃに届いた場合、通信部１０４は受信した内容をイベント処理部１０５ｃに渡し、イベント処理部１０５ｃは受信した内容に含まれる個々のイベントをＧＵＩロジック処理部１０２ｃに渡す。これらの動作については図示しない。
【００８７】
このように、実施の形態４のＧＵＩ装置１００ｃは、各イベントの通知周期を含むイベントリストをサービス装置３００ｃに送信し、サービス装置３００ｃは受信したイベントリストに含まれる通知周期に基づきイベントキューを設けてタイマを開始し、イベント発生時はイベント毎の通知周期に基づきイベントキューにイベントを蓄積し、タイマが発火した場合はイベントキューに蓄積されたイベントをまとめて通知し、複数のイベントが格納された通知を受信したＧＵＩ装置１００ｃは、各イベントをＧＵＩロジック処理部１０２ｃに渡す。従って、イベント発生毎に通知する場合と比べて、通知回数を削減できるといった効果がある。
【００８８】
また、上記説明では通知対象のイベントであれば、常にイベントキューに蓄積するとしたが、ＧＵＩ装置に対して同じイベントを複数個通知する必要はない場合が多い。そこで、ステップＳＴ３０５の動作に先立って、蓄積対象のイベントキューを走査し、同じイベントが蓄積されている場合は、イベントの蓄積を行わないようにしても構わない。この動作を図２１に示す。ここで、ステップＳＴ３０６におけるイベント存在確認のステップ以外のステップは図１９に示す各ステップと同様であるため、ステップＳＴ３０６についてのみ説明する。
［ステップＳＴ３０６］：イベント処理部３０６ｃは、ステップＳＴ３０４の周期確認において、周期が０ｍｓ以外であった場合、同じイベントがイベントキューに蓄積されているか否かを確認する。蓄積済みであった場合は、そのままステップＳＴ３０３に移行して終了し、蓄積されていない場合はステップＳＴ３０５に移行する。これにより、設定された周期毎に通知されるイベントの個数を削減できるといった効果がある。
【００８９】
また、イベントキューに同じイベントが蓄積されている場合、蓄積されているイベントを削除し、改めて蓄積対象イベントをイベントキューに追加しても構わない。この動作を図２２に示す。ここで、ステップＳＴ３０７におけるイベント削除のステップ以外は図２１に示す各ステップと同様であるため、ステップＳＴ３０７についてのみ説明する。
［ステップＳＴ３０７］：イベント処理部３０６ｃは、ステップＳＴ３０６のイベント存在確認において、同じイベントが既に蓄積済みであった場合、既に蓄積されている同じイベントを削除し、ステップＳＴ３０５に移行する。このような動作により、イベントキューへの蓄積をイベント発生時刻順とすることができる。
【００９０】
また、上記説明ではイベントを一意に特定する情報としてイベント名を用いているが、イベントが何らかのパラメータを持つ場合、イベントキューへの蓄積可否の判断に、このパラメータも併せて用いても構わない。例えば、ＳｅｒｖｉｃｅＡ＿ＥｖｅｎｔＡが２個のパラメータ（ｐａｒａｍ＿ａ，ｐａｒａｍ＿ｂ）を持つとする。
イベントキューには、ＳｅｒｖｉｃｅＡ＿Ｅｖｅｎｔ（１，２００）というイベントが蓄積されているとする。この状態でＳｅｒｖｉｃｅＡ＿Ｅｖｅｎｔ（２，２００）というイベントが発生した場合を考える。ここでは、上述した図２１及び図２２の動作におけるステップＳＴ３０６の「イベント存在確認」において、パラメータの値も用いてイベントの同一性を判定する。このため、イベント処理部３０６ｃは、ＳｅｒｖｉｃｅＡ＿Ｅｖｅｎｔ（１，２００）とＳｅｒｖｉｃｅＡ＿Ｅｖｅｎｔ（２，２００）は異なるイベントであると判定し、結果としてＳｅｒｖｉｃｅＡ＿Ｅｖｅｎｔ（２，２００）はイベントキューに格納される。
【００９１】
なお、上記説明ではイベントリスト８００の通知周期８１２に「ｍｓ」と単位まで記述したが、イベントリスト８００の記述仕様がＧＵＩ装置１００ｃとサービス装置３００ｃの間で明確に決められている場合は、単位を省略しても構わない。これは、通知周期８１２が文字列でなく数値でもこの実施の形態の効果が変わらないことを意味する。
【００９２】
また、実施の形態４では、実施の形態１におけるＧＵＩ装置１００、サービス装置３００に対して追加した手順を説明したが、実施の形態２と実施の形態３におけるＧＵＩ装置１００ａ、ＧＵＩ装置１００ｂ、サービス装置３００ａ、サービス装置３００ｂに対しても同様の手順を追加することにより、この実施の形態の効果が得られることは言うまでもない。
【００９３】
さらに、実施の形態３における差分の表現において、イベントの名称は同じで通知周期のみ異なる場合は、操作種別７１１に通知周期のみを差し替えるための種別を追加することで、操作種別７１１が「ＤＥＬ」「ＡＤＤ」の２種類の場合より、差分のサイズを削減することができる。例えば、これを図１６を用いて説明する。
【００９４】
図１６では、ＳｅｒｖｉｃｅＡ＿ＥｖｅｎｔＡに対して周期１００ｍｓを設定している。図１６のイベントリストがサービス処理部３０１で使用されている状態として、周期を２００ｍｓに変更する場合の差分記述を考える。
ＤＥＬとＡＤＤを組み合わせた場合は、イベント差分リストは次のような記述となる。（１）ＤＥＬ，ＳｅｒｖｉｃｅＡ＿ＥｖｅｎｔＡ
（２）ＡＤＤ，ＳｅｒｖｉｃｅＡ＿ＥｖｅｎｔＡ，２００ｍｓ
一方、操作種別にＲＥＰＬＡＣＥを追加する。これは、イベントリストの通知周期のみを書き換えるものである。イベント差分リストは以下のように記述することができる。
（１）ＲＥＰＬＡＣＥ，ＳｅｒｖｉｃｅＡ＿ＥｖｅｎｔＡ，  ２００ｍｓ
このように、差分のサイズは通知周期のみを差し替えるための種別を用いた方が小さくすることができる。
【００９５】
以上説明したように、実施の形態４の通信システムによれば、ＧＵＩ装置側イベント処理部は、サービス装置にイベントリストを送信する場合、各イベントにサービス装置からの通知間隔の情報を付加し、かつ、サービス装置は、各イベントの通知間隔に対応したイベントキューを格納するイベント蓄積部を備え、サービス装置側イベント処理部は、サービス処理部のサービスによって発生するイベントがＧＵＩ装置から通知されたイベントであった場合は、イベントの通知間隔に対応したイベントキューにそのイベントを格納すると共に、イベントキューの通知タイミングになった場合は、イベントキューに格納されているイベントをＧＵＩ装置に通知するようにしたので、サービス装置の仕様を変更することなく、通知周期を変更することができる。また、サービス装置とＧＵＩ装置間の通信回数を削減することができる。
【００９６】
また、実施の形態４の通信システムによれば、サービス装置側イベント処理部は、イベントキューにイベントを格納する際、既に同じイベントが格納されていた場合は、イベントの格納を行わないか、既に格納されていたイベントを削除してからイベントを格納するようにしたので、設定された周期毎に通知されるイベントの個数を削減することができる。
【００９７】
また、実施の形態４の通信システムによれば、サービス装置側イベント処理部は、イベントがパラメータを有する場合、イベントキューに既に同じイベントが格納されているか否かの同一性判定をパラメータを含めて行うようにしたので、ＧＵＩ装置がイベントに含まれるパラメータの値に基づき表示を変える場合に、必要なイベントをサービス装置で捨ててしまうといったことがなく、意図したＧＵＩの変更が可能となる。
【００９８】
なお、本願発明はその発明の範囲内において、各実施の形態の自由な組み合わせ、あるいは各実施の形態の任意の構成要素の変形、もしくは各実施の形態において任意の構成要素の省略が可能である。
【産業上の利用可能性】
【００９９】
以上のように、この発明に係る通信システムは、サーバにサービスロジック、クライアントにＧＵＩを実装し、それらがネットワーク経由で連携することにより、システムを構成するものであり、ＧＵＩを持つ組み込み機器に用いるのに適している。
【符号の説明】
【０１００】
１００，１００ａ，１００ｂ，１００ｃ  ＧＵＩ装置、１０１  表示部、１０２  ＧＵＩロジック処理部、１０３  要求処理部、１０４  通信部、１０５，１０５ａ，１０５ｂ，１０５ｃ  イベント処理部、１０６  イベントリスト記憶部、１０７  インターフェース部、２００  ネットワーク、３００，３００ａ，３００ｂ，３００ｃ  サービス装置、３０１  サービス処理部、３０２  サービスＡ、３０３  サービスＢ、３０４  要求処理部、３０５  通信部、３０６，３０６ａ，３０６ｂ，３０６ｃ  イベント処理部、３０７  ＩＤ管理部、３０８  イベントリスト記憶部、３０９  イベント蓄積部、３１０ａ，３１０ｂ  イベントキュー、３１１ａ，３１１ｂ  タイマ、４００，４００Ａ，４００Ｂ，８００  イベントリスト、５００，５００Ａ，５００Ｂ  ＩＤ、６００  登録結果、６１０  削除ＩＤリスト、７００  イベントリスト登録要求、７１０  イベント差分リスト、８１１ｐ〜８１１ｓ  イベント名、８１２ｐ〜８１２ｓ  通知周期。
【図１】
2014006669.tif 000003
【図２】
2014006669.tif 000004
【図３】
2014006669.tif 000005
【図４】
2014006669.tif 000006
【図５】
2014006669.tif 000007
【図６】
2014006669.tif 000008
【図７】
2014006669.tif 000009
【図８】
2014006669.tif 000010
【図９】
2014006669.tif 000011
【図１０】
2014006669.tif 000012
【図１１】
2014006669.tif 000013
【図１２】
2014006669.tif 000014
【図１３】
2014006669.tif 000015
【図１４】
2014006669.tif 000016
【図１５】
2014006669.tif 000017
【図１６】
2014006669.tif 000018
【図１７】
2014006669.tif 000019
【図１８】
2014006669.tif 000020
【図１９】
2014006669.tif 000021
【図２０】
2014006669.tif 000022
【図２１】
2014006669.tif 000023
【図２２】
2014006669.tif 000024
【手続補正書】
【提出日】平成26年4月23日(2014.4.23)
【手続補正１】
【補正対象書類名】明細書
【補正対象項目名】全文
【補正方法】変更
【補正の内容】
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、ＧＵＩ装置とサービス装置がネットワークを介して接続され、相互に通信することでＧＵＩ装置におけるグラフィックスを表示する通信システムに関する。
【背景技術】
【０００２】
従来の、ＧＵＩ（Ｇｒａｐｈｉｃａｌ  Ｕｓｅｒ  Ｉｎｔｅｒｆａｃｅ）を持つ組み込み機器では、各アプリケーションの挙動を既定するサービスロジックとＧＵＩを同一の機器に実装し、単体で独立した動作が可能な装置として構成されることが一般的である。
その一方で、サーバ・クライアントシステムのように、サーバにサービスロジック、クライアントにＧＵＩを実装し、それらがネットワーク経由で連携することにより、システムを構成する方法もある。
【０００３】
近年の組み込み機器の処理能力の向上と、ネットワーク接続機能を持つことが一般的になってきていることにより、組み込み機器に上記のサーバ・クライアントシステムを適用し、ＧＵＩとサービスロジックをそれぞれ異なる機器に実装することが可能である。
このようなシステムでは、従来は同一機器内で行われていたＧＵＩとサービスロジック間の通信が、機器間の通信に置き換わる。機器間通信の処理能力は、同一機器内の通信の処理能力より低いことが一般的である。また、従来はサービスロジックで発生したイベントはすべてＧＵＩに通知し、ＧＵＩが受信したイベントの必要性を判断してＧＵＩへの反映を行っていた。機器内の通信が機器間の通信に置き換わると、通信に要する時間が長くなってしまうため、機器間の通信量及び通信頻度を削減することによるシステム全体の応答性能（例えばユーザがＧＵＩを操作してから、サービスロジックがその操作に対応する処理を行い、処理の結果をＧＵＩに反映させるまでの時間）の改善が必要となる。具体的には、不要なイベントをサービスロジックからＧＵＩに通知しないようにすることが望ましい。
【０００４】
例えば、特許文献１では、イベント通知要求を行った通知先をリスナーに登録し、登録されたリスナーのみにイベントを通知することにより、不要なイベント通知の発生を回避している。また、特許文献２では、通知者プログラムがイベントを発生させたとき、要求者プログラムが通知マネージャに提示したイベントのみを要求者プログラムに通知することにより、不要なイベント通知の発生を回避している。このとき、通知パラメータとそれに対応する辞書を用いることにより、通知マネージャへ提示する１つ以上のイベントの指定に要する通信量を削減している。
【先行技術文献】
【特許文献】
【０００５】
【特許文献１】特開２００８−７７２１９号公報
【特許文献２】特表２００４−５３２４７９号公報
【発明の概要】
【発明が解決しようとする課題】
【０００６】
しかしながら、特許文献１に示されたような技術では、イベントを１つ受信すると、次のイベントを受信するためには再びイベント通知要求を行う必要がある。したがって、特許文献１の手法を、ＧＵＩとサービスロジックが異なる機器に実装されているシステムに適用すると、通信が頻繁に行われてしまうという課題があった。
【０００７】
また、特許文献２に示された構成では、通知マネージャへの通知パラメータと辞書の対応関係が固定されている。イベントの種類が少ないシステムでは特許文献２の手法でも問題ないが、イベントの種類が多いシステムでは、辞書のサイズが大きくなってしまうという課題がある。さらに、サービスロジックは変更せずＧＵＩのみを変更するという場合を考えると、ＧＵＩの変更に伴いＧＵＩで必要とするイベントのパターンも変更される可能性があるが、特許文献２の手法では変更されたパターンが辞書にないとＧＵＩの変更に対応できないという課題があった。
【０００８】
この発明は、上記のような課題を解決するためになされたもので、通信量を削減することのできる通信システム、ＧＵＩ装置及びサービス装置を得ることを目的とする。
【課題を解決するための手段】
【０００９】
この発明に係る通信システムは、イベント通知に基づき画面構築を行うＧＵＩ装置と、サービスを実行してイベントを発生するサービス装置とがネットワークを介して接続され、相互に通信を行う通信システムにおいて、ＧＵＩ装置は、イベントの一覧であるイベントリストと、イベントリストに対応するＩＤを格納するＧＵＩ装置側イベントリスト記憶部と、ＧＵＩ装置側イベントリスト記憶部を参照し、画面構築に必要なイベントリストと一致するイベントリストが存在する場合は、イベントリストに対応するＩＤを取得し、取得したＩＤをイベントリストの代わりにサービス装置に送信するＧＵＩ装置側イベント処理部と、を備えるものである。
【００１０】
また、この発明に係るＧＵＩ装置は、サービスを実行してイベントを発生するサービス装置とネットワークを介して接続され、サービス装置と相互に通信を行い、イベント通知に基づき画面構築を行うＧＵＩ装置において、イベントの一覧であるイベントリストと、イベントリストに対応するＩＤを格納するＧＵＩ装置側イベントリスト記憶部と、画面構築時に画面に必要なイベントリストをサービス装置に送信すると共に、送信前に、ＧＵＩ装置側イベントリスト記憶部を参照し、送信対象イベントリストと一致するイベントリストが存在する場合は、そのイベントリストに対応するＩＤを取得し、送信対象イベントリストの代わりにＩＤをサービス装置に送信するＧＵＩ装置側イベント処理部と、を備えるものである。
【００１１】
また、この発明に係るサービス装置は、イベント通知に基づき画面構築を行うＧＵＩ装置とネットワークを介して接続され、ＧＵＩ装置と相互に通信を行い、サービスを実行してイベントを発生するサービス装置において、イベントの一覧であるイベントリストと、イベントリストに対応するＩＤを格納するサービス装置側イベントリスト記憶部と、イベントリストとＩＤとの関係を管理するＩＤ管理部と、ＧＵＩ装置からイベントリストを受信した場合、サービス装置側イベントリスト記憶部を参照し、受信したイベントリストと一致するイベントリストが存在する場合は、そのイベントリストに対応するＩＤを取得し、ＩＤをＧＵＩ装置への応答メッセージに含めて送信し、一方、サービス装置側イベントリスト記憶部を参照した結果、受信したイベントリストと一致するイベントリストが存在しない場合は、ＩＤ管理部からサービス装置側イベントリスト記憶部に登録されていないＩＤを取得して、取得したＩＤと受信したイベントリストとを１個の組として、サービス装置側イベントリスト記憶部に登録し、取得したＩＤをＧＵＩ装置への応答メッセージに含めて送信し、ＧＵＩ装置からＩＤを受信した場合は、サービス装置側イベントリスト記憶部を参照し、受信したＩＤに対応するイベントリストが存在する場合は、受信したＩＤをＧＵＩ装置への応答メッセージに含めて送信するサービス装置側イベント処理部と、を備えるものである。
【発明の効果】
【００１２】
この発明に係る通信システム、ＧＵＩ装置及びサービス装置によれば、通信量を削減することができる。
【図面の簡単な説明】
【００１３】
【図１】この発明の実施の形態１による通信システムを示す構成図である。
【図２】この発明の実施の形態１による通信システムのイベントリストを示す説明図である。
【図３】この発明の実施の形態１による通信システムのイベントリスト記憶部の記憶内容を示す説明図である。
【図４】この発明の実施の形態１による通信システムのイベントリスト登録時のＧＵＩ装置の動作を示すフローチャートである。
【図５】この発明の実施の形態１による通信システムのイベントリスト登録時のサービス装置の動作を示すフローチャートである。
【図６】この発明の実施の形態１による通信システムのイベント発生時のサービス装置の動作を示すフローチャートである。
【図７】この発明の実施の形態２による通信システムを示す構成図である。
【図８】この発明の実施の形態２による通信システムの応答メッセージに含まれる登録結果を示す説明図である。
【図９】この発明の実施の形態２による通信システムのイベントリスト登録時のＧＵＩ装置の動作を示すフローチャートである。
【図１０】この発明の実施の形態２による通信システムのイベントリスト登録時のサービス装置の動作を示すフローチャートである。
【図１１】この発明の実施の形態３による通信システムを示す構成図である。
【図１２】この発明の実施の形態３による通信システムのイベントリスト登録要求を示す説明図である。
【図１３】この発明の実施の形態３による通信システムのイベントリスト登録時のＧＵＩ装置の動作を示すフローチャートである。
【図１４】この発明の実施の形態３による通信システムのイベントリスト登録時のサービス装置の動作を示すフローチャートである。
【図１５】この発明の実施の形態４による通信システムを示す構成図である。
【図１６】この発明の実施の形態４による通信システムのイベント発生時のサービス装置の動作を示すフローチャートである。
【図１７】この発明の実施の形態４による通信システムのイベントリスト登録時のＧＵＩ装置の動作を示すフローチャートである。
【図１８】この発明の実施の形態４による通信システムのイベントリスト登録時のサービス装置の動作を示すフローチャートである。
【図１９】この発明の実施の形態４による通信システムのイベント発生時のサービス装置の動作を示すフローチャートである。
【図２０】この発明の実施の形態４による通信システムのイベントキューとタイマとの関係を示す説明図である。
【図２１】この発明の実施の形態４による通信システムのイベント発生時のサービス装置の他の動作を示すフローチャートである。
【図２２】この発明の実施の形態４による通信システムのイベント発生時のサービス装置のさらに他の動作を示すフローチャートである。
【発明を実施するための形態】
【００１４】
実施の形態１．
図１は、この発明の実施の形態１による通信システムを示す構成図である。
図１に示す通信システムは、ＧＵＩ装置１００とサービス装置３００とがネットワーク２００を介して接続された構成となっている。
【００１５】
ＧＵＩ装置１００は、表示部１０１、ＧＵＩロジック処理部１０２、要求処理部１０３、通信部１０４、イベント処理部（ＧＵＩ装置側イベント処理部）１０５、イベントリスト記憶部（ＧＵＩ装置側イベントリスト記憶部）１０６、インターフェース部１０７を備える。
【００１６】
表示部１０１は、例えば液晶ディスプレイなどの装置であり、ＧＵＩを表示する。ＧＵＩロジック処理部１０２は、表示部１０１に表示するＧＵＩを構築したり、インターフェース部１０７との入出力を担当したりする装置である。また、ＧＵＩロジック処理部１０２は、要求処理部１０３を介してサービス装置３００に要求を発行したり、イベント処理部１０５から通知されたイベントに基づき表示部１０１に表示するＧＵＩを変更したり、インターフェース部１０７を介してＧＵＩ以外の出力を行ったりする。要求処理部１０３は、ＧＵＩロジック処理部１０２から受けたサービス装置３００への要求を、通信部１０４を介した通信に適合するように変換する装置である。例えば、ＧＵＩロジック処理部１０２が要求処理部１０３に対して関数呼び出しを行い、ＧＵＩ装置１００とサービス装置３００がＨＴＴＰ（ＨｙｐｅｒＴｅｘｔ  Ｔｒａｎｓｆｅｒ  Ｐｒｏｔｏｃｏｌ）を用いて通信している場合（ＧＵＩ装置１００がクライアント、サービス装置３００がサーバとする）、ＧＵＩロジック処理部１０２からの関数呼び出しをＨＴＴＰリクエストに変換することに相当する。
【００１７】
通信部１０４は、ネットワーク２００を介したサービス装置３００とのデータ授受を担当する装置である。イベント処理部１０５は、ＧＵＩ装置１００におけるイベントに関する処理を担当する装置である。例えば、サービス装置３００に対するイベントリストの登録や、サービス装置３００から受信したイベントをＧＵＩロジック処理部１０２に渡すことである。イベントリストについては後述する。イベントリスト記憶部１０６は、イベント処理部１０５がサービス装置３００に登録したイベントリストと、そのイベントリストを一意に特定するためのＩＤの組を記憶するための装置である。インターフェース部１０７は、システムのユーザとのインタラクションを行うことを目的とした装置であり、例えばタッチパネル、スピーカなどが挙げられる。
【００１８】
サービス装置３００は、サービス処理部３０１、要求処理部３０４、通信部３０５、イベント処理部（サービス装置側イベント処理部）３０６、ＩＤ管理部３０７、イベントリスト記憶部（サービス装置側イベントリスト記憶部）３０８を備える。
サービス処理部３０１は、１つ以上のサービスを備える。図１では、２つのサービス（サービスＡ３０２、サービスＢ３０３）を備えている例を示している。なお、サービスとはそれぞれに固有の機能を提供するプログラムである。要求処理部３０４は、ＧＵＩ装置１００から受けた要求を、サービス処理部３０１に適合するように変換する装置である。例えば、ＧＵＩ装置１００とサービス装置３００がＨＴＴＰを用いて通信しており、サービス処理部３０１が各サービスで定義されているＡＰＩ（Ａｐｐｌｉｃａｔｉｏｎ  Ｐｒｏｇｒａｍｍｉｎｇ  Ｉｎｔｅｒｆａｃｅ）を公開している場合、ＨＴＴＰリクエストを解析して対応するＡＰＩを特定し、特定したＡＰＩを呼び出すことに相当する。通信部３０５は、ネットワーク２００を介したＧＵＩ装置１００とのデータ授受を担当する装置である。
【００１９】
イベント処理部３０６は、サービス装置３００におけるイベントに関する処理を担当する装置である。例えば、ＧＵＩ装置１００から要求されたイベントリストの登録を行ったり、サービス処理部３０１から発生したイベントを受け取りそのイベントをＧＵＩ装置１００に通知するか否かを判断したりする。ＩＤ管理部３０７は、ＧＵＩ装置１００から送信されたイベントリストを一意に特定するためのＩＤを決定するための装置である。また、ＩＤ管理部３０７は、イベントリスト記憶部３０８に記憶された内容を参照し、イベント処理部３０６から指定されたＩＤに対応するイベントリストを特定するという機能も担当する。イベントリスト記憶部３０８は、ＧＵＩ装置１００から送信されたイベントリストと、そのイベントリストを一意に特定するためのＩＤの組を記憶するための装置である。
【００２０】
図２は、この実施の形態におけるイベントリスト４００の構成を示す図である。イベントリスト４００は０個以上のイベント名を格納する。この実施の形態において、イベントはイベントの名称によりシステム内で一意に特定できるものとする。なお、イベントリスト４００の終端は、要素数もしくは終端を意味する要素により認識可能だが、図２では省略する。
【００２１】
図３は、この実施の形態におけるイベントリスト記憶部１０６及びイベントリスト記憶部３０８が記憶する内容を示す図である。記憶する内容は、ＩＤとイベントリストの組（イベントリスト４００ＡとＩＤ５００Ａ、イベントリスト４００ＢとＩＤ５００Ｂ）を一要素としており、図３では２個の要素が格納されている。
【００２２】
次に、ＧＵＩ装置１００及びサービス装置３００の動作について、図１、図２、図３、図４、図５、図６を用いて説明する。
図４は、この実施の形態におけるイベントリスト登録時のＧＵＩ装置１００の動作を示すフローチャートである。なお、イベントリストの登録は、ＧＵＩロジック処理部１０２において、例えば画面遷移などによる表示内容の変化が発生したときに、画面構築処理の一部として行われるものとする。画面遷移のトリガとしては、サービス装置３００からのイベント通知、またはインターフェース部１０７からの入力イベント通知等が挙げられる。
【００２３】
［ステップＳＴ１００］：ＧＵＩロジック処理部１０２は、画面遷移などの発生により、画面構築処理を開始する。
［ステップＳＴ１０１］：ＧＵＩロジック処理部１０２は、遷移後の画面で必要なイベントをイベント処理部１０５に提供する。イベント処理部１０５は、ＧＵＩロジック処理部１０２から提供された０個以上のイベントを用いてイベントリスト４００を作成し、イベント処理部１０５の内部に一時的に記憶する。なお、０個のイベント（＝イベント無し）でイベントリスト４００を作成する場合を含むのは、サービス装置３００からのイベントを必要としないサービスに対応するためである。
［ステップＳＴ１０２］：イベント処理部１０５は、ステップＳＴ１０１で一時的に記憶したイベントリスト４００を用いて、イベントリスト記憶部１０６にイベントリスト４００に一致する要素が登録されているか検索する。「未登録」の場合は、ステップＳＴ１０３に進む。「登録済」の場合は、該当する要素に記憶されているＩＤを取得し、ステップＳＴ１０４に進む。
［ステップＳＴ１０３］：イベント処理部１０５は、通信部１０４を介して、サービス装置３００にイベントリスト４００を送信する。例えばイベントリスト４００には４個のイベントが格納されているが、この個数は画面ごとに異なり、０個の場合もある。
【００２４】
［ステップＳＴ１０４］：イベント処理部１０５は、通信部１０４を介して、サービス装置３００にステップＳＴ１０２で得たＩＤを送信する。なお、サービス装置３００は、ＧＵＩ装置１００からのイベントリスト送信とＩＤ送信の区別が可能である。これは、送信データの書式（例えば、ＨＴＴＰリクエストのＵＲＩ（Ｕｎｉｆｏｒｍ  Ｒｅｓｏｕｒｃｅ  Ｉｄｅｎｔｉｆｉｅｒ）、もしくはＢＯＤＹに記述するテキストのフォーマット）を事前に決めておくことで実現できる。
［ステップＳＴ１０５］：通信部１０４は、ステップＳＴ１０３もしくはステップＳＴ１０４で実行した送信に対するサービス装置３００からの応答を待つ。応答を受信すると、通信部１０４はその応答をイベント処理部１０５に渡し、ステップＳＴ１０６に進む。
［ステップＳＴ１０６］：ステップＳＴ１０５で受信した応答には図３に示したＩＤが含まれており、イベント処理部１０５はＩＤが有効か否かを検査する。ＩＤが０、もしくは応答にＩＤが含まれていない場合は「無効なＩＤ」と判定し、ステップＳＴ１０８に進む。それ以外の場合は「有効なＩＤ」と判定し、ステップＳＴ１０７に進む。
【００２５】
［ステップＳＴ１０７］：イベント処理部１０５は、ステップＳＴ１０５で受信したＩＤとステップＳＴ１０１で内部に一時的に記憶したイベントリスト４００の組を、イベントリスト記憶部１０６に登録する。なお、ＩＤの値が一致する要素がイベントリスト記憶部１０６に存在する場合、その要素のイベントリスト部分を上書きする。
［ステップＳＴ１０８］：イベント処理部１０５は、内部に一時的に記憶していたイベントリスト４００を破棄すると共に、ＧＵＩロジック処理部１０２にイベントを渡す機能を有効にして、処理を終了する。なお、ＧＵＩロジック処理部１０２にイベントを渡す機能は、ステップＳＴ１００もしくは画面遷移の遷移元の終了処理などで適切に無効化されているものとする。また、ＧＵＩロジック処理部１０２にイベントを渡す機能が無効になっている期間に受信したイベントは、イベント処理部１０５内部で蓄積されるか、もしくはイベント処理部１０５にて破棄される。
【００２６】
図５は、この実施の形態におけるイベントリスト登録時のサービス装置３００の動作を示すフローチャートである。
［ステップＳＴ２００］：図４のステップＳＴ１０３もしくはステップＳＴ１０４でＧＵＩ装置１００が送信処理を行い、サービス装置３００の通信部３０５がそれを受信すると、サービス装置３００は処理を開始する。
［ステップＳＴ２０１］：通信部３０５はイベント処理部３０６に受信データを渡す。イベント処理部３０６は、受信データがＩＤかイベントリストのどちらであるかを判定する。ＩＤの場合は、イベント処理部３０６が受信データに含まれるＩＤをイベント処理部３０６の内部に一時的に記憶し、ステップＳＴ２０２に進む。イベントリストの場合は、イベント処理部３０６が受信データに含まれるイベントリストをイベント処理部３０６の内部に記憶し、ステップＳＴ２０３に進む。
【００２７】
［ステップＳＴ２０２］：イベント処理部３０６は、ＩＤ管理部３０７にステップＳＴ２０１で記憶したＩＤを渡し、検索を要求する。ＩＤ管理部３０７は、前記ＩＤを用いてイベントリスト記憶部３０８に一致する要素が登録されているか検索する。該当する要素を発見した場合、ＩＤ管理部３０７は「取得成功」と判定し、発見した要素に含まれるイベントリストをイベント処理部３０６に渡し、ステップＳＴ２０７に進む。該当する要素が見つからなかった場合、ＩＤ管理部３０７は「取得失敗」と判定し、判定結果をイベント処理部３０６に渡し、ステップＳＴ２０８に進む。
［ステップＳＴ２０３］：イベント処理部３０６は、ステップＳＴ２０１で記憶したイベントリストを用いてイベントリスト記憶部３０８を参照し、一致する要素が存在するか確認する。存在する場合、「該当あり」と判断し、ステップＳＴ２０４に進む。存在しない場合、「該当なし」と判断し、ステップＳＴ２０５に進む。
【００２８】
［ステップＳＴ２０４］：イベント処理部３０６は、イベントリスト記憶部３０８に存在した、ステップＳＴ２０１で記憶したイベントリストに一致する要素のＩＤを、イベント処理部３０６の内部に一時的に記憶し、ステップＳＴ２０７に進む。
［ステップＳＴ２０５］：イベント処理部３０６は、ＩＤ管理部３０７に対して、未使用のＩＤの取得を要求する。ＩＤ管理部３０７は、イベントリスト記憶部３０８を参照し、イベントリスト記憶部３０８に存在しないＩＤを決定し、決定したＩＤをイベント処理部３０６に渡す。
［ステップＳＴ２０６］：イベント処理部３０６は、ステップＳＴ２０５でＩＤ管理部３０７から渡されたＩＤと、ステップＳＴ２０１で記憶したイベントリストの組を、イベントリスト記憶部３０８に登録する。
【００２９】
［ステップＳＴ２０７］：イベント処理部３０６は、ステップＳＴ２０２を実行した場合は、ステップＳＴ２０２でイベントリスト記憶部３０８から取得したイベントリストを、イベント処理部３０６の内部に記憶する。なお、それ以外の場合はステップＳＴ２０１で記憶する動作を実行しているため、何もしない。
［ステップＳＴ２０８］：イベント処理部３０６は、通信部３０５を介して、応答メッセージをＧＵＩ装置１００に送信する。応答メッセージには、ステップＳＴ２０１で取得した、もしくはステップＳＴ２０４でＩＤ管理部３０７から渡された、もしくはステップＳＴ２０５でＩＤ管理部３０７から渡されたＩＤを格納する。ただし、ステップＳＴ２０２で「取得失敗」の場合は、無効なＩＤ（ステップＳＴ１０６に合わせると０）を格納する。
［ステップＳＴ２０９］：サービス装置３００は処理を終了する。
【００３０】
図６は、この実施の形態におけるイベント発生時のサービス装置３００の動作を示すフローチャートである。
［ステップＳＴ３００］：サービスＡ３０２もしくはサービスＢ３０３でイベントが発生し、サービス処理部３０１を介してイベント処理部３０６に前記イベントが渡されると、サービス装置３００は処理を開始する。
［ステップＳＴ３０１］：イベント処理部３０６は、サービス処理部３０１から渡されたイベントの名称に基づき、イベント処理部３０６の内部に記憶しているイベントリストに該当するイベントが存在するか確認する。存在する場合は、前記イベントを「通知対象」と判断し、ステップＳＴ３０２に進む。存在しない場合は、前記イベントを「通知対象外」と判断し、前記イベントを破棄して、ステップＳＴ３０３に進む。
［ステップＳＴ３０２］：イベント処理部３０６は、サービス処理部３０１から渡されたイベントを、通信部３０５を介してＧＵＩ装置１００に通知する。
［ステップＳＴ３０３］：サービス装置３００は処理を終了する。
【００３１】
この実施の形態において、サービス装置３００からのイベント通知が発生した場合、ＧＵＩ装置１００は、通信部１０４を介して前記イベントをイベント処理部１０５に渡し、イベント処理部１０５はこのイベントをＧＵＩロジック処理部１０２に渡す。これらの動作の詳細については省略する。
【００３２】
このように、実施の形態１のＧＵＩ装置１００は、ＧＵＩ装置１００が必要とするイベントの一覧（イベントリスト）をサービス装置３００に送信する前に、イベント処理部１０５がイベントリスト記憶部１０６に送信対象イベントリストを一意に特定するＩＤが存在するかを確認し、存在する場合はＩＤを送信する。また、サービス装置３００のイベント処理部３０６は、イベントリストを受信したときに、ＩＤ管理部３０７とイベントリスト記憶部３０８を用いて、イベントリスト記憶部３０８に前記イベントリストに一致する要素がない場合に、ＩＤ管理部３０７から未使用のＩＤを取得し、前記イベントリストと前記ＩＤの組をイベントリスト記憶部３０８に登録し、ＧＵＩ装置１００に前記ＩＤを送信する。また、ＧＵＩ装置１００のイベント処理部１０５は、サービス装置３００から受信したＩＤと、サービス装置に送信しようとしたイベントリストの組を、イベントリスト記憶部１０６に登録する。
【００３３】
また、サービス装置３００のサービス処理部３０１からイベント処理部３０６にイベントが渡されると、イベント処理部３０６は内部に記憶しているイベントリストを用いて、ＧＵＩ装置１００に前記イベントを通知するか否かを判断する。従って、ＧＵＩ装置１００にとって不要なイベントの通知を行わないため、ＧＵＩ装置１００からサービス装置３００への通信量を削減できるという効果がある。
【００３４】
また、イベントリスト記憶部１０６に送信対象イベントリストに該当する要素が存在する場合、イベントリストではなくＩＤをサービス装置３００に送信することで、イベント処理部３０６はＩＤを用いてイベントリストの設定が可能となるため、ＧＵＩ装置１００からサービス装置３００への通信量を削減できるという効果もある。すなわち、一般に、イベントリストのデータ量よりもＩＤのデータ量の方が小さいからである。さらに、サービス装置３００に予めイベントリストとＩＤの対応関係を準備していなくても通信量の削減が可能であるため、イベントリストとＩＤの対応関係の設計および実装に要する費用を削減できるといった効果もある。
【００３５】
また、上記説明ではＩＤの値が０の場合、もしくは応答にＩＤが含まれていない場合、無効なＩＤと判断していたが、他の方法を用いても構わない。
【００３６】
以上説明したように、実施の形態１の通信システムによれば、イベント通知に基づき画面構築を行うＧＵＩ装置と、サービスを実行してイベントを発生するサービス装置とがネットワークを介して接続され、相互に通信を行う通信システムにおいて、ＧＵＩ装置は、イベントの一覧であるイベントリストと、イベントリストを一意に特定するＩＤを格納するＧＵＩ装置側イベントリスト記憶部と、画面構築時に画面に必要なイベントリストをサービス装置に送信すると共に、送信前に、ＧＵＩ装置側イベントリスト記憶部を参照し、送信対象イベントリストと一致するイベントリストが存在する場合は、そのイベントリストを一意に特定するＩＤを取得し、送信対象イベントリストの代わりにＩＤをサービス装置に送信するＧＵＩ装置側イベント処理部とを備え、かつ、ＧＵＩ装置側イベント処理部は、イベントリストまたはＩＤをサービス装置に送信した結果として得られる応答メッセージにＩＤが含まれる場合は、応答メッセージに含まれるＩＤと、サービス装置に対して送信したイベントリスト、または、その代わりにＩＤを送信したイベントリストとを１個の組としてＧＵＩ装置側イベントリスト記憶部に記憶させ、サービス装置は、イベントの一覧であるイベントリストと、イベントリストを一意に特定するＩＤを格納するサービス装置側イベントリスト記憶部と、イベントリストとＩＤとの関係を管理するＩＤ管理部と、サービスを実行し、イベントを発生させるサービス処理部と、ＧＵＩ装置からイベントリストを受信した場合、サービス装置側イベントリスト記憶部を参照し、受信したイベントリストと一致するイベントリストが存在する場合は、そのイベントリストを一意に特定するＩＤを取得し、ＩＤをＧＵＩ装置への応答メッセージに含めて送信し、一方、サービス装置側イベントリスト記憶部を参照した結果、受信したイベントリストと一致するイベントリストが存在しない場合は、ＩＤ管理部からサービス装置側イベントリスト記憶部に登録されていないＩＤを取得して、取得したＩＤと受信したイベントリストとを１個の組として、サービス装置側イベントリスト記憶部に登録し、取得したＩＤをＧＵＩ装置への応答メッセージに含めて送信し、ＧＵＩ装置からＩＤを受信した場合は、サービス装置側イベントリスト記憶部を参照し、受信したＩＤと一致するイベントリストが存在する場合は、受信したＩＤをＧＵＩ装置への応答メッセージに含めて送信するイベント処理部とを備え、かつ、サービス装置側イベント処理部は、サービス処理部のサービスによって発生するイベントに対して、イベントが含まれるイベントリストがＧＵＩ装置への通知対象となっているかを判定し、通知対象となっている場合にのみ、イベントをＧＵＩ装置に通知するようにしたので、ＧＵＩ装置とサービス装置間の通信量を削減し、かつ、イベントのパターン変更にも柔軟に対処することができる。
【００３７】
実施の形態２．
実施の形態１では、イベントリスト記憶部１０６およびイベントリスト記憶部３０８に対するイベントリストとＩＤの組の登録について説明したが、実施の形態２では、イベントリスト記憶部３０８に設けられた記憶容量の制限に対応することで、サービス装置３００のリソース使用効率を改善するようにした例を説明する。
【００３８】
この発明の実施の形態２における通信システムの全体構成を図７に示す。
通信システムは、実施の形態１と同様に、ＧＵＩ装置１００ａとサービス装置３００ａがネットワーク２００を介して接続された構成となっている。
ＧＵＩ装置１００ａは、表示部１０１、ＧＵＩロジック処理部１０２、要求処理部１０３、通信部１０４、イベント処理部（ＧＵＩ装置側イベント処理部）１０５ａ、イベントリスト記憶部（ＧＵＩ装置側イベントリスト記憶部）１０６、インターフェース部１０７を備える。ここで、表示部１０１、ＧＵＩロジック処理部１０２、要求処理部１０３、通信部１０４、イベントリスト記憶部１０６、インターフェース部１０７については、実施の形態１と同様の構成であるため、ここでの説明は省略する。
【００３９】
イベント処理部１０５ａは、ＧＵＩ装置１００ａにおけるイベントに関する処理を担当する装置であり、実施の形態１におけるイベント処理部１０５に対して、イベントリスト記憶部１０６に対するイベントリストとＩＤの組で構成される要素を削除する機能を追加したものである。
【００４０】
サービス装置３００ａは、サービス処理部３０１、要求処理部３０４、通信部３０５、イベント処理部（サービス装置側イベント処理部）３０６ａ、ＩＤ管理部３０７、イベントリスト記憶部（サービス装置側イベントリスト記憶部）３０８を備える。ここで、サービス処理部３０１、要求処理部３０４、通信部３０５、ＩＤ管理部３０７については、実施の形態１と同様の構成であるため、ここでの説明は省略する。なお、イベントリスト記憶部３０８については、登録可能なデータサイズという情報が追加されているが、これについては図示しない。
【００４１】
イベント処理部３０６ａは、サービス装置３００ａにおけるイベントに関する処理を担当する装置であり、実施の形態１におけるイベント処理部３０６に対して、イベントリスト記憶部３０８に対するイベントリストとＩＤの組で構成される要素を削除する機能を追加したものである。
【００４２】
図８は、ＧＵＩ装置１００ａからのイベントリスト登録の要求に対して、サービス装置３００ａからＧＵＩ装置１００ａへ送信する応答メッセージに含まれる登録結果６００の構成を示した図である。登録結果６００は、登録したイベントリストを一意に特定するＩＤ５００と、削除したＩＤの列を格納する削除ＩＤリスト６１０を備える。例えば、図８では、削除ＩＤリスト６１０が２個のＩＤ（値は２０、３０）を格納している。なお、削除ＩＤリスト６１０の終端は、要素数もしくは終端を意味する要素により認識可能だが、図８では省略している。
【００４３】
次に、ＧＵＩ装置１００ａとサービス装置３００ａの動作について、図７、図８、図９、図１０を用いて説明する。
図９は、この実施の形態におけるイベントリスト登録時のＧＵＩ装置１００ａの動作を示すフローチャートである。
ステップＳＴ１００、ステップＳＴ１０１、ステップＳＴ１０２、ステップＳＴ１０３、ステップＳＴ１０４、ステップＳＴ１０５、ステップＳＴ１０６、ステップＳＴ１０７、ステップＳＴ１０８においては、ステップＳＴ１０５の次に実行するがステップＳＴ１０９に変更になることと、通信相手がサービス装置３００からサービス装置３００ａに変更になることを除き、実施の形態１におけるイベント処理部１０５と実施の形態２におけるイベント処理部１０５ａの動作に違いはない。そのため、ここではこれらステップの説明は省略する。
【００４４】
［ステップＳＴ１０９］：イベント処理部１０５ａは、ステップＳＴ１０５で受信した応答に含まれる削除ＩＤリスト６１０を先頭から順番に参照し、イベントリスト記憶部１０６から各ＩＤを含む要素を削除する。図８の例では、ＩＤが２０と３０の要素をイベントリスト記憶部１０６から削除することになる。また、イベント処理部１０５ａは、ＩＤリスト６１０の終端に到達すると、ステップＳＴ１０６に進む。
【００４５】
図１０は、この実施の形態におけるイベントリスト登録時のサービス装置３００ａの動作を示すフローチャートである。
ステップＳＴ２００、ステップＳＴ２０１、ステップＳＴ２０２、ステップＳＴ２０３、ステップＳＴ２０４、ステップＳＴ２０５、ステップＳＴ２０６、ステップＳＴ２０７、ステップＳＴ２０９においては、ステップＳＴ２０３の次にステップＳＴ２０５を実行する場合は、その前にステップＳＴ２１０を実行すること、およびステップＳＴ２０８の代わりにステップＳＴ２０８ａを実行することと、通信相手がＧＵＩ装置１００からＧＵＩ装置１００ａに変更になることを除き、実施の形態１におけるイベント処理部３０６と実施の形態２におけるイベント処理部３０６ａの動作に違いはない。そのため、ここではこれらステップの説明を省略する。
【００４６】
［ステップＳＴ２１０］：イベント処理部３０６ａは、（ア）ステップＳＴ２０１で記憶したイベントリストのサイズ＋ＩＤのサイズ、（イ）イベントリスト記憶部３０８に登録されている各要素のサイズ、（ウ）イベントリスト記憶部３０８に登録可能なデータサイズ、を用いて、（ア）＋（イ）＞（ウ）が成立する場合は、イベントリスト記憶部３０８に登録されている１個以上の要素を削除し、前記の不等式が成立しないようにする。削除する要素の選択基準としては、例えば、（ア）より大きいサイズの中で最小のもの、登録時刻が最も古いものから順番に、イベントリストやＩＤを用いた検索で該当した回数が少ないものから順番に、など様々なものが挙げられるが、目的を達成できるものであれば、任意の基準でよい。前記の不等式が成立しない状態になると、ステップＳＴ２０５に進む。
【００４７】
［ステップＳＴ２０８ａ］：イベント処理部３０６ａは、通信部３０５を介して応答メッセージをＧＵＩ装置１００に送信する。応答メッセージには、登録結果６００を格納する。ＩＤ５００には、ステップＳＴ２０１で取得した、もしくはステップＳＴ２０４でＩＤ管理部３０７から渡された、もしくはステップＳＴ２０５でＩＤ管理部３０７から渡されたＩＤを格納する。また、削除ＩＤリスト６１０には、ステップＳＴ２１０で削除した要素の０個以上のＩＤを格納する（０個の場合は、終端を意味する値のみを格納する）。ただし、ステップＳＴ２０２で「取得失敗」の場合は、ＩＤ５００には無効なＩＤを設定し、削除ＩＤリスト６１０は空にする。
【００４８】
この実施の形態におけるイベント発生時のサービス装置３００ａの動作は、実施の形態１と同様であるため、ここでは説明を省略する。
また、この実施の形態において、サービス装置３００ａからのイベント通知が発生した場合のＧＵＩ装置１００ａの動作については、実施の形態１と同様であるため、ここでは説明を省略する（ＧＵＩ装置１００、サービス装置３００、イベント処理部１０５は、それぞれＧＵＩ装置１００ａ、サービス装置３００ａ、イベント処理部１０５ａと読み替える）。
【００４９】
このように、実施の形態２のサービス装置３００ａは、新たなイベントリストをイベントリスト記憶部３０８に登録するとき、イベントリスト記憶部３０８に登録可能なデータサイズという制限を満たすように、イベントリスト記憶部３０８から要素を削除し、ＧＵＩ装置１００ａは、その削除結果として作成される削除ＩＤリスト６１０をサービス装置３００ａから受け取り、イベントリスト記憶部１０６から該当する要素を削除する。したがって、イベントリスト記憶部３０８に登録したデータのサイズが肥大化することにより発生し得るリソース不足（例えば、メモリ枯渇）を回避できるといった効果がある。また、イベントリスト記憶部３０８に登録したデータサイズに制限を設けることにより、イベントリスト記憶部３０８に対する処理に要する時間の上限を抑えることができるといった効果もある。さらに、ＧＵＩ装置１００ａにも削除した要素のＩＤを提供するため、ＧＵＩ装置１００ａから指定されたＩＤに対応する要素がイベントリスト記憶部３０８に存在しないといった現象が発生しなくなり、ＧＵＩ装置１００ａとサービス装置３００ａ間の無駄な通信を削減できるといった効果もある。
【００５０】
なお、この実施の形態では、サービス装置３００ａにおける、イベントリスト記憶部３０８に登録可能なデータサイズという制限への対応について説明したが、ＧＵＩ装置１００ａについても、同様の手順を適用することにより、イベントリスト記憶部１０６に登録可能なデータサイズという制限に対応可能である。すなわち、イベント処理部１０５ａは、イベントリストまたはＩＤをサービス装置３００ａに送信した結果として得られる応答メッセージにＩＤが含まれる場合、イベントリスト記憶部１０６に登録可能なデータサイズを超えるかを判定し、超える場合は、超えない状態になるように、イベントリスト記憶部１０６に登録済みのイベントリストとＩＤとの組を１個以上削除し、その状態で、応答メッセージに含まれるＩＤと、ＧＵＩ装置１００ａが送信したイベントリスト、またはその代わりにＩＤを送信したイベントリストとを１個の組として、イベントリスト記憶部１０６に登録するようにしてもよい。
【００５１】
以上説明したように、実施の形態２の通信システムによれば、サービス装置側イベント処理部は、ＧＵＩ装置から受信したイベントリストと、イベントリストを一意に特定するＩＤの組をサービス装置側イベントリスト記憶部に登録する前に、サービス装置側イベントリスト記憶部に登録可能なデータサイズを超えるかを判定し、超える場合は、超えない状態になるように、サービス装置側イベントリスト記憶部に登録済みのイベントリストとＩＤとの組を削除し、その状態で、ＧＵＩ装置から受信したイベントリストとイベントリストを一意に特定するＩＤの組をサービス装置側イベントリスト記憶部に登録し、一方、削除したイベントリストを一意に特定するＩＤをＧＵＩ装置への応答メッセージに含めて送信し、ＧＵＩ装置側イベント処理部は、イベントリストまたはＩＤをサービス装置に送信した結果として得られる応答メッセージにサービス装置側イベントリスト記憶部で削除されたＩＤが含まれる場合は、削除されたＩＤに対応したイベントリストをＧＵＩ装置側イベントリスト記憶部から削除するようにしたので、サービス装置側のリソース不足を抑制することができると共に、ＧＵＩ装置とサービス装置間の無駄な通信を削減することができる。
【００５２】
また、実施の形態２の通信システムによれば、ＧＵＩ装置側イベント処理部は、イベントリストまたはＩＤをサービス装置に送信した結果として得られる応答メッセージにＩＤが含まれる場合、ＧＵＩ装置側イベントリスト記憶部に登録可能なデータサイズを超えるかを判定し、超える場合は、超えない状態になるように、ＧＵＩ装置側イベントリスト記憶部に登録済みのイベントリストとＩＤとの組を削除し、その状態で、応答メッセージに含まれるＩＤと、ＧＵＩ装置が送信したイベントリスト、またはその代わりにＩＤを送信したイベントリストとを１個の組として、ＧＵＩ装置側イベントリスト記憶部に登録するようにしたので、ＧＵＩ装置側のリソース不足を抑制することができる。
【００５３】
実施の形態３．
実施の形態１や実施の形態２では、ＧＵＩ装置１００（ＧＵＩ装置１００ａ）からサービス装置３００（サービス装置３００ａ）に対してイベントリストの登録を要求する場合は、イベントリストそのものか、イベントリストを一意に特定するＩＤのいずれかを送信していた。ここで、送信対象のイベントリストと、イベントリスト記憶部１０６に登録されているイベントリストとの違いが少ない場合（例えばイベントを１個追加した）、イベントリスト全体を送信することは非効率である。そこで、実施の形態３では、登録済みのイベントリストとの差分を用いることで、イベントリストそのものを送信する場合よりも通信量を削減する。
【００５４】
この発明の実施の形態３におけるシステム全体の構成を図１１に示す。
システムはＧＵＩ装置１００ｂとサービス装置３００ｂがネットワーク２００を介して接続した構成となっている。
【００５５】
ＧＵＩ装置１００ｂは、表示部１０１、ＧＵＩロジック処理部１０２ｂ、要求処理部１０３、通信部１０４、イベント処理部（ＧＵＩ装置側イベント処理部）１０５ｂ、イベントリスト記憶部（ＧＵＩ装置側イベントリスト記憶部）１０６、インターフェース部１０７を備える。表示部１０１、ＧＵＩロジック処理部１０２ｂ、要求処理部１０３、通信部１０４、イベントリスト記憶部１０６、インターフェース部１０７については、実施の形態１と同様の構成であるため、ここでの説明は省略する。
【００５６】
イベント処理部１０５ｂは、ＧＵＩ装置１００ｂにおけるイベントに関する処理を担当する装置であり、実施の形態１におけるイベント処理部１０５に対して、ＩＤとイベントリストの差分を用いたイベントリストの登録をサービス装置３００ｂに要求する機能を追加したものである。
【００５７】
サービス装置３００ｂは、サービス処理部３０１、要求処理部３０４、通信部３０５、イベント処理部（サービス装置側イベント処理部）３０６ｂ、ＩＤ管理部３０７、イベントリスト記憶部（サービス装置側イベントリスト記憶部）３０８を備える。サービス処理部３０１、要求処理部３０４、通信部３０５、ＩＤ管理部３０７、イベントリスト記憶部３０８については、実施の形態１と同様の構成であるため、ここでの説明は省略する。
【００５８】
イベント処理部３０６ｂは、サービス装置３００ｂにおけるイベントに関する処理を担当する装置であり、実施の形態１におけるイベント処理部３０６に対して、ＩＤとイベントリストの差分を用いてイベントリストを登録する機能を追加したものである。
【００５９】
図１２は、ＧＵＩ装置１００ｂがＩＤとイベントリストの差分を用いてサービス装置３００ｂにイベントリストの登録を要求する場合に送信するイベントリスト登録要求７００の構成を示した図である。イベントリスト登録要求７００は、ＩＤ５００とイベント差分リスト７１０を備える。イベント差分リスト７１０は、操作種別７１１とイベント名７１２の組で構成される要素の列を備える。図１２では、（操作種別７１１ｘ、イベント名７１２ｘ）、（操作種別７１１ｙ、イベント名７１２ｙ）の２要素が格納されている。また、操作種別７１１ｘの「ＡＤＤ」は基準となるイベントリストにイベント名７１２ｘを追加すること、操作種別７１１ｙの「ＤＥＬ」は基準となるイベントリストからイベント名７１２ｙを削除することを意味する。なお、イベント差分リスト７１０の終端は、要素数もしくは終端を意味する要素により認識可能だが、図１２では省略している。
【００６０】
次に、ＧＵＩ装置１００ｂとサービス装置３００ｂの動作について、図３、図１１、図１２、図１３、図１４を用いて説明する。
図１３は、この実施の形態におけるイベントリスト登録時のＧＵＩ装置１００ｂの動作を示すフローチャートである。
ステップＳＴ１００、ステップＳＴ１０１、ステップＳＴ１０２、ステップＳＴ１０３、ステップＳＴ１０４、ステップＳＴ１０５、ステップＳＴ１０６、ステップＳＴ１０７、ステップＳＴ１０８においては、ステップＳＴ１０２で未登録と判断した場合の次の処理がステップＳＴ１１０に変更になることと、通信相手がサービス装置３００からサービス装置３００ｂに変更になることを除き、実施の形態１のイベント処理部１０５と実施の形態３のイベント処理部１０５ｂの動作に違いはない。そのため、ここではこれらステップの説明を省略する。
【００６１】
［ステップＳＴ１１０］：イベント処理部１０５ｂは、ステップＳＴ１０１で内部に一時的に記憶したイベントリストと、イベントリスト記憶部１０６に登録された各要素のイベントリストを用いて、イベント差分リスト７１０を生成し、その中で要素数が最も小さいものを選択する。同時に、イベント処理部１０５ｂは、前記イベント差分リスト７１０の生成に用いたイベントリストを一意に特定するＩＤを、イベントリスト記憶部１０６から取得する。例えば、図３のイベントリスト４００ＡとＩＤ５００Ａのみがイベントリスト記憶部１０６に登録されており、今回送信しようとしているイベントリストが「ＳｅｒｖｉｃｅＡ＿ＥｖｅｎｔＢ」「ＳｅｒｖｉｃｅＡ＿ＥｖｅｎｔＣ」「ＳｅｒｖｉｃｅＡ＿ＥｖｅｎｔＰ」「ＳｅｒｖｉｃｅＢ＿ＥｖｅｎｔＸ」という構成の場合、生成されるイベント差分リストは７１０のようになり、ＩＤ５００の値は１０となる。なお、イベント差分リスト７１０における操作種別７１１ｘの「ＡＤＤ」とイベント名７１２ｘの「ＳｅｒｖｉｃｅＡ＿ＥｖｅｎｔＰ」は、イベントリストに「ＳｅｒｖｉｃｅＡ＿ＥｖｅｎｔＰ」を追加することを示し、操作種別７１１ｙの「ＤＥＬ」とイベント名７１２ｙの「ＳｅｒｖｉｃｅＡ＿ＥｖｅｎｔＡ」は、イベントリストから「ＳｅｒｖｉｃｅＡ＿ＥｖｅｎｔＡ」を削除することを示している。
【００６２】
［ステップＳＴ１１１］：イベント処理部１０５ｂは、ステップＳＴ１０１で内部に一時的に記憶したイベントリストの情報量である要素数と、ステップＳＴ１１０で生成したイベント差分リスト７１０の情報量である要素数とを比較する。一時的に記憶したイベントリストの要素数の方が大きい場合は、「差分＜元のリスト」と判断し、ステップＳＴ１１２に進む。それ以外の場合は、「差分≧元のリスト」と判断し、ステップＳＴ１０３に進む。なお、イベントリスト記憶部１０６に何も登録されていない場合は、無条件でステップＳＴ１０３に進む。
【００６３】
［ステップＳＴ１１２］：イベント処理部１０５ｂは、ステップＳＴ１１０で得たイベント差分リスト７１０と、このイベント差分リスト７１０の生成に用いたイベントリストを一意に特定するＩＤとを用いて、イベントリスト登録要求７００を生成し、通信部１０４を介して、サービス装置３００にイベントリスト登録要求７００を送信する。
【００６４】
図１４は、この実施の形態におけるイベントリスト登録時のサービス装置３００ｂの動作を示すフローチャートである。
ステップＳＴ２００、ステップＳＴ２０２、ステップＳＴ２０４、ステップＳＴ２０５、ステップＳＴ２０６、ステップＳＴ２０７、ステップＳＴ２０９においては、通信相手がＧＵＩ装置１００からＧＵＩ装置１００ｂに変更になることを除いて、実施の形態１のイベント処理部３０６と実施の形態３のイベント処理部３０６ａの動作に違いはない。そのため、ここではこれらステップの説明を省略する。
【００６５】
［ステップＳＴ２０１ａ］：通信部３０５はイベント処理部３０６ｂに受信データを渡す。イベント処理部３０６ｂは、受信データの種類（ＩＤ、イベントリスト、ＩＤ＋差分）を判定する。ＩＤの場合は、イベント処理部３０６ｂが受信データに含まれるＩＤを記憶し、ステップＳＴ２０２に進む。イベントリストの場合は、イベント処理部３０６ｂが受信データに含まれるイベントリストを記憶し、ステップＳＴ２０３ａに進む。ＩＤ＋差分の場合は、ステップＳＴ２１１に進む。
【００６６】
［ステップＳＴ２１１］：イベント処理部３０６ｂは、ＩＤ管理部３０７に、受信データに含まれるＩＤを渡し、検索を要求する。ＩＤ管理部３０７は、前記ＩＤを用いて、イベントリスト記憶部３０８に一致する要素が登録されているか検索する。ここで、該当する要素を発見しなかった場合、イベント処理部３０６ｂは「生成失敗」と判断し、ステップＳＴ２０８ｂに進む。該当する要素を発見した場合、ＩＤ管理部３０７は、発見した要素に含まれるイベントリストをイベント処理部３０６ｂに渡し、イベント処理部３０６ｂは、前記イベントリストと、受信データ含まれるイベント差分リスト７１０を用いて、登録対象となるイベントリストを生成する。具体的には、ＩＤ管理部３０７から渡されたイベントリストに対して、操作種別７１１が「ＡＤＤ」となっている要素のイベント名７１２を追加し、操作種別７１１が「ＤＥＬ」となっている要素のイベント名７１２を削除する。その後、イベント処理部３０６ｂは、生成したイベントリストを内部に記憶し、「生成成功」と判断し、ステップＳＴ２０３ａに進む。
【００６７】
［ステップＳＴ２０３ａ］：イベント処理部３０６ｂは、ステップＳＴ２０１もしくはステップＳＴ２１１で記憶したイベントリストを用いてイベントリスト記憶部３０８を参照し、一致する要素が存在するか確認する。存在する場合、「該当あり」と判断し、ステップＳＴ２０４に進む。存在しない場合、「該当なし」と判断し、ステップＳＴ２０５に進む。
［ステップＳＴ２０８ｂ］：イベント処理部３０６ｂは、通信部３０５を介して、応答メッセージをＧＵＩ装置１００に送信する。応答メッセージには、ステップＳＴ２０１で取得した、もしくはステップＳＴ２０４でＩＤ管理部３０７から渡された、もしくはステップＳＴ２０５でＩＤ管理部３０７から渡されたＩＤを格納する。ただし、ステップＳＴ２０２で「取得失敗」の場合、もしくはステップＳＴ２１１で「生成失敗」の場合は、無効なＩＤを格納する。
【００６８】
この実施の形態におけるイベント発生時のサービス装置３００ｂの動作は、実施の形態１と同様であるため、ここでは説明を省略する。
【００６９】
また、この実施の形態において、サービス装置３００ｂからのイベント通知が発生した場合のＧＵＩ装置１００ｂの動作については、実施の形態１と同様であるため、ここでは説明を省略する（ＧＵＩ装置１００、サービス装置３００、イベント処理部１０５は、それぞれＧＵＩ装置１００ｂ、サービス装置３００ｂ、イベント処理部１０５ｂと読み替える）。
【００７０】
このように、実施の形態３のＧＵＩ装置１００ｂは、イベントリストをサービス装置３００ｂに送信する前に、イベントリスト記憶部１０６に登録されたイベントリストを用いて差分を生成し、差分のサイズが小さい場合、差分の生成に用いたイベントリストを一意に特定するＩＤと、生成した差分をサービス装置３００ｂに送信し、サービス装置３００ｂは、受信したＩＤと差分とイベントリスト記憶部３０８に格納されたイベントリストを用いて、登録対象のイベントリストを生成する。従って、イベントリストそのものを送信する場合より、通信量を削減できるといった効果がある。
【００７１】
また、この実施の形態の説明では、イベントリストの差分における要素数を基準に情報量が最小となるものを選択したが、例えばデータサイズを情報量の基準としても構わない。
【００７２】
なお、この実施の形態の説明では操作種別７１１に「ＡＤＤ」「ＤＥＬ」などの文字列を設定したが、数値で表現しても、この実施の形態により得られる効果は変わらない。
また、この実施の形態では、実施の形態１におけるＧＵＩ装置１００、サービス装置３００に対して追加した手順を説明したが、実施の形態２におけるＧＵＩ装置１００ａ、サービス装置３００ａに対しても同様の手順を追加することにより、この実施の形態の効果が得られることは言うまでもない。
【００７３】
以上説明したように、実施の形態３の通信システムによれば、ＧＵＩ装置側イベント処理部は、ＧＵＩ装置側イベントリスト記憶部に登録されていないイベントリストをサービス装置に送信する場合、送信対象イベントリストと、ＧＵＩ装置側イベントリスト記憶部に登録済みのイベントリストとの差分を生成し、生成した差分を示す情報量が、送信対象イベントリストの情報量よりも小さい場合は、送信対象イベントリストの代わりに、生成した差分と、差分を生成するために用いたＧＵＩ装置側イベントリスト記憶部に登録済みのイベントリストを一意に特定するＩＤとをサービス装置に送信し、サービス装置側イベント処理部は、ＧＵＩ装置からＩＤと差分を受信した場合、ＩＤを用いてサービス装置側イベントリスト記憶部からイベントリストを取得し、取得したイベントリストと差分を用いて新たなイベントリストを生成し、生成した新たなイベントリストをＧＵＩ装置から受信したイベントリストに代えて処理を行うようにしたので、さらにＧＵＩ装置とサービスサービス装置間の通信量を削減することができる。
【００７４】
実施の形態４．
実施の形態１〜３では、サービス装置３００（サービス装置３００ａ、サービス装置３００ｂ）で発生したイベントは、イベント処理部３０６（イベント処理部３０６ａ、イベント処理部３０６ｂ）における通知判定を行った後、直ぐにＧＵＩ装置１００（ＧＵＩ装置１００ａ、ＧＵＩ装置１００ｂ）に通知する動作としていた。イベントの発生周期や頻度は、発生元であるサービス装置の仕様により定められることが多いが、ＧＵＩ装置の仕様によっては、サービスの仕様によりも長い周期や少ない頻度の通知とすることが望ましい場合がある。しかし、ＧＵＩ装置の都合でサービス装置の仕様を変更することは望ましくない。そこで、実施の形態４では、ＧＵＩ装置からイベント毎に通知周期を設定する仕組みを追加することにより、サービス装置の仕様を変更することなく、通知周期を変更できるようにする。また、同じ通知周期のイベントをまとめて通知することで、サービス装置とＧＵＩ装置間の通信回数を削減する。
【００７５】
この発明の実施の形態４におけるシステム全体の構成を図１５に示す。
システムはＧＵＩ装置１００ｃとサービス装置３００ｃがネットワーク２００を介して接続した構成となっている。
【００７６】
ＧＵＩ装置１００ｃは、表示部１０１、ＧＵＩロジック処理部１０２ｃ、要求処理部１０３、通信部１０４、イベント処理部（ＧＵＩ装置側イベント処理部）１０５ｃ、イベントリスト記憶部１０６、インターフェース部１０７を備える。表示部１０１、要求処理部１０３、通信部１０４、イベントリスト記憶部１０６、インターフェース部１０７については、実施の形態１と同様の構成であるため、ここでの説明は省略する。
【００７７】
ＧＵＩロジック処理部１０２ｃは、表示部１０１に表示するＧＵＩを構築したり、インターフェース部１０７との入出力を担当したりする装置である。また、ＧＵＩロジック処理部１０２ｃは、要求処理部１０３を介してサービス装置３００に要求を発行したり、イベント処理部１０５ｃから通知されたイベントに基づき表示部１０１に表示するＧＵＩを変更したり、インターフェース部１０７を介してＧＵＩ以外の出力を行ったりする。ＧＵＩロジック処理部１０２ｃは、イベント処理部１０５ｃに対して、各画面に必要なイベントをイベント処理部１０５ｃに提供するとき、各イベントの通知周期も併せて提供する。
イベント処理部１０５ｃは、ＧＵＩ装置１００ｃにおけるイベントに関する処理を担当する装置であり、実施の形態１におけるイベント処理部１０５に対して、イベント毎の通知周期を設定する機能と、複数のイベントを含む通知に対応する機能を追加したものである。
【００７８】
サービス装置３００ｃは、サービス処理部３０１、要求処理部３０４、通信部３０５、イベント処理部（サービス装置側イベント処理部）３０６ｃ、ＩＤ管理部３０７、イベントリスト記憶部３０８、イベント蓄積部３０９を備える。サービス処理部３０１、要求処理部３０４、通信部３０５、ＩＤ管理部３０７については、実施の形態１と同様の構成であるため、ここでの説明は省略する。
イベント処理部３０６ｃは、サービス装置３００ｃにおけるイベントに関する処理を担当する装置であり、実施の形態１におけるイベント処理部３０６に対して、イベントの通知周期を設定する機能と、複数のイベントをまとめて通知する機能を追加したものである。イベント蓄積部３０９は、通知対象のイベントを一時的に記憶するための装置である。
【００７９】
図１６は、この実施の形態におけるイベントリスト８００の構成を示す図である。イベントリスト８００は、イベント名８１１と通知周期８１２の組を一要素とした場合、０個以上の要素を格納する。図１６の例では、（イベント名８１１ｐと通知周期８１２ｐの組）〜（イベント名８１１ｓと通知周期８１２ｓ）の組の４組が格納されている。なお、イベントリスト８００の終端は、要素数もしくは終端を意味する要素により認識可能だが、図１６では省略している。
【００８０】
次に、ＧＵＩ装置１００ｃとサービス装置３００ｃの動作について、図１５、図１６、図１７、図１８、図１９、図２０を用いて説明する。
図１７は、この実施の形態におけるイベントリスト登録時のＧＵＩ装置１００ｃの動作を示すフローチャートである。
ステップＳＴ１００、ステップＳＴ１０４、ステップＳＴ１０５、ステップＳＴ１０６、ステップＳＴ１０８においては、イベントリスト４００がイベントリスト８００に変更になることと、通信相手がサービス装置３００からサービス装置３００ｃに変更になることを除き、実施の形態１のイベント処理部１０５と実施の形態４のイベント処理部１０５ｃの動作に違いはない。そのため、ここでは実施の形態１と同様のステップについてはその説明を省略する。
【００８１】
［ステップＳＴ１０１ａ］：ＧＵＩロジック処理部１０２ｃは、遷移後の画面で必要なイベントと通知周期をイベント処理部１０５ｃに提供する。イベント処理部１０５ｃは、ＧＵＩロジック処理部１０２ｃから提供された０個以上のイベントと通知周期の組を用いてイベントリスト８００を作成し、内部に一時的に記憶する。
［ステップＳＴ１０２ａ］：イベント処理部１０５ｃは、ステップＳＴ１０１ａで内部に一時的に記憶したイベントリスト８００を用いて、イベントリスト記憶部１０６にイベントリスト８００に一致する要素が登録されているかを検索する。「未登録」の場合は、ステップＳＴ１０３ａに進む。「登録済」の場合は、該当する要素に記憶されているＩＤを取得し、ステップＳＴ１０４に進む。
［ステップＳＴ１０３ａ］：イベント処理部１０５ｃは、通信部１０４を介して、サービス装置３００ｃにイベントリスト８００を送信する。
［ステップＳＴ１０７ａ］：イベント処理部１０５ｃは、ステップＳＴ１０５で受信したＩＤとステップＳＴ１０１ａで内部に一時的に記憶したイベントリスト８００の組を、イベントリスト記憶部１０６に登録する。
【００８２】
図１８は、この実施の形態におけるイベントリスト登録時のサービス装置３００ｃの動作を示すフローチャートである。
ステップＳＴ２００、ステップＳＴ２０１、ステップＳＴ２０２、ステップＳＴ２０４、ステップＳＴ２０５、ステップＳＴ２０６、ステップＳＴ２０７、ステップＳＴ２０８、ステップＳＴ２０９においては、通信相手がＧＵＩ装置１００からＧＵＩ装置１００ｃに変更になることを除き、実施の形態１のイベント処理部３０６と実施の形態４のイベント処理部３０６ｃの動作に違いはない。そのため、ここではこれらのステップの説明を省略する。
【００８３】
［ステップＳＴ２０３ｂ］：イベント処理部３０６ｃは、ステップＳＴ２０１で記憶したイベントリストを用いてイベントリスト記憶部３０８を参照し、一致する要素が存在するか確認する。存在する場合、「該当あり」と判断し、ステップＳＴ２０４に進む。存在しない場合、「該当なし」と判断し、ステップＳＴ２０５に進む。なお、実施の形態１におけるステップＳＴ２０３との違いは、イベントリストの一致判定に、通知周期も用いることである。
［ステップＳＴ２１２］：イベント処理部３０６ｃは、まずイベント蓄積部３０９に存在するイベントキューをすべてクリアする。各イベントキューには通知周期を設定できる（後述する図２０に示す）が、その設定もクリアする。次に、イベント処理部３０６ｃは、内部に記憶したイベントリストの各要素の通知周期を参照し、イベント蓄積部３０９にその周期向けのイベントキューが存在するか確認し、存在しない場合はイベント蓄積部３０９にイベントキューを生成するか、もしくは通知周期が未設定のイベントキューに通知周期を設定する。なお、周期が０ｍｓの場合は、イベントキューへの蓄積は行わないため、イベントキューを生成しない。最後に、イベント処理部３０６ｃは、通知周期を設定したイベントキュー毎に、通知周期毎に発火する（通知周期毎に通知のためのトリガを発生させる）タイマを準備し、開始する。
【００８４】
図１９は、この実施の形態におけるイベント発生時のサービス装置３００ｃの動作を示すフローチャートである。
ステップＳＴ３００、ステップＳＴ３０１、ステップＳＴ３０２、ステップＳＴ３０３においては、ステップＳＴ３０１で「通知対象」と判断した場合に次の処理がステップＳＴ３０４になることと、通信相手がサービス装置３００からサービス装置３００ｃに変更になることを除き、実施の形態１のイベント処理部３０６と実施の形態４のイベント処理部３０６ｃの動作に違いはない。そのため、ここではこれらのステップの説明を省略する。
【００８５】
［ステップＳＴ３０４］：イベント処理部３０６ｃは、サービス処理部３０１から渡されたイベントの名称に基づき、内部に記憶しているイベントリストから、前記イベントの通知周期を取得し、０ｍｓの場合はステップＳＴ３０２に進む。０ｍｓ以外の場合、ステップＳＴ３０５に進む。
［ステップＳＴ３０５］：イベント処理部３０６ｃは、ステップＳＴ３０４で取得した周期を用いて、イベント蓄積部３０９から該当するイベントキューを特定し、サービス処理部３０１から渡されたイベントを格納する。
【００８６】
図２０は、イベントキューとタイマとの関係を示す説明図である。
図示例では、イベントキュー３１０ａには、ＳｅｒｖｉｃｅＢ＿ＥｖｅｎｔＸが２個格納され、イベントキュー３１０ｂには、ＳｅｒｖｉｃｅＡ＿ＥｖｅｎｔＣが２個、ＳｅｒｖｉｃｅＡ＿ＥｖｅｎｔＡが１個格納されている。また、イベントキュー３１０ａは２００ｍｓ毎に発火するタイマ３１１ａが、イベントキュー３１０ｂには１００ｍｓ毎に発火するタイマ３１１ｂがそれぞれ対応付けられている。
【００８７】
このようにイベントキューとタイマが関連付けられた状態で、いずれかのタイマが発火した場合、イベント処理部３０６ｃは、発火したタイマに対応するイベントキューからイベントをすべて取り出し、通信部３０５を介してＧＵＩ装置１００ｃに通知する。その後、イベントキューに設定された周期を用いて、タイマを開始する。すなわち、タイマは発火が終了するとその後は動作を行わないため、再度タイマを開始させ、イベントキューからイベントを取り出し通知するという動作を周期的に行う。なお、イベントキュー３１０が空の場合は、通知を行わない。これらの動作については図示しない。
【００８８】
サービス装置３００ｃから複数のイベントが通知され、このような複数のイベントが含まれた通知がＧＵＩ装置１００ｃに届いた場合、通信部１０４は受信した内容をイベント処理部１０５ｃに渡し、イベント処理部１０５ｃは受信した内容に含まれる個々のイベントをＧＵＩロジック処理部１０２ｃに渡す。これらの動作については図示しない。
【００８９】
このように、実施の形態４のＧＵＩ装置１００ｃは、各イベントの通知周期を含むイベントリストをサービス装置３００ｃに送信し、サービス装置３００ｃは受信したイベントリストに含まれる通知周期に基づきイベントキューを設けてタイマを開始し、イベント発生時はイベント毎の通知周期に基づきイベントキューにイベントを蓄積し、タイマが発火した場合はイベントキューに蓄積されたイベントをまとめて通知し、複数のイベントが格納された通知を受信したＧＵＩ装置１００ｃは、各イベントをＧＵＩロジック処理部１０２ｃに渡す。従って、イベント発生毎に通知する場合と比べて、通知回数を削減できるといった効果がある。
【００９０】
また、上記説明では通知対象のイベントであれば、常にイベントキューに蓄積するとしたが、ＧＵＩ装置に対して同じイベントを複数個通知する必要はない場合が多い。そこで、ステップＳＴ３０５の動作に先立って、蓄積対象のイベントキューを走査し、同じイベントが蓄積されている場合は、イベントの蓄積を行わないようにしても構わない。この動作を図２１に示す。ここで、ステップＳＴ３０６におけるイベント存在確認のステップ以外のステップは図１９に示す各ステップと同様であるため、ステップＳＴ３０６についてのみ説明する。
［ステップＳＴ３０６］：イベント処理部３０６ｃは、ステップＳＴ３０４の周期確認において、周期が０ｍｓ以外であった場合、同じイベントがイベントキューに蓄積されているか否かを確認する。蓄積済みであった場合は、そのままステップＳＴ３０３に移行して終了し、蓄積されていない場合はステップＳＴ３０５に移行する。これにより、設定された周期毎に通知されるイベントの個数を削減できるといった効果がある。
【００９１】
また、イベントキューに同じイベントが蓄積されている場合、蓄積されているイベントを削除し、改めて蓄積対象イベントをイベントキューに追加しても構わない。この動作を図２２に示す。ここで、ステップＳＴ３０７におけるイベント削除のステップ以外は図２１に示す各ステップと同様であるため、ステップＳＴ３０７についてのみ説明する。
［ステップＳＴ３０７］：イベント処理部３０６ｃは、ステップＳＴ３０６のイベント存在確認において、同じイベントが既に蓄積済みであった場合、既に蓄積されている同じイベントを削除し、ステップＳＴ３０５に移行する。このような動作により、イベントキューへの蓄積をイベント発生時刻順とすることができる。
【００９２】
また、上記説明ではイベントを一意に特定する情報としてイベント名を用いているが、イベントが何らかのパラメータを持つ場合、イベントキューへの蓄積可否の判断に、このパラメータも併せて用いても構わない。例えば、ＳｅｒｖｉｃｅＡ＿ＥｖｅｎｔＡが２個のパラメータ（ｐａｒａｍ＿ａ，ｐａｒａｍ＿ｂ）を持つとする。
イベントキューには、ＳｅｒｖｉｃｅＡ＿Ｅｖｅｎｔ（１，２００）というイベントが蓄積されているとする。この状態でＳｅｒｖｉｃｅＡ＿Ｅｖｅｎｔ（２，２００）というイベントが発生した場合を考える。ここでは、上述した図２１及び図２２の動作におけるステップＳＴ３０６の「イベント存在確認」において、パラメータの値も用いてイベントの同一性を判定する。このため、イベント処理部３０６ｃは、ＳｅｒｖｉｃｅＡ＿Ｅｖｅｎｔ（１，２００）とＳｅｒｖｉｃｅＡ＿Ｅｖｅｎｔ（２，２００）は異なるイベントであると判定し、結果としてＳｅｒｖｉｃｅＡ＿Ｅｖｅｎｔ（２，２００）はイベントキューに格納される。
【００９３】
なお、上記説明ではイベントリスト８００の通知周期８１２に「ｍｓ」と単位まで記述したが、イベントリスト８００の記述仕様がＧＵＩ装置１００ｃとサービス装置３００ｃの間で明確に決められている場合は、単位を省略しても構わない。これは、通知周期８１２が文字列でなく数値でもこの実施の形態の効果が変わらないことを意味する。
【００９４】
また、実施の形態４では、実施の形態１におけるＧＵＩ装置１００、サービス装置３００に対して追加した手順を説明したが、実施の形態２と実施の形態３におけるＧＵＩ装置１００ａ、ＧＵＩ装置１００ｂ、サービス装置３００ａ、サービス装置３００ｂに対しても同様の手順を追加することにより、この実施の形態の効果が得られることは言うまでもない。
【００９５】
さらに、実施の形態３における差分の表現において、イベントの名称は同じで通知周期のみ異なる場合は、操作種別７１１に通知周期のみを差し替えるための種別を追加することで、操作種別７１１が「ＤＥＬ」「ＡＤＤ」の２種類の場合より、差分のサイズを削減することができる。例えば、これを図１６を用いて説明する。
【００９６】
図１６では、ＳｅｒｖｉｃｅＡ＿ＥｖｅｎｔＡに対して周期１００ｍｓを設定している。図１６のイベントリストがサービス処理部３０１で使用されている状態として、周期を２００ｍｓに変更する場合の差分記述を考える。
ＤＥＬとＡＤＤを組み合わせた場合は、イベント差分リストは次のような記述となる。（１）ＤＥＬ，ＳｅｒｖｉｃｅＡ＿ＥｖｅｎｔＡ
（２）ＡＤＤ，ＳｅｒｖｉｃｅＡ＿ＥｖｅｎｔＡ，２００ｍｓ
一方、操作種別にＲＥＰＬＡＣＥを追加する。これは、イベントリストの通知周期のみを書き換えるものである。イベント差分リストは以下のように記述することができる。
（１）ＲＥＰＬＡＣＥ，ＳｅｒｖｉｃｅＡ＿ＥｖｅｎｔＡ，  ２００ｍｓ
このように、差分のサイズは通知周期のみを差し替えるための種別を用いた方が小さくすることができる。
【００９７】
以上説明したように、実施の形態４の通信システムによれば、ＧＵＩ装置側イベント処理部は、サービス装置にイベントリストを送信する場合、各イベントにサービス装置からの通知間隔の情報を付加し、かつ、サービス装置は、各イベントの通知間隔に対応したイベントキューを格納するイベント蓄積部を備え、サービス装置側イベント処理部は、サービス処理部のサービスによって発生するイベントがＧＵＩ装置から通知されたイベントであった場合は、イベントの通知間隔に対応したイベントキューにそのイベントを格納すると共に、イベントキューの通知タイミングになった場合は、イベントキューに格納されているイベントをＧＵＩ装置に通知するようにしたので、サービス装置の仕様を変更することなく、通知周期を変更することができる。また、サービス装置とＧＵＩ装置間の通信回数を削減することができる。
【００９８】
また、実施の形態４の通信システムによれば、サービス装置側イベント処理部は、イベントキューにイベントを格納する際、既に同じイベントが格納されていた場合は、イベントの格納を行わないか、既に格納されていたイベントを削除してからイベントを格納するようにしたので、設定された周期毎に通知されるイベントの個数を削減することができる。
【００９９】
また、実施の形態４の通信システムによれば、サービス装置側イベント処理部は、イベントがパラメータを有する場合、イベントキューに既に同じイベントが格納されているか否かの同一性判定をパラメータを含めて行うようにしたので、ＧＵＩ装置がイベントに含まれるパラメータの値に基づき表示を変える場合に、必要なイベントをサービス装置で捨ててしまうといったことがなく、意図したＧＵＩの変更が可能となる。
【０１００】
なお、本願発明はその発明の範囲内において、各実施の形態の自由な組み合わせ、あるいは各実施の形態の任意の構成要素の変形、もしくは各実施の形態において任意の構成要素の省略が可能である。
【符号の説明】
【０１０１】
１００，１００ａ，１００ｂ，１００ｃ  ＧＵＩ装置、１０１  表示部、１０２  ＧＵＩロジック処理部、１０３  要求処理部、１０４  通信部、１０５，１０５ａ，１０５ｂ，１０５ｃ  イベント処理部、１０６  イベントリスト記憶部、１０７  インターフェース部、２００  ネットワーク、３００，３００ａ，３００ｂ，３００ｃ  サービス装置、３０１  サービス処理部、３０２  サービスＡ、３０３  サービスＢ、３０４  要求処理部、３０５  通信部、３０６，３０６ａ，３０６ｂ，３０６ｃ  イベント処理部、３０７  ＩＤ管理部、３０８  イベントリスト記憶部、３０９  イベント蓄積部、３１０ａ，３１０ｂ  イベントキュー、３１１ａ，３１１ｂ  タイマ、４００，４００Ａ，４００Ｂ，８００  イベントリスト、５００，５００Ａ，５００Ｂ  ＩＤ、６００  登録結果、６１０  削除ＩＤリスト、７００  イベントリスト登録要求、７１０  イベント差分リスト、８１１ｐ〜８１１ｓ  イベント名、８１２ｐ〜８１２ｓ  通知周期。
【手続補正２】
【補正対象書類名】特許請求の範囲
【補正対象項目名】全文
【補正方法】変更
【補正の内容】
【特許請求の範囲】
【請求項１】
イベント通知に基づき画面構築を行うＧＵＩ装置と、サービスを実行してイベントを発生するサービス装置とがネットワークを介して接続され、相互に通信を行う通信システムにおいて、
前記ＧＵＩ装置は、
前記イベントの一覧であるイベントリストと、当該イベントリストに対応するＩＤを格納するＧＵＩ装置側イベントリスト記憶部と、
前記ＧＵＩ装置側イベントリスト記憶部を参照し、前記画面構築に必要なイベントリストと一致するイベントリストが存在する場合は、前記イベントリストに対応するＩＤを取得し、取得したＩＤを前記イベントリストの代わりに前記サービス装置に送信するＧＵＩ装置側イベント処理部と、
を備えることを特徴とする通信システム。
【請求項２】
前記サービス装置は、
前記イベントの一覧であるイベントリストと、当該イベントリストに対応するＩＤを格納するサービス装置側イベントリスト記憶部と、
前記ＧＵＩ装置から前記ＩＤを受信した場合に、前記サービス装置側イベントリスト記憶部を参照し、前記受信したＩＤに対応するイベントリストが存在する場合は、受信したＩＤを前記ＧＵＩ装置への応答メッセージに含めて送信するサービス装置側イベント処理部と、を備え、
前記ＧＵＩ装置側イベント処理部は、前記ＩＤを前記サービス装置に送信した結果として得られる応答メッセージに有効なＩＤが含まれる場合は、当該応答メッセージに含まれるＩＤと、前記サービス装置に対して送信したイベントリスト、または、その代わりにＩＤを送信したイベントリストとを１個の組として前記ＧＵＩ装置側イベントリスト記憶部に記憶させる
ことを特徴とする請求項１記載の通信システム。
【請求項３】
前記サービス装置は、
前記サービスを実行し、前記イベントを発生させるサービス処理部と、
前記サービス処理部の前記サービスによって発生する前記イベントに対して、当該イベントが含まれるイベントリストが前記ＧＵＩ装置への通知対象となっているかを判定し、通知対象となっている場合に、前記イベントを前記ＧＵＩ装置に通知するサービス装置側イベント処理部と、
を備えることを特徴とする請求項１記載の通信システム。
【請求項４】
前記サービス装置は、
前記イベントの一覧であるイベントリストと、当該イベントリストに対応するＩＤを格納するサービス装置側イベントリスト記憶部と、
前記イベントリストと前記ＩＤとの関係を管理するＩＤ管理部と、
前記ＧＵＩ装置から前記イベントリストを受信した場合、前記サービス装置側イベントリスト記憶部を参照し、前記受信したイベントリストと一致するイベントリストが存在する場合は、そのイベントリストに対応するＩＤを取得し、当該ＩＤを前記ＧＵＩ装置への応答メッセージに含めて送信し、一方、前記サービス装置側イベントリスト記憶部を参照した結果、受信したイベントリストと一致するイベントリストが存在しない場合は、前記ＩＤ管理部から前記サービス装置側イベントリスト記憶部に登録されていないＩＤを取得して、当該取得したＩＤと前記受信したイベントリストとを１個の組として、前記サービス装置側イベントリスト記憶部に登録し、前記取得したＩＤを前記ＧＵＩ装置への応答メッセージに含めて送信するサービス装置側イベント処理部と、
を備えることを特徴とする請求項１記載の通信システム。
【請求項５】
前記サービス装置側イベント処理部は、前記ＧＵＩ装置から受信したイベントリストと、当該イベントリストに対応するＩＤの組を前記サービス装置側イベントリスト記憶部に登録する前に、当該サービス装置側イベントリスト記憶部に登録可能なデータサイズを超えるかを判定し、超える場合は、超えない状態になるように、前記サービス装置側イベントリスト記憶部に登録済みのイベントリストとＩＤとの組を削除し、その状態で、前記ＧＵＩ装置から受信したイベントリストと当該イベントリストに対応するＩＤの組を前記サービス装置側イベントリスト記憶部に登録し、一方、削除したイベントリストに対応するＩＤを前記ＧＵＩ装置への応答メッセージに含めて送信し、
前記ＧＵＩ装置側イベント処理部は、イベントリストまたはＩＤを前記サービス装置に送信した結果として得られる応答メッセージに前記サービス装置側イベントリスト記憶部で削除されたＩＤが含まれる場合は、当該削除されたＩＤに対応したイベントリストを前記ＧＵＩ装置側イベントリスト記憶部から削除する
ことを特徴とする請求項４記載の通信システム。
【請求項６】
前記ＧＵＩ装置側イベント処理部は、イベントリストまたはＩＤを前記サービス装置に送信した結果として得られる応答メッセージにＩＤが含まれる場合、前記ＧＵＩ装置側イベントリスト記憶部に登録可能なデータサイズを超えるかを判定し、超える場合は、超えない状態になるように、前記ＧＵＩ装置側イベントリスト記憶部に登録済みのイベントリストとＩＤとの組を削除し、その状態で、前記応答メッセージに含まれるＩＤと、前記ＧＵＩ装置が送信したイベントリスト、またはその代わりにＩＤを送信したイベントリストとを１個の組として、前記ＧＵＩ装置側イベントリスト記憶部に登録することを特徴とする請求項４記載の通信システム。
【請求項７】
前記ＧＵＩ装置側イベント処理部は、前記ＧＵＩ装置側イベントリスト記憶部に登録されていないイベントリストを前記サービス装置に送信する場合、当該送信対象イベントリストと、前記ＧＵＩ装置側イベントリスト記憶部に登録済みのイベントリストとの差分を生成し、生成した差分を示す情報量が、前記送信対象イベントリストの情報量よりも小さい場合は、当該送信対象イベントリストの代わりに、前記生成した差分と、当該差分を生成するために用いた前記ＧＵＩ装置側イベントリスト記憶部に登録済みのイベントリストに対応するＩＤとを前記サービス装置に送信し、
前記サービス装置側イベント処理部は、前記ＧＵＩ装置から前記ＩＤと前記差分を受信した場合、当該ＩＤを用いて前記サービス装置側イベントリスト記憶部からイベントリストを取得し、当該取得したイベントリストと前記差分を用いて新たなイベントリストを生成し、当該生成した新たなイベントリストを前記ＧＵＩ装置から受信したイベントリストに代えて処理を行う
ことを特徴とする請求項４記載の通信システム。
【請求項８】
前記ＧＵＩ装置側イベント処理部は、前記サービス装置にイベントリストを送信する場合、各イベントに当該サービス装置からの通知間隔の情報を付加し、
前記サービス装置は、前記各イベントの通知間隔に対応したイベントキューを格納するイベント蓄積部を備え、
前記サービス装置側イベント処理部は、前記サービスによって発生するイベントが前記ＧＵＩ装置から通知されたイベントであった場合は、当該イベントの通知間隔に対応したイベントキューにそのイベントを格納すると共に、前記イベントキューの通知タイミングになった場合は、当該イベントキューに格納されているイベントを前記ＧＵＩ装置に通知する
ことを特徴とする請求項４記載の通信システム。
【請求項９】
前記サービス装置側イベント処理部は、イベントキューにイベントを格納する際、既に同じイベントが格納されていた場合は、前記イベントの格納を行わないか、もしくは既に格納されていたイベントを削除してから前記イベントを格納することを特徴とする請求項８記載の通信システム。
【請求項１０】
前記サービス装置側イベント処理部は、イベントがパラメータを有する場合、イベントキューに既に同じイベントが格納されているか否かの同一性判定を前記パラメータを含めて行うことを特徴とする請求項９記載の通信システム。
【請求項１１】
サービスを実行してイベントを発生するサービス装置とネットワークを介して接続され、前記サービス装置と相互に通信を行い、イベント通知に基づき画面構築を行うＧＵＩ装置において、
前記イベントの一覧であるイベントリストと、当該イベントリストに対応するＩＤを格納するＧＵＩ装置側イベントリスト記憶部と、
前記画面構築時に当該画面に必要なイベントリストを前記サービス装置に送信すると共に、当該送信前に、前記ＧＵＩ装置側イベントリスト記憶部を参照し、送信対象イベントリストと一致するイベントリストが存在する場合は、そのイベントリストに対応するＩＤを取得し、前記送信対象イベントリストの代わりに当該ＩＤを前記サービス装置に送信するＧＵＩ装置側イベント処理部と、
を備えることを特徴とするＧＵＩ装置。
【請求項１２】
イベント通知に基づき画面構築を行うＧＵＩ装置とネットワークを介して接続され、前記ＧＵＩ装置と相互に通信を行い、サービスを実行してイベントを発生するサービス装置において、
前記イベントの一覧であるイベントリストと、当該イベントリストに対応するＩＤを格納するサービス装置側イベントリスト記憶部と、
前記イベントリストと前記ＩＤとの関係を管理するＩＤ管理部と、
前記ＧＵＩ装置から前記イベントリストを受信した場合、前記サービス装置側イベントリスト記憶部を参照し、前記受信したイベントリストと一致するイベントリストが存在する場合は、そのイベントリストに対応するＩＤを取得し、当該ＩＤを前記ＧＵＩ装置への応答メッセージに含めて送信し、一方、前記サービス装置側イベントリスト記憶部を参照した結果、受信したイベントリストと一致するイベントリストが存在しない場合は、前記ＩＤ管理部から前記サービス装置側イベントリスト記憶部に登録されていないＩＤを取得して、当該取得したＩＤと前記受信したイベントリストとを１個の組として、前記サービス装置側イベントリスト記憶部に登録し、前記取得したＩＤを前記ＧＵＩ装置への応答メッセージに含めて送信し、前記ＧＵＩ装置からＩＤを受信した場合は、前記サービス装置側イベントリスト記憶部を参照し、前記受信したＩＤに対応するイベントリストが存在する場合は、受信したＩＤを前記ＧＵＩ装置への応答メッセージに含めて送信するサービス装置側イベント処理部と、
を備えることを特徴とするサービス装置。
【手続補正書】
【提出日】平成27年10月29日(2015.10.29)
【手続補正１】
【補正対象書類名】明細書
【補正対象項目名】００１０
【補正方法】変更
【補正の内容】
【００１０】
また、この発明に係るＧＵＩ装置は、サービスを実行してイベントを発生するサービス装置とネットワークを介して接続され、サービス装置と相互に通信を行い、イベント通知に基づき画面構築を行うＧＵＩ装置において、イベントの一覧であるイベントリストと、イベントリストに対応するＩＤを格納するＧＵＩ装置側イベントリスト記憶部と、ＧＵＩ装置側イベントリスト記憶部を参照し、画面構築に必要なイベントリストと一致するイベントリストが存在する場合は、そのイベントリストに対応するＩＤを取得し、取得したＩＤをイベントリストの代わりにサービス装置に送信するＧＵＩ装置側イベント処理部と、を備えるものである。
【手続補正２】
【補正対象書類名】特許請求の範囲
【補正対象項目名】全文
【補正方法】変更
【補正の内容】
【特許請求の範囲】
【請求項１】
イベント通知に基づき画面構築を行うＧＵＩ装置と、サービスを実行してイベントを発生するサービス装置とがネットワークを介して接続され、相互に通信を行う通信システムにおいて、
前記ＧＵＩ装置は、
前記イベントの一覧であるイベントリストと、当該イベントリストに対応するＩＤを格納するＧＵＩ装置側イベントリスト記憶部と、
前記ＧＵＩ装置側イベントリスト記憶部を参照し、前記画面構築に必要なイベントリストと一致するイベントリストが存在する場合は、前記イベントリストに対応するＩＤを取得し、取得したＩＤを前記イベントリストの代わりに前記サービス装置に送信するＧＵＩ装置側イベント処理部と、
を備えることを特徴とする通信システム。
【請求項２】
前記サービス装置は、
前記イベントの一覧であるイベントリストと、当該イベントリストに対応するＩＤを格納するサービス装置側イベントリスト記憶部と、
前記ＧＵＩ装置から前記ＩＤを受信した場合に、前記サービス装置側イベントリスト記憶部を参照し、前記受信したＩＤに対応するイベントリストが存在する場合は、受信したＩＤを前記ＧＵＩ装置への応答メッセージに含めて送信するサービス装置側イベント処理部と、を備え、
前記ＧＵＩ装置側イベント処理部は、前記ＩＤを前記サービス装置に送信した結果として得られる応答メッセージに有効なＩＤが含まれる場合は、当該応答メッセージに含まれるＩＤと、前記サービス装置に対して送信したイベントリスト、または、その代わりにＩＤを送信したイベントリストとを１個の組として前記ＧＵＩ装置側イベントリスト記憶部に記憶させる
ことを特徴とする請求項１記載の通信システム。
【請求項３】
前記サービス装置は、
前記サービスを実行し、前記イベントを発生させるサービス処理部と、
前記サービス処理部の前記サービスによって発生する前記イベントに対して、当該イベントが含まれるイベントリストが前記ＧＵＩ装置への通知対象となっているかを判定し、通知対象となっている場合に、前記イベントを前記ＧＵＩ装置に通知するサービス装置側イベント処理部と、
を備えることを特徴とする請求項１記載の通信システム。
【請求項４】
前記サービス装置は、
前記イベントの一覧であるイベントリストと、当該イベントリストに対応するＩＤを格納するサービス装置側イベントリスト記憶部と、
前記イベントリストと前記ＩＤとの関係を管理するＩＤ管理部と、
前記ＧＵＩ装置から前記イベントリストを受信した場合、前記サービス装置側イベントリスト記憶部を参照し、前記受信したイベントリストと一致するイベントリストが存在する場合は、そのイベントリストに対応するＩＤを取得し、当該ＩＤを前記ＧＵＩ装置への応答メッセージに含めて送信し、一方、前記サービス装置側イベントリスト記憶部を参照した結果、受信したイベントリストと一致するイベントリストが存在しない場合は、前記ＩＤ管理部から前記サービス装置側イベントリスト記憶部に登録されていないＩＤを取得して、当該取得したＩＤと前記受信したイベントリストとを１個の組として、前記サービス装置側イベントリスト記憶部に登録し、前記取得したＩＤを前記ＧＵＩ装置への応答メッセージに含めて送信するサービス装置側イベント処理部と、
を備えることを特徴とする請求項１記載の通信システム。
【請求項５】
前記サービス装置側イベント処理部は、前記ＧＵＩ装置から受信したイベントリストと、当該イベントリストに対応するＩＤの組を前記サービス装置側イベントリスト記憶部に登録する前に、当該サービス装置側イベントリスト記憶部に登録可能なデータサイズを超えるかを判定し、超える場合は、超えない状態になるように、前記サービス装置側イベントリスト記憶部に登録済みのイベントリストとＩＤとの組を削除し、その状態で、前記ＧＵＩ装置から受信したイベントリストと当該イベントリストに対応するＩＤの組を前記サービス装置側イベントリスト記憶部に登録し、一方、削除したイベントリストに対応するＩＤを前記ＧＵＩ装置への応答メッセージに含めて送信し、
前記ＧＵＩ装置側イベント処理部は、イベントリストまたはＩＤを前記サービス装置に送信した結果として得られる応答メッセージに前記サービス装置側イベントリスト記憶部で削除されたＩＤが含まれる場合は、当該削除されたＩＤに対応したイベントリストを前記ＧＵＩ装置側イベントリスト記憶部から削除する
ことを特徴とする請求項４記載の通信システム。
【請求項６】
前記ＧＵＩ装置側イベント処理部は、イベントリストまたはＩＤを前記サービス装置に送信した結果として得られる応答メッセージにＩＤが含まれる場合、前記ＧＵＩ装置側イベントリスト記憶部に登録可能なデータサイズを超えるかを判定し、超える場合は、超えない状態になるように、前記ＧＵＩ装置側イベントリスト記憶部に登録済みのイベントリストとＩＤとの組を削除し、その状態で、前記応答メッセージに含まれるＩＤと、前記ＧＵＩ装置が送信したイベントリスト、またはその代わりにＩＤを送信したイベントリストとを１個の組として、前記ＧＵＩ装置側イベントリスト記憶部に登録することを特徴とする請求項４記載の通信システム。
【請求項７】
前記ＧＵＩ装置側イベント処理部は、前記ＧＵＩ装置側イベントリスト記憶部に登録されていないイベントリストを前記サービス装置に送信する場合、当該送信対象イベントリストと、前記ＧＵＩ装置側イベントリスト記憶部に登録済みのイベントリストとの差分を生成し、生成した差分を示す情報量が、前記送信対象イベントリストの情報量よりも小さい場合は、当該送信対象イベントリストの代わりに、前記生成した差分と、当該差分を生成するために用いた前記ＧＵＩ装置側イベントリスト記憶部に登録済みのイベントリストに対応するＩＤとを前記サービス装置に送信し、
前記サービス装置側イベント処理部は、前記ＧＵＩ装置から前記ＩＤと前記差分を受信した場合、当該ＩＤを用いて前記サービス装置側イベントリスト記憶部からイベントリストを取得し、当該取得したイベントリストと前記差分を用いて新たなイベントリストを生成し、当該生成した新たなイベントリストを前記ＧＵＩ装置から受信したイベントリストに代えて処理を行う
ことを特徴とする請求項４記載の通信システム。
【請求項８】
前記ＧＵＩ装置側イベント処理部は、前記サービス装置にイベントリストを送信する場合、各イベントに当該サービス装置からの通知間隔の情報を付加し、
前記サービス装置は、前記各イベントの通知間隔に対応したイベントキューを格納するイベント蓄積部を備え、
前記サービス装置側イベント処理部は、前記サービスによって発生するイベントが前記ＧＵＩ装置から通知されたイベントであった場合は、当該イベントの通知間隔に対応したイベントキューにそのイベントを格納すると共に、前記イベントキューの通知タイミングになった場合は、当該イベントキューに格納されているイベントを前記ＧＵＩ装置に通知する
ことを特徴とする請求項４記載の通信システム。
【請求項９】
前記サービス装置側イベント処理部は、イベントキューにイベントを格納する際、既に同じイベントが格納されていた場合は、前記イベントの格納を行わないか、もしくは既に格納されていたイベントを削除してから前記イベントを格納することを特徴とする請求項８記載の通信システム。
【請求項１０】
前記サービス装置側イベント処理部は、イベントがパラメータを有する場合、イベントキューに既に同じイベントが格納されているか否かの同一性判定を前記パラメータを含めて行うことを特徴とする請求項９記載の通信システム。
【請求項１１】
サービスを実行してイベントを発生するサービス装置とネットワークを介して接続され、前記サービス装置と相互に通信を行い、イベント通知に基づき画面構築を行うＧＵＩ装置において、
前記イベントの一覧であるイベントリストと、当該イベントリストに対応するＩＤを格納するＧＵＩ装置側イベントリスト記憶部と、
前記ＧＵＩ装置側イベントリスト記憶部を参照し、前記画面構築に必要なイベントリストと一致するイベントリストが存在する場合は、前記イベントリストに対応するＩＤを取得し、取得したＩＤを前記イベントリストの代わりに前記サービス装置に送信するＧＵＩ装置側イベント処理部と、
を備えることを特徴とするＧＵＩ装置。
【請求項１２】
イベント通知に基づき画面構築を行うＧＵＩ装置とネットワークを介して接続され、前記ＧＵＩ装置と相互に通信を行い、サービスを実行してイベントを発生するサービス装置において、
前記イベントの一覧であるイベントリストと、当該イベントリストに対応するＩＤを格納するサービス装置側イベントリスト記憶部と、
前記イベントリストと前記ＩＤとの関係を管理するＩＤ管理部と、
前記ＧＵＩ装置から前記イベントリストを受信した場合、前記サービス装置側イベントリスト記憶部を参照し、前記受信したイベントリストと一致するイベントリストが存在する場合は、そのイベントリストに対応するＩＤを取得し、当該ＩＤを前記ＧＵＩ装置への応答メッセージに含めて送信し、一方、前記サービス装置側イベントリスト記憶部を参照した結果、受信したイベントリストと一致するイベントリストが存在しない場合は、前記ＩＤ管理部から前記サービス装置側イベントリスト記憶部に登録されていないＩＤを取得して、当該取得したＩＤと前記受信したイベントリストとを１個の組として、前記サービス装置側イベントリスト記憶部に登録し、前記取得したＩＤを前記ＧＵＩ装置への応答メッセージに含めて送信し、前記ＧＵＩ装置からＩＤを受信した場合は、前記サービス装置側イベントリスト記憶部を参照し、前記受信したＩＤに対応するイベントリストが存在する場合は、受信したＩＤを前記ＧＵＩ装置への応答メッセージに含めて送信するサービス装置側イベント処理部と、
を備えることを特徴とするサービス装置。
【国際調査報告】
2014006669.tif 000025
2014006669.tif 000026
2014006669.tif 000027
2014006669.tif 000028