特許 6687802 サービス処理方法及び装置

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

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

(11)【特許番号】6687802

(24)【登録日】2020年4月6日

(45)【発行日】2020年4月28日

(54)【発明の名称】サービス処理方法及び装置

(51)【国際特許分類】

   G06Q 30/06 20120101AFI20200421BHJP

   G06F 9/50 20060101ALI20200421BHJP

   G06Q 20/08 20120101ALI20200421BHJP

【ＦＩ】

   G06Q30/06 300

   G06F9/50 150B

   G06Q20/08

【請求項の数】10

【全頁数】18

(21)【出願番号】特願2019-503611(P2019-503611)

(86)(22)【出願日】2017年3月29日

(65)【公表番号】特表2019-519052(P2019-519052A)

(43)【公表日】2019年7月4日

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

(87)【国際公開番号】WO2017177821

(87)【国際公開日】20171019

【審査請求日】2018年10月24日

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

(32)【優先日】2016年4月11日

(33)【優先権主張国】CN

(73)【特許権者】

【識別番号】510330264

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

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

(74)【代理人】

【識別番号】100099759

【弁理士】

【氏名又は名称】青木 篤

(74)【代理人】

【識別番号】100123582

【弁理士】

【氏名又は名称】三橋 真二

(74)【代理人】

【識別番号】100114018

【弁理士】

【氏名又は名称】南山 知広

(74)【代理人】

【識別番号】100119987

【弁理士】

【氏名又は名称】伊坪 公一

(74)【代理人】

【識別番号】100159259

【弁理士】

【氏名又は名称】竹本 実

(72)【発明者】

【氏名】フー ツォンワン

【審査官】 鈴木 和樹

(56)【参考文献】

【文献】 米国特許出願公開第２００６／０２７１４９７（ＵＳ，Ａ１）

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

【文献】 特表２０１２−５１９９０７（ＪＰ，Ａ）

【文献】 中国特許出願公開第１０３０２０８１５（ＣＮ，Ａ）

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

Ｇ０６Ｑ １０／００ − ９９／００

Ｇ０６Ｆ ９／５０

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

【請求項1】

第１サービス機能を所有する第１サーバが、クライアントによって送信された第１サービス要求を受信するステップと、
前記第１サービス要求に基づいて第１サービス結果を生成するステップと、
第２サーバが、前記第１サービス結果に基づいて第２サービス結果を直接生成するため、且つ、前記第２サーバが前記第１サービス結果に基づいて前記クライアントによって生成された第２サービス要求を受信した後に、前記生成された第２サービス結果を前記クライアントに送信するために、前記第１サービス結果を前記クライアント及び第２サービス機能を所有する前記第２サーバに送信するステップであって、前記第２サーバは、前記第１サーバが前記第１サービス結果を前記クライアントに送信した後、且つ、前記第２サーバが前記第２サービス要求を前記クライアントから受信する前に、前記第２サービス結果を生成する、ステップと、
を含む、サービス処理方法。

【請求項2】

前記第１サービス要求は、発注要求であり、
前記第１サーバは、発注サーバを含み、
前記第１サービス結果は、注文情報を含み、
前記第２サーバは、支払サーバを含み、
第１サーバがクライアントによって送信された第１サービス要求を受信するステップは、前記発注サーバが、前記クライアントによって送信された前記発注要求を受信するステップを含み、
前記第１サービス要求に基づいて第１サービス結果を生成するステップは、前記発注要求に基づいて前記注文情報を生成するステップを含み、
前記第１サービス結果を前記クライアント及び第２サービス機能を所有する第２サーバに送信するステップは、発注情報を前記クライアント及び前記発注要求に関連付けられた前記支払サーバに送信するステップを含む、請求項１に記載の方法。

【請求項3】

第２サービス機能を所有する第２サーバが、第１サービス機能を所有する第１サーバによって送信された第１サービス結果を受信するステップであって、前記第１サービス結果は、前記第１サーバがクライアントによって送信された第１サービス要求を処理した後に生成される、ステップと、
前記第１サービス結果に基づいて第２サービス結果を生成するステップと、
前記第２サーバが、前記クライアントによって送信された第２サービス要求を受信するステップと、
前記第２サービス要求を受信した後に、前記生成された第２サービス結果を前記クライアントにフィードバックするステップと、
を含み、
前記第２サーバは、前記第１サーバが前記第１サービス結果を前記クライアントに送信した後、且つ、前記第２サーバが前記第２サービス要求を前記クライアントから受信する前に、前記第２サービス結果を生成する、サービス処理方法。

