JP5440004B2 - 情報配信システム、情報配信システムのサービス実現方法およびそのプログラム - Google Patents

Description

本発明は、送信者および受信者の間で相互に情報を配信する情報配信システム、情報配信システムのサービス実現方法およびそのプログラムに関するものである。

従来、コンピュータに接続されたプリンタ、ディスプレイ、カードリーダ等の複数種類のデバイス（受信者）に情報を配信する場合、コンピュータにアプリケーション・プログラム（送信者，以下、単に「アプリケーション」と称する。）をインストールし、当該アプリケーションから指令を出す。この場合、例えばこれら複数種類のデバイスに、一連の処理を実行させようとすると、第１のデバイスに動作を指令してそれに対するイベント情報を受け取り、次に第２のデバイスに動作を指令してそれに対するイベント情報を受け取る、といったデバイス毎の処理をアプリケーションに書き込む必要があり、アプリケーションの作成に手間がかかる。そこで、アプリケーションと複数のデバイスとの間に管理モジュールを介在させ、アプリケーションからは、デバイス名と処理内容（処理識別子）を管理モジュールに通知し、管理モジュールは当該通知内容をテーブルに書き込んで、各デバイスに対し、一連の処理を実行させるようにしたシステムが知られている（例えば、特許文献１）。この構成によれば、アプリケーションに、一連の処理を実行させるための処理内容を書き込む必要が無くなるため、作成が容易となる。また、デバイスの増減があった場合でも、アプリケーションの変更を最小限に留めることができる、などの利点がある。

特開２０００−２４２５９４号公報

ところが、上記特許文献１に記載のシステムでは、プリンタに印刷する印刷内容、レイアウトまたは書式などの修正が必要となった場合、アプリケーションの変更が必要となる。また、デバイスの入れ替えによって機種が変更となった場合も、送信する制御情報（コマンド）を変更しなければならないため、アプリケーションの変更が必要となる。このように、上記特許文献１に記載のシステムは、処理内容の変更や機種の違いを、管理モジュールによって吸収できる構成とはなっていない。

また、上記のシステムにおいて、第１のデバイスに情報を配信（動作を指令）し、正常に情報が配信できた場合は、次に第２のデバイスに別の情報を配信する、といった連携処理（逐次処理）を行うことも考えられるが、正常に情報が配信できたか否かの判別処理をアプリケーション側で行う必要があるため、結果的にデバイス毎の処理をアプリケーションに書き込む必要がある。したがって、連携処理を行う場合は、上記のシステムを適用しても、その効果が得られなかった。

そこで、処理内容の変更、並びに受信者の種類や仕様の変更に伴うアプリケーション変更の手間を軽減することができ、アプリケーションを介することなく複数の受信者による連携処理を実現可能とする情報配信システム、あるいは情報配信システムのサービス実現方法とそのプログラムが望まれていた。

本発明は、少なくとも上述の課題の一つを解決するように、下記の適用例または形態として実現され得る。

〔適用例１〕
本適用例の情報配信システムは、情報変換規則を示すスタイルシートを記憶する記憶部と、送信者から出力データを取得する出力データ取得部と、受信者の１つである第１の受信者に対応する第１の受信者情報は、前記第１の受信者の宛先と前記第１の受信者に対応した情報変換規則である第１のスタイルシートとを指定する第１の情報と、前記第１の受信者に対する配信の後に配信を受ける第２の受信者に対応する第２の受信者情報を指定する第２の情報とを含み、前記第１の受信者情報と前記第２の受信者情報とを含む配信情報を取得する配信情報取得部と、前記出力データを前記第１の受信者情報または前記第２の受信者情報が指定する前記スタイルシートによって変換した変換データを、前記第１の受信者または前記第２の受信者に配信する配信部と、前記配信部による前記変換データの配信が正常に行われたか否かを判別する配信判別部と、を備えた情報配信システムであって、前記配信部が、前記配信判別部による前記第１のスタイルシートにより変換された第１の変換データの前記第１の受信者への配信の成否判別の結果に従って、前記出力データを前記第２の受信者情報に基づき前記第２の受信者に配信することを特徴とする。

本適用例によれば、スタイルシートによって、送信者の出力データを変換データ（第１の変換データまたは第２の変換データ）に変換するため、処理内容が変更となった場合や、受信者の入れ替えがあった場合（種類や仕様の異なるデバイスに入れ替えられた場合など）でも、スタイルシートの書換えによって対応することができる。つまり、スタイルシートによって、処理内容の変更、並びにデバイスの種類や仕様の違いを吸収できるため、送信者のアプリケーションの作成が容易になると共に、処理内容の変更や受信者の入れ替えに伴う手間を軽減できる。

また、「配信情報」は、複数取得が可能とすることが好ましい。これにより、一つの「配信情報」に基づく処理を実行している最中であっても、次の「配信情報」を受理でき、効率の良い情報配信システムが実現できる。

また、「配信情報」を複数取得する場合は、「出力データ」に、その情報変換に利用する「配信情報」を指定する情報が付加されていることが好ましい。さらに、「配信情報」は、「出力データ」の送信者から取得しても良い。この場合、「配信情報」および「出力データ」は、同時に取得しても良い。このことにより、複数の「配信情報」から「出力データ」に対応する「配信情報」を特定することができる。

また、この場合、「配信情報」および「出力データ」は、別のタイミングで取得しても良い。このことにより、以前使用した配信情報の再利用が可能となるので複数の「配信情報」を都度個々に配信する必要がなく、配信データの量を削減できる。その結果、送信時間の短縮もできる。

さらに、「配信情報」は出力データの配信前に送信しておくことも可能である。これにより、同じ「配信情報」が使用できる場合は、同じ「配信情報」を都度個々に配信する必要がなく、配信データの量を削減できる。その結果、送信時間の短縮もできる。

〔適用例２〕
上述の適用例において、前記第２の受信者は、少なくとも、前記配信判別部により、前記第１の変換データの配信が正常に行なわれたと判別された場合に、前記配信部が第２の変換データを配信する前記第１の受信者に対する連携受信者であって、前記配信情報は、少なくとも、前記連携受信者の宛先と前記連携受信者に対応した情報変換規則である連携スタイルシートとを指定する受信者情報である連携受信者情報を含み、前記第２の変換データは、前記連携受信者情報に基づく前記連携スタイルシートによって前記出力データが変換された連携変換データであることを特徴とする。

本適用例によれば、情報配信システムは、第１の受信者情報に基づく情報配信が正常に行われた場合、第２の受信者としての連携受信者の連携受信者情報に基づく情報配信を行うことで、実体的に第２の受信者は第１の受信者としての機能を有することとなり、アプリケーション側は、出力データを１回出力するだけで、次々と複数の受信者を逐次的に動作させることができる。つまり、アプリケーションを介することなく、複数の受信者による連携処理を実現することができる。

〔適用例３〕
上述の適用例において、前記第２の受信者は、少なくとも、前記配信判別部により、前記第１の変換データの配信が正常に行なわれなかったと判別された場合に、前記配信部が第２の変換データを配信する前記第１の受信者に対する代替受信者であって、前記配信情報は、少なくとも、前記代替受信者の宛先と前記代替受信者に対応した情報変換規則である代替スタイルシートとを指定する受信者情報である代替受信者情報を含み、前記第２の変換データは、前記代替受信者情報に基づく前記代替スタイルシートによって前記出力データが変換された代替変換データである、ことを特徴とする。

本適用例によれば、第１の変換データの配信が正常に行われなかった場合は、第１の受信者に代わる代替受信者に対して、当該受信者に対応した第２のスタイルシートによって変換した第２の変換データを配信するため、第１の受信者と代替受信者の種類や仕様が異なる場合でも、アプリケーションを介することなく、第１の受信者に代わる代替受信者に出力データを配信することができる。

〔適用例４〕
上述の適用例において、前記配信情報は、前記第１の受信者情報と前記連携受信者情報と前記代替受信者情報とに続き、優先順位を有する１以上の連携受信者情報と優先順位を有する１以上の代替受信者情報の両方もしくは一方を含んでおり、前記配信部が、前記配信判別部により前記連携受信者情報もしくは前記代替受信者情報に基づく配信が正常に行われたと判別された場合、さらに優先順位の低い前記連携受信者情報に基づいて配信を行い、前記配信判別部により前記連携受信者情報もしくは前記代替受信者情報に基づく配信が正常に行われなかったと判別された場合、さらに優先順位の低い前記代替受信者情報に基づいて配信を行う、ことを特徴とする。

本適用例によれば、代替受信者によって代替受信が可能なため、出力データの連携配信を確実に達成できる。特に連携受信者情報に優先順を有する複数情報を持つことは、多数の受信者による連携処理を実現する。また代替受信者情報に優先順を有する複数情報を持つことは、未配信を確実に排除できる。

〔適用例５〕
上述の適用例において、前前記受信者情報は、配信エラーの判定基準となる制限時間を指定し、前記配信判別部は、前記制限時間到達時点において、前記第１の受信者、または前記連携受信者および前記代替受信者を含む前記第２の受信者への配信が終了していない場合、配信が正常に行われなかったと判別する、ことを特徴とする。

