WO2013046771A1 - 情報処理装置、情報処理方法、情報処理プログラム、及び情報処理プログラムが記録された記録媒体 - Google Patents

Abstract

　当初の申込みを受け付けることができない事態が生じた場合であっても、当該申込みの代わりとなる代替案を申込者に提示し、申込者が容易に当該代替案による申込みを行うことができる情報処理装置等を提供することを目的とする。　受信した送信データから当初の申込み内容を把握し、当該申込みを受け付けることができないと判定した場合に、当該申込みに対する代替案を識別可能な送信先情報を含む返信データを作成して、当該作成した返信データを、送信データの送信元に送信する。

Description

情報処理装置、情報処理方法、情報処理プログラム、及び情報処理プログラムが記録された記録媒体

　本発明は、申込者が申込対象を容易に申し込むことができる情報処理装置等の技術分野に関する。

　従来、ｗｅｂページで構成されるショッピングサイトを利用したショッピングが普及している。そうした中、特許文献１には、注文者が電子メールで容易に商品を注文することができる技術が開示されている。具体的には、サーバが、注文者の端末装置から、注文商品の商品コードを含む電子メールアドレスを送信先とする電子メールを受信し、受信した電子メールの送信先アドレスに含まれる商品コードから注文商品を識別する技術である。

特開２００８－１２９６８０号公報

　しかしながら、電子メールで注文を受け付ける場合には、ショッピングサイトを介して注文を受け付ける場合と異なり、注文者が在庫の有無等を確認できないまま注文を行う場合が多く、注文を受け付けることができない事態が生じる可能性が低くない。特許文献１には、この場合の対処の仕方について記載されていない。このことは、商品を注文する場面に限らず、サービスを予約する場面や資源（施設，人など）を確保する場面など、何らかの申込みを行う場面全般においてもあてはまる。

　本発明は以上の点に鑑みてなされたものであり、当初の申込みを受け付けることができない事態が生じた場合であっても、当該申込みの代わりとなる代替案を申込者に提示し、申込者が容易に当該代替案の申込みを行うことができる情報処理装置等を提供することを目的とする。

　上記課題を解決するために、請求項１に記載の発明は、申込対象を識別可能な送信先情報を宛先とし、一方向の通信により送信された送信データを受信する受信手段と、前記受信手段により受信された送信データの送信先情報により識別される申込対象の申込みを受け付けることができない場合に、代替案を識別可能な送信先情報を含む返信データを作成する返信データ作成手段と、前記返信データ作成手段により作成された返信データを前記送信データの送信元を宛先として送信する送信手段と、を備えることを特徴とする情報処理装置である。

　この発明によれば、申込対象の申込みを受け付けることができない場合であっても、代替案に係る申込対象を識別可能な送信先情報を含む返信データが送信元宛に送信されることから、申込者は返信データに含まれる送信先情報を宛先として再送信データを送信するだけで代わりの申込対象の申込みを容易に行うことができる。

　請求項１の発明において行われる送信データの送信には、http（HyperText Transfer Protocol）やhttps（Hypertext Transfer Protocol over Secure Socket Layer）等による双方向の通信ではなく、一方向（片方向、単方向）の通信が利用される。具体的には、電子メールによるデータの通信、ＳＭＳ（Short Message Service）によるデータの通信等がある。

　また、請求項１の発明における「申込み」には、商品の「注文」、サービス（理容、診察・治療等の医療サービス、飲食物の提供、宿泊施設の提供、各種施設（運動施設、娯楽施設）の提供、各種の出張サービス等）の「予約」、資源（会議室、ＯＡ機器、人的資源等）の「確保」などが含まれるものとする。

　請求項２に記載の発明は、前記受信手段が、さらに、前記代替案を識別可能な送信先情報を宛先とする再送信データを受信し、前記受信手段により受信された再送信データの送信先情報により識別される代替案に係る申込対象の申込みを受け付ける申込受付手段をさらに含む、ことを特徴とする請求項１に記載の情報処理装置である。

　この発明によれば、申込者が指定した代替案に係る申込対象の申込みを受け付けることができる。

　請求項３に記載の発明は、前記作成された返信データに含まれる送信先情報により識別される代替案に係る申込対象の仮申込みを登録する仮申込登録手段と、前記仮申込みを登録してから所定期間が経過した後、当該仮申込みを取り消す仮申込取消手段と、をさらに備え、前記申込受付手段は、前記受信手段により受信された再送信データの送信先情報により識別される代替案に係る申込対象が仮申込登録されている場合に、当該仮申込みを正規の申込みとして確定させる、ことを特徴とする請求項２に記載の情報処理装置である。

　この発明によれば、仮申込みを登録してから所定期間が経過した後に当該仮申込みが取り消されるので、代替案にかかる申込対象をいつまでも仮申込み状態のまま確保しておく必要がなくなり、他の申込者による申込みの機会が徒に奪われてしまうことを回避することができる。

　請求項４に記載の発明は、前記返信データ作成手段が、代替案を識別可能な送信先情報を複数含む返信データを作成し、前記仮申込登録手段は、前記作成された返信データに含まれる送信先情報により識別される各代替案に係る申込対象の仮申込みを登録し、前記仮申込取消手段は、前記申込受付手段により前記仮申込み登録がなされている申込対象が正規の申込みとして確定された場合に、当該申込対象と同時期に仮申込みの登録がなされた他の申込対象に係る仮申込みを取り消すことを特徴とする請求項３に記載の情報処理装置である。

　この発明によれば、申込者に対して提示された代替案のうち申込者に指定されなかった代替案に係る仮申込みは、申込者に指定された代替案に係る申込みが正規の申込みとして確定された場合に取り消されるので、いつまでも仮申込み状態のまま確保しておく必要がなくなり、他の申込者による申込みの機会が徒に奪われてしまうことを回避することができる。

　請求項５に記載の発明は、前記代替案は申込条件を含み、前記返信データ作成手段が、前記代替案を識別可能な送信先情報を生成し、当該生成された送信先情報を含む返信データを作成する、ことを特徴とする請求項２乃至４の何れか一項に記載の情報処理装置である。

　この発明によれば、申込者に対して申込条件を含む代替案を提案することができるとともに、申込者は返信データに含まれる送信先情報を宛先として再送信データを送信するだけで代替案による申込みを容易に行うことができる。

　請求項６に記載の発明は、前記返信データ作成手段により生成された送信先情報を宛先とする再送信データの受信を可能とし、所定期間経過後に、当該生成された送信先情報を宛先とする再送信データの受信を不可能とする送信先情報管理手段をさらに備える、ことを特徴とする請求項５に記載の情報処理装置である。

　この発明によれば、返信メールに含まれる送信先情報を宛先とする再送信データをいつまでも受信可能な状態とするように送信先情報を管理しなくて済む。

　請求項７に記載の発明は、前記受信手段が、申込条件をさらに含む前記送信データを受信し、前記受信手段により受信された送信データの送信先情報により識別される申込対象の申込みを当該送信データに含まれる申込条件のもとで受け付けることができない場合に、当該申込対象と当該申込条件とのうち少なくともいずれかを変更した受付け可能な代替案を検索する検索手段をさらに備え、前記返信データ作成手段が、前記検索手段により検索された代替案を識別可能な送信先情報を含む返信データを作成することを特徴とする請求項１乃至６の何れか一項に記載の情報処理装置である。

　この発明によれば、送信データに含まれる申込対象及び申込条件による申込みを受け付けることができない場合であっても、申込対象と申込条件とのうち少なくともいずれかを変更した受付け可能な代替案を申込者に提示することができ、申込者は返信データに含まれる送信先情報を宛先として再送信データを送信するだけで代替案による申込みを容易かつ確実に行うことができる。

　請求項８に記載の発明は、前記受信手段が、前記申込対象とともに申し込まれるべき他の申込対象を識別可能な識別情報を含む前記送信データを受信し、前記検索手段が、前記受信手段により受信された送信データの送信先情報により識別される申込対象と、当該送信データに含まれる識別情報により識別される他の申込対象とを、当該送信データに含まれる申込条件のもとで受け付けることができない場合に、当該他の申込対象を変更せずに、当該申込対象及び当該他の申込対象の申込みが同一の申込条件のもとで受付け可能な代替案を検索する、ことを特徴とする請求項７に記載の情報処理装置である。

　この発明によれば、申込対象と他の申込対象とを送信データに含まれる申込条件のもとで受け付けることができない場合に、他の申込対象を変更せずに、申込対象及び当該他の申込対象の申込みが同一の申込条件のもとで受付け可能な代替案を申込者に対して提示することができ、申込者は返信データに含まれる送信先情報を宛先として再送信データを送信するだけで代替案による申込みを容易に行うことができる。

　請求項９に記載の発明は、前記申込対象は、特定の資源であり、前記他の申込対象は、前記資源を利用するユーザであって複数おり、前記申込条件は、前記資源の利用開始日時及び利用終了日時を含む利用期間の条件であり、前記検索手段は、前記他の申込対象が前記同一の申込条件のもとで受付け可能か否かを判定する場合に、一定時間早めた前記利用開始日時と一定時間遅らせた前記利用終了日時との少なくともいずれかを申込条件とすることを特徴とする請求項８に記載の情報処理装置である。

　この発明によれば、他の申込対象（資源を利用するユーザ）について資源を利用する時間帯の前又は後の少なくとも何れかに別の予定が入っている場合であっても、当該別の予定と資源を利用する時間帯の間に一定時間の余裕を確保することができ、資源を利用するユーザの利便性が向上する。

　請求項１０に記載の発明は、前記代替案は申込条件を含み、前記返信データ作成手段が
、前記申込対象を識別可能な送信先情報と、前記申込条件を含む返信データを作成し、前記返信データ作成手段により作成された返信データには、当該返信メールに含まれる送信先情報が指定された場合に当該送信先情報を宛先とする再送信データであって、当該返信メールに含まれる申込条件のうち申込者により指定された申込条件を含む再送信データの作成を補助する補助データが更に含まれていることを特徴とする請求項２乃至４の何れか一項に記載の情報処理装置である。

