JP2019079407A - 装置、管理システム及びプログラム - Google Patents

Abstract

【課題】特定の提供者が利用者の希望する商品を提供できない場合、希望の商品と同等の商品を提供する他の提供者の商品を提供する装置、管理システム及びプログラムを提供する。【解決手段】予約管理サーバ５は、利用者のアクセス先となった第１の提供者が提供する第１の商品を候補として利用者に通知し、第１の商品を提供できない場合、予め定めた第２の提供者が提供する第２の商品を候補として利用者に通知する通知手段（予約制御部１０１）を有する。【選択図】図６

Description

本発明は、装置、管理システム及びプログラムに関する。

検索の条件を満たす商品（サービスや情報を含む）の候補を検索の結果として提示する仕組みがある。例えば複数の提供者が提供する商品を横断的に検索し、検索の条件を満たす商品を提供する特定の提供者に利用者を誘導する仕組みがある。

特開２００４−８６５８２号公報

特定の提供者から商品の提供を受けたい場合には、検索の条件として特定の提供者を含める必要があるが、希望の商品が見つからない場合には改めて検索をやり直す必要がある。

本発明は、利用者の希望する特定の提供者が利用者の希望する商品を提供できない場合、希望の商品と同等の商品 を提供する他の提供者の商品を提供することを目的とする。

請求項１に記載の発明は、利用者のアクセス先となった第１の提供者が提供する第１の商品を候補として利用者に通知し、当該第１の商品を提供できない場合、予め定めた第２の提供者が提供する第２の商品を候補として利用者に通知する通知手段を有する装置である。
請求項２に記載の発明は、前記第１の商品及び前記第２の商品は、予約の対象となる空間である、請求項１に記載の装置である。
請求項３に記載の発明は、前記第１の商品及び前記第２の商品は、扉の開閉を通じて出入りできる空間である、請求項２に記載の装置である。
請求項４に記載の発明は、前記第１の商品及び前記第２の商品は、壁で囲まれた空間である、請求項２に記載の装置である。
請求項５に記載の発明は、前記第２の商品は、利用者が希望する前記第１の商品について予め紐付けられている、請求項１に記載の装置である。
請求項６に記載の発明は、利用者が希望した前記第１の商品は、検索の条件を満たす候補の中から利用者によって指定される、請求項５に記載の装置である。
請求項７に記載の発明は、利用者が希望した前記第１の商品は、前記第１の提供者が用意した候補の中から利用者によって指定される、請求項５に記載の装置である。
請求項８に記載の発明は、前記候補として通知が可能な前記第２の商品が複数ある場合、前記通知手段は、評価が高い順番に当該第２の商品を通知する、請求項１に記載の装置である。
請求項９に記載の発明は、前記第１の商品及び前記第２の商品が予約の対象となる空間である場合、利用者の現在の位置から当該第２の商品である空間への移動の時間が短い候補の評価が高く設定される、請求項８に記載の装置である。
請求項１０に記載の発明は、前記第１の商品及び前記第２の商品が予約の対象となる空間である場合、利用者が指定した当該第１の商品である空間から当該第２の商品である空間への移動の時間が短い候補の評価が高く設定される、請求項８に記載の装置である。
請求項１１に記載の発明は、前記第１の商品及び前記第２の商品が予約の対象となる空間である場合、当該第２の商品である空間への移動に伴い発生する実費用が少ない候補の評価が高く設定される、請求項８に記載の装置である。
請求項１２に記載の発明は、前記実費用は、利用者が支払う交通費である、請求項１１に記載の装置である。
請求項１３に記載の発明は、前記実費用は、前記第２の商品の利用に対して利用者に付与される対価と利用者が支払う交通費との差額である、請求項１１に記載の装置である。
請求項１４に記載の発明は、成約に伴い発生する利益が大きい候補の評価が高く設定される、請求項８に記載の装置である。
請求項１５に記載の発明は、 前記通知手段は、前記第１の商品を提供できない場合に使用する条件が定められている場合、当該条件に従って候補として通知する前記第２の商品を特定する、請求項１に記載の装置である。
請求項１６に記載の発明は、前記条件は、前記第１の商品及び前記第２の商品が予約の対象となる空間である場合、利用者が指定した空間から移動に要する時間である、請求項１５に記載の装置である。
請求項１７に記載の発明は、前記条件は、前記第１の商品及び前記第２の商品が予約の対象となる空間である場合、移動に伴い発生する実費用である、請求項１５に記載の装置である。
請求項１８に記載の発明は、前記条件は、成約に伴い発生する利益である、請求項１５に記載の装置である。
請求項１９に記載の発明は、利用者のアクセス先となった第１の提供者が提供する第１の商品を候補として利用者に通知し、当該第１の商品を提供できない場合、予め定めた第２の提供者が提供する第２の商品を候補として利用者に通知する通知手段と、前記第１の商品の管理データを保持する第１のデータベースと、前記第２の商品の管理データを保持する第２のデータベースとを有する管理システムである。
請求項２０に記載の発明は、コンピュータを、利用者のアクセス先となった第１の提供者が提供する第１の商品を候補として利用者に通知し、当該第１の商品を提供できない場合、予め定めた第２の提供者が提供する第２の商品を候補として利用者に通知する通知手段として機能させるプログラムである。

請求項１記載の発明によれば、利用者の希望する第１の提供者が利用者の希望する第１の商品を提供できない場合、希望の商品と同等の第２の商品を提供する第２の提供者の商品を提供できる。
請求項２記載の発明によれば、利用者の希望する第１の提供者が利用者の希望する第１の商品を提供できない場合、希望の商品と同等の第２の商品を提供する第２の提供者の商品を提供できる。
請求項３記載の発明によれば、利用者の希望する第１の提供者が利用者の希望する第１の商品を提供できない場合、希望の商品と同等の第２の商品を提供する第２の提供者の商品を提供できる。
請求項４記載の発明によれば、利用者の希望する第１の提供者が利用者の希望する第１の商品を提供できない場合、希望の商品と同等の第２の商品を提供する第２の提供者の商品を提供できる。
請求項５記載の発明によれば、利用者が希望する第１の商品と同等の第２の商品を提示できる。
請求項６記載の発明によれば、利用者が希望する第１の商品と同等の第２の商品を提示できる。
請求項７記載の発明によれば、利用者が希望する第１の商品と同等の第２の商品を提示できる。
請求項８記載の発明によれば、利用者の利益を高めることができる。
請求項９記載の発明によれば、利用者の利益を高めることができる。
請求項１０記載の発明によれば、利用者の利益を高めることができる。
請求項１１記載の発明によれば、利用者の利益を高めることができる。
請求項１２記載の発明によれば、利用者の利益を高めることができる。
請求項１３記載の発明によれば、利用者の利益を高めることができる。
請求項１４記載の発明によれば、第１の提供者の利益を高めることができる。
請求項１５記載の発明によれば、追加の条件により第２の商品を絞り込むことができる。
請求項１６記載の発明によれば、利用者の利益を高めることができる。
請求項１７記載の発明によれば、利用者の利益を高めることができる。
請求項１８記載の発明によれば、第１の提供者の利益を高めることができる。
請求項１９記載の発明によれば、利用者の希望する第１の提供者が利用者の希望する第１の商品を提供できない場合、希望の商品と同等の第２の商品を提供する第２の提供者の商品を提供できる。
請求項２０記載の発明によれば、利用者の希望する第１の提供者が利用者の希望する第１の商品を提供できない場合、希望の商品と同等の第２の商品を提供する第２の提供者の商品を提供できる。

管理システムの全体構成の例を概略的に示す図である。 ユーザに対して貸し出される時間貸し空間の外観構成例を説明する図である。 ユーザ端末のハードウェア構成の例を説明する図である。 管理システムを構成するサーバのハードウェア構成の例を説明する図である。 管理システムを構成する時間貸し空間の構成例を説明する図である。 ＣＰＵのソフトウェア構成の例を説明する図である。 実施の形態１で想定する予約の仕組みを説明する図である。 ユーザがアクセスした予約サイト（予約管理サーバ）の予約制御部で実行される処理動作の例を説明するフローチャートである。 予約制御部が参照する管理テーブル（優先設定を含む）の例を説明する図である。 予約の過程で表示される一連の操作画面の例を説明する図である。（Ａ）は自社の候補の提示画面であり、（Ｂ）は予約依頼の画面であり、（Ｃ）は提携先の候補の提示画面であり、（Ｄ）は詳細情報の確認画面であり、（Ｅ）は予約依頼の画面であり、（Ｆ）は予約完了時の画面である。 実施の形態２で想定する物品の販売の仕組みを説明する図である。 ＣＰＵのソフトウェア構成の例を説明する図である。 ユーザがアクセスした販売約サイト（販売管理サーバ）の販売制御部で実行される処理動作の例を説明するフローチャートである。 販売制御部が参照する管理テーブル（優先設定を含む）の例を説明する図である。 物品を購入する過程で表示される一連の操作画面の例を説明する図である。（Ａ）は自社で提供可能な物品の提示画面であり、（Ｂ）は提携先を提示する画面であり、（Ｃ）は提携先で提供可能な物品の提示画面であり、（Ｄ）は購入設定画面であり、（Ｅ）は購入完了時の画面である。 実施の形態３で想定するサービスの販売の仕組みを説明する図である。 ＣＰＵのソフトウェア構成の例を説明する図である。 ユーザがアクセスしたサービス提供サイト（サービス管理サーバ）のサービス提供制御部で実行される処理動作の例を説明するフローチャートである。 サービス提供制御部が参照する管理テーブル（優先設定を含む）の例を説明する図である。 サービスを購入する過程で表示される一連の操作画面の例を説明する図である。（Ａ）は自社で提供可能なサービスの提示画面であり、（Ｂ）は提携先を提示する画面であり、（Ｃ）は提携先で提供可能なサービスの提示画面であり、（Ｄ）は購入設定画面であり、（Ｅ）は購入完了時の画面である。 管理システムの他の構成例を示す図である。