本適用例によれば、送信者が、配信エラーの判定基準となる制限時間を、受信者毎および出力データ毎に指定することができる。

〔適用例６〕
上述の適用例において、前記第１の受信者情報と、前記連携受信者情報または前記代替受信者情報を含む前記第２の受信者情報とは、前記送信者に対応した情報変換規則である入力用スタイルシートを含んでおり、前記受信者からの入力データを、前記入力用スタイルシートによって変換した入力変換データを、前記送信者に入力する応答部をさらに備えた、ことを特徴とする。

〔適用例７〕
上述の適用例において、前記出力データ取得部は、複数の前記送信者から前記出力データを取得可能であり、前記記憶部は、前記複数の送信者に対応した複数種類の前記入力用スタイルシートを記憶している、ことを特徴とする。

本適用例によれば、送信者は、受信者から入力された入力データを取得することができる。また、情報配信システムが、複数の送信者と提携している場合でも、送信者毎に入力用スタイルシートを指定できるため、各送信者に応じた入力変換データを入力することができる。

〔適用例８〕
上述の適用例において、前記送信者は、アプリケーションに相当すると共に、前記受信者は、デバイスまたは１のデバイスに複数の論理的構成が含まれる場合、そのいずれかの論理的構成に相当し、前記出力データ、前記第１の変換データ、前記第２の変換データ、前記入力データおよび前記入力変換データは、いずれもマークアップ文書である、ことを特徴とする。

本適用例によれば、アプリケーションから取得した情報をデバイスに配信する情報配信システムに、本発明を適用することができる。また、デバイスに代えて、１のデバイスに含まれる論理的構成（例えば、プリンタ複合機の場合、プリンタ、スキャナ、ブザーなど）を受信者とした情報配信システムに、本発明を適用することができる。また、マークアップ文書の記述言語として、ＸＭＬ（Ｅｘｔｅｎｓｉｂｌｅ Ｍａｒｋｕｐ Ｌａｎｇｕａｇｅ）が知られているが、これを用いることで、記述内容が機能を表すと共に特定の言語や文化に依存しないため設計が容易である、文書構造の曖昧さを排除できる、などの利点がある。

〔適用例９〕
上述の適用例において、前記記憶部は、前記出力データを、記述言語の異なる前記第１の変換データまたは前記第２の変換データに変換するための複数種類のスタイルシートを記憶しており、前記受信者は、解釈可能な記述言語が異なる複数種類のデバイスまたは複数種類の論理的構成を含む、ことを特徴とする。

本適用例によれば、一つの情報配信システムで、解釈可能な記述言語が異なる複数種類のデバイスまたは複数種類の論理的構成に対応することができる。これにより、例えばプリンタの処理をディスプレイに処理させる（印刷出力により情報提供していたが、これを画面表示によって実現できるようにした場合など）といったことも、アプリケーションの変更を必要とすることなくスタイルシートの書き換えだけで可能となる。従って、使用環境に応じて、デバイスの入れ替えを柔軟に行うことができる。

〔適用例１０〕
上述の適用例において、前記配信情報に、同一の優先順位を持った複数の受信者情報が含まれる、ことを特徴とする。

本適用例によれば、同一優先順位の受信者に同時に送信（同送）が可能となり、配信の確実性を高めることが可能となる。

〔適用例１１〕
本適用例の情報配信システムのサービス実現方法は、情報変換規則を示す複数のスタイルシートを記憶するデータベースを管理すると共に、少なくとも送信者から取得した情報を受信者に配信する情報配信システムのサービス実現方法であって、前記情報配信システムが、前記送信者から、出力データを取得するステップと、受信者の１つである第１の受信者に対応する第１の受信者情報は、前記第１の受信者の宛先と前記第１の受信者に対応した情報変換規則である第１のスタイルシートとを指定する第１の情報と、前記第１の受信者に対する配信の後に配信を受ける第２の受信者に対応する第２の受信者情報を指定する第２の情報とを含み、前記第１の受信者情報と前記第２の受信者情報を含む配信情報を取得するステップと、前記出力データを前記第１の受信者情報または前記第２の受信者情報が指定する前記スタイルシートによって変換した変換データを、前記第１の受信者または前記第２の受信者に配信するステップと、配信部による前記変換データの配信が正常に行われたか否かを判別するステップと、前記配信判別ステップによる前記第１のスタイルシートにより変換された第１の変換データの前記第１の受信者への配信の成否判別の結果に従って、前記出力データを前記第２の受信者情報に基づき第２のスタイルシートによって変換した第２の変換データを、前記第２の受信者に配信するステップと、を実行することを特徴とする。

上述の適用例によれば、スタイルシートによって、送信者の出力データを変換データ（第１の変換データまたは第２の変換データ）に変換するため、処理内容が変更となった場合や、受信者の入れ替えがあった場合（種類や仕様の異なるデバイスに入れ替えられた場合など）でも、スタイルシートの書換えによって対応することができる。つまり、スタイルシートによって、処理内容の変更、並びにデバイスの種類や仕様の違いを吸収できるため、送信者のアプリケーションの作成が容易になると共に、処理内容の変更や受信者の入れ替えに伴う手間を軽減できる。

〔適用例１２〕
上述の適用例において、前記第２の受信者は、少なくとも、前記配信判別ステップにより、前記第１の変換データの配信が正常に行われたと判別された場合に、前記配信ステップにより第２の変換データを配信する前記第１の受信者に対する連携受信者であって、前記配信情報は、少なくとも、前記連携受信者の宛先と前記連携受信者に対応した情報変換規則である連携スタイルシートとを指定する受信者情報である連携受信者情報を含み、前記第２の変換データは、前記連携受信者情報に基づく前記連携スタイルシートによって前記出力データが変換された連携変換データであることを特徴とする。

本適用例によれば、情報配信システムは、第１の受信者情報に基づく情報配信が正常に行われた場合、第２の受信者としての連携受信者の連携受信者情報に基づく情報配信を行うことで、実体的に第２の受信者は第１の受信者としての機能を有することとなり、アプリケーション側は、出力データを１回出力するだけで、次々と複数の受信者を逐次的に動作させることができる。つまり、アプリケーションを介することなく、複数の受信者による連携処理を実現することができる。

〔適用例１３〕
上述の適用例において、前記第２の受信者は、少なくとも、前記配信判別ステップにより、前記第１の変換データの配信が正常に行なわれなかったと判別された場合に、前記配信ステップにより第２の変換データを配信する前記第１の受信者に対する代替受信者であって、前記配信情報は、少なくとも、前記代替受信者の宛先と前記代替受信者に対応した情報変換規則である代替スタイルシートとを指定する受信者情報である代替受信者情報を含み、前記第２の変換データは、前記代替受信者情報に基づく前記代替スタイルシートによって前記出力データが変換された代替変換データである、ことを特徴とする。

本適用例によれば、第１の変換データの配信が正常に行われなかった場合は、第１の受信者に代わる代替受信者に対して、当該受信者に対応した第２のスタイルシートによって変換した第２の変換データを配信するため、第１の受信者と代替受信者の種類や仕様が異なる場合でも、アプリケーションを介することなく、第１の受信者に代わる代替受信者に出力データを配信することができる。

〔適用例１４〕
本適用例のプログラムは、コンピュータに、上述の適用例による情報配信システムのサービス実現方法における各ステップを実行させるためのものである。

本適用例によれば、処理内容の変更、並びに受信者の種類や仕様の変更に伴うアプリケーション変更の手間を軽減することができると共に、アプリケーションを介することなく複数の受信者による連携処理を実現可能な情報配信システムのサービスを実現することができる。

店内管理システムのシステム構成図である。 サーバーの機能ブロック図である。 「配信情報」および「配信結果」を示す問題領域モデル（Ｄｏｍａｉｎ Ｍｏｄｅｌ）である。 店内管理システムの情報配信処理を示すフローチャートである。 店内管理システムの応答処理を示すフローチャートである。 ＸＭＬ文書１（出力データ）の具体例を示す図である。 ＸＭＬ文書１（配信情報）の具体例を示す図である。 出力スタイルシート（ドリンク部門用）およびＸＭＬ文書２の具体例を示す図である。 出力スタイルシート（グリル部門用）およびＸＭＬ文書２の具体例を示す図である。 出力スタイルシート（サラダ部門用）およびＸＭＬ文書２の具体例を示す図である。 ＸＭＬ文書４（配信結果）の具体例を示す図である。 サーバーの代替処理を示すフローチャートである。 代替出力スタイルシートおよびＸＭＬ文書２の具体例を示す図である。 出力スタイルシートおよびＸＭＬ文書２の具体例を示す図である。 代替出力スタイルシートおよびＸＭＬ文書２の具体例を示す図である。 連携処理を含む逐次処理を実現する場合の「配信情報」を示す問題領域モデル（Ｄｏｍａｉｎ Ｍｏｄｅｌ）および処理の流れを示すブロック図である。 連携処理を含む逐次処理を示すフローチャートである。 連携処理を含む逐次処理を実現する場合のＸＭＬ文書１（配信情報）の具体例を示す図である。 連携処理を含む逐次処理を実現する場合のＸＭＬ文書４（配信結果）の具体例を示す図である。