【請求項4】

前記第２サーバは、支払サーバを含み、
前記第１サーバは、発注サーバを含み、
前記第１サービス結果は、注文情報を含み、
前記第２サービス結果は、注文情報を含む支払ページを含み、
前記第２サービス要求は、支払要求を含み、
第２サーバが、第１サーバによって送信された第１サービス結果を受信するステップは、前記支払サーバが、前記発注サーバによって送信された前記注文情報を受信するステップを含み、
前記第１サービス結果に基づいて第２サービス結果を生成するステップは、前記注文情報に基づいて前記注文情報を含む前記支払ページを生成するステップを含み、
前記第２サービス要求を受信した後に、前記生成された第２サービス結果を前記クライアントにフィードバックするステップは、前記支払要求を受信した後に、注文情報を含む前記生成された支払ページを前記クライアントにフィードバックするステップを含む、請求項３に記載の方法。

【請求項5】

第２サービス機能を所有する第２サーバが、第１サービス機能を所有する第１サーバによって送信された第１サービス結果を受信するステップであって、前記第１サービス結果は、前記第１サーバがクライアントによって送信された第１サービス要求を処理した後に生成される、ステップと、
前記第１サービス結果に基づいて第２サービス結果を生成するステップと、
前記第２サービス結果に基づいてサービスインタフェースをレンダリング及び形成するステップと、
前記第２サーバが前記クライアントによって送信された第２サービス要求を受信した後に、前記レンダリング及び形成されたサービスインタフェースを前記クライアントに表示のために送信するステップと、
を含み、
前記第２サーバは、前記第１サーバが前記第１サービス結果を前記クライアントに送信した後、且つ、前記第２サーバが前記第２サービス要求を前記クライアントから受信する前に、前記第２サービス結果を生成する、サービス処理方法。

【請求項6】

クライアントによって送信された第１サービス要求を受信するように構成される受信モジュールと、
前記第１サービス要求に基づいて第１サービス結果を生成するように構成される処理モジュールと、
第２サーバが、前記第１サービス結果に基づいて第２サービス結果を直接生成するため、且つ、前記第２サーバが前記第１サービス結果に基づいて前記クライアントによって生成された第２サービス要求を受信した後に、前記生成された第２サービス結果を前記クライアントに送信するために、前記第１サービス結果を前記クライアント及び第２サービス機能を所有する前記第２サーバに送信するように構成される送信モジュールと、
を含み、
前記第２サーバは、前記送信モジュールが前記第１サービス結果を前記クライアントに送信した後、且つ、前記第２サーバが前記第２サービス要求を前記クライアントから受信する前に、前記第２サービス結果を生成する、サービス処理装置。

【請求項7】

前記第１サービス要求は、発注要求を含み、
前記第１サービス結果は、注文情報を含み、
前記第２サーバは、支払サーバを含み、
前記受信モジュールは、前記クライアントによって送信された前記発注要求を受信するように構成され、
前記処理モジュールは、前記発注要求に基づいて前記注文情報を生成するように構成され、
前記送信モジュールは、発注情報を前記クライアント及び前記発注要求に関連付けられた支払サーバに送信するように構成される、請求項６に記載の装置。

【請求項8】

第１サービス機能を所有する第１サーバによって送信された第１サービス結果を受信するように構成される受信モジュールであって、前記第１サービス結果は、前記第１サーバがクライアントによって送信された第１サービス要求を処理した後に生成される、受信モジュールと、
前記第１サービス結果に基づいて第２サービス結果を生成するように構成される処理モジュールと、
前記受信モジュールが前記クライアントによって送信された第２サービス要求を受信した後に、生成された第２サービス結果を前記クライアントにフィードバックするように構成されるフィードバックモジュールと、
を含み、
前記処理モジュールは、前記第１サーバが前記第１サービス結果を前記クライアントに送信した後、且つ、前記受信モジュールが前記第２サービス要求を前記クライアントから受信する前に、前記第２サービス結果を生成する、サービス処理装置。

【請求項9】

