JP2019525283A - 異種のコンピュータ処理装置を標準インタフェース及び直接ネットワーク接続を介して接続するためのシステム及び方法 - Google Patents

Abstract

本開示の実施形態が、データオブジェクト情報処理方法、装置、及びシステムを説明する。１つの実施形態において、本方法は、プラットフォームサーバによってホテルデータオブジェクト情報をクライアントデバイスに提供する段階であって、ホテルデータオブジェクト情報は、クレジットタイプ属性などの複数のタイプ属性を含む、段階と、プラットフォームサーバにおいてクライアントデバイスからの予約リクエストを受信する段階であって、予約リクエストはクレジットタイプ属性の識別情報を含む、段階と、予約リクエストに応答して、クライアントデバイスと関連付けられたユーザのクレジット認証をプラットフォームサーバによって確認する段階と、クレジット認証を確認した後に、クレジットタイプ予約をプラットフォームサーバによって作成する段階と、クレジットタイプ予約と関連付けられた予約情報をホテルと関連付けられたホテルデータ処理システムにプラットフォームサーバによって送信する段階と、プラットフォームサーバにおいてホテルデータ処理システムからのチェックアウトリクエストを受信する段階と、チェックアウトリクエストを受信した後に、予約情報と関連付けられたリソースを、ユーザと関連付けられた支払いアカウントからホテルデータ処理システムにプラットフォームサーバによって移動させる段階とを含む。

Description

［関連出願の相互参照］
本出願は、２０１６年７月６日出願の「データオブジェクト情報を処理する方法、装置、及びシステム（Ｍｅｔｈｏｄ， Ａｐｐａｒａｔｕｓ， ａｎｄ Ｓｙｓｔｅｍ ｏｆ Ｐｒｏｃｅｓｓｉｎｇ Ｄａｔａ Ｏｂｊｅｃｔ Ｉｎｆｏｒｍａｔｉｏｎ）」と題する中国特許出願第２０１６１０５３０１３０．５号と、２０１７年７月３日出願の「異種のコンピュータ処理装置を標準インタフェース及び直接ネットワーク接続を介して接続するためのシステム及び方法（Ｓｙｓｔｅｍｓ ａｎｄ Ｍｅｔｈｏｄｓ ｆｏｒ Ｃｏｎｎｅｃｔｉｎｇ Ｄｉｓｐａｒａｔｅ Ｃｏｍｐｕｔｉｎｇ Ｄｅｖｉｃｅｓ ｖｉａ Ｓｔａｎｄａｒｄ Ｉｎｔｅｒｆａｃｅｓ ａｎｄ Ｄｉｒｅｃｔ Ｎｅｔｗｏｒｋ Ｃｏｎｎｅｃｔｉｏｎｓ）」と題する米国特許出願第１５／６４０，７４３号とに基づく優先権の利益を主張し、両出願はその全体が参照により本明細書に組み込まれる。

本開示は、ネットワークインタフェース及びネットワーク接続の分野に関し、具体的には、異種のコンピュータ処理装置及びネットワークを、共有された標準インタフェース、及び各装置と各ネットワークとの間の直接ネットワーク接続を介して接続するためのシステムおよび方法に関する。

オンラインツーオフライン（Ｏ２Ｏ）マーケットの重要性は、電子商取引プラットフォーム及びオンライン決済サービスが拡大を続けるにつれて、徐々に増している。「衣類、食物、住居、及び交通機関」という４つの要素の中で、「住居の要素」が最も重要な要素であり、人々のより快適な観光サービス品質の追及が新たな最盛期に達していることを、人々は認識している。この場合、今後のホテル産業は、消費者の期待を満たし、競争力を改善するために、技術装置、マーケティングモデル、業務効率、サービス概念などの観点から向上する必要がある。

既存の電子商取引プラットフォームの中には、「オンライン客室予約やオフラインチェックイン」のサービスを提供できるものがある。しかしながら、これらのプラットフォームは多数の欠陥に悩まされている。第１の問題は、面倒な支払い手続きである。従来の予約プロセス及びオンライン予約プロセスは、ユーザに客室のコストを超える支払いを求める（例えば、クレジット又はデビットカードの事前承認による予約金、オンライン決済ツールなど）。この手続きは非常に複雑であり、ユーザにお金がかかる。さらに、ホテルの地理的位置や携帯電話の信号が弱いことに起因して、ユーザがオンライン決済ツールをホテル内で使うときに、ユーザはネットワークの問題によってオンライン決済ツールを正常に使うことができない場合がある。この問題は、現在のＯ２Ｏ技術でも浮き彫りになっている。別の問題は、ホテル受付の業務効率の低さである。概して、ユーザは、混雑した時間の受付で、チェックイン、チェックアウト、又は他の手続きを行う。クレジット／デビットカードを用いる現在の方法は効率が低く、カードのスワイプや署名などの処理を行うためにユーザに待ってもらう必要があり、その結果、ユーザは概して長時間待つことになる。したがって、現在のシステムや技術を用いるホテルは非効率であり、不満足なユーザ体験をもたらしている。

本出願は、データオブジェクト情報処理方法、装置、及びシステムを提供する。この方法、装置、及びシステムは、効率を改善して、ユーザが列に並んで待つことがないようにする。この方法、装置、及びシステムは、ユーザとホテルスタッフとの間の直接対話を減らし、オンラインサービスを増やして、ホテルの業務コストを削減することもできる。

１つの実施形態において、本方法は、プラットフォームサーバによってホテルデータオブジェクト情報をクライアントデバイスに提供する段階であって、ホテルデータオブジェクト情報は、クレジットタイプ属性などの複数のタイプ属性を含む、段階と、プラットフォームサーバにおいてクライアントデバイスからの予約リクエストを受信する段階であって、予約リクエストはクレジットタイプ属性の識別情報を含む、段階と、予約リクエストに応答して、クライアントデバイスと関連付けられたユーザのクレジット認証をプラットフォームサーバによって確認する段階と、クレジット認証を確認した後に、クレジットタイプ予約をプラットフォームサーバによって作成する段階と、クレジットタイプ予約と関連付けられた予約情報をホテルと関連付けられたホテルデータ処理システムにプラットフォームサーバによって送信する段階と、プラットフォームサーバにおいてホテルデータ処理システムからのチェックアウトリクエストを受信する段階と、チェックアウトリクエストを受信した後に、予約情報と関連付けられたリソースを、ユーザと関連付けられた支払いアカウントからホテルデータ処理システムにプラットフォームサーバによって移動させる段階とを含む。

１つの実施形態において、本装置は、プロセッサと、コンピュータ実行可能命令を内部に格納した非一時的メモリとを含み、コンピュータ実行可能命令は、プロセッサによって実行された場合、本装置に複数のオペレーションを行わせ、複数のオペレーションは、ホテルデータオブジェクト情報をクライアントデバイスに提供するオペレーションであって、ホテルデータオブジェクト情報は、クレジットタイプ属性などの複数のタイプ属性を含む、オペレーションと、クライアントデバイスからの予約リクエストを受信するオペレーションであって、予約リクエストはクレジットタイプ属性の識別情報を含む、オペレーションと、予約リクエストに応答して、クライアントデバイスと関連付けられたユーザのクレジット認証を確認するオペレーションと、クレジット認証を確認した後にクレジットタイプ予約を作成するオペレーションと、クレジットタイプ予約と関連付けられた予約情報をホテルと関連付けられたホテルデータ処理システムに送信するオペレーションと、ホテルデータ処理システムからのチェックアウトリクエストを受信するオペレーションと、チェックアウトリクエストを受信した後に、予約情報と関連付けられたリソースをユーザと関連付けられた支払いアカウントからホテルデータ処理システムに移動させるオペレーションとである。

本出願によって提供される特定の実施形態によれば、本出願は、以下の技術的効果を開示する。

