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

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

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

(11)【特許番号】6707270

(24)【登録日】2020年5月22日

(45)【発行日】2020年6月10日

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

(51)【国際特許分類】

   G06Q 20/32 20120101AFI20200601BHJP

【ＦＩ】

   G06Q20/32 330

【請求項の数】20

【全頁数】20

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

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

(65)【公表番号】特表2020-504863(P2020-504863A)

(43)【公表日】2020年2月13日

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

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

(87)【国際公開日】20180614

【審査請求日】2019年7月12日

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

(32)【優先日】2016年12月8日

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

【早期審査対象出願】

(73)【特許権者】

【識別番号】510330264

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

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

(74)【代理人】

【識別番号】100188558

【弁理士】

【氏名又は名称】飯田 雅人

(74)【代理人】

【識別番号】100205785

【弁理士】

【氏名又は名称】▲高▼橋 史生

(72)【発明者】

【氏名】ゲ・チェン

(72)【発明者】

【氏名】リンナン・シェン

(72)【発明者】

【氏名】ヤンフイ・リュウ

(72)【発明者】

【氏名】ジエ・チー

【審査官】 岸 健司

(56)【参考文献】

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

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

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

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

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

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

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

【請求項1】

デジタルオブジェクト識別子(DOI)表示要求を受信する前に、第1のユーザの識別タイプ情報を前記識別タイプ情報に関連付けられた有効期間に基づいて事前認証するステップと、
DOI表示要求を受信するステップと、
表示要求に対応するサービスのサービスタイプを決定するステップと、
前記サービスタイプに基づいて、前記第1のユーザの基本ユーザ情報、および前記サービスタイプに対応する識別タイプ情報を決定するステップであって、前記識別タイプ情報が事前認証される、ステップと、
前記基本ユーザ情報および前記事前認証された識別タイプ情報に基づいて、前記第1のユーザのDOIを生成するステップと、
サービス処理を実行するように、前記DOI内の前記基本ユーザ情報および前記識別タイプ情報に基づいて、第2のユーザのために前記DOIを表示するステップと
を含むサービス処理のためのコンピュータ実装方法。

【請求項2】

前記識別タイプ情報を事前認証するステップが、
認証されるべき前記識別タイプ情報を受信するステップであって、前記識別タイプ情報が前記第1のユーザによって入力される、ステップと、
認証のために、検証機能を有するサーバに、認証されるべき前記識別タイプ情報を送信するステップと
を含む、請求項1に記載のコンピュータ実装方法。

【請求項3】

前記基本ユーザ情報および前記識別タイプ情報に基づいて、前記第1のユーザの前記DOIを生成するステップが、
前記識別タイプ情報のための情報フラグビットを設定するステップと、
前記基本ユーザ情報、および前記情報フラグビットを有する前記識別タイプ情報に基づいて、前記第1のユーザの前記DOIを生成するステップと
を含む、請求項1に記載のコンピュータ実装方法。

【請求項4】

前記DOI内の前記第1のユーザの前記識別タイプ情報が、
DOI情報を取得するために前記DOIを解析することと、
取得された情報として前記DOI情報内の事前に合意された識別タイプフラグビットに対応する情報を決定することと、
前記取得された情報を、前記第1のユーザの前記識別タイプ情報であると判断することと
によって決定される、請求項1に記載のコンピュータ実装方法。

【請求項5】

前記識別タイプ情報をチェックするステップと、
前記識別タイプ情報が前記サービスの前記サービスタイプと一致すると判断するステップとをさらに含む、請求項1に記載のコンピュータ実装方法。

【請求項6】

サービス処理を実行するステップが、
所定のサービス処理規則に基づいて、前記識別タイプ情報と一致するサービス処理方法を決定するステップと、
前記サービス処理方法および前記基本ユーザ情報に基づいてサービス処理を実行するステップと
を含む、請求項1に記載のコンピュータ実装方法。

【請求項7】

サービス処理を実行するステップが、
前記所定のサービス処理規則に基づいて、前記識別タイプ情報と一致する支払い割引係数を決定するステップと、
前記支払い割引係数および前記基本ユーザ情報に基づいて、支払いおよび控除を実行するステップと
を含む、請求項6に記載のコンピュータ実装方法。

【請求項8】

デジタルオブジェクト識別子(DOI)表示要求を受信する前に、第1のユーザの識別タイプ情報を前記識別タイプ情報に関連付けられた有効期間に基づいて事前認証するステップと、
DOI表示要求を受信するステップと、
表示要求に対応するサービスのサービスタイプを決定するステップと、
前記サービスタイプに基づいて、前記第1のユーザの基本ユーザ情報、および前記サービスタイプに対応する識別タイプ情報を決定するステップであって、前記識別タイプ情報が事前認証される、ステップと、
前記基本ユーザ情報および前記事前認証された識別タイプ情報に基づいて、前記第1のユーザのDOIを生成するステップと、
サービス処理を実行するように、前記DOI内の前記基本ユーザ情報および前記識別タイプ情報に基づいて、第2のユーザのために前記DOIを表示するステップと
を含むサービス処理のための動作を実行するためのコンピュータシステムによって実行可能な1つまたは複数の命令を記憶する非一時的コンピュータ可読記憶媒体。

【請求項9】

前記識別タイプ情報を事前認証するステップが、
認証されるべき前記識別タイプ情報を受信するステップであって、前記識別タイプ情報が前記第1のユーザによって入力される、ステップと、
認証のために、検証機能を有するサーバに、認証されるべき前記識別タイプ情報を送信するステップと
を含む、請求項8に記載の非一時的コンピュータ可読記憶媒体。

【請求項10】

前記基本ユーザ情報および前記識別タイプ情報に基づいて、前記第1のユーザの前記DOIを生成するステップが、
前記識別タイプ情報のための情報フラグビットを設定するステップと、
前記基本ユーザ情報、および前記情報フラグビットを有する前記識別タイプ情報に基づいて、前記第1のユーザの前記DOIを生成するステップと
を含む、請求項8に記載の非一時的コンピュータ可読記憶媒体。

【請求項11】

前記DOI内の前記第1のユーザの前記識別タイプ情報が、
DOI情報を取得するために前記DOIを解析することと、
取得された情報として前記DOI情報内の事前に合意された識別タイプフラグビットに対応する情報を決定することと、
前記取得された情報を、前記第1のユーザの前記識別タイプ情報であると判断することと
によって決定される、請求項8に記載の非一時的コンピュータ可読記憶媒体。

【請求項12】