　この発明によれば、返信メールに含まれる補助データにより、申込者が返信データに含まれる送信先情報を指定した場合に、当該送信先情報の示す送信先を宛先とする再送信データであって、更に申込者により指定された申込条件を含む再送信データが作成される。これにより、情報処理装置は、再送信データの送信先である送信先情報から代替案に係る申込対象を識別し、再送信データに含まれる申込条件から代替案に係る申込条件を識別することができる。また、申込者は返信データに含まれる送信先情報を選択するだけで再送信データが作成されるので、代替案による申込を容易に行うことができる。

　請求項１１に記載の発明は、コンピュータにより実行される情報処理方法であって、申込対象を識別可能な送信先情報を宛先とし、一方向の通信により送信された送信データを受信する受信工程と、前記受信工程により受信された送信データの送信先情報により識別される申込対象の申込みを受け付けることができない場合に、代替案を識別可能な送信先情報を含む返信データを作成する返信データ作成工程と、前記返信データ作成工程により作成された返信データを前記送信データの送信元を宛先として送信する送信工程と、を含むことを特徴とする。

　請求項１２に記載の発明は、コンピュータを、申込対象を識別可能な送信先情報を宛先とし、一方向の通信により送信された送信データを受信する受信手段、前記受信手段により受信された送信データの送信先情報により識別される申込対象の申込みを受け付けることができない場合に、代替案を識別可能な送信先情報を含む返信データを作成する返信データ作成手段、前記返信データ作成手段により作成された返信データを前記送信データの送信元を宛先として送信する送信手段、として機能させる情報処理プログラムがコンピュータ読み取り可能に記録された記録媒体である。

　請求項１３に記載の発明は、コンピュータを、申込対象を識別可能な送信先情報を宛先とし、一方向の通信により送信された送信データを受信する受信手段、前記受信手段により受信された送信データの送信先情報により識別される申込対象の申込みを受け付けることができない場合に、代替案を識別可能な送信先情報を含む返信データを作成する返信データ作成手段、前記返信データ作成手段により作成された返信データを前記送信データの送信元を宛先として送信する送信手段、として機能させることを特徴とする情報処理プログラムである。

　本発明によれば、申込対象の申込みを受け付けることができない場合であっても、当該申込対象の代わりとなる代替案を識別可能な送信先情報を含む返信データが送信元宛に送信されることから、申込者は返信データに含まれる送信先情報の示す宛先に再送信データを送信するだけで容易に申込みを行うことができる。

本実施形態に係る会議室予約システムＳの概要構成の一例を示す図である。 本実施形態に係る情報処理サーバ１の概要構成例を示すブロック図である。 ユーザＤＢ１２１に登録される内容（項目）の一例を示す図である。 ユーザスケジュールＤＢ１２２に登録される内容（項目）の一例を示す図である。 会議室ＤＢ１２３に登録される内容（項目）の一例を示す図である。 予約管理ＤＢ１２４に登録される内容（項目）の一例を示す図である。 返信メール管理ＤＢ１２５に登録される内容（項目）の一例を示す図である。 本実施形態に係るユーザ端末ＵＴｎの概要構成例を示すブロック図である。 情報処理サーバ１の制御部１１による受付応答処理の一例を示すフローチャートである。 アドレス帳から予約する会議室に対応する電子メールアドレスを選択する際の画面例を示す図である。 アドレス帳から予約する会議室に対応する電子メールアドレスを選択する際の画面例を示す図である。 予約する会議室に対応する電子メールアドレスを送信先とするメールを作成している際の画面例を示す図である。 予約条件を指定するためのコード体系の一例を示す図である。 情報処理サーバ１の制御部１１による受付可否判定処理の一例を示すフローチャートである。 情報処理サーバ１の制御部１１による代替案検索処理の一例を示すフローチャートである。 代替案検索処理で参照される実行処理取得テーブルの一例を示す図である。 情報処理サーバ１の制御部１１による再送信メール受信処理の一例を示すフローチャートである。 返信メールを表示した際の画面例を示す図である。 代替案に対応する電子メールアドレスを送信先とする再送信メールを表示した際の画面例を示す図である。 変形例に係るユーザＤＢ１２１Ａに登録される内容（項目）の一例を示す図である。 変形例に係るサービスＤＢ１２３Ａに登録される内容（項目）の一例を示す図である。 変形例に係る予約管理ＤＢ１２４Ａに登録される内容（項目）の一例を示す図である。 変形例に係る商品ＤＢ１２３Ｂに登録される内容（項目）の一例を示す図である。 変形例に係る注文管理ＤＢ１２４Ｂに登録される内容（項目）の一例を示す図である。 変形例に係る返信メール管理ＤＢ１２５Ｂに登録される内容（項目）の一例を示す図である。 変形例に係る情報処理サーバ１の制御部１１による受付応答処理の一例を示すフローチャートである。 変形例に係る情報処理サーバ１の制御部１１による再送信メール受信処理の一例を示すフローチャートである。 変形例に係る返信メールを表示した際の画面例を示す図である。 変形例に係る代替案に基づいて作成された再送信メールを表示した際の画面例を示す図である。 変形例に係る返信メールを表示した際の画面例を示す図である。

　以下、図面を参照して本発明の実施形態について説明する。なお、以下に説明する実施の形態は、会議室予約システムに対して本発明を適用した場合の実施形態である。

　［１．会議室予約システムの構成及び機能概要］
　先ず、本発明の一実施形態に係る会議室予約システムＳの構成及び概要機能について、図１を用いて説明する。

　図１は、本実施形態に係る会議室予約システムＳの概要構成の一例を示す図である。図１に示すように、会議室予約システムＳは、複数のユーザ端末ＵＴｎ（ｎ＝１，２，３・・・ｋ）と、情報処理サーバ（情報処理装置の一例）１と、を含んで構成されている。ユーザ端末ＵＴｎ、及び情報処理サーバ１は、夫々、ネットワークＮＷに接続される。ネットワークＮＷは、例えば、インターネット、専用通信回線（例えば、ＣＡＴＶ（Community Antenna Television）回線）、移動体通信網（基地局等を含む）、及びゲートウェイ等により構築されている。

　また、ユーザ端末ＵＴｎは電子メールを送受信する機能を有する。ユーザ端末ＵＴｎは、電子メールを送受信し管理するためのアプリケーションソフトウェア（以下、「メールソフト」という。）により、所定の電子メールアドレスに送信された電子メールをメールサーバから受信してディスプレイに表示させたり、指定された電子メールアドレス宛に電子メールを送信したりする機能を有する。

　情報処理サーバ１は、例えば、会議室の予約を管理するために設置されたサーバであり、例えば、メールサーバ、返信メール生成サーバ、予約管理サーバ、データベース管理サーバ等として機能する。

　会議室予約システムＳによれば、ユーザ端末ＵＴｎのユーザ（以下、「予約申込者」という。）は会議室を電子メールで容易に予約することができる。具体的には、まず、予約申込者は会議室毎に定められた電子メールアドレスの中から、予約したい会議室に対応する電子メールアドレスを送信先とする電子メール（以下、「予約申込メール」という。）を作成し、当該予約申込メールに予約したい利用時間帯を記入した上で送信する。予約申込メールを受信した情報処理サーバ１は、予約を受け付けられるか否かを判定し、予約を受け付けられる場合には、予約を承諾する旨が記述された返信メール（「受付受諾メール」という。）を送信元アドレスに送信する。一方、情報処理サーバ１は、予約を受け付けられない場合には、少なくとも一つの代替案を含む返信メールを送信元アドレスに送信する。代替案を含む返信メールには、代替案毎に電子メールアドレスが対応付けられて記述されており、予約申込者は何れかの代替案を受け入れる場合には、その代替案に対応付けられた電子メールアドレスを送信先として電子メール（以下、「再送信メール」という）を送信する。すると、情報処理サーバ１は、受信した再送信メールの宛先となっている電子メールアドレスから予約申込者が指定した代替案を特定し、代替案による予約を確定させる。なお、情報処理サーバ１は、返信メールに含まれる代替案について一定期間仮予約を行い、予約申込者が代替案を指定して再送信メールを再送信するまでの間に、代替案に係る会議室が他の予約申込者に予約されないようにしている。これにより、予約申込者は電子メールのやりとりだけで容易に会議室を予約することができる。

　［２．情報処理サーバ１の構成］
　図２は、本実施形態に係る情報処理サーバ１の概要構成例を示すブロック図である。図２に示すように、情報処理サーバ１は、制御部１１と、記憶部１２と、通信部１３と、入出力インターフェース部１４と、を備えている。そして、制御部１１と入出力インターフェース部１４とは、システムバス１５を介して接続されている。

　通信部１３は、ネットワークＮＷに接続して、他のメールサーバとの間で電子メールの送受信を行うための通信を制御するようになっている。

　記憶部１２は、例えば、ハードディスクドライブ等により構成されており、オペレーティングシステム及びサーバプログラム（「情報処理プログラム」の一例）等の各種プログラムを記憶する。なお、サーバプログラムは、例えば、所定のサーバ等からネットワークＮＷを介して配信されるようにしても良いし、ＣＤ（Compact Disc）、ＤＶＤ（Digital Versatile Disc）等の記録媒体に記録されて提供されるようにしてもよい。

　更に、記憶部１２には、ユーザデータベース（ＤＢ（database））１２１、ユーザスケジュールＤＢ１２２、会議室ＤＢ１２３、予約管理ＤＢ１２４、及び返信メール管理ＤＢ１２５等が構築されている。

　図３～図７は、各種データベースに登録される内容（項目）の一例を示す図である。

　図３に示すように、ユーザＤＢ１２１には、会議室又は会議室予約システムＳを利用するユーザの氏名、電子メールアドレス、及び電話番号等がユーザＩＤ毎に対応付けられて登録（記憶）されている。ユーザＤＢ１２１に登録される電子メールアドレスは、予約申込者が会議室予約システムＳを利用する際に送信する電子メールの送信元となる電子メールアドレスを登録する。

　ユーザスケジュールＤＢ１２２には、会議室又は会議室予約システムＳを利用するユーザのスケジュールが登録（記憶）されている。具体的には、図４に示すように、予定のタイトル、場所、時間帯がユーザＩＤ及び予定ＩＤ毎に対応付けられて登録されている。制御部１１は、ユーザＩＤを指定することで、該当するユーザの全ての登録済みの予定を取得することができるようになっている。