開示される実施形態に例示するように、プラットフォームにはサーバ及びクライアントデバイスが設けられてよい。１つの実施形態において、サーバは、ホテルデータ処理システムに直結され得る。このようにして、ユーザがクライアントデバイスを用いてホテルの客室を予約できる。予約を作成した後に、サーバは、直接接続を介してホテルデータ処理システムに予約を直接提供してよい。さらに、ホテルのデータオブジェクトはクレジットタイプ属性を有してよい。ユーザがクレジットタイプを選択した場合、サーバはユーザのクレジット認証を確認してよく、確認ができた場合、クレジットタイプ予約を作成してよい。このようにして、ホテルは、予約金不要のチェックイン及び／又は客室確認不要のチェックアウトなどの、クレジットタイプベースのサービスを提供することができる。ユーザがホテルからチェックアウトした後に、サーバは、予約に関連したリソースをユーザの支払いアカウントからホテルに移動させる。開示される実施形態は、効率を改善し、ユーザが列に並んで待つことがないようにする。さらに、開示される実施形態は、ユーザとホテルスタッフとの間の直接対話を減らし、オンラインサービスを拡大して、ホテルの業務コストを削減することもできる。

さらに、様々なタイプの機能オプションによって、請求書を前もって用意させること、オンライン客室選択、インテリジェントドアロック、セルフチェックイン、ルームサービス、双方向マーケティング、及び客室管理などの新たな機能が実現され得る。ホテルは、革新的な予約、チェックイン、及びサービス体験を作り出すことができ、その結果、ユーザとホテルとの間の円滑な対話を提供することになる。プラットフォームデータ、サービス、ソリューションなどを生み出すことによって、ホテルの競争力が改善され得る。ホテルは、その後、「インターネットプラス（Ｉｎｔｅｒｎｅｔ＋）」の時代にすぐに組み込まれ得る。

開示される実施形態を実装するどの製品も、上記の利点を必ずしも全て同時に実現する必要はない。

本出願の実施形態の技術的解決手段を明確に例示するために、これらの実施形態に必要とされる図面が以下に簡潔に紹介される。以下に説明される図面は、単に本出願の実施形態の一部に過ぎず、当業者であれば、創造的努力をすることなく、これらの図面に従って他の図面も取得することができることは明らかである。

本開示の一部の実施形態による、データオブジェクトを処理するためのシステムを例示するブロック図である。

本開示の一部の実施形態による、データオブジェクトを処理するための方法を例示するフロー図である。

本開示の一部の実施形態による、データオブジェクトを処理するための方法を例示するフロー図である。

本開示の一部の実施形態による、データオブジェクトを処理するための方法を例示するフロー図である。

本開示の一部の実施形態による、データオブジェクトを処理するための装置のブロック図である。

本開示の一部の実施形態による、データオブジェクトを処理するための装置のブロック図である。

本開示の一部の実施形態による、データオブジェクトを処理するための装置のブロック図である。

本開示の実施形態において説明される技術的解決手段が、本出願の実施形態の図面を参照して、以下に明確且つ十分に説明される。説明される実施形態は、本開示の実施形態の全てではなく、単なる一部に過ぎない。本出願の実施形態に基づいて当業者が取得できる他の全ての実施形態は、本開示の範囲に含まれるものとする。

開示される実施形態において、電子商取引プラットフォームは、ホテル内のデータ処理システム（例えば、資産管理システム）に接続されてよく、電子商取引プラットフォームは、１つ又は複数のサーバ及びユーザに提供されるクライアントデバイスとして実装されてよい。１つの実施形態において、電子商取引プラットフォームを用いるホテルサービスをホテルが発行する必要がある場合、電子商取引サーバは、ホテルのデータ処理システムとの接続を前もって確立して、サーバ端末の標準インタフェースなどのホテルデータ処理システム情報を提供してよい。同様に、ホテルデータ処理システムは、そのインタフェース情報も電子商取引プラットフォームに提供してよく、こうして、プラットフォームサーバとホテルデータ処理システムとの間の直接接続が実装される。一方、ホテルは、その住所、客室タイプ、及び必要なリソース（値段など）などの情報を電子商取引プラットフォームに公表してよい。電子商取引プラットフォームは、ホテルに関する情報を「データオブジェクト」の形で公表する（例えば、電子商取引プラットフォームでは、データオブジェクトは、「商品」、「サービス」、「ビジネス」などと呼ばれることがあり、各データオブジェクトは、コードと共に提示されている場合、１つの項目に対応し得る）。そのため、消費者ユーザは、クライアントデバイスを用い、電子商取引プラットフォームを介して、予約可能なホテルの客室情報を閲覧することができる。１つの実施形態において、サーバは、「クレジットステイ（ｃｒｅｄｉｔ ｓｔａｙ）」の観点からサポートを提供してよい。「クレジットステイ」とは、以下のシナリオを意味する。すなわち、ユーザが、クライアントデバイスを用いて、ホテルの客室をオンラインで予約する場合、ユーザは「クレジットステイ」の予約タイプを選択することができる。サーバはユーザのクレジット認証を確認することができ、ユーザのクレジットがビジネス条件を満たしているならば、ユーザは、オンライン決済を用いる場合、客室料金を支払う必要はない。ホテルは、予約の「クレジットステイ」識別情報に従って、予約金不要のチェックインをユーザに提供してよく、ユーザは、客室を確認してもらうことも、列に並んで待つこともなく、直接チェックアウトしてよく、また直接ホテルを出てよい。最後に、サーバは、ユーザと関連付けられた支払いアカウントからホテルに客室料金を移動させる。客室料金の支払いに関しては、ユーザ及びホテルが電子商取引プラットフォームに支払いアカウント（例えば、Ｔａｏｂａｏプラットフォームでは、Ａｌｉｐａｙアカウントが用いられてよく、又は関連する銀行口座が用いられてよい、など）を開設してよいので、ホテルデータ処理システムは、チェックアウトリクエストを開始してサーバにチェックアウトリクエストを送信するときに、具体的な支出額をサーバに提供してよい。このようにして、サーバは、対応する額をユーザの支払いアカウントからホテルの入金アカウントに移動させてよい。

ユーザとホテルとの間のオンラインでの対話を実現するために、上記の基本的な機能に基づいて追加機能が派生してよく、それにより、ホテルスタッフの負荷が軽減され、ホテルの効率及びサービス能力が改善される。その間に、サービスを提供するさらに多くの方法がホテルに提供され、ユーザがホテル滞在中に技術及びインターネットによってもたらされる利便性を体験することが可能になる。例えば、予約をキャンセルする機能オプション、ユーザが時間通りにホテルに到着できるかどうかを確認する機能オプション、予約タイプ変更を開始する機能オプション、チェックイン、チェックアウト、決済などの機能オプションが、ホテルに提供されてよい。さらに、オンライン客室選択、オンライン解錠サービス、セルフチェックイン、ビジネス領収書のオンライン発行、ホテルによって提供される別のサービス（例えば、ダイニングサービス、ランドリーサービス、クリーニングサービス、商品サービス、メンテナンスサービスなど）のオンライン申請などの機能オプションが、ユーザにさらに提供されてよい。このようにして、ユーザとホテルとの間の円滑な対話が可能になる。さらに、電子商取引プラットフォームによるデータ、サービス、ソリューションなどを生み出すことによって、ホテルの競争力は改善され得る。したがって、ホテルは、その後、「インターネットプラス」の時代にすぐに組み込まれ得る。

図１は、本開示の一部の実施形態による、データオブジェクトを処理するためのシステムを例示するブロック図である。図１を参照すると、本システムは、プラットフォームサーバ１０１と、少なくとも１つのクライアントデバイス１０２と、少なくとも１つのホテルデータ処理システム１０３（図面には１つだけが示されている）とを含む。