前記第１サーバは、発注サーバを含み、
前記第１サービス結果は、注文情報を含み、
前記第２サービス結果は、注文情報を含む支払ページを含み、
前記第２サービス要求は、支払要求を含み、
前記受信モジュールは、前記発注サーバによって送信された前記注文情報を受信するように構成され、
前記処理モジュールは、前記注文情報に基づいて前記注文情報を含む前記支払ページを生成するように構成され、
前記フィードバックモジュールは、前記受信モジュールが前記支払要求を受信した後に、前記生成された支払ページを前記クライアントにフィードバックするように構成される、請求項８に記載の装置。

【請求項10】

第１サービス機能を所有する第１サーバによって送信された第１サービス結果を受信するように構成される受信モジュールであって、前記第１サービス結果は、前記第１サーバがクライアントによって送信された第１サービス要求を処理した後に生成される、受信モジュールと、
前記第１サービス結果に基づいて第２サービス結果を生成するように構成される生成モジュールと、
前記第２サービス結果に基づいてサービスインタフェースをレンダリング及び形成するように構成されるレンダリングモジュールと、
前記受信モジュールが前記クライアントによって送信された第２サービス要求を受信した後に、前記レンダリング及び形成されたサービスインタフェースを前記クライアントに表示のために送信するように構成されるフィードバックモジュールと、
を含み、
前記生成モジュールは、前記第１サーバが前記第１サービス結果を前記クライアントに送信した後、且つ、前記受信モジュールが前記第２サービス要求を前記クライアントから受信する前に、前記第２サービス結果を生成する、サービス処理装置。

【発明の詳細な説明】

【技術分野】

【0001】

本出願は、２０１６年４月１１日に出願され、発明の名称が“SERVICE PROCESSING METHOD AND DEVICE”である中国特許出願第２０１６１０２１９４０８．７号に対する優先権を主張するものであり、その全体の参照によって、当該出願の全ての内容は、ここに引用される。

【0002】

本出願は、コンピュータ技術の分野に関連し、特に、サービス処理方法及び装置に関連する。

【背景技術】

【0003】

オンラインシステム（例：Ｗｅｂサイト）のバックエンドは、通常、様々なサービスシステムを含み、異なるサービスシステムは、異なるサービス機能を有する。従って、これらのサービスシステムにサポートされることによって、オンラインシステムは、様々なサービスをユーザに提供できる。

【0004】

現在、応用のシナリオにおいて、ユーザによって開始され、ブラウザまたはアプリケーション（ＡＰＰ）のようなクライアントを経由するサービス要求は、複数のサービスシステムが相乗効果を発揮して動作し完了することを要求することがある。

【0005】

現在の技術において、そのようなサービス要求の処理は、以下の通りである：サービスフローのシーケンスに従って、最初に、このサービス要求を処理するサービスシステムは、対応する処理結果（中間結果とも称される）を生成し、それをクライアントに返送する。中間結果に基づいて、クライアントは、次のサービスシステムが後続の処理を遂行するために、サービスフローの次のサービスシステムにリダイレクトし、要求（中間要求とも称される）を開始する。これは、サービスフローの全体が完了するまで継続する。

【0006】

例えば、クライアントによって発行されたサービス要求は、完了のためにサービスシステムＡ及びＢを必要とすると仮定する。サービスフローに従って、このサービス要求は、サービスシステムＡによって最初に処理され、中間結果が生成される。この時、サービスステムＡは、中間結果をクライアントに返送する。このクライアントは、中間結果に基づいてサービスシステムＢにリダイレクトし、サービスシステムＢに要求をさらに発行する。サービスシステムＢは、この要求を処理し、サービス結果ｂを生成し、それをクライアントに返送する。

【0007】

しかしながら、現在の技術的アプローチでは、オンラインシステム内のサービスシステムは、クライアントと相互作用するためにインターネットを使用し、インターネットのネットワーク環境は、安定性に乏しい。ネットワーク環境によって影響されるネットワーク遅延のために、中間サービス結果に基づいて中間要求を次のサービスシステムに送信することは、クライアントにとって長い時間がかかることがある。加えて、このアプローチにおいて、サービスシステムは、クライアントの要求を受信した後に対応する処理を行うことのみ可能であり、オンラインシステムは、通常、多くのユーザによってアクセスされ、各サービスシステムに重い作業負荷を引き起こし、サービスシステム処理の待ち行列における要求の待ち時間の原因となる。明らかに、要求送信段階及び処理段階において遅延が生じる可能性があり、それはクライアントに対して長い待ち時間を必然的に引き起こし、サービス処理プロセスに対して時間的有効性の乏しさをもたらす。

