JP2020149513A - 予約管理方法、予約管理プログラム、および情報処理装置 - Google Patents

Abstract

【課題】リソースに対する予約がキャンセルされたことの通知を行うユーザを絞り込むこと。【解決手段】情報処理装置１００は、ユーザから指定された、リソースを検索する条件を受け付ける都度、複数のリソースのうち、受け付けた条件に合致するリソースを検索する。情報処理装置１００は、過去に受け付けた条件のうち、ユーザによる予約が設定されなかった際の条件に基づいて、リソースを検索する条件の変遷に関する情報を生成し、ユーザに対応付けて記憶部１１０に記憶する。情報処理装置１００は、複数のリソースのいずれかのリソースに対する予約がキャンセルされた場合、ユーザに対応付けて記憶部１１０に記憶された情報から特定される条件に、いずれかのリソースが合致するか否かを判定する。情報処理装置１００は、合致すると判定すると、ユーザに対して、いずれかのリソースに対する予約が設定可能であることの通知を出力する。【選択図】図１

Description

本発明は、予約管理方法、予約管理プログラム、および情報処理装置に関する。

従来、ユーザから検索条件を受け付けて、複数のリソースのうち検索条件に合致するリソースをユーザに提示し、いずれかのリソースに対するユーザによる予約を設定し、予約状況を管理するシステムがある。リソースは、例えば、会議室や競技施設などの場所、音楽メディアや映像メディアなどの媒体、または、自転車や自動車などの乗り物である。

先行技術としては、例えば、既予約プランのキャンセル情報を受信した場合、キャンセル情報が天候を理由に送信されたと推定すると、天候予報情報に基づいて推奨プランを抽出し、既予約プランに対応する予約者端末に出力するものがある。

国際公開第２０１７／１６３３７９号

しかしながら、従来技術では、リソースに対するユーザによる予約がキャンセルされ、当該リソースを他のユーザに活用させることが望まれる場合、当該予約がキャンセルされたことの通知をいずれのユーザに対して出力すればよいのかを判断することができない。例えば、ユーザによる予約がキャンセルされたリソースを、他のユーザが使用したいと考えているかを推定することができない。

１つの側面では、本発明は、リソースに対する予約がキャンセルされたことの通知を行うユーザを絞り込むことを目的とする。

１つの実施態様によれば、ユーザから指定された、リソースを検索する条件を受け付ける都度、複数のリソースのうち、受け付けた前記条件に合致するリソースを検索し、受け付けた前記条件のうち、前記ユーザによる予約が設定されなかった際の条件に基づいて、リソースを検索する条件の変遷に関する情報を、前記ユーザに対応付けて記憶部に記憶し、前記複数のリソースのいずれかのリソースに対する予約がキャンセルされた場合、前記ユーザに対応付けて前記記憶部に記憶された情報から特定される条件に、前記いずれかのリソースが合致すれば、前記ユーザに対して、前記いずれかのリソースに対する予約が設定可能であることの通知を出力する予約管理方法、予約管理プログラム、および情報処理装置が提案される。

一態様によれば、リソースに対する予約がキャンセルされたことの通知を行うユーザを絞り込むことが可能になる。

図１は、実施の形態にかかる予約管理方法の一実施例を示す説明図である。 図２は、予約管理システム２００の一例を示す説明図である。 図３は、情報処理装置１００のハードウェア構成例を示すブロック図である。 図４は、リソース管理ＤＢ４００の記憶内容の一例を示す説明図である。 図５は、予約管理ＤＢ５００の記憶内容の一例を示す説明図である。 図６は、予約中止ＤＢ６００の記憶内容の一例を示す説明図である。 図７は、端末装置２０１のハードウェア構成例を示すブロック図である。 図８は、情報処理装置１００の機能的構成例を示すブロック図である。 図９は、動作例１において開催条件を受け付ける一例を示す説明図（その１）である。 図１０は、動作例１において開催条件を受け付ける一例を示す説明図（その２）である。 図１１は、動作例１において開催条件を受け付ける別の例を示す説明図（その１）である。 図１２は、動作例１において開催条件を受け付ける別の例を示す説明図（その２）である。 図１３は、動作例１において開催条件を受け付ける別の例を示す説明図（その３）である。 図１４は、動作例１においてユーザによる予約を設定した後においてユーザに対する通知を出力する一例を示す説明図（その１）である。 図１５は、動作例１においてユーザによる予約を設定した後においてユーザに対する通知を出力する一例を示す説明図（その２）である。 図１６は、動作例１においてユーザによる予約を中止した後においてユーザに対する通知を出力する一例を示す説明図（その１）である。 図１７は、動作例１においてユーザによる予約を中止した後においてユーザに対する通知を出力する一例を示す説明図（その２）である。 図１８は、動作例１においてＮＧ条件を登録する一例を示す説明図（その１）である。 図１９は、動作例１においてＮＧ条件を登録する一例を示す説明図（その２）である。 図２０は、動作例１において開催条件の変遷に関する情報を記憶する詳細を示す説明図（その１）である。 図２１は、動作例１において開催条件の変遷に関する情報を記憶する詳細を示す説明図（その２）である。 図２２は、動作例１において開催条件の変遷に関する情報を記憶する詳細を示す説明図（その３）である。 図２３は、動作例１において通知を出力する対象となるユーザを特定する詳細を示す説明図である。 図２４は、動作例２においてユーザによる予約を設定した後においてユーザに対する通知を出力する一例を示す説明図（その１）である。 図２５は、動作例２においてユーザによる予約を設定した後においてユーザに対する通知を出力する一例を示す説明図（その２）である。 図２６は、動作例２において開催条件の変遷に関する情報を記憶する詳細を示す説明図である。 図２７は、動作例２において通知を出力する対象となるユーザを特定する詳細を示す説明図である。 図２８は、登録処理手順の一例を示すフローチャートである。 図２９は、推薦処理手順の一例を示すフローチャート（その１）である。 図３０は、推薦処理手順の一例を示すフローチャート（その２）である。

以下に、図面を参照して、本発明にかかる予約管理方法、予約管理プログラム、および情報処理装置１００の実施の形態を詳細に説明する。

（実施の形態にかかる予約管理方法の一実施例）
図１は、実施の形態にかかる予約管理方法の一実施例を示す説明図である。図１において、情報処理装置１００は、リソースに対する予約状況を管理するコンピュータである。リソースは、例えば、会議室や競技施設などの場所、音楽メディアや映像メディアなどの媒体、または、自転車や自動車などの乗り物である。

従来、ユーザから検索条件を受け付けて、複数のリソースのうち検索条件に合致するリソースをユーザに提示し、いずれかのリソースに対するユーザによる予約を設定し、予約状況を管理するシステムがある。ここで、システムを使用する複数のユーザが、それぞれ、複数のリソースのうち使用したい優先度が高いリソースに対して予約を設定可能に制御し、複数のユーザの全体で、複数のリソースを有効に活用することが望まれる。優先度は、ユーザにとっての優先度であり、使用することを望む度合いが強いと見込まれるほど、高くなる値として扱われる。

ここで、いずれかのリソースに対するユーザによる予約がキャンセルされた際、予約がキャンセルされたリソースは、有効に活用されにくくなってしまう。このため、いずれかのリソースに対するユーザによる予約がキャンセルされた際、予約がキャンセルされたリソースを他のユーザに活用させ、予約がキャンセルされたリソースを有効に活用することが望まれる場合がある。

これに対し、いずれかのリソースに対するユーザによる予約がキャンセルされた後、予約がキャンセルされたリソースに対して、異なるいずれかのユーザにより予約が設定されることを待つことが考えられるが、該当するリソースの利用を望んでいたユーザにより予約が設定されるとは限らない。特に、最も利用したいリソースが既に予約済みであったために利用を諦めていたようなリソースを最も使用したいユーザが、予約がキャンセルされたことに気付かず、予約がキャンセルされたリソースに対して予約を設定することができないことがある。結果として、複数のユーザの全体で、複数のリソースを有効に活用することは難しい。

このため、いずれかのリソースに対するユーザによる予約がキャンセルされた際、いずれかのリソースに対するユーザによる予約がキャンセルされたことの通知を、キャンセルされたリソースを使用したいユーザに対して出力することが好ましいと考えられる。

しかしながら、いずれかのリソースに対するユーザによる予約がキャンセルされたことの通知を、いずれの他のユーザに対して出力すればよいのかを判断することは難しい。例えば、予約がキャンセルされたリソースを、いずれの他のユーザが使用したいと考えているのかを推定することは難しく、予約がキャンセルされたことの通知を、いずれの他のユーザに対して出力すればよいのかを判断することが難しい。

これに対し、ユーザからキャンセル待ちするリソースの指定を受け付け、指定のリソースがキャンセルされた際、指定のリソースがキャンセルされたことの通知を、ユーザに対して出力する手法が考えられる。この手法では、複数のユーザの全体で、複数のリソースを有効に活用することは難しい。

例えば、ユーザは、最も使用したいリソースに対する予約を諦めたとしても、２番目に使用したいリソースで妥協し、２番目に使用したいリソースに対する予約を設定することができれば、最も使用したいリソースのキャンセル待ちは行わない傾向がある。このため、ユーザが最も使用したかったリソースに対する予約がキャンセルされたとしても、ユーザに対して、リソースがキャンセルされたことの通知を出力することは難しい。

また、例えば、複数のユーザが、同じリソースのキャンセル待ちを行っている状況で、複数のユーザのいずれのユーザに対して、リソースに対する予約がキャンセルされたことの通知を出力すればよいのかを判断することができない。このため、複数のユーザのうち、キャンセルされたリソースを最も使用したいユーザが、キャンセルされたリソースに対する予約を設定可能にすることはできない。このため、リソースを有効に活用することが難しい。また、例えば、ユーザが、キャンセル待ちするリソースを指定するため、ユーザにかかる作業負担の増大化を招く。

そこで、本実施の形態では、ユーザが指定したリソースを検索する条件の変遷に関する情報に基づいて、ユーザの意図を考慮して、リソースに対する予約がキャンセルされたことの通知を、ユーザに対して出力することができる予約管理方法について説明する。この予約管理方法によれば、ユーザの作業負担の増大化を抑制しつつ、ユーザが使用したい優先度が高いリソースを使用しやすくすることができ、ユーザの利便性を向上させ、かつ、リソースが有効に活用されるようにすることができる。

図１において、（１−１）情報処理装置１００は、ユーザから指定された、リソースを検索する条件を受け付ける。条件は、複数の項目のうち１以上の項目のそれぞれの項目の項目条件の組み合わせであってもよい。情報処理装置１００は、ユーザから指定された、リソースを検索する条件を受け付ける都度、複数のリソースのうち、受け付けた条件に合致するリソースを検索する。情報処理装置１００は、ユーザに対して、検索した結果を提示し、ユーザが選択したリソースに対して予約を設定する。

（１−２）情報処理装置１００は、過去に受け付けた条件のうち、ユーザによる予約が設定されなかった際の条件に基づいて、リソースを検索する条件の変遷に関する情報を生成し、ユーザに対応付けて記憶部１１０に記憶する。生成する情報は、例えば、過去に受け付けた条件を時系列順に並べた情報を含む。条件が、複数の項目のうち１以上の項目のそれぞれの項目の項目条件の組み合わせである場合、生成する情報は、例えば、項目ごとに、過去に受け付けた項目条件を時系列順に並べた情報を含んでもよい。また、この場合、生成する情報は、例えば、複数の項目の中で、項目条件が初めて変更されたタイミングが早い順に、複数の項目を並べた情報を含んでもよい。

これによれば、情報処理装置１００は、ユーザが予約を設定しようとした際の意図が反映された情報を、記憶部１１０に記憶しておくことができる。このため、情報処理装置１００は、記憶部１１０を参照して、ユーザが予約を設定することを望むと判断されるリソースを特定可能にし、かつ、複数のリソースのそれぞれのリソースをユーザが使用したい優先度がどの程度高いのかを特定可能にすることができる。

（１−３）情報処理装置１００は、複数のリソースのいずれかのリソースに対する予約がキャンセルされた場合、ユーザに対応付けて記憶部１１０に記憶された情報から特定される条件に、予約がキャンセルされたいずれかのリソースが合致するか否かを判定する。特定される条件は、ユーザが予約を設定することを望むと判断されるリソースを特定する条件である。特定される条件は、例えば、過去に受け付けた条件である。特定される条件は、過去に受け付けた項目条件の組み合わせであってもよい。合致は、過去に受け付けた一部の項目条件を満たすことであってもよい。情報処理装置１００は、合致すると判定すると、ユーザに対して、いずれかのリソースに対する予約が設定可能であることの通知を出力する。情報処理装置１００は、合致しないと判定すると、ユーザに対して、いずれかのリソースに対する予約が設定可能であることの通知を出力しない。

これによれば、情報処理装置１００は、ユーザが指定したリソースを検索する条件の変遷に関する情報に基づいて、ユーザの意図を考慮して、リソースに対する予約がキャンセルされたことの通知を、ユーザに対して出力するか否かを判断することができる。情報処理装置１００は、例えば、予約がキャンセルされたリソースを使用したい優先度が比較的高いユーザに限って、リソースに対する予約がキャンセルされ、リソースに対して新たな予約を設定可能であることの通知を出力することができる。これにより、情報処理装置１００は、リソースに対する予約がキャンセルされたことの通知を出力する対象となるユーザを絞り込むことができる。

このため、ユーザは、使用したい優先度が比較的高いリソースを登録する作業を自発的に行わずとも、使用したい優先度が比較的高いリソースに対する予約がキャンセルされた際には、通知を受け付けることができる。また、ユーザは、使用したい優先度が比較的低いリソースに対する予約がキャンセルされた際には、通知を受け付けないようにすることができる。従って、情報処理装置１００は、ユーザの作業負担の増大化を抑制しつつ、ユーザが使用したい優先度が高いリソースに対して予約を設定しやすくすることができ、ユーザの利便性を向上させることができる。

ここで、従来では、いずれかのリソースに対するユーザによる予約がキャンセルされた後、予約がキャンセルされたリソースに対して、いずれかのユーザにより予約が設定されることを待つようにする場合がある。この場合、予約がキャンセルされたリソースを使用したいユーザは、断続的に予約状況を確認しないと、予約がキャンセルされたことを知ることができない。このため、予約がキャンセルされたリソースを使用したいユーザが、予約がキャンセルされたリソースに対して新たに予約を設定することは難しく、ユーザの作業負担の増大化を招く。

これに対し、情報処理装置１００は、ユーザが指定したリソースを検索する条件の変遷に関する情報に基づいて、リソースに対する予約がキャンセルされたことの通知を、ユーザに対して出力するか否かを判断することができる。このため、情報処理装置１００は、ユーザが自身で予約状況を確認せずに済むようにすることができる。結果として、情報処理装置１００は、ユーザの作業負担の増大化を抑制しつつ、ユーザが使用したい優先度が高いリソースに対して予約を設定しやすくすることができ、ユーザの利便性を向上させ、かつ、リソースが有効に活用されるようにすることができる。

また、従来では、ユーザからキャンセル待ちするリソースの指定を受け付け、指定のリソースがキャンセルされた際、指定のリソースがキャンセルされたことの通知を、ユーザに対して出力する場合がある。この場合、ユーザが、キャンセル待ちするリソースを指定する作業を行う必要があり、ユーザにかかる作業負担の増大化を招く。

これに対し、情報処理装置１００は、ユーザが指定したリソースを検索する条件の変遷に関する情報に基づいて、リソースに対する予約がキャンセルされたことの通知を、ユーザに対して出力するか否かを判断することができる。このため、情報処理装置１００は、ユーザの作業負担の増大化を抑制しつつ、ユーザが使用したい優先度が高いリソースに対して予約を設定しやすくすることができ、ユーザの利便性を向上させ、かつ、リソースが有効に活用されるようにすることができる。

また、通知を受け付けたユーザは、自身が先に設定していた予約をキャンセルし、受け付けた通知が示すリソースに対して新たな予約を設定することができる。そして、情報処理装置１００は、通知を受け付けたユーザによって予約がキャンセルされたことに応じて、予約がキャンセルされたリソースを使用したい優先度が比較的高い他のユーザに対して、通知を出力することができる。結果として、情報処理装置１００は、複数のユーザの全体で、それぞれのユーザが、使用したい優先度が比較的高いリソースに対して予約を設定可能にすることができ、複数のリソースの全体が有効に活用されるようにすることができる。