１つの実施形態において、プラットフォームサーバ１０１は、（１）ホテルデータオブジェクト情報をクライアントデバイスに提供し、ホテルデータオブジェクトはクレジットタイプをなどのタイプ属性を有し、（２）クライアントデバイスからの予約リクエストを受信した後に、クライアントデバイスと関連付けられたユーザのクレジット認証を確認し、（３）確認ができた場合、クレジットタイプ予約を作成し、（４）ホテルデータ処理システムのインタフェースを介して、予約情報をホテルデータ処理システムに送信し、（５）ユーザがホテルからチェックアウトした後に、予約と関連付けられたリソース（例えば、客室料金）をユーザと関連付けられた支払いアカウントからホテルと関連付けられた入金アカウントに移動させる。１つの実施形態において、クライアントデバイス１０２は、対象データオブジェクト及びタイプを選択した後に、予約リクエストをプラットフォームサーバに送信する。１つの実施形態において、ホテルデータ処理システム１０３は、プラットフォームサーバから予約を受信し、予約と関連付けられたユーザのホテル滞在中に、所定の方式に従ってクレジットタイプサービスをユーザに提供する。

一部の実施形態において、クレジットタイプ予約には「クレジットステイ」予約又は類似の予約が含まれてよい。クレジットステイ予約では、ユーザがチェックインしてホテルに滞在した後に、ユーザは客室料金も予約金も支払わない。したがって、ホテルは、プラットフォームサーバによってユーザに提供されたクレジット承認に基づいて、オフラインサービス（例えば、客室、ダイニングサービス、ランドリーサービス、クリーニングサービス、商品サービス、メンテナンスサービスなど）をユーザに提供する。プラットフォームサーバは、ユーザがオフラインサービスを使い終えた後に、支払いオペレーションの完了を支援する。換言すれば、ユーザは予約金を支払う前にオフラインサービスを使い、支払いは後で行われてよい。したがって、これは、「クレジットタイプ予約」又は「クレジットステイ」と呼ばれている。

データオブジェクトのタイプ属性に関しては、本明細書で説明されるクレジットタイプは、オンライン決済や到着後の支払いなどの従来の方式に対して新たなタイプである。ユーザは、従来の手段を用いて予約を行うことを選択してよい。あるいは、新規ユーザ又はビジネス条件を満たさないクレジット情報を有するユーザが予約を行う方法が提供されてもよい。１つの実施形態において、「従来の消費方法」を生み出すオプションがさらに提供されてよい。したがって、従来タイプ及びクレジットタイプは、異なるタイプ属性値と呼ばれてよく、タイプ属性によって、ユーザが選択するのに様々なタイプが提供されてよい。ユーザがクレジットタイプを選択した場合、開示された実施形態において提供される方式に従って、クレジット認証が確認される。ホテルは、クレジットタイプ予約が作成された後に、予約金不要サービス、チェックアウト時の客室確認不要サービスなどを提供してよい。ユーザが従来の方式を用いて客室を予約することを選択した場合、従来の方式に従って、通常の予約がユーザに作成されてよい。

ホテルは、クレジットタイプをサポートすることを選択しても、サポートしないことを選択してもよいことに留意されたい。換言すれば、ホテルがプラットフォームに入るプロセスにおいて、サーバによって提供される機能が用いるために設定されてよい。クレジットタイプ機能を用いることを選択したホテルでは、ホテルがそのデータオブジェクト情報を発行する場合、サーバは、クレジットタイプ予約を作成するオプションを提供する。

ユーザがクライアントデバイスを用いて予約を行うときに、ユーザがホテルを選択して「クレジットタイプ」予約を選択した場合、サーバは、そのリクエストをまず受信して、事前設定されたビジネス条件に従って現在のユーザのクレジット認証を確認してよい。様々な特定の確認方法があってよく、特定のビジネス条件は、実際のビジネス要件に従って決定されてよい。例えば、ユーザのクレジットレベル、クレジット限度額、未決済予約数などが利用されてよい。このようにして、ビジネス条件に関わる様々なパラメータについては、具体的に決定を行うときに、サーバは現在のユーザに対応するパラメータ値を決定してよい。サーバは次に、パラメータ値を、条件に設定されている閾値などと比較し、これにより、ユーザがビジネス条件を満たしているかどうかがさらに判定される。例えば、Ａｌｉｔｒｉｐプラットフォームでは、ユーザのＡｌｉｐａｙアカウントと関連付けられた「Ｚｈｉｍａ Ｃｒｅｄｉｔ」の情報が取得されてよく、別のユーザによって提供されるクレジット限度額情報として「Ｍａｙｉ Ｈｕａｂｅｉ」がさらに取得されてよい。さらに、Ａｌｉｐａｙアカウントと関連付けられた未決済予約数などがさらに判定されてよい。現在のユーザがビジネス条件を満たしているかどうかを判定するのに、上記の全ての要素が用いられてよい。ユーザが条件を満たしている場合、予約が作成されてよく、予約のタイプにクレジットタイプ予約の印が付けられる。

クレジットタイプ予約が作成された後に、予約情報がクライアントデバイスに提供されてよい。サーバはホテルデータ処理システムの関連インタフェースを前もって取得しているので、サーバは予約情報を直接接続によってホテルデータ処理システムに直接提供してよい。ユーザがホテルに到着してチェックインするときに、ユーザはクライアントデバイスの電源を入れて、予約情報を提供してよい。予約がクレジットタイプ予約であることを確認した後に、ホテルは、事前設定された方式に従ってクレジットタイプサービスをユーザに提供してよい。クレジットタイプサービスとは、以下のシナリオを意味し得る。すなわち、ユーザがチェックインするときに、ユーザは予約金を支払う必要はなく、あるいは、ユーザがホテルからチェックアウトするときに、客室確認が行われる必要はない。こうして、ユーザが列に並んで待つことがないようにする。さらに、ユーザは、ユーザのホテル滞在中又はホテル滞在後に、客室料金を支払う必要はない。その代わり、サーバが客室料金の支払いをアカウント間で移動させる。一部の実施形態において、ホテルデータ処理システムはさらに、予約ステータスをサーバと同期させてよい。例えば、ユーザが予約金不要の方法でチェックインした後に、ホテルデータ処理システムは予約ステータスを「チェックイン済み」に変更し、そのことをサーバに送信してよい。その後、ユーザがホテルからチェックアウトするときに、ユーザは客室を確認してもらうことなくチェックアウトしてよい。ホテルデータ処理システムは、予約ステータスを「チェックアウト済み」に変更して、そのことをサーバに送信してよい。さらに、予約と関連付けられたリソース（支出額など）などの情報が送信されてよく、サーバは、対応するリソースをプラットフォームのユーザの支払いアカウントからホテルの入金アカウントに移動させてよい。

さらに、上記の基本的な「クレジットステイ」サービスの提供に基づいて、サーバはさらに、予約の処理オペレーションに「機能オプション」を提供して、予約のライフサイクルにおける予約の処理オペレーションを容易にしてよい。

具体的には、対象となるオブジェクトに応じて、機能オプションは、ホテルデータ処理システムに提供されて、予約の処理オペレーションに用いられる少なくとも１つの第１の機能オプションと、クライアントデバイスに提供されて、予約の処理オペレーションに用いられる少なくとも１つの第２の機能オプションとに分類されてよい。第１の機能オプションは、予約と共にホテルデータ処理システムに提供されてよく、ホテルデータ処理システムは、指定予約の処理オペレーションを求めるリクエストを開始し、そのリクエストを第１の機能オプションと共にサーバに送信してよい。それに応じて、サーバはホテルデータ処理システムのリクエストを適切に処理してよい。第２の機能オプションは、ユーザのクライアントデバイスのユーザインタフェースを介して、ユーザに提供されてよい。ユーザは、オペレーションリクエストを第２の機能オプションとともにクライアントデバイスにおいて開始してよい。クライアントデバイスは、このリクエストをサーバに送信してよく、サーバはユーザのリクエストを適切に処理する。

