特許 7162587 注文情報処理方法、装置およびシステム

(19)【発行国】日本国特許庁(JP)

(12)【公報種別】特許公報(B2)

(11)【特許番号】

(24)【登録日】2022-10-20

(45)【発行日】2022-10-28

(54)【発明の名称】注文情報処理方法、装置およびシステム

(51)【国際特許分類】

   G06Q 20/40 20120101AFI20221021BHJP

【ＦＩ】

G06Q20/40

【請求項の数】 17

(21)【出願番号】P 2019500248

(86)(22)【出願日】2017-06-26

(65)【公表番号】

(43)【公表日】2019-07-18

(86)【国際出願番号】 CN2017089975

(87)【国際公開番号】W WO2018006716

(87)【国際公開日】2018-01-11

【審査請求日】2020-06-10

(31)【優先権主張番号】201610529876.4

(32)【優先日】2016-07-06

(33)【優先権主張国・地域又は機関】CN

【前置審査】

(73)【特許権者】

【識別番号】510330264

【氏名又は名称】アリババ・グループ・ホールディング・リミテッド

【氏名又は名称原語表記】ＡＬＩＢＡＢＡ ＧＲＯＵＰ ＨＯＬＤＩＮＧ ＬＩＭＩＴＥＤ

(74)【代理人】

【識別番号】110001243

【氏名又は名称】弁理士法人谷・阿部特許事務所

(72)【発明者】

【氏名】リー シャオホワ

(72)【発明者】

【氏名】フー グアンホワ

(72)【発明者】

【氏名】ホアン ユージョウ

(72)【発明者】

【氏名】リアン ボー

(72)【発明者】

【氏名】ワン リエン

(72)【発明者】

【氏名】ルオ ジアンウェイ

(72)【発明者】

【氏名】ユエン チャオ

(72)【発明者】

【氏名】ヤン シューチン

【審査官】阿部 潤

(56)【参考文献】

【文献】特開２００３－０８５４７０（ＪＰ，Ａ）

【文献】特開２００３－３３７９１６（ＪＰ，Ａ）

【文献】特開２００１－００５８８３（ＪＰ，Ａ）

(58)【調査した分野】(Int.Cl.，ＤＢ名)

Ｇ０６Ｑ １０／００ － ９９／００

(57)【特許請求の範囲】

【請求項1】

注文情報を処理するためのシステムであって、
第１のユーザデータ処理システムとサーバとを備え、
前記第１のユーザデータ処理システムが、第２のユーザの識別情報を判定し、前記第２のユーザのサービス要求を処理するときに前記第２のユーザの前記識別情報を前記サーバに提出するように構成され、前記第２のユーザは、オンライン決済アカウントを有し、
前記サーバが、前記第２のユーザに関する与信権限検証を実行し、前記与信権限検証に通過した場合にサービス注文を生成するように前記第１のユーザデータ処理システムに通知し、前記第１のユーザデータ処理システムによって送信された前記サービス注文に対応する消費資源情報を受信するのに応じて、前記消費資源情報および前記第２のユーザに関連する決済口座情報にしたがって前記サービス注文を終了するように構成され、
前記第２のユーザに関する前記与信権限検証を実行することは、前記オンライン決済アカウントに関連付けられた信用格付けに基づいて、前記第２のユーザが前記サービス注文に関連付けられたサービスを提供される前に手付金を支払う必要があるかどうかを判定し、前記第２のユーザに関する前記与信権限検証を実行する前に、前記第２のユーザが契約ユーザに属するかどうかを判定し、未だに署名されていない場合に契約に署名するように前記第２のユーザに促すことを含むことを特徴とするシステム。

【請求項2】

注文情報を処理するための方法であって、
第１のユーザデータ処理システムにより、第２のユーザのサービス要求を処理するときに前記第２のユーザの識別情報を判定することであって、前記第２のユーザは、オンライン決済アカウントを有する、ことと、
前記第２のユーザの前記識別情報をサーバに送信して前記サーバが前記第２のユーザに関する与信権限検証を実行することを可能にすることと、
成功した検証メッセージを受信した後に、サービス注文を生成して前記サーバに前記サービス注文を提出することと、
前記サービス注文の消費資源情報を前記サーバに送信して前記サーバが前記消費資源情報および前記第２のユーザに関連する決済口座情報にしたがって前記サービス注文を終了することを可能にすることと
を備え、前記第２のユーザに関する前記与信権限検証を実行することは、前記オンライン決済アカウントに関連付けられた信用格付けに基づいて、前記第２のユーザが前記サービス注文に関連付けられたサービスを提供される前に手付金を支払う必要があるかどうかを判定し、前記第２のユーザに関する前記与信権限検証を実行する前に、前記第２のユーザが契約ユーザに属するかどうかを判定し、未だに署名されていない場合に契約に署名するように前記第２のユーザに促すことを含むことを特徴とする方法。

【請求項3】

前記第２のユーザの前記識別情報を判定することが、前記第２のユーザの識別文書情報を収集することを含み、前記第２のユーザの前記識別情報を前記サーバに送信することが、前記第２のユーザの前記識別文書情報を前記サーバに送信し、前記サーバが、前記識別文書情報に基づいて前記サーバに関連する決済プラットフォームにおいて前記第２のユーザによって開設された決済口座の情報を判定し、前記決済口座の前記情報に基づいて前記第２のユーザに関する前記与信権限検証を実行することを含むことを特徴とする請求項２に記載の方法。

【請求項4】

前記第２のユーザの前記識別情報を判定することが、前記サーバに関連する決済プラットフォームにおいて前記第２のユーザによって開設された決済口座の情報を取得することを含み、前記第２のユーザの前記識別情報を前記サーバに送信することが、前記サーバが前記決済口座の前記情報に基づいて前記第２のユーザに関する前記与信権限検証を実行するように前記サーバに前記決済口座の前記情報を送信することを含むことを特徴とする請求項２に記載の方法。

【請求項5】

前記サーバに関連する前記決済プラットフォームにおいて前記第２のユーザによって開設された前記決済口座の前記情報を取得することが、前記サーバに関連する前記決済プラットフォームにおいて前記第２のユーザによって開設された前記決済口座の前記情報、前記第２のユーザの端末装置にインストールされた決済プラットフォームクライアントによって予め提供されている第１のグラフィックコード情報、および前記決済プラットフォームクライアントと前記サーバとの間に存在する関連関係を取得することを含むことを特徴とする請求項４に記載の方法。

【請求項6】

前記第２のユーザの前記識別情報を前記サーバに送信するとき、推定消費資源情報を判定することと、前記サーバが前記推定消費資源情報に基づいて前記第２のユーザに関する前記与信権限検証を実行するように、前記第２のユーザの前記識別情報が前記サーバに送信されたときに前記推定消費資源情報を前記サーバに送信することとをさらに備えることを特徴とする請求項２から５のうちいずれか一項に記載の方法。

【請求項7】

前記第１のユーザデータ処理システムが、ホテルデータ処理システムを備え、前記サービス注文が、ホテルサービス注文を含むことを特徴とする請求項２から５のうちいずれか一項に記載の方法。

【請求項8】

注文情報を処理するための方法であって、
サーバにより、第２のユーザの識別情報を受信することであって、前記第２のユーザは、オンライン決済アカウントを有する、ことと、
前記第２のユーザに関する与信権限検証を実行することと、
前記与信権限検証に通過した場合に前記与信権限検証に通過したことを示すメッセージを第１のユーザデータ処理システムに返信して前記第１のユーザデータ処理システムにサービス注文を生成させることと、
前記第１のユーザデータ処理システムによって提出された前記サービス注文の消費資源情報を受信し、前記消費資源情報および前記第２のユーザに関連する決済口座情報にしたがって前記サービス注文を終了することと
を備え、前記第２のユーザに関する前記与信権限検証を実行することは、前記オンライン決済アカウントに関連付けられた信用格付けに基づいて、前記第２のユーザが前記サービス注文に関連付けられたサービスを提供される前に手付金を支払う必要があるかどうかを判定し、前記第２のユーザに関する前記与信権限検証を実行する前に、前記第２のユーザが契約ユーザに属するかどうかを判定し、未だに署名されていない場合に契約に署名するように前記第２のユーザに促すことを含むことを特徴とする方法。

【請求項9】

前記第２のユーザの前記識別情報を受信することが、前記第１のユーザデータ処理システムによって送信された前記第２のユーザの識別文書情報を受信することを含み、前記第２のユーザに関する前記与信権限検証を実行することが、前記識別文書情報にしたがって前記サーバに関連する決済プラットフォームにおいて前記第２のユーザによって開設された前記決済口座情報を判定することと、前記決済口座情報に基づいて前記第２のユーザに関する前記与信権限検証を実行することとを含むことを特徴とする請求項８に記載の方法。

【請求項10】

前記第２のユーザの前記識別情報を受信することが、前記第１のユーザデータ処理システムから前記サーバに関連する決済プラットフォームにおいて前記第２のユーザによって開設された前記決済口座情報を受信することを含み、前記第２のユーザに関する前記与信権限検証を実行することが、前記決済口座情報に基づいて前記第２のユーザに関する前記与信権限検証を実行することを含むことを特徴とする請求項８に記載の方法。

【請求項11】

