開示される実施形態の理解を容易にするために、多くの具体的な詳細が以下の開示において説明される。しかしながら、開示される実施形態は、本明細書でまさに説明されていることと異なる多くの他の方法で実現されてよい。当業者であれば、開示される実施形態の範囲から逸脱することなく、開示される実施形態に対して修正を行うことができる。したがって、開示される実施形態は、開示される以下の具体的な実施形態に限定されるものではない。
開示される実施形態は、ホテル客室を予約するためのホテル情報処理システム、方法、装置、及び電子デバイス、予約を生成又は管理するための方法、装置、及び電子デバイス、並びに様々な他のホテル情報処理システムを提供する。これらの詳細な説明が、以下の実施形態において示されることになる。
本開示で提供されるホテル情報処理システムの全体的なオペレーションは以下の通りである。すなわち、ホテル客室タイプの予約をユーザのために生成する前に、ホテル予約サブシステムは、第1の管理サブシステムを介して、ユーザのサードパーティアカウントのホテルクレジット資格を確認する。ホテル予約サブシステムは、ユーザのサードパーティアカウントがホテルクレジット資格の確認に合格した場合にだけ、予約を生成する。さらに、ユーザがホテルをチェックアウトした後に、ユーザのサードパーティアカウントからリソースを引き落とすことをサードパーティサブシステムに通知する第1の管理サブシステムによって、予約のリソース引き落としが実施される。ユーザは、予約したホテル客室の保証金を前払いする必要もなく、ホテル予約、チェックイン、及び支払いを直接行うことができる。したがって、ユーザのホテル滞在体験が効果的に改善され得る。
図1は、本開示のいくつかの実施形態によるホテル情報処理システムを例示するブロック図である。本システムは以下のサブシステムを含む。すなわち、ホテル予約サブシステム101と、第1の管理サブシステム103と、サードパーティサブシステム105とである。
例示された実施形態において、ホテル予約サブシステム101は、ユーザのクライアントデバイス(例示されていない)によって送信される指定された客室タイプの予約リクエストを受信し、予約リクエストに基づいて、ユーザのホテルクレジット資格を確認するための第1の通知を第1の管理サブシステム103に送信し、第1の管理サブシステム103によって返信されるユーザのホテルクレジット資格の確認結果を受信し、ホテルクレジット資格の確認結果が合格である場合、予約リクエストに基づいて、指定された客室タイプの第1の予約をユーザのために生成する。
ユーザのクライアントデバイスは、スマートフォンなどの移動通信デバイスを含んでよく、あるいは、パーソナルコンピュータ、携帯情報端末、又はタブレット(例えば、iPad(登録商標))などの端末デバイスを含んでもよい。
ホテル予約サブシステム101は、オンラインホテル予約機能を実装し、概して、ホテルの公式ウェブサイトのサーバに配置される。しかしながら、ホテル予約サブシステム101はサーバに配置されることに限定されるものではなく、本明細書で説明されるホテル予約サブシステム101を実行できる任意のデバイスが用いられてよい。
1つの実施形態において、ユーザはまず、クライアントデバイスを利用して、ホテル予約サブシステム101によって提供されるホテル照会インタフェースを開き、ホテルによって提供される様々な客室タイプを閲覧してよい。ユーザは次に、関心のある客室タイプをクリックして、客室の詳細を閲覧してよい。ユーザがある客室タイプを予約しようと決めた後に、ユーザはさらに、登録されたユーザ名でホテル予約サブシステム101にログインしてよい。ホテル予約サブシステム101は次に、ユーザ名で検索することにより、ユーザの個人情報(例えば、名前、携帯電話番号、及び身分証明書番号)を取得することができる。ユーザがある客室タイプを予約しようと意図し、また当該客室タイプがクレジットに基づく方法を用いて予約可能な場合、ユーザは、ユーザのクライアントデバイスでクレジットの支払い方法を選択し、予約リクエストを提出してよい。予約リクエストは、ネットワーク(例えば、インターネット)を介してホテル予約サブシステム101に送信される。ユーザのクライアントデバイスによって送信される予約リクエストをホテル予約サブシステム101が受信した後に、ホテル予約サブシステム101は、ユーザのホテルクレジット資格を確認するための第1の通知を第1の管理サブシステム103に送信する。これは、この場合の予約がクレジット方法を利用して行われており、第1の管理サブシステム103が組み込まれているか又は設置されている機関(例えば、OTAウェブサイト)によってクレジット管理機能が実施されるからである。第1の通知はユーザの識別情報を含み、ユーザの識別情報は、前述したようにユーザ名で照会することによって、又はユーザのクライアントデバイスからの入力によって取得されてよい。第1の管理サブシステム103が第1の通知に応答して返信したユーザのホテルクレジット資格の確認結果を、ホテル予約サブシステム101が受信した後に、確認結果が合格である場合、ホテル予約サブシステム101は、予約を入れたユーザのために客室タイプのホテル予約(すなわち、第1の予約)を生成する。
第1の予約は、ホテル予約サーバに格納される。ユーザが、予約、ユーザの身分証明書番号、携帯電話番号、又は他の情報と関連付けられた番号を用いてホテルにチェックインする場合、ホテルの管理システムが、第1の予約に従ってユーザのチェックインを進める。ホテル滞在がクレジット方法を利用して予約されるので、ユーザは予約保証金又はチェックイン保証金を前払いする必要がなく、これにより、従来のオンラインホテル予約方法に存在する、保証金がユーザの利用可能な資金を減少させるという問題が解決される。一方、ホテル受付カウンターの作業が簡略化されるので、チェックインの処理速度が加速され、これにより、ユーザ体験を改善するという目標が達成される。
例示された実施形態において、第1の管理サブシステム103は、ホテル予約サブシステム101によって送信される第1の通知を受信し、第1の通知に含まれるユーザの識別情報に基づいて、ユーザのサードパーティアカウントのクレジットスコアを取得し、事前設定された最小クレジットスコア閾値をクレジットスコアが満たしている場合、ホテルクレジット資格の確認によってユーザが承認を受けていると判定し、指定されたホテル客室タイプの第2の予約(第2の予約は、第1の予約のリソース移動を管理するために第1の管理サブシステム103によって認証情報として用いられる)をユーザのために生成し、ユーザのホテルクレジット資格の確認結果をホテル予約サブシステム101に返信し、ホテルによって送信される、第1の予約のリソースを移動するための第2の通知を受信し、第2の通知に基づいて、第1の予約と関連付けられた第2の予約を取得し、第2の予約のリソースを移動するための第3の通知をサードパーティサブシステム105に送信する。
第1の管理サブシステム103は概して、OTAウェブサイトのサーバに配置される。しかしながら、他の実施形態において、第1の管理サブシステム103はOTAウェブサイトのサーバに配置されることに限定されるものではなく、本明細書で説明される第1の管理サブシステム103を実行できる任意のデバイスが用いられてよい。
ユーザの識別情報とは、ユーザの身元を一意に識別するのに用いられ得る識別情報を意味する。ユーザの識別情報は、限定されるものではないが、携帯電話番号、身分証明書番号、及び銀行預金口座などのユーザ情報を含む。
第1の管理サブシステム103は、ユーザのホテルクレジット資格の確認及び第2の予約の管理などの機能を実装する。本システムでは、ユーザのサードパーティアカウント(例えば、Alipayなどのサードパーティ支払いアカウント)のクレジットスコアに基づいてユーザのホテルクレジット資格を確認することに重点が置かれ、事前設定された最小クレジットスコア閾値をクレジットスコアが満たしている場合、ホテルクレジット資格の確認によってユーザが承認されていると判定する。その間に、第2の予約が生成される必要がある。
第2の予約は、第1の管理サブシステムが第1の予約のリソース移動を管理するための認証情報として用いられる。すなわち、第1の管理サブシステム103が、ホテルによって送信される、第1の予約のリソースを移動するための通知を受信した後に、第1の管理サブシステム103は、リソースを第2の予約に移動するようサードパーティサブシステムに通知する。
このシステムは、ユーザのサードパーティアカウントのリソース移動(支払い又は担保など)を第1の管理サブシステム103を介して管理し且つ制御し、これにより、第1の予約(ホテル予約)の自動リソース移動機能が実現され得ることに留意されたい。すなわち、ユーザのホテルクレジット資格を確認することは、ユーザのサードパーティアカウントのホテルクレジット資格を確認することを意味する。
サードパーティアカウントのクレジットスコアは概して、過去の消費行動などのユーザ情報に基づいて、サードパーティクレジットプラットフォームによってユーザ(サードパーティアカウント)に与えられる一定のクレジット限度額である。リソースが移動される前に、ユーザはクレジット限度額の範囲内で先にお金を使うことができる。これは、サードパーティプラットフォーム(例えば、サードパーティ支払いプラットフォーム)がユーザに保証を与え、ユーザの消費が確実に限度額に収まるようにすることも意味する。
サードパーティアカウントのクレジットスコアは、クレジットスコアに影響を与えるユーザの個人情報に基づいて、サードパーティクレジットプラットフォームによって生成される。クレジットスコアに影響を与える個人情報は、限定されるものではないが、クレジット履歴、消費嗜好、期限内支払い能力、身元、及び人間関係といった個人情報のうち少なくとも1つを含む。
サードパーティクレジットプラットフォームは、多数のデータ点に基づいて個人のクレジットスコアを分析し且つ評価してよく、より高く評価されたスコアがより高いクレジットレベルを意味する。クレジットスコアは、個人のユーザ情報を処理し且つ計算した後に取得される。
1つの実施形態において、第1の管理サブシステム103はさらに、ユーザのサードパーティアカウントのクレジットスコアを取得する前に、ユーザのサードパーティアカウントを取得する必要がある。ユーザのサードパーティアカウントは、以下の2つの方式で取得されてよい。1)第1の管理サブシステム103は、サードパーティプラットフォームの事前設定されたユーザログインページをユーザのクライアントデバイスに転送し、ユーザは自分のサードパーティアカウントをログインページに入力する。こうして、第1の管理サブシステム103はサードパーティアカウントを間接的に取得することができる。2)第1の管理サブシステム103はデータベースに直接照会して、ユーザの識別情報に基づいてユーザのサードパーティアカウントを取得する。ユーザのサードパーティアカウントを取得した後に、第1の管理サブシステム103はさらに、サードパーティアカウントのクレジットスコアを取得し、その後に、ホテルクレジット資格を確認する次の段階が続く。
ユーザのサードパーティアカウントのクレジットスコアを取得する段階は、以下の2つの方法で実施されてよい。1)サードパーティプラットフォーム(例えば、Alipayなどのサードパーティ支払いプラットフォーム)を利用したクレジットスコアの取得、及び2)サードパーティクレジットプラットフォームを利用したクレジットスコアの取得である。クレジットスコアを取得するこれらの2つの方法は、以下でより詳細に説明される。
1)サードパーティプラットフォームを利用したクレジットスコアの取得
サードパーティプラットフォームを利用してクレジットスコアを取得する段階は、以下の段階を含んでよい。すなわち、1.1)ユーザのサードパーティアカウントのクレジットスコア照会リクエストをサードパーティサブシステム105に送信する段階と、1.2)サードパーティサブシステム105によって返信されるユーザのサードパーティアカウントのクレジットスコアを受信する段階とである。
それに応じて、サードパーティサブシステム105はさらに、第1の管理サブシステム103によって送信されるクレジットスコア照会リクエストを受信し、最初のクレジットスコア照会リクエストに従ってユーザのサードパーティアカウントのクレジットスコアを取得し、ユーザのサードパーティアカウントのクレジットスコアを第1の管理サブシステム103に返信するように構成される。
2)サードパーティクレジットプラットフォームを利用したクレジットスコアの取得
サードパーティクレジットプラットフォームを用いてクレジットスコアを取得する場合、本システムはさらにクレジット評価サブシステムを含み、クレジット評価サブシステムはサードパーティクレジットプラットフォームで動作する。クレジット評価サブシステムは、第1の管理サブシステム103によって送信されるクレジットスコア照会リクエストを受信し、事前生成されたクレジットデータベースにユーザのサードパーティアカウントのクレジットスコアを照会し、照会されたユーザのサードパーティアカウントのクレジットスコアを第1の管理サブシステム103に返信するように構成される。
サードパーティクレジットプラットフォームを利用してクレジットスコアを取得する第1の管理サブシステム103は、以下の段階を含んでよい。すなわち、2.1)ユーザのサードパーティアカウントのクレジットスコア照会リクエストをクレジット評価サブシステムに送信する段階と、2.2)クレジット評価サブシステムによって返信されたユーザのサードパーティアカウントのクレジットスコアを受信する段階とである。
事前設定される最小クレジットスコア閾値は、履歴に基づいて決定されても、指定された客室タイプの料金に基づいて決定されてもよい。例えば、最小クレジットスコア閾値は、総合スコアとして設定されてよい。クレジットスコアが総合スコアより高い場合、ユーザは、保証金不要の予約、支払い前のチェックインなどのクレジットサービスを享受することができる。予約された客室タイプの料金が高い場合、最小クレジットスコア閾値は、リクエストされた具体的な客室の料金に基づいて設定されてよい。
第2の予約は、第1の管理サブシステム103が設けられている機関(例えば、OTAウェブサイト)のサーバに格納される。第2の予約は、ユーザのサードパーティアカウントの情報、及び第1の予約と関連付けられた予約番号などの情報を含む。ホテルによって送信される第1の予約のリソース移動通知を受信した後に、第1の管理サブシステム103は、第1の予約と関連付けられた第2の予約に従って、ホテルで実際に消費したリソース(滞在の支払いなど)を第2の予約と関連付けられたサードパーティアカウントから移動することをサードパーティサブシステム105に通知する。
ユーザが関連のないサードパーティアカウントを用いて第1の予約のリソースを移動するのを防ぐために、1つの実施形態では、第1の管理サブシステム103はさらに、サードパーティアカウントと関係があるサードパーティプラットフォームのパスワード確認ページをユーザのクライアントデバイスに転送するように構成される。サードパーティプラットフォームは、ユーザによって提供されるサードパーティアカウントのパスワードに基づいて、サードパーティアカウントのパスワードを確認し、サードパーティプラットフォームによって返信されるサードパーティアカウントのパスワードの確認結果を受信する。確認結果が合格である場合、ユーザがホテルクレジット資格の確認によって承認されていると判定する。ユーザがホテルクレジット資格の確認によって承認されていると判定された場合にだけ、第2の予約は生成される。確認結果が不合格である場合、ユーザがホテルクレジット資格の確認によって承認されていないと判定される。ユーザのホテルクレジット資格の確認結果は、その後、ホテル予約サブシステム101に返信される。サードパーティアカウントのパスワードは、上記処理を用いて確認されてよく、これにより、サードパーティアカウントを用いることの安全性が保証される。
さらに、ユーザとサードパーティプラットフォームとの間の争いを回避するために、サードパーティプラットフォームは、サードパーティプラットフォームがサードパーティアカウントからリソースを自動的に引き落としてよいことを、ユーザがはっきりと確実に理解するように努めなければならない。したがって、サードパーティプラットフォームは、自動リソース引き落としの承認をユーザから前もって取得する必要がある。したがって、いくつかの実施形態では、第1の管理サブシステム103はさらに、サードパーティアカウントの予約処理権限照会リクエストをサードパーティサブシステム105に送信し、サードパーティサブシステム105によって返信されるサードパーティアカウントの予約処理権限を受信し、予約処理権限が許可されている場合、ホテルクレジット資格の確認によってユーザが承認されていると判定するように構成される。同様に、ユーザがホテルクレジット資格の確認によって承認されていると判定された場合にだけ、第2の予約は生成される。予約処理権限が禁止されている場合、ユーザがホテルクレジット資格の確認によって承認されていないと判定され、ユーザのホテルクレジット資格の確認結果はホテル予約サブシステム101に返信される。
予約処理権限とは、サードパーティプラットフォームがサードパーティアカウントからリソースを自動的に引き落とすことを許可されるかどうかに関して、ユーザによって明確に設定される権限を意味する。
これに応じて、サードパーティサブシステム105はさらに、第1の管理サブシステム103によって送信される予約処理権限照会リクエストを受信し、予約処理権限照会リクエストに基づいてサードパーティアカウントの予約処理権限を取得し、サードパーティアカウントの予約処理権限を第1の管理サブシステム103に返信するように構成される。
1つの実施形態において、ユーザがホテルクレジットサービスの新規ユーザである場合、サードパーティアカウントの予約処理権限は、通常、まだ設けられていない。この場合、第1の管理サブシステム103はさらに、サードパーティプラットフォームの予約処理権限設定ページをユーザのクライアントデバイスに転送し、サードパーティプラットフォームによって返信されるサードパーティアカウントの承認結果を受信し、承認結果が合格である場合、ホテルクレジット資格の確認によってユーザが承認されていると判定するように構成される。承認結果が不合格である場合、ユーザがホテルクレジット資格の確認によって承認されていないと判定され、ユーザのホテルクレジット資格の確認結果はホテル予約サブシステム101に返信される。
サードパーティサブシステム105は、第1の管理サブシステム103によって送信される第3の通知を受信し、第3の通知に基づいてサードパーティアカウントからリソースを引き落とし、引き落とされたリソースをホテルのサードパーティアカウントに移動するように構成される。
サードパーティサブシステム105は概して、サードパーティプラットフォームのサーバに配置される。しかしながら、サードパーティサブシステム105はこのサーバに配置されることに限定されるものではなく、本明細書で説明されるサードパーティサブシステム105を実行できる任意のデバイスが用いられてよい。
1つの実施形態において、サードパーティサブシステム105によって返信されたリソース移動成功メッセージを受信した後に、第1の管理サブシステム103はさらに、第2の予約の状態を完了状態に更新する必要がある。第1の管理サブシステム103は次に、第1の予約のリソースの移動が成功したという通知をホテル予約サブシステム101に送信する。
この実施形態において、このシステムはさらにホテル管理サブシステムを含む。ホテル管理サブシステムは、ホテル予約サブシステム101によって生成された第1の予約(第1の予約は認証情報としてユーザのチェックインに用いられる)を受信し、ホテルのクライアントデバイスによって送信される第1の予約のリソース移動リクエストを受信し、リソース移動リクエストに含まれるリソース移動情報に基づいてリソース移動通知を第1の管理サブシステム103に送信するように構成される。
ホテルのクライアントデバイスは、ホテル受付カウンターにあるパーソナルコンピュータに配置されてよく、ネットワーク(例えば、ローカルエリアネットワーク又はワイドエリアネットワーク)を通じてホテル管理サブシステムに接続されてよい。ユーザがホテル滞在を終えたときにホテル受付カウンターでチェックアウトする場合、ホテルの受付係はホテルのクライアントデバイスを備えたパーソナルコンピュータを用いてユーザの支払いを処理する。ホテルのクライアントデバイスは、ユーザの第1の予約に対応するリソース移動リクエストをホテル管理サブシステムに送信する。ホテル管理サブシステムは、リソース移動リクエストに含まれるリソース移動情報(この情報は、第1の予約の番号、実際の消費額などを含み得る)に基づいて、リソース移動通知を第1の管理サブシステム103に送信する。リソース移動通知を受信した後に、第1の管理サブシステム103は、第1の予約と関連付けられた第2の予約を取得し、その後、第2の予約のリソースをサードパーティサブシステム105に移動するための通知を送信する。第1の管理サブシステム103によって送信される通知を受信した後に、サードパーティサブシステム105は、この通知に基づいてサードパーティアカウントからリソースを引き落とし、引き落とされたリソースをホテルのサードパーティアカウントに移動する。
別の実施形態において、ホテル管理サブシステムはさらに、ホテルのクライアントデバイスによって送信される第1の予約のチェックインリクエストを受信し、第1の予約の予約状態をチェックイン状態に更新するように構成される。第1の予約の予約状態をチェックイン状態に更新した後に、ホテル管理サブシステムはさらに、第1の予約のユーザがチェックインしたという通知を第1の管理サブシステム103に送信してよい。第1の管理サブシステム103は、この通知に基づいて、第2の予約の予約状態をチェックイン状態に更新する。したがって、第1の予約及び第2の予約の予約状態が互いに確実に一致するようになり、その結果、第1の管理サブシステム103による予約の管理が容易になる。
サードパーティアカウントのクレジットスコアは、サードパーティクレジットプラットフォームによってユーザに与えられる一定のクレジット限度額である。リソースが移動される前に、ユーザはクレジット限度額の範囲内で先にお金を使うことができる。第1の予約が生成された後には、確かに、ある程度のクレジットが利用されている。この実施形態は解決手段を示す。ここで、クレジット評価サブシステムはさらに、第2の予約が生成された後に、指定された客室タイプの料金に基づき、それに応じたサードパーティアカウントのクレジットスコアを差し引き、第2の予約の完了に成功した後に、指定された客室タイプの料金に基づき、それに応じたサードパーティアカウントのクレジットスコアを元に戻すように構成される。上記処理で、ユーザの消費が確実に限度額に収まるようになる。
上記実施形態において提供されるホテル情報処理システムでは、ホテルの公式ウェブサイトの一部として配置されたホテル予約サブシステム101が、ホテル客室タイプの予約をユーザのために生成する前に、第1の管理サブシステム103を介してユーザのサードパーティアカウントのホテルクレジット資格を確認する。ホテル予約サブシステム101は、ユーザのサードパーティアカウントがホテルクレジット資格の確認に合格した場合にだけ、予約を生成する。さらに、ユーザがホテルをチェックアウトした後に、ユーザのサードパーティアカウントからリソースを引き落とすことをサードパーティサブシステム105に通知する第1の管理サブシステム103によって、予約のリソース引き落としが実施される。このように、ユーザが、予約したホテル客室の保証金を前払いする必要はない。したがって、本開示において提供されるホテル情報処理システムは、ユーザのホテル滞在体験を効果的に改善することができ、これにより、ホテルの市場競争力が改善される。
ホテル情報処理システムが上記実施形態において提供される。これに応じて、開示された実施形態はさらにホテル予約方法を提供する。この方法は、上記システムのホテル予約サブシステムで実行される。本方法は、上記システムのホテル予約サブシステムの実施形態に対応する。
図2は、本開示のいくつかの実施形態によるホテル予約方法を例示するフロー図である。図2に開示する実施形態は、図1に関連して論じられたシステムの実施形態に関連して説明された段階に類似している。したがって、図2の説明は、図1に関連して開示された全ての実施形態を繰り返すことはせず、また図1に関連して提供された関係のある説明を参照することができる。
図2に例示するホテル予約方法は以下の段階を含む。
段階S101:ユーザのクライアントデバイスによって送信される指定された客室タイプの予約リクエストを受信する。
段階S103:予約リクエストに基づいて、ユーザのホテルクレジット資格を確認するための通知を事前設定された管理サーバに送信する。この通知はユーザの識別情報を含む。
段階S105:管理サーバによって返信されるユーザのホテルクレジット資格の確認結果を受信する。
段階S107:ホテルクレジット資格の確認結果が合格である場合、予約リクエストに基づいて、指定された客室タイプの予約をユーザのために生成する。
ホテル予約方法が上記実施形態において提供される。これに応じて、本開示はさらにホテル予約装置を提供する。1つの実施形態において、本装置は、図2に関連して説明されたオペレーションを行う。
図3は、本開示のいくつかの実施形態によるホテル予約装置を例示するブロック図である。図3の実施形態は、図2に関連して説明された方法に類似したオペレーションを行う。したがって、図3の説明は比較的簡潔である。図2に関連して提供された説明を参照することによって、図3の関連部分を参照することができる。
図3に例示するホテル予約装置が以下のユニットを含む。
ユーザのクライアントデバイスによって送信される指定された客室タイプの予約リクエストを受信するように構成された、予約リクエスト受信ユニット301。
予約リクエストに基づいて、ユーザのホテルクレジット資格を確認するための通知を事前設定された管理サーバに送信するように構成された、確認通知送信ユニット303。この通知はユーザの識別情報を含む。
管理サーバによって返信されるユーザのホテルクレジット資格の確認結果を受信するように構成された、確認結果受信ユニット305。
ホテルクレジット資格の確認結果が合格である場合、予約リクエストに基づいて、指定された客室タイプの予約をユーザのために生成するように構成された、合格確認処理ユニット307。
図4は、本開示のいくつかの実施形態による電子デバイスを例示するブロック図である。図4に図示する電子デバイスによって行われる処理は、図2に関連して論じられた方法の実施形態に類似しており、したがって、この説明は比較的簡潔である。図2に関連して説明された各段階の説明を参照することによって、図4に例示するデバイスの関連部分を参照することができる。
電子デバイスが、図4に例示する実施形態において提供される。電子デバイスは、表示装置401と、プロセッサ402と、メモリ403とを含む。メモリ403は、ホテル予約方法を実現するためのプログラムを格納するように構成され、本デバイスが電源を投入されて、プロセッサ402を介してホテル予約方法のプログラムを動作させた後に、以下の段階が実行される。すなわち、ユーザのクライアントデバイスによって送信される指定された客室タイプの予約リクエストを受信する段階と、予約リクエストに基づいて、ユーザのホテルクレジット資格を確認するための通知を管理サーバに送信する段階であって、この通知はユーザの識別情報を含む、段階と、管理サーバによって返信されるユーザのホテルクレジット資格の確認結果を受信する段階と、ホテルクレジット資格の確認結果が合格である場合、予約リクエストに基づいて、指定された客室タイプの予約をユーザのために生成する段階とである。
上記のホテル情報処理システムに従って、本開示はさらに予約管理方法を提供する。この方法は、上記システムの第1の管理サブシステムで実行される。
図5は、本開示のいくつかの実施形態による予約管理方法を例示するフロー図である。図5に例示する実施形態は、図2に関連して論じられた段階と類似の段階を含むので、それらの開示をここで繰り返すことはしない。図2に例示する実施形態の対応する部分を参照することによって参照が行われてよい。図5に提供される予約管理方法は以下の段階を含む。
段階S501:ホテル予約サーバによって送信される、予約を入れたユーザのホテルクレジット資格を確認するための通知を受信する。
1つの実施形態において、ホテル予約サーバによって送信される、予約を入れたユーザのホテルクレジット資格を確認するための通知を受信する段階の後に、本方法はさらに、通知に含まれる指定された客室タイプの料金に基づいて最小クレジットスコア閾値を設定する段階を含む。
段階S503:通知に含まれるユーザの識別情報に基づいて、予約を入れたユーザのサードパーティアカウントのクレジットスコアを取得する。
1つの実施形態において、この段階は以下の小段階を含んでよい。すなわち、1)サードパーティアカウントのクレジットスコア照会リクエストをサードパーティプラットフォームに送信する段階と、2)サードパーティプラットフォームによって返信されるサードパーティアカウントのクレジットスコアを受信する段階とである。
段階S505:事前設定された最小クレジットスコア閾値をクレジットスコアが満たしている場合、予約を入れたユーザがホテルクレジット資格の確認によって承認されていると判定し、予約を入れたユーザのために指定されたホテル客室タイプの予約を生成する段階。
1つの実施形態において、予約を入れたユーザのために指定されたホテル客室タイプの予約を生成する段階の前に、本方法はさらに、1)予約を入れたユーザのクライアントデバイスにサードパーティプラットフォームのパスワード確認ページを転送する段階であって、サードパーティプラットフォームは、予約を入れたユーザによって提供されるサードパーティアカウントのパスワードに基づいて、サードパーティアカウントのパスワードを確認する、段階と、2)サードパーティプラットフォームによって返信されるサードパーティアカウントのパスワードの確認結果を受信する段階と、3)確認結果が不合格である場合、予約を入れたユーザがホテルクレジット資格の確認によって承認されていないと判定する段階とを含む。
1つの実施形態において、予約を入れたユーザのために指定されたホテル客室タイプの予約を生成する段階の前に、本方法はさらに、1)サードパーティアカウントの予約処理権限照会リクエストをサードパーティプラットフォームに送信する段階と、2)サードパーティプラットフォームによって返信されるサードパーティアカウントの予約処理権限を受信する段階と、3)予約処理権限が禁止されている場合、予約を入れたユーザがホテルクレジット資格の確認によって承認されていないと判定する段階とを含む。
1つの実施形態において、本方法はさらに、1)予約処理権限が設けられていない場合、予約を入れたユーザのクライアントデバイスにサードパーティプラットフォームの予約処理権限設定ページを転送し、サードパーティプラットフォームによって返信されるサードパーティアカウントの承認結果を受信する段階と、2)承認結果が不合格である場合、予約を入れたユーザがホテルクレジット資格の確認によって承認されていないと判定する段階とを含む。
段階S507:予約を入れたユーザのホテルクレジット資格の確認結果をホテル予約サーバに返信する。
1つの実施形態において、予約を入れたユーザのために指定されたホテル客室タイプの予約を生成する段階の後に、本方法はさらに、通知に含まれる指定された客室タイプの料金に基づいて、対応する差し引きをサードパーティアカウントのクレジットスコアに対して行う段階を含む。これに応じて、予約の完了に成功した後に、本方法はさらに、指定された客室タイプの料金に基づいて、それに応じたサードパーティアカウントのクレジットスコアを元に戻す段階を含む。
1つの実施形態において、本方法はさらに、1)ホテル予約サーバによって送信される、予約と関連付けられたホテル予約のリソース移動通知を受信する段階と、2)リソース移動通知及び予約に基づいて、リソースをサードパーティアカウントからホテルに移動する段階とを含む。1つの実施形態において、移動に成功した場合、移動成功メッセージがホテル予約サーバに送信される。
予約管理方法が上記実施形態において提供される。それに応じて、本開示はさらに予約管理装置を提供する。本装置は、上述した方法の実施形態の実施形態に対応する。
図6は、本開示のいくつかの実施形態による予約管理装置を例示するブロック図である。図6における装置の実施形態は、図5及び他の図に関連して説明された方法の実施形態に実質的に類似している。したがって、この説明は比較的簡潔である。図5で説明された方法の実施形態の一部の説明を参照することによって、関連部分を参照することができる。
図6に例示する予約管理装置が以下のユニットを含む。
ホテル予約サーバによって送信される、予約を入れたユーザのホテルクレジット資格を確認するための通知を受信するように構成された、確認通知受信ユニット601。
通知に含まれるユーザの識別情報に基づいて、予約を入れたユーザのサードパーティアカウントのクレジットスコアを取得するように構成された、クレジットスコア取得ユニット603。
事前設定された最小クレジットスコア閾値をクレジットスコアが満たしている場合、予約を入れたユーザがホテルクレジット資格の確認によって承認されていると判定し、予約を入れたユーザのために指定されたホテル客室タイプの予約を生成するように構成された、合格確認処理ユニット605。
予約を入れたユーザのホテルクレジット資格の確認結果をホテル予約サーバに返信するように構成された、確認結果返信ユニット607。
図7は、本開示のいくつかの実施形態による電子デバイスを例示するブロック図である。デバイスの実施形態は、方法の実施形態と実質的に類似している。したがって、この説明は比較的簡潔である。方法の実施形態の一部の説明を参照することによって、関連部分を参照することができる。以下に説明されるデバイスの実施形態は、単なる例示である。
電子デバイスが、この実施形態において提供される。この電子デバイスは、表示装置701と、プロセッサ702と、メモリ703とを含む。メモリ703は、予約管理方法を実施するためのプログラムを格納するように構成され、本デバイスが電源を投入されて、プロセッサ702を介して予約管理方法のプログラムを実行した後に、以下の段階が実行される。すなわち、ホテル予約サーバによって送信される、予約を入れたユーザのホテルクレジット資格の確認に関する通知を受信する段階と、この通知に含まれる、予約を入れたユーザの識別情報に基づいて、予約を入れたユーザのサードパーティアカウントのクレジットスコアを取得する段階と、事前設定された最小クレジットスコア閾値をクレジットスコアが満たしている場合、予約を入れたユーザがホテルクレジット資格の確認によって承認されていると判定する段階と、予約を入れたユーザのために指定されたホテル客室タイプの予約を生成する段階と、予約を入れたユーザのホテルクレジット資格の確認結果をホテル予約サーバに返信する段階とである。
ホテル情報処理システムが上記実施形態において提供される。それに応じて、本開示はさらに、以下で説明するような第2のホテル情報処理システムを提供する。
図8は、本開示のいくつかの実施形態によるホテル情報処理システムを例示するブロック図である。図1及び図8に例示する2つのホテル情報処理システムの実施形態は類似しているので、ここでの説明は比較的簡潔である。図1に関連して前述したシステムの実施形態の一部の説明を参照することによって、関連部分を参照することができる。
この実施形態の第2のホテル情報処理システムは、ホテル予約サブシステム801と第1の管理サブシステム803とを含む。
ホテル予約サブシステム801は、ユーザのクライアントデバイスによって送信される指定された客室タイプの予約リクエストを受信し、予約リクエストに基づいて、ユーザのホテルクレジット資格を確認するための通知を第1の管理サブシステム803に送信し、第1の管理サブシステム803によって返信されるユーザのホテルクレジット資格の確認結果を受信し、ホテルクレジット資格の確認結果が合格である場合、予約リクエストに基づいて、指定された客室タイプの第1の予約をユーザのために生成するように構成される。
第1の管理サブシステム803は、ホテル予約サブシステム801によって送信される通知を受信し、通知に含まれるユーザの識別情報に基づいて、ユーザのサードパーティアカウントのクレジットスコアを取得し、事前設定された最小クレジットスコア閾値をクレジットスコアが満たしている場合、ホテルクレジット資格の確認によってユーザが承認を受けていると判定し、指定されたホテル客室タイプの第2の予約(第2の予約は、第1の予約のリソース移動を管理するために第1の管理サブシステム803によって認証情報として用いられる)をユーザのために生成し、ユーザのホテルクレジット資格の確認結果をホテル予約サブシステム801に返信するように構成される。
図8において提供されるホテル情報処理システムと図1において提供されるホテル情報処理システムとの間の差は、以下の点にある。すなわち、図8のシステムでは、第1の管理サブシステム803の機能に重点が置かれ、この機能は、ユーザのホテルクレジット資格を確認すると共に第1の予約及び第2の予約を生成する処理に集中するためのものであり、リソース移動の処理を規定するためのものではない。
図8において提供されるホテル情報処理システムを用いると、ユーザの消費行動に対するクレジット保証がユーザのサードパーティアカウントを介して与えられ、これにより、ユーザの消費行動が確実に限度額に収まることになる。ユーザのサードパーティアカウントがホテルクレジット資格の要件を満たしている場合、ユーザは、保証金を前払いする必要もなく、ホテル予約、チェックイン、及び支払いを直接行うことができる。したがって、ユーザのホテル滞在体験が効果的に改善され得る。
ホテル情報処理システムが上記実施形態において提供される。それに応じて、本開示はさらに、図9において第3のホテル情報処理システムを提供する。
図9は、本開示のいくつかの実施形態によるホテル情報処理システムを例示するブロック図である。これらのシステムの実施形態は類似しているので、ここでの説明は比較的簡潔である。上記のシステムの実施形態の一部の説明を参照することによって、関連部分を参照することができる。
図9に例示するホテル情報処理システムは、ホテル予約サブシステム901と、ホテル管理サブシステム903と、サードパーティサブシステム905とを含む。
ホテル予約サブシステム901は、ユーザのクライアントデバイスによって送信される指定されたホテル及び指定された客室タイプの予約リクエストを受信し、予約リクエストに含まれるユーザの識別情報に基づいて、ユーザのサードパーティアカウントのクレジットスコアを取得し、事前設定された最小クレジットスコア閾値をクレジットスコアが満たしている場合、指定されたホテルの指定された客室タイプの第1の予約をユーザのために生成し、第1の予約(第1の予約は、第2の予約のリソース移動を管理するための認証情報として、ホテル予約サブシステム901によって用いられる)に従って生成される第2の予約の第1の通知をホテル管理サブシステム903に送信し、ホテル管理サブシステム903によって送信される、第2の予約のリソース移動に関する第2の通知を受信し、第2の通知に基づいて、第1の予約のリソースを移動するための第3の通知をサードパーティサブシステムに送信するように構成される。
図9に例示するホテル情報処理システムと図1に図示するホテル情報処理システムとの間の差は、以下の点にある。すなわち、第1のシステムでは、ホテルの公式ウェブサイトによってオンラインホテル予約機能が提供されるのに対して、第3のシステムでは、サードパーティのウェブサイト(例えば、OTAウェブサイト)によってオンラインホテル予約機能が提供される。
1つの実施形態において、ユーザのクライアントデバイスは、スマートフォンなどの移動通信デバイスを含み、また、パーソナルコンピュータ、PDA、又はタブレット(例えば、iPad(登録商標))などの端末デバイスを含んでもよい。
ホテル予約サブシステム901は、オンラインホテル予約機能を実装し、概して、OTAウェブサイトのサーバに配置される。しかしながら、ホテル予約サブシステム901はOTAウェブサイトのサーバに配置されることに限定されるものではなく、本明細書で説明されるホテル予約サブシステム901を実行できる任意のデバイスが用いられてよい。
図9に例示するホテル情報処理システムと図1のホテル情報処理システムとの間の別の差は、以下の点にある。すなわち、第1の予約を生成した後に、システムのホテル予約サブシステム901は、第1の予約に対応する第2の予約の生成に関する第1の通知をホテル管理サブシステム903に送信する必要がある。これにより、ホテルは予約を入れたユーザのチェックイン及び支払いを第2の予約に従って処理しやすくなる。第3のシステムの第2の予約は第1のシステムの第1の予約と同じであり、これらの予約は両方ともホテル予約サーバに格納され、ホテル予約とも呼ばれる。同様に、第3のシステムの第1の予約は、図1に例示するシステムの第2の予約と同じである。
ホテル管理サブシステム903は、ホテル予約サブシステム901によって送信される第1の通知を受信し、第1の通知に基づいて第2の予約(第2の予約は認証情報としてユーザのチェックインに用いられる)を生成し、指定されたホテルのクライアントデバイスによって送信される第2の予約のリソース移動リクエストを受信し、リソース移動リクエストに含まれるリソース移動情報に基づいて第2の通知をホテル予約サブシステム901に送信するように構成される。
ホテル管理サブシステム903は概して、ホテルのサーバに配置される。しかしながら、ホテル管理サブシステム903はこのサーバにだけ配置されることに限定されるものではなく、本明細書で説明される第1の管理サブシステム903を実行できる任意のデバイスが用いられてよい。
サードパーティサブシステム905は、ホテル予約サブシステム901によって送信される第3の通知を受信し、第3の通知に基づいてサードパーティアカウントからリソースを引き落とし、引き落とされた第2の予約のリソースを指定されたホテルのサードパーティアカウントに移動するように構成される。
図9に関連して説明された上記実施形態において、代替のホテル情報処理システムが提供される。それに応じて、本開示はさらに、別のホテル予約方法を提供する。この方法は、図9に関連して説明されたホテル情報処理システムのホテル予約サブシステム901で実行される。
図10は、本開示のいくつかの実施形態によるホテル予約方法を例示するフロー図である。この方法の実施形態は、図9に関連して論じられたシステムの実施形態に実質的に類似している。したがって、説明は比較的簡潔である。図9のシステムの実施形態の一部の説明を参照することによって、関連部分を参照することができる。
代替のホテル予約方法が以下の段階を含む。
段階S1001:ユーザのクライアントデバイスによって送信される指定されたホテル及び指定された客室タイプの予約リクエストを受信する。
段階S1003:予約リクエストに含まれるユーザの識別情報に基づいて、ユーザのサードパーティアカウントのクレジットスコアを取得する。
段階S1005:事前設定された最小クレジットスコア閾値をクレジットスコアが満たしている場合、指定されたホテルの指定された客室タイプの予約をユーザのために生成し、予約に従って生成されたホテル予約の通知を指定されたホテル予約サーバに送信する。
1つの実施形態において、本方法はさらに以下の段階を含む。すなわち、1)指定されたホテルのサーバによって送信されるホテル予約のリソース移動通知を受信する段階と、2)リソース移動通知及び予約に基づいて、リソースをサードパーティアカウントから指定されたホテルに移動する段階とである。
代替のホテル予約方法が上記実施形態において提供される。それに応じて、本開示はさらに、別のホテル予約装置を提供する。本装置は、上記の方法の実施形態の実施形態に対応する。
図11は、本開示のいくつかの実施形態によるホテル予約装置を例示するブロック図である。この装置の実施形態は、図10に関連して説明された方法の実施形態に実質的に類似している。したがって、説明は比較的簡潔である。図10に関連して説明された方法の実施形態の一部の説明を参照することによって、関連部分を参照することができる。
図11に例示する代替のホテル予約装置が以下のユニットを含む。
ユーザのクライアントデバイスによって送信される指定されたホテル及び指定された客室タイプの予約リクエストを受信するように構成された、予約リクエスト受信ユニット1101。
予約リクエストに含まれるユーザの識別情報に基づいて、ユーザのサードパーティアカウントのクレジットスコアを取得するように構成された、クレジットスコア取得ユニット1103。
事前設定された最小クレジットスコア閾値をクレジットスコアが満たしている場合、指定されたホテルの指定された客室タイプの予約をユーザのために生成し、予約に従って生成されたホテル予約の通知を指定されたホテル予約サーバに送信するように構成された、合格確認処理ユニット1105。
図12は、本開示のいくつかの実施形態による電子デバイスを例示するブロック図である。図12のデバイスの実施形態は、図10に関連して論じられた方法の実施形態に実質的に類似したオペレーションを行う。したがって、説明は比較的簡潔である。図10に関連して説明された方法の実施形態の説明を参照することによって、関連部分を参照することができる。
電子デバイスが図12において提供される。この電子デバイスは、表示装置1201と、プロセッサ1202と、メモリ1203とを含む。メモリ1203は、ホテル予約処理を実施するためのプログラムを格納するように構成され、本デバイスが電源を投入されて、プロセッサ1202を介してホテル予約方法のプログラムを実行した後に、以下の段階が実行される。すなわち、ユーザのクライアントデバイスによって送信される指定されたホテル及び指定された客室タイプの予約リクエストを受信する段階と、予約リクエストに含まれるユーザの識別情報に基づいて、ユーザのサードパーティアカウントのクレジットスコアを取得する段階と、事前設定された最小クレジットスコア閾値をクレジットスコアが満たしている場合、指定されたホテルの指定された客室タイプの予約を生成する段階と、予約に従って生成されたホテル予約の通知を指定されたホテル予約サーバに送信する段階とである。
図9に関連して論じられたホテル情報処理システムに従って、本開示はさらに予約生成方法を提供する。この方法は、図9に関連して論じられたホテル情報処理システムのホテル管理サブシステム903で実行される。
図13は、本開示のいくつかの実施形態による予約生成方法を例示するフロー図である。図13に例示する実施形態における様々な段階の説明は、図2に例示する実施形態のものに類似しているので、それらの開示をここで繰り返すことはしない。図2に関連して説明された実施形態の対応する部分を参照することによって、参照が行われてよい。例示された図13の実施形態において提供される予約生成方法は、以下の段階を含む。
段階S1301:ホテル予約サーバによって送信される、特定の予約に従って生成されるホテル予約の通知を受信する。この通知は、予約を入れたユーザの識別情報と予約された客室タイプに関する情報とを含む。
段階S1303:通知に基づいてホテル予約を生成する。
1つの実施形態において、例示された方法はさらに以下の段階を含む。すなわち、1)ホテルのクライアントデバイスによって送信されるホテル予約のリソース移動リクエストを受信する段階と、2)リソース移動リクエストに含まれるリソース移動情報に基づいて、ホテル予約のリソース移動に関する通知をホテル予約サーバに送信する段階とである。
予約生成方法が上記実施形態において提供される。それに応じて、本開示はさらに、図13に例示する方法の実施形態の実施形態に対応する予約生成装置を提供する。
図14は、本開示のいくつかの実施形態による予約生成装置を例示するブロック図である。図14に例示する実施形態は、図13に関連して説明された方法の実施形態に類似したオペレーションを行う。したがって、説明は比較的簡潔である。図13の方法の実施形態の説明を参照することによって、関連部分を参照することができる。
図14の予約生成装置は以下のユニットを含む。
ホテル予約サーバによって送信される、特定の予約に従って生成されるホテル予約の通知を受信するように構成された、予約生成通知受信ユニット1401。この通知は、予約を入れたユーザの識別情報と予約された客室タイプに関する情報とを含む。
通知に基づいてホテル予約を生成するように構成された、予約生成ユニット1403。
図15は、本開示のいくつかの実施形態による電子デバイスを例示するブロック図である。図15に例示するデバイスの実施形態は、図13に関連して説明された方法の実施形態に類似したオペレーションを行う。したがって、説明は比較的簡潔である。図13に関連して説明された方法の実施形態の説明を参照することによって、関連部分を参照することができる。
図15に例示する実施形態において電子デバイスが提供される。この電子デバイスは、表示装置1501と、プロセッサ1502と、メモリ1503とを含む。メモリ1503は、予約生成方法を実施するためのプログラムを格納するように構成され、本デバイスが電源を投入されて、プロセッサ1502を介して予約生成方法のプログラムを実行した後に、以下の段階が実行される。すなわち、ホテル予約サーバによって送信される、特定の予約に従って生成されるホテル予約の通知を受信する段階であって、この通知は予約を入れたユーザの識別情報と予約された客室タイプに関する情報とを含む、段階と、通知に基づいてホテル予約を生成する段階とである。
図16は、本開示のいくつかの実施形態によるホテル情報処理システムを例示するブロック図である。前述した2つのシステムの実施形態は類似しているので、ここでの説明は比較的簡潔である。前述したシステムの実施形態の一部の説明を参照することによって、関連部分を参照することができる。
図16に例示するホテル情報処理システムは、ホテル予約サブシステム1601とホテル管理サブシステム1603とを含む。
ホテル予約サブシステム1601は、ユーザのクライアントデバイスによって送信される指定されたホテル及び指定された客室タイプの予約リクエストを受信し、予約リクエストに含まれるユーザの識別情報に基づいて、ユーザのサードパーティアカウントのクレジットスコアを取得し、事前設定された最小クレジットスコア閾値をクレジットスコアが満たしている場合、指定されたホテルの指定された客室タイプの第1の予約をユーザのために生成し、第1の予約(第1の予約は、第2の予約のリソース移動を管理するための認証情報として、ホテル予約サブシステム1601によって用いられる)に従って生成される第2の予約の第1の通知をホテル管理サブシステムに送信するように構成される。
ホテル管理サブシステム1603は、ホテル予約サブシステム1601によって送信される通知を受信し、この通知に基づいて第2の予約を生成するように構成され、第2の予約は認証情報としてユーザのチェックインに用いられる。
図16に例示するホテル情報処理システムと図9に例示するホテル情報処理システムとの間の差は、以下の点にある。すなわち、図16のシステムでは、ホテル予約サブシステム1601の機能に重点が置かれ、この機能はユーザのホテルクレジット資格を確認すると共に第1の予約及び第2の予約を生成する処理に集中するためのものであり、リソース移動の処理を規定するためのものではない。
図16において提供されるホテル情報処理システムを用いると、ユーザの消費行動に対するクレジット保証がユーザのサードパーティアカウントを介して与えられ、これにより、ユーザの消費行動が確実に限度額に収まることになる。ユーザのサードパーティアカウントがホテルクレジット資格の要件を満たしている場合、ユーザは、保証金を前払いする必要もなく、ホテル予約、チェックイン、及び支払いを直接行うことができる。したがって、ユーザのホテル滞在体験が効果的に改善され得る。
本開示は、特定の実施形態と共に上記に提供される。しかしながら、これらの実施形態は本開示を限定することを意図していない。当業者であれば、開示された実施形態の主旨及び範囲から逸脱することなく、様々な変形形態及び修正形態を作り出すことができる。したがって、開示された実施形態の範囲は、本開示の請求項により定められる範囲によって決まる。
典型的な構成において、コンピュータ処理装置は、1つ又は複数のプロセッサ(CPU)、入力/出力インタフェース、ネットワークインタフェース、及びメモリを含む。
メモリは、非永続的メモリ、ランダムアクセスメモリ(RAM)、及び/又は、リードオンリメモリ(ROM)若しくはフラッシュメモリ(フラッシュRAM)などの不揮発性メモリなどの形でコンピュータ可読媒体を含んでよい。このメモリはコンピュータ可読媒体の一例である。
コンピュータ可読媒体は、任意の方法又は手法によって情報記憶を実現できる永続的媒体及び非永続的媒体、並びに非固定式媒体及び固定式媒体を含む。情報は、コンピュータ可読命令、データ構造、プログラムモジュール、又は他のデータであってよい。コンピュータの記憶媒体の例には、限定されるものではないが、相変化メモリ(PRAM)、スタティックランダムアクセスメモリ(SRAM)、ダイナミックランダムアクセスメモリ(DRAM)、他のタイプのランダムアクセスメモリ(RAM)、リードオンリメモリ(ROM)、電気的消去可能プログラマブルリードオンリメモリ(EEPROM)、フラッシュメモリ若しくは他のメモリ装置、コンパクトディスクリードオンリメモリ(CD‐ROM)、デジタル多用途ディスク(DVD)若しくは他の光記憶装置、磁気カセット、磁気テープ、磁気ディスク記憶装置若しくは他の磁気記憶装置、又は、コンピュータ処理装置がアクセス可能な情報を格納するのに用いられ得る任意の他の非伝送媒体が含まれる。本明細書の定義を踏まえると、コンピュータ可読媒体は、変調データ信号及び搬送波などの非一時的コンピュータ可読媒体を含まない(一時的媒体である)。
開示された実施形態は、方法、システム、又はコンピュータプログラム製品として提供され得ることを、当業者であれば理解するはずである。したがって、開示された実施形態は、完全なハードウェア実施形態、完全なソフトウェア実施形態、又はソフトウェア構成要素及びハードウェア構成要素を組み合わせた実施形態の形を用いてよい。さらに、開示された実施形態は、コンピュータ利用可能プログラムコードを内部に格納する1つ又は複数のコンピュータ利用可能記憶媒体(限定されるものではないが、磁気ディスクメモリ、CD‐ROM、光メモリなどを含む)で実現されるコンピュータプログラム製品の形を用いてもよい。