第１の機能オプションは、ホテルデータ処理システムが予約オペレーションを能動的に開始するための、又はユーザと対話するための実現可能な方法を提供し、第１の機能オプションは、具体的には、実際の要件に従って提供されてよい。例えば、１つの実施形態において、ホテルデータ処理システムは予約をキャンセルする必要があり得る。したがってサーバは、予約をキャンセルするのに用いられる第１の機能オプションをホテルデータ処理システムに提供してよい。このようにして、ホテルが予約のキャンセルを開始する必要がある場合、ホテルは、サーバによって提供された機能オプションを用いて、キャンセルを開始してよい。それに応じて、この情報は、事前取得されたサーバの標準インタフェースを介してサーバに送信されてよい。サーバは、具体的には、予約キャンセルの関連オペレーションを行う。サーバは、最終処理結果をホテルデータ処理システムに返信してよい。また、ユーザはさらに、処理結果を通知されてよい。予約のキャンセルオペレーションを行うとき、サーバはまず、確認チェックを開始し、それをユーザのクライアントデバイスに送信してよく、予約がキャンセルされてよいことをユーザが確認した場合に、キャンセルオペレーションが実行されてよい。

別の実施形態において、ホテルはさらに、ユーザが時間通りにホテルに到着できるかどうかを確認する必要があり得る。例えば、ホテルの客室をオンラインで予約する場合、ユーザは、前もって手数料を何も支払うことなく、チェックイン日を指定してよい。この場合、ユーザが時間通りに到着して予約を実行することができないならば、ホテルは損失を負わなければならないことがある。そのような場合では、他のゲスト／ユーザの予約特典にも影響を与えることがある。したがって、このタイプの予約の場合、ホテルは、ユーザが時間通りにホテルに到着できるかどうかを確認する必要があり得る。ユーザが時間通りに到着して予約を実行することができない場合、ホテルは、他のユーザ用に客室を空けるために、予約のキャンセルオペレーションなどを開始してよい。ユーザが時間通りに到着できる場合、客室は当該ユーザのために予約されたままであってよい。現在の解決手段では、ホテルは、多くの場合、ユーザが残した電話番号を用いて手動でユーザに連絡する必要があり、これによって、ホテルの相当なリソースが消費されることは明らかである。しかしながら、本開示の実施形態では、ユーザが時間通りにホテルに到着できるかどうかを確認するための機能オプションを、ホテルデータ処理システムが有している。到着時刻確認リクエストが、このオプションを用いて、直接開始されてよい。それに応じて、リクエストを受信した後に、サーバは、指定予約と関連付けられたクライアントデバイスにユーザの到着の確認をリクエストする照会メッセージを送信し、クライアントデバイスによって返信された結果（ユーザが時間通りにホテルに到着するかどうかに関する情報を含む）をホテルデータ処理システムに提供してよい。このようにして、ホテルのリソースを節約することができ、処理効率を改善することができる。

さらに、ホテルは予約タイプを変更する必要があり得る。ここで、予約タイプ変更機能オプションとは、主に、予約を未確定予約から確定済み予約に変更することを意味する。いわゆる未確定予約とは、ユーザがホテルの客室をオンラインで予約し、前もって手数料を何も支払うことなくチェックイン日を指定するという状況を意味する。一方、確定済み予約とは、ユーザがホテルの客室をオンラインで予約し、ユーザが特定のチェックイン日を選択するときに、ホテルが要求する予約金を支払うという状況を意味する。この場合、ユーザが時間通りにチェックインできないならば、予約金は返金されず、これによりホテルは、ユーザが予約した時間に現れないことによる損失を負わないように守られることになる。ユーザが時間通りにチェックインした場合、予約金は、ユーザがホテルからチェックアウトするときに、ユーザに返金される（このプロセスは従来の確定プロセスであり、本出願の実施形態では、既存の確定プロセスが改善され得る。そのことについては、次に詳細に説明される）。例えば、ユーザが時間通りにホテルに到着できるかどうかに関する確認チェックを行う上記シナリオは、未確定予約にも適用される。ホテルは通常、ユーザが指定したチェックイン日と同じ日又はその１日前に、ユーザが時間通りにホテルに到着できるかどうかを確認する必要がある。ユーザが、自分が時間通りにホテルに到着できるかどうか分からないが、それでも、客室の予約をホテルに求める場合、ホテルは、未確定予約を確定済み予約に変更する必要があり得る。これによりホテルは、ユーザが予約した時間に現れないことによる損失を負わないように守られることになる。このシナリオにおいて、ホテルデータ処理システムは、サーバによって提供された、予約タイプ変更を行うための第２の機能オプションを用いて、対応するリクエストを開始してよい。リクエストを受信した後に、サーバは、指定予約を確定済み予約に変更し、変更結果をホテルデータ処理システムに提供してよい。

未確定予約が具体的に確定済み予約に変更された場合、他の関連オペレーションも行われてよい。予約が従来の方式で確定された場合、例えば、サーバはさらに、予約変更の間に予約金の支払いを完了するようにユーザを支援し得る。従来の確定方法には多数の欠陥がある。まず、ユーザは予約金を前もって支払う必要があり、この予約金はユーザの利用可能な資金に影響を与える。さらに、通常、支払いアカウントに関するユーザの情報は、ホテルに提供される必要がある。中国内のホテルの中には、クレジット／デビットカード、Ａｌｉｐａｙ、又は別のサードパーティの支払いツールなどを用いることを含む、多数の支払い方法をサポートしているところもある。一方、国際的なホテルの中には、クレジット／デビットカードによる支払い方法しかサポートしないところもある。どの支払い方法を用いるかに関係なく、ユーザのアカウント情報がホテルに提供されて、これが支払い中のセキュリティリスクにつながる。さらに、このオペレーションプロセスは比較的複雑であり、効率が低い。ユーザが時間通りにチェックインした場合、予約金をユーザのアカウントに返金する逆方向のプロセスも必要になる。プロセス全体がネットワークリソースの無駄につながる。したがって、１つの実施形態において、確定プロセスをさらに最適化するために、新たな確定済み予約処理方法が開示される。ユーザが確定済み予約をオンラインで行う場合、ユーザが（先に論じられた）ビジネス条件を満たしている信用されたユーザであるならば、サーバは、ユーザに関連予約金を支払ってもらう必要もなく、予約に確定済み予約の印を直接付ける。ユーザが時間通りにホテルに到着してチェックインすることができない場合、サーバは、関連予約金額をユーザの支払いアカウントからホテルの入金アカウントに移動させる。このようにして、ユーザのお金を不必要に持ち続けることを回避することができ、全体的な処理効率を改善することができる。さらに、ユーザのアカウント情報はユーザに提供される必要はなく、その結果、ユーザ情報の潜在的なセキュリティリスクが排除される。こうして、この確定方法では、サーバがホテルデータ処理システムからの予約変更リクエストを受信した場合、サーバは、他の確定関連のオペレーションを行う必要なく、対応する予約に確定済み予約の印を直接付けてよい。ユーザが時間通りにホテルに到着してチェックインした場合、サーバ及びホテルはオペレーションを何も行う必要はなく、ユーザが時間通りにチェックインしない場合、サーバは予約金を移動させるオペレーションを行う。

上述した様々な第１の機能オプションに加えて、チェックイン、チェックアウト、決済、及びサービスオペレーション完了通知機能オプションなどのオペレーション機能オプションも含まれてよい。チェックイン機能オプションが選択された場合、ホテルデータ処理システムは、予約ステータスを「チェックイン済み」に変更し、このステータス情報をサーバに提供してよい。サーバは予約ステータスを同時に変更する。チェックアウト機能オプションが選択された場合、ホテルデータ処理システムは、予約ステータスを「チェックアウト済み」に変更し、このステータス情報をサーバに提供してよい。サーバは予約ステータスを同時に変更する。決済機能オプションが選択された場合、ホテルデータ処理システムは、予約と関連付けられた支出額などの情報をサーバに提供してよい。サーバは、支出額を移動させるオペレーションを行う。サービスオペレーションが完了したことをサーバに通知するために、サービスオペレーション完了通知オプションが用いられ、サーバはこの通知をクライアントデバイスなどに転送してよい。