前記第１のユーザデータ処理システムによって送信された前記消費資源情報が、推定消費資源情報をさらに含み、前記第２のユーザに関する前記与信権限検証を実行することが、
前記第２のユーザの与信限度情報を判定することと、
前記与信限度情報が前記推定消費資源情報よりも高いかどうかを判定し、判定結果に基づいて前記与信権限検証に通過したかどうかを判定することと
を含むことを特徴とする請求項８に記載の方法。

【請求項12】

前記第１のユーザデータ処理システムによって送信された前記サービス注文の情報を受信したとき、第１のユーザに関連する回収口座情報を判定することと、
決済注文を生成するために、前記判定された前記第１のユーザの回収口座情報、前記第２のユーザの前記決済口座情報、および前記サービス注文をともに結合することと
をさらに備え、前記消費資源情報および前記第２のユーザに関連する前記決済口座情報にしたがって前記サービス注文を終了することが、
前記サービス注文に関連する決済注文を判定することと、
前記消費資源情報および前記決済注文に記録された情報に基づいて決済注文を生成することと、
前記決済注文にしたがって前記第２のユーザの決済口座から前記第１のユーザの回収口座に前記消費資源情報を割り当てることと
を含むことを特徴とする請求項８に記載の方法。

【請求項13】

前記第２のユーザのクライアントへの前記消費資源情報の転送に関する通知メッセージを提供することをさらに備えることを特徴とする請求項１２に記載の方法。

【請求項14】

前記第２のユーザの前記受信された識別情報が、前記第２のユーザのコンタクト情報を含み、前記契約に署名するように前記第２のユーザに促すことが、
前記コンタクト情報を用いて前記第２のユーザに契約署名ページにジャンプするためのリンクの情報を提供することと、
前記第２のユーザのクライアントによって送信されたユーザ動作情報を受信することによって契約署名動作を完了することと
を含むことを特徴とする請求項８に記載の方法。

【請求項15】

前記契約に署名するように前記第２のユーザに促すことが、前記第２のユーザが前記契約に署名していないことを示す促進情報を前記第１のユーザデータ処理システムに提供することと、前記第２のユーザが前記契約に署名することに同意した後に第１のユーザの動作情報が動作の選択肢を介して受信されるように、契約署名の動作の前記選択肢を実行し、契約署名動作を完了することとを含むことを特徴とする請求項８に記載の方法。

【請求項16】

第１のユーザデータ処理システムに適用される注文情報を処理するための装置であって、
第２のユーザのサービス要求を処理するときに前記第２のユーザの識別情報を判定するために使用される識別情報判定ユニットであって、前記第２のユーザは、オンライン決済アカウントを有する、ユニットと、
前記第２のユーザの前記識別情報をサーバに提出して前記サーバが前記第２のユーザに関する与信権限検証を実行することを可能にするために使用される情報提出ユニットと、
サービス注文を生成して成功した検証メッセージを受信した後に前記サービス注文を前記サーバに提出するために使用される注文生成ユニットと、
前記サービス注文の消費資源情報を前記サーバに提出して前記サーバが前記消費資源情報および前記第２のユーザに関連する決済口座情報にしたがって前記サービス注文を終了することを可能にするために使用される消費資源情報提出ユニットと
を備え、前記第２のユーザに関する前記与信権限検証を実行することは、前記オンライン決済アカウントに関連付けられた信用格付けに基づいて、前記第２のユーザが前記サービス注文に関連付けられたサービスを提供される前に手付金を支払う必要があるかどうかを判定し、前記第２のユーザに関する前記与信権限検証を実行する前に、前記第２のユーザが契約ユーザに属するかどうかを判定し、未だに署名されていない場合に契約に署名するように前記第２のユーザに促すことを含むことを特徴とする装置。

【請求項17】

サーバに適用される注文情報を処理するための装置であって、
第２のユーザの識別情報を受信するために使用される第１の情報受信ユニットであって、前記第２のユーザは、オンライン決済アカウントを有する、ユニットと、
前記第２のユーザに関する与信権限検証を実行するために使用される第１の検証ユニットと、
前記与信権限検証に通過した場合に前記与信権限検証に通過したことを示すメッセージを第１のユーザデータ処理システムに返信して前記第１のユーザデータ処理システムにサービス注文を生成させるために使用される第１の情報返信ユニットと、
前記第１のユーザデータ処理システムによって提出された前記サービス注文の消費資源情報を受信し、前記消費資源情報および前記第２のユーザに関連する決済口座情報にしたがって前記サービス注文を終了するために使用される第１の注文終了ユニットと
を備え、前記第２のユーザに関する前記与信権限検証を実行することは、前記オンライン決済アカウントに関連付けられた信用格付けに基づいて、前記第２のユーザが前記サービス注文に関連付けられたサービスを提供される前に手付金を支払う必要があるかどうかを判定し、前記第２のユーザに関する前記与信権限検証を実行する前に、前記第２のユーザが契約ユーザに属するかどうかを判定し、未だに署名されていない場合に契約に署名するように前記第２のユーザに促すことを含むことを特徴とする装置。

【発明の詳細な説明】

【技術分野】

【0001】

本出願は、注文情報処理の技術分野に関し、特に注文情報処理方法、装置およびシステムに関する。

【背景技術】

【0002】

電子商取引プラットフォームおよびオンライン決済サービスの継続的な拡大に伴い、オフラインからオフライン（Ｏ２Ｏ）市場の重要性が徐々に現れている。「住宅」と「交通」は、「衣料品、食品、住宅、および交通」において非常に重要な要素であり、旅行サービスやレンタカーサービスの質の追求もまた、新たなレベルにまで上昇している。この状況において、今後のホテル業界およびレンタカー業界は、消費者の期待に応え、産業の競争力を強化するために、技術機器、マーケティングモデル、運営効率およびサービスコンセプトなどの面で新しいレベルにアップグレードされる必要がある。

【0003】

ホテル業界を例にとると、従来の「オンライン予約およびオフラインチェックイン」のサービスには、少なくとも以下の問題がある：まず、支払いが便利ではない。現在、従来の予約方法およびオンライン予約方法では、ユーザは、現金、銀行カード事前承認、またはオンライン決済ツールを使用して、室料よりも多くの特定のデポジットを支払う必要がある。その手順は非常に面倒であり、ユーザの資金を浪費する。さらに、ホテルの地理的位置およびネットワーク信号の不確実性のため、ユーザは、オンライン決済ツールがホテルで使用される場合、オンライン決済ツールを使用することができない。この問題はまた、Ｏ２Ｏで遭遇する顕著な問題でもある。他の問題は、ホテルのフロントデスクが非効率的であるということである。フロントデスクでのチェックインおよびチェックアウトの手続は、一般に集中する。クレジットカード／貯蓄カードを使用する既存の方法は非効率的であり、カード待機、ユーザ署名などのプロセスを必要とする。これは、大抵の場合、多数のユーザが待機することにつながり、ホテルに関連する効率の低減およびチェックインの経験の低減をもたらす。

【発明の概要】

【0004】

本出願は、効率を改善することができ且つ現在処理中の第２のユーザがあまりにも長く待機するのを防止することができる注文情報を処理するための方法、装置およびシステムを提供する。

【0005】

本出願は、以下の解決策を提供する。

【0006】

注文情報処理システムは、第１のユーザデータ処理システムとサーバとを含み、第１のユーザデータ処理システムは、第２のユーザの識別情報を判定し、第２のユーザのサービス要求を処理するときに第２のユーザの識別情報をサーバに提出するように構成され、サーバは、第２のユーザに関する与信権限検証を実行し、検証に通過した場合にサービス注文を生成するように第１のユーザデータ処理システムに通知し、第１のユーザデータ処理システムによって提出されたサービス注文に対応する消費資源情報を受信するのに応じて、消費資源情報および第２のユーザに関連する決済口座情報にしたがってサービス注文を終了するように構成されている。

【0007】

注文情報処理方法は、第１のユーザデータ処理システムにより、第２のユーザのサービス要求を処理するときに第２のユーザの識別情報を判定することと、第２のユーザの識別情報をサーバに提出してサーバが第２のユーザに関する与信権限検証を実行することを可能にすることと、成功した検証メッセージを受信した後に、サービス注文を生成してサーバにサービス注文を提出することと、サービス注文の消費資源情報をサーバに提出してサーバが消費資源情報および第２のユーザに関連する決済口座情報にしたがってサービス注文を終了することを可能にすることとを含む。

【0008】

注文情報処理方法は、サーバにより、第２のユーザの識別情報を受信することと、第２のユーザに関する与信権限検証を実行することと、検証に通過した場合に検証に通過したことを示すメッセージを第１のユーザデータ処理システムに返信して第１のユーザデータ処理システムにサービス注文を生成させることと、第１のユーザデータ処理システムによって提出されたサービス注文の消費資源情報を受信することと、消費資源情報および第２のユーザに関連する決済口座情報にしたがってサービス注文を終了することとを含む。

【0009】

注文情報処理方法は、第１のユーザデータ処理システムにより、第２のユーザのサービス要求に応じたサービス注文を生成することと、サービス注文の情報に基づいて第２のグラフィックコードを生成し、第２のユーザに関連する決済口座がログインされたときに第２のユーザのクライアントが第２のグラフィックコードをスキャンし、スキャンされた決済口座情報およびサービス注文情報をサーバに提出し、サーバが決済口座情報にしたがって第２のユーザに関する与信権限検証を実行し、検証に通過した場合に検証に通過したことを示すメッセージを第１のユーザデータ処理システムに返信することと、検証に通過したことを示すメッセージを受信することと、サービス注文の消費資源情報をサーバに提出し、消費資源情報および第２のユーザに関連する決済口座情報にしたがってサービス注文をサーバに終了させることとを含む。