ここでは、情報処理装置１００が、ユーザごとに、リソースに対する予約が設定可能であることの通知を出力するか否かを判定する場合について説明したが、これに限らない。例えば、情報処理装置１００が、複数のユーザのいずれのユーザに対して、リソースに対する予約が設定可能であることの通知を出力するかを決定する場合があってもよい。この時は、情報処理装置１００は、複数のユーザ同士の競合を防ぐため、前記の優先度を考慮して各ユーザへの通知を発行する順序を決定してもよい。

（予約管理システム２００の一例）
次に、図２を用いて、図１に示した情報処理装置１００を適用した、予約管理システム２００の一例について説明する。

図２は、予約管理システム２００の一例を示す説明図である。図２において、予約管理システム２００は、情報処理装置１００と、端末装置２０１とを含む。予約管理システム２００において、情報処理装置１００と端末装置２０１とは、有線または無線のネットワーク２１０を介して接続される。ネットワーク２１０は、例えば、ＬＡＮ（Ｌｏｃａｌ Ａｒｅａ Ｎｅｔｗｏｒｋ）、ＷＡＮ（Ｗｉｄｅ Ａｒｅａ Ｎｅｔｗｏｒｋ）、インターネットなどである。

情報処理装置１００は、図４〜図６に後述する各種ＤＢ（ＤａｔａＢａｓｅ）を記憶する。情報処理装置１００は、ユーザから指定された、リソースを検索する条件を、端末装置２０１から受信する。情報処理装置１００は、図４に後述するリソース管理ＤＢ４００を参照して、複数のリソースのうち、受信した条件に合致するリソースを検索し、検索した結果を、端末装置２０１に送信する。情報処理装置１００は、いずれかのリソースに対して予約を設定することを要求する設定要求を、端末装置２０１から受信すると、いずれかのリソースに対して予約を設定する。

情報処理装置１００は、図５および図６に後述する各種ＤＢを用いて、ユーザが指定したリソースを検索する条件の遷移に関する情報を、ユーザに対応付けて記憶する。情報処理装置１００は、図５および図６に後述する各種ＤＢを参照して、リソースに対する予約がキャンセルされた際、リソースに対する予約が設定可能になったことの通知を出力する対象とするユーザを特定する。情報処理装置１００は、特定したユーザに対して、リソースに対する予約が設定可能になったことの通知を出力する。情報処理装置１００は、例えば、サーバやＰＣ（Ｐｅｒｓｏｎａｌ Ｃｏｍｐｕｔｅｒ）などである。

端末装置２０１は、リソースに対して予約を設定するユーザが使用するコンピュータである。端末装置２０１は、ユーザの操作入力に基づき、リソースを検索する条件の指定を受け付け、ユーザから指定された、リソースを検索する条件を、情報処理装置１００に送信する。端末装置２０１は、検索した結果を、情報処理装置１００から受信して表示する。端末装置２０１は、ユーザの操作入力に基づき、いずれかのリソースに対して予約を設定することを要求する設定要求を、情報処理装置１００に送信する。端末装置２０１は、例えば、ＰＣ、タブレット端末、スマートフォンなどである。

（予約管理システム２００の具体例（その１））
次に、予約管理システム２００の具体例（その１）について説明する。例えば、予約管理システム２００の具体例（その１）としては、リソースが、場所である場合における具体例が考えられる。場所は、例えば、会議室や競技施設などである。競技施設は、例えば、テニスコートやゴルフコースなどである。条件は、例えば、会議を開催する会議室を検索する条件である。以下の説明では、会議を開催する会議室を検索する条件を、「開催条件」と表記する場合がある。

（予約管理システム２００の具体例（その２））
次に、予約管理システム２００の具体例（その２）について説明する。例えば、予約管理システム２００の具体例（その２）としては、リソースが、レンタルされる物体である場合における具体例が考えられる。物体は、例えば、図書、音楽メディアや映像メディアなどの媒体、または、自転車や自動車などの乗り物である。条件は、例えば、レンタルする図書を検索する条件である。

（予約管理システム２００の具体例（その３））
次に、予約管理システム２００の具体例（その３）について説明する。例えば、予約管理システム２００の具体例（その３）としては、リソースが、サービスを提供する従業員である場合における具体例が考えられる。サービスは、例えば、エステや散髪などである。条件は、従業員を検索する条件である。

ここでは、情報処理装置１００が、端末装置２０１とは異なる装置である場合について説明したが、これに限らない。例えば、情報処理装置１００が、端末装置２０１と一体である場合があってもよい。以下の説明では、上述した予約管理システム２００の具体例（その１）を一例として、情報処理装置１００の動作について説明する。

（情報処理装置１００のハードウェア構成例）
次に、図３を用いて、情報処理装置１００のハードウェア構成例について説明する。

図３は、情報処理装置１００のハードウェア構成例を示すブロック図である。図３において、情報処理装置１００は、ＣＰＵ（Ｃｅｎｔｒａｌ Ｐｒｏｃｅｓｓｉｎｇ Ｕｎｉｔ）３０１と、メモリ３０２と、ネットワークＩ／Ｆ（Ｉｎｔｅｒｆａｃｅ）３０３と、記録媒体Ｉ／Ｆ３０４と、記録媒体３０５と、入力装置３０６と、出力装置３０７とを有する。また、各構成部は、バス３００によってそれぞれ接続される。

ここで、ＣＰＵ３０１は、情報処理装置１００の全体の制御を司る。メモリ３０２は、例えば、ＲＯＭ（Ｒｅａｄ Ｏｎｌｙ Ｍｅｍｏｒｙ）、ＲＡＭ（Ｒａｎｄｏｍ Ａｃｃｅｓｓ Ｍｅｍｏｒｙ）およびフラッシュＲＯＭなどを有する。具体的には、例えば、フラッシュＲＯＭやＲＯＭが各種プログラムを記憶し、ＲＡＭがＣＰＵ３０１のワークエリアとして使用される。メモリ３０２に記憶されるプログラムは、ＣＰＵ３０１にロードされることで、コーディングされている処理をＣＰＵ３０１に実行させる。

ネットワークＩ／Ｆ３０３は、通信回線を通じてネットワーク２１０に接続され、ネットワーク２１０を介して他のコンピュータに接続される。そして、ネットワークＩ／Ｆ３０３は、ネットワーク２１０と内部のインターフェースを司り、他のコンピュータからのデータの入出力を制御する。ネットワークＩ／Ｆ３０３は、例えば、モデムやＬＡＮアダプタなどである。

記録媒体Ｉ／Ｆ３０４は、ＣＰＵ３０１の制御に従って記録媒体３０５に対するデータのリード／ライトを制御する。記録媒体Ｉ／Ｆ３０４は、例えば、ディスクドライブ、ＳＳＤ（Ｓｏｌｉｄ Ｓｔａｔｅ Ｄｒｉｖｅ）、ＵＳＢ（Ｕｎｉｖｅｒｓａｌ Ｓｅｒｉａｌ Ｂｕｓ）ポートなどである。記録媒体３０５は、記録媒体Ｉ／Ｆ３０４の制御で書き込まれたデータを記憶する不揮発メモリである。記録媒体３０５は、例えば、ディスク、半導体メモリ、ＵＳＢメモリなどである。記録媒体３０５は、情報処理装置１００から着脱可能であってもよい。

入力装置３０６は、データの入力を行う装置である。入力装置３０６は、例えば、文字、数字、各種指示などの入力のためのキーを有し、データの入力を行う。入力装置３０６は、具体的には、キーボードやマウスなどである。また、入力装置３０６は、具体的には、タッチパネル式の入力パッドやテンキーなどであってもよい。または、入力装置３０６は、具体的には、マイクなどであってもよい。

出力装置３０７は、データの出力を行う装置である。出力装置３０７は、例えば、カーソル、アイコンあるいはツールボックスをはじめ、文書、画像、機能情報などのデータを表示するディスプレイである。ディスプレイは、例えば、ＣＲＴ（Ｃａｔｈｏｄｅ Ｒａｙ Ｔｕｂｅ）、液晶ディスプレイ、有機ＥＬ（Ｅｌｅｃｔｒｏｌｕｍｉｎｅｓｃｅｎｃｅ）ディスプレイなどである。出力装置３０７は、例えば、プリンタ、スキャナ、スピーカーなどであってもよい。

情報処理装置１００は、入力装置３０６や出力装置３０７を有していなくてもよい。また、情報処理装置１００は、記録媒体Ｉ／Ｆ３０４や記録媒体３０５を複数有していてもよい。また、情報処理装置１００は、記録媒体Ｉ／Ｆ３０４や記録媒体３０５を有していなくてもよい。

（リソース管理ＤＢ４００の記憶内容）
次に、図４を用いて、リソース管理ＤＢ４００の記憶内容の一例について説明する。リソース管理ＤＢ４００は、例えば、図３に示した情報処理装置１００のメモリ３０２や記録媒体３０５などの記憶領域により実現される。図４の例では、リソースは会議室である。

図４は、リソース管理ＤＢ４００の記憶内容の一例を示す説明図である。図４に示すように、リソース管理ＤＢ４００は、名称と、短縮名と、事業所と、最寄り駅と、建屋と、階数と、区画と、映写機器と、無線ＬＡＮと、有線ＬＡＮと、ゲスト使用と、人数とのフィールドを有する。リソース管理ＤＢ４００は、リソースである会議室ごとに各フィールドに情報を設定することにより、予約変更情報が記憶される。

名称のフィールドには、ＩＤとして用いられる会議室の名称が設定される。短縮名のフィールドには、会議室の短縮名が設定される。短縮名は、ユーザにより短縮名が入力された場合に、会議室を特定するために利用可能である。

事業所のフィールドには、会議室が存在する事業所の名称が設定される。最寄り駅のフィールドには、会議室が存在する事業所の最寄り駅の名称が設定される。建屋のフィールドには、会議室が存在する建屋の名称が設定される。階数のフィールドには、会議室が存在する階数が設定される。区画のフィールドには、会議室が存在する区画の名称が設定される。

映写機器のフィールドには、会議室の映写機器の有無が設定される。映写機器のフィールドには、会議室にある映写機器の属性がさらに設定されてもよい。無線ＬＡＮのフィールドには、会議室の無線ＬＡＮ設備の有無が設定される。無線ＬＡＮのフィールドには、会議室にある無線ＬＡＮ設備の属性がさらに設定されてもよい。有線ＬＡＮのフィールドには、会議室の有線ＬＡＮ設備の有無が設定される。有線ＬＡＮのフィールドには、会議室にある有線ＬＡＮ設備の属性がさらに設定されてもよい。

ゲスト使用のフィールドには、会議室をゲストが使用可能か否かが設定される。ゲストは、例えば、会議室を設けた会社に属する人間ではない社外の人間である。人数のフィールドには、会議室に収容可能な人数が設定される。

（予約管理ＤＢ５００の記憶内容）
次に、図５を用いて、予約管理ＤＢ５００の記憶内容の一例について説明する。予約管理ＤＢ５００は、例えば、図３に示した情報処理装置１００のメモリ３０２や記録媒体３０５などの記憶領域により実現される。

図５は、予約管理ＤＢ５００の記憶内容の一例を示す説明図である。図５に示すように、予約管理ＤＢ５００は、予約ＩＤと、開始時間と、終了時間と、開催者と、参加者と、場所と、タイトルと、予約条件とのフィールドを有する。予約管理ＤＢ５００は、会議の予約ごとに各フィールドに情報を設定することにより、予約情報が記憶される。

予約ＩＤのフィールドには、会議の予約を識別する予約ＩＤが設定される。開始時間のフィールドには、予約対象の会議の開催時間の開始時刻が設定される。終了時間のフィールドには、予約対象の会議の開催時間の終了時刻が設定される。

開催者のフィールドには、予約対象の会議の開催者であり、会議の予約を設定したユーザの名称が設定される。参加者のフィールドには、予約対象の会議の参加者の名称が設定される。場所のフィールドには、会議の予約が設定された会議室の名称が設定される。タイトルのフィールドには、会議に付与されたタイトルが設定される。予約条件のフィールドには、会議の予約が設定される際に、ユーザにより指定された会議室を検索する開催条件の変遷に関する情報が設定される。予約条件のフィールドには、会議の予約を設定しない会議室を示すＮＧ条件がさらに設定されてもよい。

予約条件のフィールドには、例えば、図９〜図２３を用いて後述する動作例１に示すような、ユーザにより指定された会議室を検索する開催条件の変遷に関する情報が設定される。予約条件のフィールドには、具体的には、項目ごとに、過去に受け付けた項目条件を時系列順に並べた情報、および、複数の項目の中で、項目条件が初めて変更されたタイミングが早い順に、複数の項目を並べた情報が設定される。

また、予約条件のフィールドには、例えば、図２４〜図２７を用いて後述する動作例２に示すような、ユーザにより指定された会議室を検索する開催条件の変遷に関する情報が設定されてもよい。予約条件のフィールドには、具体的には、過去に受け付けた会議室を検索する開催条件を時系列順に並べた情報が設定される。

（予約中止ＤＢ６００の記憶内容）
次に、図６を用いて、予約中止ＤＢ６００の記憶内容の一例について説明する。予約中止ＤＢ６００は、例えば、図３に示した情報処理装置１００のメモリ３０２や記録媒体３０５などの記憶領域により実現される。

図６は、予約中止ＤＢ６００の記憶内容の一例を示す説明図である。図６に示すように、予約中止ＤＢ６００は、検索ＩＤと、開催者と、参加者と、タイトルと、予約条件とのフィールドを有する。予約中止ＤＢ６００は、会議の予約を中止するまでの予約作業ごとに各フィールドに情報を設定することにより、予約中止情報が記憶される。

検索ＩＤのフィールドには、会議の予約を中止するまでの予約作業を識別する検索ＩＤが設定される。開催者のフィールドには、予約対象の会議の開催者であり、会議の予約を中止したユーザの名称が設定される。参加者のフィールドには、予約対象の会議の参加者の名称が設定される。タイトルのフィールドには、会議に付与されたタイトルが設定される。予約条件のフィールドには、会議の予約が中止されるまでに、ユーザにより指定された会議室を検索する開催条件の変遷に関する情報が設定される。予約条件のフィールドには、会議の予約を設定しない会議室を示すＮＧ条件がさらに設定されてもよい。

予約条件のフィールドには、例えば、図９〜図２３を用いて後述する動作例１に示すような、ユーザにより指定された会議室を検索する開催条件の変遷に関する情報が設定される。予約条件のフィールドには、具体的には、項目ごとに、過去に受け付けた項目条件を時系列順に並べた情報、および、複数の項目の中で、項目条件が初めて変更されたタイミングが早い順に、複数の項目を並べた情報が設定される。

また、予約条件のフィールドには、例えば、図２４〜図２７を用いて後述する動作例２に示すような、ユーザにより指定された会議室を検索する開催条件の変遷に関する情報が設定されてもよい。予約条件のフィールドには、具体的には、過去に受け付けた会議室を検索する開催条件を時系列順に並べた情報が設定される。

（端末装置２０１のハードウェア構成例）
次に、図７を用いて、図２に示した予約管理システム２００に含まれる端末装置２０１のハードウェア構成例について説明する。

図７は、端末装置２０１のハードウェア構成例を示すブロック図である。図７において、端末装置２０１は、ＣＰＵ７０１と、メモリ７０２と、ネットワークＩ／Ｆ７０３と、記録媒体Ｉ／Ｆ７０４と、記録媒体７０５と、ディスプレイ７０６と、入力装置７０７とを有する。また、各構成部は、バス７００によってそれぞれ接続される。

ここで、ＣＰＵ７０１は、端末装置２０１の全体の制御を司る。メモリ７０２は、例えば、ＲＯＭ、ＲＡＭおよびフラッシュＲＯＭなどを有する。具体的には、例えば、フラッシュＲＯＭやＲＯＭが各種プログラムを記憶し、ＲＡＭがＣＰＵ７０１のワークエリアとして使用される。メモリ７０２に記憶されるプログラムは、ＣＰＵ７０１にロードされることで、コーディングされている処理をＣＰＵ７０１に実行させる。

ネットワークＩ／Ｆ７０３は、通信回線を通じてネットワーク２１０に接続され、ネットワーク２１０を介して他のコンピュータに接続される。そして、ネットワークＩ／Ｆ７０３は、ネットワーク２１０と内部のインターフェースを司り、他のコンピュータからのデータの入出力を制御する。ネットワークＩ／Ｆ７０３は、例えば、モデムやＬＡＮアダプタなどである。

