特許 7036826 サービス処理方法および装置

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

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

(11)【特許番号】

(24)【登録日】2022-03-07

(45)【発行日】2022-03-15

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

(51)【国際特許分類】

   G06Q 40/04 20120101AFI20220308BHJP

   G06Q 30/06 20120101ALI20220308BHJP

【ＦＩ】

G06Q40/04

G06Q30/06 340

【請求項の数】 12

(21)【出願番号】P 2019534167

(86)(22)【出願日】2017-12-15

(65)【公表番号】

(43)【公表日】2020-01-23

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

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

(87)【国際公開日】2018-06-28

【審査請求日】2019-06-21

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

(32)【優先日】2016-12-21

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

【前置審査】

(73)【特許権者】

【識別番号】520015461

【氏名又は名称】アドバンスド ニュー テクノロジーズ カンパニー リミテッド

(74)【代理人】

【識別番号】100099759

【弁理士】

【氏名又は名称】青木 篤

(74)【代理人】

【識別番号】100123582

【弁理士】

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

(74)【代理人】

【識別番号】100092624

【弁理士】

【氏名又は名称】鶴田 準一

(74)【代理人】

【識別番号】100114018

【弁理士】

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

(74)【代理人】

【識別番号】100117019

【弁理士】

【氏名又は名称】渡辺 陽一

(74)【代理人】

【識別番号】100173107

【弁理士】

【氏名又は名称】胡田 尚則

(72)【発明者】

【氏名】ニー フェイ

(72)【発明者】

【氏名】フー ツォンワン

【審査官】上田 威

(56)【参考文献】

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

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

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

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

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

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

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

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

【請求項1】

取引処理方法であって、
第２サーバが、第１サーバにより送られる、前記第１サーバがクライアントにより送られる第１取引要求を処理した後に生成される第１取引結果を、受信することと、
前記第１取引結果に対応するタイプを判定することと、
前記第２サーバが、前記クライアントにより送られる第２取引要求を受信する前に、前記タイプと前記第１取引結果に従って、前記タイプと整合する第２取引結果を生成することと、
前記生成された第２取引結果を、前記第２サーバが、前記第２取引要求を受信した後に、前記クライアントにフィードバックすることを有し、
前記第１取引要求は、注文を出すための要求であり、前記第１サーバは、前記注文を出すためのサーバを備え、前記第１取引結果は、前記注文のデータを備え、
前記第２サーバは、支払サーバを備え、前記第２取引結果は、前記第２取引要求を受信する前に前記注文のデータに従って前記タイプと整合するように描画および構築され、前記クライアントに表示される支払ページを有している方法。

【請求項2】

前記注文の前記データは、前記注文を出すための前記サーバのタイプ識別子を備え、
前記第１取引結果に対応するタイプを前記判定することは、
前記注文の前記データに含まれている、前記注文を出すための前記サーバの前記タイプ識別子を判定することを備え、
前記タイプと前記第１取引結果に従って、前記タイプと整合する第２取引結果を前記生成することは、
タイプ識別子とページテンプレートとの間の、予め確立された対応関係に従って、前記注文の前記データに対応するページテンプレートを判定することと、
前記判定されたページテンプレートに従って、前記ページテンプレートと整合する前記注文のデータに標識を付けることと、
前記標識を付けられた前記注文のデータに従って、前記支払ページを描画および構築することを有していることを特徴とする請求項１に記載の方法。

【請求項3】

前記標識を付けられた前記注文のデータに従って、前記支払ページを前記描画および構築することは、
前記注文の前記データに従って、支払状態を判定することと、
前記支払状態は、支払の実行が許可されているということであると判定されたときは、前記標識を付けられた前記注文のデータに従って、前記支払ページを描画および構築することを有していることを特徴とする請求項２に記載の方法。

【請求項4】

前記支払状態は、支払の実行が許可されていないということであると判定されたときは、前記方法は更に、
前記標識を付けられた前記注文のデータの標識を削除することと、
例外ページを描画および構築することを有していることを特徴とする請求項３に記載の方法。

【請求項5】