【0010】

注文情報処理方法は、サーバにより、第２のユーザのサービス要求にしたがって第１のユーザデータ処理システムによって生成された、第２のユーザのクライアントによって提出されたサービス注文情報、および第２のユーザの決済口座情報をサーバで受信することと、決済口座情報に基づいて第２のユーザに関する与信権限検証を実行することと、検証に通過した場合に検証に通過したことを示すメッセージを第１のユーザデータ処理システムに返信して第１のユーザデータ処理システムにサービス注文を生成させることと、第１のユーザデータ処理システムによって提出されたサービス注文の消費資源情報を受信するのに応じて、消費資源情報および第２のユーザに関連する決済口座情報にしたがってサービス注文を終了することとを含む。

【0011】

注文情報処理方法は、第２のユーザのクライアントにより、第２のユーザに関連する決済口座がログインされている状態で第１のユーザデータ処理システムによって提供される第２のグラフィックコードであって、第２のユーザのサービス要求にしたがって第１のユーザデータ処理システムによって生成されたサービス注文情報を担持する第２のグラフィックコードを取得することと、第２のユーザに関連する決済口座情報と第２のグラフィックコードにおけるサービス注文情報とをサーバに提出し、サーバが決済口座情報にしたがって第２のユーザに関する与信権限検証を実行し、検証に通過した場合に検証に通過したことを示すメッセージを第１のユーザデータ処理システムに返信することとを含み、サーバが、消費資源情報および第２のユーザに関連する決済口座情報にしたがってサービス注文を終了する。

【0012】

第１のユーザデータ処理システムに適用される注文情報処理装置は、第２のユーザのサービス要求を処理するときに第２のユーザの識別情報を判定するために使用される識別情報判定ユニットと、第２のユーザの識別情報をサーバに提出してサーバが第２のユーザに関する与信権限検証を実行することを可能にするために使用される情報提出ユニットと、サービス注文を生成して成功した検証メッセージを受信した後にサービス注文をサーバに提出するために使用される注文生成ユニットと、サービス注文の消費資源情報をサーバに提出してサーバが消費資源情報および第２のユーザに関連する決済口座情報にしたがってサービス注文を終了することを可能にするために使用される消費資源情報提出ユニットとを含む。

【0013】

サーバに適用される注文情報処理装置は、第２のユーザの識別情報を受信するために使用される第１の情報受信ユニットと、第２のユーザに関する与信権限検証を実行するために使用される第１の検証ユニットと、検証に通過した場合に検証に通過したことを示すメッセージを第１のユーザデータ処理システムに返信して第１のユーザデータ処理システムにサービス注文を生成させるために使用される第１の情報返信ユニットと、第１のユーザデータ処理システムによって提出されたサービス注文の消費資源情報を受信し、消費資源情報および第２のユーザに関連する決済口座情報にしたがってサービス注文を終了するために使用される第１の注文終了ユニットとを含む。

【0014】

第１のユーザデータ処理システムに適用される注文情報処理装置は、第２のユーザのサービス要求にしたがってサービス注文を生成するために使用されるサービス注文生成ユニットと、サービス注文の情報にしたがって第２のグラフィックコードを生成し、第２のユーザのクライアントが第２のユーザに関連する決済口座がログインされている場合に第２のグラフィックコードをスキャンし、スキャンされた決済口座情報およびサービス注文情報をサーバに提出し、サーバが決済口座情報にしたがって第２のユーザに関する与信権限検証を実行し、検証に通過した場合に検証に通過したことを示すメッセージを第１のユーザデータ処理システムに返信するために使用されるグラフィックコード生成ユニットと、検証に通過したことを示すメッセージを受信するために使用されるメッセージ受信ユニットと、サービス注文の消費資源情報をサーバに提出し、サーバに消費資源情報および第２のユーザに関連する決済口座情報にしたがってサービス注文を終了させるために使用される消費資源情報提出ユニットとを含む。

【0015】

サーバに適用される注文情報処理装置は、第２のユーザのサービス要求にしたがって第１のユーザデータ処理システムによって生成された、第２のユーザのクライアントによって提出されたサービス注文情報、および第２のユーザの決済口座情報を受信するために使用される第２の情報受信ユニットと、決済口座情報にしたがって第２のユーザの与信権限検証を実行するために使用される第２の検証ユニットと、検証に通過した場合に検証に通過したことを示すメッセージを第１のユーザデータ処理システムに返信して第１のユーザデータ処理システムにサービス注文を生成させるために使用される第２の情報返信ユニットと、消費資源情報を受信するのに応じて、第１のユーザデータ処理システムによって提出されたサービス注文の消費資源情報および第２のユーザに関連する決済口座情報にしたがってサービス注文を終了するために使用される第２注文終了ユニットとを含む。

【0016】

第２のユーザのクライアントに適用される注文情報処理装置は、第２のユーザに関連する決済口座がログインされている状態で第１のユーザデータ処理システムによって提供される第２のグラフィックコードであって、第２のユーザのサービス要求にしたがって第１のユーザデータ処理システムによって生成されたサービス注文情報を担持する第２のグラフィックコードを取得するために使用されるグラフィックコード取得ユニットと、第２のユーザに関連する決済口座情報および第２のグラフィックコードにおけるサービス注文情報をサーバに提出し、サーバが決済口座情報にしたがって第２のユーザに関する与信権限検証を実行し、検証に通過した場合に検証に通過したことを示すメッセージを第１のユーザデータ処理システムに返信するために使用される情報提出ユニットとを含み、サーバが消費資源情報および第２のユーザに関連する決済口座情報にしたがってサービス注文を終了する。

【0017】

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

【0018】

本出願の実施形態を使用して、第２のユーザのサービス要求を受信すると、第１のユーザデータ処理システムは、第２のユーザの識別情報をサーバに提出する必要があるのみである。サーバは、第２のユーザに関する与信権限検証を実行し、サービス条件が満たされているかどうかを判断することによって判定を行うことができる。満たされている場合、第１のユーザデータ処理システムは、予め設定された方法（例えば、デポジットなしのチェックイン、ホテルから退出するときに部屋の点検がないなど）にしたがって現在の第２のユーザにサービスを提供するように通知される。サービスの終了時に、サーバは、対応する注文のチェックアウト動作を実行する。したがって、デポジットの回収、ホテルからの退出時の確認、デポジットの返却などの作業を行うことを回避することができ、それゆえに効率を向上させる。同時に、（カードの取り出し、カードの読み取り、パスワードの入力、および署名を含む）カードを読み取る消費資源の決済、現金決済（金銭の預かり、金銭の検査、釣銭の持ち出し）などのプロセスの操作がスキップされるため、現在処理中の第２のユーザは、長時間待機することが防止される。

【0019】

明らかに、本出願の製品のいずれかを実装することは、上述した利点の全てが同時に達成されることを必ずしも必要とするものではない。

【0020】

本出願の実施形態または既存の技術における技術的スキームをより明確に説明するため、実施形態で用いられる図面について以下に簡単に説明する。明らかに、以下の説明における図面は、本出願の一部の実施形態のみを表している。当業者は、いかなる創造的な努力もすることなく、これらの図面にしたがって他の図面を得ることができる。

【図面の簡単な説明】

【0021】

【図1】図１は、本出願の実施形態によって提供されるシステムの概略図である。

【図2】図２は、本出願の実施形態によって提供される第１の方法のフローチャートである。

【図3】図３は、本出願の実施形態によって提供される第２の方法のフローチャートである。

【図4】図４は、本出願の実施形態によって提供される第３の方法のフローチャートである。

【図5】図５は、本出願の実施形態によって提供される第４の方法のフローチャートである。

【図6】図６は、本出願の実施形態によって提供される第５の方法のフローチャートである。

【図7】図７は、本出願の実施形態によって提供される第１の装置の概略図である。

【図8】図８は、本出願の実施形態によって提供される第２の装置の概略図である。

【図9】図９は、本出願の実施形態によって提供される第３の装置の概略図である。

【図10】図１０は、本出願の実施形態によって提供される第４の装置の概略図である。

【図11】図１１は、本出願の実施形態によって提供される第５の装置の概略図である。

【発明を実施するための形態】

【0022】

本出願の実施形態における技術的解決策は、本出願の実施形態における図面を参照して以下に明確に且つ完全に記載される。明らかに、記載された実施形態は、本出願の実施形態の単に一部を示しているに過ぎず、全てを示していない。本出願の実施形態に基づいて当業者によって得られる全ての他の実施形態は、本開示の保護の範囲内に入る。

【0023】