以下、図面を参照して、本発明の実施の形態を説明する。
以下で説明する実施の形態では、提供の対象としての物品、サービス、情報などの意味で商品ということがある。
以下で説明する実施の形態では、提供の対象である商品が有料で提供される場合について説明するが、無料で提供されてもよいし、電子的なポイントを介して提供されてもよい。

＜実施の形態１＞
＜管理システムの全体構成＞
通信速度の向上や通信端末の小型化に伴い、オフィス外でも各種の情報にアクセスできる環境が整っている。一方で、ビジネス上の会話や情報は秘匿性が高いため、静かでセキュアな環境が求められている。
本実施の形態では、これらの要望を満たす空間を提供するための管理システムについて説明する。もっとも、以下に説明する空間は、ビジネス用途に限るものでなく、個人での利用も可能である。

図１は、管理システム１の全体構成の例を概略的に示す図である。
図１に示すように、管理システム１は、クラウドネットワーク２に接続された各種の端末で構成される。
図１には、管理システム１を構成する端末の例として、複数台の時間貸し空間３と、時間貸し空間３を利用する個々のユーザが携帯する複数台のユーザ端末４と、個々の時間貸し空間３の予約を管理する予約管理サーバ５と、個々の時間貸し空間３の利用の状況を管理する空間管理サーバ６と、利用者に対する請求を管理する請求管理サーバ７と、時間貸し空間３を利用できる会員の情報を管理する会員管理サーバ８とが示されている。
なお、本実施の形態における時間貸し空間３は、保守等で使用される時間を除き、２４時間３６５日の利用が可能である。

図１の場合、目的別（機能別）に１台のサーバが用意されているが、目的別に複数台のサーバを用意してもよい。また、１台のサーバで複数の目的（機能）を分担してもよい。
時間貸し空間３の時間貸しサービスを提供する事業者は、単独でも複数でもよい。例えば予約の管理、入退室や室内の利用状況などの管理、ユーザに対する利用料金の請求に関する管理、利用者として登録されている会員の管理のそれぞれを異なる事業者が分担してもよい。なお、１つの目的（機能）についての管理を複数の事業者が協働で提供してもよい。
また、１つの目的（機能）に対して複数のサーバを用意してもよい。単独の事業者が１つの目的（機能）に対して複数のサーバを用意する場合や複数の目的（機能）に対応する複数のサーバを用意する場合には、イントラネットを介して接続すればよい。
また、時間貸し空間３も単独の事業者が提供する場合だけでなく、複数の事業者によって提供されてもよい。
すなわち、管理システム１は、複数の事業者が提供するサービスの集合体として実現されてもよい。

本実施の形態においては、施錠や解錠に電子鍵を使用する。電子鍵は、ユーザ端末４や不図示の近距離無線通信に対応したＩＣ（Integrated Circuit）カードに格納する。ユーザ端末４を電子鍵として使用する場合には、予約の確定後に、予約管理サーバ５からユーザ端末４に電子鍵が提供される。ＩＣカードを電子鍵として使用する場合には、予約の確定後に、電子鍵を記録したＩＣカードが予約管理サーバ５から配布される。
電子鍵の場合には、施錠や解錠を有効に行える時間を自由に定めることができる。また、１つの時間貸し空間３の利用に必要な電子鍵を同じ時間帯に対して複数発行することもできる。
なお、物理的な鍵を予約された時間別に複数用意し、時間貸し空間３を施錠し又は解錠できるようにしてもよい。また、利用者の認証を鍵の代わりに使用してもよいし、電子鍵や物理的な鍵を補足する手段として使用してもよい。

予約管理サーバ５は、例えば利用可能な時間貸し空間３を登録した登録リスト５１と、個々の時間貸し空間３の利用を希望する予約者の割り当てを管理する予約リスト５２を管理する。
本実施の形態の場合、予約管理サーバ５は、保守等に確保された時間を除き、２４時間３６５日、時間貸し空間３の予約を受け付ける。また、必要に応じて、ユーザ端末４に対する電子鍵の発行や認証の処理を実行する。なお、認証の処理は空間管理サーバ６の側で行ってもよい。

空間管理サーバ６は、例えば個々の時間貸し空間３への入退室の情報を管理する情報６１と、個々の時間貸し空間３の利用状況の情報６２を管理する。また、空間管理サーバ６は、時間貸し空間３に配置されている認証ユニット３２Ａ（図２参照）と通信し、利用者の入室を許可するか否かを管理する機能も有している。認証に際し、空間管理サーバ６は、予約管理サーバ５と通信する。
この他、空間管理サーバ６は、時間貸し空間３内に配置されている各種の機器３１からの情報の収集や各種の機器３１の制御を実行する機能を有している。
図１の例では、空間管理サーバ６はクラウドネットワーク２に接続されているが、機能の一部又は全部が、時間貸し空間３に収容されていてもよい。

請求管理サーバ７は、予約情報と、利用者の情報と、入退室の情報等に基づいて会員別（自然人の場合もあれば法人の場合もある）に請求書を発行する機能を有している。請求管理サーバ７は、予約管理サーバ５から予約情報を取得し、空間管理サーバ６から入退室の情報を取得し、会員管理サーバ８から会員情報を取得する。
会員管理サーバ８は、登録されている会員の情報と利用者の情報とを管理する。会員が自然人の場合には、会員と利用者は一致する。一方、会員が法人の場合には、会員別に個々の利用者が登録され、管理される。

図２は、ユーザに対して貸し出される時間貸し空間３の外観構成例を説明する図である。
本実施の形態における時間貸し空間３は、例えば駅の構内、空港、オフィスビル、飲食店やデパート等の商業施設、銀行、図書館、美術館、博物館、公共機関や施設、連絡通路、公園等、室内外を問わずに配置される。
本実施の形態では、時間貸し空間３として防音性に優れた小部屋を想定する。この意味で、時間貸し空間３は、閉鎖型の空間の一例である。本実施の形態において、閉鎖型とは、密閉の意味ではなく、実用的な防音性能を備える意味で使用する。従って、通気口や小窓等の開口や隙間が、時間貸し空間３を構成する躯体３０の一部分に設けられていてもよい。

本実施の形態における躯体３０は、天井３０Ａと、床面３０Ｂと、開閉可能な扉３２が取り付けられている壁面３０Ｃと、壁面３０Ｃの両側に位置する２つの壁面３０Ｄ及び３０Ｅと、扉３２の対面側に位置する壁面３０Ｆとで構成される。
本実施の形態の場合、扉３２として、１枚の扉部材が弧を描くように開閉する片開きの開き戸を想定する。もっとも、扉３２は、１つの開口部を２枚の扉部材で仕切る両開きの開き戸でもよい。
また、扉３２は、引き戸でもよい。引き戸は、１枚の扉をスライドする片引きタイプでも、２枚以上の扉を行き違わせて開閉する引き違いタイプでも、２枚の扉を左右にスライドする引き分けタイプでもよい。
また、扉３２は、蝶番で連結された２枚１組の扉部材を折り畳むように開く折れ戸でもよい。折れ戸にも、片方にのみ開くタイプと、両方向に開くタイプがある。
また、特殊なタイプとして、収納時に扉３２が壁の中に引き込まれる引き込み戸や間仕切り戸であってもよい。
なお、扉３２は内開きでも外開きでも構わない。

本実施の形態の場合、壁面３０Ｄ及び３０Ｅの一部は、例えば透光性の部材（例えばガラス、アクリル樹脂）で構成される。
もっとも、壁面３０Ｄ及び３０Ｅの少なくとも一部には、目隠し（外部から室内の観察を難しくする又は視認性を低下させる）の機能を実現する構造、材質、加工などが採用されていてもよい。
例えば壁面３０Ｄ及び３０Ｅの材質自体が半透明の部材でもよいし、光が散乱するように部材の表面に細かい傷がつけられた部材でもよいし、同等の機能を備えるフィルム状の部材が貼り付けられていてもよい。なお、フィルム状の部材は、透過と白濁を電気的に切り替え可能な液晶フィルムや透過率を電気的に制御可能な偏光フィルムでもよい。
また、目隠しのための構造や部材が別に用意されていてもよい。もっとも、壁面３０Ｄ及び３０Ｅも、他の面と同じく光を通さない部材で構成されてもよい。もっとも、３面以上が透明又は半透明の部材で構成されていてもよい。

時間貸し空間３の利用人数は、時間貸し空間の容積によっておおよそ決まる。本実施の形態では、基本的に１人が使用する個室型を想定しているが、多人数を収容可能な大部屋でもよい。大部屋は単独の部屋として構成されていてもよいが、時間貸し空間３の壁面３０Ｄ及び３０Ｅの一方又は両方を取り除いて連結して構成されていてもよい。
なお、個室型とは１人しか利用できない意味ではなく、少人数、例えば２〜３人の利用が可能な意味で使用する。
個々の時間貸し空間３を構成する躯体３０の形状や構造、提供される設備や性能は任意である。
本実施の形態の場合、躯体３０の内部には、机３３と椅子３４が１つずつ配されている。また、机３３の上には、機器３１の一例である印刷装置３１Ｄ、コンピュータ本体３１Ｅ、表示デバイス３１Ｆ、入力デバイス３１Ｇが配されている。なお、コンピュータ本体３１Ｅに記憶されているデータや履歴の情報は、システム側の制御によって、利用の終了後に全て消去される。利用者の情報を保護するためである。

この他、機器３１として、空調装置３１Ａ、人感センサ３１Ｂ、室内の照明に使用される照明器具３１Ｃ、機器３１を含む電子機器の動作を制御する制御装置３１Ｈ、認証ユニット３２Ａが配置される。
なお、機器３１として例示した具体的な電子機器は一例である。例えば机３３の上に配されている印刷装置３１Ｄ、コンピュータ本体３１Ｅ、表示デバイス３１Ｆ、入力デバイス３１Ｇは設置されていなくてもよい。そのような場合は、利用者のコンピュータやスマートフォンが用いられる。

