JP2020091899A

JP2020091899A - 情報処理装置の制御方法、情報処理装置および制御プログラム

Info

Publication number: JP2020091899A
Application number: JP2020030634A
Authority: JP
Inventors: イルグイ; Ilgu Lee; 雄介片桐; Yusuke Katagiri
Original assignee: Line Corp
Current assignee: Z Intermediate Global Corp
Priority date: 2020-02-26
Filing date: 2020-02-26
Publication date: 2020-06-11

Abstract

【課題】予約を希望するユーザに予約が競合するユーザの情報を通知する等、予約譲渡を効果的に実現し、利便性の高い情報処理装置の制御方法、情報処理装置および制御プログラムを提供する。【解決手段】情報処理装置の制御方法は、端末とネットワークを介して接続された情報処理装置の制御方法であって、ユーザの予約情報を記憶するステップと第１のユーザ端末から予約要求を受信するステップと、記憶されている予約情報のうち、予約要求に含まれる予約対象、予約リソース数および予約時間に基づいて、予約要求と全部または一部が競合する予約情報を検索するステップと、検索の結果、競合する予約情報が存在するときは、当該競合する予約情報から第１のユーザ端末を保有するユーザに譲渡可能な予約情報を抽出するステップと、検索の結果または抽出の結果の少なくともいずれか一つを、第１のユーザ端末に送信するステップとを含む。【選択図】図８ａ

Description

本発明は、情報処理装置の制御方法、情報処理装置および制御プログラムに関し、特に予約を希望するユーザに予約譲渡を実現することできるサービスシステムに係る情報処理装置の制御方法、情報処理装置および制御プログラムに関する。

近年、レストランやヘアサロン等への予約にあたって、コンシェルジュ等の専門家がクライアントの希望にそったお店とその空き状況を検索して、予約の代行までを行うサービスが普及している。また、ＩＴ化に伴い、クライアントが簡易的に当該サービスに利用できるようにするために、また、専門家の負担を軽減するために、オンライン上でクライアントの希望にそったお店とその空き状況の検索や予約を行うシステムが増加している。

このような予約サービスにおいて、希望のお店の予約に空きがないとき、クライアントはこのお店への予約を諦めるか、キャンセル待ちをせざるを得ず、クライアントの希望どおりの予約をすることが困難な場合があった。

このような問題を解決するための技術として、例えば、特許文献１には、電車等の交通機関等において、座席を占有中のユーザが、他のユーザに離席する時期を示す情報を送信し、それに対して、当該他のユーザが座席を占有するユーザに予約を申し込んで交渉し、交渉が成立すると当該座席の予約状況を更新し、ユーザ間で座席が譲渡されることが開示されている。

また、特許文献２には、会議室等での予約において、自身の予約をカレンダ表示し、当該カレンダ表示のうち、自身が予約している会議室ごとの時間枠において、指定したユーザに譲渡する技術が開示されている。

さらに、特許文献３には、電子チケットの譲渡において、チケットＩＤおよびユーザ情報を埋め込んだ電子チケットを利用し、当該電子チケットを他のユーザに譲渡した際に、譲渡先のユーザに譲渡元のユーザの個人情報を知られることなく電子チケットの譲渡を可能とする技術が開示されている。

特開２００３− ９９６５４公報特開２００２−１４９９２８公報特開２００５−３５２７８６公報

しかしながら、特許文献１〜３に記載の発明では、いずれの発明についても、予約を譲渡してもらえるユーザを自ら探して特定した上で譲渡依頼または譲渡の打診等をしなくてはならないという前提がある。予約の空き状況がない中で予約を希望するユーザは、自身の希望する予約対象と時間帯を占有しているユーザを探す必要があった。

また、予約を希望するユーザが、自身の希望する予約対象と時間帯を占有するユーザを探して見つけたとしても、当該ユーザから譲渡してもらえる見込みがあるかどうか（譲渡する意志があるかどうか）、実際に直接交渉しないと分からないという問題がある（特許発明１および２については、譲渡人側からこれらの発明に係るシステムで譲渡を指定することで、譲渡のやり取り等が発生する発明であり、譲渡を希望する（譲受人）側から当該システムで譲渡を指定して譲渡のやり取り等が発生するものではない）。

また、特許文献１〜３に記載の発明は、予約内容の全てまたは一部を同一人に譲渡しなければならないという問題がある。例えば、予約している時間帯を分割して２以上のユーザに譲渡するといった予約の譲渡ができず、その汎用性に乏しいという問題がある。

そこで、本発明は、上記問題に鑑みてなされたものであり、予約を希望するユーザに、予約が競合するユーザ情報と、当該競合するユーザのうち予約の譲渡が可能なユーザを示す情報を通知し、効果的にユーザ間の予約譲渡を実現することできるサービスシステムに係る情報処理装置の制御方法、情報処理装置および制御プログラムを提供することを目的とする。

本発明に係る情報処理装置の制御方法は、端末とネットワークを介して接続された情報処理装置の制御方法であってユーザの予約情報を記憶する記憶ステップと第１のユーザ端末から予約要求を受信する第１の受信ステップと、記憶されている予約情報のうち、予約要求に含まれる予約対象、予約リソースおよび予約時間に基づいて、予約要求と全部または一部が競合する予約情報を検索する検索ステップと、検索の結果、競合する予約情報が存在するときは、当該競合する予約情報から第１のユーザ端末を保有するユーザに譲渡可能な予約情報を抽出する抽出ステップと、検索の結果または抽出の結果の少なくともいずれか一つを、第１のユーザ端末に送信する第１の送信ステップとを含む。

さらに、本発明に係る情報処理装置の制御方法において、予約情報は、予約譲渡に対するインセンティブ情報を含み、抽出ステップは、さらに、インセンティブ情報に基づいて譲渡可能な予約情報か否か判定し、抽出するものであってもよい。

さらに、本発明に係る情報処理装置の制御方法において、検索ステップは、さらに、競合する予約情報が存在するときは、予約要求に含まれる予約対象、予約リソース数および予約時間に基づいて、所定の範囲内にある予約対象の空き時間または予約対象に類似する予約対象の空き時間の少なくともいずれか一つを検索し、第１の送信ステップは、さらに、検索の結果を第１のユーザ端末に送信するものであってもよい。

さらに、本発明に係る情報処理装置の制御方法において、予約情報は、予約リソース数を含み、抽出ステップは、予約要求に含まれる予約リソース数と、譲渡可能な予約情報の予約リソース数を比較して、これらの予約リソース数の差分が一致または所定の範囲内にある譲渡可能な予約情報の優先度を高くするよう、譲渡可能な予約情報の優先度を判定し、第１の送信ステップは、譲渡可能な予約情報に判定した優先度を設定して送信するものであってもよい。

さらに、本発明に係る情報処理装置の制御方法は、第１のユーザ端末から予約の交渉要求を受信する第２の受信ステップと、交渉要求を、譲渡可能な予約情報に係る第２のユーザ端末に送信する第２の送信ステップと、第２のユーザ端末から、交渉要求に対する交渉回答情報を受信する第３の受信ステップと、交渉回答情報に基づいて、第１のユーザ端末または第２のユーザ端末の少なくともいずれか一つに、トークルームの開設通知または交渉回答情報の少なくともいずれか一つを送信する第３の送信ステップとをさらに含むものであってもよい。

また、本発明に係る情報処理装置の制御方法は、第１のユーザ端末から特定のユーザをトークルームに追加することを要求するユーザ追加要求を受信する第４の受信ステップと、ユーザ追加要求で指定されたユーザが保有する第３のユーザ端末にトークルームへの参加を要求するトークルーム参加要求を送信する第４の送信ステップと、第３のユーザ端末から、参加要求に対する参加回答情報を受信する第５の受信ステップと、参加回答情報に基づいて、第３のユーザ端末にトークルームの開設通知を送信する第５の送信ステップと含むものであってもよい。

さらに、本発明に係る情報処理装置の制御方法は、第１のユーザ端末から予約の譲渡要求または予約の確定要求を受信する第６の受信ステップと、譲渡要求または予約の確定要求に基づいて、予約情報を更新する更新ステップと、更新結果を、第１のユーザ端末および第２のユーザ端末に送信する第６の送信ステップとをさらに含むものであってもよい。

さらに、本発明に係る情報処理装置の制御方法は、更新ステップ以前に、第２のユーザ端末に予約への譲渡承認要求を送信する第７の送信ステップと、第２のユーザ端末から譲渡承認要求に対する承認回答情報を受信する第７の受信ステップとをさらに含み、更新ステップは、承認回答情報に基づいて、予約情報を更新するものであってもよい。

さらに、本発明に係る情報処理装置の制御方法は、譲渡可能な予約対象に係る第４のユーザ端末に、譲渡要求または承認回答情報に基づいて生成する予約の譲渡許可要求を送信する第８の送信ステップと、第４のユーザ端末から、譲渡許可要求に対して許可するか否かの判定情報を含む許可回答情報を受信する第８の受信ステップとをさらに含み、更新ステップは、さらに、許可回答情報に基づいて、予約情報を更新するものであってもよい。

