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

Abstract

【課題】ユーザにとって利便性の高い取り引き申し込みを実現すること。【解決手段】本願にかかる情報処理装置は、申込受付部と、提示部とを有する。申込受付部は、所定の取り引きにおける料金プランの１つである第１のプランであって、キャンセルを行う場合の条件として第１の条件が設定される第１のプランへの申し込みを受け付ける。提示部は、申込受付部により第１のプランへの申し込みが受け付けられた後に、第１のプランから、所定の取り引きにおける料金プランの１つである第２のプランであって、キャンセルを行う場合の条件として第１の条件とは異なる第２の条件が設定される第２のプランへの変更申し込みを受け付けるためのコンテンツを提示する。【選択図】図３

Description

本発明の実施形態は、情報処理装置、情報処理方法および情報処理プログラムに関する。

従来、旅館、ホテル、飲食店などの施設を利用しようとするユーザは、一般にインターネットや電話などを通じて施設を予約することができる。施設事業者は、予約を行ったユーザに対して規約として前受金や解約料を要求する場合もあるが、ユーザが前受金や解約料を支払わずにキャンセルすることも多く、施設事業者側に損害が発生することがある。

そこで、特許文献１には、施設利用予約システムへユーザから施設の予約があったときは、ユーザから前受金をカードによって徴収し、予約がキャンセルされたときは前受金を施設事業者側に解約料として支払う技術が提案されている。かかる施設利用予約システムでは、ユーザから前受金を徴収することから、予約がキャンセルされた場合において損害の発生を防止することができる。

特開２００３−１９６４０６号公報

上記の従来技術は、サービスを提供する側（例えば、施設事業者側）の損害を押さえる技術であるため、必ずしもユーザにとって利便性の高い取り引き申し込みを実現することができるとは限らない。

本願は、上記に鑑みてなされたものであって、ユーザにとって利便性の高い取り引き申し込みを実現することができる情報処理装置、情報処理方法および情報処理プログラムを提供することを目的とする。

本願にかかる情報処理装置は、所定の取り引きにおける料金プランの１つである第１のプランであって、キャンセルを行う場合の条件として第１の条件が設定される第１のプランへの申し込みを受け付ける申込受付部と、前記申込受付部により前記第１のプランへの申し込みが受け付けられた後に、前記第１のプランから、前記所定の取り引きにおける料金プランの１つである第２のプランであって、キャンセルを行う場合の条件として第１の条件とは異なる第２の条件が設定される第２のプランへの変更申し込みを受け付けるためのコンテンツを提示する提示部と、を有することを特徴とする。

実施形態の一態様によれば、ユーザにとって利便性の高い取り引き申し込みを実現することができるといった効果を奏する。

図１は、実施形態にかかる情報処理の一例を示す図である。 図２は、実施形態にかかる情報処理システムの構成例を示す図である。 図３は、実施形態にかかる情報処理装置の構成例を示す図である。 図４は、実施形態にかかるサービス情報記憶部の一例を示す図である。 図５は、実施形態にかかる申込情報記憶部の一例を示す図である。 図６は、実施形態にかかる情報処理手順を示すフローチャートである。 図７は、情報処理装置の機能を実現するコンピュータの一例を示すハードウェア構成図である。

以下に、本願にかかる情報処理装置、情報処理方法および情報処理プログラムを実施するための形態（以下、「実施形態」と呼ぶ）について図面を参照しつつ説明する。なお、この実施形態により本願にかかる情報処理装置、情報処理方法および情報処理プログラムが限定されるものではない。また、以下の実施形態において、同一の部位には同一の符号を付し、重複する説明は省略される。

〔１．情報処理の一例〕
まず、図１を用いて、実施形態にかかる情報処理の一例について説明する。図１は、実施形態にかかる情報処理の一例を示す図である。実施形態にかかる情報処理は、図１に示す情報処理装置１００によって行われる。

図１の説明に先立って、図２を用いて、実施形態にかかる情報処理システムについて説明する。図２は、実施形態にかかる情報処理システム１の構成例を示す図である。実施形態にかかる情報処理システム１は、図２に示すように、端末装置１０と、保険会社装置４０と、カード会社装置８０と、情報処理装置１００とを含む。端末装置１０、保険会社装置４０、カード会社装置８０、情報処理装置１００は、ネットワークＮを介して有線または無線により通信可能に接続される。なお、図１に示す情報処理システム１には、複数台の端末装置１０や、複数台の保険会社装置４０や、複数台のカード会社装置８０や、複数台の情報処理装置１００が含まれてよい。

また、図２の例では不図示であるが、実施形態にかかる情報処理システム１には、施設（例えば、宿泊施設）の事業主（施設事業主）に属する端末装置である施設装置も含まれてよい。

端末装置１０は、ユーザによって利用される情報処理装置である。端末装置１０は、例えば、スマートフォンや、タブレット型端末や、ノート型ＰＣ（Personal Computer）や、デスクトップＰＣや、携帯電話機や、ＰＤＡ（Personal Digital Assistant）等である。例えば、端末装置１０は、ユーザの操作に応じて、宿泊予約サービスを提供するサイト（以下、「予約サイトＹ１」と表記する場合がある）にアクセスし、宿泊予約に関する各種の情報制御を行う。後述するが、予約サイトＹ１は情報処理装置１００によって提供されるため、端末装置１０は、情報処理装置１００にアクセスすることで、情報処理装置１００から受信した各種情報の表示制御等を行う。なお、本実施形態では、端末装置１０には、予約サイトＹ１に対応するアプリケーションがインストールされており、ユーザは初期設定として、自身の個人情報を登録済みであるものとする。

保険会社装置４０は、保険会社ＨＹに属するサーバ装置である。例えば、保険会社装置４０は、顧客との保険契約に関する各種情報を蓄積するとともに、保険契約に関する各種制御を行う。一例を示すと、保険会社装置４０は、保険料および保険金の算出を行う。保険料は、契約者が保障を得る対価として保険会社に支払うお金である。なお、本実施形態では、保険料には、それが指す金額（すなわち、保険料金額）の概念も含まれているものとする。また、保険金は、保険会社から被保険者（受取人）に支払われるお金である。同様に、本実施形態では、保険金には、それが指す金額（すなわち、保険金額）の概念も含まれているものとする。

カード会社装置８０は、カード会社に属するサーバ装置である。例えば、カード会社装置８０は、決済に関する各種制御を行う。一例を示すと、カード会社装置８０は、ユーザが予約サイトＹ１にて事前決済を指定した場合には、情報処理装置１００との間で決済処理を行う。

ここで、実施形態にかかる情報処理が行われるにあたっての１つ目の前提について説明する。宿泊予約を例に挙げると、宿泊予約の申し込みが行われた後この予約申し込みがキャンセルされても、例えば、チェックイン日の１日前までのキャンセルであれば、事前決済による申し込み金額の全額を返金する、といった料金プラン（プランＸ１とする）が存在する。一方、宿泊予約の申し込みが行われた後この予約申し込みがキャンセルされても、事前決済による申し込み金額を一切返金しない、といった料金プラン（プランＸ２とする）が存在する。

ここで、１つの宿泊プランＸＰの中に、プランＸ１およびプランＸ２といった２つの料金プランが存在するが、このような場合には、一般に、プランＸ１の方がプランＸ２よりも高い申し込み金額が設定される。例えば、プランＸ１では申し込み金額「４０，０００円」、プランＸ２では申し込み金額「３０，０００円」といった金額設定である。これは、プランＸ１では申し込みがキャンセルされた場合、条件を満たすキャンセル（例えば、チェックイン日の１日前までのキャンセル）であれば、申し込み金額の全額を返金しなければならないため、キャンセルされた場合の宿泊施設の損失を見越した料金設定がなされるためである。これに対して、プランＸ２では、申し込みがキャンセルされたとしても申し込み金額を一切返金しないため（宿泊施設に損失が発生しないため）、安めの料金設定がなされる。

そして、１つの宿泊プランＸＰ（例えば、露天風呂付離れ客室１０１号のお部屋宿泊プラン）の中に、プランＸ１およびプランＸ２が存在すれば、ユーザは、申し込み金額は高いが当日キャンセルしなければならなくなる可能性もあるため、一旦プランＸ１への予約申し込みを行っておき、当日キャンセルしなくてよいことが明確になったタイミングで料金の安いプランＸ２に変更したいと考える。このような場合、ユーザは、プランＸ１をキャンセルしたうえで、プランＸ２への予約申し込みを１から行わなければならず面倒な作業を要求されるため、プランＸ１からプランＸ２への変更の簡略化を望むニーズがある。

