(57)【要約】  本願は、権限分離制御に基づくネットワーク取引方法及び装置に関する。権限分離制御に基づくネットワーク取引方法は、第１アカウントによって提出された注文を受信し、予め記憶された結合関係に基づいて前記第１のアカウントに結合された第２のアカウントを決定し、第１のアカウントによって提出された前記注文に基づいて前記第２のアカウントへの決済要求を開始し、前記第２のアカウントが前記決済要求を確認することに応答して、前記注文の決済が成功したと決定することを含む。本願が提供する技術的解決策は、購入者ユーザの注文権限と決済権限を分離するメカニズムを採用することによって、１つの取引内の注文及び決済操作を異なるアカウントによって実行させることを可能にする。これにより、システム側の資源の不要な消費を効果的に削減しながら、複数のユーザによる同じアカウントの使用によって引き起こされる不便さの問題を回避する。【選択図】図１
2019526115.tif 000002
【特許請求の範囲】
【請求項１】
取引システム側に適用される権限分離制御に基づくネットワーク取引方法であって、異なるアカウント間の結合関係が予め確立されて記憶され、任意の２つの結合されたアカウントの一方は少なくとも購入者ユーザ注文権限を有し、他方は少なくとも購入者ユーザ決済権限を有し、前記ネットワーク取引方法は、
第１のアカウントによって提出された注文を受信し、
予め記憶された結合関係に基づいて前記第１のアカウントに結合された第２のアカウントを決定し、
前記第１のアカウントによって提出された前記注文に基づいて前記第２のアカウントへの決済要求を開始し、
前記第２のアカウントが前記決済要求を確認することに応答して、前記注文の決済が成功したと決定する、
ことを含むネットワーク取引方法。
【請求項２】
予め記憶された結合関係に基づいて前記第１のアカウントに結合された第２のアカウントを決定することは、
前記第１のアカウントが決済権限を有するか否かを決定することを含み、有さない場合は、予め記憶された結合関係に基づいて前記第１のアカウントに結合された第２のアカウントを決定することをさらに含む、請求項１に記載の方法。
【請求項３】
前記第２のアカウントへの決済要求を開始することは、取引システムの内部メッセージを使用して、決済要求通知メッセージを前記第２のアカウントに送信すること、
又は、
前記第２のアカウントの関連する連絡モードを使用して、決済要求通知メッセージを前記第２のアカウントに送信することを含む、請求項１に記載の方法。
【請求項４】
前記決済要求通知メッセージには、前記決済要求を確認するように構成された、ショートカット操作ポータルが含まれる、請求項３に記載の方法。
【請求項５】
前記異なるアカウント間の結合関係は、
決済権限を有する１つのアカウントが注文権限を有する複数のアカウントに結合されること、
又は、
注文権限を有する１つのアカウントが決済権限を有する複数のアカウントに結合されること、
を含む、請求項１に記載の方法。
【請求項６】
注文権限を有する１つのアカウントが決済権限を有する複数のアカウントに結合される場合、第１のアカウントによって提出された注文は、決済権限を有する指定されたアカウントの識別子を含み、
前記予め記憶された結合情報に基づいて前記第１のアカウントに結合された第２のアカウントを決定することは、前記予め記憶された結合情報及び前記識別子に基づいて前記第１のアカウントに結合された前記第２のアカウントを決定することを含む、
請求項５に記載の方法。
【請求項７】
取引システム側に適用される権限分離制御に基づくネットワーク取引装置であって、
前記ネットワーク取引装置は、
任意の２つの結合されたアカウントの少なくとも一方は購入者ユーザ注文権限を有し、他方は少なくとも購入者ユーザ決済権限を有する、予め確立された異なるアカウント間の結合関係を記憶するように構成された結合関係記憶モジュールと、
第１のアカウントによって提出された注文を受信するように構成された、注文受信モジュールと、
予め記憶された結合関係に基づいて前記第１のアカウントに結合された第２のアカウントを決定するように構成された、決済アカウント決定モジュールと、
前記第１のアカウントによって提出された前記注文に基づいて前記第２のアカウントへの決済要求を開始するように構成された、決済要求開始モジュールと、
前記第２のアカウントが前記決済要求を確認することに応答して、前記注文の決済が成功したと決定するように構成された、決済決定モジュールと、
を含む、ネットワーク取引装置。
【請求項８】
前記決済アカウント決定モジュールは、前記第１のアカウントが決済権限を有するか否かを決定するように構成され、有さない場合、前記予め記憶された結合関係に基づいて前記第１のアカウントに結合された第２のアカウントを決定するようにさらに構成された、請求項７に記載の装置。
【請求項９】
前記決済要求開始モジュールは、前記取引システムの内部メッセージを使用して、決済要求通知メッセージを前記第２のアカウントに送信し、
又は、
前記第２のアカウントの関連する連絡モードを使用して、決済要求通知メッセージを前記第２のアカウントに送信する、ように構成された、
請求項７に記載の装置。
【請求項１０】
前記決済要求通知メッセージには、前記決済要求を確認するように構成された、ショートカット操作ポータルが設けられる、請求項９に記載の装置。
【請求項１１】
前記異なるアカウント間の結合関係は、
決済権限を有する１つのアカウントが注文権限を有する複数のアカウントに結合されること、
又は、
注文権限を有する１つのアカウントが決済権限を有する複数のアカウントに結合されること、
を含む、請求項７に記載の装置。
【請求項１２】
注文権限を有する１つのアカウントが決済権限を有する複数のアカウントに結合される場合、第１のアカウントによって提出された注文は、決済権限を有する指定されたアカウントの識別子を含み、
前記決済アカウント決定モジュールは、前記予め記憶された結合情報及び前記識別子に基づいて前記第１のアカウントに結合された前記第２のアカウントを決定するように構成された、請求項７に記載の装置。
【発明の詳細な説明】
【技術分野】
【０００１】
本願は、２０１６年６月２９日に「Ｎｅｔｗｏｒｋ  Ｔｒａｎｓａｃｔｉｏｎ  Ｍｅｔｈｏｄ  ａｎｄ  Ｄｅｖｉｃｅ  Ｂａｓｅｄ  ｏｎ  Ａｕｔｈｏｒｉｚａｔｉｏｎ  Ｓｅｐａｒａｔｉｏｎ  Ｃｏｎｔｒｏｌ」と題して出願された中国特許出願番号２０１６１０５００３８８．０に対して優先権の利益を主張するものであり、その出願全体の内容が参照により本明細書に組み込まれる。
【０００２】
本願は、インターネットアプリケーション技術の分野に関し、特に、権限分離制御に基づくネットワーク取引方法及び装置に関する。
【背景技術】
【０００３】
ネットワーク取引のプロセスにおいて、購入者ユーザにとって、「注文」と「決済」は２つの基本的な操作である。ここで、「注文」は、購入する商品を選択し決定する購入者ユーザの操作を指し、「決済」は、購入者ユーザが購入商品に対応する金額を販売者ユーザに送信するプロセスを指す。
【０００４】
一般に、「注文」と「決済」は同じユーザが行うが、場合によっては「注文」と「決済」が異なるユーザによって行われる必要がある。例えば、企業における調達の状況では、企業の内部権限配分に基づいて、購入担当者が注文を行い、責任者又は財務管理者が支払を完了する必要がある。既存のネットワーク取引システムは、上述の実際の要求を十分に満たすことができず、ユーザにとって不便であり、システム資源を不必要に消費することになる。
【発明の概要】
【発明が解決しようとする課題】
【０００５】
上記の技術的問題に鑑みて、本願は、権限分離制御に基づくネットワーク取引方法及び装置を提供する。その技術的解決策は以下の通りである。
【課題を解決するための手段】
【０００６】
取引システム側に適用される権限分離制御に基づくネットワーク取引方法であって、異なるアカウント間の結合関係が予め確立されて記憶され、任意の２つの結合されたアカウントの一方は少なくとも購入者ユーザ注文権限を有し、他方は少なくとも購入者ユーザ決済権限を有し、前記ネットワーク取引方法は、
第１のアカウントによって提出された注文を受信し、
予め記憶された結合関係に基づいて前記第１のアカウントに結合された第２のアカウントを決定し、
前記第１のアカウントによって提出された前記注文に基づいて前記第２のアカウントへの決済要求を開始し、
前記第２のアカウントが前記決済要求を確認することに応答して、前記注文の決済が成功したと決定する、ことを含む。
【０００７】
取引システム側に適用される権限分離制御に基づくネットワーク取引装置であって、
前記ネットワーク取引装置は、
任意の２つの結合されたアカウントの少なくとも一方は購入者ユーザ注文権限を有し、他方は少なくとも購入者ユーザ決済権限を有する、予め確立された異なるアカウント間の結合関係を記憶するように構成された、結合関係記憶モジュールと、
第１のアカウントによって提出された注文を受信するように構成された、注文受信モジュールと、
予め記憶された結合関係に基づいて前記第１のアカウントに結合された第２のアカウントを決定するように構成された、決済アカウント決定モジュールと、
前記第１のアカウントによって提出された前記注文に基づいて前記第２のアカウントへの決済要求を開始するように構成された、決済要求開始モジュールと、
前記第２のアカウントが前記決済要求を確認することに応答して、前記注文の決済が成功したと決定するように構成された、決済決定モジュールと、
を含む。
【０００８】
本願が提供する技術的解決策は、購入者ユーザの注文権限と決済権限を分離するメカニズムを採用することによって、１つの取引内の注文及び決済操作を異なるアカウントによって実行させることを可能にする。これにより、システム側の資源の不要な消費を効果的に削減しながら、複数のユーザによる同じアカウントの使用によって引き起こされる不便さの問題を回避する。
【０００９】
上記の一般的な説明及び以下の詳細な説明は、単なる例示及び説明に過ぎず、本願を限定するわけではないことに留意されたい。
【００１０】
本願の実施形態又は従来技術の技術的解決策をより明確に示すために、実施形態又は従来技術の説明で使用される図面の簡単な説明を以下に与える。明らかに、以下の説明における図面は、単に本願の実施形態のいくつかを示す。これらの図面を考慮して、当業者は他の図面を得ることができる。
【図面の簡単な説明】
【００１１】
【図１】本願のネットワーク取引方法のフローチャートである。
【図２】本願のネットワーク取引装置の概略構成図である。
【発明を実施するための形態】
【００１２】
当業者が本願の技術的解決策をよりよく理解することを可能にするために、本願の実施形態の図面を併せて参照して、本願の実施形態の技術的解決策を以下に詳細に説明する。説明される実施形態は、本願の実施形態の一部に過ぎず、実施形態の全てを網羅するわけではない。本願の実施形態に基づいて当業者によって得られる他の全ての実施形態は、本願の範囲内に含まれるべきである。
【００１３】
第一に、本願では、「ユーザ」とは実際のオペレータを指す。例えば、購入担当者と財務管理者は異なるユーザである。「アカウント」はネットワーク内の仮想ＩＤを指す。ネットワーク内の実際のユーザのアクティビティは、「アカウント」の行動によって反映される。実際のアプリケーションでは、複数の実際のユーザが同じアカウントを使用することを許可しているが、これによって不都合が生じる。
【００１４】
既存のネットワーク取引システムは、主に個人の購入者ユーザ向けに設計されている。つまり、取引の注文と決済は同じ人によって行われるのがデフォルトである。しかしながら、このメカニズムでは、背景技術で説明された、異なる人々が注文と決済を完了する需要状況に関して、注文担当者と決済担当者は、各自の業務を完了するために同じ取引アカウントを使用する必要がある。実際のアプリケーションにおいては、注文担当者が注文を送信した後、現在のデバイスで決済を完了するように決済担当者に要求するか、電話などで決済担当者に通知して、他のデバイスで同じアカウントにログインして決済を完了させる必要がある。
【００１５】
明らかに、実際の「ユーザ」権限は、「アカウント」権限と矛盾するため、問題を解決するには複数のユーザが同じアカウントを共有する「非従来型」の方法を採用する必要がある。しかしながら、採用される方法にかかわらず、ユーザの実際の操作プロセスは非常に面倒で厄介である。また、複数の人が同じアカウントを使用するため、同時に使用できない、操作上の競合、繰り返しのログインなどのような作業効率に影響を与える様々な問題の発生が避けられない。システム側にとっては、例えば、エラープロンプト、アイデンティティ認証などのような多くの余分な処理も追加されることによって、処理資源の不必要な浪費をもたらす。
【００１６】
従来技術に存在する問題に対して、本願が提供する技術的解決策は、異なるアカウントに対して注文権限、決済権限などを含む異なる購入者の操作権限を構成し、異なる操作権限を有する複数のアカウントの結合を実行することを許可する。実際に取引を実行するとき、結合関係を有するアカウントは、１つの取引操作を完了するために協働することができ、これにより複数の人々が同じアカウントを共有することによって引き起こされる様々な問題を効果的に回避する。
【００１７】
小企業において、Ａが購入担当者であり、Ｂが財務責任者であると仮定する。本願の解決策に基づいて、取引システムでは、ユーザＡとユーザＢに対してそれぞれ異なるアカウントを登録することができる。登録されたアカウントＩＤは、それぞれＩＤ＿ａとＩＤ＿ｂであり、アカウントＩＤ＿ａは購入者ユーザの注文権限を有し、アカウントＩＤ＿ｂは購入者ユーザの決済権限を有すると仮定する。その後、アカウントＩＤ＿ａとＩＤ＿ｂとの間の結合関係が取引システム側で確立され、記憶される。結合関係を確立することの意義は、現在の取引システムにおいて、結合された２つのアカウントが同じ取引を完了するために購入者として協働して連係することが許可されることである。
【００１８】
図１は、本願が提供するネットワーク取引方法の相互フローチャートである。図に含まれる相互サブジェクトは、アカウントＩＤ＿ａ及びアカウントＩＤ＿ｂであり、すなわち、それらは論理的相互サブジェクト、又は取引システムのソフトウェアシステムにおける「アカウント」オブジェクトの２つの具体例であると理解できることに留意されたい。それらは、アカウントに現在ログインしている携帯電話、ＰＣなどのような実際のユーザ機器として理解することもできる。「取引システム」はまた、広義にはネットワーク取引を実行するために使用されるソフトウェア及びハードウェアプラットフォームと理解することができる。それらの要素は、本願の解決策の説明には影響しない。
【００１９】
Ｓ１０１、アカウントＩＤ＿ａは取引システムに注文を送信する。
【００２０】
前述の説明によると、アカウントＩＤ＿ａは注文権限を有するアカウントである。通常の状況では、このアカウントは、実際に注文作業を実行するユーザ（例えば、購入担当者）によって使用される。ここでは、アカウントＩＤ＿ａが購入者Ａによって使用されると仮定する。そして購入者Ａは、電子商取引プラットフォームで購入する商品のモデル、スタイル、数量、販売業者などを選択し、特定の操作を使用して対応する注文を生成し、注文を取引システムに送信する。説明の便宜上、この注文はＸとして識別される。購入商品の情報を含むことに加えて、この注文には送信アカウントの識別子も含まれる必要がある、すなわち、この注文がアカウントＩＤ＿ａによって送信されたことを示すアカウントＩＤ＿ａも含む。
【００２１】
Ｓ１０２、予め記憶された結合関係に基づいてアカウントＩＤ＿ａに結合されるアカウントを決定する。
【００２２】
取引システムは注文を受けた後、最初に注文を提出したアカウント識別子を解析し、次に予め記憶されたアカウント結合関係に基づいて注文を提出したアカウントに結合されたアカウントを決定する。具体的には、「注文権限を有するアカウント」に結合された「決済権限を有するアカウント」を決定する。
【００２３】
本実施形態では、注文Ｘに対する注文アカウントがＩＤ＿ａであり、予め記憶された結合情報によれば、アカウントＩＤ＿ａに結合されたアカウントは、アカウントＩＤ＿ｂであると決定することができる。
【００２４】
Ｓ１０３、アカウントＩＤ＿ａによって提出された注文に対して、アカウントＩＤ＿ａに結合されたアカウントに決済要求を開始する。
【００２５】
本願の解決策によれば、１つの取引における注文及び決済は、同じアカウントによって完了される必要はない。この実施形態では、アカウントＩＤ＿ａは決済権限を有していないので、結合されたアカウントＩＤ＿ｂに転送され、注文Ｘに対する次の決済操作を完了させる。
【００２６】
結合されたアカウントへの決済要求の開始は、様々な方法で達成でき、例えば、取引システムの内部メッセージシステムを使用して対応するアカウントに通知メッセージを送信することによって達成できる。電子メール、テキストメッセージ、インスタントメッセージなどの他の連絡モードが対象アカウントと関連付けられている場合、これらのチャネルを介して、通知メッセージが対象アカウントに送信されるので、対象アカウントに対応する実際のユーザは、通知を見てできるだけ早く決済を完了することができる。
【００２７】
ユーザの決済を容易にするために、決済要求を確認するための通知メッセージにショートカット操作ポータルを提供することができる。例えば、注文情報インターフェースと決済確認インターフェースにユーザを直接リダイレクトできるリンクを通知メッセージの本文に追加することができ、又は決済ＱＲコード（登録商標）を通知メッセージの本文に追加することなどができる。決済ユーザの注文のレビュー要求を満たすために、詳細情報又は要約情報もまた、通知メッセージの本文又は決済確認インターフェースに追加することができる。
【００２８】
異なる実際のユーザは、取引システムによって提供される機能に依存することなく、通信できることが理解され得る。したがって、「アクティブ通知」は、要求される取引システムの機能ではない。
【００２９】
Ｓ１０４〜Ｓ１０５、アカウントＩＤ＿ｂは決済要求を確認し、取引システムは注文の決済が成功したと決定する。
【００３０】
アカウントＩＤ＿ｂが注文Ｘを確認して、対応する決済を実行した後、取引システムは関連する確認情報を受信する。次いで、この決済が成功して、次の発送及び配達プロセスに進むことを決定することができる。
【００３１】
従来技術と比較して、本願の解決策は、一態様において、仮想アカウントと実際のユーザ間の一対一の対応を確保するように、アカウント権限を実際の担当業務と一致させ、異なる操作権限を異なる購入者アカウントに対して構成することを可能にする。別の態様において、異なるアカウント間の結合関係を設定することによって、結合関係を有するアカウントは、１つの取引の複数操作を完了するために連係することができる。異なる業務を有するユーザは異なるアカウントを使用して各自の機能を実行する。これは、操作上の競合や繰り返しのログインなどの様々な問題を効果的に回避でき、全体的な作業効率が向上する。システム側では、それに応じてエラープロンプトやＩＤ認証などの余分な処理を減らすことができ、処理資源の不要な消費を減らすことができる。
【００３２】
上記の実施形態では、本願の基本的な解決策は「１つの注文アカウントの１つの決済アカウントへの結合」のみを使用して示されているが、本願の他の実施形態では、様々な複雑な使用要求を満たすために結合関係をより柔軟に構成することができる。更に以下に例を示す。
【００３３】
本願の解決策によれば、結合された２つのアカウントについて、一方は少なくとも購入者ユーザの注文権限を有し、他方は少なくとも購入者ユーザの決済権限を有するべきである。しかし、これは、各アカウントには１つの購入者ユーザ権限しか許可されないことを意味するわけではない。例えば、前述のアカウントＩＤ＿ａ及びアカウントＩＤ＿ｂについて、アカウントＩＤ＿ａは注文権限のみを有し、アカウントＩＤ＿ｂは注文権限及び決済権限の両方を有するように構成することができる。このアプローチに対応する実際の要求は、購入担当者がアカウントＩＤ＿ａを使用して注文のみできるが、決済はできない。責任者は、アカウントＩＤ＿ｂを使用して自身の注文を行うだけでなく、購入担当者によって行われた注文をレビューして決済することもできる。
【００３４】
それに対応して、前述のステップＳ１０２において、取引システムは、注文を受信し、注文を提出したアカウントの識別子を解析した後、このアカウントが決済権限を有するか否かを最初に決定する。有さない場合、予め記憶された結合関係に基づいてこのアカウントに結合されているアカウントを続けて決定し得る。注文を提出したアカウントが決済権限を有する場合（例えば、アカウントＩＤ＿ｂ）、それは従来の取引プロセスに基づいて取引を実行することができる。すなわち、同じアカウントが注文と決済を実行する。
【００３５】
取引システムにおけるアカウントは、購入者注文権限及び購入者決済権限に加えて、他の様々な権限を含み得ることが理解され得る。これは、本願の解決策に関係しなくともよく、さらに説明はされない。
【００３６】
さらに、本願の解決策に基づいて、各結合関係に対応するアカウントの数は２であるが、任意の１つのアカウントに対して複数の結合関係を有することが許容される。すなわち、１つのアカウントを複数の他のアカウントに結合することができる。
【００３７】
例えば、決済権限を有する１つのアカウントは、注文権限を有する複数のアカウントに結合されている。
【００３８】
この種の結合構成に対応する実際の要求は、複数の購入者がそれぞれ自分の専用アカウントを使用して注文を行い、次いでそれをレビュー及び決済のためにプリンシパルに提出することができる。既存の技術が提供する同じアカウントを複数の人々が共有している場合、実際の実施が非常に面倒になることを想像するのは難しいことではない。しかし、本願の解決策を実装することによって、決済権限を有する１つのアカウントを、注文権限を有する複数のアカウントと一体に結合するという必要性を満たすことは非常に簡単であろう。
【００３９】
典型的な設定方法は、メインアカウントとサブアカウントのシステムを設定することである。１つのメインアカウントは、その名前で複数のサブアカウントを開くことができ、サブアカウントとメインアカウント間は自動的に結合関係を確立し、メインアカウントのユーザはサブアカウントを増減して、サブアカウント権限を修正することにより、実際の実施における管理要求を満たす。例えば、メインアカウントは決済権限を有し、それを使用のために責任者と財務管理者に提供することができる。このメインアカウントの名前で、複数の購入担当者による使用のために注文権限を有する複数のサブアカウントを開くことができる。この構成解決策では、異なる購入担当者はサブアカウントを別々に使用して購入することができ、すべての注文情報はメインアカウントに報告され、関連するプリンシパルがこれらの注文の統一されたレビューと決済を行う。
【００４０】
注文権限を有する１つのアカウントは、決済権限を有する複数のアカウントに結合される。
【００４１】
この種の結合構成に対する実際の要求は、１つの購入担当者が複数の異なる部門のために購入し、それに応じて異なるプリンシパルが注文をレビューし、決済を確認する必要があることである。
【００４２】
この結合構成では、注文に対する決済アカウントは一意ではないので、提出された注文は決済権限アカウントと共に指定アカウントの識別子を含む必要があり、取引システムが現在の注文を決済するためのアカウントを決定することができる。もちろん、注文に含まれる決済権限を有するアカウントの識別子に関して、取引システムはさらに注文を提出したアカウントとその指定された決済アカウントとの間に結合関係を有するか否かをさらに検証できる。さらに、取引システムはまた、注文が提出される前に、結合関係に基づいて、結合された複数の決済アカウントの情報を現在の注文アカウントに提供して、直接の選択を容易にする。要約すると、取引システムは、予め記憶された結合情報と注文に含まれるアカウント識別子とに基づいて、現在の注文に対する決済要求を送信するアカウントを決定することができる。
【００４３】
例えば、注文権限を有するアカウントＩＤ＿ａは、決済権限を有する３つのアカウントＩＤ＿ｂ１、ＩＤ＿ｂ２、ＩＤ＿ｂ３に結合される。したがって、アカウントＩＤ＿ａが注文を行うと、取引システムは、ＩＤ＿ｂ１、ＩＤ＿ｂ２、ＩＤ＿ｂ３を注文確認インターフェースにリストの形式で表示でき、現在の注文の決済アカウントとして１つを選択するように購入者ユーザに問い合わせる。注文ユーザがＩＤ＿ｂ２を選択するとすれば、「ＩＤ＿ｂ２」が注文に追加情報として含まれ、次に取引システムは、この注文の決済要求をアカウントＩＤ＿ｂ２に直接送信する。
【００４４】
本願の解決策に基づいて、アカウント間の結合関係は、アカウント登録段階で指定されてもよく、又はアカウント登録後に必要に応じて指定され又は修正されてもよい。
【００４５】
また、本願の実施例に記載された「取引システム」は、広義にはネットワーク取引を実行するためのソフトウェア及びハードウェアを指すものであり、特定の物理的装置又は電子商取引プラットフォームとして理解されるべきではない。例えば、第三者決済システムを使用する場合、「取引システム」は機能的に２つの部分、すなわち、電子商取引プラットフォームと決済プラットフォームとに分割することができる。ここで、電子商取引プラットフォームは、主に「注文」に関連する機能を実行させるために使用され、決済プラットフォームは、主に「決済」に関連する機能を実行させるために使用される。本願の解決策に対応する改善されたプロセスは以下の通りである。第１のアカウントは注文を電子商取引プラットフォームに提出する。電子商取引プラットフォームは、決済プラットフォームを介して第２のアカウントへの決済要求を開始する。第２のアカウントが決済プラットフォームを介して決済を完了した後、決済プラットフォームは成功した決済情報を電子商取引プラットフォームにフィードバックして、電子商取引プラットフォームはこの注文の決済が成功して、次の発送及び配達のプロセスに進むことができることを決定してもよい。
【００４６】
ここで注意する必要があるのは、電子商取引プラットフォームと決済プラットフォームでは異なるアカウントシステムを使用できるが、１人の実際のユーザが電子商取引プラットフォームアカウントと決済プラットフォームアカウントに対してクロスプラットフォームの結合関係を有するべきである（ここでの「結合」は、本願の解決策における「結合」とは異なる意味を有することに注意されたい）。したがって、本願の解決策における２つのアカウント間の結合は、電子商取引プラットフォーム内の２つのアカウントの結合、決済プラットフォーム内の２つのアカウントの結合、又は電子商取引プラットフォームアカウントと決済プラットフォームアカウントとの間の結合とすることができる。それに対応して、結合関係は、電子商取引プラットフォーム又は決済プラットフォームに記憶されてもよく、又はこれらは特定の方法で２つのプラットフォーム間で交換、同期することができる。これは必要に応じて当業者によって柔軟に構成できる。
【００４７】
前述の方法の実施形態に対応して、本願は権限分離制御に基づくネットワーク取引装置をさらに提供する。本装置は取引システム側に構成される。図２に示すように、本装置は以下を含むことができる。
【００４８】
結合関係記憶モジュール１５０は、異なるアカウント間の予め確立された結合関係を記憶するために使用される。２つの結合アカウントのうちのいずれか一方は少なくとも購入者ユーザ注文権限を有し、他方は少なくとも購入者ユーザ決済権限を有する。
【００４９】
注文受信モジュール１１０は、第１のアカウントによって提出された注文を受信するために使用される。
【００５０】
決済アカウント決定モジュール１２０は、予め記憶された結合関係に基づいて第１のアカウントに結合された第２のアカウントを決定するために使用される。
【００５１】
決済要求開始モジュール１３０は、第１のアカウントによって提出された注文に対して第２のアカウントへの決済要求を開始するために使用される。
【００５２】
決済決定モジュール１４０は、第２のアカウントが決済要求を確認した後に、注文決済が成功したと決定するために使用される。
【００５３】
本願の特定の実施方法において、決済アカウント決定モジュール１２０は、第１のアカウントが決済権限を有するか否かを決定し、有さない場合、予め記憶された結合関係に基づいて第１のアカウントに結合された第２のアカウントを決定するために使用される。
【００５４】
本願の特定の実施方法では、決済要求開始モジュール１３０は、
取引システムの内部メッセージを使用して、決済要求通知メッセージを第２のアカウントに送信し、
又は、
第２のアカウントの関連する連絡モードを使用して、決済要求通知メッセージを第２のアカウントに送信するために使用される。
【００５５】
本願の特定の実施形態では、決済要求通知メッセージには、ショートカット操作ポータルが提供されてもよく、決済要求を確認するために使用される。
【００５６】
本願の特定の実装方法では、異なるアカウント間の結合関係は、
決済権限を有する１つのアカウントが注文権限を有する複数のアカウントに結合されること、
又は、
注文権限を有する１つのアカウントが決済権限を有する複数のアカウントに結合されること、を含む。
【００５７】
本願の特定の実施方法において、注文権限を有する１つのアカウントが決済権限を有する複数のアカウントに結合される場合、第１のアカウントによって提出された注文は、決済権限を有する指定されたアカウントの識別子を含むことができる。
【００５８】
それに対応して、決済アカウント決定モジュール１２０は、予め記憶された結合情報及び識別子に基づいて、第１のアカウントに結合された第２のアカウントを決定するように使用されてもよい。
【００５９】
本願がソフトウェアと必要な汎用ハードウェアプラットフォームとによって実現され得ることは、上記の実施形態の説明から当業者には明らかであろう。そのような理解に基づいて、本願の技術的解決策に不可欠であるか、又は先行技術に貢献する部分は、ソフトウェア製品の形で具体化されてもよい。このコンピュータソフトウェア製品は、ＲＯＭ／ＲＡＭ、磁気ディスク、又は光学ディスクなどの記憶媒体に記憶されてもよく、コンピュータ装置（パーソナルコンピュータ、サーバ、又はネットワークデバイスなどでもよい）に本願の実施形態の方法、又は実施形態の特定の部分を実行させるための複数の命令を含むことができる。
【００６０】
本明細書における様々な実施形態は漸進的に記載されており、様々な実施形態間の同一又は類似の部分は互いに参照されることがある。各実施形態は他の実施形態との相違点に焦点を合わせている。特に、装置の実施形態の説明は方法の実施形態と基本的に同様であるので、比較的単純であり、方法の実施形態を参照することによって関連する特徴の説明は十分である。上述の装置の実施形態は単なる例示である。ここで、別々の部分として説明されたモジュールは物理的に分離されてもされなくてもよい。本願の実施形態の解決策を実施する場合、各モジュールの機能は、同一又は複数のソフトウェア及び／又はハードウェアユニットで達成されてもよい。実施形態の解決策の目的を達成するためには、実際の必要性に基づいて、モジュールの一部又はすべてを選択してもよい。当業者は、いかなる創造的な努力なしに、理解し実行することができる。
【００６１】
上記の説明は本願の特定の実施形態にすぎない。当業者は本願の原理から逸脱することなくいくつかの改良及び修正を加えることもでき、それらは本願の保護範囲とみなされるべきであることに留意されたい。
【図１】
2019526115.tif 000003
【図２】
2019526115.tif 000004
【国際調査報告】
2019526115.tif 000005
2019526115.tif 000006
2019526115.tif 000007
2019526115.tif 000008