記録媒体Ｉ／Ｆ７０４は、ＣＰＵ７０１の制御に従って記録媒体７０５に対するデータのリード／ライトを制御する。記録媒体Ｉ／Ｆ７０４は、例えば、ディスクドライブ、ＳＳＤ、ＵＳＢポートなどである。記録媒体７０５は、記録媒体Ｉ／Ｆ７０４の制御で書き込まれたデータを記憶する不揮発メモリである。記録媒体７０５は、例えば、ディスク、半導体メモリ、ＵＳＢメモリなどである。記録媒体７０５は、端末装置２０１から着脱可能であってもよい。

ディスプレイ７０６は、カーソル、アイコンあるいはツールボックスをはじめ、文書、画像、機能情報などのデータを表示する。ディスプレイ７０６は、例えば、ＣＲＴ、液晶ディスプレイ、有機ＥＬディスプレイなどである。入力装置７０７は、文字、数字、各種指示などの入力のためのキーを有し、データの入力を行う。入力装置７０７は、キーボードやマウスなどであってもよく、また、タッチパネル式の入力パッドやテンキーなどであってもよい。

端末装置２０１は、上述した構成部の他、例えば、プリンタ、スキャナ、マイク、スピーカーなどを有してもよい。また、端末装置２０１は、記録媒体Ｉ／Ｆ７０４や記録媒体７０５を複数有していてもよい。また、端末装置２０１は、記録媒体Ｉ／Ｆ７０４や記録媒体７０５を有していなくてもよい。

（情報処理装置１００の機能的構成例）
次に、図８を用いて、情報処理装置１００の機能的構成例について説明する。

図８は、情報処理装置１００の機能的構成例を示すブロック図である。情報処理装置１００は、記憶部８００と、取得部８０１と、検索部８０２と、生成部８０３と、設定部８０４と、予約部８０５と、出力部８０６とを含む。

記憶部８００は、例えば、図３に示したメモリ３０２や記録媒体３０５などの記憶領域によって実現される。以下では、記憶部８００が、情報処理装置１００に含まれる場合について説明するが、これに限らない。例えば、記憶部８００が、情報処理装置１００とは異なる装置に含まれ、記憶部８００の記憶内容が情報処理装置１００から参照可能である場合があってもよい。

取得部８０１〜出力部８０６は、制御部の一例として機能する。取得部８０１〜出力部８０６は、具体的には、例えば、図３に示したメモリ３０２や記録媒体３０５などの記憶領域に記憶されたプログラムをＣＰＵ３０１に実行させることにより、または、ネットワークＩ／Ｆ３０３により、その機能を実現する。各機能部の処理結果は、例えば、図３に示したメモリ３０２や記録媒体３０５などの記憶領域に記憶される。

記憶部８００は、各機能部の処理において参照され、または更新される各種情報を記憶する。記憶部８００は、ユーザの名前や属性を記憶する。記憶部８００は、リソースの名称や特徴を記憶する。リソースは、例えば、会議室や競技施設などの場所、図書、音楽メディアや映像メディアなどの媒体、または、自転車や自動車などの乗り物である。記憶部８００は、例えば、会議室の名称や特徴を記憶する。会議室の特徴は、例えば、会議室の空き時間、会議室の設備、会議室の場所などである。記憶部８００は、具体的には、会議室の名称や特徴を、図３に示したリソース管理ＤＢ４００を用いて記憶する。

記憶部８００は、リソースに対する予約内容を示す予約情報を記憶し、予約状況を管理する。記憶部８００は、予約部８０５がリソースに対する予約を設定する都度、リソースに対する予約内容を示す予約情報を記憶する。記憶部８００は、具体的には、予約部８０５が会議室に対する会議の予約を設定する都度、会議室に対する会議の予約内容を示す予約情報を、図５に示した予約管理ＤＢ５００を用いて記憶する。会議の予約内容は、例えば、会議の開催時間、会議の開催者、会議の参加者、会議のタイトル、および、会議の予約が設定された会議室などである。

記憶部８００は、ユーザから指定された、リソースを検索する条件の変遷に関する情報を、ユーザに対応付けて記憶する。条件は、複数の項目の少なくともいずれかの項目に関する項目条件を含む。条件は、例えば、会議室を使用する時間を示す項目、会議室が有する設備を示す項目、または、会議室が位置する場所を示す項目に関する項目条件を含む。記憶部８００は、ユーザが複数いる場合、複数のユーザのそれぞれのユーザに対応付けて、リソースを検索する条件の変遷に関する情報を記憶する。以下の説明では、リソースを検索する条件の変遷に関する情報を、「変遷情報」と表記する場合がある。

取得部８０１は、各機能部の処理に用いられる各種情報を取得する。取得部８０１は、取得した各種情報を、記憶部８００に記憶し、または、各機能部に出力する。また、取得部８０１は、記憶部８００に記憶しておいた各種情報を、各機能部に出力してもよい。取得部８０１は、例えば、使用者の操作入力に基づき、各種情報を取得する。取得部８０１は、例えば、情報処理装置１００とは異なる装置から、各種情報を受信してもよい。

取得部８０１は、ユーザから指定された、リソースを指定する条件を受け付ける。取得部８０１は、リソースを指定する条件として、複数の項目のうち１以上の項目のそれぞれの項目の項目条件を受け付けてもよい。取得部８０１は、例えば、ユーザからの予約開始要求を受け付けた場合に、ユーザから指定された、リソースを検索する条件を受け付ける。予約開始要求は、予約を設定するリソースを検索し、リソースに対する予約を設定するための予約作業を開始することを要求する通知である。取得部８０１は、例えば、受け付けた条件で検索部８０２が検索した１以上のリソースのそれぞれのリソースが予約済みである場合に、再び、ユーザから指定された、リソースを検索する条件を受け付ける。

取得部８０１は、例えば、受け付けた条件で複数のリソースのいずれのリソースも検索部８０２により検索されない場合に、再び、ユーザから指定された、リソースを検索する条件を受け付ける。取得部８０１は、例えば、ユーザからの再検索要求を受け付けた場合に、ユーザから指定された、リソースを検索する条件を受け付ける。再検索要求は、検索部８０２が検索した結果に基づき、ユーザがいずれのリソースに対する予約も設定しないため、予約作業を続行し、リソースを再検索することを要求する通知である。

取得部８０１は、具体的には、ユーザとの対話形式で情報の入出力を制御する画面を、ユーザの端末装置２０１に表示させる。そして、取得部８０１は、具体的には、表示させた画面を介して、ユーザから指定された、リソースを検索する条件を、端末装置２０１から受信する。また、取得部８０１は、具体的には、表示させた画面を介して、予約開始要求や再検索要求を受信すると、表示させた画面を介して、ユーザから指定された、リソースを検索する条件を、端末装置２０１から受信する。取得部８０１は、具体的には、入力装置３０６を用いて、ユーザから指定された、リソースを検索する条件を受け付けてもよい。また、取得部８０１は、具体的には、入力装置３０６を用いて、予約開始要求や再検索要求を受け付け、ユーザから指定された、リソースを検索する条件を受け付けてもよい。

取得部８０１は、リソースに対するユーザによる予約を設定することを要求する設定要求を受け付ける。取得部８０１は、例えば、検索部８０２が検索した１以上のリソースのうち、ユーザにより選択されたリソースに対するユーザによる予約を設定することを要求する設定要求を受け付ける。取得部８０１は、具体的には、ユーザとの対話形式で情報の入出力を制御する画面を、ユーザの端末装置２０１に表示させる。そして、取得部８０１は、具体的には、表示させた画面を介して、検索したリソースに対するユーザによる予約を設定する設定要求を、端末装置２０１から受信する。取得部８０１は、具体的には、入力装置３０６を用いて、検索したリソースに対するユーザによる予約を設定する設定要求を受け付けてもよい。

取得部８０１は、中止指示を受け付ける。中止指示は、リソースを検索する条件の受付を中止し、予約を設定するリソースを検索し、リソースに対する予約を設定するための予約作業を中止することを要求する通知である。取得部８０１は、具体的には、ユーザとの対話形式で情報の入出力を制御する画面を、ユーザの端末装置２０１に表示させる。そして、取得部８０１は、表示させた画面を介して、中止指示を受け付ける。取得部８０１は、中止指示を受け付けた場合、ユーザから指定される、リソースを検索する条件の受付を中止する。

検索部８０２は、ユーザから指定された、リソースを検索する条件を受け付ける都度、複数のリソースのうち、受け付けた条件に合致する１以上のリソースを検索する。検索部８０２は、例えば、図４に示したリソース管理ＤＢ４００を参照して、複数のリソースのうち、受け付けた条件に合致する１以上のリソースを検索する。これにより、検索部８０２は、ユーザから指定された条件に合致し、ユーザにより予約を設定することを望まれると判断されるリソースを、ユーザに提示可能にすることができる。

生成部８０３は、変遷情報を生成し、記憶部８００に記憶する。変遷情報は、例えば、過去に受け付けた条件を時系列順に並べた情報を含む。生成部８０３は、例えば、取得部８０１が過去に受け付けた条件のうち、ユーザによる予約が設定されなかった際の条件に基づいて、変遷情報を生成し、ユーザに対応付けて記憶部８００に記憶する。

生成部８０３は、具体的には、第１の条件で検索したリソースに対するユーザによる予約が設定された場合、受け付けた条件のうち、第１の条件より前に受け付けた条件に基づいて、変遷情報を生成する。そして、生成部８０３は、具体的には、生成した変遷情報を、ユーザに対応付けて、図５に示した予約管理ＤＢ５００を用いて記憶する。これにより、生成部８０３は、ユーザが予約を設定しようとした際の意図が反映された変遷情報を記憶しておくことができる。

生成部８０３は、具体的には、第１の条件で検索したリソースに対するユーザによる予約が設定された場合、受け付けた条件のうち、第１の条件以前に受け付けた条件に基づいて、変遷情報を生成してもよい。そして、生成部８０３は、具体的には、生成した変遷情報を、ユーザに対応付けて、図５に示した予約管理ＤＢ５００を用いて記憶する。これにより、生成部８０３は、第１の条件を含めて、ユーザが予約を設定しようとした際の意図が反映された変遷情報を記憶しておくことができる。

生成部８０３は、具体的には、ユーザによる予約が設定されず、リソースを検索する条件の受付が中止された場合、受け付けた条件のうち、受付の中止までに受け付けた条件に基づいて、変遷情報を生成する。そして、生成部８０３は、具体的には、生成した変遷情報を、ユーザに対応付けて、図６に示した予約中止ＤＢ６００を用いて記憶する。これにより、生成部８０３は、リソースを検索する条件の受付が中止された場合にも、ユーザが予約を設定しようとした際の意図が反映された変遷情報を記憶しておくことができる。

生成部８０３は、具体的には、ユーザとの対話形式で情報の入出力を制御する画面の表示中に受け付けた条件のうち、第１の条件より前に受け付けた条件に基づいて、変遷情報を生成する。そして、生成部８０３は、具体的には、生成した変遷情報を、ユーザに対応付けて記憶部８００に記憶する。

生成部８０３は、具体的には、ユーザとの対話形式で情報の入出力を制御する画面の表示中に受け付けた条件のうち、リソースを検索する条件の受付の中止までに受け付けた条件に基づいて、変遷情報を生成する。そして、生成部８０３は、具体的には、生成した変遷情報を、ユーザに対応付けて記憶部８００に記憶する。

生成部８０３は、より具体的には、受け付けた条件のうち、ユーザとの対話形式で情報の入出力を制御する画面の表示から、設定要求または中止要求を受け付けるまでの条件に基づいて、変遷情報を生成する。そして、生成部８０３は、より具体的には、生成した変遷情報を、ユーザに対応付けて、図５に示した予約管理ＤＢ５００または図６に示した予約中止ＤＢ６００を用いて記憶する。これにより、生成部８０３は、画面の表示中を、ユーザの予約作業の１回分とし、予約作業の１回分単位における変遷情報を生成することができる。

生成部８０３は、具体的には、過去に受け付けた条件のうち、連続してユーザによる予約が設定されなかった２つの条件ごとの差分に基づいて、変遷情報を生成する。変遷情報は、例えば、項目ごとの項目条件の変遷、および、複数の項目の中で、項目条件が変更された順番に関する情報である。生成部８０３は、より具体的には、項目ごとに、過去に受け付けた項目条件を時系列順に並べた情報、および、複数の項目の中で、項目条件が初めて変更されたタイミングが早い順に、複数の項目を並べた情報を含む変遷情報を生成する。そして、生成部８０３は、具体的には、生成した変遷情報を、ユーザに対応付けて、図５に示した予約管理ＤＢ５００または図６に示した予約中止ＤＢ６００を用いて記憶する。これにより、生成部８０３は、変遷情報のサイズの低減化を図ることができる。

生成部８０３は、受け付けた条件のうち、ユーザによる予約を設定可能なリソースが検索されたが、ユーザによる予約が設定されなかった際の条件に基づいて、ユーザによる予約を設定しないリソースを、ユーザに対応付けて記憶部８００に記憶する。生成部８０３は、具体的には、検索された、ユーザによる予約を設定可能なリソースを、ＮＧ条件として、ユーザに対応付けて、図５に示した予約管理ＤＢ５００または図６に示した予約中止ＤＢ６００に記憶する。これにより、生成部８０３は、ユーザが予約を設定することを望まないと判断されるリソースを特定可能にすることができる。

生成部８０３は、第１の条件で検索したリソースに対するユーザによる予約が設定された場合、生成した変遷情報と、設定されたユーザによる予約とを、ユーザに対応付けて記憶部８００に記憶してもよい。生成部８０３は、例えば、生成した変遷情報と、設定されたユーザによる予約とを、ユーザに対応付けて、図５に示した予約管理ＤＢ５００を用いて記憶する。これにより、生成部８０３は、ユーザによる予約を特定可能にすることができる。

設定部８０４は、複数のリソースのいずれかのリソースに対する予約がキャンセルされた場合、複数のユーザのいずれかのユーザを、予約がキャンセルされたリソースに対する予約が設定可能であることの通知を出力する対象として設定する。以下の説明では、予約がキャンセルされたリソースに対する予約が設定可能であることの通知を出力する対象を、「出力対象」と表記する場合がある。

設定部８０４は、例えば、複数のリソースのいずれかのリソースに対する予約がキャンセルされた場合、それぞれのユーザを順に選択する。次に、設定部８０４は、選択したユーザに対応付けて記憶部８００に記憶された変遷情報から特定される条件に、予約がキャンセルされたリソースが合致するか否かを判定する。そして、設定部８０４は、例えば、合致すると判定すれば、選択したユーザを、出力対象として設定する。一方で、設定部８０４は、例えば、合致しないと判定すれば、選択したユーザを、出力対象として設定しない。

設定部８０４は、具体的には、図５に示した予約管理ＤＢ５００または図６に示した予約中止ＤＢ６００に記憶された、選択したユーザに対応付けられた変遷情報から特定される条件に、予約がキャンセルされた会議室が合致するか否かを判定する。そして、設定部８０４は、具体的には、合致すると判定すれば、選択したユーザを、出力対象として設定する。一方で、設定部８０４は、例えば、合致しないと判定すれば、選択したユーザを、出力対象として設定しない。これにより、設定部８０４は、ユーザごとに、ユーザが予約を設定することを望むと判断されるリソースがキャンセルされた場合に、ユーザを出力対象に設定することができる。

設定部８０４は、例えば、複数のユーザのうち、予約がキャンセルされたリソースと合致する条件を特定可能な、記憶部８００に記憶された変遷情報に対応付けられた、１以上のユーザを特定し、出力対象に設定する。設定部８０４は、具体的には、予約がキャンセルされた会議室と合致する条件を特定可能な、図５に示した予約管理ＤＢ５００または図６に示した予約中止ＤＢ６００に記憶された変遷情報に対応付けられた、１以上のユーザを特定し、出力対象に設定する。これにより、設定部８０４は、予約がキャンセルされたリソースに対して、新たな予約を設定することを望むと判断される１以上のユーザを特定し、出力対象に設定することができる。

設定部８０４は、例えば、特定した１以上のユーザのそれぞれのユーザに対応付けて記憶部８００に記憶された情報から特定され、予約がキャンセルされたリソースと合致する条件についての妥協度合いを示す指標値を算出する。指標値は、例えば、ユーザが最も使用したいリソースを妥協せずに検索した場合に用いられた条件を基準とした妥協度合いを示す。基準の条件は、例えば、ユーザが最初に指定した条件である。指標値は、例えば、予約がキャンセルされたリソースをユーザが使用したい優先度がどの程度高いのかを示す。指標値は、具体的には、値が小さいほど、ユーザの妥協度合いが大きいことを示し、予約がキャンセルされたリソースをユーザが使用したい優先度が高いことを示す。