本出願の実施形態では、第１のユーザは、商人または販売者とすることができる。このタイプの第１のユーザは、通常、宿泊施設、車両などのサービス資源を提供する方法で、ホテルなどの第２のユーザにサービスを提供する。これに対応して、第２のユーザは、第１のユーザによって提供されるサービス資源を使用することによって対応するサービスを取得する購入者、消費者などである。具体的には、異なるカテゴリの第１のユーザにとって、特定のタイプのサービス資源もまた異なる。例えば、ホテルカテゴリの第１のユーザにとって、特定のサービス資源は、部屋、部屋の施設などを含むことができる。レンタカーカテゴリの第１のユーザにとって、特定のサービス資源は、主に車両を指す。上記用途シナリオでは、第１のユーザは、第２のユーザにサービスを提供するプロセスにおいて特定のサービス資源を第２のユーザに供給する必要があるため、第２のユーザは、対応する使用料を支払う必要がある。第２のユーザが消費のために店舗に行くとき、第１のユーザは、通常、特定のデポジットを請求する必要がある。第２のユーザが店舗を退出すると、部屋の確認や車両の確認などの点検作業が行われる。第２のユーザによってサービス資源を使用する過程において、破損または紛失したサービス資源などの状況が発生したことが発見された場合、第１のユーザは、デポジットの一部または全部を補償として控除することができる。上記状況が発生しない場合、第２のユーザがサービス資源を返却すると、デポジットは第２のユーザに払い戻される。しかしながら、使用料の支払い、デポジットの支払い、点検、デポジットの返却などの動作が全て第１のユーザのフロントデスクで行われると、通常は比較的長い時間がかかり、他のユーザに長時間列をなして待機させる。さらに、デポジットを回収する方法は、第２のユーザに信頼されていないと感じさせ、ユーザの経験は良くない。

【0024】

したがって、本出願の実施形態では、注文の資源情報が例えば第２のユーザによって実際に消費された資金の情報などの消費資源情報を主に指す新規な注文情報処理方法が提供される。この方法では、与信権限が条件を満たす第２のユーザがホテルへのチェックイン時にデポジットを支払うことを免除することができ且つホテルから退出するときに点検や待ち行列から解放されるように、上記用途シナリオにおける資源決済などの動作のプロセスをサポートするために電子商取引プラットフォームが使用可能である。ホテルから退出するとき、プラットフォームのサーバは、注文のための資源決済を直接行う。そのため、第２のユーザは、消費プロセス中にサービスをより効率的に取得することができ、過度の資源占有を回避することができ、信頼されて尊敬されるユーザ経験を得ることができる。説明の便宜上、上記機能は、本出願の実施形態において「クレジット・ステイ」機能と称されることがある。

【0025】

具体的には、現在のオンライン決済ツールの人気に基づいて、全てのユーザは、基本的に、例えば、Ａｌｉｐａｙアカウントなどの自己のオンライン決済アカウントを開設する。したがって、本出願の実施形態は、上記状況に応じて第１のユーザおよび第２のユーザに注文情報処理サービスを提供する。具体的には、第２のユーザが第１のユーザのオフライン店舗に行ってルームチェックインまたはレンタカーなどのサービスに関する手続を行うと、第２のユーザの識別情報が様々な手段を用いて「クレジット・ステイ」などの機能を提供可能なサーバに提供されることができる。サーバは、例えば信用度などの情報がサービス条件を満たしているかどうかなど、予め定められたサービス条件が満たしているかどうかを判定するために第２のユーザに関する与信権限検証を実行することができる。満たしている場合、第１のユーザは、第２のユーザのためにデポジットのないチェックインまたはデポジットのないレンタカーなどを処理するように通知されることができる。換言すれば、サーバは、決済口座を開設して比較的高い信用格付けを有するユーザに対する「信用承認」を提供する。そのため、第２のユーザは、チェックインまたは車の貸借時に第１のユーザに室料、デポジットなどを支払う必要がなく、それゆえに、第２のユーザの資金の過度の占有を回避し、処理中の他のユーザの待機時間を短縮する。店舗から退出するとき、サービス資源は、直接返却されることができる。第１のユーザは、部屋の点検や車の点検などの作業を行う必要がなく、デポジット払い戻しの状況は存在しない。第２のユーザは、店舗から直接退出することができ、本出願の実施形態では、室料などの後払いの自動転送がサーバによって行われることができる。

【0026】

なお、上記説明において記載されたような「ホテル」、「レンタカー」などは、主に本出願の実施形態の具体的な実装を説明するために使用されており、本出願の実施形態の範囲を限定するものと解釈されるべきではないことに留意すべきである。

【0027】

具体的な実装については、以下に詳述する。

【0028】

第１の実施形態
まず、第１の実施形態は、システムの観点から注文情報処理システムを提供する。図１を参照すると、システムは、第１のユーザデータ処理システム１０１およびサーバ１０２を含むことができる。第１のユーザデータ処理システム１０１は、第２のユーザのサービス要求を処理するときに第２のユーザの識別情報を判定し、第２のユーザの識別情報をサーバに提出するように構成されている。サーバ１０２は、第２のユーザに関する与信権限検証を実行し、検証に通過した場合にサービス注文を生成するように第１のユーザデータ処理システム１０１に通知し、消費資源情報の受信に応じて第１のユーザデータ処理システム１０１によって提出されたサービス注文に対応する消費資源情報および第２のユーザに関連する決済口座情報にしたがってサービス注文を終了するように構成されている。

【0029】

実際の用途では、第１のユーザデータ処理システムは、ホテルなどのＰＭＳ（不動産管理システム）システムを指すことができる。サービス注文は、ホテルのサービス注文などを指すことができる。このタイプのシナリオでは、第２のユーザがチェックインするためにホテルに入ると、ホテルのＰＭＳは、第２のユーザの身元認証情報を収集し、サーバ（例えば、Ａｌｉ Ｔｒａｖｅｌプラットフォームのサーバなど）に身元認証情報をアップロードすることができる。第２のユーザの「Ｚｈｉｍａクレジット」および他のデータによれば、サーバは、第２のユーザに関する与信権限検証を実行する。通過した場合、ホテルのＰＭＳシステムは、特別なサービス注文を生成することができ、その特質は、以下のように反映される：第２のユーザは、デポジットを支払う必要がなく、前もって室料を支払う必要がない；オフライン資源は、第２のユーザに直接割り当てられることができ、第２のユーザは、直接チェックインすることができる；第２のユーザがホテルから退出するときに部屋の点検やデポジットの払い戻しなどの操作を行う必要がない；例えば、Ａｌｉ Ｔｒａｖｅｌプラットフォームのサーバは、第２のユーザに関連する口座から関連資源情報をホテルの口座に直接転送することができる。理解されるように、「信用＝富」は、本出願の実施形態において真に具体化される。ホテルから退出する前に第２のユーザによって消費されるものは、自己の信用であり、現実の資金などの資源は、実際には最後にホテルを退出した後にのみ消費される。これはまた、本出願の実施形態とクレジットカード消費との最大の差異でもある。

【0030】

本出願の実施形態の技術的解決策は、より具体的な実装の観点から、以下の実施形態において詳細に説明される。

【0031】

第２の実施形態
第２の実施形態は、第１のユーザデータ処理システムの観点から注文情報を処理するための方法を提供する。図２を参照すると、本方法は、以下のステップを含むことができる。

【0032】

Ｓ２０１：第１のユーザデータ処理システムは、第２のユーザのサービス要求を処理するときに第２のユーザの識別情報を判定する。

【0033】

第１のユーザデータ処理システムは、第１のユーザによって使用される企業管理プラットフォームクライアントとすることができる。このタイプの企業管理プラットフォームクライアントは、「クレジット・ステイ」機能を提供することができるサーバとの協働関係を確立することができる。両当事者の間で、各当事者は、前もって相手方のための標準化されたインターフェースを開くことができ、それゆえに両者間の直接通信を可能にする。あるいは、第１のユーザデータ処理システムはまた、「クレジット・ステイ」機能を提供するサーバによって第１のユーザに提供されてもよい。例えば、「クレジット・ステイ」機能を有するサーバを提供する場合、Ａｌｉ Ｔｒａｖｅｌプラットフォームはまた、Ａｌｉ Ｔｒａｖｅｌを提供する第１のユーザクライアントを提供することもできる。

【0034】

本出願の実施形態では、特定の用途シナリオは、以下とすることができる：第２のユーザが第１のユーザのオフライン店舗に行ってチェックインまたは車をレンタルなどする場合（すなわち、第２のユーザと第１のユーザとの間で行われるものは、オフライン取引である）、第２のユーザは、電子商取引プラットフォーム上で事前予約するのではなく、第１のユーザのオフライン店舗に直接行ってチェックインまたは車のレンタルなどを行う。このとき、第１のユーザデータ処理システムによって受信されるものは、第２のユーザのサービス要求である。あるいは、第２のユーザはまた、前もって他の電子商取引プラットフォームから予約を行うこともできる（本明細書における「他」は、以下として言及される：本出願の実施形態における「クレジット・ステイ」サービスがＡｌｉ ＴｒａｖｅｌやＡｌｉｐａｙなどのＴａｏシリーズプラットフォームによって提供される場合、旅行やレンタカーのためのオンライン予約サービスを提供する他の販売プラットフォームは、「他の電子商取引プラットフォーム」と称されるが、未だ決済を行っていない）。上記の様々なタイプの状況に対して、本出願の実施形態によって提供される解決策は、非常に効率的な処理を達成するために使用されることができ、それにより、ユーザの長い待機時間を回避する。

【0035】

換言すれば、第２のユーザがオフライン取引を処理するために第１のユーザのオフライン店舗に行くとき、または第２のユーザがチェックインするために他の電子商取引プラットフォームを介して予約を行って第１のユーザのオフライン店舗に行くとき、第１のユーザデータ処理システムは、第２のユーザの識別情報を判定することができる。そのような情報は、後続ステップにおいてサーバに提供され、サーバは、「クレジット・ステイ」が実行可能であるかどうかを判定する。

【0036】