　図５に示すように、会議室ＤＢ１２３には、会議室予約システムＳの予約対象となる会議室の電子メールアドレス、及び収容可能人数等が会議室ＩＤ毎に対応付けられて登録（記憶）されている。会議室ＤＢ１２３に登録される電子メールアドレスは、会議室毎に固有の電子メールアドレスであり、電子メールアドレスから会議室を識別することができるようになっている。

　図６に示すように、予約管理ＤＢ１２４には、予約された会議室の会議室ＩＤ、予約された利用時間帯（始期及び終期）、予約申込者のユーザＩＤ、利用人数、予約申込者以外の各利用者のユーザＩＤ等が予約ＩＤ毎に対応付けられて登録（記憶）されている。なお、予約管理ＤＢ１２４には、予約が確定した場合のみならず、後述するように、制御部１１により仮予約がなされた場合にもデータが登録される。予約ＩＤは、予約管理ＤＢ１２４にデータが登録される度に発行される。

　図７に示すように、返信メール管理ＤＢ１２５には、制御部１１が代替案毎に生成した電子メールアドレス（代替案に対応する電子メールアドレス）、当該電子メールアドレスの有効期限、各代替案について仮予約を行った際の予約ＩＤ（代替案に対応する予約ＩＤ）等が返信メール管理ＩＤ毎に対応付けられて登録（記憶）されている。すなわち、一の返信メールが作成される度に、対応する一の返信メール管理ＩＤで識別されるデータが登録される。このとき、制御部１１は、代替案が複数ある場合にも、代替案と電子メールアドレスと予約ＩＤの対応関係を判別できるように、電子メールアドレス（１）に代替案１に対応する電子メールアドレスを登録し、予約ＩＤ（１）に代替案１に対応する予約ＩＤを登録する。なお、後述するように、制御部１１が代替案に対応する電子メールアドレスを生成した場合には、当該電子メールアドレスの有効期限（例えば、電子メールアドレスを生成した日の翌日の午後２３時５９分５９秒などに設定する。また、代替案に対応するデータを予約管理ＤＢ１２４に登録した時刻から所定時間後（例えば２４時間後）の時刻を設定してもよい。）を返信メール管理ＤＢ１２５に登録する。代替案が複数あり電子メールアドレスを複数生成した場合にも一つの有効期限で管理することとする。

　また、制御部１１は、有効期限が切れた電子メールアドレスがあった場合には、当該電子メールアドレスの使用を不可とするとともに、当該電子メールアドレスに対応する仮予約を取り消すべく、返信メール管理ＤＢ１２５にて当該電子メールアドレスと対応付けられた予約ＩＤで識別されるデータを予約管理ＤＢ１２４から削除する。これにより、電子メールアドレスの有効期限が切れるまでに正規の予約がなされなかった会議室の仮予約は解除されるので、仮予約された会議室がいつまでも仮予約された状態となることなく、他の予約申込者の予約の機会を奪ってしまう可能性を低くすることができる。

　なお、上記各種データベースは、情報処理サーバ１がアクセス可能な所定のサーバの記憶手段に設けることとしてもよい。

　入出力インターフェース部１４は、通信部１３及び記憶部１２と制御部１１との間のインターフェース処理を行うようになっている。

　制御部１１は、ＣＰＵ（Central Processing Unit）１１ａ、ＲＯＭ（Read Only Memory）１１ｂ、ＲＡＭ（Random Access Memory）１１ｃ等により構成されている。そして、コンピュータとしての制御部１１は、記憶部１２に記憶されたサーバプログラムを実行することにより、受付応答処理等を行う。なお、制御部１１は、受信手段、返信データ作成手段、送信手段、申込受付手段、仮申込登録手段、仮申込取消手段、送信先情報管理手段、検索手段として機能する。

　［３．ユーザ端末ＵＴｎの構成］
　ユーザ端末ＵＴｎは、図８に示すように、ＣＰＵ、ＲＡＭ、ＲＯＭ等を有する制御部３１と、記憶部３２と、ネットワークを介してメールサーバ等との間での通信を制御する通信部３３と、タッチパネル３４等を備えている。記憶部３２は、オペレーティングシステムやメールソフト、アドレス帳を管理するためのアプリケーションソフトウェア（以下、「アドレス帳ソフト」という。）等の各種プログラムを記憶する。タッチパネル３４は、例えば、静電容量方式のタッチパネルと表示装置とからなり、操作部及び表示部として機能する。なお、ユーザ端末ＵＴｎとして、例えば、パーソナルコンピュータ（ＰＣ）、ＰＤＡ（Personal Digital Assistant）、携帯電話機、又はスマートホン等が利用される。

　［４．情報処理サーバ１の動作］
　［４．１．受付応答処理］
　次に、情報処理サーバ１の制御部１１による受付応答処理について図９等を用いて説明する。図９は、情報処理サーバ１の制御部１１よる受付応答処理を示すフローチャートである。

　図９に示すフローチャートは、情報処理サーバ１が予約申込者のユーザ端末ＵＴｎから予約申込メールを受信するステップ（ステップＳ１１）から始まるが、まず、図９に示す処理フローの説明の前に当該予約申込メールを予約申込者が送信する際の流れについて図１０等を用いて説明する。

　予約申込者は会議室を予約しようとする場合に、図１０に示すように、ユーザ端末ＵＴｎのアドレス帳ソフトを起動しアドレス帳をタッチパネル３４に表示させる。そして、予約申込者が予約を希望する会議室を選択すると（図１０では会議室１０３を選択している様子を示している。）、ユーザ端末ＵＴｎの制御部３１は、タッチパネル３４の画面を切り替え、図１１に示すように予約申込者により選択された会議室に対応する電子メールアドレス５２を表示させる。次いで、予約申込者が、電子メールアドレス表示部５２を選択すると、制御部３１は、タッチパネル３４の画面を切り替え、図１２に示すように予約申込者に選択された電子メールアドレスを送信先６１とする電子メールの作成画面を表示させる。

　図１２に示す電子メールの作成画面には、送信先６１として、予約申込者が予約を希望する会議室に対応する電子メールアドレスがセットされる。また、送信元６４としては予約申込者の電子メールアドレスがセットされる。但し、予約申込者の電子メールアドレスとしては、情報処理サーバ１が送信元アドレスにより予約申込者を識別できるように、情報処理サーバ１のユーザＤＢ１２１に登録されている電子メールアドレスをセットすることとする。件名６５には、予約申込者が会議室を予約する際の条件がセットされる。具体的には、予約申込者が会議室を利用する日時に関する条件と、会議室を利用する利用人数に関する条件をセットする。より具体的には、予約申込者は、図１３に示す形式で、会議室の利用開始時刻と利用終了時刻と利用人数を指定する。また、図１２の本文６６には、会議室を利用する他のユーザ（会議室を同時に利用するユーザであって、例えば、当該会議室で行われる会議の参加者。以下、「他の利用者」という。この「他の利用者」は「他の申込対象」の一例である。）を指定する。他の利用者の指定の仕方は、任意だが、本実施形態ではユーザＩＤで指定することとする。但し、予約申込者が他の利用者のユーザＩＤを知らないことも想定されるため、他の利用者の電子メールアドレスで他の利用者を指定することとしてもよい。なお、件名６５にて他の利用者を指定することとしてもよい。この場合、図１３に示した形式を変更して、例えば、利用人数の後ろに、「ハイフン」を挿入して、他の利用者のユーザＩＤを指定する形式としてもよい。また、予約申込者は必要に応じてＣｃ６２、Ｂｃｃ６３に電子メールアドレスをセットしてもよい。そして、予約申込者は、宛先６１、送信元６４、件名６５及び本文６６に正しく情報がセットされていることを確認した後、送信ボタン６９を選択し、予約申込メールを送信する。

　図９に示すフローチャートに戻り、情報処理サーバ１の制御部１１は、上述したようにユーザ端末ＵＴｎから送信された予約申込メールを受信すると（ステップＳ１１）、会議室ＤＢ１２３を参照し、受信した予約申込メールの送信先電子メールアドレス（すなわち、図１２の宛先６１にセットされた電子メールアドレス）から、会議室（会議室ＩＤ）を識別する（ステップＳ１２）。

　次いで、制御部１１は、ステップＳ１１の処理で受信した予約申込メールの送信元電子メールアドレスから予約申込者のユーザＩＤを特定する（ステップＳ１３）。次いで、制御部１１は、ステップＳ１１の処理で受信した予約申込メールの件名から利用時間帯と利用人数を特定する（ステップＳ１４）。また、制御部１１は、ステップＳ１１の処理で受信した予約申込メールの本文等から、予約申込メールを送信した予約申込者以外の他の利用者を特定する（ステップＳ１５）。次いで、制御部１１は、図１４を用いて説明する受付可否判定処理を行う（ステップＳ１６）。

　ここで、図１４を用いて受付可否判定処理について説明する。図１４は、情報処理サーバ１の制御部１１よる受付可否判定処理を示すフローチャートである。なお、受付可否判定処理では３つのフラグ（会議室ＮＧフラグ、収容人数ＮＧフラグ及び利用者ＮＧフラグ）を用いるが、当該フローチャートに示す処理が開始されるまでに全て初期化しておく（全てのフラグをOFFにしておく）こととする。

　まず、制御部１１は、図９のステップＳ１２の処理で識別した会議室が空いているか否かを判定する（ステップＳ３１）。具体的には、制御部１１は、予約管理ＤＢ１２４を参照して、ステップＳ１２の処理で識別した会議室の会議室ＩＤに基づいて、図９のステップＳ１４の処理で特定した利用時間帯について、当該会議室の空き状況を確認する。制御部１１は、会議室が空いていないと判定した場合には（ステップＳ３１：ＮＯ）、会議室ＮＧフラグをONにして（ステップＳ３２）、ステップＳ３３の処理に移行し、一方、会議室が空いていると判定した場合には（ステップＳ３１：ＹＥＳ）、そのまま、ステップＳ３３の処理に移行する。

　次いで、制御部１１は、図９のステップＳ１４の処理で特定した利用人数は、予約対象の会議室の収容人数以下であるか否かを判定する（ステップＳ３３）。具体的には、制御部１１は、会議室ＤＢ１２３を参照して、ステップＳ１２の処理で識別した会議室の会議室ＩＤに基づいて、当該会議室の収容可能人数を取得し、会議室の利用人数が当該取得した収容可能人数以下であるか否かを判定する。制御部１１は、会議室の利用人数が収容可能人数以下ではないと判定した場合には（ステップＳ３３：ＮＯ）、収容人数ＮＧフラグをONにして（ステップＳ３４）、ステップＳ３５の処理に移行し、一方、会議室の利用人数が収容可能人数以下であると判定した場合には（ステップＳ３３：ＹＥＳ）、そのまま、ステップＳ３５の処理に移行する。