さらに、本発明に係る情報処理装置の制御方法において、記憶ステップは、さらに、ユーザごとの予約回数、予約実行回数、予約キャンセル回数または予約譲渡回数の少なくともいずれか一つ含む予約実績情報を記憶し、本発明に係る情報処理装置の制御方法は、譲渡可能な予約情報に係る第４のユーザ端末から、予約どおりに実行されたか否かを判定する判定情報を受信する第９の受信ステップと、受信した判定情報に基づいて、当該判定情報に紐づく予約実績情報の予約実行回数または予約キャンセル回数の少なくともいずれか一つを更新する予約実績更新ステップとをさらに含み、更新ステップは、さらに、譲渡要求または予約の確定要求に基づいて、予約回数または予約譲渡回数の少なくともいずれか一つを更新し、予約実績情報に基づいて、予約キャンセル回数、予約キャンセル回数から予約実行回数を差し引いた数、予約キャンセル率、予約譲渡回数、予約譲渡回数から予約実行回数を差し引いた回数、予約譲渡率の少なくともいずれか一つが所定の閾値を上回る場合は、譲渡要求を破棄し、第６の送信ステップは、当該破棄の結果を第１のユーザ端末に送信するものであってもよい。

本発明に係る情報処理装置は、端末とネットワークを介して接続された情報処理装置であって、ユーザの予約情報を記憶する記憶部と第１のユーザ端末から予約要求を受信する受信部と、記憶されている予約情報のうち、予約要求に含まれる予約対象、予約リソースおよび予約時間に基づいて、予約要求と全部または一部が競合する予約情報を検索する検索部と、検索の結果、競合する予約情報が存在するときは、当該競合する予約情報から第１のユーザ端末を保有するユーザに譲渡可能な予約情報を抽出する抽出部と、検索の結果または抽出の結果の少なくともいずれか一つを、第１のユーザ端末に送信する送信部とを備える。

本発明に係る制御プログラムは、端末とネットワークを介して接続されるコンピュータを制御するプログラムであって、ユーザの予約情報を記憶する記憶機能と第１のユーザ端末から予約要求を受信する受信機能と、記憶されている予約情報のうち、予約要求に含まれる予約対象、予約リソースおよび予約時間に基づいて、予約要求と全部または一部が競合する予約情報を検索する検索機能と、検索の結果、競合する予約情報が存在するときは、当該競合する予約情報から第１のユーザ端末を保有するユーザに譲渡可能な予約情報を抽出する抽出機能と、検索の結果または抽出の結果の少なくともいずれか一つを、第１のユーザ端末に送信する送信機能とをコンピュータにより実現させる。

上記のように構成された本発明の情報処理装置の制御方法によれば、端末とネットワークを介して接続された情報処理装置の制御方法であって、ユーザの予約情報を記憶する記憶ステップと第１のユーザ端末から予約要求を受信する第１の受信ステップと、記憶されている予約情報のうち、予約要求に含まれる予約対象、予約リソースおよび予約時間に基づいて、予約要求と全部または一部が競合する予約情報を検索する検索ステップと、検索の結果、競合する予約情報が存在するときは、当該競合する予約情報から他のユーザに譲渡可能な予約情報を抽出する抽出ステップと、検索の結果または抽出の結果の少なくともいずれか一つを、第１のユーザ端末に送信する第１の送信ステップを含むため、予約が競合する場合、予約を希望するユーザに、競合相手のユーザ情報と、当該競合相手のユーザのうち予約の全部または一部の譲渡が可能なユーザを示す情報を通知できるサービスシステムに係る情報処理装置の制御方法を提供することができる。これにより、予約を希望するユーザは、自身の希望する予約対象と時間帯を占有しているユーザおよび当該ユーザが譲渡可能であるか検索および確認する手間が省け、予約を希望するユーザに予約譲渡を効果的に実現し、利便性および合目的性の高いサービスを提供することができる。

サービスシステム構成を示すシステム図サーバ（情報処理装置）および端末の機能構成を示すブロック図予約要求メッセージのデータ構成例を示すデータ概念図予約情報のデータ構成例を示すデータ概念図予約実績情報のデータ構成例を示すデータ概念図予約の譲渡のやり取りの例を説明するための模式図（ａ）−（ｃ）は、予約の譲渡受付無効または破棄の例を示す模式図（ａ）−（ｃ）は、予約状況および予約の競合状況を示すタイムラインの例を示す模式図（ａ）−（ｃ）は、予約の譲渡の直接交渉でのやり取りの例を説明するための模式図予約情報の記憶から競合する予約の抽出結果の送信に係るサーバ（情報処理装置）の動作を示すフローチャート図予約の譲渡要求から予約情報の更新結果の送信に係るサーバ（情報処理装置）の動作を示すフローチャート図予約実績情報の更新に係るサーバ（情報処理装置）の動作を示すフローチャート図サーバ（情報処理装置）と端末間の情報のやり取りおよび処理の流れを示すシーケンス図サーバ（情報処理装置）と端末間の情報のやり取りおよび処理の流れを示すシーケンス図参考例に係るサーバ（情報処理装置）および端末の機能構成を示すブロック図

以下、本発明の一実施態様について、図面を参照しながら説明する。
＜概要＞
図１は、サービスシステム構成を示すシステム図である。

図１に示すように、当該サービスシステムは、サーバ（情報処理装置）１００、複数のユーザ端末２００Ａ、２００Ｂを含む。サーバ（情報処理装置）１００は、ネットワーク４００を介してユーザ端末２００Ａ、２００Ｂと接続される。なお、図１において、説明を簡単にするために、ユーザ端末は２台だけ示してあるが、これ以上存在してもよいことは言うまでもない。また、ユーザ端末２００の具体的な機器は、図示のように、スマートフォンに限定されず、例えば、携帯端末、タブレット端末、パーソナルコンピュータ、その他の電子機器であってもよい。なお、以下においては、特に区別の必要がない場合に、ユーザ端末を総省して、ユーザ端末２００と記載する。

ユーザ端末２００Ａ〜２００Ｂは、本発明の一実施形態によるサービスの一部であるチャットを、サービス側が提供するメッセージングアプリを搭載し、当該アプリを用いて行っている。なお、ユーザ端末２００Ａは、ユーザ端末２００Ｂおよび図示しないその他の複数のユーザ端末と共にグループを構成することもでき、グループ間でメッセージのやり取りを行うことができる。

なお、端末装置２００Ａは、端末装置２００Ｂを含まないグループに属していても良い。すなわち、各端末装置は、それぞれ他の端末装置と共に複数のグループを構成することができる。

サービスシステムは、レストランおよびサロン等のサービスの予約が可能な店舗や施設、会議室およびレンタルスペース等を貸与する企業等の予約サービスまたはタスクスケジュールを管理するタスク管理サービス等に用いることができる。ここで、一例として、サービスシステムを図４でレストランの予約サービスに用いた例について説明する。

例えば、ユーザが希望のレストランに予約する場合、図４（ａ）に示すようにユーザ端末２００に表示された画面の入力受付フィールドに従い、予約時間を「2015/11/15 19:00-21:00」と、予約リソース数（レストランやサロン等の予約であれば予約を希望する人数、タスク管理の予約であれば、工数等）を「5名」と、席・部屋情報（レストラン等の店舗であれば、カウンター席、窓際テーブル、個室、禁煙席、宴会席等の席情報、会議室等であれば、応接室、大規模会議室、集会室等の部屋情報）を「窓際テーブル」と、メニュー情報（レストラン等の店舗であれば、席の予約だけでなく、料理の予約をする際に対象の料理を示す情報、サロン等の店舗であれば、カット、カラー、パーマ、ネイル等の施術メニュー）を「季節の限定コース」と指定し、予約内容を設定することができる。また、併せて仮に予約が競合してしまった場合に備え、予めインセンティブ予算を設定することもできる。図４（ａ）で示すように、例えば、下限1,000円、上限3,000円と設定することができる。

ここで、「インセンティブ」とは、予約の競合が発生した際に、競合相手に予約の譲渡してもらうために支払われる金銭、メッセージングアプリで使用できるポイント等をいう。当該インセンティブを設けることで、ある店舗のある時間帯に行くことを強く希望するユーザに、既に予約をしている他のユーザが予約を譲渡する誘因となり、仮に競合が発生しても、予約を強く希望するユーザが諦めることなく、希望する店舗等に予約をすることができる。

上述の予約内容を条件として、「この条件で予約」表記する入力ボタンを押下すると、予約要求が実行される。予約要求が実行されると、図４（ｂ）に示すように、競合する予約が存在する場合には、「申し訳ございません。ご指定の条件は予約がいっぱいです。予約譲渡可能なユーザ情報等をご覧ください。」といった断りのメッセージを表示することができる。また、併せて予約状況として、競合する他のユーザと当該他のユーザの予約時間、自らの予約希望時間および競合している時間をタイムライン表で表示することで、どのユーザに予約の譲渡交渉をすればいいのか視覚的に容易に理解することができる。また、当該タイムライン表示の特定のユーザの予約時間エリアをタップ等して指定すると、詳細情報として、例えば「ユーザＣ ○完全譲渡のみ ○3,000円で譲渡可能」といった表示をドロップダウンメニューで表示し、譲渡交渉相手が設定したインセンティブ情報を確認することもできる。また、当該タイムライン表示の中に（例えば、特定のユーザの予約時間エリア内に）インセンティブ情報を表示してもよい。これにより、具体的に、予約の譲渡にあたってどの様な条件を満たせばいいのか、視覚的に容易に、また、ユーザの情報と併せて一度に確認することができる。なお、この時、例えば、競合相手のユーザ情報および当該ユーザのうち予約の譲渡が可能なユーザの情報を表示するにあたって、これらのユーザのプライバシーを考慮して、ユーザが特定されるような詳細な情報（例えば、ユーザ名、アイコン等）を非表示にして表示することもできる。