以下、本発明の一実施形態に係る情報配信システム、情報配信システムのサービス実現方法およびそのプログラムについて、添付図面を参照しながら詳細に説明する。本発明は、送信者（アプリケーション）から取得した情報を、個々の受信者（デバイス）に好適な情報に変換して配信することにより、各受信者を統合的に制御することを特徴とするものである。そこで、本発明の情報配信システム等を、レストラン等の飲食店における店内管理システム（オーダリング端末から取得した注文情報に基づいて、キッチンプリンタや厨房機器等の各種デバイスを制御するシステム）に適用した場合を例示する。

図１は、本実施形態に係る店内管理システムＳＹのシステム構成図である。店内管理システムＳＹは、顧客からの注文を入力するオーダリング端末１０と、オーダーターミナルとして機能するコンピュータ２０（以下、「ＰＣ」と称する。）と、統合デバイス制御サービス４４が組み込まれたサーバー３０（情報配信システム）と、キッチンプリンタ６１や厨房機器６２等のデバイス５０と、を含む。また、ＰＣ２０、サーバー３０およびデバイス５０は、イントラネット等のネットワークＮＴを介して接続されている。

ＰＣ２０は、ＣＰＵ（Ｃｅｎｔｒａｌ Ｐｒｏｃｅｓｓｉｎｇ Ｕｎｉｔ）２１、ＲＯＭ（Ｒｅａｄ Ｏｎｌｙ Ｍｅｍｏｒｙ）２２、ＲＡＭ（Ｒａｎｄｏｍ Ａｃｃｅｓｓ Ｍｅｍｏｒｙ）２３、入力デバイス２４、通信インターフェース２５、ディスプレイ２６およびＨＤＤ（Ｈａｒｄ Ｄｉｓｋ Ｄｒｉｖｅ）２７を備えている。通信インターフェース２５は、オーダリング端末１０と無線通信を行うためのものであり、本実施形態では主に注文情報の受信に用いられる。

また、ＨＤＤ２７には、アプリケーション・プログラム４１（以下、単に「アプリケーション」と称する。）と、スタイルシート生成プログラム４２と、が記憶されている。アプリケーション４１は、情報配信対象となるデバイス５０（受信者）に対し、「送信者」として機能する。また、スタイルシート生成プログラム４２は、サーバー３０において、デバイス５０の各デバイスに対応した情報変換を行うための情報変換規則であるスタイルシートを生成するためのプログラムである。

一方、サーバー３０は、ＰＣ２０と同様に、一般的なコンピュータの構成を有しており、ＣＰＵ３１、ＲＯＭ３２、ＲＡＭ３３、入力デバイス３４、ディスプレイ３５および記憶装置３６とを備えている。記憶装置３６には、統合デバイス制御サービス４４と、デバイスサービス登録プログラム４６と、が記憶されていると共に、データベース４５を有している。データベース４５には、上記のスタイルシートや、デバイス５０に対応するデバイス制御サービス７３，７５（図２参照）に関する情報が登録される。

統合デバイス制御サービス４４は、本実施形態の骨子を成す構成要素である。統合デバイス制御サービス４４は、ＰＣ２０（アプリケーション４１）から取得した情報を、データベース４５から読み出したスタイルシートを用いて、デバイス５０に好適な情報に変換し、デバイス５０に対応したデバイス制御サービス７３，７５に出力する。また、デバイスサービス登録プログラム４６は、ネットワークＮＴ上に存在するデバイス制御サービス７３，７５の存在を統合デバイス制御サービス４４が認識できるように、予めデータベース４５に登録しておくためのプログラムである。

一方、デバイス５０としては、ＰＯＳターミナル５１、およびＰＯＳターミナル５１に接続されたキッチンプリンタ６１、厨房機器用のプロトコルコンバータ５２、およびプロトコルコンバータ５２に接続された厨房機器６２の他、ネットワークＮＴへの接続機能を有する各種デバイス（キッチンディスプレイ６３、照明機器６４、空調機器６５、映像・音響機器６６、テーブルディスプレイ６７、クーポン発券機６８）などを有している。なお、ＰＯＳターミナル５１に接続されたキッチンプリンタ６１や、プロトコルコンバータ５２に接続された厨房機器６２など、直接ネットワーク接続できないローカルデバイスの制御においては、ＰＯＳターミナル５１やプロトコルコンバータ５２が、アプリケーション４１から配信された情報を受信する「受信者」として機能する。

このように、店内管理システムＳＹは、オーダリング端末１０から出力された注文情報に応じて、上記のデバイス５０を統合的に制御する。具体的には、店内管理システムＳＹは、注文情報にグリル部門のオーダーが含まれる場合、厨房のグリル部門に設置されたキッチンプリンタ６１に、調理指示伝票を発行させる。また、店内管理システムＳＹは、注文情報にドリンク部門のオーダーが含まれる場合、ドリンク部門に設置された別のキッチンプリンタ６１に、調理指示伝票を発行させる。また、店内管理システムＳＹは、キッチンディスプレイ６３に、注文された料理のレシピ情報を表示させ、照明機器６４から、注文情報に応じた機器（間接照明、スポットライトなど）を選択して、注文情報に応じた照度で点灯させる。また、店内管理システムＳＹは、空調機器６５に、注文情報に応じた温度や湿度に調整するための指令を出し、映像・音響機器６６に、注文情報に応じた映像・音楽を注文情報に応じた画質・音質で映像・音声出力させる。さらに、店内管理システムＳＹは、オーダーした顧客が着席するテーブルのテーブルディスプレイ６７に、注文内容、オーダーされた料理の原材料情報、カロリー、アレルギー情報等を表示させ、クーポン発券機６８に、注文情報に応じたクーポン券を発行させる。このように、店内管理システムＳＹは、顧客の１回の注文に応じて、店内に配置された複数種類のデバイス５０の各ローカルデバイスを制御可能である。以下、その実現方法について、詳細に説明する。

図２は、サーバー３０の具体的な機能を示すブロック図である。サーバー３０は、上記の統合デバイス制御サービス４４およびデータベース４５を備えている。また、サーバー３０は、スタイルシート管理部７１、デバイス制御サービス管理部７２および既存デバイス５０ａ用のデバイス制御サービス７３を備えている。

スタイルシート管理部７１は、スタイルシートの管理（登録、削除、更新など）を行う。また、スタイルシート管理部７１は、スタイルシートを簡単に生成するためのスタイルシート生成ツール（図示省略）を、ＰＣ２０に提供する。スタイルシート生成ツールとしては、例えばキッチンプリンタ６１でレシート印刷を行うために、ＸＭＬＰＯＳ形式に変換するためのスタイルシートを対象にし、予め用意された項目を変更するだけで、フォーマットを変更できるようなツールを提供する。

デバイス制御サービス管理部７２は、デバイスサービス登録プログラム４６（図１参照）が実行されることによって機能するものであり、ネットワークＮＴ上に存在するデバイス制御サービス７３，７５の管理（登録、削除、更新など）を行う。なお、デバイス制御サービス管理部７２は、プライベートＵＤＤＩ（Ｕｎｉｖｅｒｓａｌ Ｄｅｓｃｒｉｐｔｉｏｎ，Ｄｉｓｃｏｖｅｒｙ ａｎｄ Ｉｎｔｅｇｒａｔｉｏｎ）を利用して、デバイス制御サービス７３，７５の検索や照会を行う。

デバイス制御サービス７３は、既存デバイス５０ａを制御するためのサービスである。なお、既存デバイスドライバを利用する場合は、既存デバイスドライバ用コマンド変換モジュールおよび既存ドライバＡＰＩ（いずれも図示省略）が更に必要となる。なお、デバイス５０の各ローカルデバイスによっては、デバイス制御サービス７５を内蔵しているものなど、サーバー３０内のデバイス制御サービス７３を必要としないものも存在する。そのようなデバイス５０（以下、「新デバイス５０ｂ」と称する。）については、統合デバイス制御サービス４４と、直接情報の入出力を行う。また、デバイス制御サービス７５は、ＷＳＤＬ（Ｗｅｂ Ｓｅｒｖｉｃｅｓ Ｄｅｓｃｒｉｐｔｉｏｎ Ｌａｎｇｕａｇｅ）によりサービスが定義されていれば、デバイス５０内およびサーバー３０内のいずれに存在していても良い。

一方、データベース４５は、スタイルシートを記憶するスタイルシートデータベース８１（記憶部）と、デバイス制御サービス７３，７５に関する情報（以下、「デバイス別サービス情報」と称する。）を記憶するデバイス別サービス情報データベース８２と、を有している。