代替の実施形態において、他の機能オプションが、ホテルデータ処理システムの要件（本明細書では詳細に説明されていない）に従って、ホテルデータ処理システムに提供されてよい。

第２の機能オプションのタイプが以下に紹介される。

第２の機能オプションは、ユーザが予約オペレーションを能動的に開始するための、又はホテルデータ処理システムと対話するための実現可能な方法を提供し、第２の機能オプションは実際の要件に従って提供されてよい。まず、サーバは、オンラインチェックアウトの機能オプションをユーザに提供してよい。この機能オプションによって、ユーザはチェックアウトリクエストをオンラインで開始してよい。このリクエストは、まずサーバに届けられてよく、次にサーバは、当該リクエストをホテルデータ処理システムに転送する。

代替的に又は前述の事項と共に、ユーザは通常、ビジネス領収書（請求書など）を必要とするかもしれない。現在の解決手段では、概して、ゲストがホテルからチェックアウトするときに、ゲストは、請求書（金額、題目など）を用意するリクエストを受付係に通知する。受付係は請求書を発行して、その請求書をゲストに手渡す。しかしながら、ゲストが受付でチェックアウトを行い、受付が請求書を発行するのを待つ必要がある場合、受付が人手不足であったり、多数のゲストが同じ目的のために同時に待っていたりするならば、かなり時間がかかることになる。そのような待ち時間があるシナリオでは、ゲストが飛行機、列車などに乗り遅れるという結果にもなり得る。ホテル産業では、チェックアウト手続きは通常、正午前又は午後２時前に行われる必要がある。ゲストが時間通りにチェックアウトできなかった場合、ホテルは追加手数料を請求してよい。結果として、ゲストは皆、チェックアウトを朝に済ましたくなるかもしれず、これにより、受付係は午前８時を過ぎると多忙を極めることになる。さらに、受付係が請求書を発行するプロセスでは、概して、メモを印刷する必要があり、そのメモが正しいことを顧客が受付で確認した後に、受付係が請求書を印刷する。この手続きには相互の対話と待ち時間とが必要なので、多くの時間が費やされる。多数のゲストがチェックアウトして請求書を待っている場合、列に並んでいる最後のゲストは長時間待つ必要があり、そのことが、このゲストのその後の旅行日程に影響を与えるかもしれない。

このようなことに対処するために、サーバはさらに、ビジネス領収書をユーザに発行するための機能オプションを提供してよい。この機能オプションは通常、予約に「チェックイン済み」ステータスが入力された後に、使用可能ステータスに変更される。このようにして、ユーザは、ホテルからチェックアウトする前に、ビジネス領収書を発行するリクエストを開始してよい。サーバは次に、このリクエストをホテルデータ処理システムに転送する。ホテルスタッフは、ビジネス領収書発行に関するあらゆる関連オペレーションを前もって行い、請求書を印刷して、必要であれば請求書を客室に届け、請求書を受付で保管し、請求書をユーザにメールすることなどができる。忙しい時間に、ビジネス領収書が発行されるのを受付で待たなければならないことが回避され得るので、処理効率が改善され、別のユーザのために時間が節約される。最初のユーザの場合、ビジネス領収書を発行するリクエストは異なる時間で処理され得るので、サービス品質が改善される。サービスを提供するプラットフォームはさらに、様々なサービス及び情報を改善し得る。

ユーザは、チェックインする前に手数料を何も支払うことなく、クレジット消費方法を利用するので、日数が増えると、支出額は常に変化する。したがって、ユーザは自分の現在の支出額を確認する必要があるかもしれない。現在の解決手段では、ユーザは通常、自分で受付と話すか又は電話をかけて照会することなどができる。しかしながら、１つの実施形態において、サーバは、現在の支出額を照会するための機能オプションを、クライアントデバイスのユーザインタフェースに提供してよい。このようにして、ユーザは、そのような必要性が生じたときに、クライアントデバイスを用いてリクエストを開始してよい。サーバは、指定予約の支出額の照会を求める受信済みリクエストをホテルデータ処理システムに送信し、ホテルデータ処理システムによって返信された照会結果をクライアントデバイスに提供してよい。

ユーザがホテル滞在中に、ホテルは多くの場合、ゲストの滞在をより楽しめるものにするために、ダイニングサービス、ランドリーサービス、クリーニングサービス、商品サービス、及びメンテナンスサービスなどの他の関連接客サービスを提供することがある。現在の解決手段では、これらのサービスは、ユーザが受付に電話をかけた後、又は自分で受付係を訪ねた後に利用可能になる。しかしながら、１つの実施形態において、ホテルによって提供される接客サービスを利用するための機能オプションが、クライアントデバイスのユーザインタフェースに提供されてよい。指定予約の接客サービスを利用するリクエストを受信した後に、サーバはこのリクエストをホテルデータ処理システムに送信してよい。ホテルデータ処理システムは次に、対応するリソース（人的リソース及び物的リソースを含む）を割り当て、対応するサービスを関連するユーザに提供することになる。

さらに、オンライン客室選択、オンライン解錠サービス、セルフチェックインなどを含むよりインテリジェントな第２の機能オプションが、システムのインテリジェンスをさらに高めるために提供されてよい。客室選択に関しては、現在の解決手段において、ユーザは客室タイプ、すなわち、スタンダードルーム、ビジネスルームなどしか選択できない。しかしながら、特定の客室番号は、ユーザがチェックインするときに、受付係のみによって割り当てられる。ユーザは、提供されたものを承諾してチェックインすることしかできない。割り当てられた客室にユーザが満足できない場合、客室変更に関して受付係とさらに対話する必要があるので、低効率と不満足なユーザ体験とがもたらされる。
しかしながら、１つの実施形態において、サーバは、オンライン客室選択機能オプションをユーザに提供してよい。ユーザが客室をオンラインで選択する必要がある場合、ユーザはこのオプションを用いてリクエストを開始してよい。サーバは、ホテルの屋内／屋外の地図データと、ホテルデータ処理システムから事前取得されたリアルタイムの客室予約情報とに従って、オンライン客室選択インタフェースをクライアントデバイスに提供し、クライアントデバイスによって送信された選択結果を予約に加えて、その予約をホテルデータ処理システムに提供してよい。オンライン客室選択によって、ユーザは、ユーザのニーズを満たす客室をオンラインで選択してよい。さらに、この選択は客室タイプに限定されるものではない。選択オプションには客室番号が含まれ、どの方向に客室が向いているか、どのフロアに客室が位置しているかなども利用可能である。一部の実施形態において、ホテルの客室詳細情報などの基本的なデータ情報がホテルによって提供されてよく、それに応じてプラットフォームサーバは、ユーザのクライアントデバイスに提供される地図データを作成する。客室選択の要求は通常、ユーザがチェックイン日を決定した後に生じる。したがって、ユーザが客室を選択した後に、サーバは、選択された客室と、関連するチェックイン日の情報とを記録してよい。これらの情報は、ホテルの客室のリアルタイム予約情報として用いられてよい。別のユーザからのオンライン客室選択リクエストが続いて受信された場合、同じチェックイン日に予約されていない客室が、別のユーザに提供されてよい。

オンライン解錠サービスとは、以下の状況、すなわち、ユーザがホテルにチェックインするときに、ユーザがクライアントデバイスを用いて身元確認情報を直接送信してよいという状況を意味する。サーバは身元情報を確認し、確認ができた場合、その確認結果をホテルデータ処理システムに送信する。確認結果を見た後に、受付係は、客室カード及び客室のパスワードなどの情報をユーザに送信してよい。さらに、自動エレベータ制御、自動電源オフなどのような機能がさらに実行されてよい。様々なタイプの身元確認情報が利用可能である。例えば、１つの実施形態において、身元確認情報はユーザの顔スキャン情報であってよい。換言すれば、ユーザがオンライン解錠機能オプションを利用した後に、クライアントデバイスはクライアントデバイス上の画像取得デバイスを起動し、ユーザの顔をスキャンしてスキャン情報をサーバにアップロードしてよい。サーバは公安部署などのシステムに接続され、ユーザの実名及びＩＤ番号などの事前格納情報に従って、身分証明書番号と関連付けられた身分証明書の写真を公安システムから引き出してよい。サーバは次に、受信された顔スキャン結果を身分証明書の写真と比較し、この比較結果に基づいて、ユーザの身元確認情報を確認する。この確認はさらに、指紋比較及び虹彩比較などの他の方法で行われてよい。