ここでの時間貸し空間３の全体（躯体３０を含む）は、特許請求の範囲における装置の一例である。また、ユーザ端末４、予約管理サーバ５、空間管理サーバ６、請求管理サーバ７、会員管理サーバ８も、特許請求の範囲における装置の一例である。
また、管理システム１は、特許請求の範囲における管理システムの一例である。

＜端末の構成＞
図３〜図５を使用して、管理システム１を構成する端末の構成例を説明する。
図３は、ユーザ端末４のハードウェア構成の例を説明する図である。
本実施の形態では、ユーザ端末４として、例えばスマートフォンを使用する。
ユーザ端末４は、ファームウェアやアプリケーションプログラムの実行を通じて各種の機能を提供するＣＰＵ（Central Processing Unit）４１と、ファームウェアやＢＩＯＳ（Basic Input Output System）を格納する記憶領域であるＲＯＭ（Read Only Memory）４２と、プログラムの実行領域であるＲＡＭ（Random Access Memory）４３を有している。
また、ユーザ端末４は、ダウンロードしたアプリケーションプログラムや電子鍵等を記憶する揮発性の記憶装置４４と、外部との通信に使用される通信インタフェース（通信ＩＦ）４５と、タッチパネル等の入力デバイス４６と、情報の表示に使用される表示デバイス４７と、撮像カメラ４８とを有している。記憶装置４４には、例えば半導体メモリが用いられる。
ここで、ＣＰＵ４１と各種のデバイスはバス４９を通じて接続されている。

図４は、管理システム１を構成するサーバのハードウェア構成の例を説明する図である。
図４では、予約管理サーバ５の構成を代表的に表している。もっとも、他のサーバ、すなわち、空間管理サーバ６、請求管理サーバ７、会員管理サーバ８の構成も図４に示す構成と同様である。
予約管理サーバ５は、オペレーションシステムやアプリケーションプログラムの実行を通じて各種の管理機能を提供するＣＰＵ５１Ａと、オペレーションシステムやＢＩＯＳを格納する記憶領域であるＲＯＭ５２Ａと、プログラムの実行領域であるＲＡＭ５３を有している。
また、予約管理サーバ５は、担当する管理機能を実現するアプリケーションプログラムや各種の管理データを記憶する揮発性のハードディスクドライブ（ＨＤＤ）５４と、外部との通信に使用される通信インタフェース（通信ＩＦ）５５と、キーボード等の入力デバイス５６と、情報の表示に使用される表示デバイス５７とを有している。
ここで、ＣＰＵ５１Ａと各種のデバイスはバス５８を通じて接続されている。
なお、各サーバは、管理データを保持するデータベースの一例である。すなわち、各サーバは、特許請求の範囲における第１のデータベース及び第２のデータベースの一例である。

図５は、管理システム１を構成する時間貸し空間３の構成例を説明する図である。
時間貸し空間３は、空調装置３１Ａ、人感センサ３１Ｂ、照明器具３１Ｃ、印刷装置３１Ｄ、コンピュータ本体３１Ｅ、表示デバイス３１Ｆ、入力デバイス３１Ｇ、制御装置３１Ｈ、認証ユニット３２Ａを有している。
ここで、空調装置３１Ａは、室内の気温や湿度の調整に使用される。なお、空調装置３１Ａと共に、又は、空調装置３１Ａとは別に換気に特化した機構（換気装置）を設けてもよい。換気装置は、室内に新しい空気を供給する給気設備と室内の空気を外部に排出する排気設備で構成される。
人感センサ３１Ｂは、室内の人の検知に用いられるセンサであり、様々なタイプが存在する。例えば人の動きを検知可能な焦電型赤外線人感センサ、人の数と位置を検知可能な画像型人感センサやサーモパイル型人感センサがある。目的に応じて、これらのセンサのうちのいずれか、または、複数を組み合わせて使用する。

印刷装置３１Ｄ、コンピュータ本体３１Ｅ、表示デバイス３１Ｆ、入力デバイス３１Ｇは、利用者の操作用に予め室内に用意されている情報機器の一例である。これらはＬＡＮ（Local Area Network）３１Ｖ（例えばＬＡＮケーブルや無線ＬＡＮ）を通じて接続されている。なお、利用者がコンピュータを持ち込む場合には、持ち込まれたコンピュータがＬＡＮ３１Ｖに接続される。無線ＬＡＮには、例えばＷｉＦｉ（商標）やブルートゥース（登録商標）が用いられる。
制御装置３１Ｈは、ＬＡＮ３１Ｖに接続された機器から情報を収集すると共に、個々の機器の動作を制御する制御用のコンピュータである。なお、制御装置３１Ｈは、管理システム１によっては、空間管理サーバ６としての機能を提供することもある。
認証ユニット３２Ａは、例えば扉３２に取り付けられている。認証ユニット３２Ａは、扉３２の施錠や解錠に必要となる情報の取得や受け渡しに使用される。例えば認証の処理は、予約管理サーバ５で実行され、認証の結果だけが認証ユニット３２Ａに通知される。認証ユニット３２Ａは、認証が成功した場合、扉３２を解錠する。解錠の後、扉３２の開閉が可能になり、時間貸し空間３（図２参照）への入室が可能になる。

この他、時間貸し空間３には、外部との通信用の通信インタフェース（通信ＩＦ）３１Ｉが用意されている。通信ＩＦ３１Ｉは、クラウドネットワーク２（図１参照）に接続されており、各種のサーバとの通信に使用される。
時間貸し空間３には、扉３２の開閉を機械的に制御する扉開閉機構３１Ｊが用意されている。扉開閉機構３１Ｊには、例えば扉３２を駆動して開閉する機構や利用者による扉３２の開閉操作に介在して開閉に要する負荷の大きさを調整する機構が含まれる。
時間貸し空間３には、開閉ロック機構３１Ｋが用意されている。開閉ロック機構３１Ｋは、利用者による扉３２の開閉を制限する機構である。開閉ロック機構３１Ｋが作動している間、少なくとも扉３２を閉じる操作が制限される。

時間貸し空間３には、室内や室外における利用者の動きの監視に用いる監視カメラ３１Ｌが用意される。もっとも、監視カメラ３１Ｌは必須ではない。
時間貸し空間３には、表示デバイス３１Ｍが用意される。本実施の形態における表示デバイス３１Ｍは、例えば扉３２が設けられている壁面３０Ｃの外側に配置され、入室しようとする利用者の操作用や情報の提供用に使用される。また、表示デバイス３１Ｍは、時間貸し空間３を利用している利用者の操作用や情報の提供用に使用される。表示デバイス３１Ｍは報知手段の一例である。
時間貸し空間３には、スピーカ３１Ｎが用意される。スピーカ３１Ｎは、室内の利用者に対する情報の報知や室外にいる人への情報の報知に使用される。スピーカ３１Ｎは報知手段の一例である。
時間貸し空間３には、集音マイク３１Ｏが用意される。集音マイク３１Ｏは、室内の音の取得に使用される。

時間貸し空間３には、温度センサ３１Ｐが用意される。温度センサ３１Ｐは、室内の気温の測定に使用される。
時間貸し空間３には、湿度センサ３１Ｑが用意される。湿度センサ３１Ｑは、室内の湿度の測定に使用される。
時間貸し空間３には、マグネットセンサ３１Ｒが用意される。マグネットセンサ３１Ｒは、扉３２に取り付けられており、磁力の検知を通じて扉３２の開閉を検知する。
時間貸し空間３には、加速度センサ３１Ｓが用意される。加速度センサ３１Ｓは、モノの動きの検知に使用される。

時間貸し空間３には、マットセンサ３１Ｔが用意される。マットセンサ３１Ｔは、モノの重さを検知して人の滞在時間や混雑状況の可視化に使用される。
時間貸し空間３には、空気環境モニタ３１Ｕが用意される。空気環境モニタ３１Ｕは、室内の空気に含まれる成分を検知するセンサであり、例えばＰＭ２．５やＰＭ１０の濃度、二酸化炭素の濃度、温度、湿度、揮発性有機化合物の濃度などを測定する。なお、測定対象はこれらの全てである必要はないし、他の成分も測定対象であってもよい。空気環境モニタ３１Ｕによって温度や湿度を測定可能な場合、温度センサ３１Ｐと湿度センサ３１Ｑを別に設ける必要はない。

＜制御機能＞
ここでは、図６を使用して、管理システム１を構成する端末のいずれかにより、又は、複数の端末の協働により実現される制御機能について説明する。
ここでは、特定の事業者（例えば事業者Ａ）が運用する予約管理サーバ５が、提携関係にある他の事業者（例えば事業者Ｂ）が運営する予約管理サーバ５との協働動作を想定する。この協働動作は、各予約管理サーバ５を構成するＣＰＵ５１Ａ（図４参照）によるプログラムの実行を通じて実現される。
本実施の形態における予約管理サーバ５は、自社の商品である時間貸し空間３の提供を優先し、自社の商品を提供できない場合には、自社と提携する特定の事業者の時間貸し空間３を利用者に提供する。

図６は、ＣＰＵ５１Ａのソフトウェア構成の例を説明する図である。
ＣＰＵ５１Ａは、プログラムの実行を通じて予約制御部１０１として機能する。予約制御部１０１は、特許請求の範囲における通知手段の一例である。
予約制御部１０１は、複数の機能によって構成されている。
例えば本実施の形態の場合、予約制御部１０１は、ユーザが希望する条件を受け付ける予約条件受付部１０２と、自社で管理する時間貸し空間３を優先的に検索する優先先検索部１０３と、自社で管理する時間貸し空間３をユーザに提供できない場合に、提携する特定の事業者で管理する時間貸し空間３を検索する提携先検索部１０４と、条件に該当した時間貸し空間３をユーザに提示する候補提示部１０５と、提携する特定の事業者との間で予約が成立した場合に自社からの斡旋の事実を記録する斡旋記録部１０６と、を有している。