スタイルシートデータベース８１は、ＰＣ２０から取得したスタイルシート（スタイルシート管理部７１によって登録されたスタイルシート）を記憶する。ここで、スタイルシートは、ＸＳＬ（Ｅｘｔｅｎｓｉｂｌｅ Ｓｔｙｌｅｓｈｅｅｔ Ｌａｎｇｕａｇｅ）で記述される。また、デバイス別サービス情報データベース８２は、デバイス制御サービス管理部７２によって登録されたデバイス別サービス情報を記憶する。ここで、デバイス別サービス情報は、ＷＳＤＬで記述される。

統合デバイス制御サービス４４は、通信インターフェース８４、ＸＭＬ（Ｅｘｔｅｎｓｉｂｌｅ Ｍａｒｋｕｐ Ｌａｎｇｕａｇｅ）文書変換部８５、およびデバイス別ＸＭＬ文書入出力部８６を有している。なお、請求項における「出力データ取得部」、「配信情報取得部」、「配信部」、「配信判別部」および「応答部」は、統合デバイス制御サービス４４に相当する。統合デバイス制御サービス４４は、主に、ＰＣ２０から情報を配信する情報配信処理、並びにデバイス５０（既存デバイス５０ａおよび新デバイス５０ｂ）からの応答処理を実現する。なお、情報配信処理に際して、アプリケーション４１またはその他の送信者から提供される情報を、以下「配信情報」と称する。当該「配信情報」は、アプリケーション４１から提供される場合、アプリケーション４１の出力データと同時に（出力データに添付されて）取得可能である。また、応答処理に際して、デバイス５０から入力される情報を、以下「配信結果」と称する。

例えば、情報配信処理を行う場合、通信インターフェース８４は、アプリケーション４１の出力データ（注文情報）と、その出力対象（情報配信対象）となる対象デバイスや出力用のスタイルシート（以下、「出力スタイルシート」と称する。）に関する情報を含む配信情報と、を取得する。これらはいずれもＸＭＬで記述されており、以下、「ＸＭＬ文書１」と総称する。また、ＸＭＬ文書変換部８５は、通信インターフェース８４から取得したＸＭＬ文書１を、スタイルシートデータベース８１から読み出した出力スタイルシートに基づいて、対象デバイスのデバイス制御コマンド（デバイス制御情報）を含むＸＭＬ文書（以下、「ＸＭＬ文書２（第１の変換データ，第２の変換データ）」と称する。）に変換する。なお、ＸＭＬ文書変換部８５は、ＸＳＬＴ（ＸＳＬ Ｔｒａｎｓｆｏｒｍａｔｉｏｎ）を利用して、ＸＭＬ文書を変換する。さらに、デバイス別ＸＭＬ文書入出力部８６は、ＸＭＬ文書変換部８５から取得したＸＭＬ文書２を、対象デバイスに対応するデバイス制御サービス７３，７５に出力する。

また、応答処理を行う場合、デバイス別ＸＭＬ文書入出力部８６は、デバイス５０からの配信結果（入力データ）を含むＸＭＬ文書（以下、「ＸＭＬ文書３」と称する。）を、ＸＭＬ文書変換部８５に入力する。ＸＭＬ文書変換部８５は、入力された当該ＸＭＬ文書３を、スタイルシートデータベース８１から読み出した入力用のスタイルシート（以下、「入力スタイルシート」と称する。）に基づいて、アプリケーション４１用のＸＭＬ文書（以下、「ＸＭＬ文書４（入力変換データ）」と称する。）に変換する。さらに、通信インターフェース８４は、ＸＭＬ文書変換部８５から取得したＸＭＬ文書４を、アプリケーション４１に入力する。

次に、図３の問題領域モデル（Ｄｏｍａｉｎ Ｍｏｄｅｌ）を参照し、情報配信処理に用いられる「配信情報」要素（ｃｌａｓｓ）、および応答処理に用いられる「配信結果」要素の詳細について説明する。なお、各情報要素に付加された大括弧は多重度を表すものである。多重度（Ｍｕｌｔｉｐｌｉｃｉｔｙ）とは、統一モデルリング言語（ＵＭＬ）の用語の一つで、配信情報などの要素情報を構成する各属性情報の個数を示している。多重度の一例として、
［１］ その属性(attribute)の個数は１個
［１．．＊］ その属性の個数は１個以上
［０．．１］ その属性の個数は０個以上１個以内
［０．．＊］ その属性の個数は０個以上
のように表記される。

図３（ａ）に示すように、「配信情報」要素は、１以上の「受信者情報（以下、「第１の受信者情報」と称する。）」属性を有している。ここで、複数の「受信者情報」属性を設定しておくことにより、アプリケーション４１による１回の出力データを、複数の受信者に対して同送することが可能となる（同送処理）。つまり、図３（ａ）において、同送受信者情報は、多重度の指定に基づいて、「配信情報」要素を構成する２個以上の「受信者情報」属性として表現されている。また、「受信者情報」要素は、受信者となる対象デバイス（デバイス制御サービス７３，７５）を特定するための「宛先情報」属性と、当該対象デバイスに好適な情報に変換するための出力スタイルシートを指定する「出力スタイルシート情報」属性と、送信者となるアプリケーション４１に好適な情報に変換するための入力スタイルシートを指定する「入力スタイルシート情報」属性と、配信エラーの判定基準となる「制限時間」属性と、正常に情報配信が行われなかった場合、代わりに情報を配信する受信者（以下、「代替受信者」と称する。）に関する「受信者情報（以下、「代替受信者情報」と称する。）」属性と、を有している。なお、当該「代替受信者情報」属性も、上記の「配信情報」要素が有する「受信者情報」属性と同じ構成要素を含んでいる。つまり、「受信者情報」属性は階層構造となっており、その階層に従って優先順位が決定されている。したがって、「代替受信者情報」属性に基づく配信が正常に行われなかった場合、次に優先順位の低い「代替受信者情報」属性に基づいて配信を行う・・・といった代替処理が繰り返されることとなる。
なお、以下では、記載内容を見易くするため、「要素」および「属性」の記載を省略する。

続いて、「配信結果」について説明する。図３（ｂ）に示すように、「配信結果」は、配信を試行した１以上の受信者に関する「受信者情報（第１の受信者情報）」を有している。また、当該「受信者情報」は、受信者となる対象デバイスを特定するための「宛先情報」と、当該対象デバイスへの「送信結果」と、正常に情報配信が行われなかった場合、代わりに情報を配信する受信者（代替受信者）に関する「受信者情報（代替受信者情報）」と、を有している。また、「送信結果」は、送信の成否を示す「成否情報」と、対象デバイスの状態（ステータス）などを示す「補足情報」と、対象デバイスからの入力データである「応答情報」と、を有している。

なお、「配信情報」と「配信結果」は、図３（ｃ）に示すように、統合することが可能である。つまり、「配信情報」のデータ構造の中に「配信結果」を追加し、要求メッセージ（図７参照）のスキーマと応答メッセージ（図１１参照）のスキーマとを、一つにまとめることが可能である。

次に、図４および図５を参照し、情報配信処理および応答処理について説明する。図４は、店内管理システムＳＹの情報配信処理を示すフローチャートである。同図に示すように、まずＰＣ２０（アプリケーション４１）は、情報配信処理の開始前に、出力スタイルシートおよび入力スタイルシートを生成し、サーバー３０に送信しておく（Ｓ０１）。サーバー３０（スタイルシート管理部７１）は、これらのスタイルシートを、スタイルシートデータベース８１に登録する（Ｓ０２）。

一方、ＰＣ２０は、オーダリング端末１０からの注文情報の取得に伴い、出力データを生成し、配信情報と共に、ＸＭＬ文書１として、サーバー３０（統合デバイス制御サービス４４）に配信する（Ｓ０３）。なお、配信情報は、出力データの配信前に、予め送信しておくことも可能である。サーバー３０は、ＰＣ２０からＸＭＬ文書１を取得し（Ｓ０４，通信インターフェース８４）、予め登録されていた出力スタイルシートに基づいて、ＸＭＬ文書１をＸＭＬ文書２に変換する（Ｓ０５，ＸＭＬ文書変換部８５）。

なお、Ｓ０５において、出力スタイルシートは、配信情報の受信者情報に含まれる「出力スタイルシート情報」によって指定されたものを用いる。これにより、受信者（デバイス５０）毎に異なる出力スタイルシートを適用可能となっている。したがって、受信者がキッチンプリンタ６１の場合は、ＸＭＬＰＯＳ（ＰＯＳデバイスの制御情報を表現する業界標準のＸＭＬ）で表されるＸＭＬ文書２に変換し、受信者がキッチンディスプレイ６３の場合は、ＸＨＴＭＬ等の表示用言語で表されるＸＭＬ文書２に変換する、といった処理も可能である。また、詳細については後述するが、各出力スタイルシートには、「条件式」を含めることができる。出力スタイルシートに「条件式」が含まれる場合は、ＸＭＬ文書１内の出力データがこの「条件式」を満たす場合のみＸＭＬ文書２への変換を行う。言い換えれば、ＸＭＬ文書１内の出力データが、出力スタイルシートに含まれる「条件式」を満たさない場合、ＸＭＬ文書２への変換およびその配信を実行しない。但し、出力シートによって異なる「条件式」を設定可能であるため、受信者として２つのキッチンプリンタ６１を指定し、出力データがある条件を満たす場合は、第１のキッチンプリンタ６１に配信し、出力データがある条件を満たさない場合は、第２のキッチンプリンタ６１に配信する、といった条件付きの同送処理を行うことも可能である。