前記注文の前記データは、前記クライアントの識別子を携えており、
前記方法は更に、
前記クライアントの前記識別子と、前記支払ページとの間の対応関係を確立することを備え、
前記生成された第２取引結果を前記クライアントにフィードバックすることは、
前記第２取引要求における、前記クライアントの前記識別子を判定することと、
前記クライアントに、前記クライアントの前記識別子に対応する、前記生成された支払ページをフィードバックすることを有していることを特徴とする請求項３または４に記載の方法。

【請求項6】

取引処理方法であって、
第１サーバがクライアントにより送られる第１取引要求を受信することと、
前記第１取引要求に従って、前記第１サーバのタイプに対応する第１取引結果を生成することと、
前記第１取引結果を第２サーバに送り、前記第２サーバに、前記第１取引結果に対応するタイプを判定させ、前記第２サーバが、前記クライアントにより送られる第２取引要求を受信する前に、前記第１取引結果と、前記第１取引結果に対応する前記タイプに従って、前記第１取引結果に対応する前記タイプと整合する第２取引結果を生成させ、前記生成された第２取引結果を、前記第２サーバが、前記第１取引結果に従って前記クライアントにより生成された前記第２取引要求を受信した後に、前記クライアントに送らせることを有し、
前記第１取引要求は、注文を出すための要求であり、前記第１サーバは、前記注文を出すためのサーバを備え、前記第１取引結果は、前記注文のデータを備え、
前記第２サーバは、支払サーバを備え、前記第２取引結果は、前記第２取引要求を受信する前に前記注文のデータに従って前記タイプと整合するように描画および構築され、前記クライアントに表示される支払ページを有している方法。

【請求項7】

取引処理装置であって、
第１サーバにより送られる、前記第１サーバがクライアントにより送られる第１取引要求を処理した後に生成される第１取引結果を、受信するように構成されている受信モジュールと、
前記第１取引結果に対応するタイプを判定するように構成されているタイプ判定モジュールと、
前記タイプと前記第１取引結果に従って、前記取引処理装置が、前記クライアントにより送られる第２取引要求を受信する前に、前記タイプと整合する第２取引結果を生成するように構成されている生成モジュールと、
前記生成された第２取引結果を、前記取引処理装置が、前記第２取引要求を受信した後に、前記クライアントにフィードバックするように構成されているフィードバックモジュールを有し、
前記第１取引要求は、注文を出すための要求であり、前記第１サーバは、前記注文を出すためのサーバを備え、前記第１取引結果は、前記注文のデータを備え、
前記取引処理装置は、支払サーバを備え、前記第２取引結果は、前記第２取引要求を受信する前に前記注文のデータに従って前記タイプと整合するように描画および構築され、前記クライアントに表示される支払ページを有している装置。

【請求項8】

前記注文の前記データは、前記注文を出すための前記サーバのタイプ識別子を備え、
前記タイプ判定モジュールは、前記注文の前記データに含まれている、前記注文を出すための前記サーバの前記タイプ識別子を判定し、
前記生成モジュールは、タイプ識別子とページテンプレートとの間の、予め確立された対応関係に従って、前記注文の前記データに対応するページテンプレートを判定し、前記判定されたページテンプレートに従って、前記ページテンプレートと整合する前記注文のデータに標識を付け、前記標識を付けられた前記注文のデータに従って、前記支払ページを描画および構築することを特徴とする請求項７に記載の装置。

【請求項9】

前記生成モジュールは、前記注文の前記データに従って、支払状態を判定し、前記支払状態は、支払の実行が許可されているということであると判定されたときは、前記標識を付けられた前記注文のデータに従って、前記支払ページを描画および構築することを特徴とする請求項８に記載の装置。

【請求項10】

前記生成モジュールが、前記支払状態は、支払の実行が許可されていないということであると判定したときは、前記生成モジュールは、前記注文の前記データの標識を削除し、例外ページを描画および構築することを特徴とする請求項９に記載の装置。

【請求項11】

前記注文の前記データは、前記クライアントの識別子を携えており、
前記装置は更に、前記クライアントの前記識別子と、前記支払ページとの間の対応関係を確立するように構成されている関係確立モジュールを備え、
前記フィードバックモジュールは、前記第２取引要求における、前記クライアントの前記識別子を判定し、前記クライアントに、前記クライアントの前記識別子に対応する、前記生成された支払ページをフィードバックすることを特徴とする請求項９または１０に記載の装置。

【請求項12】