【発明の概要】

【0008】

本出願の実施形態は、サービス処理プロセスに対する時間的有効性の乏しさの既存の問題を解決するために、サービス処理方法及び装置を提供する。

【0009】

本出願の実施形態によって提供されるサービス処理方法は、
第１サービス機能を所有する第１サーバが、クライアントによって送信された第１サービス要求を受信するステップと、
第１サービス要求に基づいて第１サービス結果を生成するステップと、
第２サーバが、第１サービス結果に基づいて第２サービス結果を直接生成するため、且つ、第２サーバが第１サービス結果に基づいてクライアントによって生成された第２サービス要求を受信した後に、生成された第２サービス結果をクライアントに送信するために、第１サービス結果をクライアント及び第２サービス機能を所有する第２サーバに送信するステップと、を含む。

【0010】

本出願の実施形態によって同様に提供されるサービス処理方法は、
第２サービス機能を所有する第２サーバが、第１サービス機能を所有する第１サーバによって送信された第１サービス結果を受信するステップであって、第１サービス結果は、第１サーバがクライアントによって送信された第１サービス要求を処理した後に生成される、ステップと、
第１サービス結果に基づいて第２サービス結果を生成するステップと、を含む。

【0011】

本出願の実施形態によって提供される他のサービス処理方法は、
第２サービス機能を所有する第２サーバが、第１サービス機能を所有する第１サーバによって送信された第１サービス結果を受信するステップであって、第１サービス結果は、第１サーバがクライアントによって送信された第１サービス要求を処理した後に生成される、ステップと、
第１サービス結果に基づいて第２サービス結果を生成するステップと、
第２サービス結果に基づいてサービスインタフェースをレンダリング及び形成するステップと、
第２サーバがクライアントによって送信された第２サービス要求を受信した後に、レンダリング及び形成されたサービスインタフェースをクライアントに表示のために送信するステップと、を含む。

【0012】

本出願の実施形態によって提供されるサービス処理装置は、
クライアントによって送信された第１サービス要求を受信するように構成される受信モジュールと、
第１サービス要求に基づいて第１サービス結果を生成するように構成される処理モジュールと、
第２サーバが、第１サービス結果に基づいて第２サービス結果を直接生成するため、且つ、第２サーバが第１サービス結果に基づいてクライアントによって生成された第２サービス要求を受信した後に、生成された第２サービス結果をクライアントに送信するために、第１サービス結果をクライアント及び第２サービス機能を所有する第２サーバに送信するように構成される送信モジュールと、を含む。

【0013】

本出願の実施形態によって提供される他のサービス処理装置は、
第１サービス機能を所有する第１サーバによって送信された第１サービス結果を受信するように構成される受信モジュールであって、第１サービス結果は、第１サーバがクライアントによって送信された第１サービス要求を処理した後に生成される、受信モジュールと、
第１サービス結果に基づいて第２サービス結果を生成するように構成される処理モジュールと、を含む。

【0014】

本出願の実施形態によって提供される他のサービス処理装置は、
第１サービス機能を所有する第１サーバによって送信された第１サービス結果を受信するように構成される受信モジュールであって、第１サービス結果は、第１サーバがクライアントによって送信された第１サービス要求を処理した後に生成される、受信モジュールと、
第１サービス結果に基づいて第２サービス結果を生成するように構成される生成モジュールと、
第２サービス結果に基づいてサービスインタフェースをレンダリング及び形成するように構成されるレンダリングモジュールと、
受信モジュールがクライアントによって送信された第２サービス要求を受信した後に、レンダリング及び形成されたサービスインタフェースをクライアントに表示のために送信するように構成されるフィードバックモジュールと、を含む。

【0015】

本出願の実施形態は、サービス処理方法及び装置を提供する。この方法によって、第１サーバがクライアントによって発行された第１サービス要求を受信した後に、第１サービス要求は処理され、対応する第１サービス結果が生成される。この時、第１サービス結果をクライアントに返送することに加えて、第１サーバは、サービスフローに従って、この第１サービス結果を第２サーバに送信してよい。このような方法で、第２サーバは、第１サービス結果を迅速に処理し、次に第２サービス結果を生成できる。このアプローチを使用することにより、第２サーバは、クライアントから第２サービス要求を受信するより前に、第２サービス結果を生成できる。第２サーバは、クライアントによって送信された第２要求を受信した後に、既に生成された第２サービス結果をクライアントに直接返送できる。明らかに、現在の技術のアプローチと比較して、第２サーバは、第１サービス結果に基づいて、クライアントの第２サービス要求を受信する前に前もって第２サービス結果を生成することができ、従って、クライアントの待ち時間を効果的に減少し、サービス要求処理の時間的有効性を強化する。

