JP2020506470A - 取引対象予約システム、方法、及び装置 - Google Patents

取引対象予約システム、方法、及び装置 Download PDF

Info

Publication number
JP2020506470A
JP2020506470A JP2019539285A JP2019539285A JP2020506470A JP 2020506470 A JP2020506470 A JP 2020506470A JP 2019539285 A JP2019539285 A JP 2019539285A JP 2019539285 A JP2019539285 A JP 2019539285A JP 2020506470 A JP2020506470 A JP 2020506470A
Authority
JP
Japan
Prior art keywords
reservation
information
request
target
server
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Pending
Application number
JP2019539285A
Other languages
English (en)
Inventor
シュエ ビン
シュエ ビン
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Alibaba Group Holding Ltd
Original Assignee
Alibaba Group Holding Ltd
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Alibaba Group Holding Ltd filed Critical Alibaba Group Holding Ltd
Publication of JP2020506470A publication Critical patent/JP2020506470A/ja
Pending legal-status Critical Current

Links

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F16/00—Information retrieval; Database structures therefor; File system structures therefor
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F16/00—Information retrieval; Database structures therefor; File system structures therefor
    • G06F16/20—Information retrieval; Database structures therefor; File system structures therefor of structured data, e.g. relational data
    • G06F16/25—Integrating or interfacing systems involving database management systems
    • G06F16/252—Integrating or interfacing systems involving database management systems between a Database Management System and a front-end application
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q10/00—Administration; Management
    • G06Q10/02—Reservations, e.g. for tickets, services or events
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q10/00—Administration; Management
    • G06Q10/08—Logistics, e.g. warehousing, loading or distribution; Inventory or stock management
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q10/00—Administration; Management
    • G06Q10/08—Logistics, e.g. warehousing, loading or distribution; Inventory or stock management
    • G06Q10/087—Inventory or stock management, e.g. order filling, procurement or balancing against orders
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q50/00—Information and communication technology [ICT] specially adapted for implementation of business processes of specific business sectors, e.g. utilities or tourism
    • G06Q50/10—Services
    • G06Q50/12—Hotels or restaurants

Landscapes

  • Business, Economics & Management (AREA)
  • Engineering & Computer Science (AREA)
  • Tourism & Hospitality (AREA)
  • Theoretical Computer Science (AREA)
  • Physics & Mathematics (AREA)
  • Economics (AREA)
  • General Physics & Mathematics (AREA)
  • Marketing (AREA)
  • General Business, Economics & Management (AREA)
  • Human Resources & Organizations (AREA)
  • Strategic Management (AREA)
  • Operations Research (AREA)
  • Databases & Information Systems (AREA)
  • Quality & Reliability (AREA)
  • Development Economics (AREA)
  • Entrepreneurship & Innovation (AREA)
  • General Health & Medical Sciences (AREA)
  • Health & Medical Sciences (AREA)
  • Primary Health Care (AREA)
  • Data Mining & Analysis (AREA)
  • General Engineering & Computer Science (AREA)
  • Accounting & Taxation (AREA)
  • Finance (AREA)
  • Management, Administration, Business Operations System, And Electronic Commerce (AREA)

Abstract

本出願は電子技術の分野に関し、より詳細には、予約プロセスにおいてリンクが多いために生じる予約成功率が低い問題を解決するための取引対象予約システム、方法、及び装置に関する。取引対象予約方法が本出願の実施形態例において提供される。この取引対象予約方法は、クライアントターミナルによって送られた第１の予約リクエストをプラットフォームサーバによって受け取ることと、第１の予約リクエスト内の予約対象情報と在庫の予約情報とにより、在庫の予約情報が第１の予約リクエストを満足するか否かを判定することと、在庫の予約情報が第１の予約リクエストを満足する場合に、第１の予約リクエストに対応する予約対象情報に基づいて第１の予約結果を生成し、そうでない場合に、第１の予約リクエストを取引対象サーバに送って、取引対象サーバによってフィードバックされた第１の予約結果を受け取ることと、第１の予約結果をクライアントターミナルにフィードバックすることと、を含む。

Description