また、当該ドロップダウンメニューで当該ユーザと予約譲渡のための交渉を要求するための「交渉要求」ボタンや予約譲渡要求を実行する「譲渡要求」ボタンを入力受付機能として設けることもできる。さらに、併せて、予約譲渡だけではなく、指定した予約内容に類似する予約時間帯で空きがあれば「20:30〜22:30であれば予約可能です！」といった案内表示や類似する席で空きがあれば「窓から離れたテーブルであれば予約可能です！」といった案内表示を表示することもできる。予約時間に近い空き時間や予約対象の店舗等に類似する店舗情報を通知することで、単に予約が競合するため予約不可能であるとの通知をする従来技術と比較して、予約の選択の可能性および選択の幅を広げ、ユーザにとって利便性の高いサービスを提供することができる。

例えば、図４で示すように「譲渡要求」ボタンを押下して、譲渡要求を実行すると、一例として、図４（ｃ）で示すように、予約の譲渡が成立させ「○ユーザＣからの譲渡が成立しました！」と表示し、また、予約を確定させ「○2015-11-15（日）19:00〜21:00 5名窓際テーブル季節の限定コースで予約が確定しました。」と表示することができる。

これにより、サービスシステムを用いたレストラン予約サービスを利用するユーザは、予約が競合しているため、単に希望の予約を諦めるのではなく、競合するユーザを自身で検索せずに、予約の競合相手のユーザの情報および当該ユーザのうち予約の譲渡が可能なユーザの情報を確認することができる。ひいては、効率的に予約の譲渡によって希望の予約をすることができる。または、類似の予約を案内することで、希望に近い予約をすることができる。

ここで、一例として、タイムラインの例を、図６を用いて説明する。例えば、図６（ａ）で示すように、予約サービスにおいて、ユーザＡが18:00〜19:30に予約し、ユーザＢが18:30〜20:00に予約し、ユーザＣが20:30〜22:00に予約をしていた場合、ユーザが19:00〜21:00の予約時間を希望し予約要求を実行すると、希望する予約時間のうち、19:00〜20:00の時間区間および20:30〜21:00の時間区間について、予約の多重度（所定の時間区間における予約の重なっている数）により競合が発生していると判定することができる。当該例は、予約の多重度が１より大きくなった場合（予約の多重度が２以上の場合）に競合が発生していると判定しているが、当該判定における多重度の基準については、店舗等側の希望する席または予約リソース数を満たす席数、所有する会議室数、スタイリストの同時並行で施術できる人数等をふまえて、適宜設定すればよい。当該例においては、19:00〜20:00の時間区間においてはユーザＡおよびユーザＢに当該時間区間の予約を完全または部分譲渡してもらい、20:30〜21:00の時間区間についてはユーザＣに完全または部分譲渡してもらうことで、希望どおりの予約内容で予約をすることができる。

また、図６（ｂ）で示すように、予約サービスにおいて、ユーザＡが18:00〜20:00に予約し、ユーザＢが20:30〜22:00、ユーザＣが19:00〜21:00に予約し、予約の多重度の基準を２と設定していた場合、ユーザが19:00〜21:00の予約時間を希望し予約要求を実行すると、希望する予約時間のうち、予約の多重度が２より大きい時間区間（予約の多重度が３以上の時間区間）である19:00〜20:00の時間区間および20:30〜21:00の時間区間について予約の競合が発生していると判定することができる。当該例においては、いずれの時間区間においても、ユーザＡおよびユーザＢに当該時間区間の予約を完全または部分譲渡してもらうか、または、ユーザＣに完全譲渡してもらうことで、希望どおりの予約内容で予約をすることができる。

また、例えば、本発明をタスク管理サービスに用いる場合、ユーザが新規タスクを予約（登録）すると、当該タスクを実施する期間において別タスクとの重複がないか競合するタスクの存在を検索し、存在した場合には、さらにそのうちトレードオフが可能（譲渡が可能）なタスクを抽出することもできる。図６（ｃ）で示すように、例えばタスク管理サービスにおいて、多重度の基準を１と設定した場合、「●●会議」タスクに対し、「■■報告書作成」タスクは、19:00〜21:00の時間区間で重複するタスクとして抽出し、当該重複している状態を競合として判定してもよい。当該抽出にあたっては、タスクの緊急度および重要度に基づいて抽出可能か判定してもよい。

＜構成＞
以下、サーバ（情報処理装置）１００、ユーザ端末２００の構成について説明する。図２は、サーバ１００、ユーザ端末２００の機能構成を示すブロック図である。図２に示すように、サーバ１００は、通信部１１０と、制御部１２０と、記憶部１３０を含んで構成される。

通信部１１０は、受信部１１１および送信部１１２を備え、ネットワーク４００を介して、ユーザ端末２００との通信（各種データ、メッセージの送受信等）を実行する機能を有する。当該通信は、有線、無線のいずれでもよく、また、互いの通信が実行できるのであれば、どのような通信プロトコルを用いてもよい。ここで、「メッセージ」とは、テキストメッセージに限らず、画像、音声、動画、スタンプ（デジタルステッカー）等が含まれる。

受信部１１１は、ネットワーク４００を介して、各ユーザ端末２００からメッセージを受信し、当該メッセージに含まれるデータを制御部１２０に伝達する機能を有する。具体的には、例えば、受信部１１１は、予約譲渡の交渉要求、予約譲渡の交渉回答情報、トークルームのユーザ追加要求、トークルームの参加回答情報、予約の譲渡要求、予約譲渡の承認回答情報および予約譲渡の許可回答情報等を受信し、制御部１２０に伝達する。また、受信部１１１は、予約要求の受信の際に、受信した日時情報を当該要求に含まれるデータ（以下、「予約要求データ」という）に付与してから制御部１２０に伝達してもよい。例えば、受信部１１１は、ユーザ端末２００Ａからレストランの予約依頼をするための予約要求を受信した場合、当該予約要求データに、当該要求の受信日時情報を予約要求日時情報として付与し、制御部１２０に伝達してもよい。

ここで、「予約要求」とは、ユーザがレストラン、サロン等の様々な店舗等に予約をするためにサービスシステム１００に当該予約をオンライン上で依頼した際に受信するメッセージでもあり、また、それ以外にもサービスシステム１００が提供するタスク管理サービスにおいて、ユーザがサービスシステム１００にタスクの予約を依頼する際に受信するメッセージでもある。予約要求のメッセージの詳細は、後述の＜データ＞で示す。

また、受信部１１１は、制御部１２０の制御に従い、一つの予約またはタスクに対して複数の予約要求または予約の譲渡要求が要求された場合、当該要求をメッセージ・キュー（Message Queue）等に保存して、先に受信した要求が処理（例えば、更新部１２３による予約の更新処理または制御部１２０の制御による予約譲渡の承認処理もしくは却下処理等）されるまで、それ以降に受信した要求を保持してもよい。これにより、一つの予約またはタスクに対して複数の予約要求または予約の譲渡要求が要求された場合でも整合を図って、予約の更新または譲渡等の処理を行うことができる。

また、受信部１１１は、ユーザ端末２００から予約譲渡の交渉のための交渉要求を受信すると、制御部１２０の制御に従い、予約譲渡可能な予約情報に係る交渉相手のユーザが保有するユーザ端末２００に当該交渉要求を送信するよう、送信部１１２に伝達する。その後、受信部１１１は、制御部１２０の制御に従い、交渉相手のユーザのユーザ端末２００から当該交渉要求に対する交渉回答情報を受信すると、当該交渉回答情報の内容が交渉可能な旨の内容を含むものであれば、予約譲渡の交渉を希望するユーザおよび交渉相手のユーザの両方にユーザ端末２００にトークルームの開設通知を送信するよう、トークルームの開設通知を送信部１１２に伝達する。これにより、予約譲渡にあたって、交渉に係るユーザ間においてトークルーム上で直接交渉することができ、予約譲渡交渉を成立させることができる。

なお、当該トークルーム上での直接交渉において、新たなインセンティブ情報の設定入力をすることもできる。当該入力の詳細は、後述の表示部２１０で説明する。

一方、当該交渉回答情報の内容が交渉不可能な旨の内容を含むものであれば、受信部１１１は、制御部１２０の制御に従い、予約譲渡の交渉を希望するユーザに当該交渉が不可能な旨の交渉回答情報を送信するよう、当該交渉回答情報を送信部１１２に伝達する。これにより、交渉相手のユーザは直接交渉を拒否することもできる。