また、プランＸ１をキャンセルするということは、結局のところ、宿泊プランＸＰ自体への予約申し込みをキャンセルすることであるため、プランＸ１をキャンセルしたタイミングで、例えば、他のユーザが宿泊プランＸＰを予約してしまい宿泊プランＸＰが埋まってしまう（プランＸ２への予約申し込みができなくなる）といった事態も起こり得る。このため、ユーザは、プランＸ１をキャンセルしたうえで、プランＸ２への予約申し込みを行いたいが、宿泊プランＸＰ自体が埋まってしまう恐れがありキャンセルには抵抗がある。このため、宿泊プランＸＰは、確保した状態で、料金プランだけプランＸ２からプランＸ１へと変更させたいといったニーズもある。

以上のような前提および問題点を踏まえて、実施形態にかかる情報処理装置１００は、実施形態にかかる情報処理を行う。具体的には、情報処理装置１００は、所定の取り引きにおける料金プランの１つである第１のプランであって、キャンセルを行う場合の条件として第１の条件が設定される第１のプランへの申し込みを受け付ける。そして、情報処理装置１００は、第１のプランへの申し込みを受け付けた後に、第１のプランから、所定の取り引きにおける料金プランの１つである第２のプランであって、キャンセルを行う場合の条件として第１の条件とは異なる第２の条件が設定される第２のプランへの変更申し込みを受け付けるためのコンテンツを提示する。

より具体的には、情報処理装置１００は、第１の条件として、ユーザによりキャンセルされた場合に購入金額の一部または全額がユーザに返金される条件が設定される第１のプランへの申し込みを受け付ける。そして、情報処理装置１００は、第１の条件とは異なる第２の条件として、ユーザによりキャンセルされた場合に購入金額が返金されない条件が設定される第２のプランへの変更申し込みを受け付けるためのコンテンツを提示する。

ここで、実施形態にかかる情報処理が行われるにあたっての２つ目の前提について説明する。同様に宿泊予約を例に挙げる。例えば、ユーザは宿泊予約の申し込みを完了させた後、急な用事の発生、悪天候、体調不良等の不測の事態が起こってしまうことで、宿泊予約をキャンセルしなければならないことがある。このような場合、ユーザは、例えば、キャンセルポリシーに従ってキャンセル料を支払うことになる。一例を示すと、チェックイン日の７日前までのキャンセルであれば申込金額の１０％、チェックイン日の１日前から６日前までの間でのキャンセルであれば申込金額の５０％、チェックイン日当日のキャンセルであれば申込金額の１００％をキャンセル料として支払う支払義務を課す、といったキャンセルポリシーに従って、キャンセル料を支払う。

不測の事態とはいえ、サービス（かかる例では、宿泊サービス）を受けることなく、支払いが課せられることは、ユーザにとって経済的および精神的に痛手である。そこで、このような事態に備えて、キャンセル料の少なくとも一部を補償する保険サービス（キャンセル料の少なくとも一部を保険金として、被保険者に支払う保険サービス）が存在する。かかる保険はキャンセル保険等と呼ばれることがある。

ユーザは、このような保険サービスを受けたい場合、例えば、宿泊予約サイトとは別に、この保険サービスを提供しているサイトへとアクセスし、各種個人情報等を入力し自身が保険契約を交わす必要があり面倒である。このため保険サービスを受けたいが、諦めるといったユーザも存在する可能性がある。また、経済的な側面から保険料を支払うには提供があるといったユーザも存在する可能性がある。

そこで、このようなことから面倒な作業での申し込みを必要とせず、また、保険料支払い問題についても解決できるようなサービスを求めるニーズがある。また、上記説明した宿泊プランＸＰの中に、プランＸ１およびプランＸ２だけでなく、キャンセル保険が適用される料金プラン（プランＸ３とする）が存在するとする。そうすると、ユーザは、一旦プランＸ１への予約申し込みを行っておき、当日キャンセルしなくてよいことが明確になったタイミングで保険の安心感があり、かつ、プランＸ１より料金の安いプランＸ３に変更したいと考える。このような場合、ユーザは、プランＸ１をキャンセルしたうえで、プランＸ３への予約申し込みを１から行わなければならず面倒な作業を要求されるため、プランＸ１からプランＸ３への変更の簡略化を望む可能性がある。

以上のような前提および問題点を踏まえて、実施形態にかかる情報処理装置１００は、実施形態にかかる情報処理を行う。具体的には、情報処理装置１００は、所定の取り引きにおける料金プランの１つである第１のプランであって、キャンセルを行う場合の条件として第１の条件が設定される第１のプランへの申し込みを受け付ける。そして、情報処理装置１００は、第１のプランへの申し込みを受け付けた後に、第２のプラン、または、所定の取り引きにおける料金プランの１つである第３のプランであって、ユーザによりキャンセルされた場合に発生するキャンセル料を補償する第３のプランへの変更申し込みを受け付けるためのコンテンツを提示する。

以下、実施形態にかかる情報処理の一例について説明する。本実施形態では、情報処理装置１００は、事業主Ｙによって管理されるものとする。また、情報処理装置１００は、予約サイトＹ１を提供するため、予約サイトＹ１は事業主Ｙにより運営されるサイトと言い換えることができる。予約サイトＹ１での予約申し込みに係る一連の取り引きは、所定の取り引きの一例である。また、図１の例では、端末装置１０の利用者をユーザＵ１とする。また、ユーザＵ１の「Ｕ１」は、ユーザ氏名とともに、ユーザを識別する識別情報も兼ねているものとする。

まず、端末装置１０は、ユーザＵ１の操作に応じて情報処理装置１００にアクセスし、予約サイトＹ１内のページＰ１を表示している。ページＰ１では、ある宿泊施設における宿泊プランの１つであるプランＳＶ１が紹介されている。また、ページＰ１の領域ＡＲ１内には、プランＳＶ１における料金プランの１つである料金プランＰＬ１１への予約申し込みに関する情報が表示されている。料金プランＰＬ１１は、チェックイン日の１日前までのキャンセルであれば、事前決済による申し込み金額の全額を返金する（実質、キャンセル料無料）の料金プランであり、第１のプランの一例である。また、ページＰ１の領域ＡＲ１内には、ユーザに対して個人情報を入力させるページＰ２へ進むためのボタンＢＴ１が含まれる。

また、ページＰ１の領域ＡＲ２内には、料金プランＰＬ１１への申し込みを行った後であれば、料金プランＰＬ１２への変更が可能である旨表示されている。料金プランＰＬ１２は、予約申し込みがキャンセルされたとしても申し込み金額を一切返金しない料金プランであり、第２のプランの一例である。

また、ページＰ１の領域ＡＲ３内には、料金プランＰＬ１１への申し込みを行った後であれば、料金プランＰＬ１３への変更が可能である旨表示されている。料金プランＰＬ１３は、キャンセル時にはキャンセル料を補償する保険金をユーザが受け取ることのできる料金プランであり、第３のプランの一例である。予約サイトＹ１では、料金プランＰＬ１３への予約申し込み（料金プランＰＬ１３への変更申し込み）が完了した後、当該予約申し込みをキャンセルする場合には、チェックイン日から遡る日数に関係なく、一律２０％（申し込み金額の２０％）がキャンセル料として課せられるものとする。

また、図１に示すページＰ１の例では、料金プランＰＬ１１の申し込み金額が「４０，０００円」で最も高く、料金プランＰＬ１２の申し込み金額が「３０，０００円」で最も安く、料金プランＰＬ１３の申し込み金額が「３５，０００円」で料金プランＰＬ１１およびＰＬ１２との間の値段設定がなされている。このような値段設定がなされることで、例えば、ユーザは、ほぼキャンセルすることはないと思われるが、仮にキャンセルせざるを得なくなった場合、「３０，０００円」の支払いは経済的に厳しいため、料金プランＰＬ１２への変更には抵抗がある。しかし、ユーザは、キャンセルの可能性がわずかでもあるのであれば、「４０，０００円」よりは安く、かつ、キャンセル時に保険金が下りる料金プランＰＬ１３へ変更することでお得感と安心感とを得られる。

なお、予約サイトＹ１では、例えば、これまでのユーザの利用状況に応じて、ユーザには会員ランクが付与される。図１に示すページＰ１の例では、ユーザＵ１の会員ランクはレギュラー（レギュラー会員）である。なお、会員ランクには、レギュラー以外にもプラチナ、シルバー、ブロンズ等が存在する。