前記識別タイプ情報をチェックするステップと、
前記識別タイプ情報が前記サービスの前記サービスタイプと一致すると判断するステップとをさらに含む、請求項8に記載の非一時的コンピュータ可読記憶媒体。

【請求項13】

サービス処理を実行するステップが、
所定のサービス処理規則に基づいて、前記識別タイプ情報と一致するサービス処理方法を決定するステップと、
前記サービス処理方法および前記基本ユーザ情報に基づいてサービス処理を実行するステップと
を含む、請求項8に記載の非一時的コンピュータ可読記憶媒体。

【請求項14】

サービス処理を実行するステップが、
前記所定のサービス処理規則に基づいて、前記識別タイプ情報と一致する支払い割引係数を決定するステップと、
前記支払い割引係数および前記基本ユーザ情報に基づいて、支払いおよび控除を実行するステップと
を含む、請求項13に記載の非一時的コンピュータ可読記憶媒体。

【請求項15】

1つまたは複数のコンピュータと
前記1つまたは複数のコンピュータに相互動作可能に結合され、1つまたは複数の命令を記憶する有形の非一時的機械可読記憶媒体を有する1つまたは複数のコンピュータメモリデバイスとを備えるサービス処理のためのコンピュータ実装システムであって、
前記1つまたは複数の命令が、前記1つまたは複数のコンピュータによって実行されると、
デジタルオブジェクト識別子(DOI)表示要求を受信する前に、第1のユーザの識別タイプ情報を前記識別タイプ情報に関連付けられた有効期間に基づいて事前認証するステップと、
DOI表示要求を受信するステップと、
表示要求に対応するサービスのサービスタイプを決定するステップと、
前記サービスタイプに基づいて、前記第1のユーザの基本ユーザ情報、および前記サービスタイプに対応する識別タイプ情報を決定するステップであって、前記識別タイプ情報が事前認証される、ステップと、
前記基本ユーザ情報および前記事前認証された識別タイプ情報に基づいて、前記第1のユーザのDOIを生成するステップと、
サービス処理を実行するように、前記DOI内の前記基本ユーザ情報および前記識別タイプ情報に基づいて、第2のユーザのために前記DOIを表示するステップと
を含む1つまたは複数の動作を実行する、コンピュータ実装システム。

【請求項16】

前記識別タイプ情報を事前認証するステップが、
認証されるべき前記識別タイプ情報を受信するステップであって、前記識別タイプ情報が前記第1のユーザによって入力される、ステップと、
認証のために、検証機能を有するサーバに、認証されるべき前記識別タイプ情報を送信するステップと
を含む、請求項15に記載のコンピュータ実装システム。

【請求項17】

前記基本ユーザ情報および前記識別タイプ情報に基づいて、前記第1のユーザの前記DOIを生成するステップが、
前記識別タイプ情報のための情報フラグビットを設定するステップと、
前記基本ユーザ情報、および前記情報フラグビットを有する前記識別タイプ情報に基づいて、前記第1のユーザの前記DOIを生成するステップと
を含む、請求項15に記載のコンピュータ実装システム。

【請求項18】

前記DOI内の前記第1のユーザの前記識別タイプ情報が、
DOI情報を取得するために前記DOIを解析することと、
取得された情報として前記DOI情報内の事前に合意された識別タイプフラグビットに対応する情報を決定することと、
前記取得された情報を、前記第1のユーザの前記識別タイプ情報であると判断することと
によって決定される、請求項15に記載のコンピュータ実装システム。

【請求項19】

前記識別タイプ情報をチェックするステップと、
前記識別タイプ情報が前記サービスの前記サービスタイプと一致すると判断するステップとをさらに含む、請求項15に記載のコンピュータ実装システム。

【請求項20】

サービス処理を実行するステップが、
所定のサービス処理規則に基づいて、前記識別タイプ情報と一致するサービス処理方法を決定するステップと、
前記サービス処理方法および前記基本ユーザ情報に基づいてサービス処理を実行するステップと
前記所定のサービス処理規則に基づいて、前記識別タイプ情報と一致する支払い割引係数を決定するステップと、
前記支払い割引係数および前記基本ユーザ情報に基づいて、支払いおよび控除を実行するステップと
を含む、請求項15に記載のコンピュータ実装システム。

【発明の詳細な説明】

【技術分野】

【0001】

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

【背景技術】

【0002】

情報技術が発展するにつれて、デジタルリソース識別技術を使用することによって生成されたバーコードなどのデジタルオブジェクト識別子(DOI)は、たとえば、コード走査支払い、連絡先追加、および追跡など、様々なサービスにおいて広く使用されている。DOIは、特定の幾何学模様(たとえば、長い帯の形や矩形)を特定の規則に従って分散させることによって形成されたコーディングパターンであり、1次元バーコード、2次元コードなどを含む。

【0003】

DOIは、リンク情報、ユーザ識別子、製品情報など複数の「見えない」情報がコード化された後にグラフィカルに表示される。したがって、ユーザは、対応するデバイスを使用して、DOIを走査および識別して、DOIに含まれる情報を取得し、それによって、対応するサービス操作を実行することができる。

【0004】

既存の技術において、DOIを使用してサービス操作を完了する方法は、通常、以下の通りである。第1のユーザは、第1の端末デバイスを使用して第1のユーザのDOI(たとえば2次元コード)を表示し、DOIは、第1のユーザのユーザIDを記憶し、第2のユーザは、第2の端末デバイス(たとえば、コード走査デバイス)を使用して第1のユーザのDOIを走査し、第1のユーザのユーザIDを取得した後、ユーザIDに基づいて対応するサービス処理を完了することができる。

【0005】

しかしながら、DOIを使用してサービスを完了させるプロセスでは、ニアフィールド通信(NFC)のような短距離通信技術とは異なり、2人のサービス当事者は、DOIを利用して情報を交換することができない。言い換えれば、DOIを使用することによって、一方向のワンタイム情報送信のみを実施できるだけである。特に、いくつかのサービスシナリオでは、サービスプロバイダは、第1のユーザのDOIに基づいて第1のユーザの基本情報(たとえば、ユーザIDまたはアカウント名)を知ることができるだけである。サービスを完了するには、サービスプロバイダは、追加のサービス操作を実行する必要がある。明らかに、この方法は、相対的に面倒である。

【発明の概要】

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

【0006】

本出願の実装形態は、DOIを使用するサービスシナリオにおいて、いくつかのサービスの実施が過度に面倒であるという既存の技術における問題を軽減するように、サービスを処理するための方法を提供する。

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

【0007】

本出願の実装形態は、DOIを使用するサービスシナリオにおいて、いくつかのサービスの実施が過度に面倒であるという既存の技術における問題を軽減するように、サービスを処理するための装置を提供する。