関連出願の相互参照
本出願は、中国特許出願第２０１７１００４５８５１．１号（２０１７年１月２０日に出願）、発明の名称「ＴＲＡＮＳＡＣＴＩＯＮ ＯＢＪＥＣＴ ＲＥＳＥＲＶＡＴＩＯＮ ＳＹＳＴＥＭ，ＭＥＴＨＯＤ，ＡＮＤ ＡＰＰＡＲＡＴＵＳ」に対する優先権を主張する。なおこの文献は、その全体において参照により本明細書に組み込まれている。
本出願は電子技術の分野に関し、より詳細には、取引対象予約システム、取引対象予約方法、及び取引対象予約装置に関する。
ホテルオンライン予約サービスとは、ユーザがホテル予約情報を記入して予約情報をホテルに送信することでホテルの部屋予約が完了するウェブページまたはモバイルアプリケーション（アプリ）をユーザに提供するインターネットサービスプロセスのことを指す。
図１に示すように、従来のすべての予約サービスでは、クライアントターミナルがプラットフォームサーバに予約情報を送信した後に、プラットフォームサーバはエージェントシステムに対してリクエストを起こし、そしてエージェントシステムはチャネル管理システムにリクエストを送り、チャネル管理システムはホテル資産管理システム（ＰＭＳ）システムにリクエストを送り、最後に予約結果（すなわち、形成された注文情報）がクライアントターミナルに返される。
このように、従来の注文情報形成プロセスには多くのリンクがあり、いずれかのリンクにおいて何らかの問題が生じると予約失敗となるため、予約成功率が低い。たとえば、各システムの処理成功率が９９％であると想定すると、オンライン予約サービスシステム、エージェントシステム、チャネル管理システム、及びホテルＰＭＳシステムの後が全成功率は９９％の４乗となって、ほぼ９６％に等しい。
要約すれば、現在では、ユーザが予約情報を送信した後の後続の注文情報形成プロセスにはリンクが多いため、予約成功率が低くなる。
本出願の実施形態例では、注文情報形成プロセスにおいてリンクが多いことによって生じる予約成功率が低い問題を解決するための取引対象予約システム、方法、及び装置が提供される。
本出願の実施形態例で提供される取引対象予約システムは、
プラットフォームサーバであって、
クライアントターミナルによって送られた、予約対象情報を保持する第１の予約リクエストを受け取ることと、
予約対象情報と在庫の予約情報とにより、在庫の予約情報が第１の予約リクエストを満足するか否かを判定することであって、在庫の予約情報は、予約対象情報を保持する第２の予約リクエストをプラットフォームサーバがあらかじめ起こすことによって取得される、判定することと、
在庫の予約情報が第１の予約リクエストを満足する場合に、第１の予約リクエストに対応する第１の予約結果を生成することと、
そうでない場合に、第１の予約リクエストを取引対象サーバに送って第１の予約結果を取得することと、
第１の予約結果をクライアントターミナルにフィードバックすることと、を行うように構成される、プラットフォームサーバと、
クライアントターミナルであって、
ユーザが提出した予約対象情報を受け取って、予約対象情報に基づいてプラットフォームサーバに第１の予約リクエストを送ることと、
第１の予約リクエスト内の予約対象情報と在庫の予約情報とに基づいてプラットフォームサーバによってフィードバックされた第１の予約結果を受け取ることと、を行うように構成される、クライアントターミナルと、
取引対象サーバであって、
プラットフォームサーバがあらかじめ起こした第２の予約リクエストを受け取って、プラットフォームサーバに第２の予約結果をフィードバックすることであって、第２の予約結果には、第２の予約リクエストに対応する予約成功についての情報が含まれ、情報は、プラットフォームサーバの初期在庫の予約情報となる、フィードバックすることと、
ユーザが起こし、プラットフォームサーバによって送られた第１の予約リクエストを受け取って、プラットフォームサーバに第１の予約結果をフィードバックすることと、を行うように構成され取引対象サーバと、
を備える、取引対象予約システムである。
本出願の実施形態例で提供される取引対象予約方法は、
クライアントターミナルによって送られた、予約対象情報を保持する第１の予約リクエストをプラットフォームサーバによって受け取ることと、
第１の予約リクエスト内の予約対象情報と在庫の予約情報とによって、在庫の予約情報が第１の予約リクエストを満足するか否かを判定することであって、在庫の予約情報には、予約対象情報を保持する第２の予約リクエストを取引対象サーバに対してプラットフォームサーバがあらかじめ起こした後にプラットフォームサーバによって取得された予約成功についての情報が含まれる、判定することと、
在庫の予約情報が第１の予約リクエストを満足する場合に、第１の予約リクエストに対応する予約対象情報に基づいて第１の予約結果を生成し、そうでない場合には、第１の予約リクエストを取引対象サーバに送って、取引対象サーバによってフィードバックされた第１の予約結果を受け取ることと、
第１の予約結果をクライアントターミナルにフィードバックすることと、を含む。
本出願の実施形態例でさらに提供される取引対象予約方法は、
ユーザが提出した予約対象情報をクライアントターミナルによって受け取ることと、
予約対象情報を保持する第１の予約リクエストをプラットフォームサーバに送ることと、
第１の予約リクエスト内の予約対象情報と在庫の予約情報とによりプラットフォームサーバによってフィードバックされた第１の予約結果を受け取ることであって、在庫の予約情報には、予約対象情報を保持する第２の予約リクエストを取引対象サーバに対してプラットフォームサーバがあらかじめ起こした後にプラットフォームサーバによって取得された予約成功についての情報が含まれ、第１の予約結果には、第１の予約リクエストに対応する予約成功についての情報が含まれる、受け取ることと、を含む。
本出願の実施形態例で提供されるプラットフォームサーバは、
クライアントターミナルによって送られた、予約対象情報を保持する第１の予約リクエストを受け取るように構成された受信モジュールと、
予約処理モジュールであって、第１の予約リクエスト内の予約対象情報と在庫の予約情報とにより、在庫の予約情報が第１の予約リクエストを満足するか否かを判定することであって、在庫の予約情報には、予約対象情報を保持する第２の予約リクエストを取引対象サーバに対して送信モジュールがあらかじめ起こした後に取得された予約成功についての情報が含まれる、判定することと、在庫の予約情報が第１の予約リクエストを満足する場合に、第１の予約リクエストに対応する予約対象情報に基づいて第１の予約結果を生成することと、そうでない場合に、送信モジュールを制御して、第１の予約リクエストを取引対象サーバに送り、取引対象サーバによってフィードバックされた第１の予約結果を受信モジュールによって取得することと、を行うように構成された、予約処理モジュールと、を含み、
送信モジュールはさらに、第１の予約結果をクライアントターミナルにフィードバックするように構成されている。
本出願の実施形態例でさらに提供されるクライアントターミナルは、
ユーザが提出した予約対象情報を受け取るように構成された第１の受信モジュールと、
予約対象情報に基づいて予約対象情報を保持する第１の予約リクエストを生成するように構成された第１の生成モジュールと、
第１の予約リクエストを送るように構成された送信モジュールと、
第１の予約リクエスト内の予約対象情報と在庫の予約情報とによりプラットフォームサーバによってフィードバックされた第１の予約結果を受け取るように構成された第２の受信モジュールであって、在庫の予約情報には、予約対象情報を保持する第２の予約リクエストを取引対象サーバに対してプラットフォームサーバがあらかじめ起こした後にプラットフォームサーバによって取得された予約成功についての情報が含まれ、第１の予約結果には、第１の予約リクエストに対応する予約成功についての情報が含まれる、第２の受信モジュールと、を含む。
前述の実施形態例を用いることによって、プラットフォームサーバは、ユーザが実際にプラットフォームサーバに対して予約リクエストを起こす前に、システム外部の取引対象サーバに対して事前に予約リクエストを起こし、取得した予約結果を初期在庫の予約情報として記憶する。クライアントターミナルが実際に起こした予約リクエストを受け取った後に、ユーザの実際の予約リクエストに対応する予約結果を、ローカル在庫の予約情報に基づいてクライアントターミナルに返す。したがって、プラットフォームサーバは、クライアントターミナルからリクエストを受け取った時に取引対象サーバに対してリクエストを起こす必要がなく、クライアントターミナルは、プラットフォームサーバが返した予約結果を遅れずに取得することができ、その結果、予約効率及び予約成功率が向上し、そしてユーザ経験が改善される。
背景の説明による予約プロセスの概略フローチャートである。 本出願の実施形態例１による取引対象予約方法のフローチャートである。 本出願の実施態様の効果例図である。 本出願の実施形態例２による取引対象予約方法のフローチャートである。 本出願の実施形態例３による取引対象予約システムの概略図である。 本出願の実施形態例４によるプラットフォームサーバの概略構造図である。 本出願の実施形態例５によるクライアントターミナルの概略構造図である。
本出願の実施形態例は主に、プラットフォームサーバがシステム外部の取引対象サーバに予約リクエストを送ってクライアントターミナルユーザに予約結果を提供する必要があるシナリオに適用することができる。このシナリオでは、従来のリクエストプロセスにより、プラットフォームサーバが、ユーザが実際に起こした予約リクエストを受け取った後に、システム外部の取引対象サーバからの予約結果をリクエストし、予約プロセスにおけるリンクが多いために予約リクエストの失敗率が高い。
本出願の解決方法を、一例としてホテル予約を選ぶことによって以下でさらに紹介する。
実施形態例１
図２は本出願の実施形態例１による取引対象予約方法のフローチャートであり、以下が含まれる。
Ｓ２０１において、クライアントターミナルが、ユーザが提出した予約対象情報を受け取る。
ホテル予約に関して、ユーザが提出した予約対象情報には、ホテル名及び部屋タイプなどの情報が含まれていてもよい。
Ｓ２０２において、クライアントターミナルは、受け取った予約対象情報に基づいて、予約対象情報を保持する第１の予約リクエストをプラットフォームサーバに送る。
ここで、ユーザが予約を確認した後で、クライアントターミナルは、ユーザが選択した予約対象情報を保持する第１の予約リクエストをプラットフォームサーバに送る。
Ｓ２０３において、プラットフォームサーバは、第１の予約リクエスト内の予約対象情報と在庫の予約情報とにより、在庫の予約情報が第１の予約リクエストを満足するか否かを判定する。在庫の予約情報が第１の予約リクエストを満足する場合にはＳ２０４ａを行い、そうでない場合にはＳ２０４ｂを行う。在庫の予約情報には、予約対象情報を保持する第２の予約リクエストを取引対象サーバに対してプラットフォームサーバがあらかじめ起こした後にプラットフォームサーバによって取得された予約成功についての情報が含まれる。
具体的な実施では、プラットフォームサーバが、予約対象情報を保持する第２の予約リクエストを、将来の予約時間帯における在庫要求に応じて取引対象サーバに対して事前に起こし、予約が成功した後で、取引対象サーバが返す予約成功についての予約情報を記憶する。
次に、ユーザが実際に起こした予約リクエストを受け取った後に、記憶した予約情報を最初にチェックして、それがユーザの予約リクエストを満足するか否かをみる。そうである場合には、Ｓ２０４ａに示すように、ユーザに予約結果を直ちに返す。そうでない場合に、Ｓ２０４ｂに示すように、従来のプロセスにより取引対象サーバにさらにリクエストを送る必要がある。
具体的には、プラットフォームサーバは、過去の予約データにより、将来の予約時間帯における在庫要求を決定する。過去の予約データには、取引対象サーバによって与えられる予約対象、実際にユーザが起こした予約の予約データが含まれる。在庫要求は、取引対象サーバによって与えられる各タイプの予約対象に対する様々なユーザの要求の総数量（たとえば、必要なスタンダードルームの数、及び必要なキングサイズルームの数）を含み、決定された在庫要求に応じて取引対象サーバに第２の予約リクエストを送り、取引対象サーバが返した予約成功についての情報を保持する第２の予約結果を受け取り、第２の予約結果を初期在庫の予約情報として用いる。
ここで、過去の予約データをプラットフォームサーバに記憶してもよいし、または独立したデータベースに記憶してもよく、プラットフォームサーバは必要に応じてデータベースに対して問合せリクエストを起こす。
実際の実施態様では、プラットフォームサーバは、複数の取引対象サービスプロバイダ（たとえば、ホテル）それぞれに対応する記憶した過去の注文データｒにより、所定の時間帯において各取引対象サービスプロバイダに対して在庫要求情報を予測してもよい。次に、取引対象サービスプロバイダに対して予測された在庫要求に応じて、取引対象サービスプロバイダに対応する取引対象サーバ（たとえば、ホテルのホテル管理システム）に第２の予約リクエストを送る。
予約対象情報を保持する第２の予約リクエストを取引対象サーバに対してプラットフォームサーバが事前に起こした後に、予約成功についての取得情報と取引対象サーバに対応するサービスプロバイダ識別子情報（たとえば、ホテル名）との間のマッピング関係を設定して、マッピング関係を在庫の予約情報として記憶する。次に、第１の予約リクエストをユーザが実際に起こした後で、第１の予約リクエスト内に保持されたサービスプロバイダ識別子識報により、サービスプロバイダ識別子情報に対応する予約成功についての情報に対して在庫の予約情報を検索する。さらに、第１の予約リクエスト内の他の予約対象情報（部屋タイプ、及び部屋の数、たとえば、２つのスタンダードルーム）により、検索した予約成功についての情報が第１の予約リクエストを満足するか否かを判定する。
プラットフォームサーバ→エージェントシステム→チャネル管理システム→取引対象サーバのリクエスト経路に関して、プラットフォームサーバが取引対象サーバに第２の予約リクエストを送ると、最初にエージェントシステムに対して第２の予約リクエストが起こされ、エージェントシステムは第２の予約リクエストを受け取った後にチャネル管理システムに対して連続的にリクエストを起こし、最後にチャネル管理システムは、取引対象サーバ（たとえば、ホテル管理システム）に対してリクエストを起こして、取引対象サーバが返した第２の予約結果をプラットフォームサーバにエージェントシステムを通して返す。
プラットフォームサーバは、最初に取得した予約結果を初期在庫の予約情報として記憶する。たとえば、予約成功のホテル名、ホテルの部屋タイプ、チェックイン時間、注文番号などを記録する。
Ｓ２０４ａにおいて、在庫の予約情報が第１の予約リクエストを満足するときに、プラットフォームサーバは、第１の予約リクエストに対応する予約対象情報に基づいて第１の予約結果を生成して、在庫の予約情報を更新する。
ここで、プラットフォームサーバは在庫の予約情報を検索して、第１の予約リクエストに対応する予約情報があるか否かを判定し、見出した予約情報に基づいて第１の予約リクエストに対応する第１の予約結果を生成する。
たとえば、在庫の予約情報には、プラットフォームサーバが事前に予約に成功したチェーンホテルの１０つのスタンダードルームの部屋情報が含まれる。第１の予約リクエストにおいてチェーンホテルのスタンダードルームの予約がリクエストされている場合、あらかじめ予約が成功している１０つのスタンダードルームから１つの部屋が選択されて、関連する注文情報（ホテル情報、部屋タイプ、チェックイン時間、注文番号など）がクライアントターミナルに返される。
具体的な実施では、予約を起こすためにユーザ情報を記入する必要があるいくつかのシナリオに対して、プラットフォームサーバは、注文を事前に形成する間に実際のユーザ情報が分からない。そのため、注文を事前に形成する間にプラットフォームのデフォルトユーザ情報を用いて予約を起こしてもよく、実際のユーザに対して注文が形成された後に注文情報更新プロセスが起こされる。
具体的には、プラットフォームサーバは、第１の予約リクエスト内に保持されたクライアントターミナルユーザ情報と第１の予約リクエストに対応する予約対象情報とに基づいて第１の予約結果を生成することであって、第１の予約結果には、第１の予約リクエストに対応する予約成功についての情報とクライアントターミナルユーザ情報とが含まれる、生成することと、第１の予約結果を生成した後に取引対象サーバに予約情報更新リクエストを送ることであって、予約情報更新リクエストは、第２の予約リクエストが送られるときに用いられたデフォルトユーザ情報からクライアントターミナルユーザ情報に、第１の予約結果に付随するユーザ情報を更新することをリクエストするように構成されている、送ることと、を行う。
たとえば、ホテルの予約要求により、ゲスト関連情報を、プラットフォームサーバがあらかじめ起こす第２の予約リクエスト内に保持する必要がある。この場合、プラットフォームサーバは、デフォルトユーザ情報を用いてホテル予約リクエストを起こして、予約に成功したホテル情報を初期在庫の予約情報として取得してもよい。クライアントターミナルユーザが実際に起こした第１の予約リクエストを受け取った後に、クライアントターミナルユーザに対して与えられた部屋があらかじめ予約した部屋から選択され、実際のクライアントターミナルユーザ情報を用いて生成されたホテル予約結果がクライアントターミナルに返される。次に、プラットフォームサーバは、ホテル管理システムに対して注文情報更新リクエストを起こして、あらかじめ予約したデフォルトユーザ情報を実際のクライアントターミナルユーザ情報に変えてもよい。
任意的に、在庫の予約情報が更新された後に予約対象の在庫数量が設定閾値よりも小さいか否かが判定され、予約対象の在庫数量が設定閾値よりも小さい場合、マネージャに在庫警告情報をプッシュして、マネージャに在庫を補充するかまたは取引対象サーバに対して自動的に予約プロセスを起こすかの選択を促す。
したがって、プラットフォームサーバによって、事前に完了した予約情報が十分な在庫状態にあることが確実になるため、ユーザが起こした予約リクエストがリアルタイムで満足される。
Ｓ２０４ｂにおいて、在庫の予約情報が第１の予約リクエストを満足しない場合、プラットフォームサーバが取引対象サーバに第１の予約リクエストを送って、取引対象サーバによってフィードバックされた第１の予約結果を受け取る。
ここで、たとえば、在庫が不十分で、クライアントターミナルがホテルの２つのスタンダードルームの予約をリクエストして、在庫にスタンダードルームがないかまたは１つのみであるとき、この場合、プラットフォームサーバは、従来のプロセスにより取引対象サーバに対して第１の予約リクエストを起こしてもよい。
Ｓ２０５において、プラットフォームサーバは第１の予約結果をクライアントターミナルにフィードバックする。
ここで、プラットフォームサーバによってクライアントターミナルにフィードバックされた第１の予約結果は、在庫が要求を満足するときには、プラットフォームサーバによって直ちに生成された予約結果であってもよいし、在庫が不十分であるときには、取引対象サーバからリクエストされてプラットフォームサーバによって返される予約結果であってもよい。クライアントターミナルは、在庫の予約情報に基づいてサーバが返した第１の予約結果を受け取って、ユーザに第１の予約結果を与える。
前述の実施形態例では、ユーザが実際にプラットフォームサーバに対して予約リクエストを起こす前に、プラットフォームサーバが事前にシステム外部の取引対象サーバに対して予約リクエストを起こし、取得した予約結果を初期在庫の予約情報として記憶する。クライアントターミナルが実際に起こした予約リクエストを受け取った後に、ユーザの実際の予約リクエストに対応する予約結果を、ローカル在庫の予約情報に基づいてクライアントターミナルに返す。したがって、プラットフォームサーバは、クライアントターミナルからのリクエストを受け取ったときに取引対象サーバに対してリクエストを起こす必要はなく、クライアントターミナルは、プラットフォームサーバが返した予約結果を遅れずに取得する、そのため、予約効率及び予約成功率が向上し、そしてユーザ経験が改善される。
図３に示すように、プラットフォームサーバは、あらかじめ計算した在庫要求に応じて、ＸＸホテル及びＹＹホテルから事前に１０つのスタンダードルームを確保する。その後に、ユーザＡがＸＸホテルのスタンダードルームを予約するリクエストを起こし、この場合、プラットフォームサーバは、事前に記憶された在庫情報によりユーザＡの予約リクエストは満足されると判定し、そしてＸＸホテルのスタンダードルームの予約成功についての情報をユーザＡに与える。したがって、ユーザＡは予約成功についての情報を迅速に取得することができる。その後に、ユーザＢはＹＹホテルのキングサイズルームを予約するリクエストを起こし、この場合、プラットフォームサーバは、事前に記憶された在庫情報によりユーザＢの予約リクエストは満足され得ないと判定し、その時間においてＹＹホテルのＰＭＳシステムに予約リクエストを送り、ＹＹホテルのＰＭＳシステムによって送られた予約結果をユーザＢに返す必要がある。ユーザＢの予約プロセスにはユーザＡの場合よりも長い時間が必要であることが明らかである。
実際の実施態様では、ホテル予約のシナリオに加えて、本出願はさらに、任意の他のシナリオであって、プラットフォームサーバが取引対象サーバに予約リクエストを送って、クライアントターミナルユーザに対して予約結果（たとえば、航空券予約及び映画チケット予約）を送る必要があるシナリオに適用することができる。
これらのシナリオでは、プラットフォームサーバはユーザ要求を事前に計算し、プラットフォーム外部のサービスプロバイダに対して事前に予約リクエストを起こし、リクエストした予約結果を在庫の予約情報として記憶する。次に、クライアントターミナルがリクエストを実際に起こすと、関連する予約結果が、あらかじめリクエストした予約情報に基づいてクライアントターミナルに対して与えられる。
本出願の考え方を、具体的な実施形態例を通して以下でさらに例示する。
図４は、本出願の実施形態例２による取引対象予約方法のフローチャートであり、以下が含まれる。
Ｓ４０１では、プラットフォームサーバは、過去の予約データにより、各取引対象サーバに対する将来の予約時間帯における在庫要求を決定し、過去の予約データには、取引対象サーバによって与えられる予約対象に対して実際にユーザが起こした予約の予約データが含まれ、在庫要求には、取引対象サーバによって与えられる予約対象に対する様々なユーザの要求の総数量が含まれる。
具体的な実施では、プラットフォームサーバは、ユーザに対して種々の予約サービス（たとえば、ホテル予約及び航空券予約）を提供することができ、また各予約サービスにおいて、各取引対象サービスプロバイダ（たとえば、ＸＸチェーンホテル及びＹＹチェーンホテル、ならびにチェーンホテル及びエージェントの組み合わせであってもよい）によって提供され得る各取引対象（たとえばスタンダードルーム及びキングサイズルーム）の在庫要求をそれぞれカウントすることができる。具体的には、最近の事前設定時間長さ（たとえば、１ヶ月）において各取引対象に対して完了した注文データを計算してもよく、予約時間帯（たとえば、１日）における取引対象に対する在庫要求情報を、計算した注文データに基づいて予測する。たとえば、チェーンホテルのスタンダードルームの記憶した注文データにより、最近の月におけるチェーンホテルのスタンダードルームの予約数Ｎを計算することによって、チェーンホテルのスタンダードルームの予約数が毎日約Ｎ／３０であると予測することができる。したがって、プラットフォームサーバによって、その後に、毎日７：００ａｍからチェーンホテルのＮ／３０つのスタンダードルームを事前に確保することができる。
前述の予測プロセスは単に例であり、実際の実施態様では、予約時間帯のそれと同一の属性を有する過去の時間帯における注文データを最初に、予約時間帯の属性情報（たとえば、休日であるかどうか、特定の都市においてイベントが開かれるかどうか等）により取得することができ、注文データに基づいて注文要求情報を予測する。
たとえば、予約時間帯がメーデー休日である場合、最近３年間のメーデー休日の注文データを取得してもよく、リクエスト対象の注文要求情報を注文データに基づいて予測する。
ここで、プラットフォームサーバによって、予約時間帯における各取引対象の予測された在庫要求に基づいて第２の予約リクエストが生成される。ここで、各取引対象に対して、プラットフォームサーバは、１つのリクエストにおいて予約時間帯における取引対象の予約を完了してもよい。たとえば、チェーンホテルのスタンダードルームの予約要求数は毎日Ｎ／３０と予測され、プラットフォームサーバは、１つの予約リクエストにおいてチェーンホテルの管理システムからチェーンホテルのＮ／３０つのスタンダードルームの予約をリクエストすることができる。しかし、プラットフォームサーバは、チェーンホテルのＮ／３０つのスタンダードルームを予約するために複数の予約リクエストを起こして、たとえば、各リクエストにおいて１つの部屋を予約することもできる。
具体的な実施では、前述の予約時間帯の長さを１サイクルとして用いてもよく、プラットフォームサーバは第２の予約リクエストを周期的に起こして第２の予約結果を取得してもよい。たとえば、前述の例では、サーバは、システム外部に対して毎朝ホテル予約リクエストを起こして、その日のホテルの部屋を確保してもよい。
Ｓ４０２において、プラットフォームサーバは、決定した在庫要求に応じて、デフォルトユーザ情報を保持する第２の予約リクエストを取引対象サーバに送る。
実際の実施態様では、プラットフォームサーバはまた、在庫の予約情報内に未予約の取引対象が残っていると判定したときに、クライアントターミナルが実際に起こした予約リクエストにより、取引対象サーバに対して予約キャンセルリクエストを起こしてもよい。たとえば、プラットフォームサーバは、７：００ａｍにチェーンホテルの１０つのスタンダードルームの予約をリクエストし、６：００ｐｍにおいて５つの部屋が予約されずに残っていることを見出す。このときに、プラットフォームサーバは、５部屋の予約をキャンセルするリクエストを起こすことができる。
Ｓ４０３において、プラットフォームサーバは、取引対象サーバが返した、予約成功についての情報を保持する第２の予約結果を受け取って、このような情報を初期在庫の予約情報として用いる。
Ｓ４０４において、クライアントターミナルは、ユーザが提出した予約対象情報を受け取る。
Ｓ４０５において、クライアントターミナルは、受け取った予約対象情報に基づいて、予約対象情報を保持する第１の予約リクエストとクライアントターミナルユーザ情報とをプラットフォームサーバに送る。
Ｓ４０６において、プラットフォームサーバは、第１の予約リクエスト内の予約対象情報と在庫の予約情報とにより、在庫の予約情報が第１の予約リクエストを満足するか否かを判定する。そうである場合には、Ｓ４０７ａを行い、そうでない場合にはＳ４０７ｂを行う。
Ｓ４０７ａにおいて、在庫の予約情報が第１の予約リクエストを満足するときに、プラットフォームサーバは、第１の予約リクエストに対応する予約対象情報とクライアントターミナルユーザ情報とに基づいて第１の予約結果を生成して、在庫の予約情報を更新する。次に、Ｓ４０８及びＳ４０９を行う。
Ｓ４０８において、予約情報更新リクエストを取引対象サーバに送って、第２の予約リクエストを送るときに用いたデフォルトユーザ情報から、クライアントターミナルユーザ情報に、第１の予約結果に付随するユーザ情報の更新をリクエストする。
Ｓ４０７ｂにおいて、在庫の予約情報が第１の予約リクエストを満足しない場合は、プラットフォームサーバが取引対象サーバに第１の予約リクエストを送って、取引対象サーバによってフィードバックされた第１の予約結果を受け取る。
ここで、プラットフォームサーバは通常の予約プロセスに基づいて予約を起こす。
Ｓ４０９において、プラットフォームサーバは第１の予約結果をクライアントターミナルにフィードバックする。
ここで、クライアントターミナルは、第１の予約リクエスト内の予約対象情報と在庫の予約情報とに基づいてプラットフォームサーバによってフィードバックされた第１の予約結果を受け取る。
前述の実施形態例を用いて、プラットフォームサーバは、ユーザが実際にプラットフォームサーバに対して予約リクエストを起こす前に、システム外部の取引対象サーバに対してあらかじめ予約リクエストを起こし、取得した予約結果を初期在庫の予約情報として記憶することができる。クライアントターミナルが実際に起こした予約リクエストを受け取った後に、ユーザの実際の予約リクエストに対応する予約結果を、ローカル在庫の予約情報に基づいてクライアントターミナルに返す。したがって、プラットフォームサーバは、クライアントターミナルからのリクエストを受け取ったときに取引対象サーバに対してリクエストを起こす必要はなく、クライアントターミナルは、プラットフォームサーバが返した予約結果を遅れずに取得することができ、その結果、予約効率及び予約成功率が向上し、そしてユーザ経験が改善される。
同じ発明概念に基づいて、取引対象予約方法に対応する取引対象予約システム及び装置が、本発明の実施形態例においてさらに提供される。問題を解決するシステム及び装置に対する原理は、本出願の実施形態例による取引対象予約方法のそれと同様であり、したがって、システム及び装置を実施するための方法の実施態様に言及することができ、繰り返される部分についてはここでは詳しくは述べない。
実施形態例３
図５は、本出願の実施形態例３による取引対象予約システム５００の概略図であり、以下が含まれる。プラットフォームサーバ５１。プラットフォームサーバ５１は、クライアントターミナルによって送られた、予約対象情報を保持する第１の予約リクエストを受け取ることと、予約対象情報と在庫の予約情報とにより、在庫の予約情報が第１の予約リクエストを満足するか否かを判定することであって、在庫の予約情報は、予約対象情報を保持する第２の予約リクエストをプラットフォームサーバがあらかじめ起こすことによって取得される、判定することと、そうである場合に、第１の予約リクエストに対応する第１の予約結果を生成することと、そうでない場合に、第１の予約リクエストを取引対象サーバに送って第１の予約結果を取得することと、第１の予約結果をクライアントターミナルにフィードバックすることと、を行うように構成されている。クライアントターミナル５２。クライアントターミナル５２は、ユーザが提出した予約対象情報を受け取って、予約対象情報に基づいてプラットフォームサーバに第１の予約リクエストを送ることと、第１の予約リクエスト内の予約対象情報と在庫の予約情報とに基づいてプラットフォームサーバによってフィードバックされた第１の予約結果を受け取ることと、を行うように構成されている。取引対象サーバ５３。取引対象サーバ５３は、プラットフォームサーバがあらかじめ起こした第２の予約リクエストを受け取って、プラットフォームサーバに第２の予約結果をフィードバックすることであって、第２の予約結果には、第２の予約リクエストに対応する予約成功についての情報が含まれ、情報はプラットフォームサーバの初期在庫の予約情報となる、フィードバックすることと、ユーザが起こし、プラットフォームサーバによって送られた第１の予約リクエストを受け取って、プラットフォームサーバに第１の予約結果をフィードバックすることと、を行うように構成されている。
任意的に、予約対象はホテルの部屋であり、取引対象サーバはホテル管理サーバであり、予約対象情報には予約したホテルの名前及び部屋タイプが含まれる。
任意的に、プラットフォームサーバ５１は具体的に、過去の予約データにより将来の予約時間帯における在庫要求を決定するステップであって、過去の予約データには、予約対象に対して実際にユーザが起こした予約の予約データが含まれ、在庫要求には、取引対象サーバによって与えられる予約対象に対する様々なユーザの要求の総数量が含まれるステップと、決定された在庫要求に応じて第２の予約リクエストを取引対象サーバに送るステップと、により第２の予約リクエストを起こすように構成されている。
任意的に、クライアントターミナルユーザ情報はさらに第１の予約リクエスト内に保持され、デフォルトユーザ情報はさらに第２の予約リクエスト内に保持されており、在庫の予約情報が第１の予約リクエストを満足するときに、プラットフォームサーバ５１は具体的に、第１の予約リクエスト内に保持されるクライアントターミナルユーザ情報と第１の予約リクエストに対応する予約対象情報とに基づいて、第１の予約結果を生成するステップであって、第１の予約結果には、第１の予約リクエストに対応する予約成功についての情報とクライアントターミナルユーザ情報とが含まれるステップにより、第１の予約結果を生成するように構成され、プラットフォームサーバ５１はさらに、第１の予約結果を生成した後に取引対象サーバに予約情報更新リクエストを送ることであって、予約情報更新リクエストは、第２の予約リクエストが送られたときに用いられたデフォルトユーザ情報から、クライアントターミナルユーザ情報に、第１の予約結果に付随するユーザ情報を更新することをリクエストするように構成されている、送ることを行うように構成され、取引対象サーバ５３はさらに、予約情報更新リクエストにより、第１の予約結果に付随する記憶されたユーザ情報を、デフォルトユーザ情報からクライアントターミナルユーザ情報に更新するように構成されている。
任意的に、プラットフォームサーバ５１はさらに、在庫の予約情報が更新された後に、予約対象の在庫数量が設定閾値よりも小さいか否かを判定することと、そうである場合には、マネージャに在庫警告情報をプッシュして、マネージャに在庫を補充するかまたは取引対象サーバに対して自動的に予約プロセスを起こすかの選択を促すことと、を行うように構成されている。
実施形態例４
図６は本出願の実施形態例４によるプラットフォームサーバ６００の概略構造図であり、以下が含まれる。受信モジュール６１。受信モジュール６１は、クライアントターミナルによって送られた、予約対象情報を保持する第１の予約リクエストを受け取るように構成されている。予約処理モジュール６２。予約処理モジュール６２は、第１の予約リクエスト内の予約対象情報と在庫の予約情報とにより、在庫の予約情報が第１の予約リクエストを満足するか否かを判定することであって、在庫の予約情報には、予約対象情報を保持する第２の予約リクエストを取引対象サーバに対して送信モジュール６３が事前に起こした後に取得された予約成功についての情報が含まれる、判定することと、在庫の予約情報が第１の予約リクエストを満足する場合に、第１の予約リクエストに対応する予約対象情報に基づいて第１の予約結果を生成することと、在庫の予約情報が第１の予約リクエストを満足しない場合に、送信モジュール６３を制御して第１の予約リクエストを取引対象サーバに送り、取引対象サーバによってフィードバックされた第１の予約結果を受信モジュール６１によって取得することと、を行うように構成されている。送信モジュール６３はさらに、第１の予約結果をクライアントターミナルにフィードバックするように構成されている。
任意的に、予約処理モジュール６２は具体的に、第２の予約リクエストを、過去の予約データにより将来の予約時間帯における在庫要求を決定するステップであって、過去の予約データには、予約対象に対して実際にユーザが起こした予約の予約データが含まれ、在庫要求には、取引対象サーバによって与えられる予約対象に対する様々なユーザの要求の総数量が含まれるステップと、決定された在庫要求に応じて第２の予約リクエストを取引対象サーバに送るステップと、により行うように構成されている。
任意的に、クライアントターミナルユーザ情報はさらに第１の予約リクエスト内に保持され、フォルトユーザ情報はさらに第２の予約リクエスト内に保持されており、予約処理モジュール６２は具体的に、第１の予約リクエスト内に保持されたクライアントターミナルユーザ情報と第１の予約リクエストに対応する予約対象情報とに基づいて、第１の予約結果を生成するステップであって、第１の予約結果には、第１の予約リクエストに対応する予約成功についての情報とクライアントターミナルユーザ情報とが含まれるステップにより第１の予約結果を生成するように構成されており、送信モジュール６３はさらに、取引対象サーバに予約情報更新リクエストを送ることであって、予約情報更新リクエストは、第２の予約リクエストが送られたときに用いられるデフォルトユーザ情報から、クライアントターミナルユーザ情報に、第１の予約結果に付随するユーザ情報を更新することをリクエストするように構成されている、送ることを行うように構成されている。
任意的に、予約処理モジュール６２はさらに、第１の予約リクエストに対応する予約対象情報に基づいて第１の予約結果を生成した後に在庫の予約情報を更新するように構成されている。
任意的に、予約処理モジュール６２はさらに、在庫の予約情報が更新された後に予約対象の在庫数量が設定閾値よりも小さいか否かを判定することと、そうである場合には、送信モジュール６３によってマネージャに在庫警告情報をプッシュして、マネージャに在庫を補充するかまたは取引対象サーバに対して自動的に予約プロセスを起こすかの選択を促すことと、を行うように構成されている。
任意的に、サービスプロバイダ識別子情報がさらに、第１の予約リクエスト内に保持されている。プラットフォームサーバ６００にはさらに、記憶モジュール６４が含まれる。記憶モジュール６４は、予約成功についての取得情報と取引対象サーバに対応するサービスプロバイダ識別子情報との間のマッピング関係を、予約対象情報を保持する第２の予約リクエストが取引対象サーバに対して送信モジュール６３によって事前に起こされた後に設定し、マッピング関係を在庫の予約情報として記憶するように構成されている。予約処理モジュール６２は具体的に、在庫の予約情報が第１の予約リクエストを満足するか否かの判定を、第１の予約リクエスト内に保持されたサービスプロバイダ識別子情報により、サービスプロバイダ識別子情報に対応する予約成功に関する情報について在庫の予約情報を検索するステップと、第１の予約リクエスト内の予約対象情報により、検索した予約成功についての情報が第１の予約リクエストを満足するか否かを判定するステップと、により行うように構成されている。
プラットフォームサーバは、ユーザが実際にプラットフォームサーバに対して予約リクエストを起こす前に、システム外部の取引対象サーバに対してあらかじめ予約リクエストを起こし、取得した予約結果を初期在庫の予約情報として記憶することができる。クライアントターミナルが実際に起こした予約リクエストを受け取った後に、ユーザの実際の予約リクエストに対応する予約結果を、ローカル在庫の予約情報に基づいてクライアントターミナルに返す。したがって、プラットフォームサーバは、クライアントターミナルからのリクエストを受け取ったときに取引対象サーバに対してリクエストを起こす必要はなく、クライアントターミナルは、プラットフォームサーバが返した予約結果を遅れずに取得することができ、その結果、予約効率及び予約成功率が向上し、そしてユーザ経験が改善される。
実施形態例５
図７は、本出願の実施形態例５によるクライアントターミナル７００の概略構造図であり、以下が含まれる。ユーザが提出した予約対象情報を受け取るように構成された第１の受信モジュール７１。予約対象情報に基づいて予約対象情報を保持する第１の予約リクエストを生成するように構成された生成モジュール７２。第１の予約リクエストを送るように構成された送信モジュール７３。第２の受信モジュール７４。第２の受信モジュール７４は、第１の予約リクエスト内の予約対象情報と在庫の予約情報とによりプラットフォームサーバによってフィードバックされた第１の予約結果を受け取ることであって、在庫の予約情報には、予約対象情報を保持する第２の予約リクエストを取引対象サーバに対してあらかじめ起こした後にプラットフォームサーバによって取得された予約成功についての情報が含まれ、第１の予約結果には、第１の予約リクエストに対応する予約成功についての情報が含まれる、受け取ることを行うように構成されている。
前述のクライアントターミナルを用いて、あらかじめ記憶した予約情報に基づいてプラットフォームサーバが返した予約結果をユーザに遅れずに返すことができ、その結果、予約効率及び予約成功率が向上し、そしてユーザ経験が改善される。
当業者であれば分かるように、本出願の実施形態例を方法、システム、またはコンピュータプログラム製品として与えてもよい。したがって、本出願は、完全なハードウェア実施形態例、完全なソフトウェア実施形態例、またはソフトウェア及びハードウェアを組み合わせた実施形態例の形態で実施してもよい。また本出願は、コンピュータ利用可能なプログラムコードを含む１つ以上のコンピュータ利用可能な記憶媒体（たとえば、これらに限定されないが、磁気ディスクメモリ、ＣＤ−ＲＯＭ、光メモリなど）上で実施されるコンピュータプログラム製品の形態であってもよい。
本出願を、本出願の実施形態例による方法、装置（システム）及びコンピュータプログラム製品のフローチャート及び／またはブロック図を参照して説明する。当然のことながら、コンピュータプログラム命令を用いて、フローチャート及び／またはブロック図における各プロセス及び／またはブロックならびにフローチャート及び／またはブロック図におけるプロセス及び／またはブロックの組み合わせを実施してもよい。これらのコンピュータプログラム命令を、汎用コンピュータ、専用コンピュータ、組み込みプロセッサ、またはマシンを形成する別のプログラマブルデータ処理デバイスのプロセッサに与えて、命令がコンピュータまたは別のプログラマブルデータ処理デバイスのプロセッサによって実行されると、フローチャートの１つ以上のプロセスならびに／またはブロック図の１つ以上のブロック内の１つ以上のプロセスにおける特定の機能を実施するように構成された装置が形成されるようにしてもよい。
またこれらのコンピュータプログラム命令を、コンピュータまたは別のプログラマブルデータ処理デバイスを特定の仕方で動作するようにガイドすることができるコンピュータ可読メモリに記憶して、コンピュータ可読メモリに記憶された命令によって命令装置を含む製造品が形成されるようにしてもよい。命令装置は、フローチャート内の１つ以上のプロセス及び／またはブロック図内の１つ以上のブロックにおいて特定された機能を実施する。
またこれらのコンピュータプログラム命令をコンピュータまたは別のプログラマブルデータ処理デバイス上にロードして、コンピュータまたは別のプログラマブルデバイス上で一連の動作ステップが行われるようにしてもよく、その結果、コンピュータ実施の処理が形成される。したがって、コンピュータまたは別のプログラマブルデバイス上で命令を実行することによって、フローチャート内の１つ以上のプロセス及び／またはブロック図内の１つ以上のブロック内で特定された機能を実施するためのステップが得られる。
本出願の好ましい実施形態例について説明してきたが、当業者であれば、基本的な創造的概念を理解したら、これらの実施形態例に対して他の変形及び変更を行うことができる。したがって、添付の請求項には、好ましい実施形態例及び本出願の範囲に入るすべての変形及び変更が組み込まれると解釈すべきことが意図されている。
当業者であれば、本出願の趣旨及び範囲から逸脱することなく、本出願に対して種々の変更及び変形を施せることが明らかである。したがって、本出願のこれらの変更及び変形が本出願の請求項及びその同等技術の範囲に含まれる場合には、本出願にはこれらの変更及び変形も組み込まれることが意図されている。