そして、設定部８０４は、例えば、算出した指標値に基づいて、特定した１以上のユーザのいずれかのユーザを、出力対象に設定する。設定部８０４は、具体的には、算出した指標値が最も小さいユーザを、出力対象に設定する。これにより、設定部８０４は、予約がキャンセルされたリソースをユーザが使用したい優先度がどの程度高いのかを示す指標値を算出することができる。そして、設定部８０４は、ユーザが使用したい優先度が比較的高いと判断されるリソースがキャンセルされた場合に、ユーザを出力対象に設定することができる。

設定部８０４は、それぞれのユーザに対応付けて記憶部８００に記憶された情報から特定され、予約がキャンセルされたリソースと合致する条件を特定する。設定部８０４は、特定した条件が、項目条件が初めて変更されたタイミングが何番目に早い項目に関し、何番目に変遷した項目条件を含むかに基づいて、指標値を算出する。設定部８０４は、例えば、特定した条件に項目条件が含まれる項目が、項目条件が初めて変更されたタイミングが早い項目であるほど、指標値が小さくなるように算出する。また、設定部８０４は、特定した条件に含まれる項目条件が、受け付けた順番が早い項目条件であるほど、指標値が小さくなるように算出する。これにより、設定部８０４は、予約がキャンセルされたリソースをユーザが使用したい優先度がどの程度高いのかを示す指標値を算出することができる。

設定部８０４は、それぞれのユーザに対応付けて記憶部８００に記憶された情報から特定され、予約がキャンセルされたリソースと合致する条件が、何番目に指定された条件であるかに基づいて、指標値を算出する。設定部８０４は、例えば、予約がキャンセルされたリソースと合致する条件が、指定された順番が早い条件であるほど、ユーザが使用したい優先度が高い条件であると扱い、指標値を小さくする。これにより、設定部８０４は、予約がキャンセルされたリソースをユーザが使用したい優先度がどの程度高いのかを示す指標値を算出することができる。

設定部８０４は、例えば、予約がキャンセルされたリソースが、ユーザに対応付けて記憶部８００に記憶された情報から特定される条件に合致し、かつ、ユーザに対応付けて記憶部８００に記憶されたリソースと異なれば、ユーザを、出力対象に設定する。これにより、設定部８０４は、ユーザが予約を設定することを望まないと判断されるリソースがキャンセルされた場合には、ユーザを出力対象としないことができる。

設定部８０４は、ユーザに対応付けて記憶部８００に記憶された情報から特定される条件に、他のユーザによる予約がキャンセルされたリソースが合致すれば、ユーザに対して、予約がキャンセルされたリソースに対する予約が設定可能であることの通知を出力する。これにより、設定部８０４は、ユーザが予約をキャンセルしたリソースに関し、同じユーザに対して通知を出力しないようにすることができる。

設定部８０４は、リソースを検索する条件が変更された回数に基づいて、特定した１以上のユーザのそれぞれのユーザに対応付けて記憶部８００に記憶された情報から特定され、予約がキャンセルされたリソースと合致する条件の妥協度合いを示す指標値を算出する。これにより、設定部８０４は、リソースを検索する条件が変更された回数が比較的多く、使用したい優先度が比較的低いリソースしか予約することができなかったユーザを優先して、出力対象とすることができる。

予約部８０５は、ユーザからの設定要求を受け付けた場合、設定要求から特定される、検索部８０２が検索したリソースに対するユーザによる予約を設定する。これにより、予約部８０５は、ユーザが予約を設定することを望むリソースに対して、ユーザによる予約を設定することができる。

予約部８０５は、ユーザに対して、予約がキャンセルされたリソースに対する新たな予約が設定可能であることの通知を出力した結果、予約要求を受け付けた場合、予約がキャンセルされたリソースに対するユーザによる新たな予約を設定する。これにより、予約部８０５は、ユーザが先に予約を設定したリソースよりも、使用したい優先度が高いリソースに対するユーザによる新たな予約を設定することができる。

予約部８０５は、予約要求を受け付けた場合、予約がキャンセルされたリソースに対するユーザによる新たな予約を設定し、ユーザに対応付けて記憶部８００に記憶されたユーザによる予約をキャンセルする。これにより、予約部８０５は、ユーザが先に予約を設定したリソースよりも、使用したい優先度が高いリソースに対するユーザによる新たな予約を設定した際、ユーザが先に設定していた予約をキャンセルすることができる。

出力部８０６は、検索部８０２が検索した結果を出力する。出力部８０６は、例えば、端末装置２０１に、検索部８０２が検索した結果を送信し、ユーザとの対話形式で情報の入出力を制御する画面を介して表示させる。出力部８０６は、例えば、出力装置３０７を用いて、検索した結果を出力してもよい。これにより、出力部８０６は、ユーザが、検索した結果を把握可能にすることができる。

出力部８０６は、設定部８０４が出力対象として設定した１以上のユーザのいずれかのユーザに対して、予約がキャンセルされたリソースに対する新たな予約が設定可能であることの通知を出力する。出力部８０６は、例えば、予約がキャンセルされたリソースに対する新たな予約が設定可能であることの通知を、端末装置２０１に送信する。出力部８０６は、例えば、出力装置３０７を用いて、予約がキャンセルされたリソースに対する新たな予約が設定可能であることの通知を出力してもよい。これにより、出力部８０６は、ユーザが先に予約を設定したリソースよりも、使用したい優先度が高いリソースに対して、新たな予約が設定可能であることを、ユーザが把握可能にすることができる。

出力部８０６は、いずれかの機能部の処理結果を出力してもよい。出力形式は、例えば、ディスプレイへの表示、プリンタへの印刷出力、ネットワークＩ／Ｆ３０３による外部装置への送信、または、メモリ３０２や記録媒体３０５などの記憶領域への記憶である。これにより、出力部８０６は、各機能部の処理結果を、情報処理装置１００の利用者に通知可能にし、情報処理装置１００の利便性の向上を図ることができる。

（情報処理装置１００の動作例１）
次に、図９〜図２３を用いて、情報処理装置１００の動作例１について説明する。まず、図９および図１０を用いて、動作例１において、情報処理装置１００が開催条件を受け付ける一例について説明する。

図９および図１０は、動作例１において開催条件を受け付ける一例を示す説明図である。図９において、情報処理装置１００は、端末装置２０１に対して表示制御を行い、開催条件を入力する入力画面９００を端末装置２０１に表示させる。開催条件は、例えば、１以上の項目条件を含む。入力画面９００は、例えば、複数の入力欄９０１〜９０６と、検索ボタン９０７とを含む。

入力欄９０１は、会議のタイトルが入力される。入力欄９０２は、会議の参加者が入力される。入力欄９０３は、会議を開催する会議室に関する項目条件が入力される。会議室に関する項目条件は、会議室が位置する場所、および、会議室が有する設備に関する項目条件である。入力欄９０４は、会議の開催時間に関する項目条件として、日付に関する項目条件が入力される。入力欄９０５は、会議の開催時間に関する項目条件として、時間範囲に関する項目条件が入力される。入力欄９０６は、会議にかかる時間に関する項目条件が入力される。

端末装置２０１のユーザは、例えば、会議のタイトル、会議室に関する項目条件、会議の開催時間に関する項目条件、および、参加者などを、各種入力欄９０１〜９０６に入力し、検索ボタン９０７をクリックする。情報処理装置１００は、例えば、検索ボタン９０７のクリックにより、端末装置２０１から、会議のタイトル、会議室に関する項目条件、会議の開催時間に関する項目条件、および、参加者などを受け付け、開催条件を生成する。情報処理装置１００は、生成した開催条件に合致する会議室を検索する。次に、図１０の説明に移行する。

図１０において、情報処理装置１００は、端末装置２０１に対して表示制御を行い、検索した結果１００１を示す選択画面１０００を端末装置２０１に表示させる。検索した結果１００１は、検索された開催条件に合致する会議室の一覧である。選択画面１０００は、例えば、検索した結果１００１と、会議室を選択するための選択ボタン１００２と、再検索ボタン１００３とを含む。

端末装置２０１のユーザは、選択ボタン１００２を用いて、予約を設定する会議室を選択し、選択した会議室に対する予約の設定要求を、端末装置２０１から情報処理装置１００に送信させる。情報処理装置１００は、設定要求に応じて、選択された会議室に対する予約を設定する。

また、端末装置２０１のユーザは、検索された会議室に対して予約を設定せず、再検索ボタン１００３をクリックしてもよい。情報処理装置１００は、再検索ボタン１００３のクリックにより、再び、入力画面９００を表示し、開催条件を受け付ける。また、情報処理装置１００は、検索された会議室がすべて予約済みである場合、または、検索された会議室がない場合、再び、入力画面９００を表示し、開催条件を受け付けてもよい。これにより、情報処理装置１００は、開催条件を受け付ける都度、開催条件に合致する会議室を検索することができる。

次に、図１１〜図１３を用いて、動作例１において、情報処理装置１００が開催条件を受け付ける別の例について説明する。図１１〜図１３は、動作例１において開催条件を受け付ける別の例を示す説明図である。

図１１〜図１３において、情報処理装置１００は、ユーザとの対話形式で、情報の入出力を制御するチャットボットを実現し、開催条件を受け付ける。図１１において、情報処理装置１００は、端末装置２０１に対して表示制御を行い、チャットボットを実現するブラウザ画面１１００を表示させる。

ブラウザ画面１１００は、例えば、情報処理装置１００からのメッセージと、端末装置２０１のユーザが入力したメッセージとを表示する会話表示領域１１１０を含む。会話表示領域１１１０は、例えば、端末装置２０１のユーザがメッセージを入力する入力欄１１１１と、入力したメッセージを確定して情報処理装置１００に送信する送信ボタン１１１２とを含む。また、ブラウザ画面１１００は、チャットボットを介して設定された会議の予約内容を表示する予約表示領域１１２０を含む。予約表示領域１１２０は、端末装置２０１におけるユーザの操作入力に基づき、会議の予約内容を修正可能にされてもよい。

図１１の例では、情報処理装置１００は、開催条件の入力を促すメッセージを、会話表示領域１１１０に表示し、開催条件の入力を待つ。開催条件は、例えば、１以上の項目条件を含む。１以上の項目条件は、１度に入力されなくてもよく、ユーザとの対話形式で、複数回に分けて入力されてもよい。端末装置２０１のユーザは、例えば、会議のタイトル、会議の開催時間に関する項目条件、開催者や参加者などを含むメッセージを入力欄１１１１に入力し、送信ボタン１１１２をクリックする。情報処理装置１００は、例えば、送信ボタン１１１２のクリックにより、端末装置２０１から、会議のタイトル、会議の開催時間に関する項目条件、開催者や参加者などを含むメッセージを受け付ける。次に、図１２の説明に移行する。

図１２の例では、情報処理装置１００は、会議の開催時間に関する項目条件を修正するか否かを確認するメッセージを、会話表示領域１１１０に表示する。端末装置２０１のユーザは、「修正する」と入力欄１１１１に入力し、送信ボタン１１１２をクリックする。情報処理装置１００は、送信ボタン１１１２のクリックにより、端末装置２０１から、「修正する」と受け付けたため、会議の開催時間の修正を促すメッセージを、会話表示領域１１１０に表示する。端末装置２０１のユーザは、会議の開催時間に関する項目条件を、入力欄１１１１に入力し、送信ボタン１１１２をクリックする。情報処理装置１００は、送信ボタン１１１２のクリックにより、端末装置２０１から、会議の開催時間に関する項目条件を受け付ける。

また、情報処理装置１００は、会議の開催場所に関する項目条件の入力を促すメッセージを、会話表示領域１１１０に表示する。端末装置２０１のユーザは、会議の開催場所に関する項目条件を入力欄１１１１に入力し、送信ボタン１１１２をクリックする。情報処理装置１００は、送信ボタン１１１２のクリックにより、端末装置２０１から、会議の開催場所に関する項目条件を受け付ける。このように、情報処理装置１００は、端末装置２０１におけるユーザの操作入力に基づき、会議の開催条件として１以上の項目条件を、端末装置２０１から受け付ける。次に、図１３の説明に移行する。

図１３の例では、情報処理装置１００は、受け付けた各種項目条件に合致する会議室を検索し、検索した結果を含むメッセージを、会話表示領域１１１０に表示し、予約を設定する会議室の選択、または、開催条件の再入力を待つ。端末装置２０１のユーザは、予約を設定する会議室を選択し、決定ボタンまたは入力欄１１１１により、選択した会議室に対する予約の設定要求を、端末装置２０１から情報処理装置１００に送信させる。情報処理装置１００は、設定要求に応じて、会議室に対する予約を設定する。

また、端末装置２０１のユーザは、検索された会議室に対して予約を設定せず、入力欄１１１１により、開催条件を再入力してもよい。また、情報処理装置１００は、検索された会議室が予約済みである場合、または、検索された会議室がない場合、開催条件の再入力を促すメッセージを、会話表示領域１１１０に表示し、開催条件の再入力を待ってもよい。これにより、情報処理装置１００は、開催条件を受け付ける都度、開催条件に合致する会議室を検索することができる。

次に、図１４および図１５を用いて、動作例１において、情報処理装置１００が会議室に対するユーザによる予約を設定した後において、情報処理装置１００がユーザに対する通知を出力する一例について説明する。

図１４および図１５は、動作例１においてユーザによる予約を設定した後においてユーザに対する通知を出力する一例を示す説明図である。図１４において、情報処理装置１００は、端末装置２０１におけるユーザの操作入力に基づき、予約開始要求を端末装置２０１から受け付け、予約作業を開始する。予約作業は、例えば、上述した入力画面９００またはブラウザ画面１１００を介して実現される。

ユーザは、矢印１４０１に示すように、１回目の検索にかかる開催条件を、端末装置２０１から情報処理装置１００に送信させる。情報処理装置１００は、開催条件を受け付け、開催条件を蓄積し、開催条件に合致する会議室を検索する。情報処理装置１００は、矢印１４０２に示すように、検索した結果、検索された会議室が０件である通知を、端末装置２０１に送信し、ユーザに参照可能にする。ユーザは、矢印１４０３に示すように、２回目の検索にかかる開催条件を、端末装置２０１から情報処理装置１００に送信させる。情報処理装置１００は、開催条件を受け付け、開催条件を蓄積し、開催条件に合致する会議室を検索する。情報処理装置１００は、矢印１４０４に示すように、検索した結果が、会議卓１と会議卓２との２件である通知を、端末装置２０１に送信し、ユーザに参照可能にする。

ここで、ユーザは、矢印１４０５に示すように、会議卓１と会議卓２とのいずれに対しても、会議の予約を設定せずに却下する。そして、ユーザは、矢印１４０６に示すように、３回目の検索にかかる開催条件を、端末装置２０１から情報処理装置１００に送信させる。情報処理装置１００は、開催条件を受け付け、開催条件を蓄積する。ここで、情報処理装置１００は、会議の予約が設定されず、新たな開催条件を受け付けたため、会議卓１と会議卓２とをＮＧ条件として、予約管理ＤＢ５００に記憶する。ＮＧ条件を登録する一例については、例えば、図１８および図１９を用いて後述する。また、情報処理装置１００は、開催条件に合致する会議室を検索し、矢印１４０７に示すように、検索した結果が、会議室Ａの１件である通知を、端末装置２０１に送信し、ユーザに参照可能にする。

ユーザは、矢印１４０８に示すように、会議室Ａに対して会議の予約を設定することの設定要求を、端末装置２０１から情報処理装置１００に送信させる。情報処理装置１００は、設定要求を受け付けると、矢印１４０９に示すように、会議室Ａに対して会議の予約を設定し、予約内容を予約管理ＤＢ５００に記憶する。また、情報処理装置１００は、会議の予約が設定されたため、蓄積した開催条件に基づき、変遷情報を生成し、予約管理ＤＢ５００に記憶する。変遷情報を記憶する詳細については、例えば、図２０〜図２２を用いて後述する。次に、図１５の説明に移行する。

図１５において、情報処理装置１００は、「６階会議室Ａに対する○月△日の９：００〜１１：００の会議の予約」がキャンセルされたことを検出し、予約内容をキャンセル事例１５００として記憶する。情報処理装置１００は、キャンセル事例１５００が、予約管理ＤＢ５００に記憶された変遷情報に合致するか否かを判定する。

ここで、情報処理装置１００は、例えば、レコード５０１の変遷情報が示す時間に関する項目条件「１０：００〜１１：００」および場所に関する項目条件「６階の部屋」に、キャンセル事例１５００が合致すると判定する。このため、情報処理装置１００は、レコード５０１のタイトル、および、開始時間や終了時間などに基づいて、メッセージ１５１０を生成し、レコード５０１の開催者から特定されるユーザの端末装置に送信する。メッセージ１５１０は、会議の予約がキャンセルされた「６階会議室Ａ」に対して、新たにユーザによる予約が設定可能であることを示す。