【0008】

本出願の実装形態は、以下の技術的解決策を使用する。

【0009】

本出願の一実装形態は、サービスを処理するための方法を提供し、方法は、デジタルオブジェクト識別子(DOI)表示要求を受信するステップと、表示要求に対応するサービスタイプを決定するステップと、決定されたサービスタイプに基づいて、第1のユーザの基本ユーザ情報、およびサービスタイプに対応する事前認証された識別タイプ情報を取得するステップと、第2のユーザが、表示されたDOIに含まれる基本ユーザ情報および識別タイプ情報に基づいてサービス処理を実行するように、基本ユーザ情報および識別タイプ情報に基づいて、第1のユーザのDOIを生成し、表示するステップとを含む。

【0010】

本出願の一実装形態は、サービスを処理するための方法をさらに提供し、方法は、第1のユーザのDOIを取得するステップであり、DOIは、第1のユーザの基本ユーザ情報、および対応するサービスタイプの事前認証された識別タイプ情報に基づいて生成される、ステップと、DOIに含まれる基本ユーザ情報、およびDOIにさらに含まれる第1のユーザの識別タイプ情報を決定するステップと、基本ユーザ情報および識別タイプ情報に基づいてサービス処理を実行するステップとを含む。

【0011】

本出願の一実装形態は、サービスを処理するための装置を提供し、装置は、デジタルオブジェクト識別子(DOI)表示要求を受信するように構成された受信モジュールと、表示要求に対応するサービスタイプを決定するように構成された決定モジュールと、決定されたサービスタイプに基づいて、第1のユーザの基本ユーザ情報、およびサービスタイプに対応する事前認証された識別タイプ情報を取得するように構成された取得モジュールと、第2のユーザが、表示されたDOIに含まれる基本ユーザ情報および識別タイプ情報に基づいてサービス処理を実行するように、基本ユーザ情報および識別タイプ情報に基づいて、第1のユーザのDOIを生成し、表示するように構成された生成モジュールとを含む。

【0012】

本出願の一実装形態は、サービスを処理するための別の装置を提供し、装置は、第1のユーザのDOIを取得するように構成された取得モジュールであり、DOIは、第1のユーザの基本ユーザ情報、および対応するサービスタイプの事前認証された識別タイプ情報に基づいて生成される、取得モジュールと、DOIに含まれる基本ユーザ情報、およびDOIにさらに含まれる第1のユーザの識別タイプ情報を決定するように構成された決定モジュールと、基本ユーザ情報および識別タイプ情報に基づいてサービス処理を実行するように構成された処理モジュールとを含む。

【0013】

本出願の実装形態において使用される、前に説明した技術的解決策のうちの少なくとも1つは、以下の有益な効果を達成することができる。

【0014】

DOIを使用してビジネスサービスを取得するシナリオでは、第1の端末デバイスがサービスによって必要とされる第1のユーザのDOIを生成するとき、サービスタイプに基づいて、第1のユーザの基本ユーザ情報、およびサービスタイプに適用可能な第1のユーザの識別タイプ情報が取得され、基本ユーザ情報および識別タイプ情報に基づいて、第1のユーザのDOIが生成される。したがって、コード走査などによって第1のユーザのDOIを取得した後、サービスプロバイダは、DOIから、DOIに含まれる要求側の識別タイプ情報を取得して、その識別タイプ情報に基づいて、対応するビジネスサービスを提供することができる。したがって、要求側は、サービスプロバイダによって提供されるビジネスサービスを全面的に取得することができる。

【0015】

既存の技術における方法と比較して、本出願の実装形態では、サービスプロバイダが、要求側の識別タイプ情報とともに、要求側のDOIを取得できるように、要求側の識別タイプ情報がDOIに追加され、これによって、サービスプロバイダによってさらに実行される対応する操作を効果的に低減または防止し、サービス提供効率をさらに向上させ、要求側によって取得されるサービスの恩恵を確実にする。

【0016】

本明細書に記載された添付の図面は、本出願のさらなる理解を提供するために使用され、本出願の一部を構成する。本出願の概略的な実装形態、および実装形態の説明は、本出願を説明するために使用されており、本出願に対する不適切な限定を構成するものではない。添付の図面において、以下の通りである。

【図面の簡単な説明】

【0017】

【図1a】本出願の一実装形態による、サービス処理プロセスの基礎となるアーキテクチャを示す概略図である。

【図1b】本出願の一実装形態による、サービス処理プロセスを示す概略図である。

【図2】本出願の一実装形態による、ユーザが表示要求を送信するインターフェースを示す概略図である。

【図3】本出願の一実施形態による、DOIに含まれる情報を示す概略図である。

【図4】本出願の一実施形態による、第2のユーザ側でのサービス処理プロセスを示す概略図である。

【図5a】本出願の一実装形態による、オンライン支払いシナリオにおけるアーキテクチャを示す概略図である。

【図5b】本出願の一実装形態による、オンラインコード走査支払いシナリオにおけるサービス手順を示す概略図である。

【図6】本出願の一実装形態による、第1のユーザ側においてサービスを処理するための装置を示す概略構造図である。

【図7】本出願の一実装形態による、第2のユーザ側においてサービスを処理するための装置を示す概略構造図である。

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

【0018】

上述したように、DOIを使用してサービスが処理されるとき、第1のユーザは、第1のデバイスを使用してDOIを表示し、第2のユーザは、第2のデバイスを使用したコード走査を介して、第1のデバイスによって表示されたDOIを取得することができる。既存の短距離送信技術における複数回の情報交換とは異なり、第2のデバイスは、コード走査プロセスで、第1のデバイスにDOIをフィードバックしない。言い換えれば、コード走査プロセスは、実際には一方向の情報送信プロセスと見なすことができる。さらに、生成されたDOIに含まれる情報は固定されており、第2のデバイスがコード走査操作を実行したときに取得された情報は、DOIに含まれる情報である。他の情報を取得するには、新しいDOIを生成する必要がある。DOI走査は、一方向のワンタイム情報送信プロセスであることがわかる。

【0019】

本出願の目的、技術的解決策、および利点をより明確にするために、以下は、本出願における特定の実装形態および対応する添付の図面を参照して、本出願の技術的解決策を明確かつ包括的に説明する。明らかに、記載された実装形態は、本出願の実装形態のすべてではなく、ほんの一部にすぎない。創造的な取り組みなしに本出願の実装形態に基づいて当業者によって取得されるすべての他の実装形態は、本出願の保護範囲内に入るものとする。

【0020】