予約条件受付部１０２は、例えばユーザ端末４（図１参照）を通じて予約の条件を受け付ける機能を提供する。予約の条件には、例えば場所と時間帯が含まれる。時間帯は、開始の時間と終了の時間によって特定される。なお、予約の条件には、利用可能な設備やサービスの提供者を含めることもできる。また、これらのうちの１つだけを予約の条件とすることもできる。
優先先検索部１０３は、自社が管理する時間貸し空間３を対象として、入力された条件を満たす予約が可能か否かを検索する。
提携先検索部１０４は、自社で管理する時間貸し空間３を予約できない場合に用いられる機能である。提携先検索部１０４は、自社が提携している特定の事業者が管理している時間貸し空間３を対象として、入力された条件を満たす予約が可能か否かを検索する。

候補提示部１０５は、優先先検索部１０３又は提携先検索部１０４で検索された、予約の条件を満たした時間貸し空間３を候補として提示する。本実施の形態では、自社又は提携先のいずれかにおいて、予約の条件を満たす時間貸し空間３が見つからない場合、代替的な候補を提示する。
斡旋記録部１０６は、自社のサイトにアクセスしたユーザに対して、提携先の時間貸し空間３を斡旋し、予約が成立した場合に斡旋の事実を記録する。
本実施の形態の場合、この記録は、予約が成立した提携先の事業者から斡旋に対する対価を受け取るために使用される。また、自社が管理する時間貸し空間３を使用できなかったユーザに対する対価の付与に使用される。ここでの対価は、金銭の場合もあれば、いわゆるポイントの場合もある。
なお、ユーザに対する対価は運用上の理由によるものである。例えば提携先が管理する時間貸し空間３の予約をユーザが受け入れた場合に、予約先の時間貸し空間３に移動するために要する費用の補填等に使用してもよい。

＜制御例＞
以下では、予約制御部１０１（図６参照）の制御を通じて実現される予約に関する制御の例を説明する。
まず、制御によって実現される予約サービスの全体像を説明する。
図７は、実施の形態１で想定する予約の仕組みを説明する図である。
図７には図１との対応部分に対応する符号を付して示している。
図７の例では、予約に関係のある端末だけを表している。図７の場合、５つの予約管理サーバ５Ａ、５Ｂ、５Ｃ、５Ｄ、５Ｅが存在する。予約管理サーバ５Ａ、５Ｂ、５Ｃ、５Ｄ、５Ｅは、それぞれ時間貸し空間３の貸し出しサービスを運営しているＡ社、Ｂ社、Ｃ社、Ｄ社、Ｅ社に対応する。
本実施の形態では、これら５社のうち、Ａ社、Ｂ社、Ｃ社が互いに提携し、Ｄ社とＥ社は独立して貸し出しサービスを運営しているものとする。

本実施の形態における提携とは、ユーザからの予約の窓口になったが事業者が、自社と提携先との間で予約の条件を満たす時間貸し空間３を融通し合う補完関係をいう。図７の例であれば、Ａ社と、Ｂ社と、Ｃ社は、時間貸し空間３を互いに融通し合う関係にある。
図７では、ユーザが、Ａ社の予約サイトにアクセスした場合を想定している。このため、ユーザ端末４から予約管理サーバ５Ａに向かう矢印１１１が描かれている。

本実施の形態の場合、予約管理サーバ５Ａは、予約の条件を満たす時間貸し空間３の検索を２段階に実行する。
１段目は、自社が管理する時間貸し空間３を対象とする検索である。予約サイトへのアクセスには、アクセス先であるＡ社が提供している時間貸し空間３を使用したいというユーザの暗黙の希望が認められるためである。
２段目は、提携先が管理する時間貸し空間３を対象とする検索である。Ａ社の時間貸し空間３を提供できない場合に、提携先を通じて自社と同等の時間貸し空間３をユーザに提供するためである。
この場合、ユーザは、Ｂ社の予約サイトにアクセスして希望の条件を入力し直さなくても、自身がアクセスしたＡ社の予約サイトを通じて時間貸し空間３を予約できる。
また、ユーザは、アクセス先であるＡ社を通じてＢ社又はＣ社の時間貸し空間３を利用するので、Ａ社と同等のサービスの提供を期待できる。

なお、図中の矢印１１２及び１１３は、予約の条件を満たす時間貸し空間３をＡ社が提供できないが、Ｂ社又はＣ社が管理する時間貸し空間３であれば提供が可能な場合の斡旋の向きを表している。
図７では、提携関係にないＤ社とＥ社への斡旋は生じないので矢印にバツ印をつけて描いている。

図８は、ユーザがアクセスした予約サイト（予約管理サーバ）の予約制御部１０１で実行される処理動作の例を説明するフローチャートである。
以下では、Ａ社の予約管理サーバ５Ａ（図７参照）にユーザがアクセスしたものとして説明する。
まず、予約制御部１０１は、予約の条件を受け付ける（ステップ１０１）。予約の条件として、例えば希望の場所が入力される。
次に、予約制御部１０１は、入力された予約の条件に基づいて、自社（Ａ社）で管理する時間貸し空間３を検索する（ステップ１０２）。予約の条件を満たす時間貸し空間３が複数見つかった場合、予約制御部１０１は、それらを候補としてユーザに提示する。候補を提示する場合には、候補に対する他のユーザの予約を受け付けないように処理する。
続いて、予約制御部１０１は、提示された候補に対するユーザの指定を受け付ける（ステップ１０３）。

予約制御部１０１は、指定された候補の予約が可能か否かを判定する（ステップ１０４）。予約が可能である場合（ステップ１０４で肯定結果の場合）、予約制御部１０１は、予約を確定し（ステップ１０５）、管理データを更新する（ステップ１０６）。
一方、指定された候補の予約を受け付けられない（ステップ１０４で否定結果の場合）、予約制御部１０１は、提携先の時間貸し空間３を対象とする検索動作に移行する。
なお、ステップ１０２における検索の結果、予約の条件を満たす候補が存在しなかった場合には、ステップ１０３を飛ばしてステップ１０４の判定が実行され、否定の結果が得られる。

検索に先立ち、予約制御部１０１は、ユーザによる優先設定があるか否かを判定する（ステップ１０７）。
優先設定は、提携先の時間貸し空間３が提示される場合に、どの条件を優先するかについての設定である。優先設定には、例えば指定された時間貸し空間３からの移動の距離又は時間が短い方を優先する、移動に要する実費用が少ない方を優先する、延長可能な時間が長い方を優先する、付帯設備が多い方を優先する、斡旋によって自社（ここではＡ社）が受け取る利益が大きい方を優先する、予め定めた優先順が上位の提携先を優先する等がある。
ここで、移動の距離又は時間とは、ユーザが指定した時間貸し空間３の位置を起点とする場合と、ユーザの現在の位置を起点とする場合が含まれる。
また、移動に要する実費用は、利用者が支払う交通費であってもよいし、利用者が支払う交通費と提携先の利用に対して付与される報奨金との差額であってもよい。
また、自社が受け取る利益とは、斡旋に伴って提携先から受領する斡旋料の額である。
なお、候補のそれぞれについて計算される評価値が高い方を優先してもよい。

ステップ１０７で肯定結果が得られた場合（優先設定があった場合）、予約制御部１０１は、ユーザの優先設定と指定された時間貸し空間３に紐付けられている設定に基づいて提携先が管理する時間貸し空間３を提示する（ステップ１０８）。
図９は、予約制御部１０１が参照する管理テーブル（優先設定を含む）の例を説明する図である。
図９に示す管理テーブル１５０は、複数の項目１５１〜１６１で構成されている。
項目１５１は、Ａ社が管理する時間貸し空間３の一覧である。図９では、ユーザがステップ１０３（図８参照）で指定した時間貸し空間３（Ａ＃０５００２）を太線で囲んで示している。
項目１５２は、管理会社の欄である。図９では、予約制御部１０１が、Ａ社の予約管理サーバ５Ａ（図７参照）の場合を想定しているので、全ての列にＡ社を示す記号が記載されている。なお、項目１５２は、Ａ社から委託を受けた他社が予約サイトを運営している場合に必要となる。

項目１５３は、Ａ社が管理する個々の時間貸し空間３に紐付けられている提携先の時間貸し空間３の一覧である。
図９では、Ａ＃０５００２で管理される時間貸し空間３に対してＢ＃２０５５６で管理される時間貸し空間３が紐付けられている。なお、紐付けられている時間貸し空間３の数は１つである必要はなく複数であっても良い。紐付けられる複数の時間貸し空間３は異なる提携先で管理されていてもよい。
図９では、個々の時間貸し空間３に提携先の時間貸し空間３を紐付けているが、提携先を紐付けの対象としてもよい。この場合には、項目１５４だけでよい。
項目１５４は、紐付けられている時間貸し空間３の管理会社の欄である。
項目１５５は、ユーザが指定した時間貸し空間３からの移動の距離又は時間に関する情報の表示に使用される。
図９の例では、移動の距離が短い場合を二重丸で表し、次に短い場合を丸印で表し、次に短い場合を三角で表している。
図９の例では、記号によって情報を表現しているが、これらの評価に対応する数値が記録されてもよい。また、情報は、距離を表す数値でもよいし、時間を表す数値でもよい。

項目１５６は、移動に要する交通費の欄である。紐付けられている時間貸し空間３を受け入れた場合には電車やバスなどの交通機関の利用が必要になることがあるためである。徒歩で移動できる場合には無料であるので評価は最も高くなる。図９の例では、交通費が低い場合を丸印で示し、次に低い場合を三角印で示し、次に低い場合をバツ印で示している。
項目１５７は、延長可能な時間の欄である。この欄の情報は、予約の時点における他の予約との関係で変わり得る。図９では長時間の延長が可能な場合を丸印で示し、次に延長可能な時間が長い区分を三角印で示し、延長できない場合をバツ印で示している。

項目１５８は、付帯設備の欄である。この欄の情報は付帯設備が多い場合を二重丸で示し、次に付帯設備が多い場合を丸印で示し、次に多い場合を三角印で表している。
ここでの項目１５５〜１５８がユーザの優先設定に対応する。
項目１５９は、ユーザの希望に対する合致度を表す欄である。図９のうち太線で囲んだ例では３位と記載されている。この３位とは、紐付けられている時間貸し空間３（Ｂ＃２０５５６）の予約の条件に対する合致度が、提携先であるＢ社とＣ社で提供可能な時間貸し空間３のうちで３番目であることを表している。なお、この欄は、各欄に記されている評価の総合評価でもよい。

