特許 7460248 支払い処理方法、電子機器及びコンピュータプログラム

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

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

(11)【特許番号】

(24)【登録日】2024-03-25

(45)【発行日】2024-04-02

(54)【発明の名称】支払い処理方法、電子機器及びコンピュータプログラム

(51)【国際特許分類】

   G06Q 20/20 20120101AFI20240326BHJP

   G06Q 20/40 20120101ALI20240326BHJP

   G06Q 30/0207 20230101ALI20240326BHJP

   G06Q 30/0238 20230101ALI20240326BHJP

   G06Q 50/10 20120101ALI20240326BHJP

【ＦＩ】

G06Q20/20

G06Q20/40

G06Q30/0207

G06Q30/0238

G06Q50/10

【請求項の数】 13

(21)【出願番号】P 2021565093

(86)(22)【出願日】2020-05-13

(65)【公表番号】

(43)【公表日】2022-07-13

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

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

(87)【国際公開日】2020-12-03

【審査請求日】2021-11-02

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

(32)【優先日】2019-05-24

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

(73)【特許権者】

【識別番号】517392436

【氏名又は名称】▲騰▼▲訊▼科技（深▲セン▼）有限公司

【氏名又は名称原語表記】ＴＥＮＣＥＮＴ ＴＥＣＨＮＯＬＯＧＹ （ＳＨＥＮＺＨＥＮ） ＣＯＭＰＡＮＹ ＬＩＭＩＴＥＤ

【住所又は居所原語表記】３５／Ｆ，Ｔｅｎｃｅｎｔ Ｂｕｉｌｄｉｎｇ，Ｋｅｊｉｚｈｏｎｇｙｉ Ｒｏａｄ，Ｍｉｄｗｅｓｔ Ｄｉｓｔｒｉｃｔ ｏｆ Ｈｉ－ｔｅｃｈ Ｐａｒｋ，Ｎａｎｓｈａｎ Ｄｉｓｔｒｉｃｔ， Ｓｈｅｎｚｈｅｎ，Ｇｕａｎｇｄｏｎｇ ５１８０５７，ＣＨＩＮＡ

(74)【代理人】

【識別番号】100110364

【弁理士】

【氏名又は名称】実広 信哉

(74)【代理人】

【識別番号】100150197

【弁理士】

【氏名又は名称】松尾 直樹

(72)【発明者】

【氏名】▲呉▼ ▲進▼▲發▼

(72)【発明者】

【氏名】王 ▲軍▼

(72)【発明者】

【氏名】▲盧▼ ▲シン▼▲暢▼

(72)【発明者】

【氏名】王 少▲鳴▼

(72)【発明者】

【氏名】郭 ▲潤▼▲増▼

【審査官】阿部 圭子

(56)【参考文献】

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

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

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

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

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

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

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

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

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

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

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

【請求項1】

第１の機器によって実行される、支払い処理方法であって、
注文情報を取得して、店舗が提供する決済端末である第２の機器が前記注文情報を展示するように前記注文情報を前記第２の機器に送信するステップであって、前記第１の機器が会員情報を取得し、前記会員情報に含まれる割引情報に基づいて前記注文情報に含まれる商品価格情報を算出し、前記第２の機器に送信する、ステップと、
前記第２の機器から送信された支払いコードを受信するステップであって、前記支払いコードは、前記第２の機器がユーザによりトリガされた確認支払いコマンドを受信した後、前記ユーザのユーザ支払いアイデンティティに応じて生成されたものであるステップと、
前記支払いコードに基づいて、前記支払いコードに対応する支払いアカウントから前記注文情報を支払い処理して、支払い結果を取得するステップと、
前記第２の機器が前記支払い結果を展示するように、前記支払い結果を前記第２の機器に送信するステップとを含む、
支払い処理方法。

【請求項2】

前記第１の機器は注文情報を取得する前に、前記方法は、さらに、
前記第２の機器にユーザアイデンティティ情報要求を送信するステップと、
前記第２の機器から送信されたユーザアイデンティティ情報を受信するステップであって、前記ユーザアイデンティティ情報は、前記第２の機器が前記ユーザの入力したアイデンティティ特徴に基づいて取得したものであるステップと、
前記ユーザアイデンティティ情報によりユーザが登録会員ユーザであると示された場合、前記ユーザアイデンティティ情報に基づいて、前記ユーザアイデンティティ情報に対応する会員情報を取得するステップであって、前記会員情報は、ユーザ登録情報及び消費行為に関連する権益情報を示すステップと、
前記第２の機器が前記会員情報を展示するように、前記会員情報を前記第２の機器に送信するステップとを含む、
請求項１に記載の方法。

【請求項3】

前記アイデンティティ特徴が顔情報である場合、前記ユーザアイデンティティ情報は、前記第２の機器が採集した顔情報に基づいてサーバを介してマッチングして取得したものであり、前記ユーザアイデンティティ情報によりユーザが登録会員ユーザであると示された場合、前記ユーザアイデンティティ情報が前記ユーザの会員コードである請求項２に記載の方法。

【請求項4】

前記第１の機器は注文情報を取得して第２の機器に送信した後、前記方法はさらに、
前記第２の機器から返信された注文修正要求を受信した後、前記注文修正要求に基づいて、注文情報を更新するステップを含む請求項１または２に記載の方法。

【請求項5】

前記第１の機器と前記第２の機器が、双方向通信モジュールに基づいて互いにデータパケットを送受信する請求項１～請求項４のいずれか１項に記載の方法。

【請求項6】

前記第１の機器と前記第２の機器が、双方向通信モジュールに基づいて互いにデータパケットを送受信することは、
前記第１の機器は、トラヒック層、アプリケーション層、伝送層及びリンク層を順に介してデータパケットを送信し、リンク層、伝送層、アプリケーション層及びトラヒック層を順に介してデータパケットを受信するステップと、
前記第２の機器はトラヒック層、アプリケーション層、伝送層及びリンク層を順に介してデータパケットを送信し、リンク層、伝送層、アプリケーション層及びトラヒック層を順に介してデータパケットを受信するステップとを含む請求項５に記載の方法。

【請求項7】

データパケットが物理通信リンクを通って標準的なリードインタフェース、ライトインタフェース又は制御インタフェースを介して伝送層に伝送され、データパケットが伝送層を通って前記標準的なリードインタフェース、ライトインタフェース又は制御インタフェースを介して物理通信リンクに伝送されるように、前記リンク層において標準的なリードインタフェース、ライトインタフェース及び制御インタフェースを定義し、物理通信リンクをリンク層プロトコルとして採用する請求項６に記載の方法。

【請求項8】

前記リンク層の物理通信リンクは、ＲＳ２３２インタフェース、ＵＳＢ、ネットワークライン、ブルートゥースのいずれかを採用する請求項７に記載の方法。

【請求項9】

前記伝送層においてハートビートキープアライブメカニズムを採用して前記リンク層の物理通信リンクの接続性を検出する請求項７または８に記載の方法。

【請求項10】