Claims (19)

  1. 取引対象予約システムであって、
    プラットフォームサーバであって、
    クライアントターミナルによって送られた、予約対象の予約対象情報を保持する第１の予約リクエストを受け取ることと、
    前記予約対象情報と在庫の予約情報とにより、前記在庫の前記予約情報が前記第１の予約リクエストを満足するか否かを判定することであって、前記在庫の前記予約情報は、前記予約対象情報を保持する第２の予約リクエストを前記プラットフォームサーバがあらかじめ起こすことによって取得される、前記判定することと、
    前記在庫の前記予約情報が前記第１の予約リクエストを満足するときに、前記第１の予約リクエストに対応する第１の予約結果を生成することと、
    前記在庫の前記予約情報が前記第１の予約リクエストを満足しないときに、前記第１の予約リクエストを取引対象サーバに送って前記第１の予約結果を取得することと、
    前記第１の予約結果を前記クライアントターミナルにフィードバックすることと、
    を行うように構成される、前記プラットフォームサーバと、
    前記クライアントターミナルであって、
    ユーザが提出した前記予約対象情報を受け取って、前記予約対象情報に基づいて前記プラットフォームサーバに前記第１の予約リクエストを送ることと、
    前記第１の予約リクエスト内の前記予約対象情報と前記在庫の前記予約情報とに基づいて、前記プラットフォームサーバによってフィードバックされた前記第１の予約結果を受け取ることと、
    を行うように構成される、前記クライアントターミナルと、
    前記取引対象サーバであって、
    前記プラットフォームサーバがあらかじめ起こした前記第２の予約リクエストを受け取って、前記プラットフォームサーバに第２の予約結果をフィードバックすることであって、前記第２の予約結果は、前記第２の予約リクエストに対応する予約成功についての情報を含み、前記情報は前記プラットフォームサーバの初期在庫の予約情報となる、前記フィードバックすることと、
    前記ユーザが起こし、前記プラットフォームサーバによって送られた前記第１の予約リクエストを受け取って、前記プラットフォームサーバに前記第１の予約結果をフィードバックすることと、
    を行うように構成される、前記取引対象サーバと、
    を備える、前記取引対象予約システム。
  2. 前記予約対象はホテルの部屋であり、
    前記取引対象サーバはホテル管理サーバであり、
    前記予約対象情報は前記ホテルの名前及び部屋タイプを含む、
    請求項１に記載のシステム。
  3. 前記プラットフォームサーバは、前記第２の予約リクエストを、
    過去の予約データにより将来の予約時間帯における在庫要求を決定するステップであって、前記過去の予約データは、前記予約対象に対して前記ユーザが実際に起こした予約の予約データを含み、前記在庫要求は、前記取引対象サーバによって与えられる予約対象に対する様々なユーザの要求の総数量を含む、前記決定するステップと、
    前記決定された在庫要求に応じて前記第２の予約リクエストを前記取引対象サーバに送るステップと、
    により起こす、
    請求項１に記載のシステム。
  4. 前記第１の予約リクエストはさらに、クライアントターミナルユーザ情報を保持し、前記第２の予約リクエストはさらに、デフォルトユーザ情報を保持し、
    前記在庫の前記予約情報が前記第１の予約リクエストを満足するときに、前記プラットフォームサーバはさらに、
    前記第１の予約リクエスト内に保持される前記クライアントターミナルユーザ情報と前記第１の予約リクエストに対応する前記予約対象情報とに基づいて、前記第１の予約結果を生成するステップであって、前記第１の予約結果は、前記第１の予約リクエストに対応する予約成功についての情報と前記クライアントターミナルユーザ情報とを含む、前記生成するステップにより、前記第１の予約結果を生成するように構成され、
    前記プラットフォームサーバはさらに、
    前記第１の予約結果を生成した後に前記取引対象サーバに予約情報更新リクエストを送ることであって、前記予約情報更新リクエストは、前記第２の予約リクエストが送られたときに用いられた前記デフォルトユーザ情報から、前記クライアントターミナルユーザ情報に、前記第１の予約結果に付随するユーザ情報を更新することをリクエストするように構成されている、前記送ることを行うように構成され、
    前記取引対象サーバはさらに、
    前記予約情報更新リクエストにより、前記第１の予約結果に付随する記憶されたユーザ情報を、前記デフォルトユーザ情報から前記クライアントターミナルユーザ情報に更新するように構成されている、
    請求項１に記載のシステム。
  5. 前記プラットフォームサーバはさらに、
    前記在庫の前記予約情報が更新された後に、前記予約対象の在庫数量が設定閾値よりも小さいか否かを判定することと、
    前記予約対象の前記在庫数量が前記設定閾値よりも小さいときに、マネージャに在庫警告情報をプッシュして、前記マネージャに前記在庫を補充するかまたは前記取引対象サーバに対して自動的に予約プロセスを開始するかの選択を促すことと、
    を行うように構成されている、
    請求項１に記載のシステム。
  6. クライアントターミナルによって送られた、予約対象情報を保持する第１の予約リクエストを、プラットフォームサーバによって受け取ることと、
    前記第１の予約リクエスト内の前記予約対象情報と在庫の予約情報とにより、前記在庫の前記予約情報が前記第１の予約リクエストを満足するか否かを判定することであって、前記在庫の前記予約情報は、前記予約対象情報を保持する第２の予約リクエストを取引対象サーバに対して前記プラットフォームサーバがあらかじめ起こすことによって取得された予約成功についての情報を含む、前記判定することと、
    前記在庫の前記予約情報が前記第１の予約リクエストを満足するときに、前記第１の予約リクエストに対応する前記予約対象情報に基づいて第１の予約結果を生成するか、または前記在庫の前記予約情報が前記第１の予約リクエストを満足しないときに、前記第１の予約リクエストを前記取引対象サーバに送って、前記取引対象サーバによってフィードバックされた前記第１の予約結果を受け取ることと、
    前記第１の予約結果を前記クライアントターミナルにフィードバックすることと、
    を含む、取引対象予約方法。
  7. 前記第２の予約リクエストを前記取引対象サーバに対して前記プラットフォームサーバによってあらかじめ起こすことは、
    過去の予約データにより前記プラットフォームサーバが将来の予約時間帯における在庫要求を決定することであって、前記過去の予約データは、予約対象に対してユーザが実際に起こした予約の予約データを含み、前記在庫要求は、前記取引対象サーバによって与えられる予約対象に対する様々なユーザの要求の総数量を含む、前記決定することと、
    前記決定された在庫要求に応じて前記第２の予約リクエストを前記取引対象サーバに送ることと、
    を含む
    請求項６に記載の方法。
  8. 前記第１の予約リクエストはさらに、クライアントターミナルユーザ情報を保持し、前記第２の予約リクエストはさらに、デフォルトユーザ情報を保持し、
    前記在庫の前記予約情報が前記第１の予約リクエストを満足するときに、前記第１の予約リクエストに対応する前記予約対象情報に基づいて前記第１の予約結果を生成することは、
    前記第１の予約リクエスト内に保持される前記クライアントターミナルユーザ情報と前記第１の予約リクエストに対応する前記予約対象情報とに基づいて、前記第１の予約結果を生成することであって、前記第１の予約結果は、前記第１の予約リクエストに対応する予約成功についての情報と前記クライアントターミナルユーザ情報とを含む、前記生成することを含み、
    前記第１の予約結果を生成した後に、前記方法はさらに、
    前記取引対象サーバに予約情報更新リクエストを送ることであって、前記予約情報更新リクエストは、前記第２の予約リクエストが送られたときに用いられた前記デフォルトユーザ情報から、前記クライアントターミナルユーザ情報に、前記第１の予約結果に付随するユーザ情報を更新することをリクエストするように構成されている、前記送ること、
    を含む
    請求項６に記載の方法。
  9. 前記第１の予約リクエストに対応する前記予約対象情報に基づいて前記第１の予約結果を生成した後に、前記方法はさらに、
    前記在庫の前記予約情報を更新することを含む、請求項６に記載の方法。
  10. 前記在庫の前記予約情報を前記更新した後に、前記方法はさらに、
    予約対象の在庫数量が設定閾値よりも小さいか否かを判定することと、
    前記予約対象の前記在庫数量が前記設定閾値よりも小さいときに、マネージャに警告情報をプッシュして、前記マネージャに前記在庫を補充するかまたは前記取引対象サーバに対して自動的に予約プロセスを開始するかの選択を促すことと、
    を含む、
    請求項９に記載の方法。
  11. 前記第１の予約リクエストはさらに、サービスプロバイダ識別子情報を保持し、
    前記予約対象情報を保持する前記第２の予約リクエストを前記取引対象サーバに対して前記プラットフォームサーバによってあらかじめ起こした後に、前記方法はさらに、
    予約成功についての取得情報と、前記取引対象サーバに対応する前記サービスプロバイダ識別子情報との間のマッピング関係を設定して、前記マッピング関係を前記在庫の前記予約情報として記憶することを含み、
    前記第１の予約リクエスト内の前記予約対象情報と前記在庫の予約情報とにより、前記在庫の前記予約情報が前記第１の予約リクエストを満足するか否かを判定することは、
    前記第１の予約リクエスト内に保持された前記サービスプロバイダ識別子情報により、前記サービスプロバイダ識別子情報に対応する予約成功に関する前記情報について前記在庫の前記予約情報を検索することと、
    前記第１の予約リクエスト内の前記予約対象情報により、予約成功についての検索情報が前記第１の予約リクエストを満足するか否かを判定することと、
    を含む、
    請求項６に記載の方法。
  12. ユーザリクエスト処理方法であって、
    ユーザが提出した予約対象情報をクライアントターミナルによって受け取ることと、
    前記予約対象情報を保持する第１の予約リクエストをプラットフォームサーバに送ることと、
    前記第１の予約リクエスト内の前記予約対象情報と在庫の予約情報とにより前記プラットフォームサーバによってフィードバックされた第１の予約結果を受け取ることであって、前記在庫の前記予約情報は、前記予約対象情報を保持する第２の予約リクエストを取引対象サーバに対して前記プラットフォームサーバがあらかじめ起こすことによって取得された予約成功についての情報を含み、前記第１の予約結果は、前記第１の予約リクエストに対応する予約成功についての情報を含む、前記受け取ることと、
    を含む、前記ユーザリクエスト処理方法。
  13. プラットフォームサーバであって、
    クライアントターミナルによって送られた、予約対象情報を保持する第１の予約リクエストを受け取るように構成された受信モジュールと、
    予約処理モジュールであって、
    前記第１の予約リクエスト内の前記予約対象情報と在庫の予約情報とにより、前記在庫の前記予約情報が前記第１の予約リクエストを満足するか否かを判定することと、
    前記在庫の前記予約情報が前記第１の予約リクエストを満足するときに、前記第１の予約リクエストに対応する前記予約対象情報に基づいて第１の予約結果を生成することと、
    前記在庫の前記予約情報が前記第１の予約リクエストを満足しないときに、送信モジュールを制御して前記第１の予約リクエストを取引対象サーバに送り、前記取引対象サーバによってフィードバックされた前記第１の予約結果を前記受信モジュールによって取得することと、
    を行うように構成された、前記予約処理モジュールと、を含み、
    前記送信モジュールはさらに、前記第１の予約結果を前記クライアントターミナルにフィードバックするように構成され、
    前記在庫の前記予約情報は、前記予約対象情報を保持する第２の予約リクエストが前記取引対象サーバに対して前記送信モジュールによってあらかじめ起こされた後に取得された予約成功についての情報を含む、
    前記プラットフォームサーバ。
  14. 前記予約処理モジュールはさらに、
    過去の予約データにより将来の予約時間帯における在庫要求を決定するステップであって、前記過去の予約データは、予約対象に対してユーザが実際に起こした予約の予約データを含み、前記在庫要求は、前記取引対象サーバによって与えられる予約対象に対する様々なユーザの要求の総数量を含む、前記決定するステップと、
    前記決定された在庫要求に応じて前記第２の予約リクエストを前記取引対象サーバに送るステップと、
    により前記第２の予約リクエストを送るように構成されている、
    請求項１３に記載のプラットフォームサーバ。
  15. 前記第１の予約リクエストはさらに、クライアントターミナルユーザ情報を保持し、前記第２の予約リクエストはさらに、デフォルトユーザ情報を保持し、
    前記予約処理モジュールは、
    前記第１の予約リクエスト内に保持される前記クライアントターミナルユーザ情報と前記第１の予約リクエストに対応する前記予約対象情報とに基づいて、前記第１の予約結果を生成するステップであって、前記第１の予約結果は、前記第１の予約リクエストに対応する予約成功についての情報と前記クライアントターミナルユーザ情報とを含まれる、前記生成するステップにより前記第１の予約結果を生成するように構成され、
    前記送信モジュールはさらに、
    前記取引対象サーバに予約情報更新リクエストを送ることであって、前記予約情報更新リクエストは、前記第２の予約リクエストが送られたときに用いられた前記デフォルトユーザ情報から、前記クライアントターミナルユーザ情報に、前記第１の予約結果に付随するユーザ情報を更新することをリクエストするように構成されている、前記送ることを行うように構成されている、
    請求項１３に記載のプラットフォームサーバ。
  16. 前記予約処理モジュールはさらに、
    前記第１の予約リクエストに対応する前記予約対象情報に基づいて前記第１の予約結果を生成した後に、前記在庫の前記予約情報を更新するように構成されている、
    請求項１３に記載のプラットフォームサーバ。
  17. 前記予約処理モジュールはさらに、
    前記在庫の前記予約情報が更新された後に、予約対象の在庫数量が設定閾値よりも小さいか否かを判定することと、
    前記予約対象の前記在庫数量が前記設定閾値よりも小さいときに、前記送信モジュールによってマネージャに在庫警告情報をプッシュして、前記マネージャに前記在庫を補充するかまたは前記取引対象サーバに対して自動的に予約プロセスを開始するかの選択を促すことと、
    を行うように構成されている、
    請求項１６に記載のプラットフォームサーバ。
  18. 前記第１の予約リクエストはさらに、サービスプロバイダ識別子情報を保持し、
    前記プラットフォームサーバはさらに、
    記憶モジュールであって、予約成功についての取得情報と、前記取引対象サーバに対応する前記サービスプロバイダ識別子情報との間のマッピング関係を、前記予約対象情報を保持する前記第２の予約リクエストが前記取引対象サーバに対して前記送信モジュールによって事前に起こされた後に設定し、前記マッピング関係を前記在庫の前記予約情報として記憶するように構成された前記記憶モジュールを含み、
    前記予約処理モジュールはさらに、前記在庫の前記予約情報が前記第１の予約リクエストを満足するか否かの判定を、
    前記第１の予約リクエスト内に保持された前記サービスプロバイダ識別子情報により、前記サービスプロバイダ識別子情報に対応する予約成功に関する前記情報について前記在庫の前記予約情報を検索するステップと、
    前記第１の予約リクエスト内の前記予約対象情報により、検索した予約成功についての前記情報が前記第１の予約リクエストを満足するか否かを判定するステップと、
    により行うように構成されている、
    請求項１３に記載のプラットフォームサーバ。
  19. クライアントターミナルであって、
    ユーザが提出した予約対象情報を受け取るように構成された第１の受信モジュールと、
    前記予約対象情報に基づいて前記予約対象情報を保持する第１の予約リクエストを生成するように構成された生成モジュールと、
    前記第１の予約リクエストを送るように構成された送信モジュールと、
    前記第１の予約リクエスト内の前記予約対象情報と在庫の予約情報とによりプラットフォームサーバによりフィードバックされた第１の予約結果を受け取るように構成された第２の受信モジュールであって、前記在庫の前記予約情報は、前記予約対象情報を保持する第２の予約リクエストを取引対象サーバに対して前記プラットフォームサーバがあらかじめ起こすことによって取得された予約成功についての情報を含み、前記第１の予約結果は、前記第１の予約リクエストに対応する予約成功についての情報を含む、前記第２の受信モジュールと、
    を含む、前記クライアントターミナル。