これにより、情報処理装置１００は、会議の予約がキャンセルされた会議室を使用したい優先度が比較的高いユーザに対して、会議室に対する予約がキャンセルされ、会議室に対して新たな予約を設定可能であることの通知を出力することができる。これにより、情報処理装置１００は、ユーザが使用したい優先度が高い会議室に対して予約を設定しやすくすることができ、ユーザの利便性を向上させることができる。また、情報処理装置１００は、ユーザが使用したい優先度が高い会議室を手動で登録しておかなくても、会議室に対する会議の予約がキャンセルされたことの通知の出力対象となるユーザを絞り込むことができ、ユーザの作業負担の増大化を抑制することができる。

また、情報処理装置１００は、通知を出力したユーザによる、キャンセルされた会議室に対する新たな予約を設定した場合、予約管理ＤＢ５００を参照して、先に設定されていた、通知を出力したユーザによる会議の予約を特定し、キャンセルすることができる。このため、情報処理装置１００は、会議の予約が新たにキャンセルされた会議室についての通知を、他のユーザに対して、さらに出力することができる。結果として、情報処理装置１００は、複数のユーザの全体で、それぞれのユーザが、使用したい優先度が比較的高いリソースに対して予約を設定可能にすることができ、複数のリソースの全体が有効に活用されるようにすることができる。

次に、図１６および図１７を用いて、動作例１において、情報処理装置１００が会議室に対するユーザによる予約を中止した後において、情報処理装置１００がユーザに対する通知を出力する一例について説明する。

図１６および図１７は、動作例１においてユーザによる予約を中止した後においてユーザに対する通知を出力する一例を示す説明図である。図１６において、情報処理装置１００は、端末装置２０１におけるユーザの操作入力に基づき、予約開始要求を端末装置２０１から受け付け、予約作業を開始する。予約作業は、例えば、上述した入力画面９００またはブラウザ画面１１００を介して実現される。

ユーザは、矢印１６０１に示すように、１回目の検索にかかる開催条件を、端末装置２０１から情報処理装置１００に送信させる。情報処理装置１００は、開催条件を受け付け、開催条件を蓄積し、開催条件に合致する会議室を検索する。情報処理装置１００は、矢印１６０２に示すように、検索した結果、検索された会議室が０件である通知を、端末装置２０１に送信し、ユーザに参照可能にする。ユーザは、矢印１６０３に示すように、２回目の検索にかかる開催条件を、端末装置２０１から情報処理装置１００に送信させる。情報処理装置１００は、開催条件を受け付け、開催条件を蓄積し、開催条件に合致する会議室を検索する。情報処理装置１００は、矢印１６０４に示すように、検索した結果が、会議卓１と会議卓２との２件である通知を、端末装置２０１に送信し、ユーザに参照可能にする。

ここで、ユーザは、矢印１６０５に示すように、会議卓１と会議卓２とのいずれに対しても、会議の予約を設定せずに却下する。そして、ユーザは、矢印１６０６に示すように、３回目の検索にかかる開催条件を、端末装置２０１から情報処理装置１００に送信させる。情報処理装置１００は、開催条件を受け付け、開催条件を蓄積する。ここで、情報処理装置１００は、会議の予約が設定されず、新たな開催条件を受け付けたため、会議卓１と会議卓２とをＮＧ条件として、予約管理ＤＢ５００に記憶する。ＮＧ条件を登録する一例については、例えば、図１８および図１９を用いて後述する。また、情報処理装置１００は、開催条件に合致する会議室を検索し、矢印１６０７に示すように、検索された会議室が０件である通知を、端末装置２０１に送信し、ユーザに参照可能にする。

ユーザは、会議室の予約を諦め、矢印１６０８に示すように、予約作業の中止要求を、端末装置２０１から情報処理装置１００に送信させる。情報処理装置１００は、中止要求を受け付けると、矢印１６０９に示すように、蓄積した開催条件に基づき、変遷情報を生成し、予約中止ＤＢ６００に記憶する。変遷情報を記憶する詳細については、例えば、図２０〜図２２を用いて後述する。情報処理装置１００は、予約管理ＤＢ５００に記憶されたＮＧ条件を、予約中止ＤＢ６００にコピーしてもよい。次に、図１７の説明に移行する。

図１７において、情報処理装置１００は、「６階会議室Ａに対する○月△日の９：００〜１１：００の会議の予約」がキャンセルされたことを検出し、予約内容をキャンセル事例１７００として記憶する。情報処理装置１００は、キャンセル事例１７００が、予約中止ＤＢ６００に記憶された変遷情報に合致するか否かを判定する。

ここで、情報処理装置１００は、例えば、レコード６０１の変遷情報が示す時間に関する項目条件「１０：００〜１１：００」および場所に関する項目条件「６階の部屋」に、キャンセル事例１７００が合致すると判定する。このため、情報処理装置１００は、レコード６０１のタイトルなどに基づいて、メッセージ１７１０を生成し、レコード６０１の開催者から特定されるユーザの端末装置２０１に送信する。メッセージ１７１０は、会議の予約がキャンセルされた「６階会議室Ａ」に対して、新たにユーザによる予約が設定可能であることを示す。

これにより、情報処理装置１００は、過去に会議の予約を諦めた、会議の予約がキャンセルされた会議室を使用したい優先度が比較的高いユーザに対して、会議室に対して新たな予約を設定可能であることの通知を出力することができる。これにより、情報処理装置１００は、ユーザの作業負担の増大化を抑制しつつ、ユーザが使用したい優先度が高い会議室に対して予約を設定しやすくすることができ、ユーザの利便性を向上させることができる。また、情報処理装置１００は、ユーザが使用したい優先度が高い会議室を手動で登録しておかなくても、会議室に対する会議の予約がキャンセルされたことの通知の出力対象となるユーザを絞り込むことができ、ユーザの作業負担の増大化を抑制することができる。

次に、図１８および図１９を用いて、動作例１においてＮＧ条件を登録する一例について説明する。

図１８および図１９は、動作例１においてＮＧ条件を登録する一例を示す説明図である。図１８の例では、情報処理装置１００は、図１０と同様に、端末装置２０１に対して表示制御を行い、検索した結果１００１を示す選択画面１０００を端末装置２０１に表示させたとする。検索した結果１００１は、６階会議卓１と６階会議卓２とを、まだ予約が設定されておらず、新たに予約を設定可能な会議室として示す。端末装置２０１のユーザは、検索された会議室に対して予約を設定せず、再検索ボタン１００３をクリックしたとする。

この場合、情報処理装置１００は、再検索ボタン１００３のクリックにより、６階会議卓１と６階会議卓２とが、予約が設定可能にもかかわらず予約が設定されなかったことを検出する。ここで、予約が設定可能にもかかわらず、予約が設定されなかったことは、ユーザが、６階会議卓１と６階会議卓２とに対して、予約を設定したいと考えていないことを示す。従って、情報処理装置１００は、「６階会議卓１」と「６階会議卓２」とを、ＮＧ条件として予約管理ＤＢ５００に記憶する。

ここでは、情報処理装置１００が、「６階会議卓１」と「６階会議卓２」とを、開催時間に関する情報を含めずに、ＮＧ条件として予約管理ＤＢ５００に記憶する場合について説明したが、これに限らない。例えば、情報処理装置１００が、「６／２２ １０：００〜１１：００ ６階会議卓１」と「６／２２ １０：００〜１１：００ ６階会議卓２」とを、ＮＧ条件として記憶する場合があってもよい。次に、図１９の説明に移行する。

図１９において、情報処理装置１００は、「６階会議卓１に対する○月△日の９：００〜１１：００の会議の予約」がキャンセルされたことを検出し、予約内容をキャンセル事例１９００として記憶する。情報処理装置１００は、キャンセル事例１９００が、予約管理ＤＢ５００に記憶された変遷情報に合致するか否かを判定する。また、情報処理装置１００は、キャンセル事例１９００が、予約管理ＤＢ５００に記憶されたＮＧ条件に合致するか否かを判定する。

ここで、情報処理装置１００は、例えば、レコード５０１の変遷情報が示す時間に関する項目条件「１０：００〜１１：００」および場所に関する項目条件「６階の部屋」に、キャンセル事例１９００が合致すると判定する。また、情報処理装置１００は、例えば、ＮＧ条件「６階会議卓１」に、キャンセル事例１９００が合致すると判定する。このため、情報処理装置１００は、会議の予約がキャンセルされた「６階会議卓１」に対しては、ユーザが会議の予約を設定したいと考えていないと判断する。このため、情報処理装置１００は、レコード５０１の開催者から特定されるユーザに対するメッセージを生成しないようにする。

これにより、情報処理装置１００は、会議の予約がキャンセルされた会議室を使用したいと考えていないと判断されるユーザに対して、会議室に対して新たな予約を設定可能であることの通知を出力しないことができる。このため、情報処理装置１００は、ユーザが、使用したいと考えていない会議室についての通知を受け付けることを防止することができ、ユーザの作業負担の増大化を抑制し、ユーザの利便性を向上させることができる。

以上の説明では、情報処理装置１００が、キャンセル事例１７００と合致する変遷情報が設定された、予約管理ＤＢ５００または予約中止ＤＢ６００のレコードに基づいて特定されたユーザに、通知を出力する場合について説明したが、これに限らない。例えば、情報処理装置１００が、特定されたユーザが複数存在すれば、特定されたユーザの中から、通知を出力する対象とするユーザをさらに絞り込む場合があってもよい。次に、図２０〜図２３の説明に移行し、情報処理装置１００が、特定されたユーザの中から、通知を出力する対象とするユーザをさらに絞り込む場合について説明する。

図２０〜図２２は、動作例１において開催条件の変遷に関する情報を記憶する詳細を示す説明図である。図２０〜図２２において、情報処理装置１００は、開催条件２００１〜２００６を順に受け付けた場合について説明する。この場合、情報処理装置１００は、変遷情報２０１０を生成することになる。変遷情報２０１０は、項目ごとに、過去に受け付けた項目条件を時系列順に並べた情報、および、項目条件が初めて変更されたタイミングが早い順に、複数の項目を並べた情報を含む。次に、図２１の説明に移行し、変遷情報２０１０を生成する手順について説明する。

図２１において、情報処理装置１００は、１番目の開催条件２００１に基づいて、項目ごとに、開催条件２００１に含まれる項目条件を、変遷情報２１０１として登録する。情報処理装置１００は、２番目の開催条件２００２に基づいて、変遷情報２１０１を変遷情報２１０２に更新する。情報処理装置１００は、例えば、１番目の開催条件２００１と２番目の開催条件２００２との差分に基づいて、日時条件１が「６／２２ ＡＭ」から「６／２２ ＰＭ」に変更されたことを検出する。このため、情報処理装置１００は、日時条件１の列の先頭に、項目条件が初めて変更された順番を示す「１」を付与し、日時条件１の列の「６／２２ ＡＭ」の後ろに「６／２２ ＰＭ」を設定する。情報処理装置１００は、同様に、３番目の開催条件２００３に基づいて、変遷情報２１０２を変遷情報２１０３に更新する。次に、図２２の説明に移行する。

図２２において、情報処理装置１００は、同様に、４番目の開催条件２００４に基づいて、変遷情報２１０３を変遷情報２２０１に更新する。情報処理装置１００は、同様に、５番目の開催条件２００５に基づいて、変遷情報２２０１を変遷情報２２０２に更新する。情報処理装置１００は、同様に、６番目の開催条件２００６に基づいて、変遷情報２２０２を変遷情報２２０３に更新する。これにより、情報処理装置１００は、変遷情報２０１０を生成することができる。次に、図２３の説明に移行する。

図２３は、動作例１において通知を出力する対象となるユーザを特定する詳細を示す説明図である。図２３において、情報処理装置１００は、「６／２２ ＡＭ、１時間、川崎研５Ｆ、個室、大型ディスプレイの会議室に対する会議の予約」がキャンセルされたことを検出し、予約内容をキャンセル事例２３００として記憶する。情報処理装置１００は、キャンセル事例２３００が、予約管理ＤＢ５００に記憶された変遷情報に合致するか否かを判定する。

ここで、情報処理装置１００が、変遷情報２３０１〜２３０３について合致すると判定したとする。この場合、情報処理装置１００は、変遷情報２３０１〜２３０３に基づいて、指標値を算出する。そして、情報処理装置１００は、算出した指標値に基づいて、メッセージを出力するユーザを特定する。

情報処理装置１００は、例えば、変遷情報２３０１から、キャンセル事例２３００に合致する項目条件を検索する。そして、情報処理装置１００は、検索した項目条件が、初めて項目条件が変更されたタイミングが何番目の項目に関する項目条件であり、何番目に指定された項目条件であるかに基づいて、指標値を算出する。以下の説明では、初めて項目条件が変更されたタイミングを、「初変更タイミング」と表記する場合がある。

情報処理装置１００は、具体的には、変遷情報２３０１に対し、初変更タイミングに応じて、項目ごとに配点を決定する。情報処理装置１００は、項目条件の変更がない項目の配点を５点とし、項目条件の変更がある項目の配点を、５点を基準に、初変更タイミングが遅い方から１点ずつ減らして決定する。また、情報処理装置１００は、変遷情報２３０１から、項目条件「６／２２ ＡＭ」、「１時間」、「川崎研５Ｆ」、「個室」、「大型ディスプレイ」を検索する。

情報処理装置１００は、検索した項目条件「６／２２ ＡＭ」が、初変更タイミングが１番目である項目に関する項目条件であり、項目単位では１番目に指定された項目条件であると特定する。情報処理装置１００は、項目単位で１番目に指定された項目条件であれば、項目単位ではユーザが最も望ましいと考える項目条件であり、妥協していない項目条件であると判断する。情報処理装置１００は、妥協していない項目条件であるため、項目に設定された配点に関わらず、指標値に点数を加算しない。

情報処理装置１００は、検索した項目条件「１時間」が、初変更タイミングが２番目である項目に関する項目条件であり、項目単位では２番目に指定された項目条件であると特定する。情報処理装置１００は、項目単位で２番目に指定された項目条件であれば、項目単位ではユーザが最も望ましいと考える項目条件から１つ妥協した項目条件であると判断する。このため、情報処理装置１００は、妥協した項目条件であるため、指標値に、項目に設定された配点２点を加算する。また、情報処理装置１００は、２つ以上妥協した項目条件であれば、妥協した回数から１を減算した分の点数を、さらに、指標値に加算してもよい。このように、情報処理装置１００は、変遷情報２３０１から指標値「５点」を算出する。

同様に、情報処理装置１００は、変遷情報２３０２から指標値「８点」を算出する。同様に、情報処理装置１００は、変遷情報２３０３から指標値「４点」を算出する。そして、情報処理装置１００は、指標値が最も小さい変遷情報２３０３に対応するユーザを、メッセージを出力するユーザとして特定する。

これにより、情報処理装置１００は、会議の予約がキャンセルされた会議室を使用したい優先度が比較的高いユーザに対して、会議室に対して新たな予約を設定可能であることの通知を出力することができる。これにより、情報処理装置１００は、ユーザの作業負担の増大化を抑制しつつ、ユーザが使用したい優先度が高い会議室に対して予約を設定しやすくすることができ、ユーザの利便性を向上させることができる。また、情報処理装置１００は、ユーザが使用したい優先度が高い会議室を手動で登録しておかなくても、会議室に対する会議の予約がキャンセルされたことの通知の出力対象となるユーザを絞り込むことができ、ユーザの作業負担の増大化を抑制することができる。

ここで、情報処理装置１００が、指標値が最も小さい変遷情報２３０３に対応するユーザに対して、メッセージを出力したが、キャンセル事例２３００にかかる会議室に対して予約が設定されない場合がある。この場合、情報処理装置１００は、指標値が２番目に小さい変遷情報２３０１に対応するユーザに対して、メッセージを出力するようにしてもよい。このように、情報処理装置１００は、指標値が小さい順に、変遷情報に対応するユーザに対して、メッセージを出力するようにしてもよい。

以上の説明では、情報処理装置１００が、予約管理ＤＢ５００および予約中止ＤＢ６００を用いる場合について説明したが、これに限らない。例えば、情報処理装置１００が、予約管理ＤＢ５００を用いない場合があってもよい。また、例えば、情報処理装置１００が、予約中止ＤＢ６００を用いない場合があってもよい。