サーバがどの特定の決済口座が対応するかを識別できる限り、第２のユーザの識別情報の複数の特定の形態が存在してもよい。例えば、１つの実装では、第１のユーザは、通常、第２のユーザが自己の識別文書を提示し且つ国内法および規則などにしたがって登録を行う必要があるため、第２のユーザがチェックインするために第１のユーザのオフライン店舗に行くとき、第１のユーザは、例えば、識別番号、名称などの第２のユーザの識別文書の情報を収集することができる。第２のユーザが決済プラットフォームで自己の決済口座を開設すると、決済プラットフォームはまた、通常、第２のユーザに識別文書の情報の入力を要求してその記録を行うことを含む、第２のユーザに対して実名認証を実行する。換言すれば、決済プラットフォームにおいて決済口座を開設する第２のユーザは、実際には、第２のユーザの実名識別文書の情報を決済プラットフォームに記録する。したがって、第１のユーザデータ処理システムは、第２のユーザの識別文書の情報を収集し、第２のユーザの識別情報としてサーバに情報を提出することができる。ユーザが決済口座を開設するサーバおよび決済プラットフォームは、関連関係を有することができる。例えば、Ａｌｉ ＴｒａｖｅｌプラットフォームおよびＡｌｉｐａｙプラットフォームは、それらの間の関連関係を有するなどである。このようにして、サーバは、記憶された実名認証情報にしたがって識別文書の情報に対応する決済口座の情報を判定することができる。さらに、サーバは、通常、決済口座の情報に関連付けられたクレジット情報などを記録するため、決済口座の情報に基づいて、第２のユーザが予め設定されたサービス条件を満たすかどうかに関して判定を行う。

【0037】

上記方法の便宜性は、第２のユーザの識別文書の情報の収集および第１のユーザによる情報の登録が法的手続に属することから、第１のユーザデータ処理システムが、本出願の実施形態によって提供される解決策が使用されるとき、第２のユーザの識別文書の収集された情報をサーバに提出する必要があるのみであるということである。したがって、第２のユーザのクライアントは、過度に追加動作を余儀なくされることが防止され、処理効率を改善するのに有益である。

【0038】

さらに、他の実装方法も実装されることができる。例えば、１つの方法は、第１のユーザデータ処理システムが第２のユーザに関連する決済口座情報を取得した後に、第２のユーザの情報としてサーバに決済口座情報を提出することができるものとすることができる。決済口座情報は、第２のユーザの与信権限が第２のユーザに関連する決済口座情報にしたがってサービス条件を満たすかどうかをサーバが直接判定することができるように、使用されることができるサーバに関連付けられた決済プラットフォームにおいて第２のユーザによって登録された決済口座の情報である。第１のユーザデータ処理システムが第２のユーザに関連する決済口座を取得するいくつかの特定の実装方法が存在することができる。例えば、第２のユーザは、口頭による説明によって第１のユーザのスタッフに決済口座に含まれる文字を告げることができる。このようにして、第１のユーザのスタッフは、キーボード入力によって第２のユーザの決済口座の文字を入力することができる。あるいは、第２のユーザは、通常、携帯電話などの携帯端末装置を携帯しているため、決済プラットフォームクライアントプログラムのユーザインターフェースは、通常、決済プラットフォームクライアントプログラムが装置にインストールされる場合、決済口座情報に関連する第１のグラフィックコード（バーコード、２次元コードなど）を提供して担持する。したがって、この場合、第２のユーザはまた、携帯端末装置内の決済プラットフォームクライアントプログラム（例えば、Ａｌｉｐａｙ）を開き、インターフェースから「決済」などの選択肢を選択することができ、それゆえに、第２のユーザに関連する決済口座情報を担持する第１のグラフィックコードを表示する。同時に、第１のユーザの端末装置は、第１のユーザのスタッフがコードスキャン装置を使用して第２のユーザ端末装置のインターフェースに表示された第１のグラフィックコードをスキャンすることができるように、コードスキャナなどのコードスキャン装置に接続されることができ、それにより、第２のユーザに関連する決済口座情報を取得する。

【0039】

上記方法により、第１のユーザデータ処理システムは、入力またはスキャンなどによって第２のユーザに関連する決済口座情報を取得する必要があるが、サーバは、第２のユーザの識別情報に基づいて決済口座情報を最初に判定する必要なく、直接使用可能な第２のユーザに関連する決済口座情報に基づいて第２のユーザがサービス条件を満たすかどうかを直接判定することができる。したがって、サーバの処理効率を向上させることができ、全体として処理のプロセス全体の処理効率を向上させることができる。

【0040】

Ｓ２０２：サーバが第２のユーザに関する与信権限検証を実行するように、第２のユーザの識別情報がサーバに送信される。

【0041】

第２のユーザの識別情報がサーバに提出された後、サーバは、第２のユーザの与信権限が予め設定されたサービス条件を満たすかどうかを判定することができる。特定のサービス条件は、実際のサービス要件にしたがって判定されてもよい。例えば、第２のユーザの信用格付け、信用限度の大きさ、未決済取引注文の数などに制限を加えることができる。このように、サーバは、サービス条件に含まれる様々なパラメータに基づいて、現在の第２のユーザに対応するパラメータ値を具体的に判定し、条件に定義された閾値とそのパラメータ値を比較し、それにより、第２のユーザがサービス条件を満たすかどうかを判定する。例えば、Ａｌｉｐａｙプラットフォームの下で、第２のユーザのＡｌｉｐａｙ口座に関連する「Ｚｈｉｍａクレジット」情報が取得されることができ、「ａｎｔ ｆｌｏｗｅｒ ｇａｒｄｅｎ」によって第２のユーザに提供される割り当て情報もまた取得されることができる。さらに、Ａｌｉｐａｙ口座などに関連する未決済注文の数もまた判定されることができる。現在の第２のユーザがサービス条件を満たすかどうかを判定するために上記要因が使用されることができる。

【0042】

さらに、第１のユーザデータ処理システムは、（例えば、サービス資源の単価およびチェックアウト予定日などにしたがって計算されることができる）予測消費資源情報をさらに提供し、推定消費資源情報をサーバに提供することができる。そのため、サーバは、最初に第２のユーザの信用度を判定することができる。条件が満たされている場合、第２のユーザの与信限度情報もまた判定されることができ、ユーザの与信限度が現在の予測消費資源情報よりも大きいかどうかが判定される。より大きい場合、条件は満たされる。

【0043】

第２のユーザがサービス条件を満たすと判定したのに応じて、第１のユーザデータ処理システムは、検証に通過したことを示すメッセージを返信することができる。例えば、第１のユーザには、通知メッセージなどにより、現在の第２のユーザがデポジットのないチェックインまたはデポジットのないレンタカーなどを処理するように通知されることができる。

【0044】

Ｓ２０３：検証に通過したことを示すメッセージが受信された後、サービス注文が生成されてサーバに送信される。

【0045】

検証に通過したことを示すメッセージを第１のユーザデータ処理システムが受信した後、第２のユーザは、第１のユーザによって割り当てられたサービス資源を直接使用することができ、室料やデポジットの支払い、検査の実行、デポジットの払い戻しなどの作業を行う必要がなく、それゆえに、第２のユーザの資金の追加占有を回避し、処理効率を向上させ、他の第２のユーザが長時間列をなして待機することを防止する。換言すれば、第２のユーザがチェックインするとき、いかなる料金の支払いも必要ない。第１のユーザは、自己のために部屋を直接割り当て、第２のユーザは、直接チェックインすることができる。

【0046】

さらに、検証に通過したことを示すメッセージをサーバから受信した後、第１のユーザデータ処理システムは、サービス注文、すなわち第１のユーザシステム内の注文をさらに生成することができる。サービス注文は、第１の注文の注文識別子、第１のユーザの識別情報、第２のユーザの識別情報などを含むことができる。このようにして、サービス注文の情報もまた、サーバがサービス注文に関する他の処理動作を実行するようにサーバに提供されることができる。

【0047】

Ｓ２０４：サーバが消費資源情報および第２のユーザに関連する決済口座情報にしたがってサービス注文を終了するように、サービス注文の消費資源情報がサーバに送信される。

【0048】

実際の用途では、クレジット消費サービスを実装するために第２のユーザに関する「信用承認」を行うことに加えて、サーバはまた、サービス資源の使用中に生成される（例えば、室料の決済などの）消費される資源の決済を完了するために第２のユーザを支援することができる。換言すれば、上述したように、本出願の実施形態では、第２のユーザが消費のために第１のユーザのオフライン店舗に行くとき、資源使用料は未払いである。効率をさらに向上させ、現金支払い、カード読み取りなどによる決済を行う第２のユーザによって引き起こされる過度な時間占有を回避するために、サーバはまた、決済動作を実行する、すなわち、第２のユーザの口座から第１のユーザの口座への関連消費資源を直接転送することもできる。この動作は、第２のユーザが、現金支払い、カード読み取り、または他の第三者決済ツールの使用などの操作を実行する必要なく、オンラインで直接完了することができる。

【0049】

特定の実装では、サーバは、サービス注文を受信した後に第２のユーザに関連する決済口座情報を判定することができ、第１のユーザに関連する決済口座情報を判定することもできる。サーバは、第１のユーザの回収口座、第２のユーザの決済口座情報およびサービス注文の情報をさらに結合することができ、決済注文を生成する。決済注文は、決済プラットフォーム内の注文に属し、第２のユーザが後の段階でサービス資源の実際の使用料を支払ったときに、第２のユーザの決済口座から第１のユーザの回収口座に直接転送するために使用される。決済注文は、第１のユーザデータ処理システムには不可視とすることができ、ユーザ決済システムのみが特定の資源情報の処理を実行する。