JP2019539285A 2017-01-20 2018-01-09 取引対象予約システム、方法、及び装置 Pending JP2020506470A (ja)

Applications Claiming Priority (3)

Application Number Priority Date Filing Date Title
CN201710045851.1A CN108334964A (zh) 2017-01-20 2017-01-20 一种业务对象预订系统、方法及装置
CN201710045851.1 2017-01-20
PCT/CN2018/071872 WO2018133699A1 (zh) 2017-01-20 2018-01-09 一种业务对象预订系统、方法及装置

Publications (1)

Publication Number Publication Date
JP2020506470A true JP2020506470A (ja) 2020-02-27

Family

ID=62907720

Family Applications (1)

Application Number Title Priority Date Filing Date
JP2019539285A Pending JP2020506470A (ja) 2017-01-20 2018-01-09 取引対象予約システム、方法、及び装置

Country Status (6)

Country Link
US (1) US20190340710A1 (ja)
JP (1) JP2020506470A (ja)
KR (1) KR20190103199A (ja)
CN (1) CN108334964A (ja)
TW (1) TWI751213B (ja)
WO (1) WO2018133699A1 (ja)

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2021179666A (ja) * 2020-05-11 2021-11-18 Kddi株式会社 管理装置、対象物確保方法及びプログラム