また、情報処理装置１００が、変遷情報に基づいて指標値を算出する場合について説明したが、これに限らない。例えば、情報処理装置１００が、変遷情報と、ユーザが開催条件を変更した回数とに基づいて、指標値を算出する場合があってもよい。この場合、例えば、情報処理装置１００は、ユーザが開催条件を変更した回数が多いほど、指標値が小さくなるように算出する。

ここでは、情報処理装置１００が、受け付けた開催条件に基づいて、変遷情報を生成する場合について説明したが、これに限らない。例えば、情報処理装置１００が、受け付けた開催条件のうち、会議の予約を設定可能な会議室が検索されたが会議の予約が設定されなかった際の開催条件を除外して、変遷情報を生成する場合があってもよい。

（情報処理装置１００の動作例２）
次に、図２４〜図２７を用いて、情報処理装置１００の動作例２について説明する。動作例２は、動作例１とは変遷情報の形式が異なる一例である。

まず、図２４および図２５を用いて、動作例２において、情報処理装置１００が会議室に対するユーザによる予約を設定した後において、情報処理装置１００がユーザに対する通知を出力する一例について説明する。

図２４および図２５は、動作例２においてユーザによる予約を設定した後においてユーザに対する通知を出力する一例を示す説明図である。図２４において、情報処理装置１００は、開催条件を受け付けた後、予約が設定された場合、動作例１とは異なり、過去に受け付けた開催条件を時系列順に並べた変遷情報を生成し、予約管理ＤＢ２４００に記憶する。次に、図２５の説明に移行する。

図２５において、情報処理装置１００は、「６階会議室Ａに対する○月△日の９：００〜１１：００の会議の予約」がキャンセルされたことを検出し、予約内容をキャンセル事例２５００として記憶する。情報処理装置１００は、キャンセル事例２５００が、予約管理ＤＢ２４００に記憶された変遷情報に合致するか否かを判定する。

ここで、情報処理装置１００は、例えば、レコード２４０１の変遷情報が示す時間に関する開催条件「○月△日、１０：００〜１１：００、６階の部屋」に、キャンセル事例２５００が合致すると判定する。このため、情報処理装置１００は、レコード２４０１のタイトル、および、開始時間や終了時間などに基づいて、メッセージ２５１０を生成し、レコード２４０１の開催者から特定されるユーザの端末装置２０１に送信する。メッセージ２５１０は、会議の予約がキャンセルされた「６階会議室Ａ」に対して、新たにユーザによる予約が設定可能であることを示す。

これにより、情報処理装置１００は、会議の予約がキャンセルされた会議室を使用したい優先度が比較的高いユーザに対して、会議室に対する予約がキャンセルされ、会議室に対して新たな予約を設定可能であることの通知を出力することができる。これにより、情報処理装置１００は、ユーザが使用したい優先度が高い会議室に対して予約を設定しやすくすることができ、ユーザの利便性を向上させることができる。また、情報処理装置１００は、ユーザが使用したい優先度が高い会議室を手動で登録しておかなくても、会議室に対する会議の予約がキャンセルされたことの通知の出力対象となるユーザを絞り込むことができ、ユーザの作業負担の増大化を抑制することができる。

また、情報処理装置１００は、通知を出力したユーザによる、キャンセルされた会議室に対する新たな予約を設定した場合、予約管理ＤＢ２４００を参照して、先に設定されていた、通知を出力したユーザによる会議の予約を特定し、キャンセルすることができる。このため、情報処理装置１００は、会議の予約が新たにキャンセルされた会議室についての通知を、他のユーザに対して、さらに出力することができる。結果として、情報処理装置１００は、複数のユーザの全体で、それぞれのユーザが、使用したい優先度が比較的高いリソースに対して予約を設定可能にすることができ、複数のリソースの全体が有効に活用されるようにすることができる。

ここでは、情報処理装置１００が、開催条件を受け付けた後、予約が設定された場合、変遷情報を生成し、予約管理ＤＢ２４００に記憶する場合について説明したが、これに限らない。例えば、情報処理装置１００が、開催条件を受け付けた後、予約が中止された場合、過去に受け付けた開催条件を時系列順に並べた変遷情報を生成し、予約中止ＤＢ６００に記憶する場合について、同様に、メッセージを端末装置２０１に送信してもよい。次に、図２６および図２７の説明に移行し、情報処理装置１００が、特定されたユーザの中から、通知を出力する対象とするユーザをさらに絞り込む場合について説明する。

図２６は、動作例２において開催条件の変遷に関する情報を記憶する詳細を示す説明図である。図２６において、情報処理装置１００は、開催条件２６０１〜２６０６を順に受け付けた場合について説明する。この場合、情報処理装置１００は、変遷情報２６１０を生成することになる。変遷情報２６１０は、過去に受け付けた開催条件を時系列順に並べた情報である。次に、図２７の説明に移行する。

図２７は、動作例２において通知を出力する対象となるユーザを特定する詳細を示す説明図である。図２７において、情報処理装置１００は、「６／２２ ＡＭ、１時間、川崎研５Ｆ、個室、大型ディスプレイの会議室に対する会議の予約」がキャンセルされたことを検出し、予約内容をキャンセル事例２７００として記憶する。情報処理装置１００は、キャンセル事例２７００が、予約管理ＤＢ５００に記憶された変遷情報に合致するか否かを判定する。

ここで、情報処理装置１００が、変遷情報２７０１〜２７０３について合致すると判定したとする。ここで、キャンセル事例２７００の「１時間」は、項目条件「２時間」に包含されるため、項目条件「２時間」に合致すると判定される。この場合、情報処理装置１００は、変遷情報２７０１〜２７０３に基づいて、指標値を算出する。そして、情報処理装置１００は、算出した指標値に基づいて、メッセージを出力するユーザを特定する。

情報処理装置１００は、例えば、変遷情報２７０１から、キャンセル事例２７００に合致する開催条件を検索する。そして、情報処理装置１００は、検索した開催条件が、何番目に指定された開催条件であるかに基づいて、指標値を算出する。情報処理装置１００は、具体的には、変遷情報２７０１に対し、検索した開催条件が、４番目に指定された開催条件であるため、指標値を、番号と同じ「４点」として算出する。

同様に、情報処理装置１００は、変遷情報２７０２から指標値「１点」を算出する。同様に、情報処理装置１００は、変遷情報２７０３から指標値「３点」を算出する。そして、情報処理装置１００は、指標値が最も小さい変遷情報２７０２に対応するユーザを、メッセージを出力するユーザとして特定する。

これにより、情報処理装置１００は、会議の予約がキャンセルされた会議室を使用したい優先度が比較的高いユーザに対して、会議室に対して新たな予約を設定可能であることの通知を出力することができる。これにより、情報処理装置１００は、ユーザの作業負担の増大化を抑制しつつ、ユーザが使用したい優先度が高い会議室に対して予約を設定しやすくすることができ、ユーザの利便性を向上させることができる。また、情報処理装置１００は、ユーザが使用したい優先度が高い会議室を手動で登録しておかなくても、会議室に対する会議の予約がキャンセルされたことの通知の出力対象となるユーザを絞り込むことができ、ユーザの作業負担の増大化を抑制することができる。

ここで、情報処理装置１００が、指標値が最も小さい変遷情報２７０２に対応するユーザに対して、メッセージを出力したが、キャンセル事例２７００にかかる会議室に対して予約が設定されない場合がある。この場合、情報処理装置１００は、指標値が２番目に小さい変遷情報２７０３に対応するユーザに対して、メッセージを出力するようにしてもよい。このように、情報処理装置１００は、指標値が小さい順に、変遷情報に対応するユーザに対して、メッセージを出力するようにしてもよい。

以上の説明では、情報処理装置１００が、予約管理ＤＢ５００および予約中止ＤＢ６００を用いる場合について説明したが、これに限らない。例えば、情報処理装置１００が、予約管理ＤＢ５００を用いない場合があってもよい。また、例えば、情報処理装置１００が、予約中止ＤＢ６００を用いない場合があってもよい。

また、情報処理装置１００が、変遷情報に基づいて指標値を算出する場合について説明したが、これに限らない。例えば、情報処理装置１００が、変遷情報と、ユーザが開催条件を変更した回数とに基づいて、指標値を算出する場合があってもよい。この場合、情報処理装置１００は、ユーザが開催条件を変更した回数が多いほど、指標値が小さくなるように算出する。

（登録処理手順）
次に、図２８を用いて、情報処理装置１００が実行する、登録処理手順の一例について説明する。登録処理は、例えば、図３に示したＣＰＵ３０１と、メモリ３０２や記録媒体３０５などの記憶領域と、ネットワークＩ／Ｆ３０３とによって実現される。

図２８は、登録処理手順の一例を示すフローチャートである。図２８において、情報処理装置１００は、入力された開催条件を受信する（ステップＳ２８０１）。そして、情報処理装置１００は、ステップＳ２８０２の処理に移行する。

ステップＳ２８０２では、情報処理装置１００は、受信した開催条件に合致する開催場所が存在するか否かを判定する（ステップＳ２８０２）。ここで、開催条件に合致する開催場所が存在する場合（ステップＳ２８０２：Ｙｅｓ）、情報処理装置１００は、ステップＳ２８０７の処理に移行する。一方で、開催条件に合致する開催場所が存在しない場合（ステップＳ２８０２：Ｎｏ）、情報処理装置１００は、ステップＳ２８０３の処理に移行する。

ステップＳ２８０３では、情報処理装置１００は、受信した開催条件を予約条件として蓄積する（ステップＳ２８０３）。そして、情報処理装置１００は、ステップＳ２８０４の処理に移行する。

ステップＳ２８０４では、情報処理装置１００は、開催条件の再入力指示を出力する（ステップＳ２８０４）。そして、情報処理装置１００は、開催条件が再入力されたか否かを判定する（ステップＳ２８０５）。ここで、開催条件が再入力された場合（ステップＳ２８０５：Ｙｅｓ）、情報処理装置１００は、ステップＳ２８０２の処理に戻る。一方で、開催条件が再入力されていない場合（ステップＳ２８０５：Ｎｏ）、情報処理装置１００は、ステップＳ２８０６の処理に移行する。

ステップＳ２８０６では、情報処理装置１００は、蓄積された１以上の予約条件に基づいて、予約条件の変遷を示す情報を生成し、予約中止ＤＢ６００に記憶する（ステップＳ２８０６）。そして、情報処理装置１００は、登録処理を終了する。

ステップＳ２８０７では、情報処理装置１００は、受信した開催条件に合致する１以上の開催場所をユーザに通知する（ステップＳ２８０７）。そして、情報処理装置１００は、予約先として、受信した開催条件に合致するいずれかの開催場所が選択されたか否かを判定する（ステップＳ２８０８）。ここで、開催場所が選択された場合（ステップＳ２８０８：Ｙｅｓ）、情報処理装置１００は、ステップＳ２８１０の処理に移行する。一方で、開催場所が選択されていない場合（ステップＳ２８０８：Ｎｏ）、情報処理装置１００は、ステップＳ２８０９の処理に移行する。

ステップＳ２８０９では、情報処理装置１００は、受信した開催条件に合致する開催場所を、ＮＧ条件として予約管理ＤＢ５００に記憶する（ステップＳ２８０９）。そして、情報処理装置１００は、ステップＳ２８０４の処理に移行する。

ステップＳ２８１０では、情報処理装置１００は、受信した開催条件を予約条件として蓄積し、蓄積された１以上の予約条件に基づいて、予約条件の変遷を示す情報を生成し、予約管理ＤＢ５００に記憶する（ステップＳ２８１０）。

次に、情報処理装置１００は、予約先として選択された開催場所に対する予約情報を、予約管理ＤＢ５００に記憶する（ステップＳ２８１１）。そして、情報処理装置１００は、登録処理を終了する。

（推薦処理手順）
次に、図２９および図３０を用いて、情報処理装置１００が実行する、推薦処理手順の一例について説明する。推薦処理は、例えば、図３に示したＣＰＵ３０１と、メモリ３０２や記録媒体３０５などの記憶領域と、ネットワークＩ／Ｆ３０３とによって実現される。

図２９および図３０は、推薦処理手順の一例を示すフローチャートである。図２９において、情報処理装置１００は、キャンセル事例のリストを取得する（ステップＳ２９０１）。そして、情報処理装置１００は、ステップＳ２９０２の処理に移行する。

ステップＳ２９０２では、情報処理装置１００は、キャンセル事例のリストのうち、すべてのキャンセル事例について処理済みであるか否かを判定する（ステップＳ２９０２）。ここで、すべてのキャンセル事例について処理済みである場合（ステップＳ２９０２：Ｙｅｓ）、情報処理装置１００は、推薦処理を終了する。一方で、未処理のキャンセル事例が存在する場合（ステップＳ２９０２：Ｎｏ）、情報処理装置１００は、ステップＳ２９０３の処理に移行する。

ステップＳ２９０３では、情報処理装置１００は、キャンセル事例のリストのうち、いずれかのキャンセル事例を処理対象として選択する（ステップＳ２９０３）。次に、情報処理装置１００は、予約管理ＤＢ５００および予約中止ＤＢ６００の中から、処理対象として選択したキャンセル事例が示す開催場所と合致する予約条件を示すレコードを検索する（ステップＳ２９０４）。

そして、情報処理装置１００は、検索されたレコードが１以上存在するか否かを判定する（ステップＳ２９０５）。ここで、検索されたレコードが存在しない場合（ステップＳ２９０５：Ｎｏ）、情報処理装置１００は、ステップＳ２９０２の処理に戻る。一方で、検索されたレコードが１以上存在する場合（ステップＳ２９０５：Ｙｅｓ）、情報処理装置１００は、ステップＳ２９０６の処理に移行する。

ステップＳ２９０６では、情報処理装置１００は、検索されたレコードを含む、レコードのリストを生成する（ステップＳ２９０６）。そして、情報処理装置１００は、図３０のステップＳ３００１の処理に移行する。

図３０において、情報処理装置１００は、レコードのリストに基づいて、それぞれのレコードにおける、処理対象として選択したキャンセル事例が示す開催場所と合致する予約条件についての、最初の予約条件を基準とした妥協度を算出する（ステップＳ３００１）。そして、情報処理装置１００は、ステップＳ３００２の処理に移行する。

ステップＳ３００２では、情報処理装置１００は、レコードのリストのうち、算出された妥協度が最も小さいレコードに基づいて、通知先となるユーザの端末装置２０１を特定する（ステップＳ３００２）。次に、情報処理装置１００は、特定したユーザの端末装置２０１に、処理対象として選択したキャンセル事例が示す開催場所に対する予約が可能であることを示す推薦通知を送信する（ステップＳ３００３）。

そして、情報処理装置１００は、推薦通知への応答が、予約指示であるか否かを判定する（ステップＳ３００４）。ここで、予約指示である場合（ステップＳ３００４：Ｙｅｓ）、情報処理装置１００は、ステップＳ３００５の処理に移行する。一方で、予約指示ではない場合（ステップＳ３００４：Ｎｏ）、情報処理装置１００は、ステップＳ３００６の処理に移行する。

ステップＳ３００５では、情報処理装置１００は、処理対象として選択したキャンセル事例が示す開催場所に対する予約情報を、予約管理ＤＢ５００に記憶する（ステップＳ３００５）。そして、情報処理装置１００は、図２９のステップＳ２９０２の処理に戻る。

ステップＳ３００６では、情報処理装置１００は、推薦通知への応答が、辞退指示であるか否かを判定する（ステップＳ３００６）。ここで、辞退指示である場合（ステップＳ３００６：Ｙｅｓ）、情報処理装置１００は、ステップＳ３００９の処理に移行する。一方で、辞退指示ではない場合（ステップＳ３００６：Ｎｏ）、情報処理装置１００は、ステップＳ３００７の処理に移行する。

ステップＳ３００７では、情報処理装置１００は、推薦通知への応答がなく一定時間が経過したか否かを判定する（ステップＳ３００７）。ここで、一定時間が経過している場合（ステップＳ３００７：Ｙｅｓ）、情報処理装置１００は、ステップＳ３００９の処理に移行する。一方で、一定時間が経過していない場合（ステップＳ３００７：Ｎｏ）、情報処理装置１００は、所定時間待機し（ステップＳ３００８）、ステップＳ３００４の処理に戻る。

ステップＳ３００９では、情報処理装置１００は、レコードのリストが空であるか否かを判定する（ステップＳ３００９）。ここで、空ではない場合（ステップＳ３００９：Ｎｏ）、情報処理装置１００は、ステップＳ３００２の処理に戻る。一方で、空である場合（ステップＳ３００９：Ｙｅｓ）、情報処理装置１００は、図２９のステップＳ２９０２の処理に戻る。