さて、このような状態において、ユーザＵ１がボタンＢＴ１を押下したとする。かかる場合、端末装置１０は、ボタンＢＴ１が押下された旨の情報（ＢＴ１押下情報）を情報処理装置１００に送信する（ステップＳ１）。ＢＴ１押下情報には、例えば、端末装置１０の識別情報、および、料金プランＰＬ１１の識別情報が含まれる。

情報処理装置１００は、ＢＴ１押下情報を受信すると、個人情報を入力させるページＰ２を配信するための配信処理を行う（ステップＳ２）。情報処理装置１００は、配信処理として、図１に示すようなページＰ２を生成する。例えば、情報処理装置１００は、個人情報の入力欄と、料金プランＰＬ１１の予約を確定させ決済処理を行わせるボタンＢＴ２とを含むページＰ２を生成する。また、情報処理装置１００は、配信処理として、生成したページＰ２を端末装置１０に配信する。

このような状態において、ユーザＵ１がボタンＢＴ２を押下したとする。かかる場合、端末装置１０は、ボタンＢＴ２が押下された旨の情報（ＢＴ２押下情報）を情報処理装置１００に送信する（ステップＳ３）。ＢＴ２押下情報には、例えば、端末装置１０の識別情報や、ユーザＵ１による入力内容を示す入力情報が含まれる。

情報処理装置１００は、ＢＴ２押下情報を受信すると、料金プランＰＬ１１への予約申し込みにおける申し込み金額「４０，０００円」を決済する決済処理を行う（ステップＳ４）。例えば、情報処理装置１００は、不図示のカード会社装置８０との間で決済処理を行う。例えば、情報処理装置１００は、ユーザＵ１の銀行口座から申し込み金額「４０，０００円」が引き落とされるよう決済処理を行う。なお、情報処理装置１００は、ＢＴ２押下情報を受信することにより、ユーザＵ１による料金プランＰＬ１１への予約申し込みの受け付けを完了する。

次に、情報処理装置１００は、キャンセル時にユーザＵ１が受け取ることのできる保険金を算出する算出処理を実行する（ステップＳ５）。具体的には、情報処理装置１００は、料金プランＰＬ１３がキャンセルされた場合に発生するキャンセル料を補償する保険金であって、料金プランＰＬ１３をキャンセル時にユーザＵ１が受け取ることのできる保険金を算出する。例えば、情報処理装置１００は、ユーザＵ１の会員ランクに応じた割合に基づいて、保険金を算出する。また、例えば、情報処理装置１００は、予約サイトＹ１を提供する事業主であって、料金プランＰＬ１３への予約申し込みがキャンセルされた場合に発生するキャンセル料を補償する保険であるキャンセル保険に加入する事業主（図１の例では、事業主Ｙ）によって支払われる保険料に基づく割合に基づいて、保険金を算出する。キャンセル保険への加入に関するロジックについては後述する。

ここで、保険金は、保険料から賄われる。例えば、保険金は、保険料に基づき情報処理装置１００によって算出される。また、保険の性質上、保険金は損失額より多く支払われることはない。図１の例での損失額とはキャンセル料であり、申し込み金額「３５，０００円」に対応するキャンセル料は、申し込み金額の２０％に基づき「７，０００円」となる。したがって、情報処理装置１００は、ユーザＵ１の会員ランク「レギュラー」、現在の保険料の状況、キャンセル料「７，０００」に基づいて、保険会社ＨＹに損失が発生しないよう、かつ、キャンセル料「７，０００」を超えないような保険金を算出できる保険金割合であって、会員ランクに応じて変動する保険金割合を動的に決定する。そして、情報処理装置１００は、決定した保険金割合に基づいて保険金を算出する。かかる例では、情報処理装置１００は、保険金割合「５０％」を決定したとすると、キャンセル料「７，０００」×保険金割合「０．５」により、保険金「３，５００円」を算出する。

なお、一例であるが、情報処理装置１００は、ブロンズ会員のユーザには保険金割合「７０％」、シルバー会員のユーザには保険金割合「８０％」、プラチナ会員のユーザには保険金割合「９０％」を算出したりする。なお、情報処理装置１００が動的に保険金割合を決定する例を示したが、保険金割合は、例えば、事業主Ｙあるいは保険会社ＨＹにより予め決定されていてもよい。また、情報処理装置１００がステップＳ５において算出する保険金（図１の例では、３，５００円）は、ユーザＵ１に支払うことができる上限額（限度額）である。

次に、情報処理装置１００は、予約申し込みがキャンセルされたとしても申し込み金額を一切返金しない料金プランＰＬ１２、および、キャンセル時にはキャンセル料を補償する保険金（図１の例では、３，５００円）をユーザＵ１が受け取ることのできる料金プランＰＬ１３のうち、いずれかのプランへの変更を受け付けるためのページＰ３を配信するための配信処理を行う（ステップＳ６）。このようなことから、ページＰ３は、ユーザによりキャンセルされた場合に購入金額が返金されない条件が設定される第２のプランへの変更申し込みを受け付けるためのコンテンツの一例である。また、ページＰ３は、ユーザによりキャンセルされた場合に発生するキャンセル料を補償する第３のプランへの変更申し込みを受け付けるためのコンテンツの一例でもある。

例えば、情報処理装置１００は、ステップＳ５で算出した保険金額を示す保険金情報を取得する。そして、情報処理装置１００は、配信処理として、取得した保険金情報に基づいて、ページＰ３を生成する。例えば、情報処理装置１００は、図１に示すように、領域ＡＲ３１において現在の予約申し込み状況（現在の予約申し込みされている料金プランＰＬ１１に関する情報）が表示され、領域ＡＲ３２において料金プランＰＬ１１から料金プランＰＬ１２へと変更させるための情報が表示され、領域ＡＲ３３において料金プランＰＬ１１から料金プランＰＬ１３へと変更させるための情報が表示されるようなページＰ３を生成する。例えば、領域ＡＲ３３には、ステップＳ５で算出された保険金「３，５００円」が表示される。また、領域ＡＲ３２には、料金プランＰＬ１１から料金プランＰＬ１２への変更を申込むためのボタンＢＴ３２が含まれる。また、領域ＡＲ３３には、料金プランＰＬ１１から料金プランＰＬ１３への変更を申込むためのボタンＢＴ３３が含まれる。

そして、情報処理装置１００は、配信処理として、生成したページＰ３を端末装置１０に配信する。

このような状態において、ユーザＵ１は、ページＰ３において、ボタンＢＴ３３を押下したとする。かかる場合、端末装置１０は、ボタンＢＴ３３が押下された旨の情報（ＢＴ３３押下情報）を情報処理装置１００に送信する（ステップＳ７）。ＢＴ３３押下情報には、例えば、端末装置１０の識別情報や、ユーザＵ１による変更内容を示す変更情報が含まれる。

情報処理装置１００は、ＢＴ３３押下情報を受信すると、事業主Ｙが保険会社ＨＹのキャンセル保険に加入するための契約に関する処理である加入契約処理を実行する（ステップＳ８）。本実施形態では、料金プランＰＬ１３への予約申し込みがキャンセルされた場合に発生するキャンセル料を補償する保険であるキャンセル保険を提供するのは保険会社ＨＹであり、予約サイトＹ１を提供する事業主Ｙがこのキャンセル保険に加入する。例えば、事業主Ｙは、所定額の保険料を保険会社ＨＹに対して支払うことによりキャンセル保険に加入する。つまり、本実施形態では、ユーザはキャンセル保険に加入する必要がないため、加入契約の際の面倒な手続きが不要となる。このようなことから、本実施形態では、キャンセル保険に加入する契約者は事業主Ｙであり、キャンセル保険の保険金を受け取る受取人、すなわち被保険者はユーザということになる。図１の例では、ユーザＵ１が被保険者でありキャンセル時には保険金「３，５００円」を受け取る権利がある。

なお、情報処理装置１００は、ＢＴ３３押下情報を受信すると、料金プランＰＬ１１から料金プランＰＬ１３への変更申し込みを受け付ける。言い換えれば、情報処理装置１００は、プランＳＶ１であることはそのまま維持しつつ、料金プランＰＬ１１を取り消し、料金プランＰＬ１３への予約申し込みを受け付ける。このようなことから、ユーザＵ１は、料金プランＰＬ１１をキャンセルしたうえで、料金プランＰＬ１３への予約申し込みをし直すといった手間が省ける。また、不図示であるが、情報処理装置１００は、料金プランＰＬ１３への変更申し込みを受け付けると、申し込み金額「３５，０００円」の決済処理を行うことができる。情報処理装置１００は、現時点で、申し込み金額「４０，０００円」の決済を済ませているため、例えば、差額「５，０００円」をユーザＵ１に返金する決済処理を行うことができる。