さらに、受信部１１１は、ユーザ端末２００から友達等の特定のユーザをトークルームに追加することを要求するユーザ追加要求を受信すると、制御部１２０の制御に従い、ユーザ追加要求で指定されたユーザが保有するユーザ端末２００にトークルーム参加要求を送信するよう、送信部１１２に伝達する。その後、受信部１１１は、制御部１２０の制御に従い、参加要求相手のユーザのユーザ端末２００から当該参加要求に対する参加回答情報を受信すると、当該参加回答情報の内容が参加可能な旨の内容を含むものであれば、参加要求相手のユーザのユーザ端末２００にトークルームの開設通知を送信するよう、トークルームの開設通知を送信部１１２に伝達する。一方、当該参加回答情報の内容が参加不可能な旨の内容を含むものであれば、受信部１１１は、制御部１２０の制御に従い、参加要求するユーザのユーザ端末２００に当該参加回答情報を送信するよう、当該参加回答情報を送信部１１２に伝達する。これにより、予約譲渡にあたって、交渉に係るユーザ間において友達等のユーザをトークルーム上の直接交渉に追加することができ、予約譲渡交渉を友達のユーザにも意見を聞きつつ交渉することができる。

送信部１１２は、ネットワーク４００を介して、制御部１２０の制御に従って、各ユーザ端末２００にメッセージを送信する機能を有する。具体的には、例えば、送信部１１２は、各ユーザ端末２００に予約情報の検索結果、譲渡可能な予約の抽出結果、交渉回答情報、トークルーム開設通知、トークルーム参加要求、トークルームの参加回答情報、予約の譲渡承認要求、予約の譲渡許可要求、予約譲渡の承認回答情報および予約の更新結果等を送信する。また、送信部１１２は、当該メッセージを送信する際に、送信する日時情報、送信者情報を当該送信データに付与してから各ユーザ端末２００に送信してもよい。

また、送信部１１２は、制御部１２０の制御に従い、予約の譲渡にあたって譲渡要求対象の予約を保有するユーザに、予約への譲渡承認要求を当該ユーザのユーザ端末２００に送信する。その後、受信部１１１が、当該ユーザ端末２００から、当該譲渡承認要求に対する承認回答情報を受信すると、当該承認回答情報が承認可能な旨を含む情報であった場合は、制御部１２０の制御に従い、受信部１１１は、当該承認回答情報を更新部１２３に伝達し、更新部１２３は、予約の譲渡要求に基づいて予約の更新を行う。一方、当該承認回答情報が承認不可能な旨を含む情報であった場合は、受信部１１１は、当該承認回答情報を送信部１１２に伝達し、送信部１１２は、予約が譲渡不可能な旨を譲渡要求するユーザのユーザ端末２００に送信する。これにより、譲渡対象の予約を保有するユーザの承認を得てから譲渡を実行することができ、予約の譲渡を円滑に進めることができる。

さらに、予約の譲渡にあたって、譲渡要求対象の予約を保有するユーザの単位は、１ユーザに限らず、例えば１以上のユーザから構成されるグループでもよい。譲渡要求対象の予約を保有する単位がグループの場合、送信部１１２は、制御部１２０の制御に従い、予約の譲渡にあたって譲渡要求対象の予約を保有するグループに属するユーザのうち少なくとも１以上のユーザ（例えば、グループに属するユーザ全員または一部のユーザ（予め設定したグループの代表者のユーザ等））に、予約への譲渡承認要求を当該ユーザのユーザ端末２００に送信する。その後、受信部１１１が、当該ユーザ端末２００から、当該譲渡承認要求に対する承認回答情報を受信すると、少なくとも１以上のユーザ端末（例えば、譲渡承認要求を送信した全てのユーザのユーザ端末としてもよいし、一部のユーザのユーザ端末としてもよい）から送信された当該承認回答情報が承認可能な旨を含む情報であった場合は、制御部１２０の制御に従い、受信部１１１は、当該承認回答情報を更新部１２３に伝達し、更新部１２３は、予約の譲渡要求に基づいて予約の更新を行う。

一方、当該承認回答情報が承認不可能な旨を含む情報であった場合は、受信部１１１は、当該承認回答情報を送信部１１２に伝達し、送信部１１２は、予約が譲渡不可能な旨を譲渡要求するユーザのユーザ端末２００に送信する。これにより、譲渡対象の予約を保有するユーザの単位に多様性を持たせることができ、かつ、柔軟に、当該ユーザの承認を得てから譲渡を実行することができ、予約の譲渡を円滑に進めることができる。

さらに、送信部１１２は、制御部１２０の制御に従い、予約の譲渡にあたって譲渡要求対象の店舗等側のユーザに、予約への譲渡許可要求を当該ユーザのユーザ端末２００に送信する。その後、受信部１１１が、当該ユーザ端末２００から、当該譲渡許可要求に対する許可回答情報を受信すると、当該許可回答情報が譲渡を許可する旨を含む情報で合った場合は、制御部１２０の制御に従い、受信部１１１は、当該許可回答情報を更新部１２３に伝達し、更新部１２３は、予約の譲渡要求に基づいて予約の更新を行う。一方、当該許可回答情報が譲渡拒否の旨を含む情報であった場合は、受信部１１１は、当該許可回答情報を送信部１１２に伝達し、送信部１１２は、予約が譲渡不可能な旨を譲渡要求するユーザのユーザ端末２００に送信する。これにより、譲渡対象の予約の店舗等側のユーザの許可を得てから譲渡を実行することができ、予約の譲渡を円滑に進めることができる。また、店舗等側のユーザが事前に変更を把握できることにも利点がある。

制御部１２０は、検索部１２１、抽出部１２２、更新部１２３を備え、サーバ１００の各部を制御する機能を有するプロセッサである。制御部１２０は、サーバ１００が提供するサービスに関する処理を実行するものである。そのサービスの一環として制御部１２０は、受信部１１１から伝達されたメッセージに基づいて、記憶部１２０に記憶されている予約情報および予約実績情報等を更新し、ユーザ端末２００において表示されるべき表示情報を生成する。また、制御部１２０は、図４および図５に示すように、ユーザが予約要求および予約の譲渡要求をするための入力表示および入力結果表示等のユーザ端末２００の表示部２１０に表示させる表示情報を生成する。制御部１２０は、生成した表示情報を、ユーザ端末２００に送信するよう、送信部１１２に伝達する。

検索部１２１は、受信部１１１から伝達された予約要求データに基づいて、記憶部１３０が記憶するユーザの予約情報から、当該予約要求データの予約と全部または一部が競合する予約情報を検索する機能を有する。具体的には、検索部１２１は、予約要求データに含まれる検索キーとなる情報、例えば、店舗、施設、会議室またはタスクのＩＤ情報、予約リソース数、予約時間（ユーザが予約をしたい時間区間における日付と時間帯の情報（予約をしたい日付と時間帯の開始日時および終了日時、時間数等））といった情報の少なくともいずれか一つを、単一キーまたは複合キーとして用いて検索する。

ここで、「競合する予約情報」とは、予約要求対象の予約と、予約対象（例えば、店舗ＩＤ情報またはタスクＩＤ情報等）、予約リソース数（例えば、人数または工数等）および予約時間の全てまたは一部が合致する予約の予約情報をいう。具体的には、同一の店舗および同一の人数に対する予約であり、例えば、図６（ａ）に示すように、ユーザＡおよびユーザＢは予約時間の一部が、ユーザＣは予約時間の全てが合致する場合に競合するユーザＡ、ユーザＢおよびユーザＣの予約情報は競合する予約情報となる。

検索部１２１は、当該検索の結果、合致する予約情報が記憶されている予約情報から見つかった場合は、競合する予約情報（以下、「コンフリクト情報」という）が存在するとして、当該コンフリクト情報を予約要求データと共に抽出部１２２に伝達する。また、コンフリクト情報が存在しない場合は、当該検索結果をユーザ端末２００に送信するために、送信部１１２に伝達する。

また、検索部１２１は、検索にあたって、キー情報の所定の範囲内にある情報に基づいて、予約情報を検索することができてもよい。例えば、検索部１２１は、コンフリクト情報が存在した場合に、キー情報の予約時間であれば、指定された開始時刻または終了時刻の前後２時間の範囲内においてもコンフリクト情報が存在するか追加で検索することもできる。なお、当該所定の範囲については、店舗やタスクの特性等に応じて適宜設定すればよい。当該追加の検索結果をユーザ端末２００に送信することにより、ユーザが予約時間の開始時刻をずらす変更をするだけで、他の予約との競合が解消し、希望どおりの店舗や席を等に予約することができる。

さらに、検索部１２１は、例えば、予約時間だけでなく、予約対象の店舗や会議室等に類似する店舗等に係る予約情報を追加で検索し、コンフリクト情報が存在するか検索することもできる。類似の範囲については、例えば、キーワードとなる単語（店舗であれば、場所、料理ジャンル、系統、用途・目的等を表す単語、会議室であれば、大規模・小規模、用途、プロジェクタ付き等のオプションを表す単語等）を予め店舗等に付与して記憶部１３０に店舗情報として記憶しておき、予約対象の店舗等と全部または一部が一致する店舗等を類似すると判定してもよいし、予め類似する店舗等を任意で設定し、当該店舗等のＩＤ情報を付与して記憶部１３０に記憶してもよい。