【0050】

具体的には、サービス処理が終了した後、第１のユーザデータ処理システムは、第２のユーザによるサービス資源の実際の使用日数にしたがって実際の消費資源情報をさらに判定することができ、実際の消費資源情報およびサービス注文の注文ステータスをサーバに送信することができる。そのため、サーバは、サービス注文の注文識別子にしたがって対応する決済注文を判定し、決済注文に記録された情報および実際の消費資源情報にしたがって資金を割り当てる。特定の実装では、消費された資源の実際の割り当て動作を実現するために、決済注文が生成されてもよい。決済注文は、決済動作を実行するための注文である。決済注文によれば、対応する実際の消費資源情報は、第２のユーザの決済口座から第１のユーザの回収口座に割り当てられる。明らかに、そのような転送注文は、既存の決済システムの処理プロセスのあまりにも多い変更を回避するために、Ａｌｉｐａｙなどの既存の決済システムにおける従来の処理方法を満たすために通常使用される。換言すれば、そのような転送注文が他の決済システムにおいて生成される必要はなく、資源は、決済注文に記録された情報に基づいて直接転送されることができる。

【0051】

実際の用途では、第１のユーザデータ処理システムによって生成されるサービス注文は、サービス資源割り当て結果情報、推定消費量情報、サービス開始時間、および推定サービス終了時間などをさらに含むことができる。このようにして、サーバはまた、これらの情報片を記録することができ、第２のユーザは、自己の決済口座などにログインすることによって照会を行うことができる。さらに、この情報の部分はまた、第２のユーザがサービス条件を満たすかどうかを判定するためにも使用されてもよい。例えば、第２のユーザの与信限度が、推定消費資源情報よりも大きいかどうかなどについての判定が行われてもよい。

【0052】

要約すると、本出願の実施形態では、第２のユーザのサービス要求を受信するのに応じて、第１のユーザデータ処理システムは、第２のユーザの識別情報をサーバに提出する必要があるのみである。サーバは、第２のユーザに関する与信権限検証を実行し、サービス条件が満たされているかどうかを判断することによって判定を行うことができる。満たされている場合、第１のユーザデータ処理システムは、予め設定された方法（例えば、デポジットなしのチェックイン、ホテルから退出するときに部屋の点検がないなど）にしたがって現在の第２のユーザにサービスを提供するように通知される。サービスの終了時に、サーバは、対応する注文のチェックアウト動作を実行する。したがって、デポジットの回収、ホテルからの退出時の確認、デポジットの返却などの作業を行うことを回避することができ、それゆえに効率を向上させる。同時に、（カードの取り出し、カードの読み取り、パスワードの入力、および署名を含む）カードを読み取る消費資源の決済、現金決済（金銭の預かり、金銭の検査、釣銭の持ち出し）などのプロセスの操作がスキップされるため、現在処理中の第２のユーザは、長時間待機することが防止される。

【0053】

第３の実施形態
第３の実施形態は、第２の実施形態に対応し、サーバの観点から説明される。図３を参照すると、第３の実施形態は、以下のステップを含むことができる注文情報を処理するための方法を提供する。

【0054】

Ｓ３０１：サーバは、第２のユーザの識別情報を受信する。

【0055】

識別情報は、第２のユーザのサービス要求を処理するときに、第１のユーザデータ処理システムによって提出されることができる。

【0056】

本明細書におけるサーバは、「クレジット・ステイ」サービスのサポートを提供するサーバを指す。例えば、Ａｌｉ Ｔｒａｖｅｌ、Ａｌｉｐａｙなどのシステムが「クレジット・ステイ」サービスのサポートを提供する場合、本明細書におけるサーバは、Ａｌｉ Ｔｒａｖｅｌのサーバ、Ａｌｉｐａｙのサーバなどを指すことができる。

【0057】

Ｓ３０２：与信権限検証が第２のユーザに対して実行される。

【0058】

Ｓ３０３：検証に通過した場合、検証に通過したことを示すメッセージが第１のユーザデータ処理システムに返信され、第１のユーザデータ処理システムがサービス注文を生成することを可能にする。

【0059】

Ｓ３０４：第１のユーザデータ処理システムによって送信された消費資源情報が受信され、消費資源情報および第２のユーザに関連する決済口座情報にしたがってサービス注文が終了される。

【0060】

第１のユーザデータ処理システムによって送信された受信識別情報は、第２のユーザの識別文書情報を含むことができる。このとき、サーバは、識別文書情報にしたがってサーバに関連する決済プラットフォームに開設された第２のユーザの決済口座の情報を判定することができ、決済口座の情報にしたがって第２のユーザの与信権限が予め設定されたサービス条件を満たすかどうかを判定することができる。第１のユーザデータ処理システムによって送信された受信識別情報が第２のユーザに関連する決済口座情報である場合、第２のユーザが予め設定されたサービス条件を満たすかどうかの判定は、決済口座情報に基づいて直接行うことができる。さらに、特定の実装では、第１のユーザデータ処理システムによって送信される情報は、推定消費資源情報をさらに含む。このとき、第２のユーザの与信限度情報もまた判定されることができ、与信限度情報が推定消費資源情報よりも高いかどうかが判定される。その判定結果に基づいて、検証に通過したかどうかの判定が行われる。

【0061】

サービス注文の終了は、主に、サービス注文のために消費される資源の決済などの動作を実行することを含むことができ、動作は、サーバによって完了することができる。具体的には、サービス注文の決済処理を行うために、サーバは、第１のユーザデータ処理システムによって送信されたサービス注文情報をさらに受信することができる。そして、サーバは、第１のユーザの識別情報にしたがって第１のユーザの回収口座の情報を判定し、決済注文を生成するために、判定された第１のユーザの回収口座の情報、第２のユーザの決済口座の情報、およびサービス注文を結合することができる。

【0062】

第２のユーザがホテルから退出するかまたは車両を返却する手順を処理するとき、第１のユーザデータ処理システムによって送信された実際の消費資源情報および対応するサービス注文識別子は、第２のユーザによる消費が終了した後に受信されることができる。サーバは、サービス注文の注文識別子にしたがって対応する決済注文を判定した後に、決済注文に記録された情報および実際の消費資源情報にしたがって転送注文を生成することができる。サーバは、第２のユーザの決済口座から第１のユーザの回収口座に対応する実際の消費資源情報をさらに転送することができる。その後、資源情報の転送に関する通知メッセージはまた、第２のユーザのクライアントに提供されることもできる。

【0063】

さらに、第２のユーザ与信権限がサービス条件を満たすかどうかを判定する過程で、第２のユーザの与信限度、決済注文記録などの情報が読み取られることができ、消費が終了した後に第２のユーザの決済口座から第１のユーザの回収口座への自動資金転送が関与することができることに留意すべきである。したがって、契約が事前に第２のユーザと署名されていてもよく、すなわち、第２のユーザが同意したという条件で本出願の実施形態における様々な具体的な動作が行われる。したがって、第１のユーザデータ処理システムによって提出された第２のユーザの識別情報を受信すると、サーバはまた、第２のユーザが与信権限検証を実行する必要があると判定された場合に、現在の第２のユーザが契約ユーザであるかどうかを最初に判定することができる。肯定的である場合、判定などの動作が行われる。そうでなければ、第２のユーザは、契約に署名するように促されてもよい。

【0064】

多くの具体的な促進方法が存在することができる。例えば、サーバによって受信した第２のユーザの情報が第２のユーザのコンタクト情報を含む場合、契約署名ページにジャンプするためのリンクの情報がコンタクト情報を用いて第２のユーザに提供されることができる。例えば、リンクの情報は、ショートメッセージなどを介して第２のユーザの携帯電話に送信される。このようにして、第２のユーザがリンクをクリックした後、第２のユーザのクライアントが呼び出されることができ、契約署名ページが表示される。それにより、第２のユーザのクライアントによって提出されたユーザ動作情報が受信され、それゆえに署名動作を完了することができる。

【0065】

あるいは、別の実装では、第１のユーザのオフライン店舗は、２次元コードなどの契約署名ページのアドレスを担持するグラフィックコードを提供することができる。サーバは、契約促進情報を第１のユーザデータ処理システムに送信することができ、第１のユーザのスタッフは、第２のユーザのクライアントを使用して２次元コードをスキャンして契約署名ページを直接表示するように第２のユーザに促すことができ、契約に署名する動作を実行することができる。

【0066】

さらにまた、第１のユーザデータ処理システムはまた、契約の署名を完了するための動作の選択肢を提供することもできる。このとき、サーバは、第２のユーザが契約に署名していないことを示す促進情報を第１のユーザデータ処理システムに提供することができる。第１のユーザのスタッフは、契約の内容を口頭で読むことができ、同意するかどうかを第２のユーザに尋ねることができる。第２のユーザの同意を得て、第１のユーザのスタッフは、第１のユーザデータ処理システムの動作の選択肢について動作して、口頭契約を達成することができる。このように、口頭契約の情報を受信した後、サーバは、第２のユーザの決済口座の情報が第２のユーザの情報に基づいて予め決定されていることから、第２のユーザ情報の決済口座を契約が合意された状態に変更することができることに留意すべきである。あるいは、サーバは、口頭契約を一時契約として、すなわち、現在の購入のみで有効であるか、または現在の第１のユーザのみに対して有効であるものとして扱うことができる。