別のシナリオは、ユーザがチェックインして、割り当てられた客室を見つける必要が生じてからであり、多数の客室がホテルに存在し、フロアプランが複雑な場合、ユーザは客室を捜し出すのに苦労することになる。この場合、サーバはさらに、セルフチェックインの機能オプションをユーザに提供してよい。ユーザは、この機能オプションによって提供されるオペレーションを行ってよい。クライアントデバイスからのリクエストを受信した後に、サーバは、事前格納されたホテルの屋内／屋外の地図データと、予約と関連付けられた客室の割り当て結果とに従って、ナビゲーション情報をクライアントデバイスに提供してよい。端末機器の測位精度が低い（例えば、およそ１０メートルの誤差があるかもしれない）場合、ユーザは音声リマインダによって特定の位置を通知されてよいことに留意されたい。例えば、ユーザは、エレベータを降りた後に、左又は右に曲がり、特定の距離を真っ直ぐ進み、その後、左又は右に曲がるなどのように促される。測位精度が高い場合、動的なリアルタイムナビゲーションが行われてよい。すなわち、ユーザは、ユーザの実際の移動位置と連動して、左、右などに曲がるよう促される。

ホテルとユーザとの間で対話を実現することで、必要な従業員を削減し、処理効率を改善してユーザ体験を向上させるために、サーバによって提供される様々な機能オプションが上記に紹介されている。実際には、上記の機能はさらに、実際のニーズに従って拡張されてよく、これらの機能は本明細書において限定されるものではない。また、プラットフォームに接続するプロセスにおいて、ホテルはさらに、異なる機能を構成してよく、すなわち、一部の機能オプションを用いるか又は用いないかを選択してよい。例えば、ホテルによっては、ダイニングサービスもメンテナンスサービスもなくてよく、こうしたホテルは、これらの機能オプションを用いないことを選択してよい。あるいは、ホテルによっては、確定済み予約を承諾しなくてよく、こうしたホテルは、予約タイプ変更機能オプションなどを用いないことを選択してよい。つまり、サーバは、ホテルの設定情報を格納してよく、データオブジェクト情報をクライアントデバイスに提供する場合、ホテルデータ処理システムによって用いられるように選択されたクライアントデバイス機能オプションをただ提供するだけでよい。したがって、ユーザが特定の機能オプションを選択したが、ホテルはその要件を満たすことができないという状況が回避され得る。

つまり、開示される実施形態に従って提供されるシステムを用いて、プラットフォームにはサーバ及びクライアントデバイスが設けられてよく、サーバはホテルデータ処理システムに直結され得る。このようにして、ユーザがクライアントデバイスを用いてホテルの客室を予約できる。予約を作成した後に、サーバは、直接接続を介してホテルデータ処理システムに予約を直接提供してよい。さらに、ホテルのデータオブジェクトはクレジットタイプ属性を有してよい。ユーザがクレジットタイプを選択した場合、サーバはユーザのクレジット認証を確認してよく、確認ができた場合、クレジットタイプ予約を作成してよい。このようにして、ホテルは、予約金不要のチェックイン及び客室確認不要のチェックアウトなどの、クレジットタイプベースのサービスを提供することができる。ユーザがホテルからチェックアウトした後に、サーバは、予約に関連したリソースをユーザの支払いアカウントからホテルに移動させる。この方式で効率が改善され、ユーザが列に並んで待つことがないようにする。さらに、ユーザとホテルとの間の円滑な対話が、様々な機能オプションを介して実施される。プラットフォームデータ、サービス、ソリューションなどを生み出すことによって、ホテルの競争力が改善され得る。ホテルは、その後、「インターネットプラス」の時代にすぐに組み込まれ得る。

図１に関連して論じられる実施形態は、開示される実施形態によって提供される技術的解決手段を、システムレベルの観点から主に紹介する。しかしながら、図２に関連して説明されるように、様々な方法がサーバの観点から開示される。

図２は、本開示の一部の実施形態による、データオブジェクトを処理するための方法を例示するフロー図である。図２を参照すると、例示された実施形態は、データオブジェクト情報処理方法を提供する。本方法は、以下の段階を含んでよい。

Ｓ２０１：プラットフォームサーバによってホテルデータオブジェクト情報をクライアントデバイスに提供する。ホテルデータオブジェクトはタイプ属性を有し、タイプ属性はクレジットタイプ属性を含む。

Ｓ２０２：クライアントデバイスによって送信された、指定データオブジェクトを求める予約リクエストを受信した後に、リクエストタイプがクレジットタイプである場合、クライアントデバイスと関連付けられたユーザのクレジット認証を確認する。

Ｓ２０３：確認ができた場合、予約を作成し、その予約にクレジットタイプ予約の印を付ける。

Ｓ２０４：予約と関連付けられたユーザのホテル滞在中に、所定の方式に従ってクレジットタイプサービスをユーザに提供するために、ホテルデータ処理システムのインタフェースを介して、指定データオブジェクトと関連付けられたホテルデータ処理システムに予約を提供する。

Ｓ２０５：ユーザがホテルからチェックアウトした後に、予約と関連付けられたリソースをプラットフォームユーザと関連付けられた支払いアカウントからホテルと関連付けられた入金アカウントに移動させる。

さらに、図１に関連して論じられたように、予約の処理オペレーション用の機能オプションがさらに、クライアントデバイス及び／又はホテルデータ処理システムに提供されて、予約のライフサイクルの間の予約の処理オペレーションを容易にしてよく、こうして、ユーザとホテルとの間の円滑な対話が実現される。

図３は、本開示の一部の実施形態による、データオブジェクトを処理するための方法を例示するフロー図である。図３に例示する実施形態は、クライアントデバイスの観点から、データオブジェクト情報処理方法を提供する。図３を参照すると、本方法は、以下の段階を含んでよい。

Ｓ３０１：プラットフォームサーバによって提供されるホテルデータオブジェクト情報をクライアントデバイスによって提示する。ホテルデータオブジェクトはタイプ属性を有し、タイプはクレジットタイプ属性を含む。

Ｓ３０２：リクエストタイプがクレジットタイプの場合、リクエストを受信した後に、指定データオブジェクトを求める予約リクエストをサーバに送信する。これによってサーバは、クライアントデバイスと関連付けられたユーザのクレジット認証を確認し、確認ができた場合、予約を作成して予約にクレジットタイプサービス予約の印を付け、予約と関連付けられたユーザのホテル滞在中に、所定の方式に従ってクレジットタイプサービスをユーザに提供するために、ホテルデータ処理システムのインタフェースを介して、指定データオブジェクトと関連付けられたホテルデータ処理システムに予約を提供し、ユーザがホテルからチェックアウトした後に、予約と関連付けられたリソースをユーザと関連付けられた支払いアカウントからホテルと関連付けられた入金アカウントに移動させる。

図４は、本開示の一部の実施形態による、データオブジェクトを処理するための方法を例示するフロー図である。図４に例示する実施形態は、ホテルデータ処理システムの観点から、データオブジェクト情報処理方法を提供する。図４を参照すると、本方法は以下の段階を含んでよい。

Ｓ４０１：プラットフォームサーバによって提供されるクレジット消費サービス予約を、システムインタフェースを介してホテルデータ処理システムによって受信する。一部の実施形態において、予約は以下の方式で作成される。サーバは、クライアントデバイスによって送信された、指定データオブジェクトを求める予約リクエストを受信した後に、リクエストタイプがクレジットタイプである場合、クライアントデバイスと関連付けられたユーザのクレジット認証を確認し、確認ができた場合に予約を作成し、この予約にクレジットタイプサービス予約の印を付ける。

