以下、本発明の一実施形態に係る情報配信システム、情報配信システムのサービス実現方法およびそのプログラムについて、添付図面を参照しながら詳細に説明する。本発明は、送信者(アプリケーション)から取得した情報を、個々の受信者(デバイス)に好適な情報に変換して配信することにより、各受信者を統合的に制御することを特徴とするものである。そこで、本発明の情報配信システム等を、レストラン等の飲食店における店内管理システム(オーダリング端末から取得した注文情報に基づいて、キッチンプリンタや厨房機器等の各種デバイスを制御するシステム)に適用した場合を例示する。
図1は、本実施形態に係る店内管理システムSYのシステム構成図である。店内管理システムSYは、顧客からの注文を入力するオーダリング端末10と、オーダーターミナルとして機能するコンピュータ20(以下、「PC」と称する。)と、統合デバイス制御サービス44が組み込まれたサーバー30(情報配信システム)と、キッチンプリンタ61や厨房機器62等のデバイス50と、から成る。また、PC20、サーバー30およびデバイス50は、イントラネット等のネットワークNTを介して接続されている。
PC20は、CPU(Central Processing Unit)21、ROM(Read Only Memory)22、RAM(Random Access Memory)23、入力デバイス24、通信インターフェース25、ディスプレイ26およびHDD(Hard Disk Drive)27を備えている。通信インターフェース25は、オーダリング端末10と無線通信を行うためのものであり、本実施形態では主に注文情報の受信に用いられる。
また、HDD27には、アプリケーション・プログラム41(以下、単に「アプリケーション」と称する。)と、スタイルシート生成プログラム42と、が記憶されている。アプリケーション41は、情報配信対象となるデバイス50(受信者)に対し、「送信者」として機能する。また、スタイルシート生成プログラム42は、サーバー30において、各デバイス50に対応した情報変換を行うための情報変換規則であるスタイルシートを生成するためのプログラムである。
一方、サーバー30も、PC20と同様に、一般的なコンピュータの構成を有しており、CPU31、ROM32、RAM33、入力デバイス34、ディスプレイ35および記憶装置36を備えている。記憶装置36には、統合デバイス制御サービス44と、デバイスサービス登録プログラム46と、が記憶されていると共に、データベース45を有している。当該データベース45には、上記のスタイルシートや、各デバイス50に対応するデバイス制御サービス73,75(図2参照)に関する情報が登録される。
統合デバイス制御サービス44は、本実施形態の骨子を成す構成要素であり、PC20(アプリケーション41)から取得した情報を、データベース45から読み出したスタイルシートを用いて、各デバイス50に好適な情報に変換し、各デバイス50に対応したデバイス制御サービス73,75に出力する。また、デバイスサービス登録プログラム46は、ネットワークNT上に存在するデバイス制御サービス73,75の存在を統合デバイス制御サービス44が認識できるように、予めデータベース45に登録しておくためのプログラムである。
一方、デバイス50としては、POSターミナル51、および当該POSターミナル51に接続されたキッチンプリンタ61、厨房機器用のプロトコルコンバータ52、および当該プロトコルコンバータ52に接続された厨房機器62の他、ネットワークNTへの接続機能を有する各種デバイス(キッチンディスプレイ63、照明機器64、空調機器65、映像・音響機器66、テーブルディスプレイ67、クーポン発券機68)を有している。なお、POSターミナル51に接続されたキッチンプリンタ61や、プロトコルコンバータ52に接続された厨房機器62など、直接ネットワーク接続できないローカルデバイスの制御においては、POSターミナル51やプロトコルコンバータ52が、アプリケーション41から配信された情報を受信する「受信者」として機能する。
このように、店内管理システムSYでは、オーダリング端末10から出力された注文情報に応じて、上記のデバイス50を統合的に制御できるようになっている。具体的には、注文情報にグリル部門のオーダーが含まれる場合、厨房のグリル部門に設置されたキッチンプリンタ61に、調理指示伝票を発行させる。また、注文情報にドリンク部門のオーダーが含まれる場合、ドリンク部門に設置された別のキッチンプリンタ61に、調理指示伝票を発行させる。また、キッチンディスプレイ63には、注文された料理のレシピ情報を表示させ、照明機器64には、注文情報に応じた機器(間接照明、スポットライトなど)を選択して注文情報に応じた照度で点灯させる。また、空調機器65には、注文情報に応じた温度や湿度に調整するための指令を出し、映像・音響機器66には、注文情報に応じた映像・音楽を注文情報に応じた画質・音質で映像・音声出力させる。さらに、オーダーした顧客が着席するテーブルのテーブルディスプレイ67には、注文内容、オーダーされた料理の原材料情報、カロリー、アレルギー情報等を表示させ、クーポン発券機68には、注文情報に応じたクーポン券を発行させる。このように、店内管理システムSYでは、顧客の1回の注文に応じて、店内に配置された複数種類のデバイス50の制御が可能である。以下、その実現方法について、詳細に説明する。
図2は、サーバー30の具体的な機能を示すブロック図である。サーバー30は、上記の統合デバイス制御サービス44およびデータベース45の他、スタイルシート管理部71、デバイス制御サービス管理部72および既存デバイス50a用のデバイス制御サービス73を備えている。
スタイルシート管理部71は、スタイルシートの管理(登録、削除、更新など)を行う。また、スタイルシートを簡単に生成できるようにするためのスタイルシート生成ツール(図示省略)を、PC20に提供する。スタイルシート生成ツールとしては、例えばキッチンプリンタ61でレシート印刷を行うために、XMLPOS形式に変換するためのスタイルシートを対象にし、予め用意された項目を変更するだけで、フォーマットを変更できるようなツールを提供する。
デバイス制御サービス管理部72は、デバイスサービス登録プログラム46(図1参照)が実行されることによって機能するものであり、ネットワークNT上に存在するデバイス制御サービス73,75の管理(登録、削除、更新など)を行う。なお、デバイス制御サービス管理部72は、プライベートUDDI(Universal Description, Discovery and Integration)を利用して、デバイス制御サービス73,75の検索や照会を行う。
デバイス制御サービス73は、既存デバイス50aを制御するためのサービスである。なお、既存デバイスドライバを利用する場合は、既存デバイスドライバ用コマンド変換モジュールおよび既存ドライバAPI(いずれも図示省略)がさらに必要となる。なお、デバイス50によっては、デバイス制御サービス75を内蔵しているものなど、サーバー30内のデバイス制御サービス73を必要としないものも存在する。そのようなデバイス50(以下、「新デバイス50b」と称する。)については、統合デバイス制御サービス44と、直接情報の入出力を行う。また、デバイス制御サービス75は、WSDL(Web Services Description Language)によりサービスが定義されていれば、デバイス50内およびPC20内のいずれに存在していても良い。
一方、データベース45は、スタイルシートを記憶するスタイルシートデータベース81(記憶部)と、デバイス制御サービス73,75に関する情報(以下、「デバイス別サービス情報」と称する。)を記憶するデバイス別サービス情報データベース82と、を有している。
スタイルシートデータベース81は、PC20から取得したスタイルシート(スタイルシート管理部71によって登録されたスタイルシート)を記憶する。ここで、スタイルシートは、XSL(Extensible Stylesheet Language)で記述される。また、デバイス別サービス情報データベース82は、デバイス制御サービス管理部72によって登録されたデバイス別サービス情報を記憶する。ここで、デバイス別サービス情報は、WSDLで記述される。
統合デバイス制御サービス44は、通信インターフェース84、XML(Extensible Markup Language)文書変換部85、およびデバイス別XML文書入出力部86を有している。なお、請求項における「出力データ取得部」、「受信者情報取得部」、「条件判別部」、「配信部」および「応答部」は、統合デバイス制御サービス44に相当する。統合デバイス制御サービス44は、主に、PC20から情報を配信する情報配信処理、並びにデバイス50(既存デバイス50aおよび新デバイス50b)からの応答処理を実現する。なお、情報配信処理に際して、アプリケーション41またはその他の送信者から提供される情報を、以下「配信情報」と称する。当該「配信情報」は、アプリケーション41から提供される場合、アプリケーション41の出力データと同時に(出力データに添付されて)取得可能である。また、応答処理に際して、デバイス50から入力される情報を、以下「配信結果」と称する。
例えば、情報配信処理を行う場合、通信インターフェース84は、アプリケーション41の出力データ(注文情報)と、その出力対象(情報配信対象)となる対象デバイスや出力用のスタイルシート(以下、「出力スタイルシート」と称する。)に関する情報を含む配信情報と、を取得する。これらはいずれもXMLで記述されており、以下、「XML文書1」と総称する。また、XML文書変換部85は、通信インターフェース84から取得したXML文書1を、スタイルシートデータベース81から読み出した出力スタイルシートに基づいて、対象デバイスのデバイス制御コマンド(デバイス制御情報)を含むXML文書(以下、「XML文書2(出力変換データ)」と称する。)に変換する。なお、XML文書変換部85は、XSLT(XSL Transformation)を利用して、XML文書を変換する。さらに、デバイス別XML文書入出力部86は、XML文書変換部85から取得したXML文書2を、対象デバイスに対応するデバイス制御サービス73,75に出力する。
また、応答処理を行う場合、デバイス別XML文書入出力部86は、各デバイス50からの配信結果(入力データ)を含むXML文書(以下、「XML文書3」と称する。)を、XML文書変換部85に入力する。XML文書変換部85は、入力された当該XML文書3を、スタイルシートデータベース81から読み出した入力用のスタイルシート(以下、「入力スタイルシート」と称する。)に基づいて、アプリケーション41用のXML文書(以下、「XML文書4(入力変換データ)」と称する。)に変換する。さらに、通信インターフェース84は、XML文書変換部85から取得したXML文書4を、アプリケーション41に入力する。
次に、図3を参照し、情報配信処理に用いられる「配信情報」、および応答処理に用いられる「配信結果」の詳細について説明する。なお、各情報要素に付加された大括弧は、多重度を表すものである。
図3(a)に示すように、「配信情報」は、1以上の「受信者情報」を有している。ここで、複数の「受信者情報」を設定しておくことにより、アプリケーション41による1回の出力データを、複数の受信者に対して同送することが可能となる。また、「受信者情報」は、受信者となる対象デバイス(デバイス制御サービス73,75)を特定するための「宛先情報」と、当該対象デバイスに好適な情報に変換するための出力スタイルシートを指定する「出力スタイルシート情報」と、送信者となるアプリケーション41に好適な情報に変換するための入力スタイルシートを指定する「入力スタイルシート情報」と、配信エラーの判定基準となる「制限時間」と、正常に情報配信が行われなかった場合、代わりに情報を配信する受信者(以下、「予備受信者」と称する。)に関する「受信者情報(以下、「予備受信者情報」と称する。)」と、を有している。なお、当該「予備受信者情報」も、上記の「配信情報」が有する「受信者情報(以下、「主受信者情報」と称する。」と同じ構成要素を含んでいる。つまり、「受信者情報」は階層構造となっており、その階層に従って優先順位が決定されている。したがって、「予備受信者情報」に基づく配信が正常に行われなかった場合、次に優先順位の低い「予備受信者情報」に基づいて配信を行う・・・といった代替処理が繰り返されることとなる。
続いて、「配信結果」について説明する。図3(b)に示すように、「配信結果」は、配信を試行した1以上の受信者に関する「受信者情報(主受信者情報)」を有している。また、「受信者情報」は、受信者となる対象デバイスを特定するための「宛先情報」と、当該対象デバイスへの「送信結果」と、正常に情報配信が行われなかった場合、代わりに情報を配信する受信者(予備受信者)に関する「受信者情報(予備受信者情報)」と、を有している。また、「送信結果」は、送信の成否を示す「成否情報」と、対象デバイスの状態(ステータス)などを示す「補足情報」と、対象デバイスからの入力データである「応答情報」と、を有している。
なお、「配信情報」と「配信結果」は、図3(c)に示すように、統合することが可能である。つまり、「配信情報」のデータ構造の中に「配信結果」を追加し、要求メッセージ(図7参照)のスキーマと応答メッセージ(図11参照)のスキーマとを、一つにまとめることが可能である。
次に、図4および図5を参照し、情報配信処理および応答処理について説明する。図4は、店内管理システムSYの情報配信処理を示すフローチャートである。同図に示すように、まずPC20(アプリケーション41)は、情報配信処理の開始前に、出力スタイルシートおよび入力スタイルシートを生成し、サーバー30に送信しておく(S01)。サーバー30(スタイルシート管理部71)は、これらのスタイルシートを、スタイルシートデータベース81に登録する(S02)。
一方、PC20は、オーダリング端末10からの注文情報の取得に伴い、出力データを生成し、配信情報と共に、XML文書1として、サーバー30(統合デバイス制御サービス44)に配信する(S03)。なお、配信情報は、出力データの配信前に、予め送信しておくことも可能である。サーバー30は、PC20からXML文書1を取得し(S04,通信インターフェース84)、予め登録されていた出力スタイルシートに基づいて、XML文書1をXML文書2に変換する(S05,XML文書変換部85)。
なお、S05において、出力スタイルシートは、配信情報の受信者情報に含まれる「出力スタイルシート情報」によって指定されたものを用いる。これにより、受信者(デバイス50)毎に異なる出力スタイルシートを適用可能となっている。したがって、受信者がキッチンプリンタ61の場合は、XMLPOSで表されるXML文書2に変換し、受信者がキッチンディスプレイ63の場合は、XHTML等の表示用言語で表されるXML文書2に変換する、といった処理も可能である。また、詳細については後述するが、各出力スタイルシートには、「条件式」を含めることができるようになっている。出力スタイルシートに「条件式」が含まれる場合は、XML文書1内の出力データがこの「条件式」を満たす場合のみXML文書2への変換を行う。言い換えれば、XML文書1内の出力データが、出力スタイルシートに含まれる「条件式」を満たさない場合、XML文書2への変換およびその配信を実行しない。但し、出力シートによって異なる「条件式」を設定可能であるため、受信者として2つのキッチンプリンタ61を指定し、出力データがある条件を満たす場合は、第1のキッチンプリンタ61に配信し、出力データがある条件を満たさない場合は、第2のキッチンプリンタ61に配信する、といった条件付きの同送処理を行うことも可能である。
また、サーバー30は、変換後のXML文書2を、各デバイス50のデバイス制御サービス73,75に出力する(S06,デバイス別XML文書入出力部86)。なお、出力先(対象デバイス)は、配信情報の受信者情報に含まれる「宛先情報」によって特定される。デバイス50(デバイス制御サービス73,75)は、サーバー30から出力されたXML文書2を取得する(S07)。
続いて、図5のフローチャートを参照し、店内管理システムSYの応答処理について説明する。デバイス50は、S07で取得したXML文書2に対する配信結果として、成否情報、補足情報および応答情報を含むXML文書3を生成し、サーバー30に送信する(S11)。サーバー30は、当該XML文書3を取得し(S12,デバイス別XML文書入出力部86)、予め登録されていた入力スタイルシートに基づいて、XML文書3をXML文書4に変換する(S13,XML文書変換部85)。なお、入力スタイルシートは、配信情報の受信者情報に含まれる「入力スタイルシート情報」によって指定されたものを、スタイルシートデータベース81から読み出して用いる。これにより、サーバー30が複数のPC20(アプリケーション41)と提携している場合でも、送信者であるアプリケーション41毎に異なる入力スタイルシートを利用して、好適な情報に変換することができる。
また、サーバー30は、XML文書2を複数のデバイス50に対して送信した場合、当該複数のデバイス50からの配信結果(XML文書3)を統合して、XML文書4に変換する。サーバー30は、変換後のXML文書4を、XML文書1(出力データを)送信したPC20に入力する(S14)。また、送信者となるPC20(アプリケーション41)は、サーバー30から入力された当該XML文書4を取得する(S15)。
次に、図6ないし図11を参照し、「出力データ」、「配信情報」、「スタイルシート」および「配信結果」の具体例について説明する。図6は、XML文書1に相当する「出力データ」の一例を示す図である。ここでは、オーダリング端末10から、注文情報「生ビールを1つ,ヒレステーキを1つ,シーザーサラダを1つ」を取得した場合に生成される出力データを示している。符号101に示すように、「出力データ」には、シーケンス番号、アイテムID、アイテム名(料理名)を示す情報が含まれている。なお、ドリンク部門のアイテムIDは100番台であり、グリル部門のアイテムIDは200番台であり、サラダ部門のアイテムIDは300番台と規定されているものとする。この他、「出力データ」には、レストラン名、注文日時、オーダリング端末10のID、オーダリング端末10の操作者コード、価格(単価、合計)、顧客データ(性別、年代)などの情報を含めても良い。
図7は、XML文書1に相当する「配信情報」の一例を示す図である。同図の例では、5台のキッチンプリンタ61についての「受信者情報」が記述されている。符号111に示すように、第1のデバイス要素では、「キッチンプリンタ1」が主受信者であり、その予備受信者が「キッチンプリンタ2」であり、さらにその予備受信者が「キッチンプリンタ3」となっている。したがって、最初に「キッチンプリンタ1」に送信を試み、配信エラーとなった場合は、「キッチンプリンタ2」に送信を試み、さらに配信エラーとなった場合は、「キッチンプリンタ3」に送信を試みることとなる。一方、符号112に示すように、第2のデバイス要素では、「キッチンプリンタ4」が主受信者であり、その予備受信者が「キッチンプリンタ5」となっている。したがって、最初に「キッチンプリンタ4」に送信を試み、配信エラーとなった場合は、「キッチンプリンタ5」に送信を試みることとなる。また、第3のデバイス要素は、符号113に示すように、第2のデバイス要素と同様の構成となっている。したがって、最初に「キッチンプリンタ6」に送信を試み、配信エラーとなった場合は、「キッチンプリンタ7」に送信を試みることとなる。
なお、第1のデバイス要素は、グリル部門のキッチンプリンタ61、第2のデバイス要素は、サラダ部門のキッチンプリンタ61、第3のデバイス要素は、ドリンク部門のキッチンプリンタ61に関するものであり、各デバイス50(各部門)に対応した出力スタイルシートが指定されている。また、上記のとおり「配信情報」の中には、受信者毎に、「出力スタイルシート情報」および「制限時間」が記述されている。なお、同図の例では、「配信情報」に含めることが可能な「入力スタイルシート情報」についての記述は、省略している。
図8(a)は、ドリンク部門のキッチンプリンタ61用に生成された「出力スタイルシート」の一例を示す図である。同図は、符号121に示すように、アイテムID(メニューID)が100番台のアイテムについて、注文内容(注文があった旨、並びにアイテム名および注文数)を印刷するためのスタイルシートを例示している。なお、波線で示す<xsl:if test>要素が、本スタイルシートの「条件式」となる。したがって、本スタイルシートは、出力データに含まれる「アイテムIDが100番台のアイテム」について適用される。また、同図のスタイルシートにより、XML文書2は、キッチンプリンタ61に接続されたPOSターミナル51が解釈可能な印刷言語(XMLPOS)で記述される。
図8(b)は、XML文書2の一例を示す図である。同図の例は、図8(a)の出力スタイルシートに基づいて情報変換が行われた場合のXML文書2を例示している。すなわち、符号122に示すように、ドリンク部門のキッチンプリンタ61(「キッチンプリンタ6」および「キッチンプリンタ7」,図7参照)に対し、注文内容の印刷指令を行う内容となっている。
また、図9(a)は、グリル部門のキッチンプリンタ61用に生成された「出力スタイルシート」の一例を示す図である。同図は、符号123に示すように、アイテムID(メニューID)が200番台のアイテムについて、注文内容を印刷するためのスタイルシートを例示している。なお、下線部は、図8(a)に示した「出力スタイルシート」の記述と異なる部分を示しており、図9(a)の「出力スタイルシート」では「条件式」に相当する。本スタイルシートは、出力データに含まれる「アイテムIDが200番台のアイテム」について適用される。図9(b)は、図9(a)の出力スタイルシートに基づいて情報変換が行われた場合のXML文書2を例示している。すなわち、符号124に示すように、グリル部門のキッチンプリンタ61(「キッチンプリンタ1」、「キッチンプリンタ2」および「キッチンプリンタ3」,図7参照)に対し、注文内容の印刷指令を行う内容となっている。なお、下線部は、図8(b)に示した「XML文書2」の記述と異なる部分を示している。
同様に、図10(a)は、サラダ部門のキッチンプリンタ61用に生成された「出力スタイルシート」の一例を示す図である。同図は、符号125に示すように、アイテムID(メニューID)が300番台のアイテムについて、注文内容を印刷するためのスタイルシートを例示している。なお、下線部の「条件式」に示すとおり、本スタイルシートは、出力データに含まれる「アイテムIDが300番台のアイテム」について適用される。図10(b)は、図10(a)の出力スタイルシートに基づいて情報変換が行われた場合のXML文書2を例示している。すなわち、符号126に示すように、サラダ部門のキッチンプリンタ61(「キッチンプリンタ4」および「キッチンプリンタ5」,図7参照)に対し、注文内容の印刷指令を行う内容となっている。
図11は、XML文書4に相当する「配信結果」の一例を示す図である。同図の例は、図7に示した「配信情報」に対応するものである。すなわち、符号131ないし符号133に示すように、以下の内容が記述されている。“主受信者「キッチンプリンタ1」および「キッチンプリンタ4」に対して送信を試み、「キッチンプリンタ1」はデバイス50が見つからずに動作が失敗し、その予備受信者である「キッチンプリンタ2」に送信を試みた。しかし、「キッチンプリンタ2」もタイムアウトとなり動作が失敗した。そこで、さらにその予備受信者である「キッチンプリンタ3」に送信を試み、正常に動作した。一方、「キッチンプリンタ4」および「キッチンプリンタ6」については、予備受信者(「キッチンプリンタ5」および「キッチンプリンタ7」)に送信を試みることなく、正常に動作した。”なお、「配信結果」の「成否情報」は、「レスポンスコード」要素に相当し、「補足情報」および「応答情報」は、「ビジネスエラー」要素やその子要素に相当する。
次に、図12ないし図15を参照し、サーバー30の代替処理について具体的に説明する。上記のとおりサーバー30は、主受信者に対して正常に配信できなかった場合、予備受信者に対して情報配信を試みるものとしたが、同一の情報を送信すると、所望する目的が達成できなかったり、主受信者と予備受信者とが異なる種類のデバイス50である場合など、正常に動作させることができなかったりする場合がある。そこで、このような問題を解決するための具体的な処理内容について、以下説明する。
図12は、サーバー30の代替処理を示すフローチャートである。サーバー30(統合デバイス制御サービス44)は、図5に示した応答処理によって、XML文書3を取得すると(S21,図5のS12に相当)、情報配信が成功したか否かを判別する(S22)。ここで、情報配信が正常に行われなかったと判別した場合は(S22:No)、「配信情報」に「予備受信者情報」が含まれているか否かを判別する(S23)。「配信情報」に「予備受信者情報」が含まれている場合は(S23:Yes)、予備受信者用の出力スタイルシート(以下、「予備出力スタイルシート」と称する。)に基づいて、XML文書1をXML文書2に変換し(S24,XML文書変換部85)、当該XML文書2を予備受信者となる対象デバイスのデバイス制御サービス73,75に出力する(S25,デバイス別XML文書入出力部86)。なお、予備受信者への配信を行った場合は、さらにその情報配信が成功したか否かを判別し(S22)、情報配信が正常に行われなかったと判別した場合は(S22:No)、さらに優先順位の低い「予備受信者情報」が存在するか否かを判別し(S23)、S24以降の処理を行う。
一方、情報配信が正常に行われたと判別した場合(S22:Yes)、並びに「配信情報」に「予備受信者情報」が含まれていない場合は(S23:Yes)、予備受信者への配信を行うことなく、入力スタイルシートに基づいて、「配信結果」を示すXML文書3をXML文書4に変換し(S26,図5のS13に相当)、当該XML文書4を送信者であるアプリケーション41に入力する(S27,図5のS14に相当)。
続いて、図13ないし図15を参照し、「予備出力スタイルシート」の具体例について説明する。図13(a)は、ドリンク部門から他部門(グリル部門またはサラダ部門)のキッチンプリンタ61へ出力するための出力スタイルシートを示したものであり、図8に示した「出力スタイルシート」を主受信者用の出力スタイルシート(以下、「主出力スタイルシート」と称する。)とした場合の「予備出力スタイルシート」となる。なお、図13ないし図15において、下線部は、図8に示した「出力スタイルシート」および「XML文書2」の記述と異なる部分を示している。したがって、下線部分の書換えのみで(アプリケーション41の変更を必要とすることなく)、代替処理用の「予備出力スタイルシート」の生成が可能であり、ひいては、本実施形態における代替処理を実現可能となっている。
符号141に示すように、図13(a)の「予備出力スタイルシート」は、アイテムIDが100番台のアイテムについて(「条件式」)、注文内容と共に、ドリンク部門(本来の配信先)に転送して欲しい旨を印刷するためのスタイルシートとなっている。つまり、ドリンク部門のキッチンプリンタ61がレシート切れ等で正常に動作できない場合、他部門のキッチンプリンタ61で、図13(b)に示すXML文書2(符号142参照)に基づく印刷を実行可能となっている。これにより、他部門のスタッフが、ドリンク部門に調理指令の印刷物を回すことができ、調理業務を支障なく遂行することができる。
なお、図13(a)に示した「予備出力スタイルシート」は、他部門(グリル部門またはサラダ部門)のキッチンプリンタ61で共用することができる。つまり、出力スタイルシートは、必ずしもデバイス50毎に異なるものを用意しておく必要は無い。また、「予備出力スタイルシート」としては、上記のとおり「ドリンク部門に転送して欲しい旨」の追加情報を調理指示伝票の中に挿入するのではなく、用紙のヘッダ余白部や、送付状として付加した用紙に印刷するような内容を記述しても良い。
一方、図14(a)は、ドリンク部門の厨房機器62(ドリンクベンダー)に対する動作を指令するための出力スタイルシートを示したものである。また、図15(a)は、ドリンク部門のキッチンディスプレイ63に対する動作を指令するための出力スタイルシートを示したものである。なお、図15の出力スタイルシートは、図14に示した「出力スタイルシート」を「主出力スタイルシート」とした場合の「予備出力スタイルシート」となる。
符号151に示すように、図14(a)の出力スタイルシートは、ドリンクベンダーに対し、アイテムIDが100番台のアイテム(ドリンク類)を(「条件式」)、グラス等に注ぐ動作を指令するためのスタイルシートとなっている。また、当該出力スタイルシートに基づいて、図14(b)に示すXML文書2(符号152参照)を生成可能となっている。なお、当該XML文書2は、プロトコルコンバータ52(図1参照)が解釈可能な言語で記述されている。
また、符号161に示すように、図15(a)の出力スタイルシートは、ドリンク部門のキッチンディスプレイ63に対し、アイテムIDが100番台のアイテム(ドリンク類)の注文内容を(「条件式」)、キッチンディスプレイ63に表示させるためのスタイルシートとなっている。また、当該スタイルシートに基づいて、図15(b)に示すXML文書2(符号162参照)を生成可能となっている。なお、当該XML文書2は、キッチンディスプレイ63が解釈可能な言語(XHTML)で記述されている。
このように(図14および図15に例示したように)、ドリンクベンダーが故障等により正常に動作できない場合、キッチンディスプレイ63を用いて、同じ目的を実現する(ドリンクの注文に対応する)ことができる。つまり、アプリケーション41の変更を全く必要とすることなく、「配信情報」に「受信者情報」を追加し、さらに下線部を書き換えた代替用のスタイルシートを生成するだけで、種類の異なるデバイス50で、同じ目的を実現することが可能となる。
以上、説明したとおり、本実施形態の店内管理システムSYによれば、スタイルシートによって、処理内容の変更、並びにデバイス50の種類や仕様の違いを吸収できるため、アプリケーション41による直接的なデバイス制御を不要とすることができる。これにより、アプリケーション41の作成が容易になると共に、処理内容の変更やデバイス50の入れ替えに伴うアプリケーション41の変更を不要とすることができる。
また、デバイス別XML文書入出力部86により、既存デバイス50aおよび新デバイス50bに対応した2種類のデバイス制御サービス73,75を呼び出すことができるため、例えば既存デバイス50aが新デバイス50bに入れ替えられたような場合にも、アプリケーション41の変更を不要とすることができる。
また、「出力データ」、「配信情報」および「配信結果」をXMLで記述することにより、テキストエディタ等で簡単に編集ができると共に、XSL以外の情報変換規則を新たに生み出す必要が無いなどの利点がある。また、デバイス別サービス情報(デバイス制御サービス73,75に関する情報)をWSDLで記述することにより、Webサービスの実装が容易となる。また、印刷言語としてXMLPOSを用いることで、メーカーを問わず、30種類以上のPOSデバイスを制御することが可能となる。
また、送信者であるアプリケーション41毎に入力スタイルシートを指定できるため、統合デバイス制御サービス44が、複数のアプリケーション41と提携している場合でも、各アプリケーション41に応じたXML文書4(配信結果)を取得することができる。
また、「出力スタイルシート」に「条件式」を含めることができるため、出力データの配信を制限することができる。これにより、出力データの配信を、該当する部門のアイテムIDが出力データに含まれる場合のみに制限することができる。また、「条件式」は、出力スタイルシート毎(デバイス毎)に指定できるため、複数のデバイス50を受信者として設定しておくことで、条件付きの同送処理を行うことができる。
また、代替処理により、主受信者情報に基づく情報配信が正常に行われなかった場合は、予備受信者情報に基づいて情報配信を行うため、主受信者と予備受信者の仕様が異なる場合でも、正常に動作させることができる。さらに、出力スタイルシートでは、XML文書2の記述言語を指定できるため、解釈可能な記述言語が異なる複数種類のデバイス50に対応することもできる。これにより、各店舗のデバイス環境に応じて、デバイス50の入れ替えを柔軟に行うことができる。
なお、上記の実施形態では、店内管理システムSYを例示したが、他の環境でも、本実施形態のサーバー30(統合デバイス制御サービス44)を適用可能である。例えば、デバイス50として、電子メール送信装置、ページプリンタ、大判プリンタ、電子棚札、POSコンピュータを有する販促管理システム(いずれも図示省略)に、本実施形態のサーバー30を適用した場合、クリアランスセール情報の取得をトリガとして、顧客データベースからクリアランス商品に興味のある顧客を抽出して、セール情報を電子メール送信装置に送信させる。この場合、上得意客には、クーポン情報を添付し、第1のメールアドレスへの配信が失敗した場合は第2のメールアドレスへの配信を行う(代替処理)。また、ページプリンタには、メールアドレスが登録されていない顧客用に、郵送用のダイレクトメールを印刷させ、大判プリンタには、セール情報のPOPを印刷させる。さらに、電子棚札には、価格情報をセール価格に変更する指令を出し、POSコンピュータには、商品マスタに登録された商品価格の変更を指令する。
また、上記の実施形態では、「条件式」の例として、「出力データに該当する部門のアイテムIDが含まれること」を挙げたが、「出力データに『男性』を示す顧客情報が含まれること」、「出力データに『深夜帯』を示す日時情報が含まれること」など、他の条件を設定しても良い。また、出力データに含まれる内容に関するものではなく、「出力データの容量が所定サイズ以上であること」、「出力データの出力日時が所定の日時条件を満たすこと」など出力データに関する種々の事項について、「条件式」を設定しても良い。
また、上記の実施形態では、「条件式」の記述として、<xsl:if test>要素を例示したが(図8(a)等参照)、これ以外にも、<xsl:choose>要素や<xsl:template>要素など、他の記述で「条件式」を表しても良い。
また、上記の実施形態で示した同一デバイス間における代替処理を、POSターミナル51間の転送に用いても良い。例えば、POSターミナル51が複数設置されているスーパー等の売場において、任意のPOSターミナル51が故障した場合、予備受信者として指定された隣のPOSターミナル51のプリンタから、発行元として隣のPOSターミナル51のIDが付記されたレシートを発行することが可能である。
また、上記の実施形態で示した異なる種類のデバイス間における代替処理を、クーポン発行に用いても良い。例えば、電子バリューリーダライタやポイントカードリーダライタ(電子クーポンを発行する装置)が故障した場合、予備受信者として指定されたクーポンプリンタ(紙のクーポンを発行する装置)でクーポンを発行することが可能である。その他、種々の環境で、統合デバイス制御サービス44を用いたサービスを実現可能である。
また、上記の実施形態に示した、サーバー30やPC20の各構成要素をプログラムとして提供することが可能である。また、そのプログラムを各種記録媒体(CD−ROM、フラッシュメモリ等)に格納して提供することも可能である。すなわち、コンピュータを、サーバー30やPC20の各構成要素として機能させるためのプログラム、およびそれを記録した記録媒体も、本発明の権利範囲に含まれるものである。その他、本発明の要旨を逸脱しない範囲で、適宜変更が可能である。