JP5381009B2 - デバイス制御システム - Google Patents

Description

本発明は、アプリケーションから取得した情報に基づいてデバイスを制御するデバイス制御システム、デバイス制御システムのサービス実現方法およびそのプログラムに関するものである。

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

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

本発明は、上記の問題点に鑑み、処理内容の変更、並びにデバイスの種類や仕様の変更に伴うアプリケーションの変更を不要とすることができるデバイス制御システム、デバイス制御システムのサービス実現方法およびそのプログラムを提供することを目的とする。

本発明のデバイス制御システムは、アプリケーションから情報を取得して、複数のデバイスを統合的に制御するデバイス制御システムであって、マークアップ文書の情報変換規則を示す複数のスタイルシートを記憶するスタイルシートデータベースと、アプリケーションの出力データ、並びに出力対象となる複数の対象デバイスを指定する情報および複数の対象デバイスに対応した出力用のスタイルシートを指定する情報を含むマークアップ文書である第１文書を取得する通信インターフェースと、通信インターフェースから取得した第１文書と複数の対象デバイスの内の所定の対象デバイスに対応する出力用のスタイルシートとに基づいて、所定の対象デバイスのデバイス制御情報を含むマークアップ文書である第２文書に変換するマークアップ文書変換部と、を備えたことを特徴とする。

本発明のデバイス制御システムのサービス実現方法は、マークアップ文書の変換規則を示す複数のスタイルシートを記憶するスタイルシートデータベースを管理すると共に、アプリケーションから情報を取得して、複数のデバイスを統合制御するデバイス制御システムのサービス実現方法であって、デバイス制御システムが、アプリケーションの出力データ、並びに当該出力データの出力対象となる複数の対象デバイスを指定する情報および複数の対象デバイスに対応した出力用のスタイルシートを指定する情報を含むマークアップ文書である第１文書を取得するステップと、スタイルシートデータベースから所定の対象デバイスに対応した出力用のスタイルシートを抽出し、当該所定の対象デバイスに対応した出力用のスタイルシートと第１文書とに基づいて、所定の対象デバイスのデバイス制御情報を含むマークアップ文書である第２文書に変換するステップと、第２文書を、所定の対象デバイスに向けて出力するステップと、を実行することを特徴とする。

これらの構成によれば、スタイルシートに基づいて、アプリケーションの出力データ（第１文書）を、出力対象（制御対象）となる対象デバイスのデバイス制御情報を含む第２文書に変換するため、処理内容が変更となった場合や、デバイスの入れ替えがあった場合（種類や仕様の異なるデバイスに入れ替えられた場合）でも、アプリケーションの変更を不要とすることができる。つまり、スタイルシートによって、処理内容の変更、並びにデバイスの種類や仕様の違いを吸収できるため、アプリケーションによる直接的なデバイス制御を不要とすることができる。これにより、アプリケーションの作成が容易になると共に、処理内容の変更やデバイスの入れ替えに伴うアプリケーションの変更処理に要する手間やコストを軽減できる。また、マークアップ文書の記述言語として、ＸＭＬ（Extensible Markup Language）が知られているが、これを用いることで、記述内容が機能を表すと共に特定の言語や文化に依存しないため設計が容易である、文書構造の曖昧さを排除できる、などの利点がある。
なお、「第１文書」として、「出力データ」、「出力対象となる対象デバイスを指定する情報」および「出力用のスタイルシートを指定する情報」を、必ずしも同時に取得する必要はない。例えば、「出力データ」と、「出力対象となる対象デバイスを指定する情報」および「出力用のスタイルシートを指定する情報」とを、別のタイミングで取得し、両者を関連付ける情報に基づいて、第２文書への変換処理を行っても良い。

上記に記載のデバイス制御システムにおいて、マークアップ文書変換部から取得した第２文書を、所定の対象デバイスに対応するデバイス制御サービスに出力するデバイス別マークアップ文書入出力部をさらに備えたことを特徴とする。

上記に記載のデバイス制御システムにおいて、所定の対象デバイスに対応するデバイス制御サービスには、当該所定の対象デバイスとは別体で存在するサービス、および当該対象デバイス内に存在するサービスが含まれていることを特徴とする。

これらの構成によれば、デバイス別マークアップ文書入出力部により、「対象デバイスとは別体で存在するサービス」、および「対象デバイス内に存在するサービス（サービス化されたデバイス）」を呼び出すことが可能であり、言い換えれば、これらのデバイス制御サービスを同様に扱うことができる。これにより、例えば既存のデバイスドライバ（対象デバイスとは別体で存在するサービス）を利用する既存デバイスが、サービス化された新デバイスに入れ替えられたような場合でも、アプリケーションの変更を不要とすることができる。

上記に記載のデバイス制御システムにおいて、第１文書は、対象デバイスへの配信結果をアプリケーションに入力するための入力用のスタイルシートを指定する情報をさらに含んでおり、デバイス別マークアップ文書入出力部は、所定の対象デバイスへの配信結果を含むマークアップ文書である第３文書を、マークアップ文書変換部に入力し、マークアップ文書変換部は、第３文書を、入力用のスタイルシートに基づいて、アプリケーション用のマークアップ文書である第４文書に変換し、通信インターフェースは、第４文書を、アプリケーションに入力することを特徴とする。