店舗が提供する決済端末である第２の機器によって実行される、支払い処理方法であって、
第１の機器から送信された、前記第１の機器が会員情報を取得し、前記会員情報に含まれる割引情報に基づいて商品価格情報を算出することによって得られた注文情報を受信するステップであって、前記注文情報を、前記第２の機器が受信する、ステップと、
前記注文情報を展示するステップと、
ユーザのトリガした確認支払いコマンドを受信した後、前記ユーザのユーザ支払いアイデンティティに基づいて支払いコードを生成し、前記支払いコードを前記第１の機器に送信するステップと、
前記第１の機器から送信された支払い結果を受信するステップであって、前記支払い結果は、前記第１の機器が、前記支払いコードに基づいて、前記支払いコードに対応する支払いアカウントから前記注文情報を支払い処理して得られるものであるステップと、
前記支払い結果を展示するステップとを含む、
方法。

【請求項11】

前記第１の機器から送信された注文情報を受信する前に、前記方法はさらに、
前記第１の機器から送信されたユーザアイデンティティ情報要求を受信するステップと、
前記ユーザの入力したアイデンティティ特徴に基づいてユーザアイデンティティ情報を取得し、前記ユーザアイデンティティ情報を前記第１の機器に送信するステップと、
前記第１の機器から送信された会員情報を受信するステップであって、前記会員情報は前記第１の機器が、前記ユーザアイデンティティ情報によりユーザが登録会員ユーザであると示されたことを特定した場合、前記ユーザアイデンティティ情報に基づいて取得されたものであり、前記会員情報は、ユーザ登録情報及び消費行為に関連する権益情報を示すステップと、
前記会員情報を展示するステップとを含む請求項１０に記載の方法。

【請求項12】

メモリ、プロセッサ、及び、メモリに記憶されかつプロセッサにより実行されるコンピュータプログラムを含む電子機器であって、
前記プロセッサが前記プログラムを実行すると、請求項１～９又は請求項１０～１１のいずれか１項に記載の方法を実現することを特徴とする電子機器。

【請求項13】

コマンドが含まれるコンピュータプログラムであって、
コンピュータにより実行されると、請求項１～９又は請求項１０～１１のいずれか１項に記載の方法を実行することを特徴とするコンピュータプログラム。

【発明の詳細な説明】

【技術分野】

【0001】

本出願は２０１９年０５月２４日に中国専利局に提出した、出願番号が２０１９１０４３７６０７．９であり、出願の名称が「支払い処理方法及び装置」である中国特許出願の優先権を主張し、その全ての内容は援用により本出願に結合される。

【0002】

本出願は、通信技術の分野に関し、特に、支払い処理に関する。

【背景技術】

【0003】

移動支払いユーザの規模が急速に増加し、移動支払いのオフライン支払い分野への高速浸透により、多大に支払いシナリオを豊かにして、ユーザの移動支払いに対する要求もますます高くなり、従来技術において、支払い機器（例えばスキャナー、フェイススキャニング支払い機器など）とレジスタの通信方式はいずれも一方向通信方式であって、該一方向通信方式は具体的に以下のとおりであり、支払い機器からレジスタ側に情報を送信して処理するだけであるが、レジスタは支払い機器に情報を送信することができず、このように、支払い機器とレジスタは双方向通信を実現できず、これにより支払い機器の機能が単一である。

【発明の概要】

【発明が解決しようとする課題】

【0004】

本出願の実施例は、従来技術における支払い機器とレジスタの双方向通信が実現できないという問題を解決するために、支払い処理方法、電子機器及びコンピュータ読み取り可能な記憶媒体を提供し、支払い機器の機能の多様性を向上させることに役立つ。

【課題を解決するための手段】

【0005】

本出願の実施例にかかる具体的な技術案は以下の通りである。
本出願の一つの実施例は支払い処理方法を提供し、当該支払い処理方法は第１の機器によって実行され、
注文情報を取得して、第２の機器が注文情報を展示するように、前記注文情報を第２の機器に送信するステップと、
前記第２の機器から送信された支払いコードを受信するステップであって、前記支払いコードは、前記第２の機器がユーザによりトリガされた確認支払いコマンドを受信した後、前記ユーザのユーザ支払いアイデンティティに応じて生成されたものであるステップと、
前記支払いコードに基づいて、前記支払いコードに対応する支払いアカウントから前記注文情報を支払い処理して、支払い結果を取得するステップと、
前記第２の機器が前記支払い結果を展示するように、前記支払い結果を前記第２の機器に送信するステップとを含む。

【0006】

本出願の別の一つの実施例は支払い処理方法を提供し、前記支払い処理方法は第２の機器によって実行され、
第１の機器から送信された注文情報を受信するステップと、
前記注文情報を展示するステップと、
ユーザのトリガした確認支払いコマンドを受信した後、前記ユーザのユーザ支払いアイデンティティに応じて支払いコードを生成し、前記支払いコードを前記第１の機器に送信するステップと、
前記第１の機器から送信された支払い結果を受信するステップであって、前記支払い結果は、前記第１の機器が前記支払いコードに基づいて、前記支払いコードに対応する支払いアカウントから前記注文情報を支払い処理して得られるものであるステップと、
前記支払い結果を展示するステップとを含む。

【0007】

本出願の別の一つの実施例は支払い処理装置を提供し、当該支払い処理装置は、
注文情報を取得するための第１の取得モジュールと、
前記第２の機器が前記注文情報を展示するように、前記注文情報を第２の機器に送信し、前記第２の機器から送信された支払いコードを受信するための双方向通信モジュールであって、前記支払いコードは、前記第２の機器が、ユーザのトリガされた確認支払いコマンドを受信した後、前記ユーザのユーザ支払いアイデンティティに応じて生成されたものである双方向通信モジュールと、
前記支払いコードに基づいて、前記支払いコードに対応する支払いアカウントから前記注文情報を支払い処理して支払い結果を得るための処理モジュールとを含み、
前記双方向通信モジュールは、さらに、前記第２の機器が前記支払い結果を展示するように、前記支払い結果を前記第２の機器に送信するために用いられる。

【0008】

本出願の別の一つの実施例は支払い処理装置を提供し、前記支払い処理装置は、
第１の機器から送信された注文情報を受信するための双方向通信モジュールと、
前記注文情報を展示するための第１の展示モジュールと、
ユーザのトリガした確認支払いコマンドを受信した後、前記ユーザのユーザ支払いアイデンティティに応じて支払いコードを生成するための生成モジュールと、
さらに、前記支払いコードを前記第１の機器に送信し、前記第１の機器から送信された支払い結果を受信するための双方向通信モジュールと、
前記支払い結果を展示するための第２の展示モジュールとを含み、
前記支払い結果は、前記第１の機器が前記支払いコードに基づき、前記支払いコードに対応する支払いアカウントから前記注文情報を支払い処理して得られるものである。

【0009】

本出願の別の一つの実施例は、メモリ、プロセッサ及びメモリに記憶されかつプロセッサにより実行されるコンピュータプログラムを含む電子機器を提供し、前記プロセッサが前記プログラムを実行すると、上記いずれかの支払い処理方法を実現する。

【0010】

本出願の別の一つの実施例は、コンピュータプログラムが記憶されたコンピュータ読み取り可能な記憶媒体を提供し、前記コンピュータプログラムがプロセッサにより実行されると、上記いずれかの支払い処理方法を実現する。

【0011】

本出願の別の一つの実施例は、コマンドが含まれるコンピュータプログラムを提供し、コンピュータで実行されると、前記コンピュータに上記いずれかの支払い処理方法を実行させる。

【0012】