項目１６０は、斡旋元への対価（斡旋料）の額を表す欄である。実際の斡旋料は個別の契約による。ここでの斡旋料は、予約サイトの表示に使用したアプリケーションプログラムやリンクされているウェブサイト等の情報に基づいて計算されてもよい。
項目１６１は、ユーザへの対価（報奨金）の額を表す欄である。提携先が提供する時間貸し空間３を使用することで発生する不便や交通費に対する対価として用意されている。交通費が発生しない場合には不要でよい。

図８の説明に戻る。
ステップ１０８の実行後、予約制御部１０１は、提示された候補について予約が成立したか否かを判定する（ステップ１０９）。
ステップ１０９で否定結果が得られた場合、予約制御部１０１は、ステップ１０７に戻る。例えば優先設定を外して他の候補を提示する。
ステップ１０９で肯定結果が得られた場合、予約制御部１０１は、予約を確定し（ステップ１１０）、管理データを更新する（ステップ１１１）。

なお、ステップ１０７で否定結果が得られた場合（優先設定がない場合）、予約制御部１０１は、ユーザによって指定された時間貸し空間３に紐付けられている提携先の時間貸し空間３を提示する（ステップ１１２）。
例えば予約制御部１０１は、管理テーブル１５０（図９参照）の項目１５３（図９参照）を参照し、１つ又は複数の候補をユーザに提示する。
なお、予約が完了した時点で、Ａ社は予約が成立した提携先に宛てて予約の成立を通知してもよい。通知は予め定めた件数の成立毎にまとめて行ってもよい。
また、斡旋料は斡旋のたびに清算してもよいし、月単位で清算してもよい。なお、清算自体は事前の契約に基づく条件に基づいて計算される金額によって行ってもよい。

＜操作画面の例＞
ここでは、ユーザが操作するユーザ端末４（図１参照）に表示される操作画面の例を説明する。
図１０は、予約の過程で表示される一連の操作画面の例を説明する図である。（Ａ）は自社の候補の提示画面１７１であり、（Ｂ）は予約依頼の画面１７２であり、（Ｃ）は提携先の候補の提示画面１７３であり、（Ｄ）は詳細情報の確認画面１７４であり、（Ｅ）は予約依頼の画面１７５であり、（Ｆ）は予約完了時の画面１７６である。

図１０に示す提示画面１７１では、予約の条件として場所だけが与えられた場合の例である。このため、「空いている時間帯」の欄が空欄になっている。
画面１７２は、候補のうち先頭に表示されていたＡ＃０５００２の時間貸し空間３の予約設定画面を表しており、希望時間として１５時から１７時の時間帯が入力されている。
提示画面１７３では、希望する時間帯での予約ができないため、提携先を対象とする検索によって見つかった候補が提示されている。この例では、Ｂ社が管理するＢ＃２０５５６とＣ社が管理するＣ＃００３０２が提示されている。

確認画面１７４は、ユーザがＢ社の管理するＢ＃２０５５６を指定した場合の画面である。この例では、詳細情報の確認用のため「空いている時間帯」が空欄になっている。この画面で予約設定画面をクリックすると画面１７５が表示される。この例では、希望時間が空いている時間貸し空間３が候補として提示されているので、画面１７５で予約依頼が出すと、予約完了時の画面１７６が表示される。
このように、ユーザは、Ｂ社が管理する時間貸し空間３（Ｂ＃２０５５６）を予約する場合でも、Ａ社の予約サイトにアクセスするだけで予約を実現できている。また、予約の条件を入力し直す必要もない。

＜実施の形態の効果＞
本実施の形態で説明した手法を用いれば、ユーザは、使用を希望するＡ社の予約サイトにアクセスして予約の条件を入力することで、Ａ社の提供する時間貸し空間３の予約を優先的に検索できる。そして、Ａ社の提供する時間貸し空間３の予約を実現できない場合でも、ユーザは、Ａ社の予約サイトを通じて提携先であるＢ社かＣ社の時間貸し空間３を予約することができる。

従前の予約サイトの場合であれば、今回の提携グループ（Ａ社、Ｂ社、Ｃ社）だけでなくＤ社やＥ社も含めて候補が提示され、しかも提示される順番は使用したいＡ社が上位に位置するとは限らない。また、ユーザにとっては関心がないＤ社やＥ社が管理する時間貸し空間３についても候補として提示されてしまう。
しかし、本実施の形態の場合には、ユーザが使用したいＡ社の時間貸し空間３の候補だけが最初に提示され、予約の条件を満たさない場合でも、Ａ社との提携により同等のサービスを期待できるＢ社とＣ社の時間貸し空間３の提示を受けることができる。

なお、提携グループを構成するＡ社、Ｂ社、Ｃ社にとっても、自社の予約サイトにアクセスしたユーザに対しては自社の時間貸し空間３の提示を優先できるので、自社の時間貸し空間３の稼働率を上げることができる。また、提携先にユーザを斡旋する場合でも、自社の予約サイトを通じて予約を受け付けることができるので、ユーザの期待に応えることができる。
一方、提携先にあっては、提携している他者からの斡旋を通じて予約の機会を増やすことができるので、時間貸し空間３の稼働率を上げることができる。

＜実施の形態２＞
前述の実施の形態１では時間貸し空間３の予約を想定したが、本実施の形態では、商品の販売を想定する。
＜システムの概要＞
図１１は、実施の形態２で想定する物品の販売の仕組みを説明する図である。
図１１には図７との対応部分に対応する符号を付して示している。
図１１の例では、物品の販売に関係のある端末だけを表している。図１１の場合、５つの販売管理サーバ５Ａ１、５Ｂ１、５Ｃ１、５Ｄ１、５Ｅ１が存在する。販売管理サーバ５Ａ１、５Ｂ１、５Ｃ１、５Ｄ１、５Ｅ１は、販売サイトを運営しているＡ１社、Ｂ１社、Ｃ１社、Ｄ１社、Ｅ１社に対応する。

本実施の形態における販売企業は、製造業者や生産者の場合だけでなく、特定の製造業者や生産者の物品の販売を代行する代理店でもよいし、いわゆる通販事業者でもよい。
本実施の形態では、これら５社のうち、Ａ１社とＢ１社が互いに提携し、Ｃ１社とＤ１社とＥ１社は独立して物品の販売事業を行っているものとする。
本実施の形態における提携とは、ユーザに対して窓口になった事業者が、自社と提携先との間で希望の条件を満たす物品を融通し合う補完関係をいう。
この実施の形態の場合、提携先は物品毎に定めてもよいし、事業者単位（事業者としての個人を含む）で定めてもよい。
なお、通販事業者の場合には、同業者を提携先としてもよいし、出店している商品の製造業者や生産者を提携先としてもよい。
図１１の例であれば、Ａ１社とＢ１社は、物品の販売機会を互いに融通し合う関係にある。
図１１では、ユーザが、Ａ１社の販売サイトにアクセスした場合を想定している。このため、ユーザ端末４から販売管理サーバ５Ａ１に向かう矢印１２１が描かれている。

本実施の形態の場合、販売管理サーバ５Ａ１は、希望の条件を満たす物品の検索を２段階に実行する。
１段目は、自社が販売する物品を対象とする検索である。販売サイトへのアクセスには、アクセス先であるＡ１社から物品を購入したいというユーザの暗黙の希望が認められるためである。
２段目は、提携先が販売する物品を対象とする検索である。Ａ１社が物品を販売できない場合に、提携先を通じて自社と同等の物品をユーザに提供するためである。
この場合、ユーザは、Ｂ１社の販売サイトにアクセスして希望の条件を入力し直さなくても、自身がアクセスしたＡ１社の販売サイトを通じて物品を購入できる。
また、ユーザは、アクセス先であるＡ１社を通じてＢ１社の物品を購入できるので、Ａ１社と同等のサービスの提供を期待できる。
なお、図中の矢印１２２は、条件を満たす物品をＡ１社が販売できないが、Ｂ１社が物品を販売が可能な場合の斡旋の向きを表している。
図１１では、提携関係にないＣ１社とＤ１社とＥ１社への斡旋は生じないので矢印にバツ印をつけて描いている。

＜販売管理サーバの構成＞
ここでは、販売管理サーバ５Ａ１の構成例について説明する。因みに、販売管理サーバ５Ａ１のハードウェア構成は図４に示す構成と同様である。
図１２は、ＣＰＵ５Ａ１（図４参照）のソフトウェア構成の例を説明する図である。
この実施の形態の場合、ＣＰＵ５１Ａは、プログラムの実行を通じて販売制御部１０１Ａとして機能する。販売制御部１０１Ａは、特許請求の範囲における通知手段の一例である。

販売制御部１０１Ａは、複数の機能によって構成されている。
例えば本実施の形態の場合、販売制御部１０１Ａは、ユーザが希望する条件を受け付ける希望条件受付部１０２Ａと、自社で販売する物品を優先的に検索する優先先検索部１０３Ａと、自社で販売する物品をユーザに提供できない場合に、提携する特定の事業者が販売する物品を検索する提携先検索部１０４Ａと、条件に該当した物品をユーザに提示する候補提示部１０５Ａと、提携する特定の事業者との間で販売が成立した場合に自社からの斡旋の事実を記録する斡旋記録部１０６Ａと、を有している。

希望条件受付部１０２Ａは、例えばユーザ端末４（図１参照）を通じて希望の条件を受け付ける機能を提供する。
優先先検索部１０３Ａは、自社が販売する物品を対象とした検索を実行する。
提携先検索部１０４Ａは、自社が物品を販売できない場合に用いられる機能である。提携先検索部１０４Ａは、自社が提携している特定の事業者が販売する物品を対象として、入力された条件を満たす物品の提供が可能か否かを検索する。