取引処理装置であって、
クライアントにより送られる第１取引要求を受信するように構成されている受信モジュールと、
第２サーバが、前記クライアントにより送られる第２取引要求を受信する前に、前記第１取引要求に従って、前記取引処理装置のタイプに対応する第１取引結果を生成するように構成されている生成モジュールと、
前記第１取引結果を前記クライアントと前記第２サーバに送り、前記第２サーバに、前記第１取引結果に対応するタイプを判定させ、前記第１取引結果と、前記第１取引結果に対応する前記タイプに従って、第２取引結果を生成させ、前記生成された第２取引結果を、前記第２サーバが、前記第１取引結果に従って前記クライアントにより生成された前記第２取引要求を受信した後に、前記クライアントに送らせるように構成されている発送モジュールを有し、
前記第１取引要求は、注文を出すための要求であり、前記取引処理装置は、前記注文を出すためのサーバを備え、前記第１取引結果は、前記注文のデータを備え、
前記第２サーバは、支払サーバを備え、前記第２取引結果は、前記第２取引要求を受信する前に前記注文のデータに従って前記タイプと整合するように描画および構築され、前記クライアントに表示される支払ページを有している装置。

【発明の詳細な説明】

【技術分野】

【0001】

本願は、コンピュータ技術の分野に関し、特には、取引処理方法および装置に関する。

【背景技術】

【0002】

オンラインシステム（例えば、ウェブサイト）は、バックエンド取引システムのサポートにより、ユーザへ多くの取引サービスを提供できる。幾つかの取引は、異なる取引システムにより連携して実行できる。現在の技術においては、取引要求は、ブラウザやアプリケーション（ＡＰＰ）などのクライアントを介して、ユーザにより開始できる。サービス要求の処理は、例えば、下記のようであってよい。取引フローの順序に従って、取引要求を最初に処理する取引システムは、対応する処理結果（中間結果と称することができる）を生成して、処理結果をクライアントに返すことができる。クライアントは中間結果に従って、取引フローにおける次の取引システムに転送して、取引フロー全体が完了するまで、次の取引システムが後続の処理を実行するための要求（中間要求と称することができる）を開始することなどができる。

【0003】

例えば、クライアントにより送られる取引要求は、取引システムＡと取引システムＢにより連携して実行できる。取引フローに従って、取引要求は最初に、取引システムＡにより処理されて中間結果を生成し、取引システムＡは、中間結果をクライアントに返す。クライアントは、中間結果ａに従って取引システムＢに転送し、更に、要求を取引システムＢに送る。取引システムＢは要求を処理して、処理結果ｂを生成でき、処理結果ｂをクライアントに返すことができる。

【0004】

しかし、現在の技術による方法においては、取引システムは、インターネットを介してクライアントと相互作用し、一方、インターネットのネットワーク環境は、相対的に安定性が低く、ネットワーク遅延が、ネットワーク環境の影響により起こり得る。結果として、クライアントが中間結果に従って、中間要求を次のサービスシステムに送るためには相対的に長い時間がかかり得る。加えて、上記の方法においては、取引システムは、クライアントから要求を受信した後でのみ、対応する処理を実行する。しかし、オンラインシステムは典型的には、膨大な量のユーザアクセスに直面している。従って、取引システムは、高い作業負担を有する可能性があり、取引システムの処理キューにおける遅延を引き起こす。明白なことであるが遅延は、送信段階と、要求の処理段階の両者において起こり得、クライアントの長い待ち時間と、取引処理のタイミングの悪さに繋がることは避けられない。

【発明の概要】

【0005】

本願の実施形態は、既存の取引処理におけるタイミングの悪さの問題を解決するための取引処理方法および装置を提供する。

【0006】

本願の実施形態は、取引処理方法を提供し、方法は、
第２サーバが、第１サーバにより送られる、第１サーバがクライアントにより送られる第１取引要求を処理した後に生成される第１取引結果を、受信することと、
第１取引結果に対応するタイプを判定することと、
タイプと第１取引結果に従って、タイプと整合する第２取引結果を生成することと、
生成された第２取引結果を、第２サーバが、クライアントにより送られる第２取引要求を受信した後に、クライアントにフィードバックすることを有している。

【0007】