本出願の実施例において、第１の機器は注文情報を取得して第２の機器に送信し、第２の機器が注文情報を展示して支払いコードを生成して第１の機器に送信し、第１の機器は支払いコードに基づいて以降の支払い処理を実行し、支払い結果を第２の機器に送信することができ、これにより第２の機器がユーザに支払い結果を展示することができ、第１の機器と第２の機器が双方向通信の能力を備え、互いに情報を送受信することができ、従来技術におけるレジスタが支払い機器にメッセージを送信することができないという問題を解決し、それに、ユーザが支払い過程における明細状況を直感的に知ることができるように、第２の機器に注文情報、支払い結果等を展示させることができ、このように、支払い機器の機能の多様性を向上させることに役立ち、ユーザの消費体験を向上させ、また支払いの安全性と正確性を向上させる。

【図面の簡単な説明】

【0013】

【図1】関連技術における支払い機器とレジスタの通信方式の効果模式図である。

【図2】本出願の実施例における支払い処理方法のアプリケーションアーキテクチャ模式図である。

【図3】本出願の実施例における一つの支払い処理方法のフローチャートである。

【図4】本出願の実施例における別の一つの支払い処理方法のフローチャートである。

【図5】本出願の実施例における一つの支払い処理方法のフローチャートである。

【図6】本出願の実施例における別の一つの支払い処理方法のフローチャートである。

【図7】本出願の実施例における双方向通信フレームの原理模式図である。

【図8】本出願の実施例におけるリンク層の設計効果模式図である。

【図9】本出願の実施例における伝送層の送受信フローの模式図である。

【図10】本出願の実施例におけるアプリケーション層の要求―応答フローの模式図である。

【図11】本出願の実施例における第２の機器が第１の機器に情報を送信する交互フローチャートである。

【図12】本出願の実施例における第１の機器が第２の機器に情報を送信する交互フローチャートである。

【図13】本出願の実施例における支払い機器とレジスタの双方向通信方式の効果模式図である。

【図14】本出願の実施例における会員情報の展示段階のプロセスインタフェース模式図である。

【図15】本出願の実施例における支払い詳細の展示段階のプロセスインタフェース模式図である。

【図16】本出願の実施例における一つの支払い処理装置の構成模式図である。

【図17】本出願の実施例における別の一つの支払い処理装置の構成模式図である。

【図18】本出願の実施例におけるサーバの構成模式図である。

【図19】本出願の実施例における電子機器の構成模式図である。

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

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

これにより、ユーザは第２の機器で会員情報を知り、自分の会員権益を了解することができ、ユーザの消費体験を向上させる。

【0071】

さらに、ステップ５３０を実行した後、キャッシャーは第１の機器を介して商品情報を入力し、注文を生成し、後続の支払いフローを行うことができ、即ち下記ステップ５４０－ステップ５７０である。

【0072】

ステップ５４０において、第１の機器は、注文情報を取得して、前記第２の機器が注文情報を展示するように、前記第２の機器に注文情報を送信する。

【0073】

ステップ５５０において、第１の機器は第２の機器から送信された支払いコードを受信し、そのうち、支払いコードは、第２の機器によりユーザがトリガした確認支払いコマンドを受信した後、該ユーザのユーザ支払いアイデンティティに基づいて生成されたものである。

【0074】

ステップ５６０において、第１の機器は、支払いコードに基づき、該支払いコードに対応する支払いアカウントから注文情報を支払い処理し、支払い結果を取得する。

【0075】

ステップ５７０において、第１の機器は、第２の機器が支払い結果を展示するように、前記支払い結果第２の機器に送信する。

【0076】

これにより、第１の機器はさらに会員情報を取得し、且つ注文情報を生成する時会員情報（例えば、クーポンがあるか否か、ある商品の会員割引等があるか否かの情報）に基づいて注文情報における一部の情報（例えば、割引商品の実際価格等）を算出することができ、且つ第１の機器は会員情報を第２の機器に送信することもでき、第２の機器に会員情報、注文情報、支払い結果などの情報を展示させることができ、支払い過程の制御能力がより強く、より豊富である。

【0077】

相応的に、図５に示す実施例に対応し、本出願はさらに他の支払い処理方法を提供し、図６に示すように、本出願の実施例における他の支払い処理方法のフローチャートであり、主に第２の機器に適用され、この方法は以下のステップを含む。

【0078】

ステップ６００において、第２の機器は、第１の機器から送信されたユーザアイデンティティ情報要求を受信する。

【0079】

ステップ６１０において、第２の機器はユーザが入力したアイデンティティ特徴に応じてユーザアイデンティティ情報を取得し、且つユーザアイデンティティ情報を第１の機器に送信する。

【0080】

ステップ６２０において、第２の機器は第１の機器から送信された会員情報を受信し、そのうち、会員情報は、第１の機器が、ユーザアイデンティティ情報によりユーザが登録会員ユーザであると示されることを特定した場合、ユーザアイデンティティ情報に基づいて取得されたものであり、会員情報はユーザ登録情報及び消費行為に関連する権益情報を示す。

【0081】

ステップ６３０において、第２の機器が会員情報を展示する。

【0082】

ステップ６４０において、第２の機器が第１の機器から送信された注文情報を受信する。

【0083】

ステップ６５０において、第２の機器が注文情報を展示し、ユーザのトリガした確認支払いコマンドを受信した後、該ユーザのユーザ支払いアイデンティティに応じて支払いコードを生成し、支払いコードを第１の機器に送信する。

【0084】

ステップ６６０において、第２の機器が第１の機器から送信された支払い結果を受信し、そのうち、支払い結果は、第１の機器によって支払いコードに基づいて、該支払いコードに対応する支払いアカウントから注文情報を支払い処理して得られるものである。

【0085】

ステップ６７０において、第２の機器が支払い結果を展示する。

【0086】

これにより、第１の機器と第２の機器は双方向通信能力を備え、第２の機器は第１の機器から送信された会員情報、注文情報、支払い結果などを受信することにより、展示することもでき、ユーザにより多くの支払い明細情報を展示する。

【0087】

なお、本出願の実施例における第１の機器及び第２の機器は設計された双方向通信フレームにより、双方向通信の能力を実現し、具体的に、第１の機器及び第２の機器は双方向通信モジュールに基づいて互いにデータパケットを送受信する。

【0088】

そのうち、データパケットは、上記ユーザアイデンティティ情報要求、会員情報、注文情報、支払いコード、支払い結果等であってもよく、いくつかの応答パケットを含んでもよく、交互方式はいずれも双方向通信モジュールを介して行われるものである。

【0089】

そのうち、第１の機器及び第２の機器は双方向通信モジュールに基づいて互いにデータパケットを送受信することは、具体的には、
第１の機器はトラヒック層、アプリケーション層、伝送層及びリンク層を順に介してデータパケットを送信し、リンク層、伝送層、アプリケーション層及びトラヒック層を順に介してデータパケットを受信するステップと、
第２の機器はトラヒック層、アプリケーション層、伝送層及びリンク層を順に介してデータパケットを送信し、リンク層、伝送層、アプリケーション層及びトラヒック層を順に介してデータパケットを受信するステップとを含む。

【0090】

具体的には、次に本出願の実施例における双方向通信フレームについて説明する。図７に示すように、本出願の実施例における双方向通信フレームの原理模式図である。

【0091】