本出願の一実装形態において、サービス処理プロセスは、図1aに示されるアーキテクチャに基づき得ることに留意する価値がある。第2のユーザが、対応する端末デバイス(すなわち、コード走査デバイスなど、第2の端末デバイス)を使用して、コード走査、スクリーンショットなどを介してDOIを取得できるように、第1のユーザは、第1のユーザの端末デバイス(すなわち、第1の端末デバイス)を使用して、第1のユーザのDOIを表示することができる。

【0021】

第1の端末デバイスは、限定はしないが、スマートフォン、スマートウォッチ、タブレットコンピュータ、またはコンピュータなど、表示画面を有する端末デバイスを含む。第2の端末デバイスは、限定はしないが、スマートフォン、スマートウォッチ、タブレットコンピュータ、コンピュータ、コードスキャナ、POS機、券売機、または自動販売機など、コード走査機能を有する端末デバイスを含み、これは、ここで本出願に対する限定を構成しない。

【0022】

図1aに示されるアーキテクチャに基づいて、本出願の一実装形態は、図1bに示されるサービス処理プロセスを提供する。このプロセスは、以下のステップを含む。

【0023】

S101.DOI表示要求を受信する。

【0024】

実際のサービスでは、ユーザは、第1の端末デバイスを操作して、DOIを表示することができる。したがって、第1の端末デバイスは、第1のユーザによって送信された表示要求を受信することができる。

【0025】

実際の動作では、第1のユーザが対応する機能インターフェースで表示要求を送信できるように、第1の端末デバイスは、DOI表示機能(ここでは限定されないが、この機能は、第1の端末デバイスのオペレーティングシステムによって提供されてもよく、または第1の端末デバイスにインストールされたアプリケーションによって提供されてもよい)を有する。

【0026】

S102.表示要求に対応するサービスタイプを決定する。

【0027】

本出願の本実装形態において、第1のユーザが異なるタイプのサービスを取得する必要がある場合、第1のユーザは、第1の端末デバイスを使用して、異なるタイプのサービスに適用可能なDOIを生成することができる。言い換えれば、ユーザによって送信された表示要求は、実際には異なるサービスタイプに関する情報を含む。したがって、表示要求を受信した後、第2のユーザの第2の端末デバイスは、さらに、表示要求に対応するサービスタイプを決定する。

【0028】

S103.決定されたサービスタイプに基づいて、第1のユーザの基本ユーザ情報、およびサービスタイプに対応する事前認証された識別タイプ情報を取得する。

【0029】

本出願の本実装形態において、基本ユーザ情報は、第1のユーザのユーザID、アカウント名などであり、識別タイプ情報は、第1のユーザの職業の種類、アカウントの種類などを表す、第1のユーザの識別関連情報であると理解され得る。

【0030】

実際の適用では、様々なサービスタイプについて、識別タイプ情報が、第1のユーザによって取得されたビジネスサービスに影響を与える可能性がある。たとえば、買い物支払い取引では、第1のユーザの会員資格は、第1のユーザが対応する割引を享受することを可能にすることができる。別の例では、コード走査を介した地下鉄チケット支払い取引では、第1のユーザの学生の識別は、第1のユーザが対応する割引を享受することを可能にすることができる。

【0031】

したがって、第1の端末デバイスは、DOI生成プロセスでは、対応するサービスタイプに基づいて、ユーザの識別タイプ情報を取得する。もちろん、第1のユーザの識別タイプ情報の妥当性を確実にするために、本出願の本実装形態では、識別タイプ情報が事前認証される。

【0032】

本出願の本実装形態において、第1のユーザの識別タイプ情報は、第1のユーザのDOIに含まれる。既存の技術と比較して、特に、DOIを使用して情報が送信されるとき、識別タイプ情報を含むDOIは、追加の情報送信操作を実行する必要なしに、第2のユーザが、一方向の一方向のコード走査送信プロセスで第1のユーザの識別タイプを取得することを可能にし得る。

【0033】

S104.第2のユーザが、表示されたDOIに含まれる基本ユーザ情報および識別タイプ情報に基づいてサービス処理を実行するように、基本ユーザ情報および識別タイプ情報に基づいて、第1のユーザのDOIを生成し、表示する。

【0034】

前のステップを参照すると、本ステップで生成されたDOIは、対応するサービスタイプに適用可能なDOIと見なすことができることがわかる。言い換えれば、第2のデバイスを使用して第1のユーザのDOIを取得した後、第2のユーザは、第1のユーザが対応するサービスを取得するように、DOIに含まれる識別タイプ情報に基づいてサービス処理を実行することができる。

【0035】

前述のステップによれば、DOIを使用してビジネスサービスを取得するシナリオでは、第1の端末デバイスがサービスによって必要とされる第1のユーザのDOIを生成するとき、サービスタイプに基づいて、第1のユーザの基本ユーザ情報、およびサービスタイプに適用可能な第1のユーザの識別タイプ情報が取得され、基本ユーザ情報および識別タイプ情報に基づいて、第1のユーザのDOIが生成される。したがって、コード走査などによって第1のユーザのDOIを取得した後、サービスプロバイダは、DOIから、DOIに含まれる要求側の識別タイプ情報を取得して、その識別タイプ情報に基づいて、対応するビジネスサービスを提供することができる。したがって、要求側は、サービスプロバイダによって提供されるビジネスサービスを全面的に取得することができる。

【0036】

記載されたプロセスでは、実際の適用では、図2は、3種類のサービスの支払いコード生成制御を示す。ユーザは、携帯電話の支払いコードインターフェースで、対応するサービスに適用可能な支払いコード制御を選択することができる。対応して、ユーザがある支払いコードをタップした後、それは表示要求を送信することと等価であり、携帯電話は、表示要求から対応するサービスタイプを決定することができる。したがって、携帯電話は、対応する識別タイプ情報を取得することができる。

【0037】

本出願の本実装形態では、識別タイプ情報は事前認証され、識別タイプ情報を事前認証することは、第1のユーザによって入力されたチェックされるべき識別タイプ情報を受信することと、認証のために、検証機能を有するサーバに、チェックされるべき識別タイプ情報を送信することとを含む。

【0038】

可能な方法では、第1のユーザは、チェックされるべき識別タイプ情報として、識別カード情報、健康保険カード情報、または学生IDカード情報などの情報を第1の端末デバイスに入力することができる。対応して、第1の端末デバイスは、ユーザによって入力されたチェックされるべき識別タイプ情報を、サービスプラットフォームサーバに送信することができ、したがって、サービスプラットフォームサーバは、チェックされるべき識別タイプ情報をチェックし、チェック結果を第1の端末デバイスにフィードバックする。もちろん、チェックされる識別タイプ情報をチェックするプロセスは、本出願に対する限定を構成しない。