当該追加の検索結果をユーザ端末２００に送信することにより、予約時間に近い空き時間や予約対象の店舗等に類似する店舗情報を通知することで、ユーザに希望に近い店舗や会議室等に変更する提案をすることができ、単に予約が競合するため予約不可能であるとの通知をする従来技術と比較して、予約の選択の可能性および選択の幅を広げ、ユーザにとって利便性の高いサービスを提供することができ、ユーザも希望に近い店舗等に予約をすることができる。

抽出部１２２は、検索部１２１から伝達されたコンフリクト情報等に基づいて、当該コンフリクト情報のうち、譲渡可能な予約情報を抽出する機能を有する。具体的には、抽出部１２２は、コンフリクト情報に含まれる譲渡可否情報（フラグ情報）またはコンフリクト情報に含まれるインセンティブ情報の有無を確認し、譲渡可またはインセンティブ情報有りとなっていた場合は、当該コンフリクト情報を譲渡可能な予約情報として抽出する。当該抽出の結果は、ユーザ端末２００に送信するために、上記検索結果およびコンフリクト情報と共に送信部１１２に伝達する。これにより、予約を希望するユーザは、予約の競合相手のユーザの情報および当該ユーザのうち予約の譲渡が可能なユーザの情報を自身が保有するユーザ端末２００に送信され、表示部２１０で確認することができる。ひいては、予約の譲渡によって効率的に希望の予約をすることができる。

また、抽出部１２２は、予約要求データにインセンティブ指定条件が設定されていた場合には、コンフリクト情報に含まれるインセンティブ情報が当該条件を満たす場合にのみ、当該コンフリクト情報を譲渡可能な予約情報として抽出してもよい。

さらに、抽出部１２２は、予約要求データに含まれる予約リソース数と、上記譲渡可能な予約情報の予約リソース数を比較して、これらの予約リソース数の差分が一致または所定の範囲内にある譲渡可能な予約情報の優先度が高くするように優先度を判定することもできる。

一例として、譲渡可能な予約情報が複数あった場合に、予約要求データに含まれる予約リソース数が2名で、譲渡可能な予約情報が5名と3名であった場合、3名の譲渡可能な予約情報の優先度を高く判定し、5名の譲渡可能な予約情報の優先度を低くして判定して、当該判定の結果を含む抽出結果をユーザ端末２００に送信する。これにより、店舗等側にとって人数が減ったことによる利益損失を減らすようにユーザの譲渡してもらう予約情報の選択を導くことができる。なお、当該優先度の判定結果については、一例として、ユーザ端末２００に表示する際に優先度が高い店舗順に表示したり、お勧め度合として表示したりすることで導いてもよい。

更新部１２３は、予約の譲渡要求または予約の確定要求に係るデータが受信部１１１から伝達されると、当該データに基づいて記憶部１３０に記憶する予約情報を更新する。具体的には、一例として、更新部１２３は、記憶部１３０に記憶する予約の譲渡要求の対象となる予約情報に対して、当該予約情報に含まれるユーザＩＤ、予約リソース数、メニュー情報、タスク内容等を、譲渡要求データに含まれるこれらのデータに書き換える。もしくは、記憶部１３０に記憶する予約の譲渡要求の対象となる予約情報を物理または論理削除を行い、譲渡要求データに含まれる予約情報のデータに基づいて新規の予約情報を追加する。また、例えば、更新部１２３は、予約の確定要求に係るデータに基づいて新規の予約情報を記憶部１３０に追加する。これにより、予約の譲渡要求に基づいて、予約情報を譲渡人のユーザに係る情報から譲渡先のユーザに係る情報に書き換える更新をすることで、効率的に予約の譲渡ひいては予約を実現することができる。

また、更新部１２３は、店舗側または会議室の運営会社側等のユーザ端末から予約どおり実行されたか、すなわち店舗であれば予約したユーザが来店したか否か等の判定情報を受信部１１１が受信し、当該受信した判定情報を受信部１１１から伝達されると、記憶部１３０に記憶されている予約実績情報の予約実行回数または予約キャンセル回数の少なくともいずれか一つを更新する。

さらに、更新部１２３は、予約の譲渡要求に係るデータが受信部１１１から伝達された際に、ユーザごとの予約回数、予約譲渡回数、予約実行回数または予約キャンセル回数に基づいて、予約キャンセル回数から予約実行回数を引いた数、予約キャンセル率（予約キャンセル回数を予約回数で割って求める予約全体に対する予約キャンセル回数の割合）、予約譲渡回数から予約実行回数を差し引いた数、予約譲渡率（予約譲渡回数を予約回数で割って求める予約全体に対する予約譲渡回数の割合）の少なくともいずれか一つを算出し、当該算出の結果、所定の閾値を上回る場合は、当該ユーザは不正な利益を得るための空予約（例えば、実際にはお店に行ってサービスを受ける意志がないのにも関わらず、予約譲渡の際のインセンティブを得るために、架空の予約をすること等をいう）を繰り返すユーザと判定し、当該譲渡要求を破棄してもよい。

これにより、空予約に関わる譲渡要求を受け付けなくすることができる。なお、上記所定の閾値については、予約サービス全体の予約状況、予約譲渡状況、予約実行状況、予約キャンセル状況等をふまえて適宜設定すればよい。

ここで、上記予約譲渡要求の破棄を含め、図５を用いて空予約の譲渡を成立させない入力受付を含む表示の例について説明する。例えば、図５（ａ）に示すように、空予約を繰り返すと判定されたユーザＣが予約の競合する相手として抽出され、ユーザ端末２００に表示された場合に、「現在、ユーザＣへの譲渡要求を受け付けることができません。」といったような通常のドロップダウンメニューとは異なる譲渡が不可である旨の表示をし、予約譲渡のための交渉要求や譲渡要求の入力をさせないこともできる。また、図５（ｂ）で示すように、予約状況のタイムライン表示にユーザＣの表示エリアには「譲渡不可」と表示し、タップ等による指定自体を無効にする表示をすることもできる。さらに、図５（ｃ）に示すように、一旦予約の交渉要求または譲渡要求は受け付けるものの、「申し訳ございません。ご指定の譲渡要求は、諸事情により受け付けることが出来ません。再度選び直して頂く等ご対応お願い致します。」といった譲渡が破棄された旨の表示をして、当該要求を破棄することもできる。

記憶部１３０は、サーバ１００が動作するうえで必要とする各種プログラム、データおよびパラメータを記憶する機能を有する。具体的には、例えば、記憶部１３０は、予約情報および予約実績情報等を記憶する。記憶部１３０は、典型的には、ＨＤＤ（Hard Disc Drive）、ＳＳＤ（Solid State Drive）、フラッシュメモリ等各種の記録媒体により実現される。
以上が、サーバ（情報処理装置）１００の構成である。

次にユーザ端末２００の構成について説明する。
図２に示すように、ユーザ端末２００は、表示部２１０、制御部２２０、通信部２３０、記憶部２４０を含んで構成される。

表示部２１０は、ユーザからの入力を受け付ける機能を有する。典型的には、タッチパネル等のソフトキーあるいはハードキーにより実現される。また、表示部２１０は、制御部２２０の制御に従い、サーバ１００から送信された表示情報等を表示する機能を有するモニタである。典型的には、例えば、ＬＣＤ（Liquid Crystal Display）ディスプレイ、ＬＥＤ（Light Emitting Diode）ディスプレイ、ＯＬＥＤ（Organic Light Emitting Diode）ディスプレイ等を用いればよい。

また、表示部２１０は、トークルーム上のユーザの入力について、サーバ１００の記憶部１３０に記憶する予約情報の更新が必要な入力について識別し、当該識別した入力情報をサーバ１００に送信するよう、制御部２２０の制御に従い、送信部２３２に伝達することができる。例えば、予約を要求するユーザと、交渉相手のユーザ（予約の譲渡可能なユーザ）がトークルーム上で予約譲渡の直接交渉の中で、新たなインセンティブを設定入力した場合、当該設定情報を識別し、当該識別した設定情報をサーバ１００に送信する。サーバ１００の受信部１１２が当該識別した設定情報を受信し、更新部１２３に伝達すると、更新部１２３は当該伝達された当該識別した設定情報に基づいて、予約情報の予約内容情報６０４のインセンティブ設定情報を更新することができる。

また、インセンティブの設定だけでなく、トークルーム上で予約譲渡の直接交渉の末、予約の譲渡が決定した際に、交渉の中で変更された情報のうち、予約情報の更新が必要な入力を識別し、当該識別した入力情報をサーバ１００に送信するよう、制御部２２０の制御に従い、送信部２３２に伝達することができる。これにより、直接交渉の入力とは別途、画面遷移等してインセンティブの設定入力をする必要がなく、ユーザインタフェースの向上を図ることができる。なお、予約情報の更新が必要な入力の識別においては、予めパラメータ情報として特定のキーワード情報（例えば、“［インセンティブ再設定］”等のタグ情報等）を設定し、当該特定のキーワードが付与されているかどうかで識別してもよいし、対象の入力をタップするとポップアップ表示を表示させて、当該ポップアップ表示上の入力（例えば、ポップアップ表示に“予約情報を更新する”と表示した押下ボタンを設ける等））で識別してもよい。

