JP5800000B2 - 制御方法 - Google Patents

Description

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

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

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

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

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

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

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

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

なお、「第１文書」として、「出力データ」、「出力対象となる対象デバイスを指定す
る情報」および「出力用のスタイルシートを指定する情報」を、必ずしも同時に取得する
必要はない。例えば、「出力データ」と、「出力対象となる対象デバイスを指定する情報
」および「出力用のスタイルシートを指定する情報」とを、別のタイミングで取得し、両
者を関連付ける情報に基づいて、第２文書への変換処理を行っても良い。

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

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

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

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

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

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

なお、「配信結果」とは、「成否情報」、「補足情報」および「応答情報」を含む概念
である。ここで、「補足情報」とは、デバイスのステータス等を示す情報を指し、「応答
情報」とは、デバイスによる入力データを指す。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Claims (6)

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

Images