本願の実施形態は更に、取引処理方法を提供し、方法は、
第１サーバがクライアントにより送られる第１取引要求を受信することと、
第１取引要求に従って、第１サーバのタイプに対応する第１取引結果を生成することと、
第２サーバに第１取引結果を送り、第２サーバに、第１取引結果に対応するタイプを判定させ、第１取引結果と、第１取り結果に対応するタイプに従って、第１取引結果に対応するタイプと整合する第２取引結果を生成させ、生成された第２取引結果を、第２サーバが、第１取り結果に従ってクライアントにより生成された第２取引要求を受信した後に、クライアントに送らせることを有している。

【0008】

本願の実施形態は、取引処理装置を提供し、装置は、
第１サーバにより送られる、第１サーバがクライアントにより送られる第１取引要求を処理した後に生成される第１取引結果を、受信するように構成されている受信モジュールと、
第１取引結果に対応するタイプを判定するように構成されているタイプ判定モジュールと、
タイプと第１取引結果に従って、タイプと整合する第２取引結果を生成するように構成されている生成モジュールと、
生成された第２取引結果を、第２サーバが、クライアントにより送られる第２取引要求を受信した後に、クライアントにフィードバックするように構成されているフィードバックモジュールを有している。

【0009】

本願の実施形態は更に、取引処理装置を提供し、装置は、
クライアントにより送られる第１取引要求を受信するように構成されている受信モジュールと、
第１取引要求に従って、第１サーバのタイプに対応する第１取引結果を生成するように構成されている生成モジュールと、
クライアントと第２サーバに第１取引結果を送り、第２サーバに、第１取引結果に対応するタイプを判定させ、第１取引結果と、第１取り結果に対応するタイプに従って、第２取引結果を生成させ、生成された第２取引結果を、第２サーバが、第１取り結果に従ってクライアントにより生成された第２取引要求を受信した後に、クライアントに送らせるように構成されている発送モジュールを有している。

【0010】

本願の実施形態は、取引処理方法および装置を提供する。方法によれば、第１サーバがクライアントにより送られる第１取引要求を受信した後に、第１サーバは第１取引要求を処理して、対応する第１取引結果を生成する。この時点で、第１取引結果をクライアントに返すことに加えて、第１サーバはまた、取引フローに従って、第１取引結果を第２サーバに送ることもでき、第２サーバは、第１取引結果に対応するタイプを判定できる。このように、第２サーバは第１取引結果を処理して、タイプと整合する第２取引結果を事前に生成できる。この方法を適用することにより、第２サーバは第２取引結果を、第２サーバが、クライアントにより送られる第２取引要求を受信する前に生成できる。第２サーバが、クライアントにより送られる第２取引要求を受信するときに、第２サーバは、生成された第２取引結果をクライアントに送ることができる。更に、生成された第２取引結果は、第１取引結果の取引タイプと整合している。現在の技術における方法とは対照的に、第２サーバが、クライアントからの第２取引要求を受信する前に、第２サーバが、第１取引結果に従って、第２取引結果を事前に生成できるということは明白であり、それにより、クライアントの待ち時間を効果的に節約し、取引要求を処理するためのタイミングを向上する。

【図面の簡単な説明】

【0011】

ここにおいて記述される付随する図面は、本願のより良好な理解を提供するために使用され、本願の一部を構成している。本願の例としての実施形態と、例として実施形態の記述は、本願を記述するために使用され、本願に対する不適切な制限ではない。

【図1a】本願の幾つかの実施形態に係る、取引処理のためのプロセスが基盤とするアーキテクチャの模式図である。

【図1b】本願の幾つかの実施形態に係る、第２サーバ側に基づく取引処理のためのプロセスの模式図である。

【図2】本願の幾つかの実施形態に係る、第１サーバ側に基づく取引処理プロセスのためのプロセスの模式図である。

【図3】本願の幾つかの実施形態に係る、適用の例における取引処理のためのプロセスの模式図である。

【図4】本願の幾つかの実施形態に係る、第２サーバ側に基づく取引処理装置の模式構造図である。

【図5】本願の幾つかの実施形態に係る、第１サーバ側に基づく取引処理装置の模式構造図である。

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

【0012】