図７に示すように、プロトコルフレームとアプリケーションフレームに分けられ、そのうち、アプリケーションフレームがトラヒック層に分割され、トラヒック使用中にコールされ、異なるトラヒックに基づいて異なるインタフェース又はプロトコルを設置することができ、例えば、プロトコルバッファ（Ｐｒｏｔｏｃｏｌ Ｂｕｆｆｅｒ、ＰＢ）プロトコル、受信（Ｒｅｃｅｉｖｅ、Ｒｘ）インタフェースを採用し、本出願の実施例には制限されない。プロトコルフレームがリンク層、伝送層及びアプリケーション層に分けられることができ、各層の相互協働により双方向通信機能が完成され、本出願の実施例には主に分層設計を採用し、プロトコル階層を抽象化し、次にプロトコルフレームにおける各層について説明する。

【0092】

１、リンク層
機能定義について、リンク層データ連通を担当し、ハードウェア物理通信リンクの相違を遮蔽し、上層にオリジナルデータのリードライト能力及び物理通信リンクを操作し、すなわち物理通信スイッチを制御する能力を提供する。
具体的に、リンク層には標準的なリードインタフェース、ライトインタフェース及び制御インタフェースを定義し、データパケットが物理通信リンクを通じて、標準的なリードインタフェース、ライトインタフェース又は制御インタフェースを介して伝送層に伝送され、且つデータパケットが伝送層を通じて、標準的なリードインタフェース、ライトインタフェース又は制御インタフェースを介して物理通信リンクに伝送されるように、物理通信リンクをリンク層のプロトコルとして採用する。

【0093】

そのうち、リンク層の物理通信リンクは、ＲＳ２３２インタフェース、ＵＳＢ、ネットワークライン、ブルートゥースのいずれかを採用し、例えば、Ｓｏｃｋｅｔインタフェース、シリアルポートなどであるが、本出願の実施例にはこれらの物理通信リンクに限定されるものではなく、実際需要に応じて他の物理通信リンクを採用してもよく、図７では、シリアルポート、ＵＳＢ、Ｓｏｃｋｅｔのみを例にして説明する。

【0094】

これにより、現在いずれもある特定のハードウェアについて設計されるもので、例えばシリアルポートについて設計し、他の物理通信リンクを交換する際に、リンク層と伝送層のコールインタフェース又はプロトコルを再修正する必要があり、適応性及び移植性が劣ることに対して、本出願の実施例において実際通信の物理通信リンクを抽象化し、複数の伝送媒体をサポートすることができ、即ち異なる物理通信リンクに対してサポートし、異なる物理通信リンクの相違を遮蔽し、このように、実際にＵＳＢ、シリアルポート、ネットワークライン、ブルートゥース等の使用に関わらず、本出願の実施例で提供する双方向通信フレームを用いて通信を完了することができ、修正を行う必要がなく、物理通信リンクを切り替える必要がある場合、リンク層に要求される標準的なリードインタフェース、ライトインタフェース及び制御インタフェースを実現すればよく、上層に対してまったく視認不可である。

【0095】

図８を参照して、本出願の実施例におけるリンク層の設計効果模式図であり、図８に示すように、リンク層には標準的なリードインタフェース、ライトインタフェース及び制御インタフェースを定義し、リンク層と伝送層は該標準的なリードインタフェース、ライトインタフェース又は制御インタフェースを介してデータ通信を行い、伝送層において該標準的なリードインタフェース、ライトインタフェース又は制御インタフェースを設計コールするだけでよく、異なる物理通信リンクが伝送層に対して視認不可であり、異なる物理通信リンク、例えばＵＳＢ、ＲＳ２３２インタフェース、ネットワークインタフェース等は、該標準的なリードインタフェース、ライトインタフェース又は制御インタフェースと適応する。

【0096】

本出願の実施例において、リンク層の実現に際しては、必要な物理通信リンクを採用して第１の機器と第２の機器とを接続することができ、例えば、第２の機器はＲＳ２３２インタフェースを下層通信リンクとして選択し、同時に一本のＲＳ２３２転ＵＳＢケーブルを用いて第１の機器に接続する。

【0097】

２、伝送層
機能定義について、伝送層はアプリケーション層とリンク層との間に位置し、主にリンク層データを読み取り、解析、チェック、確認、重複排除などを行うタスクを担当し、有効データをアプリケーション層に正しく渡すとともに、アプリケーション層が送信する必要のあるデータに対して、組み立て、送信、確認待ちなどのタスクを行うことにより、上層トラヒック層に安定、確実、状態が分かる通信インタフェースを提供する。
具体的に、自定義されたプロトコルパケットフォーマットに従って、それぞれアプリケーション層から送信されたデータ及びリンク層から読み取ったデータを解析し、且つチェック、確認文字（Ａｃｋｎｏｗｌｅｄｇｅｍｅｎｔ、ＡＣＫ）、再送などの実装ロジックを約束し、及び伝送層においてハートビートキープアライブメカニズムを採用してリンク層の物理通信リンクの接続性を検出する。

【0098】

図９を参照して、本出願の実施例における伝送層の送受信フローの模式図であり、データライトプロセスとリードプロセスを含み、具体的に以下の通りである。

【0099】

第１の局面において、データライトプロセス、即ち送信プロセスであって、アプリケーション層のデータをリンク層に送信する。
Ｓ１、アプリケーション層が送信したデータをパケット化し、データパケット形式で送信キューに入れる。
Ｓ２、送信キューにおけるデータパケットをリンク層に順次送信する。
Ｓ３、リンク層から返信されたデータを受信し、パケット受信処理を行う。
Ｓ４、ＡＣＫパケットであれば、送信済みキューにおける対応するデータパケットの送信に成功したことを特定し、ずっと受信されていない場合、または再送信回数を超えている場合、送信済みキューにおける対応するデータパケットの送信が失敗したことを特定する。
Ｓ５、送信済みキューにおけるデータパケットに対して、リンク層の確認応答を待って、時間閾値を超えると、再送信する。

【0100】

第２の局面において、データリードプロセス、すなわち受信プロセスであって、リンク層データを読み取りアプリケーション層に伝送する。
Ｓ１１、リンク層のデータを解析し、データチェックを行う。
そのうち、データチェックはサインアルゴリズム等を採用して、制限されず、データが正しいか否かをチェックすることができる。
Ｓ１２、受信したデータを受信パケットキューに入れ、パケットタイプを特定し、パケットタイプがＡＣＫパケットであれば、ＡＣＫパケットに基づいて送信済みデータパケットを管理し、例えばＡＣＫパケットに対応する送信済みデータパケットを除くことができ、パケットタイプが実際データ内容を含むデータパケットであれば、データパケットを管理し、例えば、受信パケットキュー管理、重複排除処理、相応するＡＣＫパケットの返信などを行い、パケットタイプがハートビートパケットであれば、ハートビート管理を行い、例えば、ハートビートパケットに基づいてリンクの状態をメンテナンスし、相応するＡＣＫパケット等を返信することができ、ハートビートパケットは主にリンク層に対して接続性検出を行うために用いられ、ハートビート検出は、例えば同期シーケンス番号（Ｓｙｎｃｈｒｏｎｉｚｅ Ｓｅｑｕｅｎｃｅ Ｎｕｍｂｅｒｓ、ＳＹＮ）プロトコルなどを採用することができ、制限されない。
Ｓ１３、アプリケーション層は予め伝送層に登録され、伝送層にデータが到来するか否かを監視し、伝送層がデータパケットを受信した後、アプリケーション層に送信する。