以上説明したように、情報処理装置１００によれば、ユーザから指定された、リソースを検索する条件を受け付ける都度、複数のリソースのうち、受け付けた条件に合致するリソースを検索することができる。情報処理装置１００によれば、受け付けた条件のうち、ユーザによる予約が設定されなかった際の条件に基づいて、変遷情報を、ユーザに対応付けて記憶部に記憶することができる。情報処理装置１００によれば、複数のリソースのいずれかのリソースに対する予約がキャンセルされた場合、ユーザに対応付けて記憶部に記憶された情報から特定される条件に、いずれかのリソースが合致するか否かを判定することができる。情報処理装置１００によれば、合致すれば、ユーザに対して、いずれかのリソースに対する予約が設定可能であることの通知を出力することができる。これにより、情報処理装置１００は、予約がキャンセルされたリソースを使用したい優先度が比較的高いユーザに対して、リソースに対する予約がキャンセルされ、リソースに対して新たな予約を設定可能であることの通知を出力することができる。

情報処理装置１００によれば、第１の条件で検索したリソースに対するユーザによる予約が設定された場合、受け付けた条件のうち、第１の条件より前に受け付けた条件に基づいて、変遷情報を生成することができる。これにより、情報処理装置１００は、変遷情報の生成に用いる条件を、第１の条件より前に受け付けた条件にすることができ、予約作業の１回単位で変遷情報を生成しやすくすることができる。

情報処理装置１００によれば、第１の条件で検索したリソースに対するユーザによる予約が設定された場合、受け付けた条件のうち、第１の条件以前に受け付けた条件に基づいて、変遷情報を生成することができる。これにより、情報処理装置１００は、変遷情報の生成に用いる条件を、第１の条件より前に受け付けた条件にすることができ、予約作業の１回単位で変遷情報を生成しやすくすることができる。また、情報処理装置１００は、第１の条件を、変遷情報の生成に用いるため、第１の条件で検索したリソースの中での第１希望のリソースを諦めて第２希望のリソースに対する予約を設定した場合などに対応することができる。

情報処理装置１００によれば、リソースを検索する条件の受付が中止された場合、受け付けた条件のうち、受付の中止までに受け付けた条件に基づいて、変遷情報を生成することができる。これにより、情報処理装置１００は、変遷情報の生成に用いる条件を、受付の中止までに受け付けた条件にすることができ、予約作業の１回単位で変遷情報を生成しやすくすることができる。また、情報処理装置１００は、予約を設定せず、予約を諦めたユーザに対しても、通知を出力可能にすることができる。

情報処理装置１００によれば、複数のユーザのうち、いずれかのリソースと合致する条件を特定可能な、記憶部に記憶された情報に対応付けられた、１以上のユーザを特定することができる。情報処理装置１００によれば、特定した１以上のユーザのいずれかのユーザに対して、いずれかのリソースに対する予約が設定可能であることの通知を出力することができる。これにより、情報処理装置１００は、予約がキャンセルされたリソースを使用したい優先度が比較的高いユーザの中から、出力対象とするユーザを絞り込むことができる。

情報処理装置１００によれば、特定した１以上のユーザのそれぞれのユーザに対応付けて記憶部に記憶された情報から特定され、いずれかのリソースと合致する条件についての妥協度合いを示す指標値を算出することができる。情報処理装置１００によれば、算出した指標値に基づいて、特定した１以上のユーザのいずれかのユーザに対して、いずれかのリソースに対する予約が設定可能であることの通知を出力することができる。これにより、情報処理装置１００は、指標値に基づいて、予約がキャンセルされたリソースをユーザが使用したい優先度を考慮し、ユーザの意図を考慮して、出力対象とするユーザを絞り込むことができる。

情報処理装置１００によれば、項目ごとの項目条件の変遷、および、項目条件が初めて変更されたタイミングが早い順に、複数の項目を並べた順番に関する情報を、ユーザに対応付けて記憶部に記憶することができる。情報処理装置１００によれば、いずれかのリソースと合致する条件が、項目条件が初めて変更されたタイミングが何番目に早い項目に関し、何番目に変遷した項目条件を含むかに基づいて、指標値を算出することができる。これにより、情報処理装置１００は、過去に受け付けた条件そのものに合致せずとも、過去に受け付けた条件に含まれる項目条件の組み合わせに合致し、ユーザが使用したい優先度が比較的高いと判断されるリソースを特定可能にすることができる。このため、情報処理装置１００は、ユーザが使用したい優先度が比較的高いと判断されるリソースに対する予約がキャンセルされた際、ユーザに対して通知が出力される確率の向上を図ることができる。また、情報処理装置１００は、受け付けた条件を時系列順に記憶する場合に比べ、記憶領域の使用量の低減化を図ることができる。

情報処理装置１００によれば、ユーザに対して、いずれかのリソースに対する予約が設定可能であることの通知を出力した結果、予約要求を受け付けた場合、いずれかのリソースに対するユーザによる予約を設定することができる。これにより、情報処理装置１００は、ユーザが使用したい優先度が高いリソースに対するユーザによる予約を設定することができ、ユーザが使用したい優先度が高いリソースを予約しやすくすることができる。

情報処理装置１００によれば、変遷情報と、設定されたユーザによる予約とを、ユーザに対応付けて記憶部に記憶することができる。情報処理装置１００によれば、予約要求を受け付けた場合、いずれかのリソースに対するユーザによる予約を設定し、ユーザに対応付けて記憶部に記憶されたユーザによる予約をキャンセルすることができる。これにより、情報処理装置１００は、予約がキャンセルされたリソースに対してユーザによる新たな予約を設定した場合、先に設定されていたユーザによる予約をキャンセルし、リソースを活用しやすくすることができる。

情報処理装置１００によれば、受け付けた条件で検索した１以上のリソースのそれぞれのリソースが予約済みである場合に、再び、ユーザから指定された、リソースを検索する条件を受け付けることができる。これにより、情報処理装置１００は、リソースを検索する条件を受け付けることを繰り返すことができる。

情報処理装置１００によれば、受け付けた条件で複数のリソースのいずれのリソースも検索されない場合に、再び、ユーザから指定された、リソースを検索する条件を受け付けることができる。これにより、情報処理装置１００は、リソースを検索する条件を受け付けることを繰り返すことができる。

情報処理装置１００によれば、ユーザからの再検索要求を受け付けた場合に、ユーザから指定された、リソースを検索する条件を受け付けることができる。これにより、情報処理装置１００は、リソースを検索する条件を受け付けることを繰り返すことができる。

情報処理装置１００によれば、リソースが、会議室であり、条件が、会議室を使用する時間を示す項目、会議室が有する設備を示す項目、または、会議室が位置する場所を示す項目に関する項目条件を含む場合について適用することができる。これにより、情報処理装置１００は、会議室に対する会議の予約を管理することができる。

情報処理装置１００によれば、ユーザとの対話形式で、情報の入出力を制御する画面を、ユーザの端末装置２０１に表示させることができる。情報処理装置１００によれば、画面を介して、ユーザから指定された、リソースを検索する条件を、端末装置２０１から受信することができる。情報処理装置１００によれば、複数のリソースのうち、受信した条件に合致する１以上のリソースを検索し、端末装置２０１に、検索した結果を送信し、画面を介して表示させることができる。情報処理装置１００によれば、画面を介して、検索したリソースに対するユーザによる予約を設定する設定要求を、端末装置２０１から受信することができる。情報処理装置１００によれば、設定要求を受信した場合、検索したリソースに対するユーザによる予約を設定することができる。これにより、情報処理装置１００は、チャットボットを実現することができ、チャットボットを介して、リソースに対する予約を管理することができる。

情報処理装置１００によれば、いずれかのリソースに対する予約が設定可能であることの通知を、端末装置２０１に送信することができる。これにより、情報処理装置１００は、端末装置２０１のユーザに、通知を把握させることができる。

情報処理装置１００によれば、他のユーザによる、複数のリソースのいずれかのリソースに対する予約がキャンセルされた場合、ユーザに対して、いずれかのリソースに対する予約が設定可能であることの通知を出力することができる。これにより、情報処理装置１００は、ユーザが予約をキャンセルしたリソースに関し、同じユーザに対して通知を出力しないようにすることができる。

情報処理装置１００によれば、ユーザによる予約を設定可能なリソースが検索されたが、ユーザによる予約が設定されなかった際の条件に基づいて、ユーザによる予約を設定しないリソースを、ユーザに対応付けて記憶部に記憶することができる。情報処理装置１００によれば、予約がキャンセルされたリソースが、ユーザに対応付けて記憶部に記憶されたリソースと合致すると、ユーザに対して、いずれかのリソースに対する予約が設定可能であることの通知を出力しないようにすることができる。これにより、情報処理装置１００は、予約がキャンセルされたリソースを使用したいと考えていないと判断されるユーザに対して、リソースに対して新たな予約を設定可能であることの通知を出力しないことができる。このため、情報処理装置１００は、ユーザが、使用したいと考えていないリソースについての通知を受け付けることを防止することができ、ユーザの作業負担の増大化を抑制することができる。

情報処理装置１００によれば、それぞれのユーザに対応付けて記憶部に記憶された情報から特定され、いずれかのリソースと合致する条件が、何番目に指定された条件であるかに基づいて、指標値を算出することができる。これにより、情報処理装置１００は、指標値に基づいて、予約がキャンセルされたリソースをユーザが使用したい優先度を考慮し、ユーザの意図を考慮して、出力対象とするユーザを絞り込むことができる。

情報処理装置１００によれば、リソースを検索する条件が変更された回数に基づいて、いずれかのリソースと合致する条件の妥協度合いを示す指標値を算出することができる。これにより、情報処理装置１００は、リソースを検索する条件が変更された回数が多く、使用したい優先度が比較的高いリソースに対する予約を設定することができず、不利益が大きいと判断されるユーザを、出力対象に設定しやすくすることができる。このため、情報処理装置１００は、ユーザの利便性の向上を図ることができる。

情報処理装置１００によれば、画面を介して受信した第１の条件で検索したリソースに対するユーザによる予約が設定された場合、画面の表示中に受け付けた条件のうち、第１の条件より前に受け付けた条件に基づいて、変遷情報を生成することができる。これにより、情報処理装置１００は、変遷情報の生成に用いる条件を、画面の表示中に、第１の条件より前に受け付けた条件にすることができ、予約作業の１回単位で変遷情報を生成しやすくすることができる。

情報処理装置１００によれば、リソースを検索する条件の受付が中止された場合、画面の表示中に受け付けた条件のうち、受付の中止までに受け付けた条件に基づいて、変遷情報を、ユーザに対応付けて記憶部に記憶することができる。これにより、情報処理装置１００は、変遷情報の生成に用いる条件を、画面の表示中に、受付の中止までに受け付けた条件にすることができ、予約作業の１回単位で変遷情報を生成しやすくすることができる。

情報処理装置１００によれば、入力装置３０６を用いて、ユーザから指定された、リソースを検索する条件を受け付けることができる。情報処理装置１００によれば、複数のリソースのうち、受信した条件に合致する１以上のリソースを検索し、出力装置３０７を用いて、検索した結果を出力することができる。情報処理装置１００によれば、入力装置３０６を用いて、検索したリソースに対するユーザによる予約を設定する設定要求を受け付けることができる。情報処理装置１００によれば、設定要求を受け付けた場合、検索したリソースに対するユーザによる予約を設定することができる。これにより、情報処理装置１００は、自装置のユーザによる予約を設定可能にすることができる。

なお、本実施の形態で説明した予約管理方法は、予め用意されたプログラムをパーソナル・コンピュータやワークステーション等のコンピュータで実行することにより実現することができる。本実施の形態で説明した予約管理プログラムは、ハードディスク、フレキシブルディスク、ＣＤ−ＲＯＭ、ＭＯ、ＤＶＤ等のコンピュータで読み取り可能な記録媒体に記録され、コンピュータによって記録媒体から読み出されることによって実行される。また、本実施の形態で説明した予約管理プログラムは、インターネット等のネットワークを介して配布してもよい。

上述した実施の形態に関し、さらに以下の付記を開示する。

（付記１）ユーザから指定された、リソースを検索する条件を受け付ける都度、複数のリソースのうち、受け付けた前記条件に合致するリソースを検索し、
受け付けた前記条件のうち、前記ユーザによる予約が設定されなかった際の条件に基づいて、リソースを検索する条件の変遷に関する情報を、前記ユーザに対応付けて記憶部に記憶し、
前記複数のリソースのいずれかのリソースに対する予約がキャンセルされた場合、前記ユーザに対応付けて前記記憶部に記憶された情報から特定される条件に、前記いずれかのリソースが合致すれば、前記ユーザに対して、前記いずれかのリソースに対する予約が設定可能であることの通知を出力する、
処理をコンピュータが実行することを特徴とする予約管理方法。

（付記２）前記記憶する処理は、
第１の条件で検索したリソースに対する前記ユーザによる予約が設定された場合、受け付けた前記条件のうち、前記第１の条件より前に受け付けた条件に基づいて、リソースを検索する条件の変遷に関する情報を、前記ユーザに対応付けて記憶部に記憶する、ことを特徴とする付記１に記載の予約管理方法。

（付記３）前記記憶する処理は、
第１の条件で検索したリソースに対する前記ユーザによる予約が設定された場合、受け付けた前記条件のうち、前記第１の条件以前に受け付けた条件に基づいて、リソースを検索する条件の変遷に関する情報を、前記ユーザに対応付けて記憶部に記憶する、ことを特徴とする付記２に記載の予約管理方法。

（付記４）リソースを検索する条件の受付が中止された場合、受け付けた前記条件のうち、前記受付の中止までに受け付けた条件に基づいて、リソースを検索する条件の変遷に関する情報を、前記ユーザに対応付けて前記記憶部に記憶する、ことを特徴とする付記１〜３のいずれか一つに記載の予約管理方法。

（付記５）前記記憶部は、複数のユーザのそれぞれのユーザに対応付けて、リソースを検索する条件の変遷に関する情報を記憶し、
前記複数のリソースのいずれかのリソースに対する予約がキャンセルされた場合、前記複数のユーザのうち、前記いずれかのリソースと合致する条件を特定可能な、前記記憶部に記憶された情報に対応付けられた、１以上のユーザを特定する、処理を前記コンピュータが実行し、
前記出力する処理は、
特定した前記１以上のユーザのいずれかのユーザに対して、前記いずれかのリソースに対する予約が設定可能であることの通知を出力する、ことを特徴とする付記１〜４のいずれか一つに記載の予約管理方法。

（付記６）特定した前記１以上のユーザのそれぞれのユーザに対応付けて前記記憶部に記憶された情報から特定され、前記いずれかのリソースと合致する条件についての妥協度合いを示す指標値を算出する、処理を前記コンピュータが実行し、
前記出力する処理は、
算出した前記指標値に基づいて、特定した前記１以上のユーザのいずれかのユーザに対して、前記いずれかのリソースに対する予約が設定可能であることの通知を出力する、ことを特徴とする付記５に記載の予約管理方法。

（付記７）前記条件は、複数の項目の少なくともいずれかの項目に関する項目条件を含み、
前記記憶する処理は、
受け付けた前記条件のうち、連続して前記ユーザによる予約が設定されなかった２つの条件ごとの差分に基づいて、前記項目ごとの項目条件の変遷、および、項目条件が初めて変更されたタイミングが早い順に、前記複数の項目を並べた順番に関する情報を、前記ユーザに対応付けて前記記憶部に記憶し、
前記算出する処理は、
前記それぞれのユーザに対応付けて前記記憶部に記憶された情報から特定され、前記いずれかのリソースと合致する条件が、項目条件が初めて変更されたタイミングが何番目に早い項目に関し、何番目に変遷した項目条件を含むかに基づいて、前記指標値を算出する、ことを特徴とする付記６に記載の予約管理方法。

（付記８）前記ユーザに対して、前記いずれかのリソースに対する予約が設定可能であることの通知を出力した結果、予約要求を受け付けた場合、前記いずれかのリソースに対する前記ユーザによる予約を設定する、処理を前記コンピュータが実行することを特徴とする付記１〜７のいずれか一つに記載の予約管理方法。

（付記９）前記記憶する処理は、
第１の条件で検索したリソースに対する前記ユーザによる予約が設定された場合、受け付けた前記条件のうち、前記第１の条件より前に受け付けた条件に基づいて、リソースを検索する条件の変遷に関する情報と、設定された前記ユーザによる予約とを、前記ユーザに対応付けて記憶部に記憶し、
前記設定する処理は、
前記予約要求を受け付けた場合、前記いずれかのリソースに対する前記ユーザによる予約を設定し、前記ユーザに対応付けて前記記憶部に記憶された前記ユーザによる予約をキャンセルする、ことを特徴とする付記８に記載の予約管理方法。