本願の目的、技術的解決策、および利点をより明確にするために、本願の技術的解決策を、本願の実施形態および付随する図面を参照して、下記に明確且つ完全に記述する。記述される実施形態は単なる例に過ぎず、本願の実施形態のすべてではないということは明白である。本願の実施形態に基づいて、通常の技量を有する当業者が、創造的努力なしに得ることができるすべての他の実施形態は、本願の範囲に含まれるものとする。

【0013】

上記のように、ユーザが、オンライシステムからクライアントを介して、２つ以上の取引システムにより連携して実行される取引を得るとき、クライアントは典型的には、異なる取引システムにより返される中間取引結果を受信し、中間結果に従って転送し、取引フロー全体が完了するまで、要求を次の取引システムに送る。しかし、このプロセスにおいて、クライアントが要求を取引システムに送るとき、クライアントは、ネットワーク環境に影響される傾向にあり、送信遅延を体験し得る。更に、現在の技術における取引システムは、取引システムが、クライアントにより送られる取引要求を受信した後のみに処理を実行可能である。取引システムが高い作業負荷を有している状況においては、処理遅延はまた、取引システムが取引要求を処理するときにも引き起こされ得る。このように、クライアントは、送信遅延と処理遅延の両者の影響を受け易く、クライアントの長い待ち時間に繋がる。明白なことであるが、取引要求のタイミングは非常に影響を受ける。

【0014】

上記を考慮すると、クライアントの待ち時間を削減可能なサービス処理方法が必要である。つまり、本願の実施形態においては、取引処理方法が提供される。

【0015】

本願の実施形態においては、ユーザにより、オンラインシステムからクライアントを介して得られる取引サービスは、２つ以上の取引システムにより連携して実行されることがよくあり、従って、クライアントは、取引のフローに従って、異なる取引システムに対して、異なる取引要求を開始するということに留意すべきである。しかし、異なる取引要求は、クライアントが同じ取引を実行するために開始されると考えることが可能である。

【0016】

本願の実施形態に係る取引処理方法は、図１ａに示されているアーキテクチャに基づいている。図１ａから、アーキテクチャは、ユーザにより使用される取引クライアント（以降、短く「クライアント」とも称される）と、第１サーバと、第２サーバを含んでいることが分かる。クライアントは、端末上で動作する、ブラウザ、アプリケーション（「ＡＰＰ」）などであってよい。第１サーバと第２サーバは、異なる取引機能を有している。１つの例においては、第１サーバと第２サーバは、取引フローにおいて互いに隣接する２つの取引サーバであってよい。第２サーバは、取引フローの処理順序において、第１サーバの後の取引サーバであってよい。例えば、３つの取引サーバＡ、Ｂ、およびＣがあり、取引は、サーバＡ、サーバＢ、サーバＣの順序で３つの取引サーバにより実行されると仮定する。取引サーバＡとＢに関しては、第１サーバは取引サーバＡであってよく、第２サーバは取引サーバＢであってよい。取引サーバＢとＣに関しては、第１サーバは取引サーバＢであってよく、第２サーバは取引サーバＣであってよい。言い換えると、本願における第１サーバと第２サーバは、２つのみのサーバのシナリオに制限されない。

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

コントローラは、任意の適切な方法で実現できる。例えば、コントローラは、例えば、マイクロプロセッサまたはプロセッサの形式であってよく、同時に、（マイクロ）プロセッサにより実行可能なコンピュータ読取り可能プログラムコード（例えば、ソフトウェアまたはファームウェア）を格納するコンピュータ読取り可能媒体、ロジックゲート、スイッチ、特殊用途向け集積回路（ＡＳＩＣ）、プログラマブルロジックコントローラ、および埋込みマイクロコントローラであってよい。コントローラの例としては、下記のマイクロコントローラに制限されるわけではないが、ＡＲＣ ６２５Ｄ、Ａｔｍｅｌ ＡＴ９１ＳＡＭ、Ｍｉｃｒｏｃｈｉｐ ＰＩＣ１８Ｆ２６Ｋ２０、およびＳｉｌｉｃｏｎｅ Ｌａｂs Ｃ８０５１Ｆ３２０がある。メモリコントローラは更に、メモリの制御ロジックの一部として実現できる。通常の技量を有する当業者は、コントローラは、純粋なコンピュータ読取り可能プログラムコードの方法で実現されるということに加えて、ロジックゲート、スイッチ、ＡＳＩＣ、プログラマブルロジックコントローラ、および埋込みマイクロコントローラなどの形式で、同じ機能をコントローラが実現することを可能にする方法のステップに対して、ロジックプログラミングを実行することは完全に実現可能であるということも認識すべきである。従って、そのようなコントローラは、ハードウェア部品と考えることができ、他方、コントローラに含まれ、種々の機能を達成するように構成されているデバイスもまた、ハードウェア部品の内部の構造と考えることができる。または、種々の機能を達成するように構成されているデバイスは、方法を実現するためのソフトウェアと、ハードウェア部品の内部の構造の両者とさえ考えることができる。