また、事業主Ｙは、料金プランＰＬ１３への変更申し込み（予約申し込み）が行われる毎に、保険会社ＨＹとの間で、この申し込みに係る加入契約を結ぶ。つまり、事業主Ｙは、１取り引き（１申し込み）につき、保険会社ＨＹとの間で、１加入契約を結ぶ。したがって、情報処理装置１００は、ステップＳ８において、この加入契約に関する加入契約処理を実行する。図１の例では、ユーザＵ１が料金プランＰＬ１３への変更申し込みを行ったことに応じて、この１変更申し込みにつき、情報処理装置１００は、事業主Ｙが保険会社ＨＹのキャンセル保険に加入するための加入契約処理を実行する。

ここで、例えば、情報処理装置１００は、料金プランＰＬ１１から料金プランＰＬ１３への変更申し込みが行われなかった場合、申し込み金額「４０，０００円」に対応する電子ポイントを算出し、算出した電子ポイントをユーザＵ１に対して付与する場合がある。例えば、ユーザＵ１の会員ランク（レギュラー）に対応する付与率が１％であるとすると、情報処理装置１００は、申し込み金額「４０，０００円」×付与率「０．０１」に基づく「４００ｐｔ」をユーザＵ１に対して付与する場合がある。しかしながら、ユーザＵ１が料金プランＰＬ１３への変更申し込みを行ったことにより、ユーザＵ１には電子ポイント「４００ｐｔ」が付与されなくなる。

事業主Ｙは、自社の資金源の一部をユーザＵ１に付与する電子ポイントに利用するが、ユーザＵ１が料金プランＰＬ１３への変更申し込みを行ったことにより、自社の資金源の一部を電子ポイント「４００ｐｔ」に利用する必要がなくなる。したがって、情報処理装置１００は、電子ポイント「４００ｐｔ」に対応する保険料として、例えば、保険料「４００円」を保険会社ＨＹの保険会社装置４０に送金することにより、事業主Ｙを料金プランＰＬ１３への変更申し込みに対応するキャンセル保険に加入させる、といった加入契約処理を行う。

このような状態において、ユーザＵ１は、端末装置１０を操作し、料金プランＰＬ１３への予約申し込みをキャンセルしたとする。かかる場合、端末装置１０は、料金プランＰＬ１３への予約申し込みのキャンセルを要求するキャンセル要求を情報処理装置１００に送信する。

情報処理装置１００は、キャンセル要求を受信すると、料金プランＰＬ１３への予約申し込みを取り消すキャンセル処理を実行する（ステップＳ９）。例えば、情報処理装置１００は、料金プランＰＬ１３への予約申し込みを取り消したうえで、予約サイトＹ１でのキャンセルポリシーに基づいて、キャンセル料を算出する。例えば、チェックイン日の７日前までのキャンセルであれば申し込み金額の１０％をキャンセル料として課すことがキャンセルポリシーにて定められており、キャンセル要求を受信した現在日がチェックイン日の７日よりも前であれば、情報処理装置１００は、キャンセル料「３，５００」を算出する。

上記の通り、本実施形態では、一律２０％（申し込み金額の２０％）がキャンセル料として課せられる。したがって、情報処理装置１００は、キャンセル料「７，０００」を算出する。また、情報処理装置１００は、ユーザＵ１は料金プランＰＬ１３をキャンセル時には保険金「３，５００円」を受け取ることができるため、このキャンセル料「７，０００」に対して保険金「３，５００円」を適用することで、最終的にユーザＵ１が支払うべきキャンセル料を算出する。かかる例では、ユーザＵ１は、キャンセル料「７，０００」から保険金「３，５００円」を差し引いた差額「３，５００円」を支払うことになる。このため、情報処理装置１００は、キャンセル料「７，０００」に対して保険金「３，５００円」を適用することで、キャンセル料「３，５００円」を算出する。

ユーザＵ１は、現在、申し込み金額「３５，０００円」の決済が済んでいるが、保険金「３，５００円」が適用された適用後のキャンセル料「３，５００円」を支払いさえすればよい。このため、情報処理装置１００は、申し込み金額「３５，０００円」から保険適用後のキャンセル料「３，５００円」を差し引いた差額「３１，５００円」をユーザＵ１に返金する返金処理を行う。例えば、情報処理装置１００は、カード会社装置８０にアクセスし、差額「３１，５００円」をユーザＵ１に返金するよう要求する。このようにして、ユーザＵ１は、間接的に保険金「３，５００円」を受け取ることができる。

なお、情報処理装置１００は、装置側で保険金「３，５００円」を動的に適用してしまうのではなく、つまり、保険適用後のキャンセル料「３，５００円」を差し引いた差額「３１，５００円」をユーザＵ１に返金するのではなく、例えば、カード会社装置８０に対して、申し込み金額「３５，０００円」全額をユーザＵ１に返金させるとともに、保険金「３，５００」もユーザＵ１に送金させてもよい。また、かかる場合、情報処理装置１００は、当初のキャンセル料「７，０００円」を支払うようユーザに指示することができる。この場合、ユーザＵ１は、例えば、キャンセル料「７，０００円」のうち「３，５００円」分を保険金「３，５００」で賄うことができる。

また、情報処理装置１００は、ユーザＵ１から料金プランＰＬ１２への変更申し込みを受け付けた場合には、料金プランＰＬ１２の申し込み金額「３０，０００円」に基づく決済処理を行う。また、情報処理装置１００は、ユーザＵ１から料金プランＰＬ１２のキャンセル要求を受信した場合には、料金プランＰＬ１２のキャンセル自体は受領するものの、申し込み金額「３０，０００円」の返金処理は行わない。

さて、これまで説明してきたように、情報処理装置１００は、第１のプランへの申し込みを受け付けた後に、第２のプランおよび第３のプランのうち、いずれかのプランへの変更申し込みを受け付けるためのコンテンツを提示する。また、第３のプランにおいて、キャンセル保険に加入契約するのは、申し込みを行ったユーザ本人ではなく、サービスを提供する事業主である。

例えば、ユーザは、キャンセルの可能性があるため、安全策をとってキャンセル時にも返金される料金プランＰＬ１１へ予約申し込みしておき、例えば、チェックイン日が近づきキャンセルすることないと確証が得られた場合には、プランＳＶ１はそのままで料金の安い料金プランＰＬ１２へと変更することができる。さらにユーザは、面倒な手続きなしに簡単な作業で料金プランＰＬ１２へと変更することができる。このようなことから、実施形態にかかる情報処理装置１００は、ユーザにとって利便性の高い取り引き申し込みを実現することができる。

例えば、ユーザは、キャンセルの可能性があるため、安全策をとってキャンセル時にも返金される料金プランＰＬ１１へ予約申し込みしておき、例えば、チェックイン日が近づきキャンセルすることないと確証が得られた場合には、プランＳＶ１はそのままで料金の安い料金プランＰＬ１２へと変更しようと考える。また、ユーザは、キャンセルすることないと確証が得られたものの直前に不測の事態が起きてキャンセルせざるを得なくなるかもしれないと考える。このような場合、ユーザは、料金プランＰＬ１１よりも安く、かつ、キャンセル料が補償される料金プランＰＬ１２へと変更することができるため、例えば、安全志向のユーザにとっては料金プランＰＬ１２以外にも選択肢が増えて便利である。さらにユーザは、面倒な手続きなしに簡単な作業で料金プランＰＬ１３へと変更することができる。このようなことから、実施形態にかかる情報処理装置１００は、ユーザにとって利便性の高い取り引き申し込みを実現することができる。

なお、図１では、情報処理装置１００は、事業主Ｙに属するサーバ装置である旨説明したが、情報処理装置１００は、事業主Ｙおよびカード会社ＨＹのいずれにも属さないサーバ装置であってもよい。