また、サーバー３０は、変換後のＸＭＬ文書２を、デバイス５０のデバイス制御サービス７３，７５に出力する（Ｓ０６，デバイス別ＸＭＬ文書入出力部８６）。なお、出力先（対象デバイス）は、配信情報の受信者情報に含まれる「宛先情報」によって特定される。デバイス５０（デバイス制御サービス７３，７５）は、サーバー３０から出力されたＸＭＬ文書２を取得する（Ｓ０７）。

続いて、図５のフローチャートを参照し、店内管理システムＳＹの応答処理について説明する。デバイス５０は、Ｓ０７で取得したＸＭＬ文書２に対する配信結果として、成否情報、補足情報および応答情報を含むＸＭＬ文書３を生成し、サーバー３０に送信する（Ｓ１１）。サーバー３０は、当該ＸＭＬ文書３を取得し（Ｓ１２，デバイス別ＸＭＬ文書入出力部８６）、予め登録されていた入力スタイルシートに基づいて、ＸＭＬ文書３をＸＭＬ文書４に変換する（Ｓ１３，ＸＭＬ文書変換部８５）。なお、入力スタイルシートは、配信情報の受信者情報に含まれる「入力スタイルシート情報」によって指定されたものを、スタイルシートデータベース８１から読み出して用いる。これにより、サーバー３０が複数のＰＣ２０（アプリケーション４１）と提携している場合でも、送信者であるアプリケーション４１毎に異なる入力スタイルシートを利用して、好適な情報に変換することができる。なお、サーバー３０は、トランスポートプロトコル（例えば、ＴＣＰ／ＩＰプロトコル群）を利用することで、受信者であるデバイス５０に対する送信者のＰＣ２０を特定することができる。

また、サーバー３０は、ＸＭＬ文書２を複数のデバイス５０に対して送信した場合、当該複数のデバイス５０からの配信結果（ＸＭＬ文書３）を統合して、ＸＭＬ文書４に変換する。サーバー３０は、変換後のＸＭＬ文書４を、ＸＭＬ文書１（出力データを）送信したＰＣ２０に入力する（Ｓ１４）。また、送信者となるＰＣ２０（アプリケーション４１）は、サーバー３０から入力された当該ＸＭＬ文書４を取得する（Ｓ１５）。

次に、図６ないし図１１を参照し、「出力データ」、「配信情報」、「出力スタイルシート」および「配信結果」の具体例について説明する。図６は、ＸＭＬ文書１に相当する「出力データ」の一例を示す図である。ここでは、オーダリング端末１０から、注文情報「生ビールを１つ，ヒレステーキを１つ，シーザーサラダを１つ」を取得した場合に生成される出力データを示している。符号１０１に示すように、「出力データ」には、シーケンス番号、アイテムＩＤ、アイテム名（料理名）を示す情報が含まれている。なお、ドリンク部門のアイテムＩＤは１００番台であり、グリル部門のアイテムＩＤは２００番台であり、サラダ部門のアイテムＩＤは３００番台と規定されているものとする。この他、「出力データ」には、レストラン名、注文日時、オーダリング端末１０のＩＤ、オーダリング端末１０の操作者コード、価格（単価、合計）、顧客データ（性別、年代）などの情報を含めても良い。

図７は、ＸＭＬ文書１に相当する「配信情報」の一例を示す図である。同図の例では、５台のキッチンプリンタ６１についての「受信者情報」が記述されている。符号１１１に示すように、第１のデバイス要素では、「キッチンプリンタ１」が第１の受信者であり、その代替受信者（＜Ｄｅｖｉｃｅ Ｒｅｊｅｃｔｅｄ＞）が「キッチンプリンタ２」であり、さらにその代替受信者が「キッチンプリンタ３」となっている。したがって、最初に「キッチンプリンタ１」に送信を試み、配信エラーとなった場合は、「キッチンプリンタ２」に送信を試み、さらに配信エラーとなった場合は、「キッチンプリンタ３」に送信を試みる（代替処理）。一方、符号１１２に示すように、第２のデバイス要素では、「キッチンプリンタ４」が第１の受信者であり、その代替受信者が「キッチンプリンタ５」となっている。したがって、最初に「キッチンプリンタ４」に送信を試み、配信エラーとなった場合は、「キッチンプリンタ５」に送信を試みる（代替処理）。また、第３のデバイス要素は、符号１１３に示すように、第２のデバイス要素と同様の構成となっている。したがって、最初に「キッチンプリンタ６」に送信を試み、配信エラーとなった場合は、「キッチンプリンタ７」に送信を試みる（代替処理）。

なお、第１のデバイス要素は、グリル部門のキッチンプリンタ６１、第２のデバイス要素は、サラダ部門のキッチンプリンタ６１、第３のデバイス要素は、ドリンク部門のキッチンプリンタ６１に関するものであり、デバイス５０（各部門）に対応した出力スタイルシートが指定されている。また、上記のとおり「配信情報」の中には、受信者毎に、「出力スタイルシート情報」および「制限時間」が記述されている。なお、同図の例では、「配信情報」に含めることが可能な「入力スタイルシート情報」についての記述は、省略している。

図８（ａ）は、ドリンク部門のキッチンプリンタ６１用に生成された「出力スタイルシート」の一例を示す図である。同図は、符号１２１に示すように、アイテムＩＤ（メニューＩＤ）が１００番台のアイテムについて、注文内容（注文があった旨、並びにアイテム名および注文数）を印刷するためのスタイルシートを例示している。なお、波線で示す＜ｘｓｌ：ｉｆ ｔｅｓｔ＞要素が、本スタイルシートの「条件式」となる。したがって、本スタイルシートは、出力データに含まれる「アイテムＩＤが１００番台のアイテム」について適用される。また、同図のスタイルシートにより、ＸＭＬ文書２は、キッチンプリンタ６１に接続されたＰＯＳターミナル５１が解釈可能な印刷言語（ＸＭＬＰＯＳ）で記述される。

図８（ｂ）は、ＸＭＬ文書２の一例を示す図である。同図の例は、図８（ａ）の出力スタイルシートに基づいて情報変換が行われた場合のＸＭＬ文書２を例示している。すなわち、符号１２２に示すように、ドリンク部門のキッチンプリンタ６１（「キッチンプリンタ６」および「キッチンプリンタ７」，図７参照）に対し、注文内容の印刷指令を行う内容となっている。

また、図９（ａ）は、グリル部門のキッチンプリンタ６１用に生成された「出力スタイルシート」の一例を示す図である。同図は、符号１２３に示すように、アイテムＩＤ（メニューＩＤ）が２００番台のアイテムについて、注文内容を印刷するためのスタイルシートを例示している。なお、下線部は、図８（ａ）に示した「出力スタイルシート」の記述と異なる部分を示しており、図９（ａ）の「出力スタイルシート」では「条件式」に相当する。本スタイルシートは、出力データに含まれる「アイテムＩＤが２００番台のアイテム」について適用される。図９（ｂ）は、図９（ａ）の出力スタイルシートに基づいて情報変換が行われた場合のＸＭＬ文書２を例示している。すなわち、符号１２４に示すように、グリル部門のキッチンプリンタ６１（「キッチンプリンタ１」、「キッチンプリンタ２」および「キッチンプリンタ３」，図７参照）に対し、注文内容の印刷指令を行う内容となっている。なお、下線部は、図８（ｂ）に示した「ＸＭＬ文書２」の記述と異なる部分を示している。

同様に、図１０（ａ）は、サラダ部門のキッチンプリンタ６１用に生成された「出力スタイルシート」の一例を示す図である。同図は、符号１２５に示すように、アイテムＩＤ（メニューＩＤ）が３００番台のアイテムについて、注文内容を印刷するためのスタイルシートを例示している。なお、下線部の「条件式」に示すとおり、本スタイルシートは、出力データに含まれる「アイテムＩＤが３００番台のアイテム」について適用される。図１０（ｂ）は、図１０（ａ）の出力スタイルシートに基づいて情報変換が行われた場合のＸＭＬ文書２を例示している。すなわち、符号１２６に示すように、サラダ部門のキッチンプリンタ６１（「キッチンプリンタ４」および「キッチンプリンタ５」，図７参照）に対し、注文内容の印刷指令を行う内容となっている。