（付記１０）前記検索する処理は、
受け付けた前記条件で検索した１以上のリソースのそれぞれのリソースが予約済みである場合に、再び、前記ユーザから指定された、リソースを検索する条件を受け付ける、ことを特徴とする付記１〜９のいずれか一つに記載の予約管理方法。

（付記１１）前記検索する処理は、
受け付けた前記条件で前記複数のリソースのいずれのリソースも検索されない場合に、再び、前記ユーザから指定された、リソースを検索する条件を受け付ける、ことを特徴とする付記１〜１０のいずれか一つに記載の予約管理方法。

（付記１２）前記検索する処理は、
前記ユーザからの再検索要求を受け付けた場合に、前記ユーザから指定された、リソースを検索する条件を受け付ける、ことを特徴とする付記１〜１１のいずれか一つに記載の予約管理方法。

（付記１３）前記リソースは、会議室であり、
前記条件は、前記会議室を使用する時間を示す項目、前記会議室が有する設備を示す項目、または、前記会議室が位置する場所を示す項目に関する項目条件を含む、ことを特徴とする付記１〜１２のいずれか一つに記載の予約管理方法。

（付記１４）前記ユーザとの対話形式で、情報の入出力を制御する画面を、前記ユーザの端末装置に表示させる、処理を前記コンピュータが実行し、
前記検索する処理は、
前記画面を介して、前記ユーザから指定された、リソースを検索する条件を、前記端末装置から受信し、
前記複数のリソースのうち、受信した前記条件に合致する１以上のリソースを検索し、
前記端末装置に、検索した結果を送信し、前記画面を介して表示させ、
前記画面を介して、検索したリソースに対する前記ユーザによる予約を設定する設定要求を、前記端末装置から受信し、
前記設定要求を受信した場合、検索したリソースに対する前記ユーザによる予約を設定する、ことを特徴とする付記１〜１３のいずれか一つに記載の予約管理方法。

（付記１５）前記出力する処理は、
前記いずれかのリソースに対する予約が設定可能であることの通知を、前記端末装置に送信する、ことを特徴とする付記１４に記載の予約管理方法。

（付記１６）前記出力する処理は、
前記ユーザとは異なるユーザによる、前記複数のリソースのいずれかのリソースに対する予約がキャンセルされた場合、前記ユーザに対応付けて前記記憶部に記憶された情報から特定される条件に、前記いずれかのリソースが合致すれば、前記ユーザに対して、前記いずれかのリソースに対する予約が設定可能であることの通知を出力する、ことを特徴とする付記１〜１５のいずれか一つに記載の予約管理方法。

（付記１７）前記記憶する処理は、
受け付けた前記条件のうち、前記ユーザによる予約を設定可能なリソースが検索されたが、前記ユーザによる予約が設定されなかった際の条件に基づいて、前記ユーザによる予約を設定しないリソースを、前記ユーザに対応付けて記憶部に記憶し、
前記出力する処理は、
前記複数のリソースのいずれかのリソースに対する予約がキャンセルされた場合、前記いずれかのリソースが、前記ユーザに対応付けて前記記憶部に記憶された情報から特定される条件に合致し、かつ、前記ユーザに対応付けて前記記憶部に記憶されたリソースと異なれば、前記ユーザに対して、前記いずれかのリソースに対する予約が設定可能であることの通知を出力する、ことを特徴とする付記１〜１６のいずれか一つに記載の予約管理方法。

（付記１８）前記算出する処理は、
前記それぞれのユーザに対応付けて前記記憶部に記憶された情報から特定され、前記いずれかのリソースと合致する条件が、何番目に指定された条件であるかに基づいて、前記指標値を算出する、ことを特徴とする付記６に記載の予約管理方法。

（付記１９）前記算出する処理は、
リソースを検索する条件が変更された回数に基づいて、特定した前記１以上のユーザのそれぞれのユーザに対応付けて前記記憶部に記憶された情報から特定され、前記いずれかのリソースと合致する条件の妥協度合いを示す指標値を算出する、ことを特徴とする付記６または７に記載の予約管理方法。

（付記２０）前記記憶する処理は、
前記画面を介して受信した第１の条件で検索したリソースに対する前記ユーザによる予約が設定された場合、前記画面の表示中に受け付けた前記条件のうち、前記第１の条件より前に受け付けた条件に基づいて、リソースを検索する条件の変遷に関する情報を、前記ユーザに対応付けて記憶部に記憶する、ことを特徴とする付記１４に記載の予約管理方法。

（付記２１）前記記憶する処理は、
リソースを検索する条件の受付が中止された場合、前記画面の表示中に受け付けた前記条件のうち、前記受付の中止までに受け付けた条件に基づいて、リソースを検索する条件の変遷に関する情報を、前記ユーザに対応付けて前記記憶部に記憶する、ことを特徴とする付記１４に記載の予約管理方法。

（付記２２）前記検索する処理は、
入力装置を用いて、前記ユーザから指定された、リソースを検索する条件を受け付け、
前記複数のリソースのうち、受信した前記条件に合致する１以上のリソースを検索し、
出力装置を用いて、検索した結果を出力し、
前記入力装置を用いて、検索したリソースに対する前記ユーザによる予約を設定する設定要求を受け付け、
前記設定要求を受け付けた場合、検索したリソースに対する前記ユーザによる予約を設定する、ことを特徴とする付記１〜１３のいずれか一つに記載の予約管理方法。

（付記２３）ユーザから指定された、リソースを検索する条件を受け付ける都度、複数のリソースのうち、受け付けた前記条件に合致するリソースを検索し、
受け付けた前記条件のうち、前記ユーザによる予約が設定されなかった際の条件に基づいて、リソースを検索する条件の変遷に関する情報を、前記ユーザに対応付けて記憶部に記憶し、
前記複数のリソースのいずれかのリソースに対する予約がキャンセルされた場合、前記ユーザに対応付けて前記記憶部に記憶された情報から特定される条件に、前記いずれかのリソースが合致すれば、前記ユーザに対して、前記いずれかのリソースに対する予約が設定可能であることの通知を出力する、
処理をコンピュータに実行させることを特徴とする予約管理プログラム。

（付記２４）ユーザから指定された、リソースを検索する条件を受け付ける都度、複数のリソースのうち、受け付けた前記条件に合致するリソースを検索し、
受け付けた前記条件のうち、前記ユーザによる予約が設定されなかった際の条件に基づいて、リソースを検索する条件の変遷に関する情報を、前記ユーザに対応付けて記憶部に記憶し、
前記複数のリソースのいずれかのリソースに対する予約がキャンセルされた場合、前記ユーザに対応付けて前記記憶部に記憶された情報から特定される条件に、前記いずれかのリソースが合致すれば、前記ユーザに対して、前記いずれかのリソースに対する予約が設定可能であることの通知を出力する、
制御部を有することを特徴とする情報処理装置。

１００ 情報処理装置
１１０，８００ 記憶部
２００ 予約管理システム
２０１ 端末装置
２１０ ネットワーク
３００，７００ バス
３０１，７０１ ＣＰＵ
３０２，７０２ メモリ
３０３，７０３ ネットワークＩ／Ｆ
３０４，７０４ 記録媒体Ｉ／Ｆ
３０５，７０５ 記録媒体
３０６，７０７ 入力装置
３０７ 出力装置
４００ リソース管理ＤＢ
５００，２４００ 予約管理ＤＢ
５０１，６０１，２４０１ レコード
６００ 予約中止ＤＢ
７０６ ディスプレイ
８０１ 取得部
８０２ 検索部
８０３ 生成部
８０４ 設定部
８０５ 予約部
８０６ 出力部
９００ 入力画面
９０１〜９０６，１１１１ 入力欄
９０７ 検索ボタン
１０００ 選択画面
１００１ 結果
１００２ 選択ボタン
１００３ 再検索ボタン
１１００ ブラウザ画面
１１１０ 会話表示領域
１１１２ 送信ボタン
１１２０ 予約表示領域
１４０１〜１４０９，１６０１〜１６０９ 矢印
１５００，１７００，１９００，２３００，２５００，２７００ キャンセル事例
１５１０，１７１０，２５１０ メッセージ
２００１〜２００６，２６０１〜２６０６ 開催条件
２０１０，２１０１〜２１０３，２２０１〜２２０３，２３０１〜２３０３，２６１０，２７０１〜２７０３ 変遷情報

Claims (16)

1. ユーザから指定された、リソースを検索する条件を受け付ける都度、複数のリソースのうち、受け付けた前記条件に合致するリソースを検索し、
   受け付けた前記条件のうち、前記ユーザによる予約が設定されなかった際の条件に基づいて、リソースを検索する条件の変遷に関する情報を、前記ユーザに対応付けて記憶部に記憶し、
   前記複数のリソースのいずれかのリソースに対する予約がキャンセルされた場合、前記ユーザに対応付けて前記記憶部に記憶された情報から特定される条件に、前記いずれかのリソースが合致すれば、前記ユーザに対して、前記いずれかのリソースに対する予約が設定可能であることの通知を出力する、
   処理をコンピュータが実行することを特徴とする予約管理方法。
2. 前記記憶する処理は、
   第１の条件で検索したリソースに対する前記ユーザによる予約が設定された場合、受け付けた前記条件のうち、前記第１の条件より前に受け付けた条件に基づいて、リソースを検索する条件の変遷に関する情報を、前記ユーザに対応付けて記憶部に記憶する、ことを特徴とする請求項１に記載の予約管理方法。
3. 前記記憶する処理は、
   第１の条件で検索したリソースに対する前記ユーザによる予約が設定された場合、受け付けた前記条件のうち、前記第１の条件以前に受け付けた条件に基づいて、リソースを検索する条件の変遷に関する情報を、前記ユーザに対応付けて記憶部に記憶する、ことを特徴とする請求項２に記載の予約管理方法。
4. リソースを検索する条件の受付が中止された場合、受け付けた前記条件のうち、前記受付の中止までに受け付けた条件に基づいて、リソースを検索する条件の変遷に関する情報を、前記ユーザに対応付けて前記記憶部に記憶する、ことを特徴とする請求項１〜３のいずれか一つに記載の予約管理方法。
5. 前記記憶部は、複数のユーザのそれぞれのユーザに対応付けて、リソースを検索する条件の変遷に関する情報を記憶し、
   前記複数のリソースのいずれかのリソースに対する予約がキャンセルされた場合、前記複数のユーザのうち、前記いずれかのリソースと合致する条件を特定可能な、前記記憶部に記憶された情報に対応付けられた、１以上のユーザを特定する、処理を前記コンピュータが実行し、
   前記出力する処理は、
   特定した前記１以上のユーザのいずれかのユーザに対して、前記いずれかのリソースに対する予約が設定可能であることの通知を出力する、ことを特徴とする請求項１〜４のいずれか一つに記載の予約管理方法。
6. 特定した前記１以上のユーザのそれぞれのユーザに対応付けて前記記憶部に記憶された情報から特定され、前記いずれかのリソースと合致する条件についての妥協度合いを示す指標値を算出する、処理を前記コンピュータが実行し、
   前記出力する処理は、
   算出した前記指標値に基づいて、特定した前記１以上のユーザのいずれかのユーザに対して、前記いずれかのリソースに対する予約が設定可能であることの通知を出力する、ことを特徴とする請求項５に記載の予約管理方法。
7. 前記条件は、複数の項目の少なくともいずれかの項目に関する項目条件を含み、
   前記記憶する処理は、
   受け付けた前記条件のうち、連続して前記ユーザによる予約が設定されなかった２つの条件ごとの差分に基づいて、前記項目ごとの項目条件の変遷、および、項目条件が初めて変更されたタイミングが早い順に、前記複数の項目を並べた順番に関する情報を、前記ユーザに対応付けて前記記憶部に記憶し、
   前記算出する処理は、
   前記それぞれのユーザに対応付けて前記記憶部に記憶された情報から特定され、前記いずれかのリソースと合致する条件が、項目条件が初めて変更されたタイミングが何番目に早い項目に関し、何番目に変遷した項目条件を含むかに基づいて、前記指標値を算出する、ことを特徴とする請求項６に記載の予約管理方法。
8. 前記ユーザに対して、前記いずれかのリソースに対する予約が設定可能であることの通知を出力した結果、予約要求を受け付けた場合、前記いずれかのリソースに対する前記ユーザによる予約を設定する、処理を前記コンピュータが実行することを特徴とする請求項１〜７のいずれか一つに記載の予約管理方法。
9. 前記記憶する処理は、
   第１の条件で検索したリソースに対する前記ユーザによる予約が設定された場合、受け付けた前記条件のうち、前記第１の条件より前に受け付けた条件に基づいて、リソースを検索する条件の変遷に関する情報と、設定された前記ユーザによる予約とを、前記ユーザに対応付けて記憶部に記憶し、
   前記設定する処理は、
   前記予約要求を受け付けた場合、前記いずれかのリソースに対する前記ユーザによる予約を設定し、前記ユーザに対応付けて前記記憶部に記憶された前記ユーザによる予約をキャンセルする、ことを特徴とする請求項８に記載の予約管理方法。
10. 前記検索する処理は、
    受け付けた前記条件で検索した１以上のリソースのそれぞれのリソースが予約済みである場合に、再び、前記ユーザから指定された、リソースを検索する条件を受け付ける、ことを特徴とする請求項１〜９のいずれか一つに記載の予約管理方法。
11. 前記検索する処理は、
    受け付けた前記条件で前記複数のリソースのいずれのリソースも検索されない場合に、再び、前記ユーザから指定された、リソースを検索する条件を受け付ける、ことを特徴とする請求項１〜１０のいずれか一つに記載の予約管理方法。
12. 前記検索する処理は、
    前記ユーザからの再検索要求を受け付けた場合に、前記ユーザから指定された、リソースを検索する条件を受け付ける、ことを特徴とする請求項１〜１１のいずれか一つに記載の予約管理方法。
13. 前記リソースは、会議室であり、
    前記条件は、前記会議室を使用する時間を示す項目、前記会議室が有する設備を示す項目、または、前記会議室が位置する場所を示す項目に関する項目条件を含む、ことを特徴とする請求項１〜１２のいずれか一つに記載の予約管理方法。
14. 前記ユーザとの対話形式で、情報の入出力を制御する画面を、前記ユーザの端末装置に表示させる、処理を前記コンピュータが実行し、
    前記検索する処理は、
    前記画面を介して、前記ユーザから指定された、リソースを検索する条件を、前記端末装置から受信し、
    前記複数のリソースのうち、受信した前記条件に合致する１以上のリソースを検索し、
    前記端末装置に、検索した結果を送信し、前記画面を介して表示させ、
    前記画面を介して、検索したリソースに対する前記ユーザによる予約を設定する設定要求を、前記端末装置から受信し、
    前記設定要求を受信した場合、検索したリソースに対する前記ユーザによる予約を設定する、ことを特徴とする請求項１〜１３のいずれか一つに記載の予約管理方法。
15. ユーザから指定された、リソースを検索する条件を受け付ける都度、複数のリソースのうち、受け付けた前記条件に合致するリソースを検索し、
    受け付けた前記条件のうち、前記ユーザによる予約が設定されなかった際の条件に基づいて、リソースを検索する条件の変遷に関する情報を、前記ユーザに対応付けて記憶部に記憶し、
    前記複数のリソースのいずれかのリソースに対する予約がキャンセルされた場合、前記ユーザに対応付けて前記記憶部に記憶された情報から特定される条件に、前記いずれかのリソースが合致すれば、前記ユーザに対して、前記いずれかのリソースに対する予約が設定可能であることの通知を出力する、
    処理をコンピュータに実行させることを特徴とする予約管理プログラム。
16. ユーザから指定された、リソースを検索する条件を受け付ける都度、複数のリソースのうち、受け付けた前記条件に合致するリソースを検索し、
    受け付けた前記条件のうち、前記ユーザによる予約が設定されなかった際の条件に基づいて、リソースを検索する条件の変遷に関する情報を、前記ユーザに対応付けて記憶部に記憶し、
    前記複数のリソースのいずれかのリソースに対する予約がキャンセルされた場合、前記ユーザに対応付けて前記記憶部に記憶された情報から特定される条件に、前記いずれかのリソースが合致すれば、前記ユーザに対して、前記いずれかのリソースに対する予約が設定可能であることの通知を出力する、
    制御部を有することを特徴とする情報処理装置。

Images