また、情報処理装置１００が、キャンセル要求を受信すると予約申し込みを取り消すキャンセル処理を実行する旨説明したが（ステップＳ９）、ユーザに対してキャンセルの理由を求め、キャンセルの理由が所定の条件情報を満たすか否かに応じたキャンセル処理を実行してもよい。一例を示すと、キャンセルの理由が「チェックイン日、現地に台風発生予報のため」であり、条件情報に「悪天候事由」が定められている場合、情報処理装置１００は、「チェックイン日、現地に台風発生」の可能性があるか否かを判定する。情報処理装置１００は、「チェックイン日、現地に台風発生」の可能性があるとの判定結果を得た場合には、キャンセルの理由が所定の条件情報を満たすと判断し、予約申し込みを取り消すキャンセル処理を実行する。一方、情報処理装置１００は、キャンセルの理由が所定の条件情報を満たさないと判断した場合、つまりユーザには予約申し込みをキャンセルする正当な理由が存在しないと判断した場合には、キャンセルを受け付ける一方で、例えば、申し込み金額全額の支払い義務をユーザに課す。なお、このような支払い義務をユーザに課すためには、例えば、キャンセルポリシーや、申し込みを受け付ける前段階（例えば、ページＰ１あるいはＰ２）にて、ユーザにこのことが通知されている必要がある。

なお、実施形態にかかる情報処理では、情報処理装置１００は、料金プランＰＬ１１から料金プランＰＬ１２、または、料金プランＰＬ１３のいずれかに予約申し込みが変更されたとしても、プランＳＶ１自体はそのまま維持する。このため、図１の例では、ユーザＵ１は、料金プランＰＬ１３へと変更したとしても、例えば、「露天風呂付離れ客室１０１号」、「朝食・夕食有」といったサービスを受けることができる。

〔２．情報処理装置の構成〕
次に、図３を用いて、実施形態にかかる情報処理装置１００について説明する。図３は、実施形態にかかる情報処理装置１００の構成例を示す図である。図３に示すように、情報処理装置１００は、通信部１１０と、記憶部１２０と、制御部１３０とを有する。例えば、情報処理装置１００は、図１で説明した情報処理を行うサーバ装置である。

（記憶部１２０について）
記憶部１２０は、例えば、ＲＡＭ（Random Access Memory)、フラッシュメモリ等の半導体メモリ素子またはハードディスク、光ディスク等の記憶装置によって実現される。記憶部１２０は、サービス情報記憶部１２１と、申込情報記憶部１２２とを有する。

（サービス情報記憶部１２１について）
サービス情報記憶部１２１は、サービスに関する情報を記憶する。本実施形態では宿泊予約サービスを対象としているが、このような場合、サービス情報記憶部１２１は、各種宿泊プランに関する情報を記憶する。例えば、サービス情報記憶部１２１は、宿泊取設毎に、当該宿泊施設が提供している宿泊プランに関する情報を記憶する。ここで、図４に実施形態にかかるサービス情報記憶部１２１の一例を示す。図４の例では、サービス情報記憶部１２１は、「プランＩＤ」、「プラン名」、「基本料金プランＩＤ」、「キャンセル条件（１）」、「金額（１）」、「変更可能プラン」、「キャンセル条件（２）」、「金額（２）」といった項目を有する。

「プランＩＤ」は、宿泊プランを識別する識別情報を示す。「プラン名」は、宿泊プランの名称を示す。「基本料金プランＩＤ」は、対応する宿泊プランに含まれる料金プランの１つであり、変更を行う前に申し込めることのできる料金プランを識別する識別情報を示す。「キャンセル条件（１）」は、対応する基本料金プランの予約申し込みをキャンセルする際の条件を示す。具体的には、「キャンセル条件（１）」は、対応する基本料金プランの予約申し込みをキャンセルする際における返金の条件を示す。「金額（１）」は、対応する基本料金プランの申し込み金額を示す。

「変更可能料金プラン」は、対応する基本料金プランの予約申し込みを行った後に当該基本料金プランから変更することのできる料金プランを識別する識別情報を示す。また、「変更可能料金プラン」は、対応する宿泊プランに含まれる料金プランの１つである。図１の例では、変更可能プラン「ＰＬ１２」および「ＰＬ１３」が入力されているが、これは、料金プランＰＬ１１の予約申し込みを行った後に、料金プランＰＬ１１から変更することのできる料金プランが料金プランＰＬ１２およびＰＬ１３である例を示す。

「キャンセル条件（２）」は、対応する変更可能料金プランの予約申し込みをキャンセルする際の条件を示す。具体的には、「キャンセル条件（２）」は、対応する変更可能料金プランの予約申し込みをキャンセルする際における返金の条件を示す。「金額（２）」は、対応する変更可能料金プランの申し込み金額を示す。

すなわち、図４の例では、プランＩＤ「ＳＶ１」によって識別される宿泊プラン（プランＳＶ１）の名称は「ＰＮＡ１」であり、プランＳＶ１には、料金プランＰＬ１１、ＰＬ１２およびＰＬ１３が含まれる例を示す。また、図４の例では、料金プランＰＬ１１、ＰＬ１２およびＰＬ１３のうち、基本料金プランである料金プランＰＬ１１には、「チェックイン日の１日前までのキャンセルでは全額返金」といったキャンセル条件が設定されており、申し込み金額は「４０，０００円」である例を示す。

また、図４の例では、料金プランＰＬ１１の予約申し込みを行った後に、料金プランＰＬ１１から変更することのできる料金プランである料金プランＰＬ１２には、「キャンセル時返金無し」といったキャンセル条件が設定されており、申し込み金額は「３０，０００円」である例を示す。また、図４の例では、料金プランＰＬ１１の予約申し込みを行った後に、料金プランＰＬ１１から変更することのできる料金プランである料金プランＰＬ１３には、「キャンセル時キャンセル保険適用」といったキャンセル条件が設定されており、申し込み金額は「３５，０００円」である例を示す。

（申込情報記憶部１２２について）
申込情報記憶部１２２は、予約申し込みに関する各種周辺情報を記憶する。ここで、図５に実施形態にかかる申込情報記憶部１２２の一例を示す。図５の例では、申込情報記憶部１２２は、「ユーザＩＤ」、「会員ランク」、「申込プラン」、「キャンセル保険金額」、「変更申込プラン」、「キャンセル情報」といった項目を有する。

「ユーザＩＤ」は、ユーザまたはユーザの端末装置１０を識別する識別情報を示す。「会員ランク」は、予約サイトＹ１でのユーザの会員ランクを示す。「プランＩＤ」は、宿泊プランを識別する識別情報を示す。「申込プラン」は、変更を行う前にユーザが予約申し込みした料金プランを識別する識別情報を示す。したがって、「申込プラン」には、図４で説明した「基本料金プランＩＤ」が入力される。「キャンセル保険金額」は、対応する宿泊プランに含まれる料金プランのうち、キャンセル保険が適用される料金プランがキャンセルされた場合にユーザが受け取ることのできる保険金の金額を示す。

「変更申込プラン」は、対応する「申込プラン」から予約申し込みが変更された変更後の料金プランを識別する識別情報を示す。「キャンセル情報」は、変更後の料金プランの予約申し込みがキャンセルされたか否かを示す情報である。例えば、図１に示すステップＳ９のキャンセル処理において、ユーザから予約申し込みのキャンセル要求が受信された場合には、「キャンセル情報」には所定の印（○マーク等）が入力される。

すなわち、図５の例では、ユーザＩＤ「Ｕ１」によって識別されるユーザ（ユーザＵ１）は、会員ランク「レギュラー」である例を示す。また、図５の例では、ユーザＵ１が、プランＳＶ１の料金プランの１つである料金プランＰＬ１１に予約申し込みした後に、プランＳＶ１の料金プランの１つである料金プランＰＬ１３へと予約申し込みを変更した例を示す。また、図５の例では、ユーザＵ１が料金プランＰＬ１３の予約申し込みをキャンセルした場合には保険金「３，５００円」を受け取り可能であることが算出された例を示す。また、図５の例では、ユーザＵ１が料金プランＰＬ１３への予約申し込みをキャンセルした例を示す。

（制御部１３０について）
図３に戻り、制御部１３０は、ＣＰＵ（Central Processing Unit）やＭＰＵ（Micro Processing Unit）等によって、情報処理装置１００内部の記憶装置に記憶されている各種プログラムがＲＡＭを作業領域として実行されることにより実現される。また、制御部１３０は、例えば、ＡＳＩＣ（Application Specific Integrated Circuit）やＦＰＧＡ（Field Programmable Gate Array）等の集積回路により実現される。

図３に示すように、制御部１３０は、受信部１３１と、申込受付部１３２と、決済部１３３と、算出部１３４と、サービス提供部１３５と、変更受付部１３６と、キャンセル処理部１３７とを有し、以下に説明する情報処理の機能や作用を実現または実行する。なお、制御部１３０の内部構成は、図３に示した構成に限られず、後述する情報処理を行う構成であれば他の構成であってもよい。また、制御部１３０が有する各処理部の接続関係は、図３に示した接続関係に限られず、他の接続関係であってもよい。