図１１は、ＸＭＬ文書４に相当する「配信結果」の一例を示す図である。同図の例は、図７に示した「配信情報」に対応するものである。すなわち、符号１３１ないし符号１３３に示すように、以下の内容が記述されている。“第１の受信者「キッチンプリンタ１」および「キッチンプリンタ４」に対して送信を試み、「キッチンプリンタ１」はデバイス５０が見つからずに動作が失敗し、その代替受信者である「キッチンプリンタ２」に送信を試みた。しかし、「キッチンプリンタ２」もタイムアウトとなり動作が失敗した。そこで、さらに優先順位の低い代替受信者である「キッチンプリンタ３」に送信を試み、正常に動作した。一方、「キッチンプリンタ４」および「キッチンプリンタ６」については、代替受信者（「キッチンプリンタ５」および「キッチンプリンタ７」）に送信を試みることなく、正常に動作した。”

なお、図３に示す「配信結果」に関連する「送信結果」は、図１１の＜Ｄｅｖｉｃｅ＞と＜／Ｄｅｖｉｃｅ＞で囲まれる情報に相当する。また、図３に示す「送信結果」を構成する「成否情報」は、図１１の＜Ｒｅｓｐｏｎｓｅ＞と＜／Ｒｅｓｐｏｎｓｅ＞で囲まれる情報に相当し、図３に示す「補足情報」および「応答情報」は、図１１の＜Ｂｕｓｉｎｅｓｓ Ｅｒｒｏｒ＞と＜／Ｂｕｓｉｎｅｓｓ Ｅｒｒｏｒ＞で囲まれる情報に相当する。

次に、図１２ないし図１９を参照し、サーバー３０の逐次処理について説明する。逐次処理には、情報配信が失敗した場合に実行される代替処理と、情報配信が成功した場合に実行される連携処理と、がある（図１６（ｂ）参照）。まず、図１２ないし図１５を参照し、サーバー３０の代替処理について具体的に説明する。上記のとおりサーバー３０は、第１の受信者に対して正常に配信できなかった場合、代替受信者に対して情報配信を試みるものとしたが、同一の情報を送信すると、所望する目的が達成できなかったり、第１の受信者と代替受信者とが異なる種類のデバイス５０である場合など、正常に動作させることができなかったりする場合がある。そこで、このような問題を解決するための具体的な処理内容について、以下説明する。

図１２は、サーバー３０の代替処理を示すフローチャートである。サーバー３０（統合デバイス制御サービス４４）は、図５に示した応答処理によって、ＸＭＬ文書３を取得すると（Ｓ２１，図５のＳ１２に相当）、情報配信が成功したか否かを判別する（Ｓ２２）。ここで、情報配信が正常に行われなかったと判別した場合は（Ｓ２２：Ｎｏ）、「配信情報」に「代替受信者情報」が含まれているか否かを判別する（Ｓ２３）。「配信情報」に「代替受信者情報」が含まれている場合は（Ｓ２３：Ｙｅｓ）、代替受信者用の出力スタイルシート（以下、「代替出力スタイルシート」と称する。）に基づいて、ＸＭＬ文書１をＸＭＬ文書２に変換し（Ｓ２４，ＸＭＬ文書変換部８５）、当該ＸＭＬ文書２を代替受信者となる対象デバイスのデバイス制御サービス７３，７５に出力する（Ｓ２５，デバイス別ＸＭＬ文書入出力部８６）。なお、代替受信者への配信を行った場合は、さらにその情報配信に対して取得したＸＭＬ文書３に基づいて、情報配信が成功したか否かを判別し（Ｓ２２）、情報配信が正常に行われなかったと判別した場合は（Ｓ２２：Ｎｏ）、さらに優先順位の低い「代替受信者情報」が存在するか否かを判別し（Ｓ２３）、Ｓ２４以降の処理を行う。

一方、情報配信が正常に行われたと判別した場合（Ｓ２２：Ｙｅｓ）、並びに「配信情報」に「代替受信者情報」が含まれていない場合は（Ｓ２３：Ｎｏ）、代替受信者への配信を行うことなく、入力スタイルシートに基づいて、「配信結果」を示すＸＭＬ文書３をＸＭＬ文書４に変換し（Ｓ２６，図５のＳ１３に相当）、当該ＸＭＬ文書４を送信者であるアプリケーション４１に入力する（Ｓ２７，図５のＳ１４に相当）。

続いて、図１３ないし図１５を参照し、「代替出力スタイルシート」の具体例について説明する。図１３（ａ）は、ドリンク部門から他部門（グリル部門またはサラダ部門）のキッチンプリンタ６１へ出力するための出力スタイルシートを示したものであり、図８に示した「出力スタイルシート」を第１の受信者用の出力スタイルシート（以下、「第１の出力スタイルシート」と称する。）とした場合の「代替出力スタイルシート」となる。なお、図１３ないし図１５において、下線部は、図８に示した「出力スタイルシート」および「ＸＭＬ文書２」の記述と異なる部分を示している。したがって、下線部分の書換えのみで（アプリケーション４１の変更を必要とすることなく）、「代替出力スタイルシート」の生成が可能であり、ひいては、本実施形態における代替処理が実現可能である。

符号１４１に示すように、図１３（ａ）の「代替出力スタイルシート」は、アイテムＩＤが１００番台のアイテムについて（「条件式」）、注文内容と共に、ドリンク部門（本来の配信先）に転送して欲しい旨を印刷するためのスタイルシートとなっている。つまり、ドリンク部門のキッチンプリンタ６１がレシート切れ等で正常に動作できない場合、他部門のキッチンプリンタ６１で、図１３（ｂ）に示すＸＭＬ文書２（符号１４２参照）に基づく印刷を実行可能となっている。これにより、他部門のスタッフが、ドリンク部門に調理指令の印刷物を回すことができ、調理業務を支障なく遂行することができる。

なお、図１３（ａ）に示した「代替出力スタイルシート」は、他部門（グリル部門またはサラダ部門）のキッチンプリンタ６１で共用することができる。つまり、出力スタイルシートは、必ずしもデバイス５０毎に異なるものを用意しておく必要は無い。また、「代替出力スタイルシート」としては、上記のとおり「ドリンク部門に転送して欲しい旨」の追加情報を調理指示伝票の中に挿入するのではなく、用紙のヘッダ余白部や、送付状として付加した用紙に印刷するような内容を記述しても良い。

一方、図１４（ａ）は、ドリンク部門の厨房機器６２（ドリンクベンダー）に対する動作を指令するための出力スタイルシートを示したものである。また、図１５（ａ）は、ドリンク部門のキッチンディスプレイ６３に対する動作を指令するための出力スタイルシートを示したものである。なお、図１５の出力スタイルシートは、図１４に示した「出力スタイルシート」を「第１の出力スタイルシート」とした場合の「代替出力スタイルシート」となる。

符号１５１に示すように、図１４（ａ）の出力スタイルシートは、ドリンクベンダーに対し、アイテムＩＤが１００番台のアイテム（ドリンク類）を（「条件式」）、グラス等に注ぐ動作を指令するためのスタイルシートとなっている。また、当該出力スタイルシートに基づいて、図１４（ｂ）に示すＸＭＬ文書２（符号１５２参照）を生成可能となっている。なお、当該ＸＭＬ文書２は、プロトコルコンバータ５２（図１参照）が解釈可能な言語で記述されている。

また、符号１６１に示すように、図１５（ａ）の出力スタイルシートは、ドリンク部門のキッチンディスプレイ６３に対し、アイテムＩＤが１００番台のアイテム（ドリンク類）の注文内容を（「条件式」）、キッチンディスプレイ６３に表示させるためのスタイルシートとなっている。また、当該スタイルシートに基づいて、図１５（ｂ）に示すＸＭＬ文書２（符号１６２参照）を生成可能となっている。なお、当該ＸＭＬ文書２は、キッチンディスプレイ６３が解釈可能な言語（ＸＨＴＭＬ）で記述されている。

このように（図１４および図１５に例示したように）、ドリンクベンダーが故障等により正常に動作できない場合、キッチンディスプレイ６３を用いて、同じ目的を実現する（ドリンクの注文に対応する）ことができる。つまり、アプリケーション４１の変更を全く必要とすることなく、「配信情報」に「受信者情報」を追加し、さらに下線部を書き換えた代替用のスタイルシートを生成するだけで、種類の異なるデバイス５０で、同じ目的を実現することが可能となる。

次に、図１６ないし図１９を参照し、連携処理を含む逐次処理について説明する。図１６（ａ）は、当該連携処理を含む逐次処理を実現する場合の「配信情報・配信結果」の構成を示す図である。この場合、図３（ｃ）に示した「配信情報・配信結果」に対し、「受信者情報」に「連携受信者情報」が含まれる点で異なる。この「連携受信者情報」とは、正常に情報配信が行われた場合、次に情報を配信する受信者（以下、「連携受信者」と称する。）に関する情報を指す。なお、図１６（ａ）に示す「代替受信者情報」とは、上記のとおり、正常に情報配信が行われなかった場合、代わりに情報を配信する代替受信者に関する情報を指すものであり、図３（ｃ）では、「受信者情報」内の「受信者情報」に相当する。