【0067】

第３の実施形態は、第２の実施形態に対応するため、関連する実装の詳細は、第１の実施形態の説明を参照することができ、その詳細は、本明細書では繰り返し説明しない。

【0068】

第４の実施形態
上記第２および第３の実施形態では、第２のユーザの識別文書情報とすることができる、またはコードスキャンなどの方法によって取得された第２のユーザの決済口座情報とすることができる第２のユーザの識別情報が第１のユーザデータ処理システムからサーバに送信される。本出願の第４の実施形態では、第２のユーザに関連する決済口座情報は、第２のユーザのクライアントによってサーバに提出されることができ、これは、以下に詳細に説明される。

【0069】

図４を参照すると、第４の実施形態は、以下のステップを含むことができる注文情報を処理するための方法を提供する。

【0070】

Ｓ４０１：ユーザデータ処理システムは、第２のユーザのサービス要求にしたがってサービス注文を生成する。

【0071】

明らかに、実際の用途では、サービス注文は、注文の識別子、第２のユーザの識別子、サービス資源割り当て情報、推定消費資源、サービス開始時間、推定サービス終了時間などをさらに含むことができる。サーバは、その記録を作成することができ、消費される実際の資源を決済するためなどに使用される決済システム内で注文をさらに生成することができる。

【0072】

Ｓ４０２：サービス注文の情報にしたがって第２のグラフィックコードが生成され、第２のユーザに関連する決済口座がログインされたときに第２のユーザのクライアントが第２のグラフィックコードをスキャンすることを可能にし、決済口座情報およびサービス注文のスキャンされた情報がサーバに送信され、決済口座の情報にしたがって第２のユーザに関する与信権限検証を実行し、満たされた場合に検証に通過したことを示すメッセージを第１のユーザデータ処理システムに返信する。

【0073】

第２のユーザのクライアントは、第２のユーザの端末装置にインストールされたＡｌｉ ｔｒａｖｅｌクライアント、Ａｌｉｐａｙクライアントなどを指すことができる。第２のユーザのクライアントは、第２のユーザに関連する決済口座がログインされた状態にあるため、スキャン後に第２のユーザの決済口座の情報とともにスキャン結果がサーバに送信されることができる。サーバは、第２のユーザがサービス条件を満たすかどうかを判定する。さらに、サービス注文は、第１のユーザの識別情報を含むため、サーバは、第２のユーザがサービス条件を満たすと判定したのに応じて、第１のユーザデータ処理システムに通知メッセージを提供することができる。

【0074】

Ｓ４０３：検証に通過したことを示すメッセージが受信される。

【0075】

Ｓ４０４：サーバが消費資源情報および第２のユーザに関連する決済口座の情報にしたがってサービス注文を終了するように、サービス注文の消費資源情報がサーバに送信される。

【0076】

検証に通過したことを示すメッセージを受信した後、第１のユーザデータ処理システムはまた、第２のユーザについてデポジットなしおよび部屋点検なしなどのサービスを実行することもできる。

【0077】

第５の実施形態
第５の実施形態は、第４の実施形態に対応し、サーバの観点から説明される。図５を参照すると、第５の実施形態は、以下のステップを含むことができる注文情報を処理するための方法を提供する。

【0078】

Ｓ５０１：サーバは、第２のユーザのサービス要求にしたがって第１のユーザデータ処理システムによって生成された、第２のユーザのクライアントによって提出されたサービス注文の情報および第２のユーザの決済口座情報を受信する。

【0079】

Ｓ５０２：決済口座情報にしたがって第２のユーザに関する与信権限検証が実行される。

【0080】

Ｓ５０３：検証に通過した場合、第１のユーザデータ処理システムがサービス注文を生成するように、検証に通過したことを示すメッセージが第１のユーザデータ処理システムに返信される。

【0081】

Ｓ５０４：第１のユーザデータ処理システムによって提出された消費資源情報を受信すると、消費資源情報および第２のユーザに関連する決済口座情報にしたがってサービス注文が終了される。

【0082】

第６の実施形態
第６の実施形態もまた、第４の実施形態に対応し、第２のユーザのクライアントの観点からの注文情報処理方法を提供する。図６を参照すると、本方法は、以下のステップを含むことができる。

【0083】

Ｓ６０１：第２のユーザのクライアントは、第２のユーザに関連する決済口座がログインされたときに第１のユーザデータ処理システムによって提供される第２のグラフィックコードであって、第２のユーザのサービス要求にしたがって第１のユーザデータ処理システムによって生成されたサービス注文の情報を担持する第２のグラフィックコードを取得する。

【0084】

Ｓ６０２：第２のユーザに関連する決済口座の情報および第２のグラフィックコードにおけるサービス注文の情報がサーバに送信され、サーバは、決済口座の情報にしたがって第２のユーザに関する与信権限検証を実行し、検証に通過した場合に検証に通過したことを示すメッセージを第１のユーザデータ処理システムに返信し、サーバは、消費資源情報および第２のユーザに関連する決済口座の情報にしたがってサービス注文を終了する。

【0085】

なお、第４から第６の実施形態における他の実装の詳細は、第２の実施形態のものと同じとすることができることに留意すべきである。したがって、第２の実施形態における説明を参照することができ、その詳細は、本明細書では繰り返し説明しない。

【0086】

第２の実施形態に対応して、本出願の実施形態は、第１のユーザデータ処理システムに適用される注文情報処理装置をさらに提供する。図７を参照すると、装置は、具体的には、第２のユーザのサービス要求を処理するときに第２のユーザの識別情報を判定するために使用される識別情報判定ユニット７０１と、第２のユーザの識別情報をサーバに提出してサーバが第２のユーザに関する与信権限検証を実行することを可能にするために使用される情報提出ユニット７０２と、サービス注文を生成して成功した検証メッセージを受信した後にサービス注文をサーバに提出するために使用される注文生成ユニット７０３と、サービス注文の消費資源情報をサーバに提出してサーバが消費資源情報および第２のユーザに関連する決済口座情報にしたがってサービス注文を終了することを可能にするために使用される消費資源情報提出ユニット７０４とを含むことができる。

【0087】

具体的な実装では、識別情報判定ユニット７０１は、具体的には、第２のユーザの識別文書情報を収集するために使用されることができ、情報提出ユニット７０２は、具体的には、サーバが識別文書情報にしたがってサーバに関連する決済プラットフォームにおいて第２のユーザによって開設された決済口座情報を判定し、決済口座情報に基づいて第２のユーザに関する与信権限検証を実行するように、第２のユーザの識別文書情報をサーバに送信するために使用される。

【0088】

あるいは、別の実装では、識別情報判定ユニット７０１は、具体的には、サーバに関連する決済プラットフォームにおいて第２のユーザによって開設された決済口座情報を取得するために使用されることができ、情報提出ユニット７０２は、具体的には、サーバが決済口座情報に基づいて第２のユーザに関する与信権限検証を実行するように、決済口座情報をサーバに送信するために使用されることができる。

【0089】

上述したような別の実装では、サーバに関連する決済プラットフォームにおいて第２のユーザによって開設された決済口座情報が取得されると、第２のユーザによって提供される第１のグラフィックコード情報がスキャンされて、サーバに関連する決済プラットフォームにおいて第２のユーザによって開設された決済口座情報、第２のユーザの端末装置にインストールされた決済プラットフォームクライアントによって提供される第１のグラフィックコード情報、および決済プラットフォームクライアントとサーバとの間に存在する関連関係を取得することができる。

【0090】

具体的な実装では、情報提出ユニット７０２はさらに、サーバが推定消費資源情報に基づいて第２のユーザに関する与信権限検証を実行するように、第２のユーザの識別情報がサーバに送信されたときに、推定消費資源情報を判定して推定消費資源情報をサーバに送信するために使用されることができる。

【0091】

実際の用途では、第１のユーザデータ処理システムは、ホテルデータ処理システムを含み、サービス注文は、ホテルサービス注文を含む。

【0092】

第３の実施形態に対応して、本出願の実施形態は、サーバに具体的に適用されることができる注文情報処理装置をさらに提供する。図８を参照すると、装置は、第２のユーザの識別情報を受信するために使用される第１の情報受信ユニット８０１と、第２のユーザに関する与信権限検証を実行するために使用される第１の検証ユニット８０２と、検証に通過した場合に検証が第１のユーザデータ処理システムに渡されたことを示すメッセージを返信して第１のユーザデータ処理システムにサービス注文を生成させるために使用される第１の情報返信ユニット８０３と、第１のユーザデータ処理システムによって提出されたサービス注文の消費資源情報を受信し、消費資源情報および第２のユーザに関連する決済口座情報にしたがってサービス注文を終了するために使用される第１の注文終了ユニット８０４とを含むことができる。

【0093】

特定の実装では、第１の情報受信ユニット８０１は、具体的には、第１のユーザデータ処理システムによって送信された第２のユーザの識別文書情報を受信するために使用されることができ、第１の検証ユニット８０２は、具体的には、識別文書情報にしたがってサーバに関連する決済プラットフォームにおいて第２のユーザによって開設された決済口座情報を判定し、決済口座情報に基づいて第２のユーザに関する与信権限検証を実行するために使用されることができる。