候補提示部１０５Ａは、優先先検索部１０３Ａ又は提携先検索部１０４Ａで検索された、希望の条件を満たした物品を候補として提示する。本実施の形態では、自社又は提携先のいずれかにおいて、希望の条件を満たす物品が見つからない場合、代替的な候補を提示する。
斡旋記録部１０６Ａは、自社のサイトにアクセスしたユーザに対して、提携先の物品を斡旋し、販売が成立した場合に斡旋の事実を記録する。
本実施の形態の場合、この記録は、販売が成立した提携先の事業者から斡旋に対する対価を受け取るために使用される。また、自社が販売する物品を使用できなかったユーザに対する対価の付与に使用される。ここでの対価は、金銭の場合もあれば、いわゆるポイントの場合もある。
なお、ユーザに対する対価は運用上の理由によるものである。

＜制御例＞
図１３は、ユーザがアクセスした販売サイト（販売管理サーバ）の販売制御部１０１Ａ（図１２参照）で実行される処理動作の例を説明するフローチャートである。
以下では、Ａ１社の販売管理サーバ５Ａ１（図１１参照）にユーザがアクセスしたものとして説明する。
まず、販売制御部１０１Ａは、希望の条件を受け付ける（ステップ２０１）。希望の条件として、例えば商品名が入力される。
次に、販売制御部１０１Ａは、入力された希望の条件に基づいて、自社（Ａ１社）で販売する物品を検索する（ステップ２０２）。希望の条件を満たす物品が複数見つかった場合、販売制御部１０１Ａは、それらを候補としてユーザに提示する。なお、在庫が限られている場合や販売個数が制限されている場合には、候補を提示する際に、候補に対する他のユーザの購入を受け付けないように処理してもよい。
続いて、販売制御部１０１Ａは、提示された候補に対するユーザの指定を受け付ける（ステップ２０３）。

販売制御部１０１Ａは、指定された候補の販売が可能か否かを判定する（ステップ２０４）。販売が可能である場合（ステップ２０４で肯定結果の場合）、販売制御部１０１Ａは、販売を確定し（ステップ２０５）、管理データを更新する（ステップ２０６）。
一方、指定された候補を販売できない場合（ステップ２０４で否定結果の場合）、販売制御部１０１Ａは、提携先が販売する物品を対象とする検索動作に移行する。
なお、ステップ２０２における検索の結果、希望の条件を満たす候補が存在しなかった場合には、ステップ２０３を飛ばしてステップ２０４の判定が実行され、否定の結果が得られる。

検索に先立ち、販売制御部１０１Ａは、ユーザによる優先設定があるか否かを判定する（ステップ２０７）。優先設定は、提携先が提示される場合に、どの条件を優先するかについての設定である。例えば到着予定日や時間、料金（送料を含めてもよい）、物品の状態、評判等が事前に設定される。
ステップ２０７で肯定結果が得られた場合（優先設定があった場合）、販売制御部１０１Ａは、ユーザの優先設定と紐付けられた提携先とに基づいて物品の候補を提示する（ステップ２０８）。

図１４は、販売制御部１０１Ａが参照する管理テーブル（優先設定を含む）の例を説明する図である。
図１４に示す管理テーブル１９０は、販売会社Ａ１と販売会社Ｂ１が共通に使用するテーブルの例を表している。管理テーブル１９０は、複数の項目１９１〜２０１で構成されている。
項目１９１は、ユーザが最初に希望した販売会社の一覧である。図１１では、ユーザがＡ１社の販売管理サーバ５Ａ１にアクセスした場合を太線で囲んで示している。
項目１９２は、紐付けされている販売会社の欄である。図１４では、販売会社Ａ１に対しては販売会社Ｂ１が紐付けられ、販売会社Ｂ１には販売会社Ａ１が紐付けられている。なお、提携先が複数ある場合には、複数の販売会社が列記される、又は、列を改めて販売会社毎に記載される。

項目１９３は、到達予定日または時間に関する情報の表示に使用される。図１４の例では、到着予定日又は時間が早い場合を二重丸で表し、次に早い場合を三角で表している。図１４では記号によって情報を表現しているが、これらの評価に対応する数値が記録されてもよい。なお、情報は到着予定日や時間を表す数値でもよい。

項目１９４は、料金の欄である。例えば送料は販売会社に応じて異なる可能性があるためである。図１４では、送料などの料金が安い場合を丸印で示し、次に安い場合をバツ印で示している。
項目１９５は、物品の状態の欄である。新品の場合には必要ないが中古の場合には必要になる。図１４では良品を丸印で示し、品質がよくない場合をバツ印で示している。

項目１９６は、評判の欄である。図１４では評判のよい販売会社を丸印で示し、次に評判がよい販売会社を三角印で示している。
ここでの項目１９３〜１９６がユーザの優先設定に対応する。
項目１９７は、ユーザが最初に希望した販売会社が属するポータル運営企業の欄である。項目１９８は、提携先の販売会社が属するポータル運営企業の欄である。いずれも販売会社とポータル運営企業が異なる場合があるためである。
項目１９９と項目２００は、斡旋元への対価（斡旋料）の額を表す欄である。ただし、項目１９９は販売会社に対する斡旋料であり、項目２００はポータル運営企業に対する斡旋料である。
項目２０１は、ユーザへの対価（報奨金）の額を表す欄である。

図１３の説明に戻る。
ステップ２０８の実行後、販売制御部１０１Ａは、提示された候補について販売が可能か否かを判定する（ステップ２０９）。
ステップ２０９で否定結果が得られた場合、販売制御部１０１Ａは、ステップ２０７に戻る。例えば優先設定を外して他の候補を提示する。
ステップ２０９で肯定結果が得られた場合、販売制御部１０１Ａは、販売を確定し（ステップ２１０）、管理データを更新する（ステップ２１１）。

なお、ステップ２０７で否定結果が得られた場合（優先設定がない場合）、販売制御部１０１Ａは、紐付けられている提携先の物品の候補を提示する（ステップ２１２）。
例えば販売制御部１０１Ａは、管理テーブル１９０（図１４参照）の項目１９２（図１４参照）を参照し、１つ又は複数の提携先について希望の条件を満たす物品の候補を検索してユーザに提示する。
なお、斡旋による販売が完了した時点で、Ａ１社は販売が成立した提携先に宛てて販売の成立を通知してもよい。通知は予め定めた件数の成立毎にまとめて行ってもよい。
また、斡旋料は斡旋のたびに清算してもよいし、月単位で清算してもよい。なお、清算自体は事前の契約に基づく条件に基づいて計算される金額によって行ってもよい。

＜操作画面の例＞
ここでは、ユーザが操作するユーザ端末４（図１参照）に表示される操作画面の例を説明する。
図１５は、物品を購入する過程で表示される一連の操作画面の例を説明する図である。（Ａ）は自社で提供可能な物品の提示画面２１１であり、（Ｂ）は提携先が提供する物品の候補を提示する画面２１２であり、（Ｃ）は提携先で提供可能な物品の提示画面２１３であり、（Ｄ）は購入設定画面２１４であり、（Ｅ）は購入完了時の画面２１５である。

図１５に示す提示画面２１１では、希望の条件として物品名（商品名）だけが与えられた場合の例である。
画面２１２は、ユーザが指定したパソコン〇〇を販売できないため、提携先を対象とする検索によって見つかった商品の候補が提示されている。この例では、販売企業Ｂ１が提示されている。なお、提携先の並びは例えばユーザの優先設定との合致度に応じて決めてもよいし、斡旋料に応じて決めてもよい。また、別途計算される評価値が高い順番としてもよい。

提示画面２１３は、ユーザが販売企業Ｂ１の販売するパソコン〇〇を指定した場合の画面である。この画面で購入画面をクリックすると購入設定画面２１４が表示される。この例では、希望の条件を満たすパソコンが候補として提示されているので、購入設定画面２１４で購入依頼を出すと、購入完了時の画面２１５が表示される。
このように、ユーザは、販売企業Ｂ１を通じて物品（パソコン〇〇）を購入する場合でも、Ａ社１の購入サイトにアクセスするだけでよい。また、希望の条件を入力し直す必要もない。

＜実施の形態の効果＞
本実施の形態で説明した手法を用いれば、ユーザは、購入を希望する販売企業Ａ１の販売サイトにアクセスして希望の条件を入力することで、販売企業Ａ１が販売する物品を優先的に検索できる。そして、販売企業Ａ１から物品を購入できない場合でも、ユーザは、販売企業Ａ１の販売サイトを通じて提携先である販売企業Ｂ１から物品を購入することができる。

従前の販売サイトの場合であれば、今回の提携グループ（Ａ１社、Ｂ１社）だけでなくＣ１社、Ｄ１社、Ｅ１社も含めて候補が提示され、しかも提示される順番は購入したいＡ１社が上位に位置するとは限らない。また、購入の経験がない又は関心がないＣ１社、Ｄ１社、Ｅ１社が販売する物品についても候補として提示されてしまう。
しかし、本実施の形態の場合には、ユーザが購入したいＡ１社が提供する物品だけが候補として最初に提示され、希望の条件を満たさない場合でも、Ａ１社との提携により同等の品質を期待できるＢ１社から物品を購入することができる。

なお、提携グループを構成するＡ１社とＢ１社にとっても、自社の販売サイトにアクセスしたユーザに対しては自社の物品の提示を優先できるので、自社の成約数を上げることができる。また、提携先にユーザを斡旋する場合でも、自社の販売サイトを通じて購入を受け付けることができるので、ユーザの期待に応えることができる。
一方、提携先にあっては、提携している他者からの斡旋を通じて販売の機会を増やすことができるので、成約数を上げることができる。

＜実施の形態３＞
前述の実施の形態１では時間貸し空間３の予約を想定したが、本実施の形態では、サービスの販売を想定する。
＜システムの概要＞
図１６は、実施の形態３で想定するサービスの販売の仕組みを説明する図である。
図１６には図１１との対応部分に対応する符号を付して示している。
図１６の例では、サービスの販売に関係のある端末だけを表している。図１６の場合、５つのサービス管理サーバ５Ａ２、５Ｂ２、５Ｃ２、５Ｄ２、５Ｅ２が存在する。サービス売管理サーバ５Ａ２、５Ｂ２、５Ｃ２、５Ｄ２、５Ｅ２は、サービス提供サイトを運営しているＡ２社、Ｂ２社、Ｃ２社、Ｄ２社、Ｅ２社に対応する。