Ｓ４０２：予約のステータス情報をサーバに提供する。

Ｓ４０３：ユーザがホテルからチェックアウトするときに、チェックアウトリクエストを開始してチェックアウトリクエストをプラットフォームサーバに送信する。これによってサーバは、予約と関連付けられたリソースをユーザと関連付けられた支払いアカウントからホテルと関連付けられた入金アカウントに移動させる。

図２から図４に例示する実施形態は、図１に関連して説明された機能及び方法に対応することに留意されたい。したがって、関連する技術実装の詳細は図１の実施形態の説明を参照することで得られ得るので、その詳細はここで繰り返されないが、その全体が参照により組み込まれる。

図５は、本開示の一部の実施形態による、データオブジェクトを処理するための装置のブロック図である。

図５に例示するように、本開示はさらに、プラットフォームサーバに適用できるデータオブジェクト情報処理装置を提供する。図５を参照すると、本装置は、ホテルデータオブジェクト情報をクライアントデバイスに提供するデータオブジェクト情報提供ユニット５０１を含む。１つの実施形態において、ホテルデータオブジェクトは、１つ又は複数のタイプ属性を含み、タイプはクレジットタイプ属性を含む。

例示された実施形態において、本装置はさらに、クライアントデバイスによって送信された、指定データオブジェクトを求める予約リクエストを受信した後に、リクエストタイプがクレジットタイプである場合、クライアントデバイスと関連付けられたユーザのクレジット認証を確認するクレジット認証確認ユニット５０２を含む。

例示された実施形態において、本装置はさらに、確認ができた場合に予約を作成し、予約にクレジットタイプサービス予約の印を付ける予約作成ユニット５０３を含む。

例示された実施形態において、本装置はさらに、予約と関連付けられたユーザのホテル滞在中に、所定の方式に従ってクレジットタイプサービスをユーザに提供するために、ホテルデータ処理システムのインタフェースを介して、指定データオブジェクトと関連付けられたホテルデータ処理システムに予約を提供する予約情報提供ユニット５０４を含む。

例示された実施形態において、本装置はさらに、ユーザがホテルからチェックアウトした後に、予約と関連付けられたリソースをユーザと関連付けられた支払いアカウントからホテルと関連付けられた入金アカウントに移動させるリソース移動ユニット５０５を含む。

図６は、本開示の一部の実施形態による、データオブジェクトを処理するための装置のブロック図である。

図６に例示するように、本開示はさらに、クライアントデバイスに適用できるデータオブジェクト情報処理装置を提供する。

例示された実施形態において、図６に例示する装置は、プラットフォームサーバによって提供されるホテルデータオブジェクト情報を提示するように構成された、データオブジェクト情報提示ユニット６０１を含み、ホテルデータオブジェクトはタイプ属性を有し、タイプはクレジットタイプを含む。

例示された実施形態において、図６に例示する装置は、リクエストを受信した後に、指定データオブジェクトを求める予約リクエストをサーバに送信するように構成された、予約リクエスト送信ユニット６０２を含む。これによってプラットフォームサーバは、リクエストタイプがクレジットタイプである場合、クライアントデバイスと関連付けられたユーザのクレジット認証を確認し、確認ができた場合に予約を作成して、予約にクレジットタイプサービス予約の印を付け、予約と関連付けられたユーザのホテル滞在中に、所定の方式に従ってクレジットタイプサービスをユーザに提供するために、ホテルデータ処理システムのインタフェースを介して、指定データオブジェクトと関連付けられたホテルデータ処理システムに予約を提供し、ユーザがホテルからチェックアウトした後に、予約と関連付けられたリソースをユーザと関連付けられた支払いアカウントからホテルと関連付けられた入金アカウントに移動させる。

図７は、本開示の一部の実施形態による、データオブジェクトを処理するための装置のブロック図である。

図７に例示するように、本開示はさらに、ホテルデータ処理システムに適用できるデータオブジェクト情報処理装置を提供する。図７を参照されたい。

図７に例示する装置は、プラットフォームサーバによって提供されるクレジット消費サービス予約を、システムインタフェースを介して受信するように構成された、予約情報受信ユニット７０１を含み、予約は以下の方式で作成される。サーバは、クライアントデバイスによって送信された、指定データオブジェクトを求める予約リクエストを受信した後に、リクエストタイプがクレジットタイプである場合、クライアントデバイスと関連付けられたユーザのクレジット認証を確認し、確認ができた場合に予約を作成し、この予約にクレジットタイプサービス予約の印を付ける。

図７に例示する装置は、予約のステータス情報をサーバに提供するように構成された、予約ステータス情報提供ユニット７０２を含む。

図７に例示する装置は、ユーザがホテルからチェックアウトするときに、チェックアウトリクエストを開始してチェックアウトリクエストをプラットフォームサーバに送信するように構成された、チェックアウトリクエスト開始ユニット７０３を含む。これによってサーバは、予約と関連付けられたリソースをユーザと関連付けられた支払いアカウントからホテルと関連付けられた入金アカウントに移動させる。

開示された実施形態によって、プラットフォームにはサーバ及びクライアントデバイスが設けられ得る。サーバは、ホテルデータ処理システムに直結され得る。このようにして、ユーザがクライアントデバイスを用いてホテルの客室を予約できる。予約を作成した後に、サーバは、直接接続を介してホテルデータ処理システムに予約を直接提供してよい。さらに、ホテルのデータオブジェクトはクレジットタイプ属性を有してよい。ユーザがクレジットタイプを選択した場合、サーバはユーザのクレジット認証を確認してよく、確認ができた場合、クレジットタイプ予約を作成してよい。このようにして、ホテルは、予約金不要のチェックイン及び客室確認不要のチェックアウトなどの、クレジットタイプベースのサービスを提供することができる。ユーザがホテルからチェックアウトした後に、サーバは、予約に関連したリソースをユーザの支払いアカウントからホテルに移動させる。開示された実施形態は、効率を改善し、ユーザが列に並んで待つことがないようにする。さらに、開示された実施形態は、ユーザとホテルスタッフとの間の直接対話を減らし、オンラインサービスを拡大して、ホテルの業務コストを削減することもできる。

各実装例に関する前述の説明によって、当業者であれば、開示された実施形態がソフトウェアと必要な汎用ハードウェアプラットフォームとによって実現され得ることを明確に理解し得る。そのような理解に基づいて、従来技術に本質的に又は部分的に寄与する開示された実施形態の技術的解決手段は、ソフトウェア製品の形で具現化されてよい。ソフトウェア製品は、ＲＯＭ／ＲＡＭ、磁気ディスク、又は光ディスクなどの記憶媒体に格納され、いくつかの命令を含んでよい。これらの命令によって、コンピュータ装置（パーソナルコンピュータ、サーバ、ネットワーク機器などであってよい）は、実施形態における方法又は本開示の実施形態の特定の部分を実行することが可能になる。

本明細書の様々な実施形態が、段階的な方式で説明されている。実施形態間の同じ部分又は類似した部分は、互いに参照されてよい。各実施形態では、他の実施形態と異なる部分に注目して、そのような部分が説明されている。特に、システム又はシステムの実施形態に関しては、これらの実施形態が方法の実施形態と実質的に類似しているので、その説明は比較的簡潔になっており、関連部分については、方法の実施形態の説明を参照することができる。上記に説明されたシステム及びシステムの実施形態は単に例示的なものであり、別個の構成要素として説明された各ユニットは、物理的に分かれていてもそうでなくてもよく、ユニットとして示された構成要素は物理的ユニットであってもそうでなくてもよく、１か所に配置され得るだけでなく、複数のネットワークユニットに分散されてもよい。モジュールの一部又は全てが、実際の要求に従って実施形態スキームの目的を実現するために選択され得る。当業者であれば、創造的努力をすることなく、開示された実施形態を理解して実施し得る。