上記に記載のデバイス制御システムにおいて、通信インターフェースは、複数のアプリケーションから、出力データを取得可能であり、スタイルシートデータベースは、複数のアプリケーションに対応した複数種類の入力用のスタイルシートを記憶していることを特徴とする。

これらの構成によれば、アプリケーションは、デバイスへの配信結果を示す第４文書を取得することができる。また、デバイス制御システムが、複数のアプリケーションと提携している場合でも、アプリケーション毎に入力用のスタイルシートを指定できるため、各アプリケーションに応じた第４文書を入力することができる。
なお、「配信結果」とは、「成否情報」、「補足情報」および「応答情報」を含む概念である。ここで、「補足情報」とは、デバイスのステータス等を示す情報を指し、「応答情報」とは、デバイスによる入力データを指す。

上記に記載のデバイス制御システムにおいて、スタイルシートデータベースは、第１文書を、記述言語の異なる第２文書に変換するための複数種類の出力用のスタイルシートを記憶しており、複数のデバイスには、解釈可能な記述言語が異なる複数種類のデバイスが含まれていることを特徴とする。

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

本発明のプログラムは、コンピュータに、上記に記載のデバイス制御システムのサービス実現方法における各ステップを実行させるためのものであることを特徴とする。

このプログラムを用いることにより、処理内容の変更、並びにデバイスの種類や仕様の変更に伴うアプリケーションの変更を不要とすることができるデバイス制御システムのサービスを実現することができる。

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

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

ＰＣ２０は、ＣＰＵ（Central Processing Unit）２１、ＲＯＭ（Read Only Memory）２２、ＲＡＭ（Random Access Memory）２３、入力デバイス２４、通信インターフェース２５、ディスプレイ２６およびＨＤＤ（Hard Disk Drive）２７を備えている。通信インターフェース２５は、オーダリング端末１０と無線通信を行うためのものであり、本実施形態では主に注文情報の受信に用いられる。

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

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

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

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

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

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

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

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

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

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

スタイルシートデータベース８１は、ＰＣ２０から取得したスタイルシート（スタイルシート管理部７１によって登録されたスタイルシート）を記憶する。ここで、スタイルシートは、ＸＳＬ（Extensible Stylesheet Language）で記述される。また、デバイス別サービス情報データベース８２は、デバイス制御サービス管理部７２によって登録されたデバイス別サービス情報を記憶する。ここで、デバイス別サービス情報は、ＷＳＤＬで記述される。

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

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

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

次に、図３を参照し、情報配信処理に用いられる「配信情報」、および応答処理に用いられる「配信結果」の詳細について説明する。なお、各情報要素に付加された大括弧は、多重度を表すものである。

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

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

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

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

一方、ＰＣ２０は、オーダリング端末１０からの注文情報の取得に伴い、出力データを生成し、配信情報と共に、ＸＭＬ文書１として、サーバー３０（統合デバイス制御サービス４４）に配信する（Ｓ０３）。なお、配信情報は、出力データの配信前に、予め送信しておくことも可能である。サーバー３０は、ＰＣ２０からＸＭＬ文書１を取得し（Ｓ０４，通信インターフェース８４）、予め登録されていた出力スタイルシートに基づいて、ＸＭＬ文書１をＸＭＬ文書２に変換する（Ｓ０５，ＸＭＬ文書変換部８５）。なお、出力スタイルシートは、配信情報の受信者情報に含まれる「出力スタイルシート情報」によって指定されたものを用いる。これにより、受信者（デバイス５０）毎に異なる出力スタイルシートを適用可能となっている。したがって、受信者がキッチンプリンタ６１の場合は、ＸＭＬＰＯＳで表されるＸＭＬ文書２に変換し、受信者がキッチンディスプレイ６３の場合は、ＸＨＴＭＬ等の表示用言語で表されるＸＭＬ文書２に変換する、といった処理も可能である。

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

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

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

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

図７は、ＸＭＬ文書１に相当する「配信情報」の一例を示す図である。同図の例では、５台のキッチンプリンタ６１についての「受信者情報」が記述されている。符号１１１に示すように、第１のデバイス要素では、「キッチンプリンタ１」が主受信者であり、その予備受信者が「キッチンプリンタ２」であり、さらにその予備受信者が「キッチンプリンタ３」となっている。したがって、最初に「キッチンプリンタ１」に送信を試み、配信エラーとなった場合は、「キッチンプリンタ２」に送信を試み、さらに配信エラーとなった場合は、「キッチンプリンタ３」に送信を試みることとなる。一方、符号１１２に示すように、第２のデバイス要素では、「キッチンプリンタ４」が主受信者であり、その予備受信者が「キッチンプリンタ５」となっている。したがって、最初に「キッチンプリンタ４」に送信を試み、配信エラーとなった場合は、「キッチンプリンタ５」に送信を試みることとなる。また、上記のとおり「配信情報」の中には、受信者毎に、「出力スタイルシート情報」および「制限時間」が記述されている。なお、同図の例では、「配信情報」に含めることが可能な「入力スタイルシート情報」についての記述は、省略している。

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

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