制御部２２０は、ユーザ端末２００の各部を制御する機能を有するプロセッサである。制御部２２０は、受信部２３１から伝達されたサーバ１００から受信した情報を表示部２１０に伝達し、表示させる機能を有する。また、制御部２２０は、表示部２１０から入力された情報に基づいて、サーバ１００に送信するよう、送信部２３２に伝達し、送信させる機能を有する。さらに、制御部２２０は、サーバ１００から受信部２３１が受信した表示情報を表示部２１０に表示するよう制御する機能を有する。さらに、制御部２２０は、伝達された各種情報に基づいて、記憶部２４０に記憶されている情報を更新（追加、変更および削除）する機能を有する。

通信部２３０は、受信部２３１および送信部２３２を備え、ネットワーク４００を介して、サーバ１００との通信（各種データ、メッセージの送受信等）を実行する機能を有する。当該通信は、有線、無線のいずれでもよく、また、互いの通信が実行できるのであれば、どのような通信プロトコルを用いてもよい。ここで、「メッセージ」とは、テキストメッセージに限らず、画像、音声、動画、スタンプ（デジタルステッカー）等が含まれる。

受信部２３１は、ネットワーク４００を介して、サーバ１００または各ユーザ端末２００からメッセージを受信し、当該メッセージに含まれるデータを制御部２２０に伝達する機能を有する。具体的には、例えば、受信部２３１は、サーバ１００から予約情報の検索結果、譲渡可能な予約の抽出結果、交渉回答情報、トークルーム開設通知、トークルーム参加要求、トークルームの参加回答情報、予約の譲渡承認要求、予約の譲渡許可要求、予約譲渡の承認回答情報および予約の更新結果等を受信する。

送信部２３２は、ネットワーク４００を介して、制御部２２０の制御に従って、サーバ１００または各ユーザ端末２００にメッセージを送信する機能を有する。具体的には、例えば、送信部２３２は、予約譲渡の交渉要求、予約譲渡の交渉回答情報、トークルームのユーザ追加要求、トークルームの参加回答情報、予約の譲渡要求、予約譲渡の承認回答情報および予約譲渡の許可回答情報等をサーバ１００に送信する。

記憶部２４０は、サーバ１００が動作するうえで必要とする各種プログラム、データおよびパラメータを記憶する機能を有する。記憶部２４０は、具体的には、例えば、メッセージングアプリおよび予約情報等を記憶する。記憶部２４０は、典型的には、ＨＤＤ（Hard Disc Drive）、ＳＳＤ（Solid State Drive）、フラッシュメモリ等各種の記録媒体により実現される。
以上が、ユーザ端末２００の構成である。

＜データ＞
ここで、本実施の形態において、予約要求メッセージのデータ構成例並びに記憶部１３０に記憶される予約情報および予約実績情報のデータ構成例について図３ａ〜ｃに示す。図３ａは、予約要求メッセージのデータ構成例を示すデータ概念図である。

予約要求ＩＤ５０１は、予約要求メッセージを識別するために付与された固有の識別情報である。

ユーザＩＤ５０２は、ユーザを識別するために付与されたユーザ固有の識別情報である。

予約要求日時５０３は、予約要求メッセージに付与される日時（日付と時刻を示すものであれば、どのような形で表現されてもよく、例えば、ISO 8601で規定されている、年＝YYYY、月＝MM、日＝DD、時＝hh、分＝mm、秒＝ssとした、基本表記YYYYMMDDThhmmssまたは、拡張表記YYYY-MM-DDThh:mm:ss等を用いることが考えられる。）の情報である。具体的には、予約要求メッセージがユーザ端末２００の表示部２１０がユーザからの予約依頼の入力を受け付けた日時もしくは制御部２２０で生成時の日時または上述のとおりサーバ１００が予約要求メッセージを受信した日時でも統一して設定されればよい。

予約時間５０４は、ユーザが予約をしたい時間区間における日付と時間帯の情報（予約をしたい開始日時および終了日時、時間数等）である。

予約内容情報５０５は、予約の対象となる店舗情報、予約の内容、予約譲渡の際に必要となるインセンティブ情報等を示す情報である。

具体的には、店舗・タスクＩＤ（店舗等および他タスク固有の識別情報）、分類（店舗等への予約かタスク予約を分別する情報）、席・部屋情報、予約リソース数、メニュー情報、指名情報（サロン等の店舗であれば、希望のスタイリスト、ネイリスト等を指定する情報）およびタスク内容（タスク管理サービスの場合に実施すべきタスクの内容を示す情報）から構成することができる。

図３ａにおいて、一例として、予約要求ＩＤが「RR0089」で示される予約要求メッセージは、ユーザＩＤ「U0123」が付与されているユーザからの予約要求であり、「2015/9/15 20:58」に表示部２１０で予約入力を受け付けられた予約要求である。また、その予約内容は、店舗ＩＤ「Res002」が付与されたレストランに対する予約であり、席・部屋情報が「窓際テーブル」と窓際にあるテーブル席を指定し、予約リソース数が「5名」と5名の人間が来店すること、また、当該人数が座れる大きさの席であることを指定し、メニュー情報が「季節の限定コース」とするコース料理を指定するものである。

インセンティブ設定情報は、ユーザの予約確定後、他のユーザから予約譲渡を要求した際に求めるインセンティブの内容を示す情報である。具体的には、インセンティブ設定情報は、譲渡分類（完全譲渡か部分譲渡か両方対応できるかを分別する情報であり、完全譲渡は予約時間全体を一つのまとまりとして譲渡するものであり、部分譲渡は任意の時間単位で予約時間を分割したまとまりで譲渡するものである）、金額（完全）（完全譲渡の際に必要となる金銭の額の上限または下限の少なくともいずれか一つ）、金額（部分）（部分譲渡の際に必要となる金銭の額の上限または下限の少なくともいずれか一つ）、単位時間（部分譲渡にあたって、分割の時間単位を示す情報）、緊急度（タスク管理サービスにあたって、対象のタスクの緊急性の度合いを示す情報（例えば、高、中、低等）および重要度（タスク管理サービスにあたって、対象のタスクの重要性の度合いを示す情報（例えば、高、中、低等）から構成することができる。

インセンティブ指定条件は、ユーザの予約要求の際、競合する予約が存在し、当該予約を譲渡してもらうにあたって、当該譲渡のためのインセンティブに対する条件を示す情報である。具体的には、インセンティブ指定条件は、譲渡分類、金額（完全）、金額（部分）および単位時間から構成することができる。インセンティブ設定情報およびインセンティブ指定条件を設けることで、ある店舗のある時間帯に行くことを強く希望するユーザに、既に予約をしている他のユーザが予約を譲渡する誘因となり、仮に競合が発生しても、予約を強く希望するユーザが諦めることなく、希望する店舗等に予約をすることができる。

図３ｂは、記憶部１３０に記憶されている予約情報のデータ構成例を示すデータ概念図である。

予約要求ＩＤ６０１、ユーザＩＤ６０２、予約要求日時６０３は、図３ａで示した予約要求メッセージで設定された情報を示すものである。予約内容情報６０４のうち、譲渡可否は対象の予約が譲渡可能か否かを示す情報であり、予約要求メッセージのインセンティブ設定情報が設定されていたら、自動的に譲渡可と判定し設定してもよいし、譲渡可否の選択フィールドを表示部２１０および予約要求メッセージに設けて判別し、設定してもよい。予約内容情報６０４の譲渡可否以外のフィールドについては、予約要求メッセージで設定された情報を示すものである。また、ステータス６０５は、対象の予約の状況を示す情報であり、予約の未実施、実行、キャンセル、譲渡済等の状況を示すことができる。

図３ｃは、記憶部１３０に記憶されている予約実績情報のデータ構成例を示すデータ概念図である。

予約実績情報は、ユーザごとの予約実績を示す情報である。ユーザＩＤ７０１は、上述のとおりユーザを識別するために付与されたユーザ固有の識別情報である。具体的には、予約実績情報は、予約回数（対象のユーザがこれまで予約サービスで予約した回数）、予約実行回数（対象のユーザが予約した予約のうち、予約内容情報どおりに店舗への来店やタスク等を実行した回数）、予約キャンセル回数（対象のユーザが予約した予約のうち、予約内容情報どおりに実行しなかった回数）、予約譲渡回数（対象のユーザが予約した予約のうち、他のユーザに予約を譲渡した回数）から構成することができる。なお、図３ｃには不図示だが、予約実績情報は、予約キャンセル率および予約譲渡率を含んでもよい。

＜動作＞
本実施の形態に係るサーバ１００の動作およびサーバ１００とユーザ端末２００のメッセージ等のやり取りの流れを説明する。図８ａ〜ｃを用いて、サーバ１００の動作を説明する。図８ａ〜ｃは、サーバ１００の動作を示すフローチャート図である。

図８ａを示すように、記憶部１３０に、ユーザの予約情報が記憶される（ステップＳ１１）。受信部１１１は、ユーザ端末２００から送信された予約要求を受信する（ステップＳ１２）。検索部１２１は、受信した予約要求メッセージに基づいて、記憶部１３０が記憶するユーザの予約情報から、当該予約要求データの予約と全部または一部が競合する予約情報を検索する（ステップＳ１３）。検索部１２１が検索した結果、競合する予約情報が存在しなかった場合（ステップＳ１４のＮＯ）には、検索部１２１が競合する予約が存在しないため予約可能であるとして当該検索結果を送信部１１２に伝達し、送信部１１２が当該検索結果をユーザ端末２００に送信する（ステップＳ１８）。

