(57)【要約】【課題】ＨＴＴＰ規格を使用する通信環境下において、サーバーから端末に対する即時通知を実現可能とする。【解決手段】本発明に係る通知システムは、音声もしくは表示の少なくとも１つによる通知を行うことを可能とする通知手段と、サーバーとＨＴＴＰ規格による通信を可能とする端末側通信手段と、サーバーから通知情報を受信した場合、受信した通知情報に基づく通知を通知手段に実行させるとともに、サーバーに対し接続要求を送信する通知処理を実行可能とする端末側制御手段と、を備えた複数の端末と、端末から接続要求を受信した場合、当該端末に対する通知を待機状態とする待機処理と、通知要求が発生した場合、通知の待機状態となっている端末であって、当該通知要求に対応する端末に対し、通知内容を含んだ通知情報を送信する送信処理とを実行可能なサーバーとを備えたことを特徴とする。【選択図】図３
2019036079.tif 000002
【特許請求の範囲】
【請求項１】
複数の端末と、端末と通信接続可能なサーバーを備える通知システムであって、
端末は、
サーバーとＨＴＴＰ規格による通信を可能とする端末側通信手段と、
サーバーから通知情報を受信した場合、受信した通知情報に基づく通知を通知手段に行わせ、サーバーに対し接続要求を送信する通知処理を実行可能とする端末側制御手段と、を備え、
サーバーは、
端末とＨＴＴＰ規格による通信を可能とするサーバー側通信手段と、
各種処理を実行するサーバー側制御手段と、を備え、
サーバー側制御手段は、待機処理と、送信処理と、を実行可能とし、
待機処理は、端末から接続要求を受信した場合、当該端末に対する通知を待機状態とし、
送信処理は、通知要求が発生した場合、通知の待機状態となっている端末であって、当該通知要求に対応する端末に対し、通知内容を含んだ通知情報を送信する
通知システム。
【請求項２】
送信処理は、通知要求に対応する端末に対し、通知情報を送信できない場合、所定時間経過したことを条件として通知情報を削除する
請求項１に記載の通知システム。
【請求項３】
端末は、宿泊施設の客室に設置され、
通知処理は、端末が所定モードになっているときに実行される
請求項１または請求項２に記載の通知システム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、サーバーと通信接続された複数の端末を備え、サーバーから端末に対して音声、映像等を使用した通知を行う通知システムに関する。
【背景技術】
【０００２】
現在、ホテル等の宿泊施設では、宿泊施設全般を管理するサーバーと、各客室内に設置された端末とをＬＡＮによる通信手段で接続し、サーバー間と端末間で通信を行うシステムが設けられていることが一般的である。このようなシステムによって、各客室内に設置された端末に対してビデオオンデマンド、飲食物の発注等、宿泊客に対する各種サービスを行うことが可能となっている。また、宿泊施設管理面においても、宿泊客が退室した後の清掃、リネンの交換等を行うため、端末に対して各客室の状況を通知することで、従業者に対して迅速に情報を提供することも開始されている。
【０００３】
特許文献１には、上述するような宿泊施設を管理するための客室情報通信システムが開示されている。この客室情報通信システムは、客室情報を管理する管理装置をフロント及び各階に設置されたリネン室に設け、リネン室の管理装置から移動可能な端末装置に対して客室情報を無線で送信することが開示されている。
【先行技術文献】
【特許文献】
【０００４】
【特許文献１】特開平１１−２７５６６６号公報
【発明の概要】
【発明が解決しようとする課題】
【０００５】
特許文献１に開示されるように各階に設置された管理装置から移動可能な端末に対して客室情報を管理するシステムでは、管理装置と通信を行う端末の数も限られたものであって、管理装置から端末に通知を行う際に特段の支障はみられない。先に述べたように、客室内に設置された端末を使用して客室の状況を通知する場合、新たに導入するシステムであれば問題は無いものの、例えば、既存のシステム、特に、ＨＴＴＰプロトコルを使用した通信環境を使用するシステムにおいては、多数の客室に対して即時通知を行うことができない問題（詳細は後述する。）が発生することがある。本発明は、このようなＨＴＴＰプロトコル（ＨＴＴＰ規格）を使用するシステムにおいて、複数の端末に対して支障無く迅速な通知を行うことを目的とするものである。
【課題を解決するための手段】
【０００６】
そのため、本発明に係る通知システムは、
複数の端末と、端末と通信接続可能なサーバーを備える通知システムであって、
端末は、
音声もしくは表示の少なくとも１つによる通知を行うことを可能とする通知手段と、
サーバーとＨＴＴＰ規格による通信を可能とする端末側通信手段と、
サーバーから通知情報を受信した場合、受信した通知情報に基づく通知を通知手段に実行させるとともに、サーバーに対し接続要求を送信する通知処理を実行可能とする端末側制御手段と、を備え、
サーバーは、
端末とＨＴＴＰ規格による通信を可能とするサーバー側通信手段と、
各種処理を実行するサーバー側制御手段と、を備え、
サーバー側制御手段は、待機処理と、送信処理と、を実行可能とし、
待機処理は、端末から接続要求を受信した場合、当該端末に対する通知を待機状態とし、
送信処理は、通知要求が発生した場合、通知の待機状態となっている端末であって、当該通知要求に対応する端末に対し、通知内容を含んだ通知情報を送信する。
【０００７】
さらに本発明に係る通知システムにおいて、
送信処理は、通知要求に対応する端末に対し、通知情報を送信できない場合、所定時間経過したことを条件として通知情報を削除する。
【０００８】
さらに本発明に係る通知システムにおいて、
端末は、宿泊施設の客室に設置され、
通知処理は、端末が所定モードになっているときに実行される。
【発明の効果】
【０００９】
本発明に係る通知システムによれば、ＨＴＴＰ規格を使用して通信を行うサーバーと複数の端末において、同時接続数制限の支障を発生させることなく迅速な通知を行うことが可能となる。また、複数の端末に対して通知を行う際においても、サーバーにおけるリソース消費の削減を図ることが可能となる。
【００１０】
さらに本発明に係る通知システムによれば、通知情報を送信できない場合、所定時間経過したことを条件として通知情報を削除することで、通知の意味を持たなくなった古い情報が不用意に通知されることを抑制することが可能となる。このような形態は、清掃、リネン交換等、最新の客室状況を通知する必要がある宿泊施設で使用するシステムにおいて有効である。
【００１１】
さらに本発明に係る通知システムによれば、端末が所定モードになっているとき、例えば、宿泊施設の客室において客の退出時において実行されることが好ましい。このように客が退出している客室の端末で実行されることで、通知の対象となる端末数の削減を図り、同時接続数制限による支障の発生を抑制することが可能となる。
【図面の簡単な説明】
【００１２】
【図１】サーバーとクライアント間におけるポーリングを説明するための図
【図２】ポーリングによるサーバーの負荷増大を説明するための図
【図３】本発明の実施形態に係る通知システムを示すブロック図
【図４】本発明の実施形態に係るクライアント側処理を示すフロー図
【図５】本発明の実施形態に係るサーバー側処理を示すフロー図
【図６】本発明の実施形態に係る通知システムにおける処理例を示す模式図
【図７】本発明の実施形態に係る通知システムにおける処理例を示す模式図
【図８】本発明の実施形態に係る通知システムにおける処理例を示す模式図
【発明を実施するための形態】
【００１３】
図１、図２は、従来のサーバーとクライアント（端末）間におけるポーリング、及び、ポーリングによるサーバーの負荷増大を説明するための図である。サーバーとクライアント間の通信には、一般的なＨＴＴＰプロトコル（ＨＴＴＰ規格）を使用している。ＨＴＴＰプロトコルにはサーバーからＰＵＳＨしてクライアントに状態変化を通知する手段はない。そのため、ＨＴＴＰプロトコルでは、クライアントがサーバーにリクエストを送り、サーバーが応答を返した後、コネクションを切断するという一組の通信が基本となる。したがって、サーバーからのデータのＰＵＳＨを実現するために、一番簡単な方法は、図１に示すように、クライアントからにサーバーに対して「通知はありませんか？」と、定期的にリクエストするポーリング方式が使用される。
【００１４】
ポーリング方式を使用した場合、サーバーに状態変化が無くてもクライアントは定期的にリクエストする必要があるため、通信の大半が無駄となってしまう。また、ネットワークのトラフィックやサーバーに負荷を掛けないようにするためには、ポーリング周期を多めに取る必要がある。しかしながら、ポーリング周期を多めに取ることは、クライアントが必要な通知を得るまでに時間が長くなる、すなわち、遅延が生じることになる。例えば、ポーリング周期を１０分とした場合、サーバーで発生した状況変化をクライアントが受け取るには、最大１０分の遅延が発生することになる。
【００１５】
Ａｐａｃｈｅ等のような汎用のサーバーを使用した場合、通信上のパフォーマンスに大きく関わる代表的な設定値（デフォルト値）として、同時接続数：２５６本、タイムアウトまでの時間：３００秒が使用される。これら設定値は変更することも可能であるが、デフォルト値で使用されることが一般的である。
【００１６】
Ｗｅｂコンテンツの閲覧的な使用状況が多い中では、ＨＴＴＰプロトコルのメリット（リクエストから応答の短い一組のコネクション）が生かされ、同時接続数が２５６本の上限値があっても多くのクライアントが共有し、上限値以上のコネクションがあるかのような効果を生じることが可能である。しかしながら、多くのクライアントが短い間隔のポーリングを行うと、ポーリング以外のリクエストもあるため、あっという間に枯渇し、遅延、タイムアウトによるリトライ、エラーが多発し始めてしまう。
【００１７】
図２は、ポーリングによるサーバーの負荷増大を説明するための図である。この例では、クライアントのポーリング間隔を５秒、サーバーのタイムアウトまでの時間を３００秒に設定している。クライアントは、サーバーの応答の有無に関わらず、５秒間隔でポーリングを行うこととしている。１回目のポーリング（ポーリング１）の開始時刻を０秒とすると、５秒後には２回目のポーリング（ポーリング２）が発生し、サーバーでは２本のコネクションが存在することになる。そして、１０秒後には３本のコネクションが存在することになる。１回目のコネクションは３００秒後までサーバーに保持され（応答待機）、２回目のコネクションは３０５秒後までサーバーに保持される（応答待機）ことになる。
【００１８】
宿泊施設のように各客室内にクライアント（端末）が設置されたシステムでは、多数のクライアントが存在することになり、例えば、８０台のクライアントが同時に接続するシステムでは、開始から１０秒後の時点で３×８０＝２４０本のコネクションが存在することになり、同時接続数制限（２５６本）まで、あと１６本しか残っていないという危機的な状況となってしまう。ポーリング分の通信だけをみてもこのような状況であるが、実際の運用では、クライアントで表示する画像データ、テキストデータ、音声データといった各種データの転送も同時に発生するため、もっと少ないクライアント数で通信の壊滅的な状況が発生する可能性がある。このような壊滅的な状況が発生した場合は、できるだけ早くクライアントに通知したいために５秒間隔のポーリングにしたはずが、実際には直ぐに通知したい情報が数十分後にようやく通知される現象が発生してしまう。
【００１９】
ここで上述するような現象を避けるには、ＨＴＴＰプロトコルを使用しなければよいのではないか、という考え方があるが、使用する宿泊施設では、ＨＴＴＰプロトコルしか与えられていない既存のシステムを使用しなければならないという制約がある場合がある。例えば、数年前に宿泊施設に納品したセットトップボックス（クライアント）を使用しなければならない場合等がこれに相当する。
【００２０】
また、上述するようなコネクションの数の制約のみならず、リソース消費の観点においても問題が生じることになる。サーバーはクライアントからのリクエストでサーブレットやｃｇｉも起動させるため、あらゆるリソースが消費され負荷がかかった状態となる。また、クライアント側も正常なポーリングのためのコネクションは常時１本で済むはずであるが、上述するようなサーバーへの負荷が生じた場合、最悪、クライアント端末が許容する数まで膨れあがっている可能性も有り、クライアント側のリソースへの圧迫にも繋がることになる。
【００２１】
以上の説明は、クライアント側が応答を待たずに定期間隔でポーリング実行している極端な例であるが、応答を待つアプリケーションにして考えてみたとしても、クライアント数が多くなり、サーバーやネットワークに負荷がかかっているときには、タイムアウトの影響が発生するため、一度タイムアウトが起こると３０５秒の遅延が起こり、不安定な通信状態が発生することが予想される。
【００２２】
ここでタイムアウトまでの時間である３００秒をもっと短くすれば問題は解決するのではないかという考えもあるが、実際の運用では、ポーリングの他にその他の表示、またはその他の端末がＷｅｂブラウザを利用するため、不用意にタイムアウトまでの時間を短くしてしまうと、Ｗｅｂブラウザが表示されない等、別の障害が発生することになる。したがってタイムアウトまでの時間を簡単に短くすることは困難である。また、宿泊施設の状況に応じて設定をカスタマイズすることは現実的ではない。
【００２３】
本発明はこのような状況を鑑みたものであって、端末とサーバー間においてＨＴＴＰプロトコルを使用する通知システムにおいて、サーバーから端末に対してＨＴＭＬ規格による通知情報を送信する際、コネクション数の制約の解消、並びに、システムにおける負荷抑制を実現することを目的としている。
【００２４】
図３は、本発明の実施形態に係る通知システムを示すブロック図である。この通知システムはホテル、旅館等の宿泊施設に設置されたものであって、各客室に設置される客室端末装置３ａ〜３ｃ（本発明の「端末」に相当、実際の宿泊施設では数十台以上となることが想定される。）、サーバー装置１（本発明の「サーバー」に相当）、ステータス管理サーバー装置２を有して構成されている。サーバー装置１、客室端末装置３ａ〜３ｃ、ステータス管理サーバー装置２はネットワークを介して通信接続されている。なお、本実施形態では、サーバー装置１とステータス管理サーバー装置２を異なる装置で構成しているが、１つの装置に両装置の機能を持たせて構成することとしてもよい。
【００２５】
客室端末装置３ａ〜３ｃは、一般的なコンピュータ装置であって、ＣＰＵ、ＲＡＭ、ＲＯＭ等、プログラムに基づいて各種制御を行う制御手段（端末側制御手段）、ネットワークを介してサーバー装置１と通信を行う通信手段（端末側通信手段）を備え、Ｗｅｂブラウザ３１の機能を備えて構成されている。Ｗｅｂブラウザ３１は、サーバー装置１から送信される各種情報を、接続されている表示部４１（通知手段）に表示出力、あるいは、音声出力部４２（通知手段）に音声出力することが可能となっている。この客室端末装置３ａ〜３ｃは、宿泊客の滞在時には宿泊客に対して宿泊施設に関する各種情報、あるいは、映画、音楽などの娯楽情報を提供することが可能となる。また、宿泊客の退出時には、客室の清掃、リネンの交換等、各種メンテナンスする従業員等に対して各種情報を提供することを可能としている。例えば、宿泊施設の各客室の退出状況を、表示部４１あるいは音声出力部４２で通知することで、次にどの客室をメンテナンスすればよいかを、作業を行う現場（客室）で知ることが可能となる。
【００２６】
Ｗｅｂブラウザ３１は、このような宿泊施設の各客室の退出状況等を通知するため、サーバー装置１から、リネン状況表示Ｗｅｂアプリ３２を取得して起動することが可能となっている。また、リネン状況表示Ｗｅｂアプリ３２には、サーバー装置１との通信を管理する機能を有するＣｏｍｅｔクライアント３２ａが搭載されている。Ｃｏｍｅｔクライアント３２ａは、サーバー装置１側のＣｏｍｅｔサーバー１３と通信を行うことで、客室端末装置３ａ〜３ｃに対して通知を行うことが可能となっている。客室端末装置３ａ〜３ｃは、起動の後、サーバー装置１からリネン状況表示Ｗｅｂアプリ３２を受信し、客室状況の通知に備えることになる。
【００２７】
一方、管理側のサーバー装置１は、一般的なコンピュータ装置であって、ＣＰＵ、ＲＡＭ、ＲＯＭ等、プログラムに基づいて各種制御を行う制御手段（サーバー側制御手段）、ネットワークを介して客室端末装置３ａ〜３ｃと通信を行う通信手段（サーバー側通信手段）を備え、を有し、Ｗｅｂサーバー１１、記憶部１２、Ｃｏｍｅｔサーバー１３の機能を有して構成されている。Ｗｅｂサーバー１１は、記憶部１２に記憶された情報に基づき、客室端末装置３ａ〜３ｃのＷｅｂブラウザに対して各種アプリ、情報を提供することが可能である。客室端末装置３ａ〜３ｃにおいて説明したように、客室状況の通知のためのＷｅｂアプリ１１ａとして、リネン状況表示Ｗｅｂアプリ３２を、客室端末装置３ａに提供することが可能である。この他、Ｗｅｂサーバーは、映画配信を行うためのＷｅｂアプリを客室端末装置３ａ〜３ｃに提供することが可能である。
【００２８】
Ｃｏｍｅｔサーバー１３は、客室端末装置３ａ〜３ｃのＣｏｍｅｔクライアント３２ａと通信するための機能である。本実施形態のＣｏｍｅｔサーバーは、ＨＴＴＰ規格を使用するとともに、通知を行うために待機状態となるサーバーであるため、ＨＴＴＰ待機サーバーと呼称されることもある。このＣｏｍｅｔサーバー１３は、客室端末装置３ａ〜３ｃに対して通知するための通知リクエストを一時記憶するためのデータキュー１３ｂを備えて構成される。本実施形態の通知リクエストは、ステータス管理サーバー装置２から送信されたものが記憶されることになる。通知リクエストには、通知対象となる客室端末装置３ａ〜３ｃを示す宛先、通知内容となる音声案内データ、ステータスデータを含んだ通知情報、通知発生タイミング（時刻）等が含んで構成される。なお、通知リクエストの宛先には、客室端末装置３ａ〜３ｃを個別に通知対象として指定する、あるいは、客室端末装置３ａ〜３ｃ全体を通知対象として指定する、あるいは、適宜客室端末装置３ａ〜３ｃの一部グループを対象として指定することが可能である。
【００２９】
また、Ｃｏｍｅｔサーバー１３は、セッションが確立している客室端末装置３ａ〜３ｃを管理するためのセッション管理テーブル１３ａを含んで構成されている。このセッション管理テーブル１３ａには、セッションが確立した客室端末装置３ａ〜３ｃを示すセッション情報として、客室端末装置３ａ〜３ｃのネットワーク上でのＩＰアドレス、あるいは、客室端末装置３ａ〜３ｃのＭＡＣアドレス等が使用される。
【００３０】
ステータス管理サーバー装置２は、宿泊施設の従業員等によって管理、操作されるサーバー装置であって、客室の入退室状況（ステータス）を管理するためのサーバー装置である。例えば、フロントで宿泊客がチェックアウトした場合、フロントの従業員は、ステータス管理サーバー装置２に対して、宿泊客のチェックアウトを入力する。ステータス管理サーバー装置２は、チェックアウトの入力に基づき、サーバー装置１のＣｏｍｅｔサーバー１３に対して音声案内データ、あるいは、ステータスデータ等を含んだ通知リクエストを送信する。客室の入退室状況（ステータス）の管理は、このような従業員による操作のみならず、客室料金の支払い、客室のカードキーの発行、回収等を行う自動精算機からの情報に基づくものであってもよい。
【００３１】
図４は、本発明の実施形態に係るクライアント側処理、すなわち、客室端末装置３ａ〜３ｃのリネン状況表示Ｗｅｂアプリ３２で実行される処理を示したフロー図である。客室端末装置３ａ〜３ｃでは、このクライアント側処理が開始されると、客室端末装置３ａ〜３ｃは、サーバー装置１のＣｏｍｅｔサーバー１３に対して接続要求を送信する（Ｓ１０１）。Ｃｏｍｅｔサーバー１３とのセッションが確立した場合（Ｓ１０２：Ｙｅｓ）、サーバー装置１から送信される通知情報の待機を開始する（Ｓ１０３）。一方、サーバー装置１とのセッションが確立できない場合（Ｓ１０２：Ｎｏ）は、所定の設定時間待機（Ｓ１０９）した後、サーバー装置１に対して接続要求を実行する（Ｓ１０１）。所定の設定時間は、宿泊施設のネットワーク環境、使用状況等によって適切な値が設定されることになるが、通常、１０秒〜３０秒で設定されることになる。この接続要求の待機は、想定外のエラー発生時に客室端末装置３ａ〜３ｃ、あるいは、サーバー装置１でのビジーループ及びリソースリークが発生しないよう保護するため措置である。
【００３２】
サーバー装置１とのセッション確立後、サーバー装置１から通知情報を受信した場合（Ｓ１０４：Ｙｅｓ）、受信した通知情報に基づく通知を行うための通知処理を実行する。本実施形態の通知情報は、ＪＳＯＮ（ＪａｖａＳｃｒｉｐｔ（登録商標）  Ｏｂｊｅｃｔ  Ｎｏｔａｔｉｏｎ）形式、または、ＪＳＯＮＰ（ＪＳＯＮ  ｗｉｎｔ  ｐａｄｄｉｎｇ）形式のデータの一部にＷｅｂアプリに実装されている既ロード済み関数を呼び出す形式の文字列を含める形式としており、この文字列をメソッドにスクリプト変換（Ｓ１０７）して実行（Ｓ１０８）することで、Ｗｅｂアプリケーションへの実装を容易にしている。なお、この通知処理で実行されるスクリプト中にはサーバー装置１とのセッション切断も規定されており、通知処理を実行することでサーバー装置１とのセッションは切断される。本実施形態では、サーバー装置１と客室端末装置３ａ〜３ｄとの間のセッションを客室端末装置３ａ〜３ｄ側から切断することとしているが、サーバー装置１が通知情報を送信したこと等を条件として、サーバー装置１側からセッションを切断することとしてもよい。
【００３３】
リネン状況表示Ｗｅｂアプリ３２で実行される通知処理の例として、受信した通知情報がステータスデータの場合、受信したステータスに応じた客室状況が表示部４１に表示される。また、受信した通知情報が音声案内データの場合、受信した音声案直データを再生することで、音声出力部４２から音声が放音される。
【００３４】
通知処理の実行後、クライアント側処理では、サーバー装置１とのセッションを一旦終了（Ｓ１０６）し、即時、サーバー装置１に対して接続要求を送信（Ｓ１０１）し、サーバー装置１から通知を受けるためのセッション確立を試みる。このように通知処理の実行後は、即時、サーバー装置１に対して接続要求を行う（Ｓ１０１）点において、セッションが確立できない場合（Ｓ１０２：Ｎｏ）、設定時間待機（Ｓ１０９）した後に接続要求を行う点において異なっている。これは、通知処理後のセッション確立は、次の通知のために迅速に準備しなければならないという必要のためである。
【００３５】
一方、受信待機開始（Ｓ１０３）の後、通知情報を受信することなく（Ｓ１０４：Ｎｏ）、サーバー装置１によるセッションの切断が発生した場合（Ｓ１０５：Ｙｅｓ）、サーバー装置１とのセッションを終了し、即時、サーバー装置１に対して接続要求を送信する（Ｓ１０１）。サーバー装置１のセッション期間中、セッション障害が発生した場合、客室端末装置３ａ〜３ｃに対して適切に通知できない場合がある。本実施形態では、所定時間（本実施形態では５分）、セッションが継続した場合、サーバー装置１側からセッションを一旦切断し、再度、セッション開始することで、セッション継続が長時間となることなく（いわば、セッションの鮮度を保ち）、適切に通知を行うことを可能としている。
【００３６】
このクライアント側処理は、常時、行うのでは無く、客室端末装置３ａ〜３ｃが所定モードとなっている際に行うことが好ましい。例えば、客室から客が退出した際、サーバー装置１からの遠隔操作によって顧客端末装置３ａ〜３ｃが所定モードに設定される。このように、通知の対象となる客室端末装置３ａ〜３ｃの数を削減し、同時接続数制限による支障の発生を抑制することが可能となる。客室端末装置３ａ〜３ｃのモード設定は、ステータス管理サーバー装置２において、従業員によるチェックイン、チェックアウトの入力設定によって設定されることが好ましい。チェックアウトから次のチェックインまでの客の不在時にクライアント側処理を実行する所定モードとすることで、客室で業務に従事する従業者に適切な通知を行うことが可能となる。客室端末装置３ａ〜３ｃにおけるモード設定は、この他、サーバー装置１あるいは客室端末装置３ａ〜３ｃにおいて設定可能としてもよい。
【００３７】
図５は、本発明の実施形態に係るサーバー側処理、すなわち、サーバー装置１のＣｏｍｅｔサーバー１３で実行される処理を示したフロー図である。まず、本実施形態の前提として、ステータス管理サーバー装置２は、従業員の操作等で客室の入退室状況（ステータス）が変化した場合、サーバー装置１に対して通知リクエストを送信する。Ｃｏｍｅｔサーバー１３は、受信した通知リクエストをデータキュー１３ｂに保存する。この通知リクエストには、通知対象となる客室端末装置３ａ〜３ｃを示す宛先、通知内容となる音声案内データ、ステータスデータを含んだ通知情報、通知発生タイミング（時刻）等が含まれている。
【００３８】
サーバー側処理では、客室端末装置３ａ〜３ｃから接続要求を受信し、当該客室端末装置３ａ〜３ｃに対する通知リクエストがデータキュー１３ｂに記憶されていない場合（Ｓ２０１：Ｙｅｓ）、接続要求を行ってきた客室端末装置３ａ〜３ｃに関するセッション情報をセッション管理テーブル１３ａに追加することで、当該客室端末装置３ａ〜３ｃをセッション待機中の状態とする。なお、セッション情報には、客室端末装置３ａ〜３ｃのネットワーク上でのＩＰアドレス、あるいは、客室端末装置３ａ〜３ｃのＭＡＣアドレス等、ネットワーク上で客室端末装置３ａ〜３ｃを識別可能な各種情報を使用することが可能である。
【００３９】
セッション管理テーブルにセッション情報がある場合、すなわち、セッション待機中の場合（Ｓ２０２：Ｙｅｓ）、セッション開始から所定時間経過しているか否かが判定される（Ｓ２０３）。これは、図４のクライアント側処理で説明したように、セッション継続が長時間となり、適切な通知ができないことを抑制するための処理である。所定時間経過（本実施形態では５分）経過していると判断された場合（Ｓ２０３：Ｙｅｓ）には、待機中のセッションを切断（Ｓ２０４）して、セッション管理テーブル１３ａから削除する（Ｓ２０５）。なお、セッションが切断された場合、客室端末装置３ａ〜３ｃから再度、接続要求が行われることになり、セッションは即時再開されることになる。
【００４０】
一方、接続要求時（Ｓ２０１：Ｙｅｓ）、接続要求を行った客室端末装置３ａ〜３ｃを宛先として有する通知リクエストが、データキュー１３ｂに記憶されている場合（Ｓ２０６：Ｙｅｓ）、宛先となる客室端末装置３ａ〜３ｃに通知リクエスト内の通知情報を送信し（Ｓ２０７）、当該客室端末装置３ａ〜３ｃに通知処理を実行させる。そして、通知情報の送信を完了したセッション情報をセッション管理テーブル１３ａから削除し、送信完了した通知情報に対応する通知リクエストをデータキュー１３ｂから削除する（Ｓ２０８）。
【００４１】
なお、本実施形態では、宿泊施設での業務を鑑み、データキュー１３ｂに保存された通知リクエストを保存開始から所定時間経過した場合、削除することとしている。システム中の何らかの障害により、通知情報が客室端末装置３ａ〜３ｃに届けられない場合、データキュー１３ｂには通知リクエストが蓄積され続ける。障害が復旧するとデータキュー１３ｂに蓄積されていた通知リクエスト内の通知情報は、宛先となる客室端末装置３ａ〜３ｃに届けられることになるが、復旧までの期間が長い場合、古い通知情報が通知されることになり、業務を行う上での情報として意味を持たないことになる。通知情報がステータスデータ、すなわち、各客室の状態を示す情報の場合、順次更新されていくため問題性は低い。しかしながら、通知情報が音声案内データの場合、その内容は「１０１号室の客室がチェックアウトしました。」、「２０１号室の清掃が完了しました。」、「３０１号室にオーダーが発生しました。」といったように、通知のリアルタイム性が重要となる内容であって、このような音声案内データが遅れて再生されることになると、現状とは異なる状態が通知されることになるため、宿泊施設における業務上の問題性は高いものとなってしまう。したがって、本実施形態では、データキュー１３ｂ内の通知リクエストを保存開始してから所定時間（例えば、３０秒〜５分）経過後、データキュー１３ｂから削除することとしている。なお、所定時間経過の判定は、通知リクエスト内の通知発生タイミング（時刻）に基づいて判定する、あるいは、通知リクエストを受信してからタイマーを動作させることで判定すること等、各種形態を採用することが考えられる。
【００４２】
図６〜図８は、本発明の実施形態に係る通知システムにおける処理例を示す模式図であって、図３で説明したシステム構成において、図４、図５で説明した処理を実行したときの客室端末装置３ａ（クライアント）とサーバー装置１（サーバー）間における状態が示されている。何れの図も横軸を時間軸とするタイムチャート形式となっている。
【００４３】
図６は、客室端末装置３ａとサーバー装置１の間のセッション開始前に通知リクエストが発生した場合の模式図である。ステータス管理サーバー装置２から通知リクエストを受信した場合、サーバー装置１はデータキュー１３ｂに受信した通知リクエストを記憶して応答待機状態となる。なお、この場合、受信した通知リクエストの宛先は、客室端末装置３ａとする。その後、客室端末装置３ａから接続要求を受信すると、データキュー１３ｂに記憶している通知リクエスト内の通知情報を客室端末装置３ａに送信し、送信が完了するとデータキュー１３ｂ内の通知リクエストを削除する。一方、客室端末装置３ａは、受信した通知情報に基づいて通知処理を開始し、即時にサーバー装置１に対して接続要求を送信する。この場合、データキュー１３ｂには客室端末装置３ａ宛ての通知リクエストは存在しないため、セッション管理テーブル１３ａに客室端末装置３ａを示すセッション情報を記憶して待機状態とする。
【００４４】
図７は、客室端末装置３ａとサーバー装置１の間のセッション開始後に通知リクエストが発生した場合の模式図である。サーバー装置１は、客室端末装置３ａから接続要求を受信すると、データキュー１３ｂに客室端末装置３ａを宛先とする通知リクエストが記憶されていないため、セッション管理テーブル１３ａに客室端末装置３ａを示すセッション情報を記憶して待機状態とする。その後、ステータス管理サーバー装置２から客室端末装置３ａを宛先とする通知リクエストを受信すると、通知リクエスト内の通知情報を客室端末装置３ａに送信し、セッション管理テーブル１３ａからセッション情報を削除する。客室端末装置３ａは、受信した通知情報に基づいて通知処理を開始し、即時にサーバー装置１に対して接続要求を送信する。サーバー装置１は、客室端末装置３ａからの接続要求に基づき、セッション管理テーブル１３ａに客室端末装置３ａを示すセッション情報を記憶して再度待機状態となる。
【００４５】
図６、図７で説明したように、本実施形態の通知システムでは、ＨＴＴＰプロトコルを使用しなければならないシステム環境下においても、セッション管理テーブル１３ａで扱うセッション情報は１つで済むことになる。したがって、図２で説明したような従来のシステムにおける１のクライアントで複数のタイムアウトが並行して実行されることが無く、宿泊施設のように多数の客室端末装置３ａ〜３ｃが接続されているネットワーク環境下において、同時接続数（コネクションの数）制限の制約緩和を図るとともに、サーバー装置１等におけるリソース消費の観点においても有利なものとすることが可能となっている。
【００４６】
図８は、客室端末装置３ａとサーバー装置１の間でセッション不通時の模式図である。ステータス管理サーバー装置２から通知リクエストを受信した場合、サーバー装置１はデータキュー１３ｂに受信した通知リクエストを記憶して応答待機状態となる。サーバー装置１と客室端末装置３ａ間はセッション不通の状態であるため、データキュー１３ｂ内の通知リクエストは送信されないまま応答待機の状態が続くことになる。本実施形態では、通知発生タイミングから所定時間経過した通知リクエストをデータキュー１３ｂから削除することで、古い通知情報が客室端末装置３ａに送信されないようにしている。この場合、所定時間経過した通知リクエストは、データキュー１３ｂから削除されるため、その後、客室端末装置３ａとの間でセッションが復旧されたとしても、客室端末装置３ａに当該通知リクエストに関する通知情報は送信されることがなく、時間経過に伴って意味の無くなった通知が行われることが抑制されることになる。なお、所定時間経過後の通知リクエストの削除は、セッション不通時のみならず、宛先となる客室端末装置３ａ〜３ｃに通知情報が送信できない各種障害発生時においても同様に実行されることになる。
【００４７】
以上、本実施形態の通知システムについて宿泊施設に適用した場合を例に取って説明したが、ＨＴＴＰ規格を使用した環境下においても、同時接続数（コネクションの数）制限の制約緩和を図った即時通知を行うことが可能となっている。また、サーバー装置１等におけるリソース消費の観点においても有利なものとすることを可能としている。なお、複数のクライアントに対して通知を行う通知システムであれば、宿泊施設に限ったものでは無く、飲食施設向け調理配膳状態の通知、美術館及び博物館等公共施設向け館内情報の通知、工場向け各種状態通知、病院向け各種案内あるいは呼出のための通知等、各種用途に使用することが可能である。
【符号の説明】
【００４８】
１：サーバー装置
２：ステータス管理サーバー装置
３ａ〜３ｃ：客室端末装置
１１：Ｗｅｂサーバー
１１ａ：Ｗｅｂアプリ
１２：記憶部
１３：Ｃｏｍｅｔサーバー
１３ａ：セッション管理テーブル
１３ｂ：データキュー
３１：Ｗｅｂブラウザ
３２：リネン状況表示Ｗｅｂアプリ
３２ａ：Ｃｏｍｅｔクライアント
４１：表示部
４２：音声出力部
【図１】
2019036079.tif 000003
【図２】
2019036079.tif 000004
【図３】
2019036079.tif 000005
【図４】
2019036079.tif 000006
【図５】
2019036079.tif 000007
【図６】
2019036079.tif 000008
【図７】
2019036079.tif 000009
【図８】
2019036079.tif 000010