本実施の形態におけるサービス事業者は、サービスの提供者自身の場合だけでなく、特定の提供者のためにサービスの販売を代行する代理店でもよい。なお、提供者は個人でも企業体でもよい。
本実施の形態の場合、サービスとは、英会話教室、音楽教室、幼児教室、個人学習指導などの教育サービス、エステ、散髪、美容などの理容サービス、病院、クリニック、健康診断などの医療サービス、クリーニングサービス、各種の配送サービスなどを含んでいる。
本実施の形態では、これら５社のうち、Ａ２社とＢ２社が互いに提携し、Ｃ２社とＤ２社とＥ２社は独立してサービスを運営しているものとする。

本実施の形態における提携とは、サービスの購入のためにユーザの最初のアクセスを受けた事業者が、自社では希望のサービスを提供できない場合に、サービスの提供機会を融通し合う補完関係をいう。
この実施の形態の場合、提携先はサービス毎に定めてもよいし、事業者単位（事業者としての個人を含む）で定めてもよい。
なお、ポータル事業者の場合には、同業者を提携先としてもよいし、代行している個々の提供者を提携先としてもよい。
図１６の例であれば、Ａ２社とＢ２社は、提供するサービスを互いに融通し合う関係にある。
図１６では、ユーザが、Ａ２社のサービス提供サイトにアクセスした場合を想定している。このため、ユーザ端末４からサービス管理サーバ５Ａ２に向かう矢印１３１が描かれている。

本実施の形態の場合、サービス管理サーバ５Ａ２は、希望の条件を満たすサービスの検索を２段階に実行する。
１段目は、自社が提供するサービスを対象とする検索である。サービス提供サイトへのアクセスには、アクセス先であるＡ２社からサービスの提供を受けたいというユーザの暗黙の希望が認められるためである。
２段目は、提携先が提供するサービスを対象とする検索である。Ａ２社がサービスを提供できない場合でも、提携先を通じて自社と同等のサービスをユーザに提供するためである。
この場合、ユーザは、Ｂ２社のサービス提供サイトにアクセスして希望の条件を入力し直さなくても、自身がアクセスしたＡ２社のサービス提供サイトを通じてサービスを購入できる。
また、ユーザは、アクセス先であるＡ２社を通じてＢ２社のサービスを購入できるので、Ａ２社と同等のサービスの提供を期待できる。
なお、図中の矢印１３２は、条件を満たすサービスをＡ２社が販売できないが、Ｂ２社がサービスを提供可能な場合の斡旋の向きを表している。
図１６では、提携関係にないＣ２社とＤ２社とＥ２社への斡旋は生じないので矢印にバツ印をつけて描いている。

＜サービス管理サーバの構成＞
ここでは、サービス管理サーバ５Ａ２の構成例について説明する。因みに、サービス管理サーバ５Ａ２のハードウェア構成は図４に示す構成と同様である。
図１７は、ＣＰＵ５１Ａ（図４参照）のソフトウェア構成の例を説明する図である。
この実施の形態の場合、ＣＰＵ５１Ａは、プログラムの実行を通じてサービス提供制御部１０１Ｂとして機能する。サービス提供制御部１０１Ｂは、特許請求の範囲における通知手段の一例である。

サービス提供制御部１０１Ｂは、複数の機能によって構成されている。
例えば本実施の形態の場合、サービス提供制御部１０１Ｂは、ユーザが希望する条件を受け付ける希望条件受付部１０２Ｂと、自社で提供するサービスを優先的に検索する優先先検索部１０３Ｂと、自社で提供するサービスをユーザに提供できない場合に、提携する特定の事業者が提供するサービスを検索する提携先検索部１０４Ｂと、条件に該当したサービスをユーザに提示する候補提示部１０５Ｂと、提携する特定の事業者との間で販売が成立した場合に自社からの斡旋の事実を記録する斡旋記録部１０６Ｂと、を有している。

希望条件受付部１０２Ｂは、例えばユーザ端末４（図１参照）を通じて希望の条件を受け付ける機能を提供する。
優先先検索部１０３Ｂは、自社が提供するサービスを対象とした検索を実行する。
提携先検索部１０４Ｂは、自社がサービスを提供できない場合に用いられる機能である。提携先検索部１０４Ｂは、自社が提携している特定の事業者が提供するサービスを対象とした検索を実行する。

候補提示部１０５Ｂは、優先先検索部１０３Ｂ又は提携先検索部１０４Ｂで検索された、希望の条件を満たしたサービスを候補として提示する。本実施の形態では、自社又は提携先のいずれかにおいて、希望の条件を満たすサービスが見つからない場合、代替的な候補を提示する。
斡旋記録部１０６Ｂは、自社のサイトにアクセスしたユーザに対して、提携先のサービスを斡旋し、販売が成立した場合に斡旋の事実を記録する。
本実施の形態の場合、この記録は、販売が成立した提携先の事業者から斡旋に対する対価を受け取るために使用される。また、自社が提供するサービスを使用できなかったユーザに対する対価の付与に使用される。ここでの対価は、金銭の場合もあれば、いわゆるポイントの場合もある。
なお、ユーザに対する対価は運用上の理由によるものである。

＜制御例＞
図１８は、ユーザがアクセスしたサービス提供サイト（サービス管理サーバ）のサービス提供制御部１０１Ｂで実行される処理動作の例を説明するフローチャートである。
以下では、Ａ２社のサービス管理サーバ５Ａ２（図１６参照）にユーザがアクセスしたものとして説明する。
まず、サービス提供制御部１０１Ｂは、希望の条件を受け付ける（ステップ３０１）。希望の条件として、例えばサービス名が入力される。
次に、サービス提供制御部１０１Ｂは、入力された希望の条件に基づいて、自社（Ａ２社）で提供するサービスを検索する（ステップ３０２）。希望の条件を満たすサービスが複数見つかった場合、サービス提供制御部１０１Ｂは、それらを候補としてユーザに提示する。なお、受け付けられる数が限られている場合には、候補を提示する際に、候補に対する他のユーザの購入を受け付けないように処理してもよい。
続いて、サービス提供制御部１０１Ｂは、提示された候補に対するユーザの指定を受け付ける（ステップ３０３）。

サービス提供制御部１０１Ｂは、指定された候補の提供が可能か否かを判定する（ステップ３０４）。提供が可能である場合（ステップ３０４で肯定結果の場合）、サービス提供制御部１０１Ｂは、販売を確定し（ステップ３０５）、管理データを更新する（ステップ３０６）。
一方、指定された候補を販売できない場合（ステップ３０４で否定結果の場合）、サービス提供制御部１０１Ｂは、提携先が提供するサービスを対象とする検索動作に移行する。
なお、ステップ３０２における検索の結果、希望の条件を満たす候補が存在しなかった場合には、ステップ３０３を飛ばしてステップ３０４の判定が実行され、否定の結果が得られる。

検索に先立ち、サービス提供制御部１０１Ｂは、ユーザによる優先設定があるか否かを判定する（ステップ３０７）。
優先設定は、提携先が提示される場合に、どの条件を優先するかについての設定である。例えば提供可能日や時間、料金（１回あたりや単位時間あたり）、評判、サービスの提供先までの距離や時間等が事前に設定される。
ステップ３０７で肯定結果が得られた場合（優先設定があった場合）、サービス提供制御部１０１Ｂは、ユーザの優先設定と紐付けられている提携先に基づいてサービスの候補を提示する（ステップ３０８）。

図１９は、サービス提供制御部１０１Ｂが参照する管理テーブル（優先設定を含む）の例を説明する図である。
図１９に示す管理テーブル２３０は、提供企業Ａ２と提供企業Ｂ２が共通に使用するテーブルの例を表している。管理テーブル２３０は、複数の項目２３１〜２４１で構成されている。
項目２３１は、ユーザが最初に希望したサービス提供企業の覧である。図１９では、ユーザがＡ２社のサービス管理サーバ５Ａ２（図１６参照）にアクセスした場合を太線で囲んで示している。
項目２３２は、紐付けられている提供企業の欄である。図１９では、提供企業Ａ２に対しては提供企業Ｂ２が紐付けられ、提供企業Ｂ２には提供企業Ａ２が紐付けられている。なお、提携先が複数ある場合には、複数の提供企業が列記される、又は、列を改めて提供企業毎に記載される。

項目２３３は、提供可能日または時間に関する情報の表示に使用される。図１９の例では、提供可能日又は日時が早い場合を二重丸で表し、次に早い場合を三角印で表している。図１９では記号によって情報を表現しているが、これらの評価に対応する数値が記録されてもよい。なお、情報は提供可能日や時間を表す数値でもよい。

項目２３４は、料金の欄である。ここでは、料金が安い場合を丸印で示し、高い場合をバツ印で示している。
項目２３５は、評判の欄である。図１９では評判のよい提供企業を丸印で示し、評判がよくない提供企業をバツ印で表している。
項目２３６は、サービスの提供先までの距離や時間の欄である。なお、ユーザの位置から提携先までの移動に要する料金の欄を別途設けてもよい。図１９では距離が近い場合を二重丸で示し、次に近い場合を丸印で示している。
ここでの項目２３３〜２３６がユーザの優先設定に対応する。
項目２３７は、ユーザが最初に希望した提供企業が属するポータル運営企業の欄である。項目２３８は、提携先の提供企業が属するポータル運営企業の欄である。いずれも販売会社とポータル運営企業が異なる場合があるためである。
項目２３９と項目２４０は、斡旋元への対価（斡旋料）の額を表す欄である。ただし、項目２３９は提供企業に対する斡旋料であり、項目２４０はポータル運営企業に対する斡旋料である。
項目２４１は、ユーザへの対価（報奨金）の額を表す欄である。