　次いで、制御部１１は、図９のステップＳ１５の処理で特定した他の利用者の予定が、ステップＳ１５の処理で特定した利用時間帯について空いているか否かを判定する（ステップＳ３５）。具体的には、制御部１１は、ユーザスケジュールＤＢ１２２を参照して、ステップＳ１５の処理で識別した他の利用者のユーザＩＤに基づいて、ステップＳ１５の処理で特定した利用時間帯について予定が入っているか否かを判定する。他の利用者が複数いる場合には、それぞれの利用者について確認する。なお、このとき、予約申込者が指定した利用時間帯については予定が入っていないが、その前に会議室の所在地から遠方の地などにおいて他の予定が入っている場合には、予定が入っていると判定することとしてもよい。この場合、制御部１１は、例えば、ユーザスケジュールＤＢ１２２に登録されている先の予定の場所から会議室の所在地までの移動時間を算出し、当該移動時間が先の予定の終了時刻から利用開始時刻までの時間より長い場合には、予定が入っていると判定する。そして、制御部１１は、他の利用者の予定が空いていないと判定した場合には（ステップＳ３５：ＮＯ）、利用者ＮＧフラグをONにして（ステップＳ３６）、ステップＳ３７の処理に移行し、一方、他の利用者の予定が空いていると判定した場合には（ステップＳ３５：ＹＥＳ）、そのまま、ステップＳ３７の処理に移行する。

　次いで、制御部１１は、全てのＮＧフラグ（会議室ＮＧフラグ、収容人数ＮＧフラグ及び利用者ＮＧフラグ）がOFFであるか否かを判定する（ステップＳ３７）。このとき、制御部１１は、全てのＮＧフラグがOFFであると判定したときには（ステップＳ３７：ＹＥＳ）、予約の受付が可であると判定し（ステップＳ３８）、当該フローチャートの処理を終了する。一方、制御部１１は、全てのＮＧフラグがOFFではない（何れかのNGフラグがONである）（ステップＳ３７：ＮＯ）と判定したときには、予約の受付が不可であると判定し（ステップＳ３９）、当該フローチャートの処理を終了する。