【0039】

基本ユーザ情報および識別タイプ情報に基づいて、第1のユーザのDOIを生成することは、識別タイプ情報のための情報フラグビットを設定することと、基本ユーザ情報、および情報フラグビットを有する識別タイプ情報に基づいて、第1のユーザのDOIを生成することとを含む。

【0040】

たとえば、コード走査を介した地下鉄チケット支払い取引では、あるユーザが学生である場合、そのユーザによって使用される携帯電話は、そのユーザのユーザIDおよび識別タイプ情報を取得することができる。この例では、識別タイプ情報がユーザ識別「Stu」(学生を示す)であると仮定する。図3に示すように、識別タイプ情報は、2次元コードが生成される前のフラグビットとして「##」を使用する。言い換えれば、図3において、「##」の間の文字列は、識別タイプ情報に対応する文字列、すなわち「Stu」である。

【0041】

前の内容は、第1のユーザ側に基づいて説明されている。第2のユーザ側について、本出願の一実装形態は、サービスを処理するための方法をさらに提供する。図4に示すように、方法は、以下のステップを含む。

【0042】

S401.第1のユーザのDOIを取得する。

【0043】

DOIは、第1のユーザの基本ユーザ情報、および対応するサービスタイプの事前認証された識別タイプ情報に基づいて生成される。

【0044】

本出願の本実装形態において、第1のユーザのDOIは、第1のユーザによって使用される第1の端末デバイスによって表示され得る。第1の端末デバイスがDOIを表示した後、第2の端末デバイス(たとえば、コード走査デバイス)は、コード走査、スクリーンショットなどを介して第1のユーザのDOIを取得することができ、これは、本出願に対する限定を構成しない。

【0045】

S402.DOIに含まれる基本ユーザ情報、およびDOIにさらに含まれる第1のユーザの識別タイプ情報を決定する。

【0046】

本出願の本実装形態において、第1のユーザの識別タイプ情報は、第1のユーザのDOIに含まれる。既存の技術と比較して、特に、DOIを使用して情報が送信されるとき、識別タイプ情報を含むDOIは、追加の情報送信操作を実行する必要なしに、サービスプロバイダが、一方向のコード走査送信プロセスで第1のユーザの識別タイプを取得することを可能にし得る。

【0047】

もちろん、実際の動作では、第2のユーザは、第1のユーザの識別タイプ情報を取得するために、第2の端末デバイスを使用して第1のユーザのDOIを取得した後にDOIを解析することができ、これは、本出願に対する限定を構成しない。

【0048】

S403.基本ユーザ情報および識別タイプ情報に基づいてサービス処理を実行する。

【0049】

実際の適用では、第1のユーザの識別タイプ情報を取得した後、第2のユーザは、第1のユーザの識別タイプ情報に基づいてサービス処理を実行することができる。

【0050】

たとえば、バスでのコード走査支払い取引では、乗客は、携帯電話を使用して2次元コードを表示し、バス上のコード走査デバイスを使用して2次元コードを走査することができる。2次元コードを取得した後、コード走査デバイスは、乗客が学生であると判断することができる。したがって、対応する割引が行われた後、控除を完了することができる。

【0051】

前述のステップによれば、DOIを使用してビジネスサービスを取得するシナリオでは、第1のユーザは、対応する識別タイプ情報を、第1のユーザの生成されたDOIに追加する。したがって、コード走査などによって第1のユーザのDOIを取得した後、サービスプロバイダは、DOIから、DOIに含まれる要求側の識別タイプ情報を取得して、その識別タイプ情報に基づいて、対応するビジネスサービスを提供することができる。したがって、要求側は、サービスプロバイダによって提供されるビジネスサービスを全面的に取得することができる。

【0052】

既存の技術における方法と比較して、本出願の本実装形態では、サービスプロバイダが、要求側の識別タイプ情報とともに、要求側のDOIを取得できるように、要求側の識別タイプ情報がDOIに追加され、これによって、サービスプロバイダによってさらに実行される対応する操作を効果的に低減または防止し、サービス提供効率をさらに向上させ、要求側によって取得されるサービスの恩恵を確実にする。

【0053】

実際の適用では、前述のステップは、サービスプロバイダによって使用される端末デバイス(すなわち第2の端末デバイス。第2の端末デバイスは、本出願の本実装形態では、以下の内容におけるコード走査デバイスと理解することができる)によって実行できることに留意する価値がある。

【0054】

実際の適用では、コード走査を介して第1のユーザのDOIを取得した後、コード走査デバイスは、DOIを解析し、解析されたDOIに含まれる情報を取得することができる。したがって、本出願の本実装形態において、DOIに含まれる第1のユーザの識別タイプ情報を決定することは、DOI情報を取得するためにDOIを解析することと、DOI情報内の事前に合意された識別タイプフラグビット内の情報を取得することと、取得された情報を、第1のユーザの識別タイプ情報と判断することとを含む。

【0055】

一例として、2次元コードが使用される。2次元コードが復号された後、たとえばユニフォームリソースロケータ(URL)または別のコード文字列など、対応する文字列を取得することができる。本出願の本実装形態におけるコード走査支払い取引では、第1のユーザによって使用される2次元コードは、ユーザのIDを含むだけでなく、ユーザの識別タイプ情報も含む。解析により取得された文字列から識別タイプ情報を決定するために、識別タイプ情報のフラグビットを、第1のユーザと第2のユーザとの間で事前に合意することができることに留意する価値がある。

【0056】

図3に示す例を依然として使用する。コード走査デバイスは、ある第1のユーザの2次元コードを復号した後、図中の文字列を取得し、その文字列は、第1のユーザのユーザIDを含む。さらに、識別タイプ情報は、所定の合意に基づくフラグビットとして「##」を使用する。言い換えれば、図3において、「##」の間の文字列は、識別タイプ情報に対応する文字列、すなわち「Stu」である。

【0057】

記載された例は、本出願の本実装形態における識別タイプ情報解析プロセスを説明するために使用されているにすぎず、実際の適用において記載された例に示された方法に限定されないことを理解されたい。

【0058】

もちろん、本出願の本実装形態において、DOIは、対応するデコーダまたはアルゴリズム、たとえば、UTF-8コーデックまたはユニコードコーデックを使用して解析することができ、これは、本出願に対する限定を構成しない。

【0059】