【0071】

上記の実施形態において記述されたシステム、装置、モジュール、またはユニットは、コンピュータチップまたは実体により実現でき、または、機能を有する製品により実現できる。典型的な実現デバイスはコンピュータである。コンピュータは、例えば、パーソナルコンピュータ、ラップトップコンピュータ、セルラーフォン、カメラフォン、スマートフォン、携帯情報端末、メディアプレーヤ、ナビゲーションデバイス、イーメールデバイス、ゲームコンソール、タブレットコンピュータ、ウェアラブルデバイス、または、それらの組み合わせであってよい。

【0072】

記述の便宜上、上記のデバイスは、記述のために、機能によって種々のユニットに分割される。ユニットの機能は、本願が実現されるときに、１つの、または複数のソフトウェアおよび／またはハードウェアにおいて実現できる。

【0073】

通常の技量を有する当業者は、本発明の実施形態は、方法、システム、またはコンピュータプログラム製品として提供できるということを理解すべきである。従って、本発明は、完全なハードウェア実施形態、完全なソフトウェア実施形態、または、ソフトウェアとハードウェアを組み合わせた実施形態として実現できる。更に、本発明は、コンピュータ使用可能プログラムコードを有している、１つ以上のコンピュータ使用可能格納媒体（下記のものに制限されるわけではないが、磁気ディスクメモリ、ＣＤ－ＲＯＭ、光メモリなどを含む）上で実現されるコンピュータプログラム製品の形式であってよい。

【0074】

本発明は、本発明の実施形態に係る方法、デバイス（システム）、およびコンピュータプログラム製品のフローチャートおよび／またはブロック図を参照して記述されている。コンピュータプログラム命令は、フローチャートおよび／またはブロック図における各プロセスおよび／またはブロック、およびフローチャートおよび／またはブロック図における複数のプロセスおよび／または複数のブロックの組み合わせを実現するために使用できるとうことは理解されるべきである。これらのコンピュータプログラム命令は、汎用コンピュータ、特殊用途向けコンピュータ、埋込みプロセッサ、または、マシンを生成するための、他のプログラマブルデータ処理装置のプロセッサに対して提供でき、コンピュータ、または他のプログラマブルデータ処理装置のプロセッサにより実行される命令に、フローチャートにおける１つ以上のプロセス、および／または、ブロック図における１つ以上のブロックにおいて指定される機能を実現するための装置を生成させる。

【0075】

これらのコンピュータプログラム命令はまた、コンピュータまたは他のプログラマブルデータ処理装置に、特別な方法で作動することを指示可能なコンピュータ読取り可能メモリにも格納でき、コンピュータ読取り可能メモリに格納された命令に、指示装置を含む、製造された製品を生成させる。指示装置は、フローチャートにおける１つ以上のプロセス、および／または、ブロック図における１つ以上のブロックにおいて指定される機能を実現する。

【0076】

これらのコンピュータプログラム命令はまた、コンピュータまたは他のプログラマブルデータ処理装置にもロードでき、一連の操作ステップを、コンピュータまたは他のプログラマブルタ装置上で実行させ、それにより、コンピュータにより実現される処理を生成する。従って、コンピュータまたは他のプログラマブル装置上で実行される命令は、フローチャートにおける１つ以上のプロセス、および／または、ブロック図における１つ以上のブロックにおいて指定される機能を実現するためのステップを提供する。

【0077】

典型的な構成においては、演算装置は、１つ以上のプロセッサ（ＣＰＵ）、入／出力インタフェース、ネットワークインタフェース、およびメモリを含んでいる。

【0078】