　図９に戻り、制御部１１は、受付できるか否かを判定する（ステップＳ１７）。すなわち、制御部１１は、受付可否判定処理(図１４）の結果、受付可と判定したか否かを判定する。制御部１１は、受付可と判定した場合には（ステップＳ１７：ＹＥＳ）、受付受諾メールを、ステップＳ１１で受信した電子メールの送信元に送信し（ステップＳ１８）、当該フローチャートの処理を終了する。一方、制御部１１は、受付不可と判定した場合には（ステップＳ１７：ＮＯ）、図１５を用いて説明する代替案検索処理を行う（ステップＳ１９）。

　ここで、図１５を用いて代替案検索処理について説明する。なお、代替案検索処理は、予約申込者の申込内容では予約を受け付けられなかった場合に、予約申込者に提示する代替案を検索する処理である。代替案の検索方法は任意の方法を採用することができ、ここでは、その一例について説明する。

　図１５は、情報処理サーバ１の制御部１１よる代替案検索処理を示すフローチャートである。なお、制御部１１は、代替案検索処理では、受付可否判定処理（図１４）で使用された３つのフラグ（会議室ＮＧフラグ、収容人数ＮＧフラグ及び利用者ＮＧフラグ）を参照する。このとき、制御部１１は、３つのフラグを、受付可否判定処理（図１４）で使用した状態（すなわち、初期化されない状態）のまま参照する。

　まず、制御部１１は、代替案検索処理にて実行すべき処理を特定し記憶部１２に当該実行すべき処理の種別をストックする（ステップＳ５１）。具体的には、図１６に示す実行処理取得テーブルを参照し、受付可否判定処理（図１４）で使用された３つのフラグのON又はOFFに応じて実行すべき処理を特定する。実行処理取得テーブルには、３つのフラグのON又はOFFに応じた７つのケースについて、それぞれ実行すべき処理として検索Ａ処理、検索Ｂ処理及び検索Ｃ処理の少なくとも何れかの処理が対応付けられている。なお、図１６では、実行処理取得テーブルの右側に備考として、実行すべき処理毎に、対応する代替案が会議室及び利用時間帯を変更又はそのまま（変更無し）の何れとする代替案であるかを示している。

　例えば、ケース１（会議室ＮＧフラグ、収容人数ＮＧフラグ及び利用者ＮＧフラグがONのケース）では、検索Ａ処理を実行すべきことが規定されている。なお、このケースでは、検索Ａ処理で検索される代替案（会議室及び利用時間帯を変更する代替案）が予約申込者に提示されることとなる。また、ケース２（会議室ＮＧフラグ及び収容人数ＮＧフラグがONで、利用者ＮＧフラグがOFFのケース）では、検索Ａ処理及び検索Ｂ処理を実行すべきことが規定されている。なお、このケースでは、検索Ａ処理で検索される代替案と、検索Ｂ処理で検索される代替案（会議室を変更し、利用時間帯はそのまま（変更無し）とする代替案）とが予約申込者に提示されることとなる。さらに、ケース４（会議室ＮＧフラグがONで、収容人数ＮＧフラグ及び利用者ＮＧフラグがOFFのケース）では、検索Ａ処理、検索Ｂ処理及び検索Ｃ処理を実行すべきことが規定されている。なお、このケースでは、検索Ａ処理で検索される代替案と、検索Ｂ処理で検索される代替案と、検索Ｃ処理で検索される代替案（会議室をそのまま（変更無し）とし、利用時間帯を変更する代替案）とが予約申込者に提示されることとなる。なお、その他のケース（ケース３、５、６、７）についての実行すべき処理は図１６に示す通りである。

　図１５に戻り、次いで、制御部１１は、ステップＳ５１の処理でストックした実行すべき処理の種別を一つ取り出す（ステップＳ５２）。次いで、制御部１１は、取り出した実行すべき処理の種別は検索Ａ処理であるか否かを判定する（ステップＳ５３）。

　このとき、制御部１１は、検索Ａ処理であると判定した場合には（ステップＳ５３：ＹＥＳ）、利用者（予約申込者と他の利用者）を全員収容可能な会議室を選択する（ステップＳ５４）。具体的には、制御部１１は、会議室ＤＢ１２３を参照し、図９のステップＳ１４の処理で特定した利用人数以上の人数を収容可能な会議室を全て選択する。

　次いで、制御部１１は、ステップＳ５４の処理で選択した会議室について予約が入っていない時間帯であって、全利用者の予定が空いている時間帯を利用時間帯として選択する（ステップＳ５５）。具体的には、制御部１１は、まず、予約管理ＤＢ１２４を参照し、ステップＳ５４の処理で選択した各会議室について予約が取られていない（すなわち、予約が可能な）時間帯を全て取得する。このとき、制御部１１は、予め設定された時間（例えば、２時間）の予約が可能な時間帯のみを取得することとしてもよい。この場合、会議室を利用するのには不適な時間(例えば、５分間といった短い時間や、１０時間といった長い時間)を取得することがなく合理的である。また、制御部１１は、予約が申し込まれた日時から予め設定された期間（例えば、３日以内）内の時間帯のみを取得することとしてもよい。この場合、予約が申し込まれた日時から１ヶ月後など、代替案として不適な時期を取得することがなく合理的である。次いで、制御部１１は、先に取得した、会議室について予約が取られていない各時間帯について、全利用者（予約申込者及び他の利用者）の予定が空いているか否かを確認する。具体的には、制御部１１は、ユーザスケジュールＤＢ１２２を参照し、取得した各時間帯に他の予定が入っていないか確認する。このとき、制御部１１は、図１４のステップＳ３５の処理について説明した内容と同様に、取得した時間帯の前に遠方の地において予定が入っている場合には、予定が入っていると判定することとしてもよい。

　次いで、制御部１１は、ステップＳ５４の処理及びステップＳ５５の処理の結果に基づく、利用者全員収容可能な会議室及び利用者全員が利用可能な利用時間帯の組合せを代替案として記憶部１２にストックし（ステップＳ５６）、ステップＳ６３の処理に移行する。

　一方、制御部１１は、ステップＳ５３の処理において検索Ａ処理ではないと判定した場合には（ステップＳ５３：ＮＯ）、次いで、ステップＳ５２の処理で取り出した実行すべき処理の種別は検索Ｂ処理であるか否かを判定する（ステップＳ５７）。

　このとき、制御部１１は、検索Ｂ処理であると判定した場合には（ステップＳ５７：ＹＥＳ）、ステップＳ５４と同様に、利用者（予約申込者と他の利用者）を全員収容可能な会議室を全て選択する（ステップＳ５８）。

　次いで、制御部１１は、ステップＳ５８の処理で選択した会議室のうち、予約申込者により指定された利用時間帯に空いている会議室を全て選択する（ステップＳ５９）。具体的には、制御部１１は、予約管理ＤＢ１２４を参照し、ステップＳ５８の処理で選択した会議室毎に、予約申込者により指定された利用時間帯に空いているか（予約可能か）を確認し、空いている会議室を選択する。

　次いで、制御部１１は、ステップＳ５９の処理で選択された会議室（会議室ＩＤ）及び予約申込者により指定された利用時間帯の組合せを代替案として記憶部１２にストックし（ステップＳ６０）、ステップＳ６３の処理に移行する。

　一方、制御部１１は、ステップＳ５７の処理において検索Ｂ処理ではないと判定した場合（ステップＳ５７：ＮＯ）、すなわち、ステップＳ５２の処理で検索Ｃ処理を取り出した場合には、次いで、予約申込者により予約を申し込まれた会議室について予約が入っていない時間帯であって、全利用者（予約申込者及び他の利用者）の予定が空いている時間帯を利用時間帯として選択する（ステップＳ６１）。具体的には、制御部１１は、まず、予約管理ＤＢ１２４を参照し、予約を申し込まれた会議室について予約が取られていない（すなわち、予約が可能な）時間帯を全て取得する。このとき、制御部１１は、ステップＳ５５の処理について説明した内容と同様に、予め設定された時間の予約が可能な時間帯のみを取得したり、予約が申し込まれた日時から予め設定された期間内の時間帯のみを取得したりしてもよい。また、制御部１１は、先に取得した、会議室について予約が取られていない各時間帯について、全利用者の予定が空いているか否かを確認する。具体的には、制御部１１は、ユーザスケジュールＤＢ１２２を参照し、各利用者について、取得した各時間帯に他の予定が入っていないか確認する。このとき、制御部１１は、図１４のステップＳ３５の処理について説明した内容と同様に、取得した時間帯の前に遠方の地において予定が入っている場合には、予定が入っていると判定することとしてもよい。

　次いで、制御部１１は、予約申込者により指定された会議室（会議室ＩＤ）及びステップＳ６１の処理で選択した利用時間帯の組合せを代替案として記憶部１２にストックし（ステップＳ６２）、ステップＳ６３の処理に移行する。

　制御部１１は、ステップＳ５６の処理、ステップＳ６０の処理又はステップＳ６２の処理を終えると、次いで、記憶部１２にストックした実行すべき処理の種別が残っているか否かを判定する（ステップＳ６３）。このとき、制御部１１は、記憶部１２にストックした実行すべき処理の種別が残っていると判定した場合に（ステップＳ６３：ＹＥＳ）、ステップＳ５２の処理に移行し、ストックした全ての実行すべき処理の種別を取り出すまで、ステップＳ５２～ステップＳ６３の処理を繰り返す。一方、制御部１１は、記憶部１２にストックした実行すべき処理の種別が残っていないと判定した場合に（ステップＳ６３：ＮＯ）、当該フローチャートの処理を終了する。

　図９に戻り、制御部１１は、代替案に対応する電子メールアドレスを生成する（ステップＳ２０）。具体的には、制御部１１は、代替案検索処理(図１５）のステップＳ５６の処理、ステップＳ６０の処理又はステップＳ６２の処理で記憶部１２にストックした会議室及び利用時間帯の組合せ毎（代替案毎）に電子メールアドレスを生成する。このとき、制御部１１は唯一無二の電子メールアドレスを生成する。電子メールアドレスの生成方法は任意であり、電子メールアドレスから代替案を推測できるように、電子メールアドレスに会議室番号や利用時間帯を組み込んで生成することとしてもよいし、ランダムな文字列で生成してもよい。

　次いで、制御部１１は、各代替案の内容に応じて、予約管理ＤＢ１２４及び返信メール管理ＤＢ１２５にデータを登録する（ステップＳ２１）。具体的には、制御部１１は、代替案毎に仮予約を行うべく、予約管理ＤＢ１２４にデータ（仮予約する会議室の会議室ＩＤ、利用時間帯、予約申込者のユーザＩＤ、利用人数、他の利用者のユーザＩＤ）を登録する。このとき、制御部１１は予約ＩＤを発行することとする。次いで、制御部１１は、代替案毎に対応する電子メールアドレスと、先に発行した予約ＩＤを、返信メール管理ＤＢ１２５に登録する。また、このとき、制御部１１は、電子メールアドレスの有効期限を設定し、返信メール管理ＤＢ１２５に登録する。なお、図示しないが、制御部１１は、ここで設定した電子メールアドレスの有効期限を適宜、チェックして、有効期限が切れた電子メールアドレスがあった場合には、上述したように、当該電子メールアドレスを無効化するとともに、当該電子メールアドレスに対応する、仮予約に係る予約ＩＤを予約管理ＤＢ１２４から削除する。

　次いで、制御部１１は、ステップＳ２０で生成した電子メールアドレスと、その電子メールアドレスに対応する代替案の内容を含む返信メールを作成する（ステップＳ２２）。なお、返信メールの例については後述する。次いで、制御部１１は、作成した返信メールを、送信元（すなわち、ステップＳ１１の処理で受信した予約申込メールの送信元を示す電子メールアドレス宛）に送信し（ステップＳ２３）、当該フローチャートの処理を終了する。

　［４．２．再送信メール受信時処理］
　次に、情報処理サーバ１の制御部１１による再送信メール受信時処理について図１７等を用いて説明する。図１７は、情報処理サーバ１の制御部１１よる再送信メール受信時処理を示すフローチャートである。

　図１７に示すフローチャートは、情報処理サーバ１が予約申込者のユーザ端末ＵＴｎから再送信された再送信メールを受信するステップ（ステップＳ１１）から始まるが、まず、フローチャートの説明の前に、上述した受付応答処理により返信メールが送信されてから、予約申込者が再送信メールを送信する際の流れについて図１８等を用いて説明する。

　図９のステップＳ２３の処理において情報処理サーバ１の制御部１１により送信される返信メールの内容は、例えば図１８で示すような内容であり、予約申込者のユーザ端末ＵＴｎで受信され、タッチパネル３４に表示される。返信メールの送信元７１は、情報処理サーバ１で管理する任意の電子メールアドレスとすることができ、例えば、予約申込メールの宛先として指定された電子メールアドレスを用いることとしてもよい。また、図１８に示すように、Ｃｃ７２には、制御部１１が、予約申込メールにて他の利用者として指定されたユーザの電子メールアドレスを設定することとしてもよい。この場合、他の利用者は、予約申込者が会議室の予約を申し込んだこと、その予約が受け付けられなかったことを把握することができる。宛先７３には、制御部１１が、予約申込メールの送信元であって電子メールアドレスをセットする。件名７４は任意とすることができ、例えば、予約申込メールに対する返信メールであることを知らせるために、予約申込メールで指定された件名の頭に「Ｒｅ：」を付けることとしてもよい。本文７５には、予定申込メールにて指定された内容では予約を受け付けることができなかった旨を示すメッセージとともに、代替案が提示されている。具体的には、代替案毎に、その内容と電子メールアドレス７５ａ、７５ｂが記述される。予約申込者は提示された代替案の中から、受け入れてもいい代替案が提示されている場合には、その代替案に対応する電子メールアドレス宛に再送信メールを返信すればよい。一方、予約申込者は受け入れてもいい代替案が提示されていない場合には、そのまま返信メールを放置すれば、これら代替案に対応する電子メールアドレスの有効期限が切れて、会議室の仮予約も解除される。

　そして、図１８に示すように、予約申込者は受け入れてもいい代替案（図１８の例では代替案２）が提示されていた場合には、その代替案に対応する電子メールアドレス７５ｂを宛先とする再送信メールを作成するべく、電子メールアドレス７５ｂを指定する。一方、ユーザ端末ＵＴｎの制御部３１は、電子メールアドレス７５ｂが指定されたことを検出すると、図１９に示すように、当該指定された電子メールアドレスを宛先とする電子メールの作成画面をタッチパネル３４に表示させる。

　図１９に示すように、情報処理サーバ１からの返信メールに対する返信メール（再送信メール）では、宛先８１に、制御部３１により、図１８の電子メールの本文７５内にて指定された電子メールアドレス７５ｂがセットされる。また、Ｃｃ７２には、情報処理サーバ１からの返信メールと同様に、制御部３１により、予約申込者以外の他の利用者に、当該指定された代替案が分かるように、他の利用者の電子メールアドレスがセットされる。送信元には、制御部３１により、予約申込者の電子メールアドレスがセットされる。また、件名７４は任意とすることができ、例えば、返信メールの件名の頭に更に「Ｒｅ：」を付けることとしてもよい。本文７５は、任意の内容を記述することでき、空欄でもよい。そして、予約申込者は、送信ボタン８９を選択し、電子メールを送信する。

　図１７に示すフローチャートに戻り、情報処理サーバ１の制御部１１は、上述したようにユーザ端末ＵＴｎから送信された再送信メールを受信すると（ステップＳ９１）、返信メール管理ＤＢ１２５を参照し、受信した再送信メールの送信先電子メールアドレスから予約ＩＤを識別する（ステップＳ９２）。次いで、制御部１１は、返信メール管理ＤＢ１２５を参照し、ステップＳ９２で識別した予約ＩＤを含むデータの返信メール管理ＩＤを特定する（ステップＳ９３）。次いで、制御部１１は、特定した返信メール管理ＩＤで管理される他の予約ＩＤ（すなわち、同じ返信メールで提案された他の代替案に対応する予約ＩＤ）を特定する（ステップＳ９４）。

　次いで、制御部１１は、予約管理ＤＢ１２４から、ステップＳ９４の処理で特定した予約ＩＤで識別されるデータを削除する（ステップＳ９５）。すなわち、制御部１１は、一の返信データにて提案した代替案のうち、予約申込者によって指定された代替案に対応する予約ＩＤで管理されるデータのみを予約管理ＤＢ１２４に残し、他の代替案に対応する予約ＩＤで管理されるデータを削除することで、指定された代替案の仮予約を正規の予約として確定させ、他の代替案の仮予約を取り消す。

　次いで、制御部１１は、返信メール管理ＤＢ１２５を参照し、ステップＳ９３の処理で特定した返信メール管理ＩＤで管理される電子メールアドレスを特定する（ステップＳ９６）。このとき、制御部１１は複数の電子メールアドレスが管理されている場合にはそれら全てを特定する。

　次いで、制御部１１は、ステップＳ９６の処理で特定した電子メールアドレスを無効化する（ステップＳ９７）。次いで、制御部１１は、返信メール管理ＤＢ１２５から、ステップＳ９３の処理で特定した返信メール管理ＩＤで管理されるデータを削除する（ステップＳ９８）。次いで、制御部１１は、受付受諾メールを、ステップＳ９１（ステップＳ１１）で受信した電子メールの送信元に送信し（ステップＳ９９）、当該フローチャートの処理を終了する。

　以上説明したように、本実施形態における情報処理サーバ１（「情報処理装置」の一例）の制御部１１は、会議室（「申込対象」、「資源」の一例）を識別可能な電子メールアドレス（「送信先情報」の一例）に基づいて送信された予約申込メール（「送信データ」の一例）を受信し、受信した予約申込メールの電子メールアドレスから予約対象となる会議室を識別し、また、予約申込メールの件名６５から利用時間帯（「申込条件」の一例）を特定する。また、制御部１１は、会議室を特定した利用時間帯で予約（「申込み」の一例）を受け付けることができるか否かを判定し、予約を受け付けることができないと判定した場合に、会議室と利用時間帯との少なくともいずれかを変更した代替案を検索し、検索した代替案にそれぞれ対応する電子メールアドレスを生成し、生成した電子メールアドレスを含む返信メール（「返信データ」の一例）を作成し、予約申込メールの送信元へ送信する。これにより、予約対象の会議室の予約を受け付けることができない場合であっても、会議室と利用時間帯との少なくともいずれかを変更した代替案を識別可能な電子メールアドレスを含む返信メールが送信元へ送信されることから、予約申込者は返信メールに含まれる代替案に対応する電子メールアドレスの示す送信先に再送信メールを再送信することで容易に予約を行うことができる。

　ところで、従来、一部の会議室予約システムでは、予約申込者が会議室番号及び利用時間帯を指定して予約申込メールを情報処理サーバに送信すると、予約を受け付けた旨を示す予約承諾メール、又は予約を受け付けられなかった旨を示す予約辞退メールの何れかが返信されていた。予約申込者は、予約辞退メールを受信した場合には改めて、利用時間帯を変更して予約申込メールを送信しなければならなかった。そのため、予約申込者は必ず会議室を予約しなければならない場合には、複数の会議室について予約申込メールを一斉送信し、予約承諾メールが送信された会議室の予約を確定するといった方法を用いていた。この方法を用いた場合に、予約承諾メールが複数送信されてきた場合（すなわち、複数の会議室を予約できた場合）に、不要な会議室の予約をキャンセルしなければならず、手間がかかっていた。これに対して、本実施形態の会議室予約システムＳによれば、返信メール（従来の予約辞退メール）に代替案が含まれており、また、代替案毎に電子メールアドレスが設定されていることから、予約申込者は、指定した代替案に対応する電子メールアドレス宛に再送信メールを送信するだけで予約を確定させることができ、予約申込者の利便性を飛躍的に向上させることができる。さらに、返信メールでは、予約申込者以外の他の利用者の予定を考慮した代替案が提示されるので、予約申込者はわざわざ他の利用者の予定を確認する必要がないという利点もある。

　［５．変形例］
　［５．１．他の適用例］
　［５．１．１．施設の予約を受け付ける施設予約システムへの適用］
　上記実施形態では、会議室を予約対象としたが、他の施設、例えば、レストランのテーブル、ホテルの部屋等の施設を予約対象とする施設予約システムに本発明を適用することができる。当該変形例では、他の利用者は、予約申込者と同じテーブルに着く同伴者であったり、同じ部屋に宿泊する同伴者であったりする。但し、予約申込者が一人でレストランやホテル等を利用する場合には、他の利用者が存在しないので、予約管理ＤＢの利用人数として「１人」が登録され、予約申込者以外の利用者のユーザＩＤにはデータが登録されない。

　［５．１．２．出張サービスの予約を受け付けるサービス予約システムへの適用］
　上記実施形態では、本発明を会議室予約システムＳに適用したが、ここでは、出張サービスの予約を受け付けるサービス予約システムに適用する場合の変形例について説明する。サービス予約システムで予約可能な出張サービスとは、例えば、自動車の修理、鍵・ガラスの修理、パソコンの修理、ハウスクリーニング等の出張サービスである。以下、サービス予約システムの変形例についての説明では、上記実施形態と同様の部材については同じ符号を用いつつ、上記実施形態との差異点を中心に説明する。

　本変形例では、情報処理サーバ１の記憶部１２には、ユーザＤＢ１２１の代わりに図２０に示すユーザＤＢ１２１Ａ、会議室ＤＢ１２３の代わりに図２１に示すサービスＤＢ１２３Ａ、予約管理ＤＢ１２４の代わりに図２２に示す予約管理ＤＢ１２４Ａが構築され、また、図４に示したユーザスケジュールＤＢ１２２及び図７に示した返信メール管理ＤＢ１２５が構築される。

　図２０に示すように、ユーザＤＢ１２１Ａには、サービス予約システムを利用するユーザの氏名、電子メールアドレス、住所、電話番号及びクレジットカード情報等がユーザＩＤ毎に対応付けられて登録（記憶）されている。ユーザＤＢ１２１Ａには、予約申込者がサービス予約システムを利用する際に送信する電子メールの送信元となる電子メールアドレスを登録する。

　図２１に示すように、サービスＤＢ１２３Ａには、サービス予約システムの予約対象となるサービスの電子メールアドレス、サービス名及び価格等がサービスＩＤ毎に対応付けられて登録（記憶）されている。サービスＤＢ１２３Ａに登録される電子メールアドレスは、サービス毎に固有の電子メールアドレスであり、電子メールアドレスからサービスを識別することができるようになっている。

　図２２に示すように、予約管理ＤＢ１２４Ａには、予約されたサービスのサービスＩＤ、予約された利用時間帯（始期及び終期）、予約申込者のユーザＩＤ等が予約ＩＤ毎に対応付けられて登録（記憶）されている。なお、予約管理ＤＢ１２４Ａには、予約が確定した場合のみならず、制御部１１により仮予約された場合にもデータが登録される。予約ＩＤは、予約管理ＤＢ１２４Ａにデータが登録される度に発行される。

　ユーザスケジュールＤＢ１２２及び返信メール管理ＤＢ１２５については、上記実施形態とほぼ同様なので説明を省略する。

　次に本変形例における受付応答処理について、図９を用いながら説明する。まず、予約申込者は出張サービスを予約しようとする場合に、ユーザ端末ＵＴｎのアドレス帳ソフトを起動しアドレス帳から予約を希望する出張サービスに対応する電子メールアドレスを指定し、当該指定した電子メールアドレスを宛先とし、件名又は本文に利用時間帯を記入した予約申込メールを送信する。これに対して、情報処理サーバ１の制御部１１は、予約申込メールを受信し（ステップＳ１１）、次いで、サービスＤＢ１２３Ａを参照し、受信した予約申込メールの送信先電子メールアドレスから、サービス（サービスＩＤ）を識別する（ステップＳ１２）。次いで、制御部１１は、ステップＳ１３の処理を行い、予約申込メールから利用時間帯を特定する（ステップＳ１４）。なお、制御部１１は、本変形例ではステップＳ１５の処理を行わない。

　次いで、制御部１１は、受付可否判定処理を行う（ステップＳ１６）。なお、本変形例における受付可否判定処理の詳細な説明は省略するが、制御部１１は、予約申込者により指定された利用時間帯に、ステップＳ１２の処理で識別したサービスの提供が可能か否か、すなわち、予約を受け付けることができるか否かを判定する。そして、制御部１１は、予約を受け付けることができないと判定した場合には（ステップＳ１７：ＮＯ）、代替案検索処理を行う（ステップＳ１９）。なお、本変形例における代替案検索処理の詳細な説明は省略するが、制御部１１は、予約申込者により指定された利用時間帯を、出張サービスを提供可能な（予約可能な）利用時間帯に変更した代替案を検索する。このとき、制御部１１は、ユーザスケジュールＤＢ１２２を参照し、予約申込者の予定が空いている利用時間帯を代替案として提示するのが好ましい。制御部１１は、こうして検索した代替案に対応する電子メールアドレスを生成し（ステップＳ２０）、ステップＳ２１の処理及びステップＳ２２の処理を行い、返信メールを予約申込メールの送信元に送信する（ステップＳ２３）。

　［５．１．３．商品の注文を受け付ける商品注文システムへの適用］
　次に、本発明を、商品の注文を受け付ける商品注文システムに適用する場合の変形例について説明する。以下、商品注文システムの変形例についての説明では、上記実施形態と同様の部材については同じ符号を用いつつ、上記実施形態との差異点を中心に説明する。なお、商品注文システムは、注文者が継続的に購入している商品を注文する場合に利用するのが好適である。この場合、注文者は、アドレス帳に商品に対応する電子メールアドレスを登録しておき、当該電子メールアドレス宛に電子メールを送信するだけで、商品を注文することができる。また、商品と当該商品に対応する電子メールアドレスが記述されたメールマガジンを注文者のユーザ端末ＵＴｎ宛に送信することとすれば、注文者はメールマガジン内で気に入った商品に対応する電子メールアドレス宛に電子メールを送信するだけでその商品を注文することができる。

　本変形例では、商品注文システムにおける情報処理サーバの記憶部には、ユーザＤＢ１２１の代わりに図２０に示すユーザＤＢ１２１Ａ、会議室ＤＢ１２３の代わりに図２３に示す商品ＤＢ１２３Ｂ、予約管理ＤＢ１２４の代わりに図２４に示す注文管理ＤＢ１２４Ｂ、返信メール管理ＤＢ１２５の代わりに図２５に示す返信メール管理ＤＢ１２５Ｂが構築され、また、図４に示したユーザスケジュールＤＢ１２２が構築される。

　図２３に示すように、商品ＤＢ１２３Ｂには、商品注文システムの注文対象となる商品の電子メールアドレス、商品名、価格及び在庫数等が商品ＩＤ毎に対応付けられて登録（記憶）されている。商品ＤＢ１２３Ｂに登録される電子メールアドレスは、商品毎に固有の電子メールアドレスであり、電子メールアドレスから商品を識別することができるようになっている。在庫数は注文可能な商品の数に対応しており、在庫数が０であれば仮注文を含めて注文を行うことができない。

　図２４に示すように、注文管理ＤＢ１２４Ｂには、注文された商品の商品ＩＤ、注文数、配送日・配送時間帯、注文申込者のユーザＩＤ等が注文ＩＤ毎に対応付けられて登録（記憶）されている。なお、注文管理ＤＢ１２４Ｂには、注文が確定した場合のみならず、制御部１１により仮注文された場合にもデータが登録される。注文ＩＤは、注文管理ＤＢ１２４Ｂにデータが登録される度に発行される。

　図２５に示すように、返信メール管理ＤＢ１２５Ｂには、制御部１１が代替案毎に生成した電子メールアドレス（代替案に対応する電子メールアドレス）、当該電子メールアドレスの有効期限、各代替案について仮注文を行った際の注文ＩＤ（代替案に対応する注文ＩＤ）等が返信メール管理ＩＤ毎に対応付けられて登録（記憶）されている。また、制御部１１は、代替案について仮注文を行い（注文管理ＤＢ１２４Ｂに代替案に対応するデータを登録し）、その際に発行される注文ＩＤを代替案毎に返信メール管理ＤＢ１２５Ｂに登録する。このとき、一の返信メールに複数の代替案が含まれる場合には、代替案毎に電子メールアドレス及び注文ＩＤを登録する。一方、制御部１１は、有効期限が切れた電子メールアドレスがあった場合には、当該電子メールアドレスの使用を不可とするとともに、当該電子メールアドレスに対応する仮注文を取り消すべく、返信メール管理ＤＢ１２５Ｂにて当該電子メールアドレスと対応付けられた注文ＩＤで識別されるデータを注文管理ＤＢ１２４Ｂから削除する。これにより、電子メールアドレスの有効期限が切れるまでに正規の注文がなされなかった商品の仮注文は解除されるので、仮注文された商品がいつまでも仮注文された状態となることなく、他の注文者の注文の機会を奪ってしまう可能性を低くすることができる。

　ユーザスケジュールＤＢ１２２については、上記実施形態とほぼ同様なので説明を省略する。また、ユーザＤＢ１２１Ａについては、上記サービス予約システムの変形例とほぼ同様なので説明を省略する。

　次に本変形例における受付応答処理について、図２６を用いながら説明する。本変形例では、商品の注文者は商品を注文しようとする場合に、ユーザ端末ＵＴｎのアドレス帳ソフトを起動しアドレス帳から注文する商品に対応する電子メールアドレスを選択し、当該選択した電子メールアドレスを宛先とし、件名又は本文に注文数及び配送日・配送時間帯を記入した注文申込メールを送信する。これに対して、情報処理サーバ１の制御部１１は、ユーザ端末ＵＴｎから注文申込メールを受信する（ステップＳ１１１）。次いで、制御部１１は、商品ＤＢ１２３Ｂを参照し、受信した注文申込メールの送信先電子メールアドレスから、商品（商品ＩＤ）を識別する（ステップＳ１１２）。次いで、制御部１１は、ユーザＤＢ１２１Ａを参照し、注文申込メールの送信元電子メールアドレスから注文者を特定する（ステップＳ１１３）。次いで、制御部１１は、注文申込メールから配送日・配送時間帯及び注文数を特定する（ステップＳ１１４）。

　次いで、制御部１１は、受付可否判定処理を行う（ステップＳ１１５）。なお、本変形例における受付可否判定処理の詳細な説明は省略するが、制御部１１は、注文者により指定された注文数及び配送日・配送時間帯で商品を発送可能か否か、すなわち、注文を受け付けることができるか否かを判定する。そして、制御部１１は、注文を受け付けることができると判定した場合には（ステップＳ１１６：ＹＥＳ）、送信元に受付受諾メールを送信し（ステップＳ１１７）、当該フローチャートにおける処理を終了する。一方、制御部１１は、注文を受け付けることができないと判定した場合には（ステップＳ１１６：ＮＯ）、代替案検索処理を行う（ステップＳ１１８）。なお、本変形例における代替案検索処理の詳細な説明は省略するが、制御部１１は、注文商品、注文者により指定された注文数、配送日・配送時間帯の少なくとも何れか一方を変更することにより注文を受け付けることできる代替案を検索する。このとき、制御部１１は、ユーザスケジュールＤＢ１２２を参照し、注文者の予定が空いている配送日・配送時間帯を代替案として提示するのが好ましい。制御部１１は、こうして検索した代替案に対応する電子メールアドレスを生成する（ステップＳ１１９）。

　次いで、制御部１１は、各代替案に応じて、注文管理ＤＢ１２４Ｂ及び返信メール管理ＤＢ１２５Ｂにデータを登録する（ステップＳ１２０）。具体的には、制御部１１は、代替案毎に仮注文を行うべく、注文管理ＤＢ１２４Ｂに各データ（仮注文する商品の商品ＩＤ、注文数、配送日・配送時間帯、注文者のユーザＩＤ）を登録する。このとき、制御部１１は注文ＩＤを発行することとする。また、制御部１１は、代替案のうち注文数が最大の代替案が指定された場合にも商品を確実に発送できるように、商品ＤＢ１２３Ｂの在庫数から当該最大の注文数を減算しておく。但し、制御部１１は、仮注文が確定した場合、又は全ての仮注文が取り消された場合には、正しい在庫数となるように調整する。次いで、制御部１１は、代替案毎に対応する電子メールアドレスと、先に発行した注文ＩＤを、返信メール管理ＤＢ１２５Ｂに登録する。また、このとき、制御部１１は、電子メールアドレスの有効期限を設定し、返信メール管理ＤＢ１２５Ｂに登録する。なお、図示しないが、制御部１１は、ここで設定した電子メールアドレスの有効期限を適宜、チェックして、有効期限が切れた電子メールアドレスがあった場合には、上述したように、当該電子メールアドレスを無効化するとともに、当該電子メールアドレスに対応する、仮注文に係る注文ＩＤを注文管理ＤＢ１２４Ｂから削除する。

　次いで、制御部１１は、ステップＳ１１９で生成した電子メールアドレスと、その電子メールアドレスに対応する代替案の内容を含む返信メールを作成し（ステップＳ１２１）、送信元（すなわち、ステップＳ１１１の処理で受信した注文申込メールの送信元を示す電子メールアドレス宛）に送信し（ステップＳ１２２）、当該フローチャートの処理を終了する。

　次に本変形例における再送信メール受信時処理について、図２７を用いながら説明する。情報処理サーバ１の制御部１１は、ユーザ端末ＵＴｎから送信された再送信メールを受信すると（ステップＳ１４１）、返信メール管理ＤＢ１２５Ｂを参照し、受信した再送信メールの送信先電子メールアドレスから注文ＩＤを識別する（ステップＳ１４２）。次いで、制御部１１は、返信メール管理ＤＢ１２５Ｂを参照し、ステップＳ１４２で識別した注文ＩＤを含むデータの返信メール管理ＩＤを特定する（ステップＳ１４３）。次いで、制御部１１は、特定した返信メール管理ＩＤで管理される他の注文ＩＤ（すなわち、同じ返信メールで提案された他の代替案に対応する注文ＩＤ）を特定する（ステップＳ１４４）。

　次いで、制御部１１は、注文管理ＤＢ１２４Ｂから、ステップＳ１４４の処理で特定した注文ＩＤで識別されるデータを削除する（ステップＳ１４５）。すなわち、制御部１１は、一の返信データにて提案した代替案のうち、注文者によって指定された代替案に対応する注文ＩＤで管理されるデータのみを注文管理ＤＢ１２４Ｂに残し、他の代替案に対応する注文ＩＤで管理されるデータを削除することで、指定された代替案の仮注文を正規の注文として確定させ、他の代替案の仮注文を取り消す。

　次いで、制御部１１は、返信メール管理ＤＢ１２５Ｂを参照し、ステップＳ１４３の処理で特定した返信メール管理ＩＤで管理される電子メールアドレスを特定する（ステップＳ１４６）。次いで、制御部１１は、ステップＳ１４６の処理で特定した電子メールアドレスを無効化する（ステップＳ１４７）。次いで、制御部１１は、返信メール管理ＤＢ１２５Ｂから、ステップＳ１４３の処理で特定した返信メール管理ＩＤで管理されるデータを削除する（ステップＳ１４８）。次いで、制御部１１は、注文者より指定された代替案にて注文を受け付けたことを示す受付受諾メールを、ステップＳ１４１（ステップＳ１１１）で受信した電子メールの送信元に送信し（ステップＳ１４９）、当該フローチャートの処理を終了する。

　なお、当該変形例では、注文者が配送日・配送時間帯や注文数を注文申込メールにて指定することとしたが、配送日・配送時間帯の指定を不可とし、注文数も一注文につき一つだけしか注文できないこととした、単純な構成としてもよい。当該構成とする場合には、注文管理ＤＢ１２４Ｂに注文数、配送日・配送時間帯の項目を設ける必要がなくなる。

　当該構成とする場合、注文者は注文商品に対応する電子メールアドレスを送信先とする注文申込メールを情報処理サーバ１に送信する。このときの注文申込メールの件名や本文は空欄とすることができる。情報処理サーバ１の制御部１１は、注文申込メールを受信すると、商品ＤＢ１２３Ｂを参照して送信先電子メールアドレスから注文商品を識別し、また、ユーザＤＢ１２１Ａを参照して送信元電子メールアドレスから注文者を特定する。次いで、制御部１１は、商品ＤＢ１２３Ｂを参照して、注文を受け付けることができるか否か（すなわち、注文商品の在庫があるか否か）を判定する。そして、制御部１１は、注文を受け付けることができないと判定した場合には、注文を受け付けることができる、他の商品を代替案として検索する。次いで、制御部１１は、検索した代替案に係る商品に対応する電子メールアドレスを商品ＤＢ１２３から取得し、次いで、取得した電子メールアドレスを含む返信メールを作成して注文申込メールの送信元に送信する。また、制御部１１は、各代替案に応じて注文管理ＤＢ１２４Ｂにデータを登録する。

　［５．２．ＳＭＳによるデータ通信］
　上記実施形態では、ユーザ端末ＵＴｎと情報処理サーバ１との間のデータの送受信に電子メールを用いているが、これに代えて、ＳＭＳ等の他の一方向の通信手段を用いることとしてもよい。

　［５．３．会議室に対応する電子メールアドレスと利用時間を指定させる返信メール］
　上記実施形態では、情報処理サーバ１の制御部１１は、代替案（会議室及び利用時間帯の組合せ）毎に電子メールアドレスを生成して、何れの電子メールアドレス宛の再送信メールを受信するかによって、予約申込者が指定した代替案（予約ＩＤ）を識別することとしているが、これに代えて、予約申込者が指定した代替案における会議室を電子メールアドレスから識別し、代替案における利用時間帯を件名等から特定することとしてもよい。この場合、例えば、図２８に示すような返信メールをユーザ端末ＵＴｎに送信し、予約申込者に当該返信メールに基づいて再送信メールを作成して送信してもらうこととする。

　図２８に示す返信メールの本文９５には、制御部１１が検索した２つの代替案それぞれについて、返信用の電子メールアドレス９５ａ、９５ｃ及びキーワード９５ｂ、９５ｄが記述されている。予約申込者は受け入れてもいい代替案が提示されている場合には、その代替案に対応する電子メールアドレス宛の再送信メールを作成し、件名にその代替案に対応するキーワードを記述し、送信すればよい。例えば、予約申込者は代替案２を指定する場合には、電子メールアドレス９５ｃを宛先とする再送信メールを作成するべく、電子メールアドレス９５ｃを指定する。一方、ユーザ端末ＵＴｎの制御部３１は、電子メールアドレス９５ｃが指定されたことを検出すると、図２９に示すように、当該指定された電子メールアドレスを宛先とする電子メールの作成画面をタッチパネル３４に表示させる。図２９に示す再送信メールでは、制御部３１により、宛先１０１に、図２８の電子メールの本文９５内にて提示された代替案に対応する電子メールアドレス９５ｃがセットされる。また、予約申込者は件名に、代替案２に対応するキーワード「Ｂ」を記述した上で、送信ボタン１０９を選択し、電子メールを送信することとする。

　そして、情報処理サーバ１の制御部１１は、再送信メールを受信すると、再送信メールの送信先電子メールアドレスから会議室ＩＤを識別するとともに、件名から利用時間帯を特定する。次いで、制御部１１は、予約管理ＤＢ１２４を参照し、識別した会議室ＩＤ及び特定した利用時間帯に基づいて予約ＩＤを識別する。次いで、制御部１１は、返信メール管理ＤＢから、識別した予約ＩＤが登録されている返信メール管理ＩＤを特定して、当該特定した返信メール管理ＩＤで管理される電子メールアドレスを全て無効化するとともに、他の代替案に対応する予約ＩＤに係る仮予約を取り消す。

　なお、ここでは、制御部１１が図２８に示すような返信メールを作成する場合について説明したが、これに代えて、図３０に示すようなＨＴＭＬ（HyperText Markup Language）メールによる返信メールを作成することとしてもよい。

　図３０に示す返信メールの本文１１５には、制御部１１が検索した２つの代替案それぞれについて、メール作成用リンク１１５ａ、１１５ｂが記述されている。メール作成用リンク１１５ａ、１１５ｂは、ＨＴＭＬタグ（「補助データ」の一例）の記述に基づくもので、メール作成用リンク１１５ａが予約申込者により指定されると、メール作成画面が開き、再送信メールの宛先に代替案１に対応する電子メールアドレスがセットされ、件名にキーワード「Ａ」がセットされるようになっている。同様に、メール作成用リンク１１５ａが予約申込者により指定されると、図２９に示すように、メール作成画面が開き、再送信メールの宛先に代替案２に対応する電子メールアドレスがセットされ、件名にキーワード「Ｂ」がセットされるようになっている。このようにＨＴＭＬメールを用いた場合には、予約申込者は、自分で件名にキーワードを記述する必要が無く、代替案に対応するメール作成用リンク１１５ａ、１１５ｂを指定するだけで再送信メールが作成されるので容易に再送信メールを送信することができる。

　［５．４．仮予約の管理］
　上記実施形態において、情報処理サーバ１の制御部１１は、代替案について仮予約をする場合には予約管理ＤＢ１２４に代替案に対応するデータを登録した上で、正規の予約がなされたデータのみを残してその他のデータを削除することで、仮予約を取り消すこととしているが、これに代えて、予約管理ＤＢ１２４の項目にキャンセルフラグを設け、データを登録する際にはキャンセルフラグをOFFにしておき、正規の予約がなされた場合に、当該正規の予約に対応するデータのみキャンセルフラグをOFFのままとする一方、その他の代替案に対応するデータ（キャンセル対象のデータ）のキャンセルフラグをONに変更することで、何れの代替案（仮予約）が正規の予約となり、何れの代替案（仮予約）がキャンセルされたかを識別できるようにしてもよい。

１　情報処理サーバ
１１　制御部
１２　記憶部
１２１　ユーザＤＢ
１２２　ユーザスケジュールＤＢ
１２３　会議室ＤＢ
１２４　予約管理ＤＢ
１２５　返信メール管理ＤＢ
１３　通信部
１４　入出力インターフェース部
１５　システムバス
ＵＴｎ　ユーザ端末
３１　制御部
３２　記憶部
３３　通信部
３４　タッチパネル
ＮＷ　ネットワーク

Claims (13)

1. 　申込対象を識別可能な送信先情報を宛先とし、一方向の通信により送信された送信データを受信する受信手段と、
   　前記受信手段により受信された送信データの送信先情報により識別される申込対象の申込みを受け付けることができない場合に、代替案を識別可能な送信先情報を含む返信データを作成する返信データ作成手段と、
   　前記返信データ作成手段により作成された返信データを前記送信データの送信元を宛先として送信する送信手段と、
   　を備えることを特徴とする情報処理装置。
2. 　前記受信手段が、さらに、前記代替案を識別可能な送信先情報を宛先とする再送信データを受信し、
   　前記受信手段により受信された再送信データの送信先情報により識別される代替案に係る申込対象の申込みを受け付ける申込受付手段をさらに含む、
   　ことを特徴とする請求項１に記載の情報処理装置。
3. 　前記作成された返信データに含まれる送信先情報により識別される代替案に係る申込対象の仮申込みを登録する仮申込登録手段と、
   　前記仮申込みを登録してから所定期間が経過した後、当該仮申込みを取り消す仮申込取消手段と、をさらに備え、
   　前記申込受付手段は、前記受信手段により受信された再送信データの送信先情報により識別される代替案に係る申込対象が仮申込登録されている場合に、当該仮申込みを正規の申込みとして確定させる、
   　ことを特徴とする請求項２に記載の情報処理装置。
4. 　前記返信データ作成手段は、代替案を識別可能な送信先情報を複数含む返信データを作成し、
   　前記仮申込登録手段は、前記作成された返信データに含まれる送信先情報により識別される各代替案に係る申込対象の仮申込みを登録し、
   　前記仮申込取消手段は、前記申込受付手段により前記仮申込み登録がなされている申込対象が正規の申込みとして確定された場合に、当該申込対象と同時期に仮申込みの登録がなされた他の申込対象に係る仮申込みを取り消す
   　ことを特徴とする請求項３に記載の情報処理装置。
5. 　前記代替案は申込条件を含み、
   　前記返信データ作成手段が、前記代替案を識別可能な送信先情報を生成し、当該生成された送信先情報を含む返信データを作成する、
   　ことを特徴とする請求項２乃至４の何れか一項に記載の情報処理装置。
6. 　前記返信データ作成手段により生成された送信先情報を宛先とする再送信データの受信を可能とし、所定期間経過後に、当該生成された送信先情報を宛先とする再送信データの受信を不可能とする送信先情報管理手段をさらに備える、
   　ことを特徴とする請求項５に記載の情報処理装置。
7. 　前記受信手段が、申込条件をさらに含む前記送信データを受信し、
   　前記受信手段により受信された送信データの送信先情報により識別される申込対象の申込みを当該送信データに含まれる申込条件のもとで受け付けることができない場合に、当該申込対象と当該申込条件とのうち少なくともいずれかを変更した受付け可能な代替案を検索する検索手段をさらに備え、
   　前記返信データ作成手段が、前記検索手段により検索された代替案を識別可能な送信先情報を含む返信データを作成する
   　ことを特徴とする請求項１乃至６の何れか一項に記載の情報処理装置。
8. 　前記受信手段が、前記申込対象とともに申し込まれるべき他の申込対象を識別可能な識別情報を含む前記送信データを受信し、
   　前記検索手段が、前記受信手段により受信された送信データの送信先情報により識別される申込対象と、当該送信データに含まれる識別情報により識別される他の申込対象とを、当該送信データに含まれる申込条件のもとで受け付けることができない場合に、当該他の申込対象を変更せずに、当該申込対象及び当該他の申込対象の申込みが同一の申込条件のもとで受付け可能な代替案を検索する、
   　ことを特徴とする請求項７に記載の情報処理装置。
9. 　前記申込対象は、特定の資源であり、
   　前記他の申込対象は、前記資源を利用するユーザであって複数おり、
   　前記申込条件は、前記資源の利用開始日時及び利用終了日時を含む利用期間の条件であり、
   　前記検索手段は、前記他の申込対象が前記同一の申込条件のもとで受付け可能か否かを判定する場合に、一定時間早めた前記利用開始日時と一定時間遅らせた前記利用終了日時との少なくともいずれかを申込条件とする
   　ことを特徴とする請求項８に記載の情報処理装置。
10. 　前記代替案は申込条件を含み、
    　前記返信データ作成手段が、前記申込対象を識別可能な送信先情報と、前記申込条件を含む返信データを作成し、
    　前記返信データ作成手段により作成された返信データには、当該返信メールに含まれる送信先情報が指定された場合に当該送信先情報を宛先とする再送信データであって、当該返信メールに含まれる申込条件のうち申込者により指定された申込条件を含む再送信データの作成を補助する補助データが更に含まれていることを特徴とする請求項２乃至４の何れか一項に記載の情報処理装置。
11. 　コンピュータにより実行される情報処理方法であって、
    　申込対象を識別可能な送信先情報を宛先とし、一方向の通信により送信された送信データを受信する受信工程と、
    　前記受信工程により受信された送信データの送信先情報により識別される申込対象の申込みを受け付けることができない場合に、代替案を識別可能な送信先情報を含む返信データを作成する返信データ作成工程と、
    　前記返信データ作成工程により作成された返信データを前記送信データの送信元を宛先として送信する送信工程と、
    　を含むことを特徴とする情報処理方法。
12. 　コンピュータを、
    　申込対象を識別可能な送信先情報を宛先とし、一方向の通信により送信された送信データを受信する受信手段、
    　前記受信手段により受信された送信データの送信先情報により識別される申込対象の申込みを受け付けることができない場合に、代替案を識別可能な送信先情報を含む返信データを作成する返信データ作成手段、
    　前記返信データ作成手段により作成された返信データを前記送信データの送信元を宛先として送信する送信手段、
    　として機能させる情報処理プログラムがコンピュータ読み取り可能に記録された記録媒体。
13. 　コンピュータを、
    　申込対象を識別可能な送信先情報を宛先とし、一方向の通信により送信された送信データを受信する受信手段、
    　前記受信手段により受信された送信データの送信先情報により識別される申込対象の申込みを受け付けることができない場合に、代替案を識別可能な送信先情報を含む返信データを作成する返信データ作成手段、
    　前記返信データ作成手段により作成された返信データを前記送信データの送信元を宛先として送信する送信手段、
    　として機能させることを特徴とする情報処理プログラム。

Images