実際の適用では、第1のユーザの識別情報を取得した後、コード走査デバイスは、さらに識別タイプ情報をチェックして、取得された識別タイプ情報の妥当性を判断することができる。言い換えれば、本出願の本実装形態において、識別タイプ情報に基づいてサービス処理を実行する前に、方法は、識別タイプ情報をチェックすることと、識別タイプ情報が処理されるべきサービスのタイプと一致すると判断することとをさらに含む。

【0060】

さらに、本出願の本実装形態におけるチェック中に、コード走査デバイスは、較正情報をさらに記憶することができ、較正情報は、標準識別タイプおよび異なる識別タイプの有効期間などの情報を含むことができる。したがって、コード走査デバイスは、記憶されている標準識別タイプ情報に従って、2次元コードから解析された識別タイプ情報をチェックすることができる。

【0061】

たとえば、文字列「Stu」が識別タイプ情報に対応することがわかった後、コード走査デバイスは、記憶されている標準識別タイプに基づいて、文字列「Stu」が標準識別タイプと一致するかどうかを決定し、コード走査デバイスはさらに、第1のユーザの年齢が「学生」の識別を満たすかどうかを判断することができる。

【0062】

同様に、本例は、記載されたチェックプロセスを説明することを意図しているにすぎず、本出願に対する限定として解釈されないものとする。実際の適用では、別のチェック方法を使用できる。簡単のために、ここでは詳細は省略する。

【0063】

チェックが成功した後、第1のユーザの識別タイプ情報に基づいて、対応するサービス操作を実行することができる。すなわち、識別タイプ情報に基づいてサービス処理を実行することは、所定のサービス処理規則に従って、識別タイプ情報と一致するサービス処理方法を決定することと、決定されたサービス処理方法に基づいてサービス処理を実行することとを含む。

【0064】

本出願の本実装形態において、サービス処理規則は、異なるサービスシナリオに適用可能な処理規則を含むことができる。たとえば、ショッピングプロセスにおけるコード走査支払い取引では、支払い規則は、消費者の会員タイプに基づいて対応する割引を提供している。代替的に、コード走査を介した地下鉄チケット支払い取引では、支払い規則は、学生、高齢者、または軍人など、異なる識別の乗客についての支払い低減規則である。もちろん、本出願の本実装形態では、サービス処理規則は限定されない。

【0065】

したがって、記載されたプロセスを使用して、記載されたサービス処理規則に従って取得された第1のユーザの識別タイプ情報を参照して、対応するサービス処理を実行して、第1のユーザのためのビジネスサービスを提供することができる。

【0066】

特に、コード走査支払い取引では、DOIは、2次元支払いコードを含む。基本ユーザ情報および識別タイプ情報に基づいてサービス処理を実行することは、所定のサービス処理規則に従って、識別タイプ情報と一致する支払い割引係数を決定することと、決定された支払い割引係数および基本ユーザ情報に基づいて、支払いおよび控除を実行することとを含む。

【0067】

ここで、記載された内容、および図1aに示されたアーキテクチャから、本出願の本実装形態におけるサービスを処理するための方法は、オフラインのシナリオに適用可能であることがわかることに留意する価値がある。言い換えれば、第1の端末デバイスと第2の端末デバイスの両方をオフライン状態にすることができ、それによって、コード走査支払いの適用性を向上させることができる。

【0068】

もちろん、本出願におけるサービスを処理するための方法は、オンラインシナリオにも適用可能である。このシナリオでは、アーキテクチャを図5aに示すことができる。サービス対話を実行する必要がある2人の当事者は、オンラインサービスプラットフォーム(たとえば、ウェブサイト)を使用することによって、対応するサービス操作を完了することができることが図5aからわかる。第1のユーザ(すなわち要求側)と第2のユーザ(プロバイダ)の両方がサービスプラットフォームにおいて対応するアカウントを登録するので、サービスプラットフォームは、サービスプラットフォーム上の各ユーザの標準識別タイプ情報フォーマットを一様に指定できる。さらに、サービスプラットフォームは、ユーザの個人情報および過去のサービス情報に基づいて、ユーザの識別タイプ情報を決定することができる。たとえば、サービスプラットフォームは、ユーザによって提供された識別情報に基づくレビューを介して、ユーザが学生であると判断することができる。別の例では、サービスプラットフォームは、ユーザの過去のサービスデータに基づいて、ユーザのアカウントタイプがシニア会員であると判断する。

【0069】

図5aに示されるオンラインシナリオに基づいて、図5bは、2人のサービス当事者による支払いサービスを完了するプロセスを示すことができる。このプロセスは、以下のステップを含む。

【0070】

S501.端末デバイスは、要求側の2次元支払いコードを生成し、表示する。

【0071】

S502.コード走査デバイスは、端末によって表示された2次元支払いコードを走査して、2次元支払いコード画像を取得する。

【0072】

S503.コード走査デバイスは、取得された2次元支払いコード画像を解析して、要求側の識別タイプ情報を含む解析結果を取得する。

【0073】

S504.コード走査デバイスは、解析結果を、チェックのためにサービスプラットフォームサーバに送信する。

【0074】

S505.サービスプラットフォームサーバは、解析結果をチェックし、チェック成功結果をフィードバックする。

【0075】

S506.チェック結果を受信し、チェックが成功したと判断した後、コード走査デバイスは、要求側の識別タイプ情報に基づいて控除を実行する。

【0076】

上記の本出願の実装形態では、サービスを処理するための方法が提供される。同じ考えに基づいて、本出願の一実装形態は、サービスを処理するための装置をさらに提供する。

【0077】

図6に示すように、装置は、デジタルオブジェクト識別子(DOI)表示要求を受信するように構成された受信モジュール601と、表示要求に対応するサービスタイプを決定するように構成された決定モジュール602と、決定されたサービスタイプに基づいて、第1のユーザの基本ユーザ情報、およびサービスタイプに対応する事前認証された識別タイプ情報を取得するように構成された取得モジュール603と、第2のユーザが、表示されたDOIに含まれる基本ユーザ情報および識別タイプ情報に基づいてサービス処理を実行するように、基本ユーザ情報および識別タイプ情報に基づいて、第1のユーザのDOIを生成し、表示するように構成された生成モジュール604とを含む。

【0078】

装置は、第1のユーザによって入力されたチェックされるべき識別タイプ情報を受信し、認証のために、検証機能を有するサーバに、チェックされるべき識別タイプ情報を送信するように構成された検証モジュール605をさらに含む。

【0079】

生成モジュール604は、識別タイプ情報について情報フラグビットを設定し、基本ユーザ情報、および情報フラグビットを有する識別タイプ情報に基づいて、第1のユーザのDOIを生成する。

【0080】