【0101】

３、アプリケーション層
機能定義について、トラヒック層と伝送層との間に位置し、主に約束のアプリケーション層プロトコルに基づいてデータを受信又は送信することを担当し、伝送層から取得されたデータを約束プロトコルに従って解析して認識し、クライアント／サーバ（Ｃｌｉｅｎｔ／Ｓｅｒｖｅｒ、Ｃ／Ｓ）通信又はピアツーピア通信等のアプリケーションプロトコルを提供することができる。
具体的に、アプリケーション層は伝送層にデータを送信し、及び伝送層から送信されたデータを受信し、伝送層から受信したデータをトラヒック層に伝送し、通信する二つの端末はＣｌｉｅｎｔでもよく、同時にＳｅｒｖｅｒの能力も備え、双方の通信は、要求―応答のパターンで行うことができ、具体的に図１０を参照して、本出願の実施例におけるアプリケーション層の要求―応答フローの模式図であり、要求プロセス及び応答プロセスを含み、具体的に以下の通りである。

【0102】

第１の局面において、要求プロセス、すなわち送信プロセスであって、トラヒック層のデータを伝送層に送信する。
この要求プロセスは、上述した伝送層のデータライトプロセスと類似であり、具体的に以下の通りである。
Ｓ２１、トラヒック層から送信されたデータをパケット化し、要求パケットを要求キューに入れる。
Ｓ２２、要求キューにおける要求パケットを伝送層に順次送信する。
Ｓ２３、伝送層から返信されたデータを受信し、パケット受信処理を行う。
Ｓ２４、返信された応答パケットに基づき、応答待ちキューにおける各要求パケットを処理し、確認応答、タイムアウト再送、エラー等の処理を実行し、トラヒック層に送信することができる。

【0103】

第２の局面において、応答プロセス、即ち受信プロセスであって、伝送層データをトラヒック層に伝送する。
Ｓ３１、伝送層のデータを解析する。
Ｓ３２、受信されたパケットを受信パケットキューに入れ、パケットタイプを特定し、パケットタイプが応答パケットであれば、応答パケット管理を行い、例えば応答待ちキューから対応するオリジナル要求を見つけ、且つ応答パケットをトラヒック層に送信することができ、パケットタイプが要求パケットであれば、要求パケット管理を行い、例えば傍受者に新たな要求があったことを通知し、ここで、傍受者はトラヒック層である。
Ｓ３３、トラヒック層は予めアプリケーション層に登録され、アプリケーション層にデータが到来するか否かを監視し、アプリケーション層が要求パケットを受信した後、トラヒック層に送信する。

【0104】

これにより、図７に示すように、第１の機器の第１のアプリケーションと第２の機器の第２のアプリケーションが双方向通信を行う場合には、データの送受信は該双方向通信フレームを採用し、通信フローも同様であり、そして、一方が他方にデータを送信し且つ他方が該データを受信する過程であり、具体的には、一方はトラヒック層、アプリケーション層、伝送層、リンク層を介してデータを送信し、他方はリンク層、伝送層、アプリケーション層、トラヒック層を介して該データを受信する。

【0105】

これにより、本出願の実施例において提供する双方向通信フレームでは、多層プロトコル設計を採用し、多層協働によって双方向通信機能を実現し、そして、リンク層には標準インタフェースが定義され、異なる物理通信リンクをサポートし、物理通信リンクの相違を遮蔽することができ、様々な異なる物理通信リンクに適用することができ、適用性がより高く、アプリケーションとトラヒックに統一、便利的なコールインタフェースを提供し、安定、確実、一致的な双方向データ伝送を実現することができる。

【0106】

なお、本出願の実施例は双方向通信フレームの例のみを提供し、需要に応じてプロトコル階層を拡張し又は簡略化することもでき、例えばある層の機能を上又は下にして隣接する層に合わせてもよいし、ある層の機能をさらに１又は２層に細分化してもよく、具体的には制限されない。

【0107】

上記の実施例に基づいて、第１の機器と第２の機器の双方向通信のフローについて簡単に説明した。図１１に示すように、本出願の実施例における第２の機器が第１の機器に情報を送信する交互フローチャートであり、以下のステップを含む。

【0108】

ステップ１１００において、第１の機器のトラヒックモジュールは双方向通信モジュールを介して新たな要求が到来することを待つ。

【0109】

即ち、第１の機器は双方向通信モジュールにより第２の機器からの送信要求があるか否かを監視することができる。

【0110】

ステップ１１０１において、第２の機器のトラヒックモジュールは双方向通信モジュールを介して対端に要求を送信する。

【0111】

例えば、第１の機器が第２の機器から送信された要求に基づいて対応する処理を行うように、ここでの要求は、例えば会員コード、支払いコードなどの第２の機器が第１の機器に送信したデータパケットでもよい。

【0112】

ステップ１１０２において、第２の機器の双方向通信モジュールは、第１の機器の双方向通信モジュールに対してデータ伝送を行う。

【0113】

ステップ１１０３において、第１の機器の双方向通信モジュールはトラヒックモジュールに新たな要求を受信することを通知する。

【0114】

ステップ１１０４において、第１の機器のトラヒックモジュールはトラヒックロジック処理を行う。

【0115】

例えば、支払いコードである場合、第１の機器は支払いコードに基づいて後続の支払い処理を行い、後で第２の機器に支払い結果を返信することができる。

【0116】

ステップ１１０５において、第１の機器のトラヒックモジュールは双方向通信モジュールを介して対端に返信を送信する。

【0117】

ステップ１１０６において、第１の機器のトラヒックモジュールは関連リソースを解放する。

【0118】

ステップ１１０７において、第１の機器の双方向通信モジュールは、第２の機器の双方向通信モジュールに対してデータ伝送を行う。

【0119】

このように、第１の機器の該要求に対する返信データが双方向通信モジュールを介して第２の機器に送信される。

【0120】

ステップ１１０８において、第２の機器の双方向通信モジュールはトラヒックモジュールに対端（即ち、第１の機器）の返信を受信することを通知する。

【0121】

ステップ１１０９において、第２の機器のトラヒックモジュールはトラヒックロジック処理を行う。

【0122】

即ち、第２の機器は第１の機器の返信データに基づき、相応するトラヒックロジック処理を実行することができる。

【0123】

相応的に、図１２に示すように、本出願の実施例における第１の機器が第２の機器に情報を送信する交互フローチャートであり、以下のステップを含む。

【0124】

ステップ１２００において、第２の機器のトラヒックモジュールは双方向通信モジュールを介して新たな要求が到来することを待つ。

【0125】

即ち、第２の機器は双方向通信モジュールにより第１の機器からの送信要求があるか否かを監視することができる。

【0126】

ステップ１２０１において、第１の機器のトラヒックモジュールは双方向通信モジュールを介して対端（即ち、第２の機器）に要求を送信する。

【0127】

例えば、ここでの要求は、第１の機器が第２の機器に送信したデータパケットでもよく、例えばユーザのアイデンティティ情報要求、注文情報、会員情報、支払い結果などである。

【0128】

ステップ１２０２において、第１の機器の双方向通信モジュールは、第２の機器の双方向通信モジュールに対してデータ伝送を行う。

【0129】

ステップ１２０３において、第２の機器の双方向通信モジュールはトラヒックモジュールに新たな要求を受信することを通知する。

【0130】