また、図１６（ｂ）に示すように、これら「連携受信者情報」および「代替受信者情報」は、それぞれ階層構造となっている。つまり、同図の階層構造の場合、「配信情報」には、「デバイス１」、「デバイス２」および「デバイス３」に関する「受信者情報（第１の受信者情報）」が含まれ、「デバイス１」の「受信者情報」には、「デバイス１１」を連携受信者とした「連携受信者情報（第２の受信者情報）」と「デバイス１０」を代替受信者とした「代替受信者情報」とが含まれている。さらに「デバイス１１」の「受信者情報」には、「デバイス１１１」を連携受信者とした「連携受信者情報（第３の受信者情報）」と「デバイス１１０」を代替受信者とした「代替受信者情報」とが含まれている。したがって、例えば「デバイス１」、「デバイス２」および「デバイス３」に対して同送処理を行ったところ、「デバイス１」への配信が成功した場合、「デバイス１１」に対して情報配信が行われる（連携処理）。また、「デバイス１」への配信が失敗した場合は、「デバイス１０」に対して情報配信が行われる（代替処理）。さらに、「デバイス１１」への配信が成功した場合は、「デバイス１１１」に対して情報配信が行われ（連携処理）、失敗した場合は、「デバイス１１０」に対して情報配信が行われる（代替処理）。

図１７は、サーバー３０の逐次処理を示すフローチャートである。サーバー３０は、図５に示した応答処理によって、ＸＭＬ文書３を取得すると（Ｓ３１）、情報配信が成功したか否かを判別する（Ｓ３２）。ここで、情報配信が正常に行われたと判別した場合は（Ｓ３２：Ｙｅｓ）、「配信情報」に「連携受信者情報（第２の受信者情報）」が含まれているか否かを判別する（Ｓ３３）。「配信情報」に「連携受信者情報」が含まれている場合は（Ｓ３３：Ｙｅｓ）、連携受信者用の出力スタイルシート（以下、「連携出力スタイルシート（第２の出力スタイルシート）」と称する。）に基づいて、ＸＭＬ文書１をＸＭＬ文書２に変換し（Ｓ３４）、当該ＸＭＬ文書２（第２の変換データ）を連携受信者となる対象デバイスのデバイス制御サービス７３，７５に出力する（Ｓ３５）。なお、連携受信者への配信を行った場合は、さらにその情報配信に対して取得したＸＭＬ文書３に基づいて、情報配信が成功したか否かを判別し（Ｓ３２）、情報配信が正常に行われたと判別した場合は（Ｓ３２：Ｙｅｓ）、さらに優先順位の低い「連携受信者情報」が存在するか否かを判別し（Ｓ３３）、Ｓ３４以降の処理を行う。

一方、「配信情報」に「連携受信者情報」が含まれていない場合は（Ｓ３３：Ｎｏ）、連携受信者への配信を行うことなく、入力スタイルシートに基づいて、「配信結果」を示すＸＭＬ文書３をＸＭＬ文書４に変換し（Ｓ３９）、当該ＸＭＬ文書４を送信者であるアプリケーション４１に入力する（Ｓ４０）。また、Ｓ３２において、情報配信が正常に行われなかったと判別した場合は（Ｓ３２：Ｎｏ）、図１２に示したＳ２３ないしＳ２７と同様の処理を行う（Ｓ３６ないしＳ４０）。

なお、連携処理のみのフローチャート（代替処理を含まない逐次処理）については、図１２のフローチャートにおいて、Ｓ２２の「配信成功？」を「配信失敗？」に、Ｓ２３の「代替受信者情報」を「連携受信者情報」に、またＳ２４の「代替出力スタイルシート」を「連携出力スタイルシート」に、それぞれ読み替えるだけであるため、図示および説明を省略する。

続いて、図１８および図１９を参照し、連携処理を含む逐次処理を実現する場合の「配信情報」および「配信結果」の具体例について説明する。なお、以下の説明において、「受信者」とは、１のデバイス５０に含まれる論理的構成を指すものとする。ここでは、図１に示したキッチンプリンタ６１に、「プリンタ」と「ブザー」といった２つの論理的構成（機能）が含まれており、第１のキッチンプリンタ６１に、受信者「キッチンプリンタ１」および「ブザー１」が含まれ、第２のキッチンプリンタ６１に、受信者「キッチンプリンタ２」および「ブザー２」が含まれているものとする。

図１８は、ＸＭＬ文書１に相当する「配信情報」の一例を示す図である。ここでは、２台のキッチンプリンタ６１に含まれる４つの論理的構成について「受信者情報」が記述されている。符号１７１に示すように、同図の例では、「キッチンプリンタ１」が第１の受信者であり、その連携受信者（第２の受信者）（＜Ｄｅｖｉｃｅ ＯＫ＞）が「ブザー１」となっている。また、第１の受信者である「キッチンプリンタ１」の代替受信者（＜Ｄｅｖｉｃｅ Ｒｅｊｅｃｔｅｄ＞）が「キッチンプリンタ２」であり、さらにその連携受信者が「ブザー２」となっている。したがって、最初に「キッチンプリンタ１」に送信を試み、配信が成功した場合は「ブザー１」に送信を試みる。また、「キッチンプリンタ１」への配信が失敗した場合は「キッチンプリンタ２」に送信を試み、当該「キッチンプリンタ２」への配信が成功した場合は「ブザー２」に送信を試みる。

図１９は、図１８に示した「配信情報」に対応する「配信結果」を示す図である。符号１８１は、図１８に示した「配信情報」に基づく一連の逐次処理の成否情報を示している。ここでは、「配信成功」と記述されている。また、符号１８２には、各受信者に対する送信結果が記述されている。つまり、ここでは“第１の受信者「キッチンプリンタ１」に対して送信を試みたが、動作が失敗したので、その代替受信者である「キッチンプリンタ２」に送信を試みた。その結果、「キッチンプリンタ２」では正常に動作したので、その連携受信者である「ブザー２」に送信を試みたところ、「ブザー２」は正常に動作した。”旨が記述されている。これは、「キッチンプリンタ２」により注文伝票が発行され、その伝票発行を報知するブザーが鳴らされたことを意味する。なお、符号１８１に示した一連の逐次処理の成否情報は、最後に動作させた受信者「ブザー２」の成否情報と一致する。

このように（図１６ないし図１９に例示したように）、連携処理と代替処理とを組み合わせることにより、複雑な逐次処理を実現することが可能である。また、逐次処理は、物理的構成が異なる複数のデバイス５０によって実現できるだけでなく、１のデバイス５０に含まれる複数の論理的構成によっても実現可能である。

以上、説明したとおり、本実施形態の店内管理システムＳＹによれば、スタイルシートによって、処理内容の変更、並びにデバイス５０の種類や仕様の違いを吸収可能なため、アプリケーション４１による直接的なデバイス制御を不要とできる。これにより、アプリケーション４１の作成が容易になると共に、処理内容の変更やデバイス５０の入れ替えに伴うアプリケーション４１の変更を不要とできる。

また、デバイス別ＸＭＬ文書入出力部８６により、既存デバイス５０ａおよび新デバイス５０ｂに対応した２種類のデバイス制御サービス７３，７５を呼び出すことが可能なため、例えば既存デバイス５０ａが新デバイス５０ｂに入れ替えられたような場合にも、アプリケーション４１の変更を不要とできる。

また、「出力データ」、「配信情報」および「配信結果」をＸＭＬで記述することにより、テキストエディタ等で簡単に編集ができると共に、ＸＳＬ以外の情報変換規則を新たに生み出す必要が無いなどの利点がある。また、デバイス別サービス情報（デバイス制御サービス７３，７５に関する情報）をＷＳＤＬで記述することにより、Ｗｅｂサービスの実装が容易となる。また、印刷言語としてＸＭＬＰＯＳを用いることで、メーカーを問わず、３０種類以上のＰＯＳデバイスを制御することが可能となる。

また、送信者であるアプリケーション４１毎に入力スタイルシートを指定できるため、統合デバイス制御サービス４４が、複数のアプリケーション４１と提携している場合でも、各アプリケーション４１に応じたＸＭＬ文書４（配信結果）を取得可能である。

また、「出力スタイルシート」に「条件式」を含めることができるため、出力データの配信を制限することができる。これにより、出力データの配信を、該当する部門のアイテムＩＤが出力データに含まれる場合のみに制限可能である。また、「条件式」は、出力スタイルシート毎（デバイス毎）に指定できるため、複数のデバイス５０を受信者として設定しておくことで、条件付きの同送処理が可能である。

また、代替処理により、第１の受信者情報に基づく情報配信が正常に行われなかった場合は、代替受信者情報に基づいて情報配信を行うため、第１の受信者と代替受信者の仕様が異なる場合でも、正常に動作させることができる。また、連携処理により、第１の受信者情報に基づく情報配信が正常に行われた場合は、連携受信者情報に基づいて情報配信を行うため、アプリケーション４１による１回のデータ出力によって、複数の受信者を逐次的に動作させることができる。言い換えれば、複数の受信者による連携処理を、アプリケーション４１を介することなく実現できる。さらに、出力スタイルシートでは、ＸＭＬ文書２の記述言語を指定できるため、解釈可能な記述言語が異なる複数種類のデバイス５０に対応可能である。これにより、各店舗のデバイス環境に応じて、デバイス５０の入れ替えを柔軟に行える。