図１８の説明に戻る。
ステップ３０８の実行後、サービス提供制御部１０１Ｂは、提示された候補について提供が可能か否かを判定する（ステップ３０９）。
ステップ３０９で否定結果が得られた場合、サービス提供制御部１０１Ｂは、ステップ３０７に戻る。例えば優先設定を外して他の候補を提示する。
ステップ３０９で肯定結果が得られた場合、サービス提供制御部１０１Ｂは、販売を確定し（ステップ３１０）、管理データを更新する（ステップ３１１）。

なお、ステップ３０７で否定結果が得られた場合（優先設定がない場合）、サービス提供制御部１０１Ｂは、紐付けられている提携先のサービスの候補を提示する（ステップ３１２）。
例えばサービス提供制御部１０１Ｂは、管理テーブル２３０（図１９参照）の項目２３２（図１９参照）を参照し、１つ又は複数の提携先について希望の条件を満たすサービスの候補を検索してユーザに提示する。
なお、斡旋による販売が完了した時点で、提供企業Ａ２は販売が成立した提携先に宛てて販売の成立を通知してもよい。通知は予め定めた件数の成立毎にまとめて行ってもよい。
また、斡旋料は斡旋のたびに清算してもよいし、月単位で清算してもよい。なお、清算自体は事前の契約に基づく条件に基づいて計算される金額によって行ってもよい。

＜操作画面の例＞
ここでは、ユーザが操作するユーザ端末４（図１参照）に表示される操作画面の例を説明する。
図２０は、サービスを購入する過程で表示される一連の操作画面の例を説明する図である。（Ａ）は自社で提供可能なサービスの提示画面２５１であり、（Ｂ）は提携先を提示する画面２５２であり、（Ｃ）は提携先で提供可能なサービスの提示画面２５３であり、（Ｄ）は購入設定画面２５４であり、（Ｅ）は購入完了時の画面２５５である。

図２０に示す提示画面２５１では、希望の条件としてサービス名だけが与えられた場合の例である。図２０の例では、１回２０００円の英会話教室が候補として提示されている。
画面２５２は、ユーザが指定したサービス（英会話教室）を提供できないため、提携先を対象とする検索によって見つかったサービスの候補が提示されている。この例では、提供企業としてＢ２社が提示されている。なお、提携先の並びは例えばユーザの優先設定との合致度に応じて決めてもよいし、斡旋料に応じて決めてもよい。また、別途計算される評価値が高い順番としてもよい。

提示画面２５３は、ユーザがＢ２社の提供するサービスを指定した場合の画面である。この場面で購入画面をクリックすると購入設定画面２５４が表示される。この例では、希望の条件を満たすサービスが候補として提示されているので、購入設定画面２５４で購入依頼を出すと、購入完了時の画面２５５が表示される。
このように、ユーザは、Ｂ２社を通じてサービスの提供を受ける場合でも、Ａ社２のサービス提供サイトにアクセスするだけでよい。また、希望の条件を入力し直す必要もない。

＜実施の形態の効果＞
本実施の形態で説明した手法を用いれば、ユーザは、提供を希望するＡ２社のサービス提供サイトにアクセスして希望の条件を入力することで、Ａ２社の提供するサービスを優先的に検索できる。そして、Ａ２社からサービスの提供を受けられない場合でも、ユーザは、Ａ２社のサービス提供サイトを通じて提携先であるＢ２社からサービスの提供を受けることができる。

従前の販売サイトの場合であれば、今回の提携グループ（Ａ２社、Ｂ２社）だけでなくＣ２社、Ｄ２社、Ｅ２社も含めて候補が提示され、しかも提示される順番は提供を受けたいＡ２社のサービスが上位に位置するとは限らない。また、購入の経験がない又は関心がないＣ２社、Ｄ２社、Ｅ２社が販売するサービスについても候補として提示されてしまう。
しかし、本実施の形態の場合には、ユーザが提供を受けたいＡ２社が提供するサービスだけが候補として最初に提示され、希望の条件を満たさない場合でも、Ａ２社との提携により同等の品質を期待できるＢ２社からサービスの提供を受けることができる。

なお、提携グループを構成するＡ２社とＢ２社にとっても、自社のサービス提供サイトにアクセスしたユーザに対しては自社のサービスの提示を優先できるので、自社の成約数を上げることができる。また、提携先にユーザを斡旋する場合でも、自社のサービス提供サイトを通じて購入を受け付けることができるので、ユーザの期待に応えることができる。
一方、提携先にあっては、提携している他者からの斡旋を通じて販売の機会を増やすことができるので、成約数を上げることができる。

＜他の実施形態＞
以上、本発明の実施の形態について説明したが、本発明の技術的範囲は上述の実施の形態に記載の範囲には限定されない。上述の実施の形態に、種々の変更又は改良を加えたものも、本発明の技術的範囲に含まれることは、特許請求の範囲の記載から明らかである。

また、管理システム１（図１参照）は前述した構成に限らない。図２１は、管理システム１Ａの他の構成例を示す図である。図２１には、図１と対応する部分に対応する符号を付して示している。管理システム１Ａは、複数の時間貸し空間３を管理する拠点サーバ２７１を用いる点で管理システム１（図１）と異なっている。コンピュータの構成を有する拠点サーバ２７１は、プログラムの実行を通じて予約制御部１０１（図６参照）等の機能を実行してもよい。この意味において、拠点サーバ２７１は、特許請求の範囲における装置の一例である。

前述の実施の形態においては、時間貸しされる空間として図２に示すように防音性能を備える小部屋を想定したが、利用の際に同様の状況が起こり得る空間であれば、例えば貸し会議室、学習室、各種の客室にも適用できる。
前述の実施の形態では、扉３２が施錠可能な場合を前提に説明しているが、前述した制御機能は、扉３２が施錠できない場合にも利用できる。
前述の実施の形態では、時間貸しされる空間を前提としているが、必ずしも時間単位で貸し出される空間でなくてもよい。

１、１Ａ…管理システム、２…クラウドネットワーク、３…時間貸し空間、４…ユーザ端末、５…予約管理サーバ、５Ａ〜５Ｅ…予約管理サーバ、５Ａ１〜５Ｅ１…販売管理サーバ、５Ａ２〜５Ｅ２…サービス管理サーバ、６…空間管理サーバ、７…請求管理サーバ、８…会員管理サーバ、１０１…予約制御部、１０１Ａ…販売制御部、１０１Ｂ…サービス提供制御部、１０２…予約条件受付部、１０２Ａ、１０２Ｂ…希望条件受付部、１０３、１０３Ａ、１０３Ｂ…優先先検索部、１０４、１０４Ａ、１０４Ｂ…提携先検索部、１０５、１０５Ａ、１０５Ｂ…候補提示部、１０６、１０６Ａ、１０６Ｂ…斡旋記録部

Claims (20)

1. 利用者のアクセス先となった第１の提供者が提供する第１の商品を候補として利用者に通知し、当該第１の商品を提供できない場合、予め定めた第２の提供者が提供する第２の商品を候補として利用者に通知する通知手段
   を有する装置。
2. 前記第１の商品及び前記第２の商品は、予約の対象となる空間である、請求項１に記載の装置。
3. 前記第１の商品及び前記第２の商品は、扉の開閉を通じて出入りできる空間である、請求項２に記載の装置。
4. 前記第１の商品及び前記第２の商品は、壁で囲まれた空間である、請求項２に記載の装置。
5. 前記第２の商品は、利用者が希望する前記第１の商品について予め紐付けられている、請求項１に記載の装置。
6. 利用者が希望した前記第１の商品は、検索の条件を満たす候補の中から利用者によって指定される、請求項５に記載の装置。
7. 利用者が希望した前記第１の商品は、前記第１の提供者が用意した候補の中から利用者によって指定される、請求項５に記載の装置。
8. 前記候補として通知が可能な前記第２の商品が複数ある場合、前記通知手段は、評価が高い順番に当該第２の商品を通知する、請求項１に記載の装置。
9. 前記第１の商品及び前記第２の商品が予約の対象となる空間である場合、利用者の現在の位置から当該第２の商品である空間への移動の時間が短い候補の評価が高く設定される、請求項８に記載の装置。
10. 前記第１の商品及び前記第２の商品が予約の対象となる空間である場合、利用者が指定した当該第１の商品である空間から当該第２の商品である空間への移動の時間が短い候補の評価が高く設定される、請求項８に記載の装置。
11. 前記第１の商品及び前記第２の商品が予約の対象となる空間である場合、当該第２の商品である空間への移動に伴い発生する実費用が少ない候補の評価が高く設定される、請求項８に記載の装置。
12. 前記実費用は、利用者が支払う交通費である、請求項１１に記載の装置。
13. 前記実費用は、前記第２の商品の利用に対して利用者に付与される対価と利用者が支払う交通費との差額である、請求項１１に記載の装置。
14. 成約に伴い発生する利益が大きい候補の評価が高く設定される、請求項８に記載の装置。
15. 前記通知手段は、前記第１の商品を提供できない場合に使用する条件が定められている場合、当該条件に従って候補として通知する前記第２の商品を特定する、請求項１に記載の装置。
16. 前記条件は、前記第１の商品及び前記第２の商品が予約の対象となる空間である場合、利用者が指定した空間から移動に要する時間である、請求項１５に記載の装置。
17. 前記条件は、前記第１の商品及び前記第２の商品が予約の対象となる空間である場合、移動に伴い発生する実費用である、請求項１５に記載の装置。
18. 前記条件は、成約に伴い発生する利益である、請求項１５に記載の装置。
19. 利用者のアクセス先となった第１の提供者が提供する第１の商品を候補として利用者に通知し、当該第１の商品を提供できない場合、予め定めた第２の提供者が提供する第２の商品を候補として利用者に通知する通知手段と、
    前記第１の商品の管理データを保持する第１のデータベースと、
    前記第２の商品の管理データを保持する第２のデータベースと
    を有する管理システム。
20. コンピュータを、
    利用者のアクセス先となった第１の提供者が提供する第１の商品を候補として利用者に通知し、当該第１の商品を提供できない場合、予め定めた第２の提供者が提供する第２の商品を候補として利用者に通知する通知手段
    として機能させるプログラム。

Images