ステップ１２０４において、第２の機器のトラヒックモジュールはトラヒックロジック処理を行う。

【0131】

例えば、注文情報、支払い結果又は会員情報であれば、展示処理を行う。

【0132】

また、例えば、ユーザアイデンティティ情報要求であれば、上記提供されたユーザアイデンティティ情報を取得する関連処理を行い、対応するユーザアイデンティティ情報を取得する。

【0133】

ステップ１２０５において、第２の機器のトラヒックモジュールは双方向通信モジュールを介して対端（即ち、第１の機器）に返信を送信する。

【0134】

ステップ１２０６において、第２の機器の双方向通信モジュールは、第１の機器の双方向通信モジュールに対してデータ伝送を行う。

【0135】

ステップ１２０７において、第１の機器の双方向通信モジュールはトラヒックモジュールに対端（即ち、第２の機器）の返信を受信することを通知する。

【0136】

ステップ１２０８において、第１の機器のトラヒックモジュールはトラヒックロジック処理を行う。

【0137】

これにより、本出願の実施例において、第１の機器と第２の機器とは双方向通信モジュールを介して相互に情報を送受信し、第１の機器と第２の機器はより多くの情報伝送及び交互能力を有することで、第２の機器においてユーザにより多くの支払い明細情報を展示することを実現し、ユーザが支払い過程における様々な支払い明細情報を直感的に見ることができ、ユーザの消費体験を向上させる。

【0138】

上記実施例に基づき、次に具体的なアプリケーションシーンを採用して本出願の実施例における支払い処理方法についてさらに説明し、第１の機器がレジスタであり、第２の機器が支払い機器であることを例にする。

【0139】

図１３を参照して、本出願の実施例における支払い機器とレジスタの双方向通信方式の効果模式図であり、図１３に示すように、支払い機器とレジスタは双方向通信であり、すなわち支払い機器はレジスタに情報を送受信することができ、レジスタは支払い機器に情報を送受信することもできる。例えば、支払い機器はスキャンコード又はフェイススキャニング、会員情報の展示、注文情報の展示、支払い結果の展示などをサポートすることができ、レジスタは発注、決済、会員特典取得などの機能をサポートすることができる。

【0140】

具体的には、本出願の実施例における支払い処理方法は二つの部分に分け、会員情報展示段階と支払い詳細展示段階に分けることができ、次に、それぞれこの二つの部分について説明する。

【0141】

第１部分について、会員情報展示段階である。

【0142】

図１４を参照して、本出願の実施例における会員情報の展示段階のプロセスインタフェース模式図である。図１４に示すように、具体的に、
Ｓ４１、商業者はレジスタによりフェイススキャニングをトリガして、すなわち支払い機器にユーザアイデンティティ情報要求を送信する。
Ｓ４２、この際に、支払い機器はホームページのインタフェースにあり、ホームページのインタフェースに支払いプラットフォームが表示され、例えばＷｅＣｈａｔ Ｐａｙであり、もちろん他の支払いプラットフォームをサポートし、ユーザに選択させることもでき、ここでは一種の支払いプラットフォームのみを挙げ、また「ここでスキャンコード」、「フェイススキャニング会員支払い」という機能を表示し、支払い機器はレジスタのトリガしたフェイススキャニングコマンドを受信した後、顧客のフェイススキャニングインタフェースに入る。
Ｓ４３、ユーザに「カメラに向けてください」ということを提示することができ、ユーザの顔情報を採集し、商業者のバックグラウンドサーバにより顔認識が成功した後、商業者のバックグラウンドサーバによって提供されるユーザの会員コードを取得し、該会員コードはユーザが予め商業者に登録された会員識別子であれば、会員コードをレジスタに送信する。
Ｓ４４、レジスタは会員コードに基づき、商業者のバックグラウンドサーバに会員ログインを要求し、商業者のバックグラウンドサーバにより提供される該会員コードに対応する会員情報を取得し、会員情報を支払い機器に送信する。
Ｓ４５、支払い機器は会員情報が展示されるインタフェースに入り、会員情報をユーザに展示する。

【0143】

例えば、会員情報は会員レベル、ポイント、現在会員権益などを含むことができ、例えば会員レベルは普通カード会員、銀カード会員などに分けることができ、展示された会員情報が予め配置されることができ、本出願の実施例は制限されず、このように、ユーザは自分の会員権益などを容易に知ることができる。

【0144】

第２部分について、支払い詳細展示段階である。

【0145】

図１５を参照して、本出願の実施例における支払い詳細の展示段階のプロセスインタフェース模式図であり、図１５に示すように、具体的には、
Ｓ５１、キャッシャーはレジスタによって商品情報を入力し、決済し、注文情報を生成し、レジスタは注文情報を支払い機器に送信する。
Ｓ５２、支払い機器は注文情報が展示されるインタフェースに入り、この時、ユーザは支払い機器に展示された注文情報により、注文情報が正確であるか否かを確認することができ、誤りがないことを確認した後、インタフェース上の「確認支払い」ボタンをクリックすることにより確認支払いコマンドをトリガすることができ、支払い機器が確認支払いコマンドを受信した後に該ユーザの支払いコードを生成し、且つ支払いコードをレジスタに送信する。
Ｓ５３、レジスタは支払いコードに基づき、支払いを開始し、商業者のバックグラウンドサーバ及びユーザが選択した支払いプラットフォームのバックグラウンドサーバにより、該支払いプラットフォームのバックグラウンドサーバによって対応する支払いアカウントから注文情報を支払い、且つレジスタに支払い結果を戻し、これによりレジスタが支払い結果を支払い機器に送信する。
Ｓ５４、支払い機器は支払い結果が展示されるインタフェースに入り、支払い結果を展示する。
例えば、該インタフェースで展示された支払い結果は支払い金額、支払い成功情報等を含んでもよく、取得された会員権益等を展示することもでき、具体的に制限されず、このように、ユーザは支払い情報を知ることができる。
Ｓ５５、支払いが完了し、支払い機器がホームページインタフェースに戻り、すなわち全体の購入支払い過程を完了する。

【0146】

このように、支払い機器及びレジスタの双方向通信により、ユーザは全体の購入支払い過程における明細状況を直感的に見ることができ、より良好な消費体験を取得する。

【0147】

上記の実施例に基づき、図１６を参照して、本出願の実施例において、支払い処理装置であって、主に第１の機器に適用され、具体的には、
注文情報を取得するための第１の取得モジュール１６００と、
第２の機器が前記注文情報を展示するように前記注文情報を第２の機器に送信し、前記第２の機器から送信された支払いコードを受信するための双方向通信モジュール１６１０と、
前記支払いコードに基づいて、前記支払いコードに対応する支払いアカウントから前記注文情報を支払い処理し、支払い結果を得るための処理モジュール１６２０とを含み、
前記支払いコードは、前記第２の機器によりユーザがトリガした確認支払いコマンドを受信した後、前記ユーザのユーザ支払いアイデンティティに基づいて生成されたものであり、
前記双方向通信モジュール１６１０は、さらに、前記第２の機器が前記支払い結果を展示するように、前記支払い結果を前記第２の機器に送信するために用いられる。

【0148】

好ましくは、前記注文情報を取得する前に、前記双方向通信モジュール１６１０は、さらに前記第２の機器にユーザアイデンティティ情報要求を送信し、前記第２の機器から送信されたユーザアイデンティティ情報を受信するために用いられ、そのうち、前記ユーザアイデンティティ情報は、前記第２の機器によってユーザの入力したアイデンティティ特徴に基づいて取得されたものである。