【図面の簡単な説明】

【0016】

ここに説明される図面は、本出願をさらに理解するためのものであり、本出願の一部である。本出願の典型的な実施形態及びその記述は、本出願を説明するためのものであり、それらは、本出願の不適切な限定を構成しない。

【図1】本出願の実施形態によって提供される、第１サーバ側に基づくサービス処理プロセスである。

【図2】本出願の実施形態によって提供される、応用のサービス処理プロセスの模式図である。

【図3a】本出願の実施形態によって提供される、第２サーバ側に基づくサービス処理プロセスである。

【図3b】本出願の実施形態によって提供される、第２サーバ側に基づく他のサービス処理プロセスである。

【図4】本出願の実施形態によって提供される、第１サーバ側に基づくサービス処理装置の構造の模式図である。

【図5】本出願の実施形態によって提供される、第２サーバ側に基づくサービス処理装置の構造の模式図である。

【図6】本出願の実施形態によって提供される、第２サーバ側に基づく他のサービス処理装置の構造の模式図である。

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

【0017】

本出願の目的、技術的スキーム及び長所を明確にするために、本出願の詳細な実施形態及び対応する図面と共に、本出願の技術的スキームの明確な、大局的な記述が以下に与えられる。明らかに、説明される実施形態は、本出願の実施形態の単なる一部に過ぎず、実施形態の全ての補足ではない。本出願の実施形態に基づいて、創造的な仕事をすることなく、当業者によって取得される全ての他の実施形態は、本出願の保護の範囲に含まれなければならない。

【0018】

前述の通り、ユーザが完了のために複数のサービスシステムを必要とするオンラインシステムからサービスを取得するためにクライアントを使用するとき、クライアントは、一般に、異なるサービスシステムによって返送される中間サービス結果を受信することが必要である。中間サービス結果に基づくリダイレクトの後に、要求は、サービスフローの全体が完了するまで、次のサービスシステムに発行される。しかしながら、このプロセスにおいて、クライアントがサービスシステムに要求を送信するとき、ネットワーク環境の影響は、伝送遅延を生成し始めそうであり、サービスシステムは、クライアントによって発行されたサービス要求を受信した後に処理を行うことのみができる。サービスシステムの作業負荷が重い環境下で、処理遅延は、サービスシステムがこのサービス要求を処理するときに生成されることがある。このような方法で、クライアントは、伝送遅延及び処理遅延の二重の影響下にあり、長いクライアントの待ち時間をもたらす。明らかに、これは、サービス要求の時間的有効性に重大な影響力を有するであろう。

【0019】

従って、クライアントの待ち時間を減らすことができるサービス処理モードは、必要とされている。すなわち、本出願の実施形態は、図１に示されるサービス処理方法を提供する。

【0020】

注目すべきは、本出願の実施形態において、オンラインシステムの中からクライアントを経由してユーザが利用可能なサービスは、大抵、完了のために複数のサービスシステムを必要とするため、クライアントは、サービスフローに従って、異なるサービスシステムを対象とした異なるサービス要求を開始することがあることである。しかしながら、クライアントによって開始される異なるサービス要求は、同一のサービスを完了することとみなされ得る。

【0021】

加えて、本出願の以下で言及される第１サーバ及び第２サーバは、サービスフローにおける二つの隣接するサービスのサーバであり得る。例えば、三つのサービスサーバＡ、Ｂ及びＣが存在し、サービスを完了することは、サービスサーバＡ、サービスサーバＢ、サービスサーバＣの順序を必要とすると仮定する。サービスサーバＡ及びＢにとって、第１サーバはサービスサーバＡの可能性があり、第２サーバはサービスサーバＢの可能性がある。サービスサーバＢ及びＣにとって、第１サーバはサービスサーバＢの可能性があり、第２サーバはサービスサーバＣの可能性がある。言い換えると、本出願の第１サーバ及び第２サーバは、二つのサーバのシナリオに限られない。

【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】