第2のユーザ側で、本出願の一実装形態は、サービスを処理するための装置をさらに提供する。図7に示すように、装置は、第1のユーザのDOIを取得するように構成された取得モジュール701であり、DOIは、第1のユーザの基本ユーザ情報、および対応するサービスタイプの事前認証された識別タイプ情報に基づいて生成される、取得モジュール701と、DOIに含まれる基本ユーザ情報、およびDOIにさらに含まれる第1のユーザの識別タイプ情報を決定するように構成された決定モジュール702と、基本ユーザ情報および識別タイプ情報に基づいてサービス処理を実行するように構成された処理モジュール703とを含む。

【0081】

さらに、決定モジュール702は、DOI情報を取得するためにDOIを解析し、DOI情報内の事前に合意された識別タイプフラグビットに対応する情報を取得し、取得された情報を、第1のユーザの識別タイプ情報と判断する。

【0082】

装置は、識別タイプ情報をチェックし、識別タイプ情報が処理されるべきサービスのタイプと一致すると判断するように構成された検証モジュール704をさらに含む。

【0083】

処理モジュール703は、所定のサービス処理規則に従って、識別タイプ情報と一致するサービス処理方法を決定し、決定されたサービス処理方法および基本ユーザ情報に基づいてサービス処理を実行する。

【0084】

コード走査支払い取引では、DOIは、2次元支払いコードを含み、処理モジュール703は、所定のサービス処理規則に従って、識別タイプ情報と一致する支払い割引係数を決定し、決定された支払い割引係数および基本ユーザ情報に基づいて、支払いおよび控除を実行する。

【0085】

1990年代には、技術の改善を、ハードウェアの改善(たとえば、ダイオード、トランジスタ、またはスイッチなどの回路構造の改善)と、ソフトウェアの改善(方法手順の改善)との間で明確に区別することができていた。しかしながら、技術が発展するにつれて、多くの方法手順の改善は、ハードウェア回路構造の直接的な改善と考えることができる。設計者はほとんどすべて、対応するハードウェア回路構造を得るために、改良された方法手順をハードウェア回路にプログラムする。したがって、ハードウェアエンティティモジュールを使用して方法手順の改善を実現することはできないとは言えない。たとえば、プログラマブル論理デバイス(PLD)(たとえばフィールドプログラマブルゲートアレイ(FPGA))は、そのような集積回路である。プログラマブル論理デバイスの論理機能は、ユーザによって実行されるコンポーネントプログラミングによって決定される。設計者は、専用の集積回路チップを設計し、製造するためにチップ製造業者を必要することなく、デジタルシステムを単一のPLDに「統合する」ために任意のプログラミングを実行する。さらに、現在、集積回路チップを手動で製造する代わりに、プログラミングは大部分、「ロジックコンパイラ」ソフトウェアによって実施されており、これは、プログラム開発中に使用されるソフトウェアコンパイラに類似している。コンパイル前のオリジナルコードは、ハードウェア記述言語(HDL)と呼ばれる特定のプログラミング言語でも書かれており、ABEL(Advanced Boolean Expression Language)、AHDL(Alteraハードウェア記述言語)、Confluence、CUPL(Cornell大学プログラミング言語)、HDCal、JHDL(Javaハードウェア記述言語)、Lava、Lola、MyHDL、PALASM、およびRHDL(Rubyハードウェア記述言語)など、複数の種類のHDLがある。現在、VHDL(超高速集積回路ハードウェア記述言語)およびVerilogが最も一般的に使用されている。当業者はまた、方法手順を論理的にプログラムし、前のハードウェア記述言語を使用して集積回路にプログラムするだけでよいので、論理的方法手順を実施するハードウェア回路を容易に得ることができることも理解されたい。

【0086】

コントローラは、任意の適切な方法を使用することによって実装され得る。たとえば、コントローラは、マイクロプロセッサ、またはプロセッサ、またはコンピュータ可読媒体、論理ゲート、スイッチ、特定用途向け集積回路(ASIC)、プログラマブル論理コントローラ、またはマイクロプロセッサもしくはプロセッサによって実行することができる(ソフトウェアまたはファームウェアなどの)コンピュータ可読プログラムコードを記憶する組込みマイクロプロセッサであり得る。コントローラの例には、限定はしないが、以下のマイクロプロセッサ、ARC 625D、Atmel AT91SAM、Microchip PIC18F26K20、およびSilicone Labs C8051F320がある。メモリコントローラは、メモリの制御論理の一部として実装することもできる。当業者はまた、純粋なコンピュータ可読プログラムコードを使用してコントローラを実装できること、およびコントローラが論理ゲート、スイッチ、特定用途向け集積回路、プログラマブル論理コントローラ、および組込みマイクロコントローラなどの形態で同じ機能をさらに実装できるように、方法のステップを論理的にプログラムできることも知っている。したがって、コントローラは、ハードウェア構成要素と見なすことができ、コントローラ内に含まれ、様々な機能を実施するように構成された装置もハードウェア構成要素内の構造と見なすことができる。代替的に、様々な機能を実装するように構成された装置は、方法を実装するためのソフトウェアモジュールとハードウェアコンポーネント内の構造の両方と見なすことができる。

【0087】

記載された実装形態において記載されたシステム、装置、モジュール、またはユニットは、コンピュータチップまたはエンティティによって実装することができ、あるいは特定の機能を有する製品によって実装することができる。典型的な実装デバイスは、コンピュータである。コンピュータは、たとえば、パーソナルコンピュータ、ラップトップコンピュータ、携帯電話、カメラ付き携帯電話、スマートフォン、パーソナルデジタルアシスタント、メディアプレーヤ、ナビゲーションデバイス、電子メールデバイス、ゲーム機、タブレットコンピュータ、ウェアラブルデバイス、またはこれらのデバイスうちの任意のものの組合せとすることができる。

【0088】

説明しやすいように、記載された装置は、機能を様々なユニットに分割することによって説明される。もちろん、本出願が実装されるとき、ユニットの機能は、1つまたは複数のソフトウェアおよび/またはハードウェアにおいて実装され得る。

【0089】

当業者であれば、本開示の実装形態が、方法、システム、またはコンピュータプログラム製品として提供され得ることを理解されたい。したがって、本開示は、ハードウェアのみの実装、ソフトウェアのみの実装、またはソフトウェアとハードウェアの組合せを用いた実装の形を使用することができる。さらに、本開示は、コンピュータ使用可能プログラムコードを含む1つまたは複数のコンピュータ使用可能記憶媒体(限定はしないが、ディスクメモリ、CD-ROM、光メモリを含む)上に実装されるコンピュータプログラム製品の形態を使用することができる。