【0149】

前記支払い処理装置はさらに、前記ユーザアイデンティティ情報がユーザを登録会員ユーザとして示す場合、前記ユーザアイデンティティ情報に基づいて、前記ユーザアイデンティティ情報に対応する会員情報を取得するための第２の取得モジュール１６３０を含み、そのうち、前記会員情報はユーザ登録情報及び消費行為に関連する権益情報を示す。

【0150】

双方向通信モジュール１６１０は、さらに前記第２の機器が前記会員情報を展示するように、前記会員情報を前記第２の機器に送信するために用いられる。

【0151】

好ましくは、前記アイデンティティ特徴が顔情報である場合、前記ユーザアイデンティティ情報は、前記第２の機器により採集した顔情報に基づき、サーバによってマッチングされて取得されたもので、そのうち、前記ユーザアイデンティティ情報はユーザが登録会員ユーザであると示した場合、前記ユーザアイデンティティ情報は前記ユーザの会員コードである。

【0152】

好ましくは、前記注文情報を第２の機器に送信した後に、第１の取得モジュール１６００はさらに、双方向通信モジュール１６１０が前記第２の機器から返信された注文修正要求を受信することを確定した後、前記注文修正要求に基づいて、注文情報を更新するために用いられる。

【0153】

好ましくは、前記装置と前記第２の機器は双方向通信モジュールに基づいて互いにデータパケットを送受信する。

【0154】

好ましくは、前記装置と前記第２の機器は双方向通信モジュールに基づいて互いにデータパケットを送受信する時、双方向通信モジュール１６１０は具体的に、
前記装置が順にトラヒック層、アプリケーション層、伝送層及びリンク層を介してデータパケットを送信し、順にリンク層、伝送層、アプリケーション層及びトラヒック層を介してデータパケットを受信し、
前記第２の機器が順にトラヒック層、アプリケーション層、伝送層及びリンク層を介してデータパケットを送信し、順にリンク層、伝送層、アプリケーション層及びトラヒック層を介してデータパケットを受信するために用いられる。

【0155】

好ましくは、前記リンク層において標準的なリードインタフェース、ライトインタフェース及び制御インタフェースを定義し、データパケットが物理通信リンクを通り、前記標準的なリードインタフェース、ライトインタフェース又は制御インタフェースを介して伝送層に伝送され、且つ、データパケットが伝送層を通り、前記標準的なリードインタフェース、ライトインタフェース又は制御インタフェースを介して物理通信リンクに伝送されるように、物理通信リンクをリンク層プロトコルとして採用する。

【0156】

好ましくは、前記リンク層の物理通信リンクは、ＲＳ２３２インタフェース、ＵＳＢ、ネットワークライン、ブルートゥースのいずれかを採用する。

【0157】

好ましくは、前記伝送層においてハートビートキープアライブメカニズムを採用して前記リンク層の物理通信リンクの接続性を検出する。

【0158】

上記実施例に基づき、図１７を参照して、本出願の実施例において、他の支払い処理装置であって、主に第２の機器に適用され、具体的には、
第１の機器から送信された注文情報を受信するための双方向通信モジュール１７００と、
前記注文情報を展示するための第１の展示モジュール１７１０と、
ユーザがトリガした確認支払いコマンドを受信した後、前記ユーザのユーザ支払いアイデンティティに基づいて支払いコードを生成するための生成モジュール１７２０と、
さらに前記支払いコードを前記第１の機器に送信し、前記第１の機器から送信された支払い結果を受信するための双方向通信モジュール１７００と、
前記支払い結果を展示するための第２の展示モジュール１７３０とを含み、
前記支払い結果は、前記第１の機器によって前記支払いコードに基づき、前記支払いコードに対応する支払いアカウントから前記注文情報を支払い処理して得られるものである。

【0159】

好ましくは、第１の機器から送信された注文情報を受信する前に、前記双方向通信モジュール１７００はさらに、
前記第１の機器から送信されたユーザアイデンティティ情報要求を受信し、
前記ユーザが入力したアイデンティティ特徴に基づいてユーザアイデンティティ情報を取得し、且つ前記ユーザアイデンティティ情報を前記第１の機器に送信し、
前記第１の機器から送信された会員情報を受信するために用いられ、
前記会員情報は、前記第１の機器が、前記ユーザアイデンティティ情報によりユーザが登録会員ユーザであると示されたことを特定した場合に、前記ユーザアイデンティティ情報に基づいて取得されたものであり、前記会員情報はユーザ登録情報及び消費行為に関連する権益情報を示し、
前記支払い処理装置はさらに、前記会員情報を展示するための第３の展示モジュール１７４０を含む。

【0160】

上記の実施例に基づき、図１８を参照して、本出願の実施例において、サーバの構成模式図である。

【0161】

本出願の実施例はサーバを提供し、このサーバは、プロセッサ１８１０（ＣｅｎｔｅｒＰｒｏｃｅｓｓｉｎｇ Ｕｎｉｔ、ＣＰＵ）、メモリ１８２０、入力機器１８３０、出力機器１８４０などを含むことができ、入力機器１８３０は、キーボード、マウス、タッチパネルなどを含むことができ、出力機器１８４０は、例えば液晶ディスプレイ（Ｌｉｑｕｉｄ Ｃｒｙｓｔａｌ Ｄｉｓｐｌａｙ、ＬＣＤ）や陰極線管（Ｃａｔｈｏｄｅ Ｒａｙ Ｔｕｂｅ、ＣＲＴ）などの表示機器を含むことができる。

【0162】

メモリ１８２０は、読み取り専用メモリ（ＲＯＭ）とランダムアクセスメモリ（ＲＡＭ）を含むことができ、メモリ１８２０に記憶されたプログラムコマンドとデータをプロセッサ１８１０に提供する。本出願の実施例において、メモリ１８２０は本出願の実施例におけるいずれかの支払い処理方法のプログラムを記憶するために用いられる。

【0163】

プロセッサ１８１０は、メモリ１８２０に記憶されたプログラムコマンドをコールすることにより、取得したプログラムコマンドに従って本出願の実施例におけるいずれかの支払い処理方法のプログラムを実行するために用いられる。

【0164】

なお、上記サーバは本出願における第１のサーバ又は第２のサーバであってもいく、第１の機器又は第２の機器の要求に基づき、相応する処理操作を実行し、重複な説明を省略する。

【0165】

上記の実施例に基づき、図１９を参照して、本出願の実施例において、電子機器の構成模式図である。

【0166】

本出願の実施例は電子機器を提供し、電子機器は携帯電話、タブレットコンピュータ、コンピュータ、支払い機器などであってもよいが、これに限らない。該電子機器は、メモリ１９１０、入力モジュール１９２０、送信モジュール１９３０、受信モジュール１９４０、出力モジュール１９５０、通信モジュール１９６０、プロセッサ１９７０などを含むことができる。具体的に以下の通りである。

【0167】

メモリ１９１０は、読み取り専用メモリ（ＲＯＭ）とランダムアクセスメモリ（ＲＡＭ）を含むことができ、メモリ１９１０に記憶されたプログラムコマンドとデータをプロセッサ１９７０に提供し、電子機器のオペレーティングシステム、アプリケーションプログラム（Ａｐｐｌｉｃａｔｉｏｎ、ＡＰＰ）、モジュール、及び電子機器で使用される各種データ等を記憶することもできる。

