JP2013178834A - 配信システム、及びデータ配信方法 - Google Patents

Abstract

【課題】処理内容の変更、並びに受信者の種類や仕様の変更に伴うアプリケーション変更の手間を軽減することができると共に、同送処理に対応することができる情報配信システム等を提供する。
【解決手段】情報配信に関する条件式を含む情報変換規則である複数のスタイルシートを記憶するスタイルシートデータベース８１と、アプリケーション４１から、出力データと、受信者の宛先および当該受信者に対応した出力スタイルシートとを指定する受信者情報と、を取得する統合デバイス制御サービス４４と、を備え、統合デバイス制御サービス４４は、出力データが出力スタイルシートに含まれる条件式を満たす場合、当該出力データを出力スタイルシートに基づいて変換した変換出力データを、受信者の宛先に配信することを特徴とする。
【選択図】図２

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）を利用して、ＸＭＬ文書を変換する。さらに、デバイス別ＸＭＬ文書入出力部８６は、ＸＭＬ文書変換部８５から取得したＸＭＬ文書２を、対象デバイスに対応するデバイス制御サービス７３，７５に出力する。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

また、上記の実施形態では、「条件式」の記述として、＜xsl:if test＞要素を例示したが（図８（ａ）等参照）、これ以外にも、＜xsl:choose＞要素や＜xsl:template＞要素など、他の記述で「条件式」を表しても良い。

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

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

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

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

Claims (8)

1. 送信者から取得した情報を受信者に配信する情報配信システムであって、
   情報配信に関する条件式を含む情報変換規則である複数の出力用スタイルシートを記憶する記憶部と、
   前記送信者から、出力データを取得する出力データ取得部と、
   前記出力データを配信する前記受信者の宛先と、当該受信者に対応した前記出力用スタイルシートと、を指定する受信者情報を取得する受信者情報取得部と、
   前記出力データが、前記受信者情報によって指定された前記出力用スタイルシートに含まれる前記条件式を満たすか否かを判別する条件判別部と、
   前記出力データが前記条件式を満たす場合、当該出力データを、前記出力用スタイルシートに基づいて変換した出力変換データを、前記受信者情報によって指定された前記宛先に配信する配信部と、を備えたことを特徴とする情報配信システム。
2. 前記受信者情報取得部は、複数の前記受信者情報を取得し、
   前記複数の受信者情報は、それぞれ異なる前記条件式を含む前記出力用スタイルシートを指定することを特徴とする請求項１に記載の情報配信システム。
3. 前記受信者情報は、前記送信者に対応した情報変換規則である入力用スタイルシートをさらに指定するものであり、
   前記受信者からの入力データを、前記入力用スタイルシートに基づいて変換した入力変換データを、前記送信者に入力する応答部をさらに備えたことを特徴とする請求項１または２に記載の情報配信システム。
4. 前記出力データ取得部は、複数の前記送信者から前記出力データを取得可能であり、
   前記記憶部は、前記複数の送信者に対応した複数の前記入力用スタイルシートを記憶していることを特徴とする請求項３に記載の情報配信システム。
5. 前記送信者は、アプリケーションであると共に、前記受信者は、デバイスであり、
   前記出力データ、前記出力変換データ、前記入力データおよび前記入力変換データは、いずれもマークアップ文書であることを特徴とする請求項３または４に記載の情報配信システム。
6. 前記記憶部は、前記出力データを、記述言語の異なる前記出力変換データに変換するための複数の出力用スタイルシートを記憶しており、
   前記受信者は、解釈可能な記述言語が異なる複数種類のデバイスを含むことを特徴とする請求項５に記載の情報配信システム。
7. 情報配信に関する条件式を含む情報変換規則である複数の出力用スタイルシートを記憶するデータベースを管理すると共に、送信者から取得した情報を受信者に配信する情報配信システムのサービス実現方法であって、
   前記情報配信システムが、
   前記送信者から、出力データを取得するステップと、
   前記出力データを配信する前記受信者の宛先と、当該受信者に対応した前記出力用スタイルシートと、を指定する受信者情報を取得するステップと、
   前記出力データが、前記受信者情報によって指定された前記出力用スタイルシートに含まれる前記条件式を満たすか否かを判別するステップと、
   前記出力データが前記条件式を満たす場合、当該出力データを、前記出力用スタイルシートに基づいて変換した出力変換データを、前記受信者情報によって指定された前記宛先に配信するステップと、を実行することを特徴とする情報配信システムのサービス実現方法。
8. コンピュータに、請求項７に記載の情報配信システムのサービス実現方法における各ステップを実行させるためのプログラム。

Images