図９は、ＸＭＬ文書４に相当する「配信結果」の一例を示す図である。同図の例は、図７に示した「配信情報」に対応するものである。すなわち、符号１３１および符号１３２に示すように、以下の内容が記述されている。“主受信者「キッチンプリンタ１」および「キッチンプリンタ４」に対して送信を試み、「キッチンプリンタ１」はデバイス５０が見つからずに動作が失敗し、その予備受信者である「キッチンプリンタ２」に送信を試みた。しかし、「キッチンプリンタ２」もタイムアウトとなり動作が失敗した。そこで、さらにその予備受信者である「キッチンプリンタ３」に送信を試み、正常に動作した。一方、「キッチンプリンタ４」については、予備受信者（「キッチンプリンタ５」）に送信を試みることなく、正常に動作した。”なお、「配信結果」の「送信結果」は、「デバイス要素」に相当する。また、「送信結果」の「成否情報」は、「レスポンスコード」要素に相当し、「補足情報」および「応答情報」は、「ビジネスエラー」要素やその子要素に相当する。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

店内管理システムのシステム構成図である。 サーバーの機能ブロック図である。 「配信情報」および「配信結果」の説明図である。 店内管理システムの情報配信処理を示すフローチャートである。 店内管理システムの応答処理を示すフローチャートである。 ＸＭＬ文書１（出力データ）の具体例を示す図である。 ＸＭＬ文書１（配信情報）の具体例を示す図である。 出力スタイルシートおよびＸＭＬ文書２の具体例を示す図である。 ＸＭＬ文書４（配信結果）の具体例を示す図である。 サーバーの代替処理を示すフローチャートである。 予備出力スタイルシートおよびＸＭＬ文書２の具体例を示す図である。 出力スタイルシートおよびＸＭＬ文書２の具体例を示す図である。 予備出力スタイルシートおよびＸＭＬ文書２の具体例を示す図である。

符号の説明

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

Claims (6)

1. 複数のデバイスを制御するデバイス制御システムであって、
   印刷もしくは表示する情報を含む出力データを出力するアプリケーションを動作させる端末と、
   前記出力データに含まれる情報を印刷もしくは表示させるためのマークアップ文書の情報変換規則を示す複数の出力用のスタイルシートを記憶するスタイルシートデータベース、前記出力データ並びに複数の出力対象となるデバイスを指定する情報および前記スタイルシートデータベースに記憶された前記複数の出力対象となるデバイスに対応した出力用のスタイルシートを指定する情報を含むマークアップ文書である第１文書を前記端末から取得する通信インターフェース、前記通信インターフェースから取得した前記第１文書を、前記第１文書で指定された出力用のスタイルシートに基づいて、前記出力対象となるデバイスのデバイス制御情報を含むマークアップ文書である第２文書に変換するマークアップ文書変換部、及び前記第２文書を出力するマークアップ文書入出力部を有するデバイス制御装置と、
   前記デバイス制御装置の前記マークアップ文書入出力部から出力された前記第２文書を受信し、前記第２文書に基づいて印刷もしくは表示する複数のデバイスと、
   を備えることを特徴とするデバイス制御システム。
2. 前記マークアップ文書入出力部は、前記第２文書を、前記出力対象となるデバイスに対応するデバイス制御サービスに出力する請求項１に記載のデバイス制御システム。
3. 前記出力対象となるデバイスに対応するデバイス制御サービスは、当該出力対象となるデバイスとは別体で存在するサービス、および当該対象となるデバイス内に存在するサービスを含む請求項２に記載のデバイス制御システム。
4. 前記第１文書は、前記出力対象となるデバイスへの配信結果を前記アプリケーションに入力するための入力用のスタイルシートを指定する情報をさらに含んでおり、
   前記マークアップ文書入出力部は、前記出力対象となるデバイスへの配信結果を含むマークアップ文書である第３文書を、前記マークアップ文書変換部に入力し、
   前記マークアップ文書変換部は、前記第３文書を、前記入力用のスタイルシートに基づいて、前記アプリケーション用のマークアップ文書である第４文書に変換し、
   前記通信インターフェースは、前記第４文書を、前記アプリケーションに取得させる請求項２または３に記載のデバイス制御システム。
5. 前記通信インターフェースは、複数の前記アプリケーションから、前記出力データを取得可能であり、
   前記スタイルシートデータベースは、前記複数のアプリケーションに対応した複数種類の前記入力用のスタイルシートを記憶する請求項４に記載のデバイス制御システム。
6. 前記スタイルシートデータベースは、前記第１文書を、記述言語の異なる前記第２文書に変換するための複数種類の前記出力用のスタイルシートを記憶しており、
   前記複数のデバイスには、解釈可能な記述言語が異なる複数種類のデバイスが含まれる請求項１ないし５のいずれか１項に記載のデバイス制御システム。
   

Images