(57)【要約】【課題】障害耐性の向上した処理の実行要求及びその結果応答を実施すること。【解決手段】第１のシステムが、第２のシステムに、処理の実行要求を送信するステップと、第１のシステムが、処理の実行受付を示す、処理の実行要求に対する応答を待ち受けるステップと、第１のシステムが、第２のシステムに、処理の結果要求を送信するステップとを含む方法。【選択図】図４Ａ
2019096112.tif 000002
【特許請求の範囲】
【請求項１】
第１のシステムが、第２のシステムに、処理の実行要求を送信するステップと、
前記第１のシステムが、前記処理の実行受付を示す、前記処理の実行要求に対する応答を待ち受けるステップと、
前記第１のシステムが、前記第２のシステムに、前記処理の結果要求を送信するステップと
を含む方法。
【請求項２】
請求項１に記載の方法であって、
前記第１のシステムが、前記処理の実行受付を示す、前記処理の実行要求に対する応答を受信した場合に、前記第２のシステムに前記処理の結果要求を繰り返し送信するように自身を設定するステップ
を更に含む方法。
【請求項３】
請求項１又は２に記載の方法であって、
前記第１のシステムが、識別情報を記憶するステップ
を更に含み、前記処理の実行要求及び前記処理の結果要求は、記憶した前記識別情報を含む、方法。
【請求項４】
システムが、処理の実行要求を受信した場合に、前記処理の実行の完了を待たずに、前記処理の実行受付を示す応答を返信するステップと、
前記システムが、前記処理の結果要求を受信した場合に、前記処理の結果を返信するために、前記処理の結果の取得を試行するステップと
を含む方法。
【請求項５】
請求項４に記載の方法であって、前記処理の実行要求及び前記処理の結果要求は、識別情報を含み、前記方法は、
前記システムが、実行要求を受信した前記処理の結果を、前記実行要求に含まれる前記識別情報に関連付けて記憶するステップ
を更に含み、前記処理の結果の取得を試行する前記ステップは、
結果要求を受信した前記処理の結果の取得を、前記結果要求に含まれる前記識別情報に基づき試行するステップ
を含む、方法。  
【請求項６】
１以上のコンピュータに、全体として、請求項１から５のうちの何れか一項に記載の方法を実行させるプログラム。
【請求項７】
請求項１から５のうちの何れか一項に記載の方法を実行するシステム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、クライアント・サーバ型システムに関する。より詳細には、障害耐性の向上した、処理の実行要求及びその結果応答を実施するクライアント・サーバ型システムに関する。
【背景技術】
【０００２】
飲食店（例えば、レストラン）等についてのクライアント・サーバ型予約システムが存在する。
【０００３】
図６は、従来技術に係る予約システムの全体的な処理の流れ６００を表す図である。６１０及び６２０はそれぞれクライアント及びサーバを示しており、図示しないネットワークを介して接続されている。クライアント６１０は、サーバ６２０に対して、予約に係る処理（例えば、ある飲食店等についての予約（登録）、予約変更及び予約キャンセル）の実行要求を送信する。サーバ６２０は、予約に係る処理を実際に実行し、受信した処理の実行要求に対して、当該処理の結果を示す応答を返信する。
【発明の概要】
【発明が解決しようとする課題】
【０００４】
上記のような予約システムによれば、ネットワークに起因する障害が発生し、予約に係る処理の実行要求又はその応答の伝達に失敗した場合に、次のような問題が生じることになる。
【０００５】
サーバ６２０において実際に実行される予約に係る処理は、その完了まで比較的時間がかかり、且つ、当該時間が変動する処理である。そのため、クライアント６１０は、処理の実行要求の送信後、基本的には応答を待ち続けることになる。しかしながら、応答が返ってこない場合、クライアント６１０は、半永久的に又は既定のタイムアウト時間（例えば、２０秒）だけ応答を待ち続けることになり、従って、クライアント６１０における要求から応答までに係る処理の滞留を招くことになる。このような滞留は、二次的に、クライアント６１０において障害を引き起こす可能性がある。
【０００６】
また、送信した処理の実行要求に対して応答が返ってこない場合、クライアント６１０の側では、予約に係る処理の実行が成功したのか失敗したのか（例えば、予約登録が成功したのか失敗したのか）を判断することができない。そのため、クライアント６１０は、次のアクション（予約したユーザへのお知らせ等）を取ることができない。
【０００７】
更に、予約に係る処理の実行要求又はその応答の伝達に失敗した場合、飲食店等とユーザとの間で、予約に係る処理に関し認識のずれが生じてしまうという問題がある。例えば、応答は返ってこないもののサーバ６２０において予約に係る処理が成功していた（例えば、予約登録が成功していた）場合には、予約をしたユーザはそのことを知ることができないために、飲食店等において、予約は入っているにも関わらず来客がないという状況となる。また、応答は返ってこないもののサーバ６２０において予約のキャンセルが成功していた場合には、キャンセルを希望したユーザは、応答が返ってこないためキャンセルできなかったと考えて飲食店等に来店するが、飲食店等側では、キャンセルができているという状況となる。
【０００８】
本発明は、以上に鑑みてなされたものであり、本発明の課題は、障害耐性の向上した処理の実行要求及びその結果応答を実施することである。
【課題を解決するための手段】
【０００９】
本発明の実施の第１態様は、第１のシステムが、第２のシステムに、処理の実行要求を送信するステップと、第１のシステムが、処理の実行受付を示す、処理の実行要求に対する応答を待ち受けるステップと、第１のシステムが、第２のシステムに、処理の結果要求を送信するステップとを含む方法である。
【００１０】
当該方法は、第１のシステムが、処理の実行受付を示す、処理の実行要求に対する応答を受信した場合に、第２のシステムに処理の結果要求を繰り返し送信するように自身を設定するステップを更に含んでいてよい。
【００１１】
当該方法は、第１のシステムが、識別情報を記憶するステップを更に含んでいてよい。このとき、処理の実行要求及び処理の結果要求は、記憶した前記識別情報を含むことが好ましい。
【００１２】
本発明の実施の第２態様は、システムが、処理の実行要求を受信した場合に、処理の実行の完了を待たずに、処理の実行受付を示す応答を返信するステップと、システムが、処理の結果要求を受信した場合に、処理の結果を返信するために、処理の結果の取得を試行するステップとを含む方法である。
【００１３】
前記処理の実行要求及び前記処理の結果要求は、識別情報を含むことが好ましい。このとき、当該方法は、システムが、実行要求を受信した処理の結果を、実行要求に含まれる識別情報に関連付けて記憶するステップを更に含むことができる。また、処理の結果の取得を試行するステップは、結果要求を受信した処理の結果の取得を、結果要求に含まれる識別情報に基づき試行するステップを含むことができる。
【００１４】
本発明の実施の第３態様は、１以上のコンピュータに、全体として、上記方法を実行させるプログラムである。
【００１５】
本発明の実施の第４態様は、上記方法を実行するシステムである。
【発明の効果】
【００１６】
本発明の実施形態によれば、ネットワークに起因する障害のほか、システムにおける障害に対する耐性をも向上させた、処理の実行要求及びその結果応答を実施することができる。
【図面の簡単な説明】
【００１７】
【図１】例示の予約システム１００の構成
【図２Ａ】クライアント１１０が実行する例示の処理２００のフローチャート
【図２Ｂ】クライアント１１０が実行する例示の処理２５０のフローチャート
【図３Ａ】サーバ１２０が実行する例示の処理３００のフローチャート
【図３Ｂ】サーバ１２０が実行する例示の処理３３０のフローチャート
【図３Ｃ】サーバ１２０が実行する例示の処理３６０のフローチャート
【図４Ａ】予約システム１００の全体的な例示の処理の流れ４００を表す図
【図４Ｂ】予約システム１００の全体的な例示の処理の流れ４２０を表す図
【図４Ｃ】予約システム１００の全体的な例示の処理の流れ４４０を表す図
【図４Ｄ】予約システム１００の全体的な例示の処理の流れ４６０を表す図
【図５】例示のコンピュータ５００の構成
【図６】従来技術に係る予約システムの全体的な処理の流れ６００を表す図
【発明を実施するための形態】
【００１８】
１  本発明の一実施形態
以下、図面を参照して、本発明の一実施形態について説明する。
【００１９】
１−１  一実施形態に係る予約システム
図１は、本発明の一実施形態に係る例示の予約システム１００の構成を表している。
【００２０】
１１０は、飲食店等の予約を行うユーザが利用するシステム（サブ・システム。予約に係る処理の流れの観点からはクライアントとして機能するため、以下、「クライアント」という。）を示している。クライアント１１０は、１以上のコンピュータから構成されたものであり、飲食店等の情報が記載され、ユーザから飲食店等についての予約の指示の入力を受け、当該予約の指示をクライアント１１０に送信するためのウェブ・ページを提供するウェブ・サーバとしての機能も有している。なお、「コンピュータ」については、「２  コンピュータ」の節も参照されたい。
【００２１】
１１５は、ユーザの手元にあり、クライアント１１０からウェブ・ページを取得して表示し、ユーザからの予約の指示の入力を受け、当該予約の指示をクライアント１１０に送信するコンピュータ（以下、「ユーザ端末」という。）を示している。図１ではユーザ端末１１５は１つのみ描かれているが、実際には複数のユーザが使用する複数のユーザ端末が存在する。
【００２２】
１２０は、飲食店等の予約を管理するシステム（サブ・システム。予約に係る処理の流れの観点からはサーバとして機能するため、以下、「サーバ」という。）を示している。サーバ１２０は、１以上のコンピュータから構成されたものであり、飲食店等の予約処理に係る要求を受けるためのウェブ・サーバとしての機能も有している。
【００２３】
１３０は、１以上のネットワーク（サブネットワーク）から構成されるネットワークを示している。ネットワーク１３０は、ローカル・エリア・ネットワーク（ＬＡＮ）及びインターネット等のワイド・エリア・ネットワーク（ＷＡＮ）の一方又は双方を含んでいてよい。少なくとも、クライアント１１０とサーバ１２０及びクライアント１１０とユーザ端末１１５は、ネットワーク１３０を介して通信可能である。
【００２４】
１−２  クライアント１１０の概要
以下、図２Ａ及びＢを参照して、クライアント１１０が実行する例示の一連の処理について説明する。なお、上述した通り、クライアント１１０は１以上のコンピュータから構成されたものであるため、一連の処理は、当該１以上のコンピュータが全体として実行するものである。なお、一連の処理が含む各ステップは、クライアント１１０を構成する１以上のコンピュータのうちの何れか１つが実行するものであるが、ステップごとに実行するコンピュータが異なっていてもよい。以下に説明するコンピュータが実行する処理（以下、「例示処理」という。）は、プログラムがコンピュータに、より詳細には、当該コンピュータのプロセッサに実行させるものであってよい。また、そのようなプログラムは、公知のコンピュータ可読記憶媒体、より詳細には、例えば非一時的コンピュータ可読記憶媒体に記憶することができる。更に、例示処理が含むステップは、一部を省略することができ、その実行順序を変更することができ、例示処理には、更なるステップを追加することができる。
【００２５】
図２Ａは、クライアント１１０がユーザ端末１１５から予約の指示を受信したときに呼び出される例示の処理２００のフローチャートである。予約の指示の例は、ある飲食店等についての予約（予約の登録）、予約の変更及び予約のキャンセルである。
【００２６】
２０２は、ユーザ端末１１５から受信した予約の指示に基づく処理の実行要求を識別するための情報（以下、「トランザクションＩＤ」という。）を、以後のステップのために記憶するステップを示している。この記憶は一時的なものであってもよいが、少なくとも、クライアント１１０における予約システム１００に係るプログラムが異常終了し、再起動した後であっても取得できるような態様で記憶されることが好ましい。なお、トランザクションＩＤは、クライアント１１０が任意の手法により生成することができる。
【００２７】
２０４は、サーバ１２０に、記憶されたトランザクションＩＤを用いて当該処理の実行要求を送信するステップを示している。具体的には、サーバ１２０は、処理の種類ごとに、処理の実行要求を受けるためのＵＲＬをウェブＡＰＩとして有することができ、従って、サーバ１２０は、予約登録用ＡＰＩ、予約変更用ＡＰＩ及び予約キャンセル用ＡＰＩ等を有することができる。また、ある処理の実行要求は、当該処理に対応したＵＲＬに、トランザクションＩＤを含む当該処理に必要な情報（予約すべき飲食店等予約内容を特定する情報や、既にした予約を特定する情報等）をパラメータとして付加したものを宛先としたＨＴＴＰリクエストであることができる。
【００２８】
２０６は、処理の実行要求に対する応答を受信したかを判定するステップを示している。具体的には、処理の実行要求に対する応答は、ＨＴＴＰリクエストに対するＨＴＴＰレスポンスであることができる。処理の実行要求に対する応答を受信している場合には後述のステップ２１４に進み、そうでない場合にはステップ２０８に進む。
【００２９】
２０８は、処理の実行要求を最後に送信してから第１の時間経過したかを判定するステップを示している。第１の時間は任意であるが、例えば２秒である。処理の実行要求を最後に送信してから第１の時間経過している場合には後述するステップ２１０に進み、そうでない場合にはステップ２０６に戻る。
【００３０】
ステップ２１０は、第１の条件を満たすかを判定するステップを示している。第１の条件は任意であるが、本実施例では、同じトランザクションＩＤを用いた処理の実行要求の送信リトライを既に３回しているという条件である。第１の条件を満たしている場合には後述するステップ２１２に進み、そうでない場合にはステップ２０４に戻る。ステップ２１０の結果として、処理の実行要求の所定回数の送信リトライが実現できることになる。
【００３１】
２１２は、所定の処理を行うステップを示している。ステップ２１２に達したことは、処理の実行要求の送信リトライを所定回数繰り返したにもかかわらず、その応答が返ってこなかったことを意味する。従って、この所定の処理は、対応するエラー処理であってよいが、エラー処理に限定されるわけではない。なお、エラー処理としては、具体的には、エラーログを記憶する、予約システム１００の保守担当者が保持する携帯電話に発報する、ユーザ端末１１５にエラーが生じたことを通知する等が考えられるが、これらに限定されるわけではない。
【００３２】
２１４は、処理の実行要求に対する応答が処理の実行受付を示すかを判定するステップを示している。応答は、処理の実行受付失敗を示すことがある。処理の実行要求に対する応答が処理の実行受付を示している場合には後述するステップ２１６に進み、そうでない場合にはステップ２２０に進む。
【００３３】
なお、ステップ２０６、２０８及び２１４は、全体として、処理の実行受付を示す、処理の実行要求に対する応答を待ち受けるステップを構成するステップの例である。
【００３４】
２１６は、ユーザ端末１１５に処理の実行が開始されることを通知するステップを示している。このステップの結果、ユーザ端末１１５には処理が実行中である旨の表示をすることができる。
【００３５】
２１８は、所定時間間隔でサーバ１２０に処理の結果要求を送信するようにクライアント１１０を設定するステップを示している。所定時間は任意であるが、例えば３秒である。このステップの結果、所定時間間隔で、後述する処理２５０が呼び出されるようになる。
【００３６】
なお、ステップ２１８は、サーバ１２０に処理の結果要求を繰り返し送信するようにクライアント１１０を設定するステップの一例である。送信と送信との間の時間は、変動してもよい。
【００３７】
２２０は、所定の処理を行うステップを示している。ステップ２２０に達したことは、処理の実行受付に失敗したことを意味する。従って、ステップ２２０における所定の処理は、対応するエラー処理であってよいが、エラー処理に限定されるわけではない。また、ステップ２２０における所定の処理は、ステップ２１２における所定の処理と同様の処理であってよいが、異なる処理であってもよい。
【００３８】
図２Ｂは、ステップ２１８の結果として所定時間間隔で呼び出される例示の処理２５０のフローチャートである。なお、処理２５０は、クライアント１１０において、予約システム１００に係るプログラムが異常終了した後、再起動したとき等の他のタイミングで呼び出されることもある。
【００３９】
２５２は、サーバ１２０に、ステップ２０２において記憶されたトランザクションＩＤを用いて処理の結果要求を送信するステップを示している。具体的には、サーバ１２０は、処理の結果要求を受けるためのＵＲＬをウェブＡＰＩとして有することができ、従って、サーバ１２０は、予約結果確認用ＡＰＩを有することができる。また、処理の結果要求は、対応したＵＲＬに、トランザクションＩＤを含む必要な情報をパラメータとして付加したものを宛先としたＨＴＴＰリクエストであることができる。
【００４０】
２５４は、処理の結果要求に対する応答を受信したかを判定するステップを示している。具体的には、処理の結果要求に対する応答は、ＨＴＴＰリクエストに対するＨＴＴＰレスポンスであることができる。処理の結果要求に対する応答を受信している場合には後述のステップ２６２に進み、そうでない場合にはステップ２５６に進む。
【００４１】
２５６は、処理の結果要求を最後に送信してから第２の時間経過したかを判定するステップを示している。第２の時間は任意であるが、例えば２秒である。処理の結果要求を最後に送信してから第２の時間経過している場合には後述するステップ２５８に進み、そうでない場合にはステップ２５４に戻る。
【００４２】
ステップ２５８は、第２の条件を満たすかを判定するステップを示している。第２の条件は任意であるが、本実施例では、対応するトランザクションＩＤが生成されてから既に１分が経過しているという条件である。第２の条件を満たしている場合には後述するステップ２６０に進み、そうでない場合には処理２５０は終了する。
【００４３】
なお、ステップ２５８並びに後述するステップ２６６及び２７０の結果として、一定時間が経過するまでの処理の結果要求の所定時間間隔での送信リトライが実現できることになる。
【００４４】
２６０は、所定の処理を行うステップを示している。ステップ２６０に達したことは、処理の結果要求の送信リトライを一定時間繰り返したにもかかわらず、その応答が返ってこなかったことを意味する。従って、ステップ２６０における所定の処理は、対応するエラー処理であってよいが、エラー処理に限定されるわけではない。また、ステップ２６０における所定の処理は、ステップ２１２における所定の処理と同様の処理であってよいが、異なる処理であってもよい。
【００４５】
２６２は、処理の結果要求に対する応答が処理の結果を示すかを判定するステップを示している。応答は、処理の結果ではなく、処理が実行中であることを示すことがある。処理の結果要求に対する応答が処理の結果を示している場合には後述するステップ２６４に進み、そうでない場合にはステップ２６６に進む。
【００４６】
２６４は、処理結果に応じた処理を行うステップを示している。処理結果に応じた処理の例は、ユーザ端末１１５に処理結果を通知することであるが、これに限定されるわけではない。
【００４７】
２６６は、第３の条件を満たすかを判定するステップを示している。第３の条件は任意であるが、本実施例では第２の条件と同一である。第３の条件を満たしている場合には後述するステップ２６８に進み、そうでない場合には処理２５０は終了する。
【００４８】
２６８は、所定の処理を行うステップを示している。ステップ２６８に達したことは、処理の結果要求の送信リトライを一定時間繰り返したにもかかわらず、処理結果を示す応答が返ってこなかった即ち処理の実行が失敗している可能性があることを意味する。従って、ステップ２６８における所定の処理は、対応するエラー処理であってよいが、エラー処理に限定されるわけではない。また、ステップ２６８における所定の処理は、ステップ２１２における所定の処理と同様の処理であってよいが、異なる処理であってもよい。
【００４９】
２７０は、ステップ２１８においてなされた所定間隔での処理の結果要求の送信設定を解除するステップを示している。このステップの結果、処理２５０は、以後、所定間隔では呼び出されないようになる。
【００５０】
１−３  サーバ１２０の概要
以下、図３Ａ〜Ｃを参照して、サーバ１２０が実行する例示の一連の処理について説明する。なお、上述した通り、サーバ１２０は１以上のコンピュータから構成されたものであるため、一連の処理は、当該１以上のコンピュータが全体として実行するものである。なお、一連の処理が含む各ステップは、サーバ１２０を構成する１以上のコンピュータのうちの何れか１つが実行するものであるが、ステップごとに実行するコンピュータが異なる場合があることに留意されたい。
【００５１】
図３Ａは、サーバ１２０が実行する例示の処理３００のフローチャートである。
【００５２】
３０２は、処理の実行要求を受信したかを判定するステップを示している。処理の実行要求を受信している場合には後述するステップ３０４に、そうでない場合にはステップ３０２を繰り返す。
【００５３】
３０４は、受信した処理の実行要求に含まれるトランザクションＩＤの一時的な記憶を試行するステップを示している。具体的には、トランザクションＩＤを、揮発性の情報を一時的に記憶しておくストレージ（キャッシュ）に記憶することができる。また、このステップにおいて、処理の実行要求の受信日時等、その他の情報を記憶してもよい。
【００５４】
３０６は、ステップ３０４における試行が成功したかを判定するステップを示している。何らかのエラーが生じた場合には、試行が成功していないと判定されることになる。試行が成功した場合には後述するステップ３０８に進み、そうでない場合にはステップ３１０に進む。
【００５５】
３０８及び３１０は、それぞれ、受信した処理の実行要求に対する応答として、処理の実行受付を示す応答を生成するステップ及び処理の実行受付失敗を示す応答を生成するステップを示している。
【００５６】
３１２は、処理の実行を実際に開始するステップを示している。なお、本実施例においては、サーバ１２０における処理の実行要求を受信するインスタンスと、当該処理を実際に実行するインスタンスとは異なっており、ステップ３１２は、前者のインスタンスから後者のインスタンスへ当該処理の実行要求を送信するステップ（図示せず）を含む。ここで、１つのインスタンスの例は、１つの物理的なコンピュータ、物理的なコンピュータ又は仮想マシンにおいて実行されている１つの仮想マシン、及び、物理的なコンピュータ又は仮想マシンにおいて実行されている１つのプロセスである。なお、前者のインスタンスと後者のインスタンスとは同一であってもよい。
【００５７】
３１４は、受信した処理の実行要求に対する応答を返信するステップを示している。なお、ステップ３１４は、ステップ３１２とは非同期に実行されてよい。即ち、ステップ３１４は、実行が開始された処理の完了を待つことなく実行することができる。
【００５８】
図３Ｂは、ステップ３１２の実行の結果呼び出される例示の処理３３０のフローチャートである。
【００５９】
３３２は、所定時間経過後に、ステップ３０４において一時的に記憶されたトランザクションＩＤが自動的に削除されるようにサーバ１２０を設定するステップを示している。この所定時間は任意であるが、例えば１２０秒である。
【００６０】
３３４は、処理を実際に実行するステップを示している。
【００６１】
３３６は、処理の結果を、対応するトランザクションＩＤに関連付けて記憶するステップを示している。なお、ステップ３３４において何らかのエラーが生じて処理が完了しなかった即ち処理の結果が得られなかった場合、ステップ３３６は実行されず、従って、処理の結果は記憶されないことに留意されたい。
【００６２】
３３８は、ステップ３０４において一時的に記憶されたトランザクションＩＤを削除するステップを示している。このステップは、ステップ３３２において設定されたトランザクションＩＤの自動削除とは独立したものである。即ち、本実施例では、一時的に記憶されたトランザクションＩＤは、所定時間が経過するか又は処理が完了した場合に削除されることになる。
【００６３】
図３Ｃは、サーバ１２０が実行する例示の処理３６０のフローチャートである。
【００６４】
３６２は、処理の結果要求を受信したかを判定するステップを示している。処理の結果要求を受信している場合には後述するステップ３６４に、そうでない場合にはステップ３６２を繰り返す。
【００６５】
３６４は、受信した処理の結果要求が含むトランザクションＩＤに基づき、記憶された処理の結果の取得を試行するステップを示している。
【００６６】
３６６は、ステップ３６４における試行が成功したかを判定するステップを示している。実行要求を受信した処理の実行が完了していない場合には、この試行に失敗することになる。なお、本実施例において、処理の実行が完了した場合にはトランザクションＩＤの一時的な記憶が削除されることから、ステップ３６６は、トランザクションＩＤが一時的に記憶されているかを判定するステップ（図示せず）を含む。試行が成功した場合には後述するステップ３６８に進み、そうでない場合にはステップ３７０に進む。
【００６７】
３６８及び３７０は、それぞれ、受信した処理の結果要求に対する応答として、処理の結果を示す応答を生成するステップ及び処理が実行中であることを示す応答を生成するステップを示している。
【００６８】
３７２は、処理の結果を取得したことを、トランザクションＩＤに関連付けて記憶するステップを示している。このステップの結果、サーバ１２０は、トランザクションＩＤに基づき、処理の結果を取得したことが記憶されているかを判定することによって、記憶されていれば、処理の結果がクライアント１１０に送信され、ひいてはユーザ端末１１５に通知されているであろうことを、記憶されていなければ未だユーザ端末１１５には通知されていないであろうことを認識することができるようになる。
【００６９】
３７４は、受信した処理の結果要求に対する応答を返信するステップを示している。
【００７０】
１−４  予約システム１００の全体的な処理の流れ
以下、図４Ａ〜Ｄを参照して、様々な状況下における、予約システム１００の全体的な例示の処理の流れについて説明する。なお、これら図において、ユーザ端末１１５及びネットワーク１３０は省略されている。
【００７１】
図４Ａは、特段の障害が発生することなく一連の処理が行われた場合の、予約システム１００の全体的な例示の処理の流れ４００を表す図である。
【００７２】
４０１は、ユーザ端末１１５からクライアント１１０に予約の指示が送信されたことを示している。
【００７３】
４０２は、クライアント１１０からサーバ１２０に、予約に係る処理の実行要求が送信されたことを示している。
【００７４】
４０３は、サーバ１２０において処理の実行を実際に開始するために、処理の実行要求を受信するインスタンスから処理の実行を実際に行うインスタンスに処理の実行要求が送信されたことを示している。
【００７５】
４０４は、サーバ１２０が処理の実行受付を示す応答を返信したことを示している。
【００７６】
４０５は、クライアント１１０がユーザ端末に、処理の実行開始を通知したことを示している。
【００７７】
４０６は、サーバ１２０において実行要求を受けた処理が完了したことを示している。      
【００７８】
４０７は、クライアント１１０からサーバ１２０に、処理の結果要求が送信されたことを示している。この図において、４０７の発生は４０６の発生よりも後であるから、処理３６０において、サーバ１２０は処理結果を取得可能である。
【００７９】
４０８は、サーバ１２０が処理結果を示す応答を返信したことを示している。
【００８０】
４０９は、クライアント１１０が、処理結果に応じた処理として、ユーザ端末１１５に処理結果を通知したことを示している。
【００８１】
このように、予約システム１００によれば、ユーザ端末１１５からの予約の指示に従い、当該指示に基づく予約に係る処理を行い、その処理結果をユーザ端末１１５に通知することが可能である。また、予約システム１００によれば、クライアント１１０は、処理の実行要求に対しては、単に処理の実行受付を示す応答を待ち受けるため、その待ち受けのタイムアウト時間を小さいものとすることができ、よって、仮に応答が返ってこなかった場合であっても予約に係る処理の実行要求からその応答までに係る処理の滞留は短いものとなる。
【００８２】
図４Ｂは、ネットワーク１３０に起因する障害が発生した場合の、予約システム１００の全体的な例示の処理の流れ４２０を表す図である。
【００８３】
４２１は、４０１と同様のことを示している。
【００８４】
４２２は、クライアント１１０が、処理の実行要求を送信したものの、サーバ１２０に届かなかったことを示している。
【００８５】
４２３は、クライアント１１０からサーバ１２０に、処理の実行要求が再度送信されたことを示している。
【００８６】
４２４〜４２７は、それぞれ、４０３〜４０６と同様のことを示している。
【００８７】
４２８は、クライアント１１０が処理の結果要求を送信したものの、サーバ１２０に届かなかったことを示している。
【００８８】
４２９は、クライアント１１０からサーバ１２０に、処理の結果要求が再度送信されたことを示している。
【００８９】
４３０及び４３１は、それぞれ、４０８及び４０９と同様のことを示している。
【００９０】
このように、予約システム１００によれば、ネットワーク１３０を介した通信が不安定な場合であっても、予約に係る一連の処理が途中で途切れる可能性が低くなる。特に、予約システム１００によれば、処理の結果要求を複数回送信することができることから、サーバ１２０において実行要求を受信した処理が完了したときに、その事実をクライアント１１０が取得できず、ひいてはユーザ端末１１５のユーザに予約の成否を通知できないといった可能性が低くなる。このことは、例えば、飲食店等において予約が入っているにもかかわらず来客がないといった事故の発生する確率が下がることを意味する。
【００９１】
図４Ｃは、クライアント１１０において障害が発生した場合の、予約システム１００の全体的な例示の処理の流れ４４０を表す図である。
【００９２】
４４１〜４４６は、４０１〜４０６と同様のことを示している。
【００９３】
４４７は、クライアント１１０において、予約システム１００に係るプログラムの異常終了が生じたことを示している。
【００９４】
４４８は、当該プログラムが再起動した後に、記憶されている識別情報を用いて、クライアント１１０からサーバ１２０に処理の結果要求が送信されたことを示している。
【００９５】
４４９及び４５０は、それぞれ、４０８及び４０９と同様のことを示している。
【００９６】
このように、予約システム１００によれば、クライアント１１０において一時的な障害が発生したとしても、障害発生前に記憶した識別情報を用いて障害発生前に実行要求を送信した処理の結果要求を送信することができ、ひいてはユーザ端末１１５のユーザに予約の成否を通知できないといった可能性が低くなる。
【００９７】
図４Ｄは、サーバ１２０において実行要求を受信した処理の実行に時間がかかった場合の、予約システム１００の全体的な例示の処理の流れ４６０を表す図である。
【００９８】
４６１〜４６７は、それぞれ、４０１〜４０７と同様のことを示している。但し、この図において、４６７の発生は４６６の発生よりも前であるから、４６７が示す処理の結果要求を受信したときには、サーバ１２０は処理結果を取得できない。
【００９９】
４６８は、サーバ１２０が処理結果を取得できなかったことにより、処理が実行中であることを示す応答を返信したことを示している。
【０１００】
４６９は、クライアント１１０からサーバ１２０に、処理の結果要求が再度送信されたことを示している。この図において、４６９の発生は４６６の発生よりも後であるから、４６９が示す処理の結果要求を受信したときに、サーバ１２０は処理結果を取得可能である。
【０１０１】
４７０は、再度送信された処理の結果要求に対して、サーバ１２０が処理結果を示す応答を返信したことを示している。
【０１０２】
４７１は、４０９と同様のことを示している。
【０１０３】
このように、予約システム１００によれば、サーバ１２０において実行要求を受信した処理の実行に時間がかかったとしても、当該実行要求に対する応答はその実行の完了を待つことなくなされることから、クライアント１１０における、予約に係る処理の実行要求から応答までに係る処理の時間はより短いものとなる。
【０１０４】
２  コンピュータ
図５は、コンピュータのハードウェア構成の一例を表している。同図に示すように、コンピュータ５００は、主に、プロセッサ５１０と、主記憶装置５２０と、補助記憶装置５３０と、ユーザ・インターフェース５４０と、通信インターフェース５５０とを備えており、これらはアドレスバス、データバス、コントロールバス等を含むバスライン５６０を介して相互に接続されている。なお、バスライン５６０と各ハードウェア資源との間には適宜インターフェース回路（図示せず）が介在している場合もある。
【０１０５】
プロセッサ５１０は、コンピュータの全体の制御を行う。プロセッサ５１０は、各々がコンピュータの一部又は全体の制御を行なう、複数のプロセッサにより構成されていてもよい。
【０１０６】
主記憶装置５２０は、プロセッサ５１０に対して作業領域を提供し、例えばＳＲＡＭ、ＤＲＡＭ等の揮発性メモリである。
【０１０７】
補助記憶装置５３０は、ソフトウェアであるプログラム（コンピュータ実行可能命令を含む）等や各種データ等を格納する、例えば、ハードディスクドライブ、フラッシュメモリ等の不揮発性メモリである。プログラムは、任意の時点で補助記憶装置５３０からバスライン５６０を介して主記憶装置５２０へとロードされ、プロセッサ５１０に各種処理、方法又はステップを実行させる。
【０１０８】
なお、主記憶装置５２０及び補助記憶装置５３０を、両者を区別することなく集合的に「メモリ」として参照する場合があることに留意されたい。
【０１０９】
ユーザ・インターフェース５４０は、ユーザに情報を提示すること及びユーザから情報の入力を受けることの一方又は双方を行う、ハードウェア資源としてのユーザ・インターフェースであり、例えば、キーボード、マウス、トラックパッド、トラックポインタ、ディスプレイ、タッチパネル・ディスプレイ、マイク、スピーカ、加速度センサ等である。
【０１１０】
通信インターフェース５５０は、ネットワーク１３０と接続されるものであり、ネットワーク１３０を介してデータを送受する。通信インターフェース５５０とネットワーク１３０とは、有線又は無線で接続されうる。通信インターフェース５５０は、ネットワークに係る情報、例えば、Ｗｉｆｉのアクセスポイントに係る情報、通信キャリアの基地局に関する情報等も取得することがある。
【０１１１】
３  むすび
以上、本発明の実施形態を説明したが、他の類似する形態の採用や、適宜形態の変更又は追加を行うことができることに留意されたい。
【図１】
2019096112.tif 000003
【図２Ａ】
2019096112.tif 000004
【図２Ｂ】
2019096112.tif 000005
【図３Ａ】
2019096112.tif 000006
【図３Ｂ】
2019096112.tif 000007
【図３Ｃ】
2019096112.tif 000008
【図４Ａ】
2019096112.tif 000009
【図４Ｂ】
2019096112.tif 000010
【図４Ｃ】
2019096112.tif 000011
【図４Ｄ】
2019096112.tif 000012
【図５】
2019096112.tif 000013
【図６】
2019096112.tif 000014