一方、検索部１２１が当該検索した結果、競合する予約情報が存在する場合（ステップ１４のＹＥＳ）には、予約時間に近い空き時間または類似の予約対象の少なくともいずれか一つを検索する（ステップＳ１５）。検索部１２１の検索結果は抽出部１２１に伝達され、抽出部１２２は、伝達された検索結果に基づいて、競合する予約のうち、譲渡可能な予約を抽出する（ステップＳ１６）。抽出部１２１は、伝達された検索結果および当該抽出結果を送信部１１２に伝達し、送信部１１２がこれらの検索結果および抽出結果をユーザ端末２００に送信する（ステップＳ１７）。

これにより、予約を希望するユーザに、予約が競合するユーザ情報と、当該競合するユーザのうち予約の譲渡が可能なユーザを示す情報を通知することで、また、予約時間に近い空き時間や予約対象の店舗等に類似する店舗情報を通知することで、単に予約が競合するため予約不可能であるとの通知をする従来技術と比較して、予約の選択の可能性および選択の幅を広げ、ユーザにとって利便性の高いサービスを提供することができる。

次に図８ｂに示すように、ユーザが競合するユーザ情報、譲渡可能なユーザを示す情報等を確認して、ユーザ端末２００から送信した予約の譲渡要求、予約の交渉要求または確定要求を、受信部１１１が受信する（ステップＳ２１）。予約の交渉要求を受信した場合（ステップＳ２２の交渉要求の場合）には、制御部１２０の制御に従い、送信部１１２が交渉要求を交渉相手のユーザ（予約の譲渡可能なユーザ）に交渉要求を送信する（ステップＳ２３）。送信された交渉要求に対して、交渉相手のユーザが、交渉に応じるか否かの回答情報をユーザ端末２００から送信し、受信部１１１は、当該回答情報を受信する（ステップＳ２４）。受信した回答情報に基づいて、交渉可能である場合には送信部１１２がトークルーム開設通知をユーザと交渉相手のユーザの双方のユーザ端末に送信する（ステップＳ２７）。

ここで、「トークルーム」とは、ユーザ端末２００に搭載されるメッセージングアプリが提供するチャット機能を用いて、ユーザ間でメッセージのやりとりをする仮想空間をいう。

トークルーム開設通知を受けたユーザと交渉相手のユーザは、トークルームのチャットを用いて具体的な予約の譲渡交渉を直接行うことができ、予約の譲渡を効果的に実現することができる。

また、受信部１１１がユーザ端末２００から予約の譲渡要求を受信した場合（ステップＳ２２の譲渡要求の場合）には、受信部１１１は、更新部１２３に当該譲渡要求を伝達し、更新部１２３は、譲渡人の予約キャンセル回数等が所定の閾値を上回るか否か判定し、所定の閾値を上回る場合（ステップＳ２７のＹＥＳ）には、当該譲渡要求を破棄し（ステップＳ３６）、当該破棄の結果を送信部１１２に伝達し、送信部１１２は伝達された破棄の結果をユーザ端末２００に送信する（ステップＳ３７）。

一方、更新部１２３は、譲渡人の予約キャンセル回数等が所定の閾値を上回らないと判定した場合（ステップＳ２７のＮＯ）には、予約の譲渡にあたって相手の承諾が必要か否か判定する（ステップＳ２８）。当該判定の基準は、予約要求の際にユーザに選択させてもよく、その場合、記憶部１３０に記憶されている予約情報に含まれる一情報として記憶し、判定の際には、当該情報に基づき判定することができる。また、当該判定の基準は、サービスシステム全体で統一してパラメータ等に設定してもよい。

更新部１２３は、相手の承認が必要と判定した場合（ステップＳ２８のＹＥＳ）には、予約の譲渡承認要求を送信部１１２に伝達し、送信部１１２は伝達された譲渡承認要求を譲渡人のユーザ端末２００に送信する（ステップＳ２９）。送信された譲渡承認要求に対して、譲渡人のユーザが、譲渡を承認するか否かの承認回答情報をユーザ端末２００から送信し、受信部１１１は、当該承認回答情報を受信する（ステップＳ３０）。受信した当該承認回答情報は、受信部１１１から更新部１２３に伝達される。

次に、更新部１２３は、予約の譲渡にあたって店舗等側の承諾が必要か否か判定する（ステップＳ３１）。更新部１２３は、店舗等側の承諾が必要と判定した場合（ステップＳ３１）には、店舗等側のユーザ端末２００に送信する譲渡許可要求を送信部１１２に伝達し、送信部１１２は伝達された予約の譲渡許可要求を店舗側のユーザ端末２００に送信する（ステップＳ３２）。送信された譲渡許可要求に対して、店舗等側のユーザが、許可するか否かの許可回答情報をユーザ端末２００から送信し、受信部１１１は、当該許可回答情報を受信する（ステップＳ３３）。受信した当該許可回答情報は、受信部１１１から更新部１２３に伝達される。

更新部１２３は、予約の譲渡要求、交渉要求および確定要求並びにそれらに関する交渉回答情報、承認回答情報および許可回答情報に基づいて記憶部１３０に記憶する予約情報および予約実績情報を更新する（ステップＳ３４）。更新部１２３は、当該更新の結果を送信部１１２に伝達し、送信部１１２は伝達された当該更新の結果をユーザ端末２００に送信する（ステップＳ３５）。なお、当該更新の結果は、交渉回答情報、承認回答情報および許可回答情報を含み、また、それらの情報に基づいて更新しなかった結果についても含むものとする。また、図８ｃに示すように、受信部１１１は、店舗等側のユーザ端末２００から、予約どおりに実行されたか否かの判定情報を受信する（ステップＳ４１）。受信部１１１は、受信した判定情報を更新部１２３に伝達し、更新部１２３は伝達された判定情報に基づいて、予約実績情報の予約の実行回数またはキャンセル回数等を更新する（ステップＳ４２）。

次に、図９および図１０を用いて、サーバ１００とユーザ端末２００間のメッセージ等の情報のやり取りおよび処理の流れを説明する。図９は、サーバ１００とユーザ端末２００間の譲渡要求の送信から予約情報等の更新結果の送信までのメッセージ等の情報のやり取りおよび処理の流れを示すシーケンス図である。ここで、図９におけるユーザ端末２００について、予約を希望し予約要求を行うユーザをユーザ１とし、ユーザ１が所有するユーザ端末２００を第１のユーザ端末、当該要求された予約と競合する予約を保有し、予約の譲渡人であるユーザをユーザ２とし、ユーザ２が所有するユーザ端末２００を第２のユーザ端末、当該要求された予約の対象となる店舗等のユーザをユーザ３とし、ユーザ３が所有するユーザ端末２００を第３のユーザ端末とする。

先ず、第１のユーザ端末が予約要求メッセージをサーバ１００に送信すると（ステップＳ５１）、サーバ１００は、当該予約要求に基づいて、競合する予約を検索し（ステップＳ５２）、競合する予約のうち、譲渡可能な予約を抽出する（ステップＳ５３）。その後、サーバ１００は、当該検索結果または抽出結果メッセージを少なくともいずれか一つを第１のユーザ端末に送信する（ステップＳ５４）。

次に、第１のユーザ端末が譲渡要求メッセージをサーバ１００に送信すると（ステップＳ５５）、サーバ１００は譲渡人の承認が必要か否か判定し、承認が必要な場合は、サーバ１００およびユーザ端末２００は、opt1（Option1、以下同じ）タグのエリア内にあるメッセージのやり取りおよび処理を実行する。具体的には、サーバ１００は譲渡承認要求メッセージを第２のユーザ端末に送信し（ステップＳ５６）、第２のユーザ端末は当該送信された譲渡承認要求メッセージに対する承認回答情報メッセージをサーバ１００に送信する（ステップＳ５７）。サーバ１００は第２のユーザ端末から当該承認回答情報メッセージを受信すると、第１のユーザ端末に当該承認回答情報メッセージを送信する（ステップＳ５８）。

また、店舗等の許可が必要な場合は、サーバ１００およびユーザ端末２００は、opt2タグのエリア内にあるメッセージのやり取りおよび処理を実行する。具体的には、サーバ１００は予約の譲渡許可要求メッセージを第３のユーザ端末に送信し（ステップＳ５９）、第２のユーザ端末は、当該譲渡許可要求メッセージに対する許可回答情報メッセージをサーバ１００に送信する（ステップＳ６０）。サーバ１００は第３のユーザ端末から当該許可回答情報メッセージを受信すると、第１のユーザ端末に当該許可回答情報メッセージを送信する（Ｓ６１）。

サーバ１００は、予約の譲渡要求、承認回答情報、許可回答情報を受信すると、記憶部１３０に記憶する予約情報および予約実績情報を更新し（ステップＳ６２）、当該更新結果を第１のユーザ端末、第２のユーザ端末および第３のユーザ端末にそれぞれ送信する（ステップＳ６３、Ｓ６４、Ｓ６５）。