これらのコンピュータプログラムの命令は、コンピュータ読み取り可能なメモリに記憶されることも可能であり、それは、コンピュータ又は他のプログラム可能なデータ処理装置に所与のモードで動作させることが可能であり、このコンピュータ読み取り可能なメモリに記憶された命令に命令装置（instruction apparatus）を含む製品を生成させる。この命令装置は、フローチャートの一つ以上のフロー及び／又はブロック図の一つ以上のブロックに明記された機能を実現する。

【0089】

これらのコンピュータプログラムの命令は、コンピュータ又は他のプログラム可能なデータ処理装置にロードされることも可能であり、コンピュータ処理を生じさせるために、コンピュータ又は他のプログラム可能な装置における一連の作業ステップの実行を可能にする。従って、コンピュータ又は他のプログラム可能な装置において実行される命令は、フローチャートの一つ以上のフロー及び／又はブロック図の一つ以上のブロックの明記された機能を実現するためのステップを提供する。

【0090】

一つの典型的な構成において、コンピュータ機器は、一つ以上のプロセッサ（ＣＰＵ：Central Processing Unit）、入出力インタフェース、ネットワークインタフェース及び内部メモリを含む。

【0091】

内部メモリは、コンピュータ読み取り可能媒体の揮発性メモリ、ＲＡＭ（Random Access Memory）、及び／又は、ＲＯＭ（Read-Only Memory）又はフラッシュＲＡＭなどの不揮発性ＲＡＭの形態を含んでよい。内部メモリは、コンピュータ読み取り可能な媒体の一例である。

【0092】

コンピュータ読み取り可能な媒体は、永続的な、非永続的な、移動可能な、及び、移動不能な媒体を含み、任意の方法又は技術を通じて情報の記憶を実現できる。情報は、コンピュータ読み取り可能な命令、データ構造、プログラムモジュール又は他のデータであってよい。コンピュータの記憶媒体の例は、ＰＲＡＭ（Phase-change RAM）、ＳＲＡＭ（Static RAM）、ＤＲＡＭ（Dynamic RAM）、他の種類のＲＡＭ、ＲＯＭ、ＥＥＰＲＯＭ（Electrically Erasable Programmable Read-Only Memory）、フラッシュメモリ若しくは他の内部メモリ技術、ＣＤ−ＲＯＭ（Compact Disk Read-Only Memory）、ＤＶＤ（Digital Versatile Disc）若しくは他の光学メモリ、カセット、磁気テープ及びディスクメモリ若しくは他の磁気メモリ、又は、コンピュータ装置によってアクセス可能な情報を記憶するために使用され得る任意の他の非伝送媒体を含むが、これらに限定されるものではない。本明細書における定義によれば、コンピュータ読み取り可能な記憶媒体は、変調されたデータ信号及び搬送波などの一時的なコンピュータ読み取り可能な媒体（一時的な媒体）を除外する。

【0093】

「含む、備える（comprise）」及び「含む、包含する（include）」という用語、又は、これらの任意の変化は、非排他的な包含（non-exclusive inclusion）を意図している。従って、一連の要素を含むプロセス、方法、製品又は装置は、これらの要素のみを含むものではない。それは、明示的に列挙されていない他の要素も含むか、それは、そのプロセス、方法、製品又は装置に固有の要素も含む。他の制限が存在しないとき、「一つの〜を含む（備える）（comprising one...）」という表現によって定義される要素は、その要素を含むプロセス、方法、製品又は装置に、他の又は類似の要素が存在することを除外しない。

【0094】

当業者は、本出願の実施形態が、方法、システム又はコンピュータプログラム製品として提供される可能性があることを理解すべきである。従って、本発明は、純粋なハードウェアの実施形態の形式、純粋なソフトウェアの実施形態の形式又はソフトウェア及びハードウェアを組み合わせた実施形態の形式を使用することがある。また、本発明は、コンピュータが実行可能なプログラムコードを含む一つ以上のコンピュータ記憶媒体（磁気ディスクメモリ、ＣＤ−ＲＯＭ及び光メモリを含むが、これらに限定されない）を経由して実現されるコンピュータプログラム製品の形式を使用することがある。

【0095】

上記された内容は、本出願の単なる実施形態である。それらは、本出願を限定するために使用されない。当業者のために、本出願は、修正又は変更されてよい。本出願の精神及び原理の中でなされる全ての改正、同等な代用品、及び向上は、本出願の特許請求の範囲に含まれねばならない。

【図1】

【図2】

【図3a】

【図3b】

【図4】

【図5】

【図6】