Families Citing this family (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN108460507A (zh) * 2017-02-22 2018-08-28 阿里巴巴集团控股有限公司 订单处理方法、交易系统及服务器
US11657322B2 (en) * 2018-08-30 2023-05-23 Nec Corporation Method and system for scalable multi-task learning with convex clustering
CN112836838B (zh) * 2021-02-10 2022-03-11 北京声智科技有限公司 预约请求处理方法、装置、设备及存储介质

Family Cites Families (7)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN100334586C (zh) * 2003-03-05 2007-08-29 珠海金山软件股份有限公司 针对团体入住的酒店管理系统
CN1851749A (zh) * 2005-04-22 2006-10-25 马颖 看图购物超市及其经营管理方法
US11030635B2 (en) * 2013-12-11 2021-06-08 Skyscanner Limited Method and server for providing a set of price estimates, such as air fare price estimates
CN104809506A (zh) * 2015-03-30 2015-07-29 张泽 房间信息交互方法、装置及系统
CN104751386A (zh) * 2015-04-14 2015-07-01 携程计算机技术（上海）有限公司 酒店的分布式比价方法
CN105512901A (zh) * 2015-12-24 2016-04-20 上海携程商务有限公司 客户服务自动提供系统及方法
TWM533788U (en) * 2016-08-29 2016-12-11 First Commercial Bank Co Ltd Global fund management system

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2021179666A (ja) * 2020-05-11 2021-11-18 Kddi株式会社 管理装置、対象物確保方法及びプログラム

Also Published As

Publication number Publication date
US20190340710A1 (en) 2019-11-07
KR20190103199A (ko) 2019-09-04
WO2018133699A1 (zh) 2018-07-26
TW201828174A (zh) 2018-08-01
TWI751213B (zh) 2022-01-01
CN108334964A (zh) 2018-07-27

Similar Documents

Publication Publication Date Title
CN109948017B (zh) 一种信息处理方法及装置
JP2020506470A (ja) 取引対象予約システム、方法、及び装置
US10922646B1 (en) Multi-echelon inventory planning under dynamic fulfillment policies
WO2019246622A1 (en) Request optimization for a network-based service
CN105592117B (zh) 一种事务消息的处理方法和装置
CN109426989B (zh) 一种订购处理方法、提供预约服务方法及设备
WO2010133421A1 (en) Improvements in or relating to a method and system of booking management
CN105096122B (zh) 一种分片式交易匹配方法和装置
US9900403B2 (en) Method and server for assigning relative order to message by using vector clock and delivering the message based on the assigned relative order under distributed environment
US20160140489A1 (en) Managing warehouse information
CN111813868B (zh) 数据同步方法及装置
CN106952085B (zh) 一种数据存储与业务处理的方法及装置
CN111563125B (zh) 数据存储系统、数据查询方法及装置
US20180129528A1 (en) Predicting transaction outcome based on artifacts in a transaction processing environment
CN110908793A (zh) 长时任务执行方法、装置、设备及可读存储介质
CN110659272A (zh) 数据清洗方法和系统
CN103607415A (zh) 一种请求资源分配的方法、客户端和服务器
WO2016077225A1 (en) Managing warehouse information
CN107203915B (zh) 数据存储方法及装置
US11288092B2 (en) Dynamically adjusting reconciliation time-delays
US9336536B1 (en) Pre-generating blank application instances to improve response time
US20190362294A1 (en) Systems and computer-implemented methods for dynamic and automatic resource management
KR102421046B1 (ko) 자동으로 발주서를 생성하는 약국 단말 및 약국 단말의 동작 방법
CN110738340B (zh) 预约产品的库存管理方法及装置
US10733020B2 (en) Resource allocation state management

Legal Events

Date Code Title Description
A521 Request for written amendment filed

Free format text: JAPANESE INTERMEDIATE CODE: A523

Effective date: 20190723