（受信部１３１について）
受信部１３１は、ユーザ操作に応じて端末装置１０から送信される各種情報を受信する。例えば、受信部１３１は、コンテンツに含まれる操作ボタンが押下された場合に、押下情報を端末装置１０から受信する。図１の例では、受信部１３１は、Ｂ１押下情報、Ｂ２押下情報、Ｂ３押下情報を受信する。なお、受信部１３１は、例えば、端末装置１０の識別情報（ユーザＩＤ）や、コンテンツでのユーザによる設定情報あるいは入力情報を含む押下情報を受信することができる。また、受信部１３１は、受信した情報を申込情報記憶部１２２に格納する。

（申込受付部１３２について）
申込受付部１３２は、取り引きの申し込みを受け付ける。具体的には、申込受付部１３２は、所定の取り引きにおける料金プランの１つである第１のプランであって、キャンセルを行う場合の条件として第１の条件が設定される第１のプランへの申し込みを受け付ける。例えば、申込受付部１３２は、第１の条件として、ユーザによりキャンセルされた場合に購入金額の一部または全額がユーザに返金される条件が設定される第１のプランへの申し込みを受け付ける。図１の例では、申込受付部１３２は、料金プランＰＬ１１（第１のプラン）に対応するページＰ２においてボタンＢＴ２が押下されたことを示すＢＴ２押下情報が受信された場合には、料金プランＰＬ１１への予約申し込みを受け付ける。

（決済部１３３について）
決済部１３３は、取り引きに関する決済を行う。例えば、決済部１３３は、申込受付部１３２により第１のプランへの申し込みが受け付けられた場合に、申し込み金額を決済する決済処理を行う。例えば、決済部１３３は、ユーザにより取り引きの事前決済（カード決済）が指定された場合には、決済処理を行う。例えば、決済部１３３は、図１で説明した決済処理を行う。

（算出部１３４について）
算出部１３４は、キャンセル料を補償する保険金を算出する。例えば、算出部１３４は、所定の取り引きに関する電子商取引サービス（図１の例では、予約サイトＹ１）でのユーザの会員ランクに応じた割合に基づいて、保険金を算出する。例えば、算出部１３４は、キャンセル料を補償する保険金として、所定の取り引きに関する電子商取引サービスを提供する事業主であって、所定の取り引きがキャンセルされた場合に発生するキャンセル料を補償する保険であるキャンセル保険に加入する事業主によって支払われる保険料に基づいて、保険金を算出する。例えば、算出部１３４は、保険金として、ユーザによって所定の取り引きが行われる度に、事業主がキャンセル保険に加入することで支払われる保険料に基づいて、保険金を算出する。例えば、算出部１３４は、図１で説明した算出処理を行う。

（サービス提供部１３５について）
サービス提供部１３５は、申込受付部１３２により第１のプランへの申し込みが受け付けられた後に、第１のプランから、所定の取り引きにおける料金プランの１つである第２のプランであって、キャンセルを行う場合の条件として第１の条件とは異なる第２の条件が設定される第２のプランへの変更申し込みを受け付けるためのコンテンツを提示する。例えば、サービス提供部１３５は、第１の条件とは異なる第２の条件として、ユーザによりキャンセルされた場合に購入金額が返金されない条件が設定される第２のプランへの変更申し込みを受け付けるためのコンテンツを提示する。より具体的には、サービス提供部１３５は、申込受付部１３２により第１のプランへの申し込みが受け付けられた後に、第２のプラン、または、所定の取り引きにおける料金プランの１つである第３のプランであって、ユーザによりキャンセルされた場合に発生するキャンセル料を補償する第３のプランへの変更申し込みを受け付けるためのコンテンツを提示する。

一例としては、サービス提供部１３５は、図１で説明した配信処理を行う。例えば、サービス提供部１３５は、算出部１３４から保険金を示す保険金情報を受信すると、保険金情報に基づいて、第２のプランである料金プランＰＬ１２、または、第３のプランである料金プランＰＬ１３への変更申し込みを受け付けるためのコンテンツであるページＰ３を生成する。そして、サービス提供部１３５は、生成したコンテンツを端末装置１０に配信する。なお、サービス提供部１３５は、押下情報が受信されたことに応じて、ページＰ１やページＰ２の生成および配信も行う。また、このようなことからサービス提供部１３５は、提示部に対応する処理部である。

（変更受付部１３６について）
変更受付部１３６は、申込受付部１３２により第１のプランへの申し込みが受け付けられた後に、第２のプラン、または、第３のプランへの変更申し込みを受け付ける。図１の例では、変更受付部１３６は、ページＰ３のボタンＢＴ３２が押下されたＢＴ３２押下情報が受信された場合には、予約申し込みの申し込み先を料金プランＰＬ１１から料金プランＰＬ１２へと変更する変更申し込みを受け付ける。また、決済部１３３は、この変更申し込みに応じて、ユーザに返金するための決済処理を行う。

また、変更受付部１３６は、ページＰ３のボタンＢＴ３３が押下されたＢＴ３３押下情報が受信された場合には、予約申し込みの申し込み先を料金プランＰＬ１１から料金プランＰＬ１３へと変更する変更申し込みを受け付ける。また、決済部１３３は、この変更申し込みに応じて、ユーザに返金するための決済処理を行う。

（キャンセル処理部１３７について）
キャンセル処理部１３７は、取り引きのキャンセルに関する処理を行う。例えば、キャンセル処理部１３７は、ユーザから取り引きのキャンセルを要求するキャンセル要求を受信した場合には、キャンセルポリシーやキャンセル時期に応じて定められている返金率に基づいてキャンセル料を算出する。そして、キャンセル処理部１３７は、申し込み金額からキャンセル料を差し引いた差額を返金する。例えば、キャンセル処理部１３７は、第３のプランがキャンセルされた場合には、キャンセル料に保険金を適用することで適切な金額を返金する。例えば、キャンセル処理部１３７は、図１で説明したキャンセル処理を行う。

〔３．処理手順〕
次に、図６を用いて、実施形態にかかる情報処理の手順について説明する。図６は、実施形態にかかる情報処理手順を示すフローチャートである。なお、図６では、取り引きを宿泊プランへの予約申し込みとして説明する。

次に、申込受付部１３２は、宿泊プランに含まれる料金プランの１つである第１のプランへの予約申し込みを受け付けたか否かを判定する（ステップＳ１０１）。申込受付部１３２は、予約申し込みを受け付けていない場合には（ステップＳ１０１；Ｎｏ）、受け付けるまで待機する。一方、決済部１３３は、申込受付部１３２により受け付けられた第１のプランへの予約申し込みに対応する申し込み金額を決済する決済処理を行う（ステップＳ１０２）。また、算出部１３４は、宿泊プランに含まれる料金プランの１つである第３のプランがキャンセルされた場合に発生するキャンセル料を補償する保険金の金額を算出する算出処理を行う（ステップＳ１０３）。

次に、サービス提供部１３５は、予約申し込みの申し込み先を第１のプランから第２のプラン、または、第３のプランへと変更させる変更申し込みを受け付けるための変更用コンテンツ（図１の例では、ページＰ３）を配信する配信処理を行う（ステップＳ１０４）。例えば、サービス提供部１３５は、算出部１３４による算出結果を用いて、変更用コンテンツ生成する。そして、サービス提供部１３５は、生成した変更用コンテンツを端末装置１０に配信する。

このような状態において、変更受付部１３６は、予約申し込みの申し込み先を第１のプランから第２のプラン、または、第３のプランへと変更させる変更申し込みを受け付けたか否かを判定する（ステップＳ１０５）。変更受付部１３６は、変更申し込みを受け付けていない場合には（ステップＳ１０５；Ｎｏ）、ステップＳ１０８を行わせる。ステップＳ１０８については後述する。一方、制御部１３０は、変更受付部１３６により受け付けられた変更申し込みが示す変更内容に基づいて、宿泊予約サービスを提供する事業主がキャンセル保険に加入するための加入契約処理を行う（ステップＳ１０６）。例えば、制御部１３０は、変更内容が予約申し込みの申し込み先を第１のプランから第３のプランへと変更させる変更申し込みが受け付けられたことを示す場合には、加入契約処理を行う。なお、変更受付部１３６は、例えば、図１の例では、ＢＴ３３押下情報が受信された場合には、予約申し込みを受け付けたと判定する。