【0168】

入力モジュール１９２０は、キーボード、マウス、タッチパネルなどを含むことができ、ユーザが入力した数字、文字情報又はタッチ操作を受信し、電子機器のユーザ設置及び機能制御に関するキー信号の入力などを発生するために用いられ、例えば、本出願の実施例において、入力モジュール１９２０はユーザの電子機器における注文情報の確認操作、入力されたアイデンティティ特徴などを受信することができる。

【0169】

送信モジュール１９３０は電子機器とサーバとの間のインタフェースを提供し、且つ他の電子機器との間のインタフェースを提供することができる。

【0170】

受信モジュール１９４０は、同様に電子機器とサーバとの間のインタフェースを提供し、且つ他の電子機器との間のインタフェースを提供する。

【0171】

出力モジュール１９５０は、例えば液晶ディスプレイ（Ｌｉｑｕｉｄ Ｃｒｙｓｔａｌ Ｄｉｓｐｌａｙ、ＬＣＤ）や陰極線管（Ｃａｔｈｏｄｅ Ｒａｙ Ｔｕｂｅ、ＣＲＴ）などの表示モジュールを含むことができ、そのうち、表示モジュールはユーザが入力した情報又はユーザに提供する情報、又は各種電子機器の操作インタフェース等を表示するために用いられる。

【0172】

通信モジュール１９６０はワイヤレスフィデリティ（ｗｉｒｅｌｅｓｓ ｆｉｄｅｌｉｔｙ、ＷｉＦｉ）モジュール、ブルートゥースモジュール、赤外線通信モジュール等を含むが、これに限らない。他の電子機器と通信する場合、該通信モジュール１９６０は本出願の実施例における双方向通信モジュールであってもよく、双方向通信フレームに基づいて相互に情報を送受信することを実現する。

【0173】

プロセッサ１９７０は電子機器の制御センターであり、各種インタフェース及び回線を利用して電子機器全体の各部を接続し、メモリ１９１０に記憶されたソフトウェアプログラム及び／又はモジュールを運行又は実行し、及びメモリ１９１０に記憶されたデータをコールすることにより、電子機器の各種機能及び処理データを実行し、電子機器全体を監視する。

【0174】

もちろん、図１９に示す電子機器の構成は、あくまで一例であり、これより多くまたは少ない部品であってもよいし、又はある部品を組み合わせたものであってもよいし、又は異なる部品によって配置されたものであってもよい。

【0175】

本出願の実施例において、上記電子機器は本出願における第１の機器又は第２の機器であってもよく、且つ本出願の実施例における提供する支払い処理方法を相応して実行してもよい。

【0176】

上記実施例に基づき、本出願の実施例において、コンピュータプログラムが記憶されたコンピュータ読み取り可能な記憶媒体を提供し、前記コンピュータプログラムがプロセッサによって実行される時に上記いずれかの方法実施例における支払い処理方法を実現する。

【0177】

上記実施例に基づき、本出願の実施例において、コマンドが含まれるコンピュータプログラムを提供し、それをコンピュータで運行させる時に、前記コンピュータに上記いずれかの方法実施例における支払い処理方法のステップを実行させる。

【0178】

商業者は、本出願の実施例が方法、システム、又はコンピュータプログラムを提供することを理解すべきである。このため、本出願は完全なハードウェア実施例、完全なソフトウェア実施例、又はソフトウェアとハードウェアを組み合わせた実施例の形式を採用することができる。そして、本出願は、一つ又は複数のコンピュータ使用可能なプログラムコードが含まれるコンピュータ使用可能な記憶媒体（磁気ディスクメモリ、ＣＤ―ＲＯＭ、光メモリ等を含むが、これに限らない）で実施したコンピュータプログラムの形式を採用することができる。

【0179】

本出願は、本出願の実施例に基づく方法、機器（システム）、及びコンピュータプログラムのフローチャート及び／又はブロック図を参照して記述されたものである。コンピュータプログラムコマンドによってフローチャート及び／又はブロック図における各フロー及び／又はブロック、並びにフローチャート及び／又はブロック図におけるフロー及び／又はブロックの組み合わせを実現することができると理解される。マシンを構成するように、これらのコンピュータプログラムコマンドを、汎用コンピュータ、専用コンピュータ、組み込みプロセッサ、または他のプログラマブルデータ処理機器のプロセッサに提供することができ、これにより、コンピュータ又は他のプログラマブルデータ処理機器のプロセッサによって実行されるコマンドにより、フローチャートの一つ又は複数のフロー及び／又はブロック図の一つ又は複数のブロックに指定される機能を実現するための装置を生成する。

【0180】

これらのコンピュータプログラムコマンドは、コンピュータ又は他のプログラマブルデータ処理機器を特定の形態で動作させることができるコンピュータ読み取り可能なメモリに記憶されてもよく、これにより、該コンピュータ読み取り可能なメモリに記憶されたコマンドは、コマンド装置が含まれる製造品を生成し、該コマンド装置はフローチャートの一つ又は複数のフロー及び／又はブロック図の一つ又は複数のブロックに指定された機能を実現する。

【0181】

これらのコンピュータプログラムコマンドはコンピュータ又は他のプログラマブルデータ処理機器にロードされてもよく、コンピュータにより実現される処理を生成するように、コンピュータ又は他のプログラマブル機器に一連の操作ステップを実行することにより、コンピュータ又は他のプログラマブル機器で実行されるコマンドは、フローチャートの一つ又は複数のフロー及び／又はブロック図の一つ又は複数のブロックに指定された機能を実現するためのステップを提供する。

【0182】

本出願の好ましい実施例が記述されたが、商業者は、基本的な創造的概念を知ると、これらの実施例に別の変更および修正を加えることができる。このため、添付の特許請求の範囲は、好ましい実施例および本出願の範囲内にあるすべての変更および修正を含むものとして解釈されることを意図している。

【0183】

明らかに、商業者は、本出願の実施例の精神および範囲から逸脱することなく、本出願の実施例に様々な変更および変形を加えることができる。このように、本出願の実施例のこれらの修正および変形が本出願の特許請求の範囲およびその同等の技術の範囲内に属する場合、本出願は、これらの修正および変形を含むことも意図する。

【符号の説明】

【0184】

１００ 第１の機器
２００ 第２の機器
３００ 第１のサーバ
４００ 第２のサーバ
１６００ 第１の取得モジュール
１６１０ 双方向通信モジュール
１６２０ 処理モジュール
１６３０ 第２の取得モジュール
１７００ 双方向通信モジュール
１７１０ 第１の展示モジュール
１７２０ 生成モジュール
１７３０ 第２の展示モジュール
１７４０ 第３の展示モジュール
１８１０ プロセッサ
１８２０ メモリ
１８３０ 入力機器
１８４０ 出力機器
１９１０ メモリ
１９２０ 入力モジュール
１９３０ 送信モジュール
１９４０ 受信モジュール
１９５０ 出力モジュール
１９６０ 通信モジュール
１９７０ プロセッサ

【図1】

【図2】

【図3】

【図4】

【図5】

【図6】

【図7】

【図8】

【図9】

【図10】

【図11】

【図12】

【図13】

【図14】

【図15】

【図16】

【図17】

【図18】

【図19】