なお、上記の実施形態では、店内管理システムＳＹを例示したが、他の環境でも、本実施形態のサーバー３０（統合デバイス制御サービス４４）を適用可能である。例えば、デバイス５０として、電子メール送信装置、ページプリンタ、大判プリンタ、電子棚札、ＰＯＳコンピュータを有する販促管理システム（いずれも図示省略）に、本実施形態のサーバー３０を適用した場合、クリアランスセール情報の取得をトリガとして、顧客データベースからクリアランス商品に興味のある顧客を抽出して、セール情報を電子メール送信装置に送信させる。この場合、上得意客には、クーポン情報を添付し、第１のメールアドレスへの配信が失敗した場合は第２のメールアドレスへの配信を行う（代替処理）。また、ページプリンタには、メールアドレスが登録されていない顧客用に、郵送用のダイレクトメールを印刷させ、大判プリンタには、セール情報のＰＯＰを印刷させる。さらに、電子棚札には、価格情報をセール価格に変更する指令を出し、ＰＯＳコンピュータには、商品マスタに登録された商品価格の変更を指令する。

また、上記の実施形態では、「条件式」の例として、「出力データに該当する部門のアイテムＩＤが含まれること」を挙げたが、「出力データに『男性』を示す顧客情報が含まれること」、「出力データに『深夜帯』を示す日時情報が含まれること」など、他の条件を設定しても良い。また、出力データに含まれる内容に関するものではなく、「出力データの容量が所定サイズ以上であること」、「出力データの出力日時が所定の日時条件を満たすこと」など出力データに関する種々の事項について、「条件式」を設定しても良い。

また、上記の実施形態では、「条件式」の記述として、＜ｘｓｌ：ｉｆ ｔｅｓｔ＞要素を例示したが（図８（ａ）等参照）、これ以外にも、＜ｘｓｌ：ｃｈｏｏｓｅ＞要素や＜ｘｓｌ：ｔｅｍｐｌａｔｅ＞要素など、他の記述で「条件式」を表しても良い。

また、上記の実施形態で示した同一デバイス間における代替処理を、ＰＯＳターミナル５１間の転送に用いても良い。例えば、ＰＯＳターミナル５１が複数設置されているスーパー等の売場において、任意のＰＯＳターミナル５１（第１の受信者）が故障した場合、代替受信者として指定された隣のＰＯＳターミナル５１のプリンタから、発行元として隣のＰＯＳターミナル５１のＩＤが付記されたレシートを発行することが可能である。

また、上記の実施形態で示した異なる種類のデバイス間における代替処理を、クーポン発行に用いても良い。例えば、電子バリューリーダライタやポイントカードリーダライタ（電子クーポンを発行する装置，第１の受信者）が故障した場合、代替受信者として指定されたクーポンプリンタ（紙のクーポンを発行する装置）でクーポンを発行することが可能である。その他、種々の環境で、統合デバイス制御サービス４４を用いたサービスを実現可能である。

また、上記の実施形態に示した、サーバー３０やＰＣ２０の各構成要素をプログラムとして提供することが可能である。また、そのプログラムを各種記録媒体（ＣＤ−ＲＯＭ、フラッシュメモリ等）に格納して提供することも可能である。すなわち、コンピュータを、サーバー３０やＰＣ２０の各構成要素として機能させるためのプログラム、およびそれを記録した記録媒体も、本発明の権利範囲に含まれるものである。その他、本発明の要旨を逸脱しない範囲で、適宜変更が可能である。

１０…オーダリング端末、２０…ＰＣ、３０…サーバー、４１…アプリケーション、４４…統合デバイス制御サービス、５０…デバイス、７３…デバイス制御サービス（既存デバイス用）、７５…デバイス制御サービス（新デバイス用）、８１…スタイルシートデータベース、８４…通信インターフェース、８５…ＸＭＬ文書変換部、８６…デバイス別ＸＭＬ文書入出力部、ＳＹ…店内管理システム。

Claims (9)

1. 情報変換規則を示すスタイルシートを記憶する記憶部と、
   端末から出力データを取得する出力データ取得部と、
   第１のデバイスの宛先を有して前記第１のデバイスに対応した情報変換規則である第１のスタイルシートを指定する第１の受信者情報及び前記第１のデバイスに対する配信の後に配信を受ける前記第１のデバイスと異なる第２のデバイスの宛先を有して前記第２のデバイスに対応した情報変換規則である第２のスタイルシートを指定する第２の受信者情報を含む配信情報を取得する配信情報取得部と、
   前記出力データを前記第１の受信者情報または前記第２の受信者情報が指定する前記スタイルシートによって変換し、前記第１のデバイスまたは前記第２のデバイスに配信する配信部と、
   前記配信部による配信が正常に行われたか否かを判別する配信判別部と、を備え、
   前記配信部は、
   前記第１のスタイルシートにより変換された変換データを前記第１のデバイスの宛先に配信し、前記配信判別部により、前記第１のスタイルシートにより変換された変換データの配信が正常に行なわれなかったと判別された場合に、前記第２の受信者情報が有する前記第２のデバイスの宛先に対して、前記第２のスタイルシートにより変換された変換データを配信する
   ことを特徴とする情報配信装置。
2. 前記端末は、オーダリング端末であり、
   前記第１のデバイスは、印刷を行なう第１のプリンターであり、
   前記第２のデバイスは、前記第１のプリンターと異なる第２のプリンターであり、
   前記出力データは、前記オーダリング端末で取得された注文情報を含む
   ことを特徴とする請求項１に記載の情報配信装置。
3. 前記配信情報は、前記第１の受信者情報と前記第２の受信者情報とに続き、優先順位が低い受信者情報を含んでおり、
   前記配信部が、
   前記配信判別部により前記第２の受信者情報に基づく配信が正常に行われなかったと判別された場合、さらに前記優先順位の低い受信者情報に基づいて配信を行う、
   ことを特徴とする請求項１または２に記載の情報配信装置。
4. 前記受信者情報は、配信エラーの判定基準となる制限時間を含み、
   前記配信判別部は、前記制限時間到達時点において、前記第１のデバイスへの配信が終了していない場合、前記第１のデバイスへの配信が正常に行われなかったと判別する、
   ことを特徴とする請求項１から３のいずれか１項に記載の情報配信装置。
5. 前記配信情報は、前記端末に対応した情報変換規則である入力用スタイルシートを含んでおり、
   前記第１のデバイスからの入力データを、前記入力用スタイルシートによって変換する応答部をさらに備えた、
   ことを特徴とする請求項１から４のいずれか１項に記載の情報配信装置。
6. 前記出力データ取得部は、複数の端末から前記出力データを取得可能であり、
   前記記憶部は、前記複数の端末に対応した複数種類の前記入力用スタイルシートを記憶している、
   ことを特徴とする請求項１から５のいずれか１項に記載の情報配信装置。
7. 前記出力データ、前記第１のスタイルシートにより変換された変換データ、前記第２のスタイルシートにより変換された変換データ、前記入力データおよび前記入力変換データは、いずれもマークアップ文書である、
   ことを特徴とする請求項１から６のいずれか１項に記載の情報配信装置。
8. 情報変換規則を示す複数のスタイルシートを記憶するデータベースを管理すると共に、少なくとも端末から取得した情報をデバイスに配信する情報配信装置のサービス実現方法であって、
   前記情報配信装置が、
   前記端末から、出力データを取得するステップと、
   第１のデバイスの宛先を有して前記第１のデバイスに対応した情報変換規則である第１のスタイルシートを指定する第１の受信者情報及び前記第１のデバイスに対する配信の後に配信を受けるデバイスである前記第１のデバイスとは異なる第２のデバイスの宛先を有して前記第２のデバイスに対応した情報変換規則である第２のスタイルシートを指定する第２の受信者情報を含む配信情報を取得するステップと、
   前記出力データを前記第１の受信者情報または前記第２の受信者情報が指定する前記スタイルシートによって変換し、前記第１のデバイスまたは前記第２のデバイスに配信する配信ステップと、
   配信部による前記変換データの配信が正常に行われたか否かを判別するステップと、を実行し、
   前記配信ステップは、
   前記第１のスタイルシートにより変換された変換データを前記第１のデバイスの宛先に配信し、前記第１のデバイスの宛先への配信が正常に行なわれなかったと判別された場合に、前記第２の受信者情報が有する前記第２のデバイスの宛先に対して、前記第２のスタイルシートにより変換された変換データを配信する
   ことを特徴とする情報配信装置のサービス実現方法。
9. コンピュータに、請求項８に記載の情報配信装置のサービス実現方法における各ステップを実行させるためのプログラム。
   

Images