以上に、開示された実施形態に提供されるデータオブジェクト情報処理方法、装置、及びシステムが詳細に紹介されている。開示された実施形態の原理及び実装方式は、具体的な実施例を参照して本明細書に記載されている。上記の実施形態の説明は、開示された実施形態の方法及び本質的な考えを理解する際の支援のみに役立てられる。また当業者においては、開示された実施形態の考えに従って、特定の実装方式及び応用範囲に変更が行われてよい。上記事項を考慮して、本明細書の内容は、開示された実施形態を限定するものと解釈されるべきではない。

Claims (20)

1. プラットフォームサーバによってホテルデータオブジェクト情報をクライアントデバイスに提供する段階であって、前記ホテルデータオブジェクト情報は、クレジットタイプ属性などの複数のタイプ属性を含む、段階と、
   前記プラットフォームサーバにおいて前記クライアントデバイスからの予約リクエストを受信する段階であって、前記予約リクエストは前記クレジットタイプ属性の識別情報を含む、段階と、
   前記予約リクエストに応答して、前記クライアントデバイスと関連付けられたユーザのクレジット認証を前記プラットフォームサーバによって確認する段階と、
   前記クレジット認証を確認した後に、クレジットタイプ予約を前記プラットフォームサーバによって作成する段階と、
   前記クレジットタイプ予約と関連付けられた予約情報をホテルと関連付けられたホテルデータ処理システムに前記プラットフォームサーバによって送信する段階と、
   前記プラットフォームサーバにおいて前記ホテルデータ処理システムからのチェックアウトリクエストを受信する段階と、
   前記チェックアウトリクエストを受信した後に、前記予約情報と関連付けられたリソースを前記ユーザと関連付けられた支払いアカウントから前記ホテルデータ処理システムに前記プラットフォームサーバによって移動させる段階と
   を備える方法。
2. 前記クレジットタイプ予約はクレジットステイ予約を含む、請求項１に記載の方法。
3. ユーザのクレジット認証を確認する段階は、ユーザのクレジットレベル、クレジット限度額、未決済予約数、又はこれらの組合せを確認する段階を有する、請求項１又は２に記載の方法。
4. 前記プラットフォームサーバ及びホテルデータ処理システムは、直接接続及び共有インタフェースを介して通信する、請求項１から３のいずれか一項に記載の方法。
5. 前記プラットフォームサーバによって前記ユーザの予約ステータスを前記ホテルデータ処理システムと同期させる段階をさらに備える、請求項１から４のいずれか一項に記載の方法。
6. 前記ホテルデータ処理システム又は前記クライアントデバイスによって実行可能な１つ又は複数の機能オプションを前記プラットフォームサーバによって提供する段階をさらに備える、請求項１から５のいずれか一項に記載の方法。
7. 前記１つ又は複数の機能オプションは、前記ホテルデータ処理システムが予約をキャンセルすることを可能にする機能を含み、前記方法はさらに、前記プラットフォームサーバによって前記クレジットタイプ予約をキャンセルする段階を備える、請求項６に記載の方法。
8. 前記１つ又は複数の機能オプションは、前記ホテルデータ処理システムが前記ユーザのチェックイン時刻を確認することを可能にする機能を含み、前記方法はさらに、
   前記プラットフォームサーバにおいて前記ホテルデータ処理システムからの到着時刻確認リクエストを受信する段階と、
   前記プラットフォームサーバによって前記クライアントデバイスに照会メッセージを送信する段階と、
   前記プラットフォームサーバによって前記照会メッセージに対する前記クライアントデバイスからの応答を受信する段階であって、前記応答はチェックイン時刻を含む、段階と、
   前記プラットフォームサーバによって前記応答を前記ホテルデータ処理システムに送信する段階と
   を備える、請求項６に記載の方法。
9. 前記１つ又は複数の機能オプションは、予約タイプ変更、チェックイン、チェックアウト、決済、及びサービスオペレーション完了通知機能オプションのうち１つ又は複数を含む、請求項６に記載の方法。
10. 前記１つ又は複数の機能オプションは、ビジネス領収書発行、現在の支出額の照会、接客サービス、客室選択、解錠、及びセルフチェックイン機能オプションのうち１つ又は複数を含む、請求項６に記載の方法。
11. プロセッサと、
    コンピュータ実行可能命令を内部に格納した非一時的メモリと
    を備える装置であって、
    前記コンピュータ実行可能命令は、前記プロセッサによって実行された場合、前記装置に複数のオペレーションを行わせ、
    前記複数のオペレーションは、
    ホテルデータオブジェクト情報をクライアントデバイスに提供するオペレーションであって、前記ホテルデータオブジェクト情報は、クレジットタイプ属性などの複数のタイプ属性を含む、オペレーションと、
    前記クライアントデバイスからの予約リクエストを受信するオペレーションであって、前記予約リクエストは前記クレジットタイプ属性の識別情報を含む、オペレーションと、
    前記予約リクエストに応答して、前記クライアントデバイスと関連付けられたユーザのクレジット認証を確認するオペレーションと、
    前記クレジット認証を確認した後にクレジットタイプ予約を作成するオペレーションと、
    前記クレジットタイプ予約と関連付けられた予約情報をホテルと関連付けられたホテルデータ処理システムに送信するオペレーションと、
    前記ホテルデータ処理システムからのチェックアウトリクエストを受信するオペレーションと、
    前記チェックアウトリクエストを受信した後に、前記予約情報と関連付けられたリソースを前記ユーザと関連付けられた支払いアカウントから前記ホテルデータ処理システムに移動させるオペレーションと
    である、装置。
12. 前記クレジットタイプ予約はクレジットステイ予約を含む、請求項１１に記載の装置。
13. ユーザのクレジット認証を確認するオペレーションは、ユーザのクレジットレベル、クレジット限度額、未決済予約数、又はこれらの組合せを確認するオペレーションを有する、請求項１１又は１２に記載の装置。
14. 前記装置及びホテルデータ処理システムは、直接接続及び共有インタフェースを介して通信する、請求項１１から１３のいずれか一項に記載の装置。
15. 前記複数のオペレーションはさらに、前記ユーザの予約ステータスを前記ホテルデータ処理システムと同期させるオペレーションを含む、請求項１１から１４のいずれか一項に記載の装置。
16. 前記複数のオペレーションはさらに、前記ホテルデータ処理システム又は前記クライアントデバイスによって実行可能な１つ又は複数の機能オプションを提供するオペレーションを含む、請求項１１から１５のいずれか一項に記載の装置。
17. 前記１つ又は複数の機能オプションは、前記ホテルデータ処理システムが予約をキャンセルすることを可能にする機能を含み、前記複数のオペレーションはさらに、前記クレジットタイプ予約をキャンセルするオペレーションを含む、請求項１６に記載の装置。
18. 前記１つ又は複数の機能オプションは、前記ホテルデータ処理システムが前記ユーザのチェックイン時刻を確認することを可能にする機能を含み、前記複数のオペレーションはさらに、
    前記ホテルデータ処理システムからの到着時刻確認リクエストを受信するオペレーションと、
    前記クライアントデバイスに照会メッセージを送信するオペレーションと、
    前記照会メッセージに対する前記クライアントデバイスからの応答を受信するオペレーションであって、前記応答はチェックイン時刻を含む、オペレーションと、
    前記応答を前記ホテルデータ処理システムに送信するオペレーションと
    を含む、請求項１６に記載の装置。
19. 前記１つ又は複数の機能オプションは、予約タイプ変更、チェックイン、チェックアウト、決済、及びサービスオペレーション完了通知機能オプションのうち１つ又は複数を含む、請求項１６に記載の装置。
20. 前記１つ又は複数の機能オプションは、ビジネス領収書発行、現在の支出額の照会、接客サービス、客室選択、解錠、及びセルフチェックイン機能オプションのうち１つ又は複数を含む、請求項１６に記載の装置。