"申込対象を識別可能な送信先情報を宛先とし、一方向の通信により送信された送信データを受信する受信手段と、前記受信手段により受信された送信データの送信先情報により識別される申込対象の申込みを受け付けることができない場合に、代替案を識別可能な送信先情報を含む返信データを作成する返信データ作成手段と、前記返信データ作成手段により作成された返信データを前記送信データの送信元を宛先として送信する送信手段と、を備えることを特徴とする情報処理装置。前記受信手段が、さらに、前記代替案を識別可能な送信先情報を宛先とする再送信データを受信し、前記受信手段により受信された再送信データの送信先情報により識別される代替案に係る申込対象の申込みを受け付ける申込受付手段をさらに含む、ことを特徴とする請求項1に記載の情報処理装置。前記作成された返信データに含まれる送信先情報により識別される代替案に係る申込対象の仮申込みを登録する仮申込登録手段と、前記仮申込みを登録してから所定期間が経過した後、当該仮申込みを取り消す仮申込取消手段と、をさらに備え、前記申込受付手段は、前記受信手段により受信された再送信データの送信先情報により識別される代替案に係る申込対象が仮申込登録されている場合に、当該仮申込みを正規の申込みとして確定させる、ことを特徴とする請求項2に記載の情報処理装置。前記返信データ作成手段は、代替案を識別可能な送信先情報を複数含む返信データを作成し、前記仮申込登録手段は、前記作成された返信データに含まれる送信先情報により識別される各代替案に係る申込対象の仮申込みを登録し、前記仮申込取消手段は、前記申込受付手段により前記仮申込み登録がなされている申込対象が正規の申込みとして確定された場合に、当該申込対象と同時期に仮申込みの登録がなされた他の申込対象に係る仮申込みを取り消すことを特徴とする請求項3に記載の情報処理装置。前記代替案は申込条件を含み、前記返信データ作成手段が、前記代替案を識別可能な送信先情報を生成し、当該生成された送信先情報を含む返信データを作成する、ことを特徴とする請求項2乃至4の何れか一項に記載の情報処理装置。前記返信データ作成手段により生成された送信先情報を宛先とする再送信データの受信を可能とし、所定期間経過後に、当該生成された送信先情報を宛先とする再送信データの受信を不可能とする送信先情報管理手段をさらに備える、ことを特徴とする請求項5に記載の情報処理装置。前記受信手段が、申込条件をさらに含む前記送信データを受信し、前記受信手段により受信された送信データの送信先情報により識別される申込対象の申込みを当該送信データに含まれる申込条件のもとで受け付けることができない場合に、当該申込対象と当該申込条件とのうち少なくともいずれかを変更した受付け可能な代替案を検索する検索手段をさらに備え、前記返信データ作成手段が、前記検索手段により検索された代替案を識別可能な送信先情報を含む返信データを作成することを特徴とする請求項1乃至6の何れか一項に記載の情報処理装置。前記受信手段が、前記申込対象とともに申し込まれるべき他の申込対象を識別可能な識別情報を含む前記送信データを受信し、前記検索手段が、前記受信手段により受信された送信データの送信先情報により識別される申込対象と、当該送信データに含まれる識別情報により識別される他の申込対象とを、当該送信データに含まれる申込条件のもとで受け付けることができない場合に、当該他の申込対象を変更せずに、当該申込対象及び当該他の申込対象の申込みが同一の申込条件のもとで受付け可能な代替案を検索する、ことを特徴とする請求項7に記載の情報処理装置。前記申込対象は、特定の資源であり、前記他の申込対象は、前記資源を利用するユーザであって複数おり、前記申込条件は、前記資源の利用開始日時及び利用終了日時を含む利用期間の条件であり、前記検索手段は、前記他の申込対象が前記同一の申込条件のもとで受付け可能か否かを判定する場合に、一定時間早めた前記利用開始日時と一定時間遅らせた前記利用終了日時との少なくともいずれかを申込条件とすることを特徴とする請求項8に記載の情報処理装置。前記代替案は申込条件を含み、前記返信データ作成手段が、前記申込対象を識別可能な送信先情報と、前記申込条件を含む返信データを作成し、前記返信データ作成手段により作成された返信データには、当該返信メールに含まれる送信先情報が指定された場合に当該送信先情報を宛先とする再送信データであって、当該返信メールに含まれる申込条件のうち申込者により指定された申込条件を含む再送信データの作成を補助する補助データが更に含まれていることを特徴とする請求項2乃至4の何れか一項に記載の情報処理装置。コンピュータにより実行される情報処理方法であって、申込対象を識別可能な送信先情報を宛先とし、一方向の通信により送信された送信データを受信する受信工程と、前記受信工程により受信された送信データの送信先情報により識別される申込対象の申込みを受け付けることができない場合に、代替案を識別可能な送信先情報を含む返信データを作成する返信データ作成工程と、前記返信データ作成工程により作成された返信データを前記送信データの送信元を宛先として送信する送信工程と、を含むことを特徴とする情報処理方法。コンピュータを、申込対象を識別可能な送信先情報を宛先とし、一方向の通信により送信された送信データを受信する受信手段、前記受信手段により受信された送信データの送信先情報により識別される申込対象の申込みを受け付けることができない場合に、代替案を識別可能な送信先情報を含む返信データを作成する返信データ作成手段、前記返信データ作成手段により作成された返信データを前記送信データの送信元を宛先として送信する送信手段、として機能させる情報処理プログラムがコンピュータ読み取り可能に記録された記録媒体。コンピュータを、申込対象を識別可能な送信先情報を宛先とし、一方向の通信により送信された送信データを受信する受信手段、前記受信手段により受信された送信データの送信先情報により識別される申込対象の申込みを受け付けることができない場合に、代替案を識別可能な送信先情報を含む返信データを作成する返信データ作成手段、前記返信データ作成手段により作成された返信データを前記送信データの送信元を宛先として送信する送信手段、として機能させることを特徴とする情報処理プログラム。しかしながら、電子メールで注文を受け付ける場合には、ショッピングサイトを介して注文を受け付ける場合と異なり、注文者が在庫の有無等を確認できないまま注文を行う場合が多く、注文を受け付けることができない事態が生じる可能性が低くない。特許文献1には、この場合の対処の仕方について記載されていない。このことは、商品を注文する場面に限らず、サービスを予約する場面や資源施設,人などを確保する場面など、何らかの申込みを行う場面全般においてもあてはまる。本発明は以上の点に鑑みてなされたものであり、当初の申込みを受け付けることができない事態が生じた場合であっても、当該申込みの代わりとなる代替案を申込者に提示し、申込者が容易に当該代替案の申込みを行うことができる情報処理装置等を提供することを目的とする。上記課題を解決するために、請求項1に記載の発明は、申込対象を識別可能な送信先情報を宛先とし、一方向の通信により送信された送信データを受信する受信手段と、前記受信手段により受信された送信データの送信先情報により識別される申込対象の申込みを受け付けることができない場合に、代替案を識別可能な送信先情報を含む返信データを作成する返信データ作成手段と、前記返信データ作成手段により作成された返信データを前記送信データの送信元を宛先として送信する送信手段と、を備えることを特徴とする情報処理装置である。この発明によれば、申込対象の申込みを受け付けることができない場合であっても、代替案に係る申込対象を識別可能な送信先情報を含む返信データが送信元宛に送信されることから、申込者は返信データに含まれる送信先情報を宛先として再送信データを送信するだけで代わりの申込対象の申込みを容易に行うことができる。請求項1の発明において行われる送信データの送信には、httpHyperTextTransferProtocolやhttpsHypertextTransferProtocoloverSecureSocketLayer等による双方向の通信ではなく、一方向片方向、単方向の通信が利用される。具体的には、電子メールによるデータの通信、SMSShortMessageServiceによるデータの通信等がある。また、請求項1の発明における申込みには、商品の注文、サービス理容、診察治療等の医療サービス、飲食物の提供、宿泊施設の提供、各種施設運動施設、娯楽施設の提供、各種の出張サービス等の予約、資源会議室、OA機器、人的資源等の確保などが含まれるものとする。請求項2に記載の発明は、前記受信手段が、さらに、前記代替案を識別可能な送信先情報を宛先とする再送信データを受信し、前記受信手段により受信された再送信データの送信先情報により識別される代替案に係る申込対象の申込みを受け付ける申込受付手段をさらに含む、ことを特徴とする請求項1に記載の情報処理装置である。この発明によれば、申込者が指定した代替案に係る申込対象の申込みを受け付けることができる。請求項3に記載の発明は、前記作成された返信データに含まれる送信先情報により識別される代替案に係る申込対象の仮申込みを登録する仮申込登録手段と、前記仮申込みを登録してから所定期間が経過した後、当該仮申込みを取り消す仮申込取消手段と、をさらに備え、前記申込受付手段は、前記受信手段により受信された再送信データの送信先情報により識別される代替案に係る申込対象が仮申込登録されている場合に、当該仮申込みを正規の申込みとして確定させる、ことを特徴とする請求項2に記載の情報処理装置である。この発明によれば、仮申込みを登録してから所定期間が経過した後に当該仮申込みが取り消されるので、代替案にかかる申込対象をいつまでも仮申込み状態のまま確保しておく必要がなくなり、他の申込者による申込みの機会が徒に奪われてしまうことを回避することができる。請求項4に記載の発明は、前記返信データ作成手段が、代替案を識別可能な送信先情報を複数含む返信データを作成し、前記仮申込登録手段は、前記作成された返信データに含まれる送信先情報により識別される各代替案に係る申込対象の仮申込みを登録し、前記仮申込取消手段は、前記申込受付手段により前記仮申込み登録がなされている申込対象が正規の申込みとして確定された場合に、当該申込対象と同時期に仮申込みの登録がなされた他の申込対象に係る仮申込みを取り消すことを特徴とする請求項3に記載の情報処理装置である。この発明によれば、申込者に対して提示された代替案のうち申込者に指定されなかった代替案に係る仮申込みは、申込者に指定された代替案に係る申込みが正規の申込みとして確定された場合に取り消されるので、いつまでも仮申込み状態のまま確保しておく必要がなくなり、他の申込者による申込みの機会が徒に奪われてしまうことを回避することができる。請求項5に記載の発明は、前記代替案は申込条件を含み、前記返信データ作成手段が、前記代替案を識別可能な送信先情報を生成し、当該生成された送信先情報を含む返信データを作成する、ことを特徴とする請求項2乃至4の何れか一項に記載の情報処理装置である。この発明によれば、申込者に対して申込条件を含む代替案を提案することができるとともに、申込者は返信データに含まれる送信先情報を宛先として再送信データを送信するだけで代替案による申込みを容易に行うことができる。請求項6に記載の発明は、前記返信データ作成手段により生成された送信先情報を宛先とする再送信データの受信を可能とし、所定期間経過後に、当該生成された送信先情報を宛先とする再送信データの受信を不可能とする送信先情報管理手段をさらに備える、ことを特徴とする請求項5に記載の情報処理装置である。この発明によれば、返信メールに含まれる送信先情報を宛先とする再送信データをいつまでも受信可能な状態とするように送信先情報を管理しなくて済む。請求項7に記載の発明は、前記受信手段が、申込条件をさらに含む前記送信データを受信し、前記受信手段により受信された送信データの送信先情報により識別される申込対象の申込みを当該送信データに含まれる申込条件のもとで受け付けることができない場合に、当該申込対象と当該申込条件とのうち少なくともいずれかを変更した受付け可能な代替案を検索する検索手段をさらに備え、前記返信データ作成手段が、前記検索手段により検索された代替案を識別可能な送信先情報を含む返信データを作成することを特徴とする請求項1乃至6の何れか一項に記載の情報処理装置である。この発明によれば、送信データに含まれる申込対象及び申込条件による申込みを受け付けることができない場合であっても、申込対象と申込条件とのうち少なくともいずれかを変更した受付け可能な代替案を申込者に提示することができ、申込者は返信データに含まれる送信先情報を宛先として再送信データを送信するだけで代替案による申込みを容易かつ確実に行うことができる。請求項8に記載の発明は、前記受信手段が、前記申込対象とともに申し込まれるべき他の申込対象を識別可能な識別情報を含む前記送信データを受信し、前記検索手段が、前記受信手段により受信された送信データの送信先情報により識別される申込対象と、当該送信データに含まれる識別情報により識別される他の申込対象とを、当該送信データに含まれる申込条件のもとで受け付けることができない場合に、当該他の申込対象を変更せずに、当該申込対象及び当該他の申込対象の申込みが同一の申込条件のもとで受付け可能な代替案を検索する、ことを特徴とする請求項7に記載の情報処理装置である。この発明によれば、申込対象と他の申込対象とを送信データに含まれる申込条件のもとで受け付けることができない場合に、他の申込対象を変更せずに、申込対象及び当該他の申込対象の申込みが同一の申込条件のもとで受付け可能な代替案を申込者に対して提示することができ、申込者は返信データに含まれる送信先情報を宛先として再送信データを送信するだけで代替案による申込みを容易に行うことができる。請求項9に記載の発明は、前記申込対象は、特定の資源であり、前記他の申込対象は、前記資源を利用するユーザであって複数おり、前記申込条件は、前記資源の利用開始日時及び利用終了日時を含む利用期間の条件であり、前記検索手段は、前記他の申込対象が前記同一の申込条件のもとで受付け可能か否かを判定する場合に、一定時間早めた前記利用開始日時と一定時間遅らせた前記利用終了日時との少なくともいずれかを申込条件とすることを特徴とする請求項8に記載の情報処理装置である。この発明によれば、他の申込対象資源を利用するユーザについて資源を利用する時間帯の前又は後の少なくとも何れかに別の予定が入っている場合であっても、当該別の予定と資源を利用する時間帯の間に一定時間の余裕を確保することができ、資源を利用するユーザの利便性が向上する。請求項10に記載の発明は、前記代替案は申込条件を含み、前記返信データ作成手段が、前記申込対象を識別可能な送信先情報と、前記申込条件を含む返信データを作成し、前記返信データ作成手段により作成された返信データには、当該返信メールに含まれる送信先情報が指定された場合に当該送信先情報を宛先とする再送信データであって、当該返信メールに含まれる申込条件のうち申込者により指定された申込条件を含む再送信データの作成を補助する補助データが更に含まれていることを特徴とする請求項2乃至4の何れか一項に記載の情報処理装置である。この発明によれば、返信メールに含まれる補助データにより、申込者が返信データに含まれる送信先情報を指定した場合に、当該送信先情報の示す送信先を宛先とする再送信データであって、更に申込者により指定された申込条件を含む再送信データが作成される。これにより、情報処理装置は、再送信データの送信先である送信先情報から代替案に係る申込対象を識別し、再送信データに含まれる申込条件から代替案に係る申込条件を識別することができる。また、申込者は返信データに含まれる送信先情報を選択するだけで再送信データが作成されるので、代替案による申込を容易に行うことができる。請求項11に記載の発明は、コンピュータにより実行される情報処理方法であって、申込対象を識別可能な送信先情報を宛先とし、一方向の通信により送信された送信データを受信する受信工程と、前記受信工程により受信された送信データの送信先情報により識別される申込対象の申込みを受け付けることができない場合に、代替案を識別可能な送信先情報を含む返信データを作成する返信データ作成工程と、前記返信データ作成工程により作成された返信データを前記送信データの送信元を宛先として送信する送信工程と、を含むことを特徴とする。請求項12に記載の発明は、コンピュータを、申込対象を識別可能な送信先情報を宛先とし、一方向の通信により送信された送信データを受信する受信手段、前記受信手段により受信された送信データの送信先情報により識別される申込対象の申込みを受け付けることができない場合に、代替案を識別可能な送信先情報を含む返信データを作成する返信データ作成手段、前記返信データ作成手段により作成された返信データを前記送信データの送信元を宛先として送信する送信手段、として機能させる情報処理プログラムがコンピュータ読み取り可能に記録された記録媒体である。請求項13に記載の発明は、コンピュータを、申込対象を識別可能な送信先情報を宛先とし、一方向の通信により送信された送信データを受信する受信手段、前記受信手段により受信された送信データの送信先情報により識別される申込対象の申込みを受け付けることができない場合に、代替案を識別可能な送信先情報を含む返信データを作成する返信データ作成手段、前記返信データ作成手段により作成された返信データを前記送信データの送信元を宛先として送信する送信手段、として機能させることを特徴とする情報処理プログラムである。本発明によれば、申込対象の申込みを受け付けることができない場合であっても、当該申込対象の代わりとなる代替案を識別可能な送信先情報を含む返信データが送信元宛に送信されることから、申込者は返信データに含まれる送信先情報の示す宛先に再送信データを送信するだけで容易に申込みを行うことができる。以下、図面を参照して本発明の実施形態について説明する。なお、以下に説明する実施の形態は、会議室予約システムに対して本発明を適用した場合の実施形態である。[1.会議室予約システムの構成及び機能概要]先ず、本発明の一実施形態に係る会議室予約システムSの構成及び概要機能について、図1を用いて説明する。図1は、本実施形態に係る会議室予約システムSの概要構成の一例を示す図である。図1に示すように、会議室予約システムSは、複数のユーザ端末UTnn=1,2,3kと、情報処理サーバ情報処理装置の一例1と、を含んで構成されている。ユーザ端末UTn、及び情報処理サーバ1は、夫々、ネットワークNWに接続される。ネットワークNWは、例えば、インターネット、専用通信回線例えば、CATVCommunityAntennaTelevision回線、移動体通信網基地局等を含む、及びゲートウェイ等により構築されている。また、ユーザ端末UTnは電子メールを送受信する機能を有する。ユーザ端末UTnは、電子メールを送受信し管理するためのアプリケーションソフトウェア以下、メールソフトという。により、所定の電子メールアドレスに送信された電子メールをメールサーバから受信してディスプレイに表示させたり、指定された電子メールアドレス宛に電子メールを送信したりする機能を有する。情報処理サーバ1は、例えば、会議室の予約を管理するために設置されたサーバであり、例えば、メールサーバ、返信メール生成サーバ、予約管理サーバ、データベース管理サーバ等として機能する。会議室予約システムSによれば、ユーザ端末UTnのユーザ以下、予約申込者という。は会議室を電子メールで容易に予約することができる。具体的には、まず、予約申込者は会議室毎に定められた電子メールアドレスの中から、予約したい会議室に対応する電子メールアドレスを送信先とする電子メール以下、予約申込メールという。を作成し、当該予約申込メールに予約したい利用時間帯を記入した上で送信する。予約申込メールを受信した情報処理サーバ1は、予約を受け付けられるか否かを判定し、予約を受け付けられる場合には、予約を承諾する旨が記述された返信メール受付受諾メールという。を送信元アドレスに送信する。一方、情報処理サーバ1は、予約を受け付けられない場合には、少なくとも一つの代替案を含む返信メールを送信元アドレスに送信する。代替案を含む返信メールには、代替案毎に電子メールアドレスが対応付けられて記述されており、予約申込者は何れかの代替案を受け入れる場合には、その代替案に対応付けられた電子メールアドレスを送信先として電子メール以下、再送信メールというを送信する。すると、情報処理サーバ1は、受信した再送信メールの宛先となっている電子メールアドレスから予約申込者が指定した代替案を特定し、代替案による予約を確定させる。なお、情報処理サーバ1は、返信メールに含まれる代替案について一定期間仮予約を行い、予約申込者が代替案を指定して再送信メールを再送信するまでの間に、代替案に係る会議室が他の予約申込者に予約されないようにしている。これにより、予約申込者は電子メールのやりとりだけで容易に会議室を予約することができる。[2.情報処理サーバ1の構成]図2は、本実施形態に係る情報処理サーバ1の概要構成例を示すブロック図である。図2に示すように、情報処理サーバ1は、制御部11と、記憶部12と、通信部13と、入出力インターフェース部14と、を備えている。そして、制御部11と入出力インターフェース部14とは、システムバス15を介して接続されている。通信部13は、ネットワークNWに接続して、他のメールサーバとの間で電子メールの送受信を行うための通信を制御するようになっている。記憶部12は、例えば、ハードディスクドライブ等により構成されており、オペレーティングシステム及びサーバプログラム情報処理プログラムの一例等の各種プログラムを記憶する。なお、サーバプログラムは、例えば、所定のサーバ等からネットワークNWを介して配信されるようにしても良いし、CDCompactDisc、DVDDigitalVersatileDisc等の記録媒体に記録されて提供されるようにしてもよい。更に、記憶部12には、ユーザデータベースDBdatabase121、ユーザスケジュールDB122、会議室DB123、予約管理DB124、及び返信メール管理DB125等が構築されている。図3~図7は、各種データベースに登録される内容項目の一例を示す図である。図3に示すように、ユーザDB121には、会議室又は会議室予約システムSを利用するユーザの氏名、電子メールアドレス、及び電話番号等がユーザID毎に対応付けられて登録記憶されている。ユーザDB121に登録される電子メールアドレスは、予約申込者が会議室予約システムSを利用する際に送信する電子メールの送信元となる電子メールアドレスを登録する。ユーザスケジュールDB122には、会議室又は会議室予約システムSを利用するユーザのスケジュールが登録記憶されている。具体的には、図4に示すように、予定のタイトル、場所、時間帯がユーザID及び予定ID毎に対応付けられて登録されている。制御部11は、ユーザIDを指定することで、該当するユーザの全ての登録済みの予定を取得することができるようになっている。図5に示すように、会議室DB123には、会議室予約システムSの予約対象となる会議室の電子メールアドレス、及び収容可能人数等が会議室ID毎に対応付けられて登録記憶されている。会議室DB123に登録される電子メールアドレスは、会議室毎に固有の電子メールアドレスであり、電子メールアドレスから会議室を識別することができるようになっている。図6に示すように、予約管理DB124には、予約された会議室の会議室ID、予約された利用時間帯始期及び終期、予約申込者のユーザID、利用人数、予約申込者以外の各利用者のユーザID等が予約ID毎に対応付けられて登録記憶されている。なお、予約管理DB124には、予約が確定した場合のみならず、後述するように、制御部11により仮予約がなされた場合にもデータが登録される。予約IDは、予約管理DB124にデータが登録される度に発行される。図7に示すように、返信メール管理DB125には、制御部11が代替案毎に生成した電子メールアドレス代替案に対応する電子メールアドレス、当該電子メールアドレスの有効期限、各代替案について仮予約を行った際の予約ID代替案に対応する予約ID等が返信メール管理ID毎に対応付けられて登録記憶されている。すなわち、一の返信メールが作成される度に、対応する一の返信メール管理IDで識別されるデータが登録される。このとき、制御部11は、代替案が複数ある場合にも、代替案と電子メールアドレスと予約IDの対応関係を判別できるように、電子メールアドレス1に代替案1に対応する電子メールアドレスを登録し、予約ID1に代替案1に対応する予約IDを登録する。なお、後述するように、制御部11が代替案に対応する電子メールアドレスを生成した場合には、当該電子メールアドレスの有効期限例えば、電子メールアドレスを生成した日の翌日の午後23時59分59秒などに設定する。また、代替案に対応するデータを予約管理DB124に登録した時刻から所定時間後例えば24時間後の時刻を設定してもよい。を返信メール管理DB125に登録する。代替案が複数あり電子メールアドレスを複数生成した場合にも一つの有効期限で管理することとする。また、制御部11は、有効期限が切れた電子メールアドレスがあった場合には、当該電子メールアドレスの使用を不可とするとともに、当該電子メールアドレスに対応する仮予約を取り消すべく、返信メール管理DB125にて当該電子メールアドレスと対応付けられた予約IDで識別されるデータを予約管理DB124から削除する。これにより、電子メールアドレスの有効期限が切れるまでに正規の予約がなされなかった会議室の仮予約は解除されるので、仮予約された会議室がいつまでも仮予約された状態となることなく、他の予約申込者の予約の機会を奪ってしまう可能性を低くすることができる。なお、上記各種データベースは、情報処理サーバ1がアクセス可能な所定のサーバの記憶手段に設けることとしてもよい。入出力インターフェース部14は、通信部13及び記憶部12と制御部11との間のインターフェース処理を行うようになっている。制御部11は、CPUCentralProcessingUnit11a、ROMReadOnlyMemory11b、RAMRandomAccessMemory11c等により構成されている。そして、コンピュータとしての制御部11は、記憶部12に記憶されたサーバプログラムを実行することにより、受付応答処理等を行う。なお、制御部11は、受信手段、返信データ作成手段、送信手段、申込受付手段、仮申込登録手段、仮申込取消手段、送信先情報管理手段、検索手段として機能する。[3.ユーザ端末UTnの構成]ユーザ端末UTnは、図8に示すように、CPU、RAM、ROM等を有する制御部31と、記憶部32と、ネットワークを介してメールサーバ等との間での通信を制御する通信部33と、タッチパネル34等を備えている。記憶部32は、オペレーティングシステムやメールソフト、アドレス帳を管理するためのアプリケーションソフトウェア以下、アドレス帳ソフトという。等の各種プログラムを記憶する。タッチパネル34は、例えば、静電容量方式のタッチパネルと表示装置とからなり、操作部及び表示部として機能する。なお、ユーザ端末UTnとして、例えば、パーソナルコンピュータPC、PDAPersonalDigitalAssistant、携帯電話機、又はスマートホン等が利用される。[4.情報処理サーバ1の動作][4.1.受付応答処理]次に、情報処理サーバ1の制御部11による受付応答処理について図9等を用いて説明する。図9は、情報処理サーバ1の制御部11よる受付応答処理を示すフローチャートである。図9に示すフローチャートは、情報処理サーバ1が予約申込者のユーザ端末UTnから予約申込メールを受信するステップステップS11から始まるが、まず、図9に示す処理フローの説明の前に当該予約申込メールを予約申込者が送信する際の流れについて図10等を用いて説明する。予約申込者は会議室を予約しようとする場合に、図10に示すように、ユーザ端末UTnのアドレス帳ソフトを起動しアドレス帳をタッチパネル34に表示させる。そして、予約申込者が予約を希望する会議室を選択すると図10では会議室103を選択している様子を示している。、ユーザ端末UTnの制御部31は、タッチパネル34の画面を切り替え、図11に示すように予約申込者により選択された会議室に対応する電子メールアドレス52を表示させる。次いで、予約申込者が、電子メールアドレス表示部52を選択すると、制御部31は、タッチパネル34の画面を切り替え、図12に示すように予約申込者に選択された電子メールアドレスを送信先61とする電子メールの作成画面を表示させる。図12に示す電子メールの作成画面には、送信先61として、予約申込者が予約を希望する会議室に対応する電子メールアドレスがセットされる。また、送信元64としては予約申込者の電子メールアドレスがセットされる。但し、予約申込者の電子メールアドレスとしては、情報処理サーバ1が送信元アドレスにより予約申込者を識別できるように、情報処理サーバ1のユーザDB121に登録されている電子メールアドレスをセットすることとする。件名65には、予約申込者が会議室を予約する際の条件がセットされる。具体的には、予約申込者が会議室を利用する日時に関する条件と、会議室を利用する利用人数に関する条件をセットする。より具体的には、予約申込者は、図13に示す形式で、会議室の利用開始時刻と利用終了時刻と利用人数を指定する。また、図12の本文66には、会議室を利用する他のユーザ会議室を同時に利用するユーザであって、例えば、当該会議室で行われる会議の参加者。以下、他の利用者という。この他の利用者は他の申込対象の一例である。を指定する。他の利用者の指定の仕方は、任意だが、本実施形態ではユーザIDで指定することとする。但し、予約申込者が他の利用者のユーザIDを知らないことも想定されるため、他の利用者の電子メールアドレスで他の利用者を指定することとしてもよい。なお、件名65にて他の利用者を指定することとしてもよい。この場合、図13に示した形式を変更して、例えば、利用人数の後ろに、ハイフンを挿入して、他の利用者のユーザIDを指定する形式としてもよい。また、予約申込者は必要に応じてCc62、Bcc63に電子メールアドレスをセットしてもよい。そして、予約申込者は、宛先61、送信元64、件名65及び本文66に正しく情報がセットされていることを確認した後、送信ボタン69を選択し、予約申込メールを送信する。図9に示すフローチャートに戻り、情報処理サーバ1の制御部11は、上述したようにユーザ端末UTnから送信された予約申込メールを受信するとステップS11、会議室DB123を参照し、受信した予約申込メールの送信先電子メールアドレスすなわち、図12の宛先61にセットされた電子メールアドレスから、会議室会議室IDを識別するステップS12。次いで、制御部11は、ステップS11の処理で受信した予約申込メールの送信元電子メールアドレスから予約申込者のユーザIDを特定するステップS13。次いで、制御部11は、ステップS11の処理で受信した予約申込メールの件名から利用時間帯と利用人数を特定するステップS14。また、制御部11は、ステップS11の処理で受信した予約申込メールの本文等から、予約申込メールを送信した予約申込者以外の他の利用者を特定するステップS15。次いで、制御部11は、図14を用いて説明する受付可否判定処理を行うステップS16。ここで、図14を用いて受付可否判定処理について説明する。図14は、情報処理サーバ1の制御部11よる受付可否判定処理を示すフローチャートである。なお、受付可否判定処理では3つのフラグ会議室NGフラグ、収容人数NGフラグ及び利用者NGフラグを用いるが、当該フローチャートに示す処理が開始されるまでに全て初期化しておく全てのフラグをOFFにしておくこととする。まず、制御部11は、図9のステップS12の処理で識別した会議室が空いているか否かを判定するステップS31。具体的には、制御部11は、予約管理DB124を参照して、ステップS12の処理で識別した会議室の会議室IDに基づいて、図9のステップS14の処理で特定した利用時間帯について、当該会議室の空き状況を確認する。制御部11は、会議室が空いていないと判定した場合にはステップS31:NO、会議室NGフラグをONにしてステップS32、ステップS33の処理に移行し、一方、会議室が空いていると判定した場合にはステップS31:YES、そのまま、ステップS33の処理に移行する。次いで、制御部11は、図9のステップS14の処理で特定した利用人数は、予約対象の会議室の収容人数以下であるか否かを判定するステップS33。具体的には、制御部11は、会議室DB123を参照して、ステップS12の処理で識別した会議室の会議室IDに基づいて、当該会議室の収容可能人数を取得し、会議室の利用人数が当該取得した収容可能人数以下であるか否かを判定する。制御部11は、会議室の利用人数が収容可能人数以下ではないと判定した場合にはステップS33:NO、収容人数NGフラグをONにしてステップS34、ステップS35の処理に移行し、一方、会議室の利用人数が収容可能人数以下であると判定した場合にはステップS33:YES、そのまま、ステップS35の処理に移行する。次いで、制御部11は、図9のステップS15の処理で特定した他の利用者の予定が、ステップS15の処理で特定した利用時間帯について空いているか否かを判定するステップS35。具体的には、制御部11は、ユーザスケジュールDB122を参照して、ステップS15の処理で識別した他の利用者のユーザIDに基づいて、ステップS15の処理で特定した利用時間帯について予定が入っているか否かを判定する。他の利用者が複数いる場合には、それぞれの利用者について確認する。なお、このとき、予約申込者が指定した利用時間帯については予定が入っていないが、その前に会議室の所在地から遠方の地などにおいて他の予定が入っている場合には、予定が入っていると判定することとしてもよい。この場合、制御部11は、例えば、ユーザスケジュールDB122に登録されている先の予定の場所から会議室の所在地までの移動時間を算出し、当該移動時間が先の予定の終了時刻から利用開始時刻までの時間より長い場合には、予定が入っていると判定する。そして、制御部11は、他の利用者の予定が空いていないと判定した場合にはステップS35:NO、利用者NGフラグをONにしてステップS36、ステップS37の処理に移行し、一方、他の利用者の予定が空いていると判定した場合にはステップS35:YES、そのまま、ステップS37の処理に移行する。次いで、制御部11は、全てのNGフラグ会議室NGフラグ、収容人数NGフラグ及び利用者NGフラグがOFFであるか否かを判定するステップS37。このとき、制御部11は、全てのNGフラグがOFFであると判定したときにはステップS37:YES、予約の受付が可であると判定しステップS38、当該フローチャートの処理を終了する。一方、制御部11は、全てのNGフラグがOFFではない何れかのNGフラグがONであるステップS37:NOと判定したときには、予約の受付が不可であると判定しステップS39、当該フローチャートの処理を終了する。図9に戻り、制御部11は、受付できるか否かを判定するステップS17。すなわち、制御部11は、受付可否判定処理を取得することがなく合理的である。また、制御部11は、予約が申し込まれた日時から予め設定された期間例えば、3日以内内の時間帯のみを取得することとしてもよい。この場合、予約が申し込まれた日時から1ヶ月後など、代替案として不適な時期を取得することがなく合理的である。次いで、制御部11は、先に取得した、会議室について予約が取られていない各時間帯について、全利用者予約申込者及び他の利用者の予定が空いているか否かを確認する。具体的には、制御部11は、ユーザスケジュールDB122を参照し、取得した各時間帯に他の予定が入っていないか確認する。このとき、制御部11は、図14のステップS35の処理について説明した内容と同様に、取得した時間帯の前に遠方の地において予定が入っている場合には、予定が入っていると判定することとしてもよい。次いで、制御部11は、ステップS54の処理及びステップS55の処理の結果に基づく、利用者全員収容可能な会議室及び利用者全員が利用可能な利用時間帯の組合せを代替案として記憶部12にストックしステップS56、ステップS63の処理に移行する。一方、制御部11は、ステップS53の処理において検索A処理ではないと判定した場合にはステップS53:NO、次いで、ステップS52の処理で取り出した実行すべき処理の種別は検索B処理であるか否かを判定するステップS57。このとき、制御部11は、検索B処理であると判定した場合にはステップS57:YES、ステップS54と同様に、利用者予約申込者と他の利用者を全員収容可能な会議室を全て選択するステップS58。次いで、制御部11は、ステップS58の処理で選択した会議室のうち、予約申込者により指定された利用時間帯に空いている会議室を全て選択するステップS59。具体的には、制御部11は、予約管理DB124を参照し、ステップS58の処理で選択した会議室毎に、予約申込者により指定された利用時間帯に空いているか予約可能かを確認し、空いている会議室を選択する。次いで、制御部11は、ステップS59の処理で選択された会議室会議室ID及び予約申込者により指定された利用時間帯の組合せを代替案として記憶部12にストックしステップS60、ステップS63の処理に移行する。一方、制御部11は、ステップS57の処理において検索B処理ではないと判定した場合ステップS57:NO、すなわち、ステップS52の処理で検索C処理を取り出した場合には、次いで、予約申込者により予約を申し込まれた会議室について予約が入っていない時間帯であって、全利用者予約申込者及び他の利用者の予定が空いている時間帯を利用時間帯として選択するステップS61。具体的には、制御部11は、まず、予約管理DB124を参照し、予約を申し込まれた会議室について予約が取られていないすなわち、予約が可能な時間帯を全て取得する。このとき、制御部11は、ステップS55の処理について説明した内容と同様に、予め設定された時間の予約が可能な時間帯のみを取得したり、予約が申し込まれた日時から予め設定された期間内の時間帯のみを取得したりしてもよい。また、制御部11は、先に取得した、会議室について予約が取られていない各時間帯について、全利用者の予定が空いているか否かを確認する。具体的には、制御部11は、ユーザスケジュールDB122を参照し、各利用者について、取得した各時間帯に他の予定が入っていないか確認する。このとき、制御部11は、図14のステップS35の処理について説明した内容と同様に、取得した時間帯の前に遠方の地において予定が入っている場合には、予定が入っていると判定することとしてもよい。次いで、制御部11は、予約申込者により指定された会議室会議室ID及びステップS61の処理で選択した利用時間帯の組合せを代替案として記憶部12にストックしステップS62、ステップS63の処理に移行する。制御部11は、ステップS56の処理、ステップS60の処理又はステップS62の処理を終えると、次いで、記憶部12にストックした実行すべき処理の種別が残っているか否かを判定するステップS63。このとき、制御部11は、記憶部12にストックした実行すべき処理の種別が残っていると判定した場合にステップS63:YES、ステップS52の処理に移行し、ストックした全ての実行すべき処理の種別を取り出すまで、ステップS52~ステップS63の処理を繰り返す。一方、制御部11は、記憶部12にストックした実行すべき処理の種別が残っていないと判定した場合にステップS63:NO、当該フローチャートの処理を終了する。図9に戻り、制御部11は、代替案に対応する電子メールアドレスを生成するステップS20。具体的には、制御部11は、代替案検索処理図15のステップS56の処理、ステップS60の処理又はステップS62の処理で記憶部12にストックした会議室及び利用時間帯の組合せ毎代替案毎に電子メールアドレスを生成する。このとき、制御部11は唯一無二の電子メールアドレスを生成する。電子メールアドレスの生成方法は任意であり、電子メールアドレスから代替案を推測できるように、電子メールアドレスに会議室番号や利用時間帯を組み込んで生成することとしてもよいし、ランダムな文字列で生成してもよい。次いで、制御部11は、各代替案の内容に応じて、予約管理DB124及び返信メール管理DB125にデータを登録するステップS21。具体的には、制御部11は、代替案毎に仮予約を行うべく、予約管理DB124にデータ仮予約する会議室の会議室ID、利用時間帯、予約申込者のユーザID、利用人数、他の利用者のユーザIDを登録する。このとき、制御部11は予約IDを発行することとする。次いで、制御部11は、代替案毎に対応する電子メールアドレスと、先に発行した予約IDを、返信メール管理DB125に登録する。また、このとき、制御部11は、電子メールアドレスの有効期限を設定し、返信メール管理DB125に登録する。なお、図示しないが、制御部11は、ここで設定した電子メールアドレスの有効期限を適宜、チェックして、有効期限が切れた電子メールアドレスがあった場合には、上述したように、当該電子メールアドレスを無効化するとともに、当該電子メールアドレスに対応する、仮予約に係る予約IDを予約管理DB124から削除する。次いで、制御部11は、ステップS20で生成した電子メールアドレスと、その電子メールアドレスに対応する代替案の内容を含む返信メールを作成するステップS22。なお、返信メールの例については後述する。次いで、制御部11は、作成した返信メールを、送信元すなわち、ステップS11の処理で受信した予約申込メールの送信元を示す電子メールアドレス宛に送信しステップS23、当該フローチャートの処理を終了する。[4.2.再送信メール受信時処理]次に、情報処理サーバ1の制御部11による再送信メール受信時処理について図17等を用いて説明する。図17は、情報処理サーバ1の制御部11よる再送信メール受信時処理を示すフローチャートである。図17に示すフローチャートは、情報処理サーバ1が予約申込者のユーザ端末UTnから再送信された再送信メールを受信するステップステップS11から始まるが、まず、フローチャートの説明の前に、上述した受付応答処理により返信メールが送信されてから、予約申込者が再送信メールを送信する際の流れについて図18等を用いて説明する。図9のステップS23の処理において情報処理サーバ1の制御部11により送信される返信メールの内容は、例えば図18で示すような内容であり、予約申込者のユーザ端末UTnで受信され、タッチパネル34に表示される。返信メールの送信元71は、情報処理サーバ1で管理する任意の電子メールアドレスとすることができ、例えば、予約申込メールの宛先として指定された電子メールアドレスを用いることとしてもよい。また、図18に示すように、Cc72には、制御部11が、予約申込メールにて他の利用者として指定されたユーザの電子メールアドレスを設定することとしてもよい。この場合、他の利用者は、予約申込者が会議室の予約を申し込んだこと、その予約が受け付けられなかったことを把握することができる。宛先73には、制御部11が、予約申込メールの送信元であって電子メールアドレスをセットする。件名74は任意とすることができ、例えば、予約申込メールに対する返信メールであることを知らせるために、予約申込メールで指定された件名の頭にRe:を付けることとしてもよい。本文75には、予定申込メールにて指定された内容では予約を受け付けることができなかった旨を示すメッセージとともに、代替案が提示されている。具体的には、代替案毎に、その内容と電子メールアドレス75a、75bが記述される。予約申込者は提示された代替案の中から、受け入れてもいい代替案が提示されている場合には、その代替案に対応する電子メールアドレス宛に再送信メールを返信すればよい。一方、予約申込者は受け入れてもいい代替案が提示されていない場合には、そのまま返信メールを放置すれば、これら代替案に対応する電子メールアドレスの有効期限が切れて、会議室の仮予約も解除される。そして、図18に示すように、予約申込者は受け入れてもいい代替案図18の例では代替案2が提示されていた場合には、その代替案に対応する電子メールアドレス75bを宛先とする再送信メールを作成するべく、電子メールアドレス75bを指定する。一方、ユーザ端末UTnの制御部31は、電子メールアドレス75bが指定されたことを検出すると、図19に示すように、当該指定された電子メールアドレスを宛先とする電子メールの作成画面をタッチパネル34に表示させる。図19に示すように、情報処理サーバ1からの返信メールに対する返信メール再送信メールでは、宛先81に、制御部31により、図18の電子メールの本文75内にて指定された電子メールアドレス75bがセットされる。また、Cc72には、情報処理サーバ1からの返信メールと同様に、制御部31により、予約申込者以外の他の利用者に、当該指定された代替案が分かるように、他の利用者の電子メールアドレスがセットされる。送信元には、制御部31により、予約申込者の電子メールアドレスがセットされる。また、件名74は任意とすることができ、例えば、返信メールの件名の頭に更にRe:を付けることとしてもよい。本文75は、任意の内容を記述することでき、空欄でもよい。そして、予約申込者は、送信ボタン89を選択し、電子メールを送信する。図17に示すフローチャートに戻り、情報処理サーバ1の制御部11は、上述したようにユーザ端末UTnから送信された再送信メールを受信するとステップS91、返信メール管理DB125を参照し、受信した再送信メールの送信先電子メールアドレスから予約IDを識別するステップS92。次いで、制御部11は、返信メール管理DB125を参照し、ステップS92で識別した予約IDを含むデータの返信メール管理IDを特定するステップS93。次いで、制御部11は、特定した返信メール管理IDで管理される他の予約IDすなわち、同じ返信メールで提案された他の代替案に対応する予約IDを特定するステップS94。次いで、制御部11は、予約管理DB124から、ステップS94の処理で特定した予約IDで識別されるデータを削除するステップS95。すなわち、制御部11は、一の返信データにて提案した代替案のうち、予約申込者によって指定された代替案に対応する予約IDで管理されるデータのみを予約管理DB124に残し、他の代替案に対応する予約IDで管理されるデータを削除することで、指定された代替案の仮予約を正規の予約として確定させ、他の代替案の仮予約を取り消す。次いで、制御部11は、返信メール管理DB125を参照し、ステップS93の処理で特定した返信メール管理IDで管理される電子メールアドレスを特定するステップS96。このとき、制御部11は複数の電子メールアドレスが管理されている場合にはそれら全てを特定する。次いで、制御部11は、ステップS96の処理で特定した電子メールアドレスを無効化するステップS97。次いで、制御部11は、返信メール管理DB125から、ステップS93の処理で特定した返信メール管理IDで管理されるデータを削除するステップS98。次いで、制御部11は、受付受諾メールを、ステップS91ステップS11で受信した電子メールの送信元に送信しステップS99、当該フローチャートの処理を終了する。以上説明したように、本実施形態における情報処理サーバ1情報処理装置の一例の制御部11は、会議室申込対象、資源の一例を識別可能な電子メールアドレス送信先情報の一例に基づいて送信された予約申込メール送信データの一例を受信し、受信した予約申込メールの電子メールアドレスから予約対象となる会議室を識別し、また、予約申込メールの件名65から利用時間帯申込条件の一例を特定する。また、制御部11は、会議室を特定した利用時間帯で予約申込みの一例を受け付けることができるか否かを判定し、予約を受け付けることができないと判定した場合に、会議室と利用時間帯との少なくともいずれかを変更した代替案を検索し、検索した代替案にそれぞれ対応する電子メールアドレスを生成し、生成した電子メールアドレスを含む返信メール返信データの一例を作成し、予約申込メールの送信元へ送信する。これにより、予約対象の会議室の予約を受け付けることができない場合であっても、会議室と利用時間帯との少なくともいずれかを変更した代替案を識別可能な電子メールアドレスを含む返信メールが送信元へ送信されることから、予約申込者は返信メールに含まれる代替案に対応する電子メールアドレスの示す送信先に再送信メールを再送信することで容易に予約を行うことができる。ところで、従来、一部の会議室予約システムでは、予約申込者が会議室番号及び利用時間帯を指定して予約申込メールを情報処理サーバに送信すると、予約を受け付けた旨を示す予約承諾メール、又は予約を受け付けられなかった旨を示す予約辞退メールの何れかが返信されていた。予約申込者は、予約辞退メールを受信した場合には改めて、利用時間帯を変更して予約申込メールを送信しなければならなかった。そのため、予約申込者は必ず会議室を予約しなければならない場合には、複数の会議室について予約申込メールを一斉送信し、予約承諾メールが送信された会議室の予約を確定するといった方法を用いていた。この方法を用いた場合に、予約承諾メールが複数送信されてきた場合すなわち、複数の会議室を予約できた場合に、不要な会議室の予約をキャンセルしなければならず、手間がかかっていた。これに対して、本実施形態の会議室予約システムSによれば、返信メール従来の予約辞退メールに代替案が含まれており、また、代替案毎に電子メールアドレスが設定されていることから、予約申込者は、指定した代替案に対応する電子メールアドレス宛に再送信メールを送信するだけで予約を確定させることができ、予約申込者の利便性を飛躍的に向上させることができる。さらに、返信メールでは、予約申込者以外の他の利用者の予定を考慮した代替案が提示されるので、予約申込者はわざわざ他の利用者の予定を確認する必要がないという利点もある。[5.変形例][5.1.他の適用例][5.1.1.施設の予約を受け付ける施設予約システムへの適用]上記実施形態では、会議室を予約対象としたが、他の施設、例えば、レストランのテーブル、ホテルの部屋等の施設を予約対象とする施設予約システムに本発明を適用することができる。当該変形例では、他の利用者は、予約申込者と同じテーブルに着く同伴者であったり、同じ部屋に宿泊する同伴者であったりする。但し、予約申込者が一人でレストランやホテル等を利用する場合には、他の利用者が存在しないので、予約管理DBの利用人数として1人が登録され、予約申込者以外の利用者のユーザIDにはデータが登録されない。[5.1.2.出張サービスの予約を受け付けるサービス予約システムへの適用]上記実施形態では、本発明を会議室予約システムSに適用したが、ここでは、出張サービスの予約を受け付けるサービス予約システムに適用する場合の変形例について説明する。サービス予約システムで予約可能な出張サービスとは、例えば、自動車の修理、鍵ガラスの修理、パソコンの修理、ハウスクリーニング等の出張サービスである。以下、サービス予約システムの変形例についての説明では、上記実施形態と同様の部材については同じ符号を用いつつ、上記実施形態との差異点を中心に説明する。本変形例では、情報処理サーバ1の記憶部12には、ユーザDB121の代わりに図20に示すユーザDB121A、会議室DB123の代わりに図21に示すサービスDB123A、予約管理DB124の代わりに図22に示す予約管理DB124Aが構築され、また、図4に示したユーザスケジュールDB122及び図7に示した返信メール管理DB125が構築される。図20に示すように、ユーザDB121Aには、サービス予約システムを利用するユーザの氏名、電子メールアドレス、住所、電話番号及びクレジットカード情報等がユーザID毎に対応付けられて登録記憶されている。ユーザDB121Aには、予約申込者がサービス予約システムを利用する際に送信する電子メールの送信元となる電子メールアドレスを登録する。図21に示すように、サービスDB123Aには、サービス予約システムの予約対象となるサービスの電子メールアドレス、サービス名及び価格等がサービスID毎に対応付けられて登録記憶されている。サービスDB123Aに登録される電子メールアドレスは、サービス毎に固有の電子メールアドレスであり、電子メールアドレスからサービスを識別することができるようになっている。図22に示すように、予約管理DB124Aには、予約されたサービスのサービスID、予約された利用時間帯始期及び終期、予約申込者のユーザID等が予約ID毎に対応付けられて登録記憶されている。なお、予約管理DB124Aには、予約が確定した場合のみならず、制御部11により仮予約された場合にもデータが登録される。予約IDは、予約管理DB124Aにデータが登録される度に発行される。ユーザスケジュールDB122及び返信メール管理DB125については、上記実施形態とほぼ同様なので説明を省略する。次に本変形例における受付応答処理について、図9を用いながら説明する。まず、予約申込者は出張サービスを予約しようとする場合に、ユーザ端末UTnのアドレス帳ソフトを起動しアドレス帳から予約を希望する出張サービスに対応する電子メールアドレスを指定し、当該指定した電子メールアドレスを宛先とし、件名又は本文に利用時間帯を記入した予約申込メールを送信する。これに対して、情報処理サーバ1の制御部11は、予約申込メールを受信しステップS11、次いで、サービスDB123Aを参照し、受信した予約申込メールの送信先電子メールアドレスから、サービスサービスIDを識別するステップS12。次いで、制御部11は、ステップS13の処理を行い、予約申込メールから利用時間帯を特定するステップS14。なお、制御部11は、本変形例ではステップS15の処理を行わない。次いで、制御部11は、受付可否判定処理を行うステップS16。なお、本変形例における受付可否判定処理の詳細な説明は省略するが、制御部11は、予約申込者により指定された利用時間帯に、ステップS12の処理で識別したサービスの提供が可能か否か、すなわち、予約を受け付けることができるか否かを判定する。そして、制御部11は、予約を受け付けることができないと判定した場合にはステップS17:NO、代替案検索処理を行うステップS19。なお、本変形例における代替案検索処理の詳細な説明は省略するが、制御部11は、予約申込者により指定された利用時間帯を、出張サービスを提供可能な予約可能な利用時間帯に変更した代替案を検索する。このとき、制御部11は、ユーザスケジュールDB122を参照し、予約申込者の予定が空いている利用時間帯を代替案として提示するのが好ましい。制御部11は、こうして検索した代替案に対応する電子メールアドレスを生成しステップS20、ステップS21の処理及びステップS22の処理を行い、返信メールを予約申込メールの送信元に送信するステップS23。[5.1.3.商品の注文を受け付ける商品注文システムへの適用]次に、本発明を、商品の注文を受け付ける商品注文システムに適用する場合の変形例について説明する。以下、商品注文システムの変形例についての説明では、上記実施形態と同様の部材については同じ符号を用いつつ、上記実施形態との差異点を中心に説明する。なお、商品注文システムは、注文者が継続的に購入している商品を注文する場合に利用するのが好適である。この場合、注文者は、アドレス帳に商品に対応する電子メールアドレスを登録しておき、当該電子メールアドレス宛に電子メールを送信するだけで、商品を注文することができる。また、商品と当該商品に対応する電子メールアドレスが記述されたメールマガジンを注文者のユーザ端末UTn宛に送信することとすれば、注文者はメールマガジン内で気に入った商品に対応する電子メールアドレス宛に電子メールを送信するだけでその商品を注文することができる。本変形例では、商品注文システムにおける情報処理サーバの記憶部には、ユーザDB121の代わりに図20に示すユーザDB121A、会議室DB123の代わりに図23に示す商品DB123B、予約管理DB124の代わりに図24に示す注文管理DB124B、返信メール管理DB125の代わりに図25に示す返信メール管理DB125Bが構築され、また、図4に示したユーザスケジュールDB122が構築される。図23に示すように、商品DB123Bには、商品注文システムの注文対象となる商品の電子メールアドレス、商品名、価格及び在庫数等が商品ID毎に対応付けられて登録記憶されている。商品DB123Bに登録される電子メールアドレスは、商品毎に固有の電子メールアドレスであり、電子メールアドレスから商品を識別することができるようになっている。在庫数は注文可能な商品の数に対応しており、在庫数が0であれば仮注文を含めて注文を行うことができない。図24に示すように、注文管理DB124Bには、注文された商品の商品ID、注文数、配送日配送時間帯、注文申込者のユーザID等が注文ID毎に対応付けられて登録記憶されている。なお、注文管理DB124Bには、注文が確定した場合のみならず、制御部11により仮注文された場合にもデータが登録される。注文IDは、注文管理DB124Bにデータが登録される度に発行される。図25に示すように、返信メール管理DB125Bには、制御部11が代替案毎に生成した電子メールアドレス代替案に対応する電子メールアドレス、当該電子メールアドレスの有効期限、各代替案について仮注文を行った際の注文ID代替案に対応する注文ID等が返信メール管理ID毎に対応付けられて登録記憶されている。また、制御部11は、代替案について仮注文を行い注文管理DB124Bに代替案に対応するデータを登録し、その際に発行される注文IDを代替案毎に返信メール管理DB125Bに登録する。このとき、一の返信メールに複数の代替案が含まれる場合には、代替案毎に電子メールアドレス及び注文IDを登録する。一方、制御部11は、有効期限が切れた電子メールアドレスがあった場合には、当該電子メールアドレスの使用を不可とするとともに、当該電子メールアドレスに対応する仮注文を取り消すべく、返信メール管理DB125Bにて当該電子メールアドレスと対応付けられた注文IDで識別されるデータを注文管理DB124Bから削除する。これにより、電子メールアドレスの有効期限が切れるまでに正規の注文がなされなかった商品の仮注文は解除されるので、仮注文された商品がいつまでも仮注文された状態となることなく、他の注文者の注文の機会を奪ってしまう可能性を低くすることができる。ユーザスケジュールDB122については、上記実施形態とほぼ同様なので説明を省略する。また、ユーザDB121Aについては、上記サービス予約システムの変形例とほぼ同様なので説明を省略する。次に本変形例における受付応答処理について、図26を用いながら説明する。本変形例では、商品の注文者は商品を注文しようとする場合に、ユーザ端末UTnのアドレス帳ソフトを起動しアドレス帳から注文する商品に対応する電子メールアドレスを選択し、当該選択した電子メールアドレスを宛先とし、件名又は本文に注文数及び配送日配送時間帯を記入した注文申込メールを送信する。これに対して、情報処理サーバ1の制御部11は、ユーザ端末UTnから注文申込メールを受信するステップS111。次いで、制御部11は、商品DB123Bを参照し、受信した注文申込メールの送信先電子メールアドレスから、商品商品IDを識別するステップS112。次いで、制御部11は、ユーザDB121Aを参照し、注文申込メールの送信元電子メールアドレスから注文者を特定するステップS113。次いで、制御部11は、注文申込メールから配送日配送時間帯及び注文数を特定するステップS114。次いで、制御部11は、受付可否判定処理を行うステップS115。なお、本変形例における受付可否判定処理の詳細な説明は省略するが、制御部11は、注文者により指定された注文数及び配送日配送時間帯で商品を発送可能か否か、すなわち、注文を受け付けることができるか否かを判定する。そして、制御部11は、注文を受け付けることができると判定した場合にはステップS116:YES、送信元に受付受諾メールを送信しステップS117、当該フローチャートにおける処理を終了する。一方、制御部11は、注文を受け付けることができないと判定した場合にはステップS116:NO、代替案検索処理を行うステップS118。なお、本変形例における代替案検索処理の詳細な説明は省略するが、制御部11は、注文商品、注文者により指定された注文数、配送日配送時間帯の少なくとも何れか一方を変更することにより注文を受け付けることできる代替案を検索する。このとき、制御部11は、ユーザスケジュールDB122を参照し、注文者の予定が空いている配送日配送時間帯を代替案として提示するのが好ましい。制御部11は、こうして検索した代替案に対応する電子メールアドレスを生成するステップS119。次いで、制御部11は、各代替案に応じて、注文管理DB124B及び返信メール管理DB125Bにデータを登録するステップS120。具体的には、制御部11は、代替案毎に仮注文を行うべく、注文管理DB124Bに各データ仮注文する商品の商品ID、注文数、配送日配送時間帯、注文者のユーザIDを登録する。このとき、制御部11は注文IDを発行することとする。また、制御部11は、代替案のうち注文数が最大の代替案が指定された場合にも商品を確実に発送できるように、商品DB123Bの在庫数から当該最大の注文数を減算しておく。但し、制御部11は、仮注文が確定した場合、又は全ての仮注文が取り消された場合には、正しい在庫数となるように調整する。次いで、制御部11は、代替案毎に対応する電子メールアドレスと、先に発行した注文IDを、返信メール管理DB125Bに登録する。また、このとき、制御部11は、電子メールアドレスの有効期限を設定し、返信メール管理DB125Bに登録する。なお、図示しないが、制御部11は、ここで設定した電子メールアドレスの有効期限を適宜、チェックして、有効期限が切れた電子メールアドレスがあった場合には、上述したように、当該電子メールアドレスを無効化するとともに、当該電子メールアドレスに対応する、仮注文に係る注文IDを注文管理DB124Bから削除する。次いで、制御部11は、ステップS119で生成した電子メールアドレスと、その電子メールアドレスに対応する代替案の内容を含む返信メールを作成しステップS121、送信元すなわち、ステップS111の処理で受信した注文申込メールの送信元を示す電子メールアドレス宛に送信しステップS122、当該フローチャートの処理を終了する。次に本変形例における再送信メール受信時処理について、図27を用いながら説明する。情報処理サーバ1の制御部11は、ユーザ端末UTnから送信された再送信メールを受信するとステップS141、返信メール管理DB125Bを参照し、受信した再送信メールの送信先電子メールアドレスから注文IDを識別するステップS142。次いで、制御部11は、返信メール管理DB125Bを参照し、ステップS142で識別した注文IDを含むデータの返信メール管理IDを特定するステップS143。次いで、制御部11は、特定した返信メール管理IDで管理される他の注文IDすなわち、同じ返信メールで提案された他の代替案に対応する注文IDを特定するステップS144。次いで、制御部11は、注文管理DB124Bから、ステップS144の処理で特定した注文IDで識別されるデータを削除するステップS145。すなわち、制御部11は、一の返信データにて提案した代替案のうち、注文者によって指定された代替案に対応する注文IDで管理されるデータのみを注文管理DB124Bに残し、他の代替案に対応する注文IDで管理されるデータを削除することで、指定された代替案の仮注文を正規の注文として確定させ、他の代替案の仮注文を取り消す。次いで、制御部11は、返信メール管理DB125Bを参照し、ステップS143の処理で特定した返信メール管理IDで管理される電子メールアドレスを特定するステップS146。次いで、制御部11は、ステップS146の処理で特定した電子メールアドレスを無効化するステップS147。次いで、制御部11は、返信メール管理DB125Bから、ステップS143の処理で特定した返信メール管理IDで管理されるデータを削除するステップS148。次いで、制御部11は、注文者より指定された代替案にて注文を受け付けたことを示す受付受諾メールを、ステップS141ステップS111で受信した電子メールの送信元に送信しステップS149、当該フローチャートの処理を終了する。なお、当該変形例では、注文者が配送日配送時間帯や注文数を注文申込メールにて指定することとしたが、配送日配送時間帯の指定を不可とし、注文数も一注文につき一つだけしか注文できないこととした、単純な構成としてもよい。当該構成とする場合には、注文管理DB124Bに注文数、配送日配送時間帯の項目を設ける必要がなくなる。当該構成とする場合、注文者は注文商品に対応する電子メールアドレスを送信先とする注文申込メールを情報処理サーバ1に送信する。このときの注文申込メールの件名や本文は空欄とすることができる。情報処理サーバ1の制御部11は、注文申込メールを受信すると、商品DB123Bを参照して送信先電子メールアドレスから注文商品を識別し、また、ユーザDB121Aを参照して送信元電子メールアドレスから注文者を特定する。次いで、制御部11は、商品DB123Bを参照して、注文を受け付けることができるか否かすなわち、注文商品の在庫があるか否かを判定する。そして、制御部11は、注文を受け付けることができないと判定した場合には、注文を受け付けることができる、他の商品を代替案として検索する。次いで、制御部11は、検索した代替案に係る商品に対応する電子メールアドレスを商品DB123から取得し、次いで、取得した電子メールアドレスを含む返信メールを作成して注文申込メールの送信元に送信する。また、制御部11は、各代替案に応じて注文管理DB124Bにデータを登録する。[5.2.SMSによるデータ通信]上記実施形態では、ユーザ端末UTnと情報処理サーバ1との間のデータの送受信に電子メールを用いているが、これに代えて、SMS等の他の一方向の通信手段を用いることとしてもよい。[5.3.会議室に対応する電子メールアドレスと利用時間を指定させる返信メール]上記実施形態では、情報処理サーバ1の制御部11は、代替案会議室及び利用時間帯の組合せ毎に電子メールアドレスを生成して、何れの電子メールアドレス宛の再送信メールを受信するかによって、予約申込者が指定した代替案予約IDを識別することとしているが、これに代えて、予約申込者が指定した代替案における会議室を電子メールアドレスから識別し、代替案における利用時間帯を件名等から特定することとしてもよい。この場合、例えば、図28に示すような返信メールをユーザ端末UTnに送信し、予約申込者に当該返信メールに基づいて再送信メールを作成して送信してもらうこととする。図28に示す返信メールの本文95には、制御部11が検索した2つの代替案それぞれについて、返信用の電子メールアドレス95a、95c及びキーワード95b、95dが記述されている。予約申込者は受け入れてもいい代替案が提示されている場合には、その代替案に対応する電子メールアドレス宛の再送信メールを作成し、件名にその代替案に対応するキーワードを記述し、送信すればよい。例えば、予約申込者は代替案2を指定する場合には、電子メールアドレス95cを宛先とする再送信メールを作成するべく、電子メールアドレス95cを指定する。一方、ユーザ端末UTnの制御部31は、電子メールアドレス95cが指定されたことを検出すると、図29に示すように、当該指定された電子メールアドレスを宛先とする電子メールの作成画面をタッチパネル34に表示させる。図29に示す再送信メールでは、制御部31により、宛先101に、図28の電子メールの本文95内にて提示された代替案に対応する電子メールアドレス95cがセットされる。また、予約申込者は件名に、代替案2に対応するキーワードBを記述した上で、送信ボタン109を選択し、電子メールを送信することとする。そして、情報処理サーバ1の制御部11は、再送信メールを受信すると、再送信メールの送信先電子メールアドレスから会議室IDを識別するとともに、件名から利用時間帯を特定する。次いで、制御部11は、予約管理DB124を参照し、識別した会議室ID及び特定した利用時間帯に基づいて予約IDを識別する。次いで、制御部11は、返信メール管理DBから、識別した予約IDが登録されている返信メール管理IDを特定して、当該特定した返信メール管理IDで管理される電子メールアドレスを全て無効化するとともに、他の代替案に対応する予約IDに係る仮予約を取り消す。なお、ここでは、制御部11が図28に示すような返信メールを作成する場合について説明したが、これに代えて、図30に示すようなHTMLHyperTextMarkupLanguageメールによる返信メールを作成することとしてもよい。図30に示す返信メールの本文115には、制御部11が検索した2つの代替案それぞれについて、メール作成用リンク115a、115bが記述されている。メール作成用リンク115a、115bは、HTMLタグ補助データの一例の記述に基づくもので、メール作成用リンク115aが予約申込者により指定されると、メール作成画面が開き、再送信メールの宛先に代替案1に対応する電子メールアドレスがセットされ、件名にキーワードAがセットされるようになっている。同様に、メール作成用リンク115aが予約申込者により指定されると、図29に示すように、メール作成画面が開き、再送信メールの宛先に代替案2に対応する電子メールアドレスがセットされ、件名にキーワードBがセットされるようになっている。このようにHTMLメールを用いた場合には、予約申込者は、自分で件名にキーワードを記述する必要が無く、代替案に対応するメール作成用リンク115a、115bを指定するだけで再送信メールが作成されるので容易に再送信メールを送信することができる。[5.4.仮予約の管理]上記実施形態において、情報処理サーバ1の制御部11は、代替案について仮予約をする場合には予約管理DB124に代替案に対応するデータを登録した上で、正規の予約がなされたデータのみを残してその他のデータを削除することで、仮予約を取り消すこととしているが、これに代えて、予約管理DB124の項目にキャンセルフラグを設け、データを登録する際にはキャンセルフラグをOFFにしておき、正規の予約がなされた場合に、当該正規の予約に対応するデータのみキャンセルフラグをOFFのままとする一方、その他の代替案に対応するデータキャンセル対象のデータのキャンセルフラグをONに変更することで、何れの代替案仮予約が正規の予約となり、何れの代替案仮予約がキャンセルされたかを識別できるようにしてもよい。"