【0090】

本開示は、本開示の実装形態による方法、デバイス(システム)、およびコンピュータプログラム製品のフローチャートおよび/またはブロック図を参照して説明される。フローチャートおよび/またはブロック図内の各プロセスおよび/または各ブロック、ならびにフローチャートおよび/またはブロック図内のプロセスおよび/またはブロックの組合せを実装するためにコンピュータプログラム命令を使用できることを理解されたい。これらのコンピュータプログラム命令は、汎用コンピュータ、専用コンピュータ、組込みプロセッサ、または任意の他のプログラム可能なデータ処理デバイスのプロセッサに提供されて機械を生成することができ、したがって、コンピュータまたは任意の他のプログラマブルデータ処理デバイスのプロセッサによって実行される命令は、フローチャート内の1つまたは複数のプロセスまたはブロック図内の1つまたは複数のブロックにおいて特定の機能を実施するための装置を生成する。

【0091】

コンピュータ可読メモリに記憶された命令が命令装置を含むアーティファクトを生成するように、特定の方法で動作するよう、コンピュータまたは任意の他のプログラム可能データ処理デバイスに命令することができるこれらのコンピュータプログラム命令を、コンピュータ可読メモリに記憶することができる。命令装置は、フローチャート内の1つまたは複数のプロセス内および/またはブロック図内の1つまたは複数のブロック内で特定の機能を実施する。

【0092】

これらのコンピュータプログラム命令は、コンピュータまたは別のプログラム可能データ処理デバイスにロードすることができ、したがって、コンピュータまたは別のプログラム可能デバイス上で一連の動作およびステップが実行され、それによってコンピュータ実装処理が生成される。したがって、コンピュータまたは別のプログラム可能デバイス上で実行される命令は、フローチャート中の1つまたは複数のプロセスまたはブロック図中の1つまたは複数のブロックにおいて特定の機能を実施するためのステップを提供する。

【0093】

典型的な構成では、コンピューティングデバイスは、1つまたは複数のプロセッサ(CPU)、1つまたは複数の入出力インターフェース、1つまたは複数のネットワークインターフェース、および1つまたは複数のメモリを含む。

【0094】

メモリは、コンピュータ可読媒体内の非永続的メモリ、ランダムアクセスメモリ(RAM)、および/または不揮発性メモリ、たとえば読取り専用メモリ(ROM)またはフラッシュメモリ(フラッシュRAM)を含むことができる。

【0095】

コンピュータ可読媒体は、任意の方法または技術を使用することによって情報記憶を実装することができる持続的、非持続的、移動可能、および移動不能の媒体を含む。情報は、コンピュータ可読命令、データ構造、プログラムモジュール、または他のデータとすることができる。コンピュータ記憶媒体は、限定はしないが、位相変化ランダムアクセスメモリ(PRAM)、スタティックランダムアクセスメモリ(SRAM)、ダイナミックランダムアクセスメモリ(DRAM)、別のタイプのランダムアクセスメモリ(RAM)、読取り専用メモリ(ROM)、電気的消去可能プログラマブル読取り専用メモリ(EEPROM)、フラッシュメモリまたは別のメモリ技術、コンパクトディスク読取り専用メモリ(CD-ROM)、デジタル多用途ディスク(DVD)または別の光学記憶デバイス、磁気テープ、磁気ディスクストレージ、別の磁気記憶デバイス、あるいはコンピューティングデバイスによってアクセスされ得る情報を記憶するために使用され得る任意の他の非送信媒体を含む。本明細書の定義に基づいて、コンピュータ可読媒体は、一時的なコンピュータ可読媒体(一時的媒体)、たとえば、変調されたデータ信号およびキャリアを含まない。

【0096】

さらに、用語「含む」、「含む」、またはそれらの任意の他の変形は、非排他的な包含をカバーするものとし、したがって、要素のリストを含むプロセス、方法、商品、またはデバイスは、それらの要素を含むだけでなく、明示的に挙げられていない他の要素をも含み、あるいはそのようなプロセス、方法、商品、またはデバイスに固有の要素をさらに含むことにさらに留意する価値がある。それ以上の制約がなければ、「〜を含む」で始まる要素は、要素を含むプロセス、方法、商品、またはデバイスにおける追加の同一要素の存在を排除しない。

【0097】

当業者であれば、本出願の実装形態が、方法、システム、またはコンピュータプログラム製品として提供され得ることを理解されたい。したがって、本出願は、ハードウェアのみの実装形態、ソフトウェアのみの実装形態、またはソフトウェアとハードウェアの組合せを用いた実装形態の形を使用することができる。さらに、本出願は、コンピュータ使用可能プログラムコードを含む1つまたは複数のコンピュータ使用可能記憶媒体(限定はしないが、ディスクメモリ、CD-ROM、光メモリなどを含む)上に実装されるコンピュータプログラム製品の形態を使用することができる。

【0098】

本出願は、たとえばプログラムモジュールなど、コンピュータによって実行されるコンピュータ実行可能命令の一般的な文脈で説明することができる。一般に、プログラムモジュールは、特定のタスクを実行するため、または特定の抽象データ型を実装するためのルーチン、プログラム、オブジェクト、コンポーネント、データ構造などを含む。本出願は、分散コンピューティング環境においても実施することができる。分散コンピューティング環境では、通信ネットワークを介して接続された遠隔処理デバイスによってタスクが実行される。分散コンピューティング環境では、プログラムモジュールは、記憶デバイスを含むローカルとリモートの両方のコンピュータ記憶媒体に配置することができる。

【0099】

本明細書における実装形態はすべて漸進的な方法で記載されている。実装形態の同一または類似の部分については、実装形態を参照されたい。各実装形態は、他の実装形態との違いに焦点を当てている。特に、システムの実装形態は方法の実装形態と基本的に似ているため、簡単に説明されている。関連部分については、方法の実装形態の部分的な説明を参照されたい。

【0100】

前述の説明は、単に本出願の実装形態にすぎず、本出願を制限するためのものではない。当業者は、本出願に対して様々な修正および変更を加えることができる。本出願の意図および原理内で行われる任意の修正、等価の置換、改良などは、本出願の特許請求の範囲内に含まれるものとする。

【符号の説明】

【0101】

601 受信モジュール
602 決定モジュール
603 取得モジュール
604 生成モジュール
605 検証モジュール
701 取得モジュール
702 決定モジュール
703 処理モジュール
704 検証モジュール

【図1a】

【図1b】

【図2】

【図3】

【図4】

【図5a】

【図5b】

【図6】

【図7】