【0094】

あるいは、別の実装では、第１の情報受信ユニット８０１は、具体的には、第１のユーザデータ処理システムからサーバに関連する決済プラットフォームにおいて第２のユーザによって開設された決済口座情報を受信するために使用されることができ、検証ユニット８０２は、具体的には、決済口座情報に基づいて第２のユーザに関する与信権限検証を実行するために使用されることができる。

【0095】

特定の実装では、第１の情報受信ユニット８０１は、推定消費資源情報を受信するためにさらに使用されることができ、装置は、第２のユーザの与信限度情報を判定するために使用される与信限度情報判定ユニットと、与信限度情報が推定消費資源情報よりも高いかどうかを判定し、判定結果に基づいて検証に通過したかどうかを判定するために使用される判定ユニットとをさらに含むことができる。

【0096】

さらに、装置は、第１のユーザデータ処理システムによって提出されたサービス注文の情報を受信すると、第１のユーザに関連する回収口座情報を判定するために使用される口座情報判定ユニットと、決済注文を生成するために、判定された第１のユーザの回収口座情報、第２のユーザの決済口座情報、およびサービス注文を結合するために使用される決済注文生成ユニットとをさらに含むことができる。

【0097】

このとき、第１の注文終了ユニット８０４は、サービス注文に関連する決済注文を判定するために使用される決済注文判定サブユニットと、実際の消費資源情報および決済注文に記録された情報に基づいて決済注文を生成するために使用される決済注文生成サブユニットと、決済注文にしたがって第２のユーザの決済口座から第１のユーザの回収口座へと対応する実際の消費資源情報を割り当てるために使用される資源転送サブユニットとを含む。

【0098】

さらに、装置は、第２のユーザのクライアントへの資源情報の転送に関する通知メッセージを提供するために使用される通知ユニットをさらに含むことができる。

【0099】

特定の実装では、装置は、第２のユーザが契約ユーザに属するかどうかを判定するために使用される契約判定ユニットと、未だに署名されていない場合に契約に署名するように第２のユーザを促すために使用される契約促進ユニットとをさらに含むことができる。

【0100】

第２のユーザの受信識別情報が第２のユーザのコンタクト情報を含む場合、契約促進ユニットは、具体的には、コンタクト情報を用いて契約署名ページにジャンプするためのリンクの情報を第２のユーザに提供するために使用されるリンク情報提供サブユニットと、第２のユーザのクライアントによって送信されたユーザ動作情報を受信することによって契約署名動作を完了するために使用されるユーザ動作情報受信サブユニットとを含むことができる。

【0101】

あるいは、別の実装では、契約促進ユニットは、具体的には、第２のユーザが契約に署名していないことを示す促進情報を第１のユーザデータ処理システムに提供し、第２のユーザが契約に署名することに同意した後に第１のユーザの動作情報が動作の選択肢を介して受信されるように、契約署名の動作の選択肢を実行し、契約署名動作を完了するために使用されることができる。

【0102】

第４の実施形態に対応して、本出願の実施形態は、第１のユーザデータ処理システムに適用される注文情報処理装置をさらに提供する。図９を参照すると、装置は、具体的には、第２のユーザのサービス要求にしたがってサービス注文を生成するために使用されるサービス注文生成ユニット９０１と、サービス注文の情報にしたがって第２のグラフィックコードを生成し、第２のユーザのクライアントが第２のユーザに関連する決済口座がログインされている場合に第２のグラフィックコードをスキャンし、スキャンされた決済口座情報およびサービス注文情報をサーバに提出し、サーバが決済口座情報にしたがって第２のユーザに関する与信権限検証を実行し、検証に通過した場合に検証に通過したことを示すメッセージを第１のユーザデータ処理システムに返信するために使用されるグラフィックコード生成ユニット９０２と、検証に通過したことを示すメッセージを受信するために使用されるメッセージ受信ユニッ９０３トと、サービス注文の消費資源情報をサーバに提出し、サーバに消費資源情報および第２のユーザに関連する決済口座情報にしたがってサービス注文を終了させるために使用される消費資源情報提出ユニット９０４とを含むことができる。

【0103】

第５の実施形態に対応して、本出願の実施形態は、サーバに適用される注文情報処理装置をさらに提供する。図１０を参照すると、装置は、具体的には、第２のユーザのサービス要求にしたがって第１のユーザデータ処理システムによって生成された、第２のユーザのクライアントによって提出されたサービス注文情報、および第２のユーザの決済口座情報を受信するために使用される第２の情報受信ユニット１００１と、決済口座情報にしたがって第２のユーザの与信権限検証を実行するために使用される第２の検証ユニット１００２と、検証に通過した場合に検証に通過したことを示すメッセージを第１のユーザデータ処理システムに返信して第１のユーザデータ処理システムにサービス注文を生成させるために使用される第２の情報返信ユニット１００３と、消費資源情報を受信するのに応じて、第１のユーザデータ処理システムによって提出されたサービス注文の消費資源情報および第２のユーザに関連する決済口座情報にしたがってサービス注文を終了するために使用される第２注文終了ユニット１００４とを含むことができる。

【0104】

第６の実施形態に対応して、本出願の実施形態は、第２のユーザのクライアントに適用される注文情報処理装置をさらに提供する。図１１を参照すると、装置は、具体的には、第２のユーザに関連する決済口座がログインされている状態で第１のユーザデータ処理システムによって提供される第２のグラフィックコードであって、第２のユーザのサービス要求にしたがって第１のユーザデータ処理システムによって生成されたサービス注文情報を担持する第２のグラフィックコードを取得するために使用されるグラフィックコード取得ユニット１１０１と、第２のユーザに関連する決済口座情報および第２のグラフィックコードにおけるサービス注文情報をサーバに提出し、サーバが決済口座情報にしたがって第２のユーザに関する与信権限検証を実行し、検証に通過した場合に検証に通過したことを示すメッセージを第１のユーザデータ処理システムに返信するために使用される情報提出ユニット１１０２とを含むことができ、サーバは、消費資源情報および第２のユーザに関連する決済口座情報にしたがってサービス注文を終了する。

【0105】

本出願の実施形態を使用して、第２のユーザのサービス要求を受信すると、第１のユーザデータ処理システムは、第２のユーザの識別情報をサーバに提出する必要があるのみである。サーバは、第２のユーザに関する与信権限検証を実行し、サービス条件が満たされているかどうかを判断することによって判定を行うことができる。満たされている場合、第１のユーザデータ処理システムは、予め設定された方法（例えば、デポジットなしのチェックイン、ホテルから退出するときに部屋の点検がないなど）にしたがって現在の第２のユーザにサービスを提供するように通知される。サービスの終了時に、サーバは、対応する注文のチェックアウト動作を実行する。したがって、デポジットの回収、ホテルからの退出時の確認、デポジットの返却などの作業を行うことを回避することができ、それゆえに効率を向上させる。同時に、（カードの取り出し、カードの読み取り、パスワードの入力、および署名を含む）カードを読み取る消費資源の決済、現金決済（金銭の預かり、金銭の検査、釣銭の持ち出し）などのプロセスの操作がスキップされるため、現在処理中の第２のユーザは、長時間待機することが防止される。

【0106】

上記実装の説明から分かるように、当業者であれば、ソフトウェアと必要な一般的なハードウェアプラットフォームとを用いて本出願が実装されることができることを明確に理解することができる。そのような理解に基づいて、本出願の技術的解決策または既存の技術に貢献する部分の本質は、ソフトウェア製品の形態で具体化されることができる。コンピュータソフトウェア製品は、ＲＯＭ／ＲＡＭ、または磁気ディスク、光ディスクなどの記憶媒体に記憶されることができ、（パーソナルコンピュータ、サーバ、またはネットワークデバイスなどとすることができる）コンピューティングデバイスに本出願の様々な実施形態または実施形態の一部に記載された方法を実行させるための命令を含む。

【0107】

本明細書における様々な実施形態は、漸進的に説明され、様々な実施形態の同一または類似の部分は、互いに参照されることができる。各実施形態は、他の実施形態のものとは異なる態様に重点を置いている。特に、方法の実施形態と実質的に類似しているため、システムまたはシステムの実施形態の説明は、比較的簡単であり、関連する部分は、方法の実施形態の説明を参照することができる。上述したシステムおよびシステムの実施形態は単なる例示である。別個の構成要素として記載されているユニットは、物理的に分離していてもいなくてもよい。ユニットとして表示される構成要素は、物理的ユニットであってもなくてもよく、すなわち、単一の場所に配置されることができるかまたは複数のネットワークユニットに分散させることもできる。実施形態の解決策の目的を達成するために、モジュールの一部または全部が実際の要件にしたがって選択されることができる。当業者であれば、いかなる創造的な努力もすることなくそれを理解して実装することができる。

【0108】

本出願によって提供される注文情報を処理するための方法、装置およびシステムは、上記詳細に説明される。本出願の原理および実装方法は、特定の例を用いて説明される。上記実施形態の説明は、本出願の方法およびそれらの中核概念を理解するのに役立つためにのみ使用される。さらにまた、当業者にとっては、本出願の発想にかかる特定の実装および適用範囲の変更が存在することができる。要約すると、本明細書の内容は、本出願を限定するものと解釈されるべきではない。

【図1】

【図2】

【図3】

【図4】

【図5】

【図6】

【図7】

【図8】

【図9】

【図10】

【図11】