図１０は、サーバ１００とユーザ端末２００間の譲渡要求の送信から予約情報等の更新結果の送信までのメッセージ等の情報のやり取りの流れを示すシーケンス図であるが、図９で示したシーケンス図に対し、ユーザ間の予約の譲渡交渉および友達のユーザを当該交渉の場に途中参加する場合のメッセージのやり取りおよび処理の流れを加えたシーケンス図である。ここで、図１０におけるユーザ端末２００について、加えて、予約を希望し予約要求を行うユーザ１の友達である別のユーザをユーザ４とし、ユーザ４が所有するユーザ端末を第４のユーザ端末とする。

第１のユーザ端末が予約要求メッセージをサーバ１００に送信し（ステップＳ７１）、サーバ１００が、当該検索結果または抽出結果メッセージを少なくともいずれか一つを第１のユーザ端末に送信する（ステップＳ７４）までのメッセージのやり取り等（ステップＳ７１〜Ｓ７４）は、図９で示したシーケンス図のメッセージのやり取り等（ステップＳ５１〜Ｓ５４）と同様である。

次に、第１のユーザ端末がサーバ１００に交渉要求メッセージを送信し（ステップＳ７５）、サーバ１００が当該交渉要求メッセージを受信すると、サーバ１００は、第２のユーザ端末に当該交渉要求メッセージを送信する（ステップＳ７６）。第２のユーザ端末は当該交渉要求メッセージを受信すると、交渉回答情報メッセージをサーバ１００に送信する（ステップＳ７７）。サーバ１００は当該交渉回答情報メッセージを受信すると予約譲渡の交渉可能か否か判定し、交渉不可の場合は、サーバ１００および第２のユーザ端末は、alt1（Alternative1、以下同じ）タグのエリアの破線上部エリアにあるメッセージのやり取りおよび処理を実行する。具体的には、サーバ１００は、第１のユーザ端末に当該交渉回答情報メッセージを送信する（ステップＳ７８）。一方、交渉可の場合は、サーバ１００および第２のユーザ端末は、al1タグのエリアの破線下部エリアにあるメッセージのやり取りおよび処理を実行する。具体的には、サーバ１００は、トークルーム開設通知メッセージを第２のユーザ端末に送信し（ステップＳ７９）、また、サーバ１００は、当該交渉回答情報メッセージおよびトークルーム開設通知メッセージを第１のユーザ端末に送信する（ステップＳ８０）。

その後、第１のユーザがサーバ１００にユーザ４をトークルームに追加するようユーザ追加要求メッセージをサーバ１００に送信し（Ｓ８１）、サーバ１００は当該追加要求メッセージを受信すると、第１のユーザ端末にトークルーム参加要求メッセージを送信する（ステップＳ８２）。第４のユーザ端末は当該参加要求メッセージを受信すると、参加回答情報メッセージをサーバ１００に送信する（ステップＳ８３）。サーバ１００は当該参加回答情報メッセージを受信するとユーザ４がトークルーム参加可能か否か判定し、参加不可の場合は、サーバ１００は、alt2タグのエリアの破線上部エリアにあるメッセージのやり取りおよび処理を実行する。具体的には、サーバ１００は、参加不可の旨の情報を含む参加回答情報メッセージを第１のユーザ端末に送信する（ステップＳ８４）。一方、参加可の場合は、サーバ１００およびユーザ端末２００は、alt2タグのエリアの破線下部エリアにあるメッセージのやり取りおよび処理を実行する。具体的には、サーバ１００は、参加可の旨の情報を含む参加回答情報メッセージを第１のユーザ端末に送信し（ステップＳ８５）、第４のユーザ端末にトークルーム開設通知メッセージを送信する（ステップＳ８６）。

第１のユーザ端末が予約の譲渡要求メッセージをサーバ１００に送信し（ステップＳ８７）、サーバ１００が、予約情報の更新結果を第１のユーザ端末、第２のユーザ端末および第３のユーザ端末にそれぞれ送信する（ステップＳ９５、Ｓ９６、Ｓ９７）までのメッセージのやり取り等（ステップＳ８７〜Ｓ９７）は、図９で示したシーケンス図のメッセージのやり取り等（ステップＳ５５〜Ｓ６５）と同様である。

本発明に係るサービスシステムにおいては、図４に示すように専用のＧＵＩとなる表示部２１０を設ける以外にも図７に示すようにトークルームを用いて予約および予約譲渡を行うこともできる。例えば、図７（ａ）に示すように、制御部２２０が備えるボット機能により、ユーザには「＠コンシェルジュサービス」アカウントとしてチャットメッセージでレストランの予約要求を受け付けることができる。予約要求を受け付け、競合する予約が存在する場合には、「＠コンシェルジュサービス」アカウントから譲渡可能な予約があること、予約時間に近い空き時間があること、希望の席に類似する席が空いていることを提案することができる。また、図７（ｂ）に示すように、チャットの途中で友達である別のユーザを参加させることもできる。これにより、ユーザは、参加した別のユーザの「＠コンシェルジュサービス」アカウントとユーザのこれまでのメッセージのやり取りを見た「＠コンシェルジュサービス」アカウントから提案された選択肢に対する意見を聞くことができる。

ユーザ間で意見を言い合い、「＠コンシェルジュサービス」アカウントから提案された選択肢から選択した案を「＠コンシェルジュサービス」アカウントに伝えると、本発明に係るサービスシステムは当該案を実行する。例えば図７（ｂ）に示すように、本発明に係るサービスシステムは予約の譲渡を選択した場合、予約の譲渡のための各処理を行う。図（ｃ）に示すように予約確定のためのインセンティブの支払い決済についても指定のメッセージをタップすることで支払い決済のためのページに遷移させ、決済処理をすることもできる。

これにより、普段トークルームにおいて友達同士でチャットをする感覚で、簡易的に予約および予約譲渡を行うことが出来、ユーザにとって利便性の高いサービスを提供することができる。

サーバ１００及びユーザ端末２００の各機能部は、集積回路（ＩＣ（Integrated Circuit）チップ、ＬＳＩ（Large Scale Integration））等に形成された論理回路（ハードウェア）や専用回路によって実現してもよいし、ＣＰＵ（Central Processing Unit）およびメモリを用いてソフトウェアによって実現してもよい。また、各機能部は、１または複数の集積回路により実現されてよく、複数の機能部の機能を１つの集積回路により実現されることとしてもよい。ＬＳＩは、集積度の違いにより、ＶＬＳＩ、スーパーＬＳＩ、ウルトラＬＳＩなどと呼称されることもある。図１１には、サーバ１００およびユーザ端末２００の各機能部を回路で示した例を示している。なお、ここで「回路」は、コンピュータによるデジタル処理、すなわち、ソフトウェアによる機能的処理としての意味合いを含んでもよい。また、当該回路は、再構築可能な回路（例えば、ＦＰＧＡ：Field Programmable Gate Array）により実現されてもよい。

サーバ１００及びユーザ端末２００の各機能部をソフトウェアにより実現する場合、サーバ１００またはユーザ端末２００は、各機能を実現するソフトウェアである表示情報生成プログラムの命令を実行するＣＰＵ、上記検索プログラムおよび各種データがコンピュータ（またはＣＰＵ）で読み取り可能に記録されたＲＯＭ（Read Only Memory）または記憶装置（これらを「記録媒体」と称する）、上記検索プログラムを展開するＲＡＭ（Random Access Memory）などを備えている。そして、コンピュータ（またはＣＰＵ）が上記検索プログラムを上記記録媒体から読み取って実行することにより、本発明の目的が達成される。上記記録媒体としては、「一時的でない有形の媒体」、例えば、テープ、ディスク、カード、半導体メモリ、プログラマブルな論理回路などを用いることができる。また、上記検索プログラムは、当該検索プログラムを伝送可能な任意の伝送媒体（通信ネットワークや放送波等）を介して上記コンピュータに供給されてもよい。本発明は、上記検索プログラムが電子的な伝送によって具現化された、搬送波に埋め込まれたデータ信号の形態でも実現され得る。

なお、上記検索プログラムは、例えば、ActionScript、JavaScript（登録商標）などのスクリプト言語、Objective-C、Java（登録商標）などのオブジェクト指向プログラミング言語、HTML5などのマークアップ言語などを用いて実装できる。

１００サーバ（情報処理装置）
１１０通信部
１１１受信部
１１２送信部
１２０制御部
１２１検索部
１２２抽出部
１２３更新部
１３０記憶部
２００ユーザ端末
２１０表示部（ユーザ端末）
２２０制御部（ユーザ端末）
２３０通信部（ユーザ端末）
２３１受信部（ユーザ端末）
２３２送信部（ユーザ端末）
２４０記憶部（ユーザ端末）
４００ネットワーク

Claims

端末とネットワークを介して接続された情報処理装置の制御方法であって
ユーザの予約情報を記憶する記憶ステップと
第１のユーザ端末から予約要求を受信する第１の受信ステップと、
前記記憶されている予約情報のうち、前記予約要求と少なくとも一部が競合する予約情報を検索する検索ステップと、
前記検索の結果、競合する予約情報が存在するときは、当該競合する１以上の予約情報から第１のユーザ端末を保有するユーザに部分譲渡可能な予約を含む予約情報を抽出する抽出ステップと、
前記検索の結果または前記抽出の結果の少なくともいずれか一つを、前記第１のユーザ端末に送信する第１の送信ステップと、
を含む情報処理装置の制御方法。