次に、キャンセル処理部１３７は、予約申し込みをキャンセルするキャンセル要求を受け付けたか否かを判定する（ステップＳ１０７）。具体的には、キャンセル処理部１３７は、現在予約申し込みされている料金プランの予約申し込みをキャンセルするキャンセル要求を受け付けたか否かを判定する。そして、キャンセル処理部１３７は、キャンセル要求を受け付けていない場合には（ステップＳ１０７；Ｎｏ）、処理を終了する。一方、キャンセル処理部１３７は、キャンセル要求を受け付けた場合には（ステップＳ１０７；Ｙｅｓ）、キャンセル要求対象の料金プランに基づいて、キャンセル処理を行う（ステップＳ１０８）。

例えば、キャンセル処理部１３７は、現在予約申し込みされている料金プランが第１のプランである場合（つまり、第２のプランまたは第３のプランへの変更申し込みが行われていない場合）には、第１のプランに対応するキャンセル条件（チェックイン日の１日前までのキャンセルであれば、申し込み金額の全額を返金）に基づいて、ユーザに返金するキャンセル処理を行う。

また、キャンセル処理部１３７は、現在予約申し込みされている料金プランが第２のプランである場合（つまり、第２のプランへの変更申し込みが行われている場合）には、第２のプランに対応するキャンセル条件（返金なし）に基づいて、キャンセル処理を行う。

また、キャンセル処理部１３７は、現在予約申し込みされている料金プランが第３のプランである場合（つまり、第３のプランへの変更申し込みが行われている場合）には、第３のプランに対応するキャンセル条件（キャンセル保険適用）に基づいて、第３のプランに対応するキャンセル料に対してステップＳ１０３で算出された保険金を適用することで、適切な金額を返金するキャンセル処理を行う。

〔４．変形例〕
上記実施形態にかかる情報処理装置１００は、上記実施形態以外にも種々の異なる形態にて実施されてよい。そこで、以下では、情報処理装置１００の他の実施形態について説明する。

〔４−１．変更申し込み可能期間〕
上記実施形態では、サービス提供部１３５が、第１の条件とは異なる第２の条件として、ユーザによりキャンセルされた場合に購入金額が返金されない条件が設定される第２のプランへの変更申し込みを受け付けるためのコンテンツを提示する例を示した。しかし、サービス提供部１３５は、所定期間の間において、第２のプランへの変更申し込みを受け付けるためのコンテンツを提示してもよい。言い換えれば、サービス提供部１３５は、申込受付部１３２により第１のプランへの申し込みが受け付けられた後に、第２のプランへの変更申し込みを受け可能な期間が条件として設定されたコンテンツを提示する。一例を示すと、サービス提供部１３５は、申込受付部１３２により第１のプランへの申し込みが受け付けられてから、チェックイン日の３日前までの期間の間、第２のプランへの変更申し込みを受け可能なコンテンツを提示する。

これにより、実施形態にかかる情報処理装置１００は、チェックイン日直前の変更により施設事業主側にデメリットが生じることを防止することができる。

〔４−２．変更申し込み不可能期間〕
また、サービス提供部１３５は、キャンセル料が発生する発生期間に関する所定の条件が満たされた場合には第３のプランから他のプランへの変更が不可能とされる変更申し込みを受け付けるためのコンテンツを提示してもよい。例えば、サービス提供部１３５は、第３のプランへの変更申し込みが受け付けられている状態でこの発生期間に入った場合には第３のプランから他のプランへの変更が不可能とされる変更申し込みを受け付けるためのコンテンツを提示する。この点について、図１の例を用いて説明する。

例えば、第３のプランの一例である料金プランＰＬ１３では、チェックイン日の１４日前からチェックイン日の１日前までの期間（期間ＰＥとする）中でのキャンセルについて５０％のキャンセル料が課せられることが定められているとする。かかる場合、サービス提供部１３５は、料金プランＰＬ１３への変更申し込みとして、料金プランＰＬ１３への変更申し込みが受け付けられている状態で期間ＰＥに入った場合には、例えば、料金プランＰＬ１３から料金プランＰＬ１２（第２のプランの一例）への変更が不可能とされるページＰ３（コンテンツの一例）を提示する。

この点を言い換えれば、サービス提供部１３５は、料金プランＰＬ１３への変更申し込みが受け付けられている状態で期間ＰＥに入った場合においてユーザが料金プランＰＬ１３から料金プランＰＬ１２へと変更しようとした場合には、変更受付部１３６に対して変更申し込みを却下するよう制御する。一方、変更受付部１３６は、料金プランＰＬ１３への変更申し込みが受け付けられている状態で、例えば、ユーザが期間ＰＥよりも前の期間で料金プランＰＬ１３から料金プランＰＬ１２への変更しようとした場合には、この変更申し込みを受け付けることができる。また、サービス提供部１３５は、そういうコンテンツを提示することができる。

これにより、実施形態にかかる情報処理装置１００は、ユーザ側の都合で自由に料金の安いプランへ変更できないよう制御することができるため、施設事業主の損害が大きくなることを防ぐことができる。

〔４−３．キャンセル状況に基づく保険金算出〕
上記実施形態では、算出部１３４が、所定の取り引きに関する電子商取引サービスでの前記ユーザの会員ランクに応じた割合に基づいて、保険金を算出する例を示した。しかし、算出部１３４は、ユーザが所定の取り引きをこれまでにキャンセルしたキャンセル状況に基づいて、保険金を算出してもよい。

例えば、算出部１３４は、ユーザが取り引きをこれまでにキャンセルしたキャンセル状況が閾値以上のキャンセル率を示す場合には、このキャンセル率に応じて、当該ユーザの会員ランクに応じた割合を下げる。そして、算出部１３４は、下げた後の割合を用いて電子ポイントを算出する。他の一例としては、算出部１３４は、ユーザが取り引きをこれまでにキャンセルしたキャンセル状況が閾値以上のキャンセル回数を示す場合には、このキャンセ回数に応じて、当該ユーザの会員ランクに応じた割合を下げる。そして、算出部１３４は、下げた後の割合を用いて電子ポイントを算出する。

取り引きがキャンセルされた場合、例えば、施設事業主（例えば、宿泊施設側）は、デメリットを受ける場合が多い。例えば、施設事業主は、予約申し込み金額の１００％をキャンセル料として支払わす場合であっても、チェックイン当日に向けてサービスの下準備を進めている場合があるが、この下準備が無駄になってしまう等のデメリットを受ける場合がある。情報処理装置１００は、このデメリットの対価としてユーザにもペナルティ（通常よりも保険金を下げる）を与えることができる。

〔４−４．サービスについて〕
上記実施形態では、宿泊予約の予約申し込みを取り引きの一例として説明してきた。具体的には、サービス提供部１５が、申込受付部１３２により１つの宿泊プランに含まれる料金プランである第１のプランへの申し込みが受け付けられた後に、この宿泊プランに含まれる別の料金プランである第２のプラン、または、この宿泊プランに含まれる別の料金プランの１つである第３のプランへの変更申し込みを受け付けるためのコンテンツを提示する例を示した。

しかし、実施形態にかかる情報処置で対象とされる取り引きは、宿泊予約の予約申し込みに限定されない。例えば、取り引きは、ＥＣ（Electronic Commerce）サイトでの商品購入に係る一連の取り引きであってもよい。そして、このような場合、取り引きのキャンセルは、例えば、購入済みの商品の返品に対応する。そうすると、第１のプランは、購入後の商品を配送して返品する場合の送料（キャンセル料の一例）を店舗側が全額負担するといったプランになる。また、第２のプランは、購入後の商品を配送して返品する場合の送料（キャンセル料の一例）をユーザ側が全額負担するといったプランになる。また、第３のプランは、購入後の商品を配送して返品する場合の送料（キャンセル料の一例）に対応する保険金をユーザが受け取ることのできるプランとなる。また、この場合、第１のプランに対応する商品の価格が最も高く、第２のプランに対応する商品の価格が最も安く、第３のプランに対応する商品の価格が中間価格、といった値段設定がなされてもよい。

このように、実施形態にかかる情報処理装置１００は、様々なサービスに対応して、キャンセル時のキャンセル料を補償する権利をユーザに与えることができるため、サービス利用時の安心感を様々な場面でユーザに与えることができる。

〔５．ハードウェア構成〕
また、上記実施形態にかかる情報処理装置１００は、例えば図７に示すような構成のコンピュータ１０００によって実現される。図７は、情報処理装置１００の機能を実現するコンピュータ１０００の一例を示すハードウェア構成図である。コンピュータ１０００は、ＣＰＵ１１００、ＲＡＭ１２００、ＲＯＭ１３００、ＨＤＤ１４００、通信インターフェイス（Ｉ／Ｆ）１５００、入出力インターフェイス（Ｉ／Ｆ）１６００、及びメディアインターフェイス（Ｉ／Ｆ）１７００を有する。