メモリには、揮発性メモリ、ランダムアクセスメモリ（ＲＡＭ）、および／または、例えばリードオンリメモリ（ＲＯＭ）またはフラッシュＲＡＭである不揮発性メモリのようなコンピュータ読取り可能媒体を含むことができる。メモリは、コンピュータ読取り可能媒体の例である。

【0079】

コンピュータ読取り可能媒体としては、永久的、揮発性、可動、非可動媒体があり、これらの媒体は、任意の方法または技術で、情報の格納を実現可能である。情報は、コンピュータ読取り可能命令、データ構造、プログラムモジュール、または他のデータであってよい。コンピュータの格納媒体の例としては、下記のものに制限されるわけではないが、相変化ランダムアクセスメモリ（ＰＲＡＭ）、スタティックランダムアクセスメモリ（ＳＲＡＭ）、ダイナミックランダムアクセスメモリ（ＤＲＡＭ）、他のタイプのランダムアクセスメモリ（ＲＡＭ）、リードオンリメモリ（ＲＯＭ）、電気的消去可能型プログラマブルリードオンリメモリ（ＥＥＰＲＯＭ）、フラッシュメモリ、または他のメモリ技術、コンパクトディスクリードオンリメモリ（ＣＤ－ＲＯＭ）、デジタル多目的ディスク（ＤＶＤ）、または他の光メモリ、カセット、カセットおよびディスクメモリ、または他の磁気メモリ装置、または、任意の他の非伝送媒体があり、それらは、演算装置がアクセス可能な情報を格納するために使用可能である。明細書における記述によれば、コンピュータ読取り可能媒体は、変調データ信号およびキャリアのような一時的媒体は含まない。

【0080】

「含む」、「備える」、またはそれらの用語の任意の他の変形である用語は、非排他的包含を含むことが意図されており、一連の要素を含んでいるプロセス、方法、製品、または装置に、これらの要素を含ませるだけではなく、明確には列挙されてない他の要素も含めさせ、または、プロセス、方法、製品、または装置に本来的に備わっている要素を更に含めさせるということに更に留意すべきである。更なる制限がないときは、「１つの～を有している」または「１つの～を含んでいる」という記述により定義される要素は、上記の要素を含んでいるプロセス、方法、製品、または装置が更に、追加的な同一要素を含むということを排除するものではない。

【0081】

通常の技量を有する当業者は、本願の実施形態が、方法、システム、またはコンピュータプログラム製品として提供され得るということを理解すべきである。従って、本願は、完全なハードウェア実施形態、完全なソフトウェア実施形態、またはソフトウェアとハードウェアを組み合わせた実施形態として実現できる。更に、本願は、コンピュータ使用可能プログラムコードを有している１つ以上のコンピュータ使用可能格納媒体（下記のものに制限されるわけではないが、磁気ディスクメモリ、ＣＤ－ＲＯＭ、光メモリなどを含む）上で実現されるコンピュータプログラム製品の形式であってよい。

【0082】

本願は、プログラムモジュールのような、コンピュータにより実行されるコンピュータ実行可能命令の通常の状況において記述できる。一般的に、プログラムモジュールは、特別な作業を実行するために、または、特別な抽象データタイプを実現するために、ルーチン、プログラム、オブジェクト、構成要素、データ構造などを有している。本願はまた、分散型演算環境においても実践できる。これらの分散型演算環境においては、通信ネットワークを介して接続されている遠隔処理装置が作業を遂行する。分散型演算環境においては、プログラムモジュールを、格納装置を含む、局所および遠隔コンピュータ格納媒体に置くことができる。

【0083】

この明細書における実施形態は、それぞれの実施形態の、他の実施形態との差に注目して徐々に前進する方法で記述されており、実施形態は、同一または類似の部分を相互に参照され得る。特に、システムの実施形態は、システムの実施形態が、方法の実施形態と略類似しているので、相対的に簡単な方法で記述されている。方法の実施形態の記述は、関連する部分に対して参照され得る。

【0084】

上記の実施形態は、本願の実施形態に過ぎず、本願を制限するためには使用されない。通常の技量を有する当業者に対しては、本願は、種々の修正および変更を有することができる。本願の精神および原理内で行われる如何なる修正、等価な置換、または改良も、本願の請求項により含まれるものとする。

【図1a】

【図1b】

【図2】

【図3】

【図4】

【図5】