ＣＰＵ１１００は、ＲＯＭ１３００又はＨＤＤ１４００に格納されたプログラムに基づいて動作し、各部の制御を行う。ＲＯＭ１３００は、コンピュータ１０００の起動時にＣＰＵ１１００によって実行されるブートプログラムや、コンピュータ１０００のハードウェアに依存するプログラム等を格納する。

ＨＤＤ１４００は、ＣＰＵ１１００によって実行されるプログラム、および、かかるプログラムによって使用されるデータ等を格納する。通信インターフェイス１５００は、通信網５０を介して他の機器からデータを受信してＣＰＵ１１００へ送り、ＣＰＵ１１００が生成したデータを、通信網５０を介して他の機器へ送信する。

ＣＰＵ１１００は、入出力インターフェイス１６００を介して、ディスプレイやプリンタ等の出力装置、及び、キーボードやマウス等の入力装置を制御する。ＣＰＵ１１００は、入出力インターフェイス１６００を介して、入力装置からデータを取得する。また、ＣＰＵ１１００は、生成したデータを、入出力インターフェイス１６００を介して出力装置へ出力する。

メディアインターフェイス１７００は、記録媒体１８００に格納されたプログラム又はデータを読み取り、ＲＡＭ１２００を介してＣＰＵ１１００に提供する。ＣＰＵ１１００は、かかるプログラムを、メディアインターフェイス１７００を介して記録媒体１８００からＲＡＭ１２００上にロードし、ロードしたプログラムを実行する。記録媒体１８００は、例えばＤＶＤ（Digital Versatile Disc）、ＰＤ（Phase change rewritable Disk）等の光学記録媒体、ＭＯ（Magneto-Optical disk）等の光磁気記録媒体、テープ媒体、磁気記録媒体、または半導体メモリ等である。

例えば、コンピュータ１０００が実施形態にかかる情報処理装置１００として機能する場合、コンピュータ１０００のＣＰＵ１１００は、ＲＡＭ１２００上にロードされたプログラムを実行することにより、制御部１３０の機能を実現する。また、ＨＤＤ１４００には、記憶部１２０内のデータが格納される。コンピュータ１０００のＣＰＵ１１００は、これらのプログラムを、記録媒体１８００から読み取って実行するが、他の例として、他の装置から、通信網５０を介してこれらのプログラムを取得してもよい。

〔６．その他〕
また、図示した各装置の各構成要素は機能概念的なものであり、必ずしも物理的に図示の如く構成されていることを要しない。すなわち、各装置の分散・統合の具体的形態は図示のものに限られず、その全部または一部を、各種の負荷や使用状況などに応じて、任意の単位で機能的または物理的に分散・統合して構成することができる。

以上、本願の実施形態をいくつかの図面に基づいて詳細に説明したが、これらは例示であり、発明の開示の欄に記載の態様を始めとして、当業者の知識に基づいて種々の変形、改良を施した他の形態で本発明を実施することが可能である。

また、上述してきた「部（section、module、unit）」は、「手段」や「回路」などに読み替えることができる。例えば、取得部は、取得手段や取得回路に読み替えることができる。

１ 情報処理システム
１０ 端末装置
１００ 情報処理装置
１２０ 記憶部
１２１ サービス情報記憶部
１２２ 申込情報記憶部
１３０ 制御部
１３１ 受信部
１３２ 申込受付部
１３３ 決済部
１３４ 算出部
１３５ サービス提供部
１３６ 変更受付部
１３７ キャンセル処理部

Claims (13)

1. 所定の取り引きにおける料金プランの１つである第１のプランであって、キャンセルを行う場合の条件として第１の条件が設定される第１のプランへの申し込みを受け付ける申込受付部と、
   前記申込受付部により前記第１のプランへの申し込みが受け付けられた後に、前記第１のプランから、前記所定の取り引きにおける料金プランの１つである第２のプランであって、キャンセルを行う場合の条件として第１の条件とは異なる第２の条件が設定される第２のプランへの変更申し込みを受け付けるためのコンテンツを提示する提示部と、
   を有することを特徴とする情報処理装置。
2. 前記申込受付部は、前記第１の条件として、ユーザによりキャンセルされた場合に購入金額の一部または全額が前記ユーザに返金される条件が設定される前記第１のプランへの申し込みを受け付け、
   前記提示部は、前記第１の条件とは異なる第２の条件として、前記ユーザによりキャンセルされた場合に購入金額が返金されない条件が設定される前記第２のプランへの変更申し込みを受け付けるための前記コンテンツを提示する
   ことを特徴とする請求項１に記載の情報処理装置。
3. 前記提示部は、所定期間の間において前記変更申し込みを受け付けるための前記コンテンツを提示する
   ことを特徴とする請求項２に記載の情報処理装置。
4. 前記提示部は、前記申込受付部により前記第１のプランへの申し込みが受け付けられた後に、前記第２のプラン、または、前記所定の取り引きにおける料金プランの１つである第３のプランであって、ユーザによりキャンセルされた場合に発生するキャンセル料を補償する第３のプランへの変更申し込みを受け付けるための前記コンテンツを提示する
   ことを特徴とする請求項１〜３のいずれか１つに記載の情報処理装置。
5. 前記提示部は、前記変更申し込みとして、前記キャンセル料が発生する発生期間に関する所定の条件が満たされた場合には前記第３のプランから他のプランへの変更が不可能とされる変更申し込みを受け付けるための前記コンテンツを提示する
   ことを特徴とする請求項４に記載の情報処理装置。
6. 前記提示部は、第３のプランへの変更申し込みが受け付けられている状態で前記発生期間に入った場合には前記第３のプランから他のプランへの変更が不可能とされる変更申し込みを受け付けるための前記コンテンツを提示する
   ことを特徴とする請求項５に記載の情報処理装置。
7. 前記キャンセル料を補償する保険金を算出する算出部をさらに有し、
   前記提示部は、前記算出部により算出された保険金に関する保険金情報が表示される前記コンテンツを提示する
   ことを特徴とする請求項４〜６のいずれか１つに記載の情報処理装置。
8. 前記算出部は、前記所定の取り引きに関する電子商取引サービスでの前記ユーザの会員ランクに応じた割合に基づいて、前記保険金を算出する
   ことを特徴とする請求項７に記載の情報処理装置。
9. 前記算出部は、前記キャンセル料を補償する保険金として、前記所定の取り引きに関する電子商取引サービスを提供する事業主であって、前記所定の取り引きがキャンセルされた場合に発生するキャンセル料を補償する保険であるキャンセル保険に加入する事業主によって支払われる保険料に基づいて、前記保険金を算出する
   ことを特徴とする請求項７または８に記載の情報処理装置。
10. 前記算出部は、前記保険金として、前記ユーザによって前記所定の取り引きが行われる度に、前記事業主が前記キャンセル保険に加入することで支払われる前記保険料に基づいて、前記保険金を算出する
    ことを特徴とする請求項９に記載の情報処理装置。
11. 前記算出部は、前記ユーザが前記所定の取り引きをこれまでにキャンセルしたキャンセル状況に基づいて、前記保険金を算出する
    ことを特徴とする請求項７〜１０のいずれか１つに記載の情報処理装置。
12. 情報処理装置が実行する情報処理方法であって、
    所定の取り引きにおける料金プランの１つである第１のプランであって、キャンセルを行う場合の条件として第１の条件が設定される第１のプランへの申し込みを受け付ける申込受付工程と、
    前記申込受付工程により前記第１のプランへの申し込みが受け付けられた後に、前記第１のプランから、前記所定の取り引きにおける料金プランの１つである第２のプランであって、キャンセルを行う場合の条件として第１の条件とは異なる第２の条件が設定される第２のプランへの変更申し込みを受け付けるためのコンテンツを提示する提示工程と、
    を含むことを特徴とする情報処理方法。
13. 所定の取り引きにおける料金プランの１つである第１のプランであって、キャンセルを行う場合の条件として第１の条件が設定される第１のプランへの申し込みを受け付ける申込受付手順と、
    前記申込受付手順により前記第１のプランへの申し込みが受け付けられた後に、前記第１のプランから、前記所定の取り引きにおける料金プランの１つである第２のプランであって、キャンセルを行う場合の条件として第１の条件とは異なる第２の条件が設定される第２のプランへの変更申し込みを受け付けるためのコンテンツを提示する提示手順と、
    をコンピュータに実行させることを特徴とする情報処理プログラム。

Images