EP3400695A1 - Système, procédé, et appareil de transmission de données - Google Patents

Système, procédé, et appareil de transmission de données

Info

Publication number
EP3400695A1
EP3400695A1 EP17705315.4A EP17705315A EP3400695A1 EP 3400695 A1 EP3400695 A1 EP 3400695A1 EP 17705315 A EP17705315 A EP 17705315A EP 3400695 A1 EP3400695 A1 EP 3400695A1
Authority
EP
European Patent Office
Prior art keywords
user
code
mobile device
data
transaction
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Withdrawn
Application number
EP17705315.4A
Other languages
German (de)
English (en)
Inventor
Louis-James DAVIS
Andrew GIBLIN
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Vst Enterprises Ltd
Original Assignee
Vst Enterprises Ltd
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Vst Enterprises Ltd filed Critical Vst Enterprises Ltd
Publication of EP3400695A1 publication Critical patent/EP3400695A1/fr
Withdrawn legal-status Critical Current

Links

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00—Payment architectures, schemes or protocols
    • G06Q20/30—Payment architectures, schemes or protocols characterised by the use of specific devices or networks
    • G06Q20/32—Payment architectures, schemes or protocols characterised by the use of specific devices or networks using wireless devices
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00—Payment architectures, schemes or protocols
    • G06Q20/08—Payment architectures
    • G06Q20/085—Payment architectures involving remote charge determination or related payment systems
    • G06Q20/0855—Payment architectures involving remote charge determination or related payment systems involving a third party
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00—Payment architectures, schemes or protocols
    • G06Q20/30—Payment architectures, schemes or protocols characterised by the use of specific devices or networks
    • G06Q20/32—Payment architectures, schemes or protocols characterised by the use of specific devices or networks using wireless devices
    • G06Q20/327—Short range or proximity payments by means of M-devices
    • G06Q20/3274—Short range or proximity payments by means of M-devices using a pictured code, e.g. barcode or QR-code, being displayed on the M-device
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00—Payment architectures, schemes or protocols
    • G06Q20/38—Payment protocols; Details thereof
    • G06Q20/385—Payment protocols; Details thereof using an alias or single-use codes
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/08—Network architectures or network communication protocols for network security for authentication of entities
    • H04L63/083—Network architectures or network communication protocols for network security for authentication of entities using passwords
    • H04L63/0838—Network architectures or network communication protocols for network security for authentication of entities using passwords using one-time-passwords
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W12/00—Security arrangements; Authentication; Protecting privacy or anonymity
    • H04W12/06—Authentication
    • H04W12/068—Authentication using credential vaults, e.g. password manager applications or one time password [OTP] applications

Definitions

  • the present invention relates to a system and method for transmitting and receiving data over a network.
  • a method and system can, for example, in one embodiment, be used to enable parties to undertake transactions. Examples of the nature of the transactions concerned include a retail transaction in which a purchaser makes a payment to a retailer.
  • GB2446706 describes a method of information exchange which can be used in the accessing of goods or services.
  • a mobile device obtains an image of a visual symbol, e.g. by using its camera to photograph a two-dimensional barcode.
  • the visual symbol is parsed into a code, and a network address of a first server that corresponds to the code is obtained.
  • the address is modified to include an identification of the mobile device, such as the IMEI number, and a request preferably in the form of a URL is sent to the modified network address.
  • the server receives the request and obtains account details such as a user name that correspond with the identification of the mobile device.
  • the present application discloses, inter alia, alternative methods of information transmission and retrieval.
  • a one-time code is generated which is stored against a user's ID value by a trusted administrator; the one-time code is rendered into an indicium which the user is then able to offer to a counterparty in a transaction as a token; the counterparty, upon receiving confirmation of the authenticity of the token from the trusted administrator then, in reliance upon the trusted administrator's confirmation, completes the transaction with the user.
  • the trusted administrator may settle the transaction by receiving details of the transaction, including the one-time code and some further data from the counterparty, using the one-time code to establish the identification of the user, and whether the user has authorised the trusted administrator to conclude the transaction on the user's behalf, and upon confirmation that the user has thus authorised the trusted administrator, sending a transaction data package to a third party which instructs the third party to perform a transaction settlement act.
  • the third party is the user's bank and the settlement act is payment of funds from the user's account to the counterparty.
  • Figs. 1 to 3 illustrate generation of a one-time code and administration of such codes
  • Figs 4 to 8 each illustrate different stages in a scenario according to an embodiment of the present invention
  • Fig.9 is a drawing illustrating various hardware and computing entities involved in the scenario of Figs. 4 to 8.
  • Fig.10 is a flow diagram of the scenario illustrated in Figs. 4 to 8.
  • DETAILED EMBODIMENTS
  • one element or 'tool' of relevance to embodiments of the present invention is a code format which provides sufficient address space to enable what amounts to, for all practical purposes, an unlimited number of different codes to be generated.
  • One embodiment of such a code format is based upon a 14 character hexadecimal number H n . This provides an address space with around 2x10 18 different numbers. Codes are generated using a random number generator 500. Once the number H n has been generated, it is then encoded into an indicium by a processor 502 running a dedicated algorithm. Encoding the number H n into an indicium serves a number of purposes.
  • the encoding algorithm performs an encryption function, since the value H n of the number cannot be parsed from the indicium without the algorithm.
  • encoding a number into an indicium then provides a means by which the number may more readily and robustly be transferred between parties and transmitted across networks.
  • the indicium may take any form that enables both encryption and representation of a code number of the requisite format.
  • the indicium may therefore be a light pattern (varying, over time, for example), a sound sequence or a visual symbol.
  • a visual symbol V is adopted in which the presence of black marks upon the white pathways represent the values of the 14 characters in the code H n .
  • a code number H n and its corresponding visual symbol V is by a suitable software application A running on a mobile device, such as, for example, a laptop computer, tablet computer, PDA or mobile telephone with appropriate processing capability.
  • the mobile device is a mobile phone 12 of a user 10.
  • the application running on the mobile phone Upon generation of the code and its associated visual symbol V, the application running on the mobile phone additionally retrieves a UserlD.
  • the UserlD (as the name suggests) is a stable identifier for the User 10 which is relied upon by an trusted administrator of the code, whose role will be discussed subsequently.
  • the application running on the phone can send a request to the server 520 of the trusted administrator to generate a code and to send that code back to the phone of the User.
  • the symbol V is then translated into packet data (for example in the form of a visual image bitmap) together with the UserlD and encrypted, typically via Secure Sockets Layer (SSL) and transmitted to an Administration server 520, at the URL value http://www.administrationoftrustedcode.fake (used in the illustrated scenario for exemplification purposes) operated by the trusted administrator.
  • the URL of administration server 520 is stored within the application running on the phone 12 so that, upon generation of the code H n and transformation into the symbol V, both the digitised symbol V and the UserlD are then transmitted to it in encrypted form.
  • one role of the trusted administrator is to run an administration server 520 which operates a database comprising a number of inter-relational data tables, some examples of which are illustrated in schematic form in Fig. 3. These tables will be usable by the trusted administrator in providing authorisations for transactions between a user and a counterparty.
  • a first group of tables T relate to values which are stored against UserlD. These include table T1 stores code values H n against UserlD (e.g. XYZXYZ). A second table T2 stores UserlD values against bank account details.
  • a third table T3 is illustrated and demonstrates that other user- related values may be stored, such as club memberships (e.g. loyalty cards or the like).
  • a second group of tables, S all relate to data values which point to a single UserlD in some way. The purpose of these tables will become apparent subsequently.
  • table S1 maps the origin of HTTP GET requests to certain Counterparty's identification ('CParty');
  • table S2 maps Cparty to Data types such as User bank details.
  • the phone 12 has a number of capabilities beyond the ability to make and receive calls via the GPRS mobile telephony system. These additional capabilities include: a camera to capture images, processing and memory capable of running applications programs which may typically perform cryptographic calculations, and memory sufficient to store captured images.
  • the user 10 wishes to enter into a transaction with a counterparty; in the present example by making a purchase from a retailer 20.
  • the user 10 has selected an item 14 carrying an indicium which encodes data relating to the item.
  • the indicium is a visual symbol in the form of a standard bar code 16 but other indicia, such as RFI Ds and other visual symbols may equally be employed.
  • the user 10 presents the item 14 to the retailer 20 and, in the usual manner, the retailer scans the bar code 16 using an Electronic Point of Sale (EPOS) system 22. This results in the bar code 16 being parsed into a character string 24 which is then sent to a database 30 as a query. That query returns a value 32 which is the price of the item which is then displayed by the EPOS system.
  • EPOS Electronic Point of Sale
  • the user 10 then uses the application running on the phone to obtain a one time code H n .
  • a code may be obtained, but, in each instance, in order to initiate this process, the payment app first requires the user to authenticate their identity. This therefore avoids the possibility of a fraudulent transaction by a third party who has possession of the phone.
  • Authentication is, in one preferred embodiment, biometrically performed, by reference to facial recognition, voice, retinal scan or, thumb print scan. Alternatively, authentication can be made by the use of a PIN, which is preferably six or more characters long.
  • authentication is made by the scan of a thumb print 40. The scanned thumb print 40 is then compared with benchmark print or scan held, in encrypted form within the phone 12, and which was created by the user 10 when the payment app was first initialised. Authentication of the person making the transaction therefore takes place within the phone.
  • the payment app then contacts the server 520 of the trusted administrator to request a one-time code.
  • the request for such a code is an encrypted data package includes the following data elements:
  • ⁇ UserlD ⁇ ⁇ TimeStamp ⁇ ⁇ LocationStamp ⁇ ⁇ CodeRequest ⁇ UserlD is a string of characters which identifies the user to the Trusted Administrator.
  • the TimeStamp is simply the time, as established from the user's mobile phone network signal 44, at which the code was generated, typically in the format DDMMYYYYHH:MM:SS/TZ, where TZ is the Time Zone which the user and bank have agreed upon.
  • the TimeStamp may contain a further hash string which authenticates the network time as genuine, since this may assist in combating fraud.
  • the LocationStamp can typically be established with reference to the mobile phone network (and therefore referencing a mobile phone cell) or, as in the present embodiment, GPS coordinates 46.
  • some external reference for example a beacon located in the retailer premises having a unique retailer ID and branch ID
  • a beacon located in the retailer premises having a unique retailer ID and branch ID can be used to establish location.
  • the CodeRequest is simply a request for a code to be sent
  • the server then generates a unique one-time code number H n .
  • this is rendered into the form of an indicium, in the present embodiment a visual indicium has the form of the symbol V.
  • the rendering takes place at the server prior to transmission so that the server 520 transmits a digitised packaged of data which describes the visual symbol; alternatively the rendering can take place at the phone based on the data sent by the server.
  • the trusted administrator server 520 sends back a plurality of One-Time Codes H n which are then stored in the phone. This can be useful for circumstances where the User is unable to gain access to the data network but may still wish to make a payment.
  • the software application running on the phone generates a code which is then sent, in enctrypted form, to the trusted administrator server 520 where a check is made to see if there are any collisions.
  • This is not a preferred embodiment but is a viable alternative.
  • the trusted administrator then stores the OneTimeCode against the UserlD in table T1 .
  • the Retailer 20 trusts the trusted administrator. Accordingly, to settle payment for the transaction between the retailer and the user, the user displays the symbol V which renders the OneTimeCode to the retailer. The retailer then scans that code and sends that OneTimeCode to the trusted administrator, together with further data, as part of a package of data TransactionDetails, which includes the following elements:
  • the further data therefore comprises:
  • PaymentSum is simply the amount that the retailer wishes to obtain from the User
  • PaymentDestination is details of the retailer's bank account and sort code
  • Transaction! D is an identifier generated by the retailer which enables the retailer then to link payments received from the bank to transactions made with customers and thereby allocate receipt of a sum to the relevant customer transaction
  • the TransactionDetails data package once received at the Administration Server 520, is decrypted and parsed by the trusted administrator.
  • the trusted administrator searches Table T1 for the OneTimeCode included with the TransactionDetails and the UserlD held in table T1 against that value. Having done so, it is then able to locate two further values with reference to the UserlD. The first of these is to search one or more of the other tables T2 to T n for values held against the UserlD value which may be required in order for the transaction to proceed (such as the bank details stored in respect of the UserlD).
  • the trusted administrator addresses the relevant set of tables S, all of which relate to the UserlD value.
  • Each of those tables maps a particular counterparty, thus Cparty (A, or B and so on) to a URL from which a request enclosing a TransactionDetails data package may come. This is set out in table S1.
  • table S2 is searched for the value of CParty returned from table S1 , in order to retrieve from that table the values held against CParty which indicate the nature of the data which the trusted administrator may use in a transaction with CParty.
  • S2 indicates that, in transactions with Cparty A, the user's bank details may be used - which of course is required in this instance in order to settle the transaction. Those bank details are held by the trusted administrator against the value UserlD in table T2.
  • the trusted administrator then generates a transaction data package, here known as the ⁇ PaymentDetails ⁇ data package.
  • This package bundles the further data which comprises the ⁇ PaymentSum ⁇ ⁇ PaymentDestination ⁇ ⁇ transaction ID ⁇ data received from the retailer together with an ⁇ Authorisation ID ⁇ data element, freshly generated by the trusted administrator.
  • the ⁇ Authorisation ID ⁇ data element is trusted and relied upon by banks as a basis for acting upon transaction requests received from the trusted administrator.
  • the ⁇ PaymentDetails ⁇ data package is then encrypted and sent to the User bank 60.
  • the user Bank 60 uses the decrypted and parsed data elements within the transaction data package ⁇ PaymentDetails ⁇ first of all, to authenticate the transaction request as genuine on the basis of an AuthorisationID having the requisite form. Once authenticated, the user Bank 60 then sends the payment to the Retailer Bank 80 in accordance with the ⁇ PaymentSum ⁇ ⁇ PaymentDestination ⁇ ⁇ transaction ID ⁇ data elements included within the ⁇ PaymentDetails ⁇ data package. That payment is bundled with the ⁇ Transaction! D ⁇ in order that the retailer 20 can then identify the payment and allocated receipt of it to the relevant customer transaction.
  • the phone 12 of the user 10 is connected to a mobile phone network via a one or more cellular network radio masts 100 to enable the making and receiving of calls and SMS messages, as well, additionally, to receive digitally-encoded time data.
  • the mobile phone network is connected to a gateway server 1 10 which interfaces with the Internet to enable the transmission of data to and receipt of data from other entities within the Internet.
  • the GPS capability of the phone 12 when activated, it receives signals from GPS satellites 120 which enable it to establish its coordinates.
  • the retailer 20 operates a server 200 which records and operates its stock database function 30, processes EPOS generated data (such as relating to a UserOneTimeCode) and attends to the assembly and transmission of TransactiondDetails over the Internet to and from the user's Bank 60 and the retailer bank 80. Finally, each of the user bank 60 and retailer bank 80 operate one or more servers 320 and 330 to receive transaction details, process transactions accordingly and dispatch messages confirming the performance of such transactions.
  • EPOS generated data such as relating to a UserOneTimeCode
  • the retailer scans the code symbol V, generates further data to bundle with the OneTimeCode to form the ⁇ Transaction Details ⁇ data package and sends these to the Trusted Admin.
  • the Trusted Admin retrieves the UserlD corresponding to the OneTimeCode sent with the ⁇ Transaction Details ⁇ package
  • the Trusted Admin generates Authorisation ID which it bundles with data elements enabling payment to be made to create to create the transaction data package ⁇ PaymentDetails ⁇ and sends ⁇ PaymentDetails ⁇ to User Bank 60
  • the payment app additionally generates a further data element known as ⁇ TransactionLimit ⁇ .
  • ⁇ TransactionLimit ⁇ This is a value up to which the user's bank 60 is prepared to honor any transaction concluded upon the basis of the respective ⁇ OneTimeCode ⁇ .
  • This figure may be generated in several ways.
  • the payment app prior to generating the ⁇ OneTimeCode ⁇ , the payment app first contacts the user's bank 60 with details of the user, whereupon the user bank 60 then returns a value for ⁇ TransactionLimit ⁇ based upon (for example) a combination of the user's balance and its own internal policies.
  • the user bank 60 provides a figure for ⁇ TransactionLimit ⁇ to the payment app on the user's phone 12 which applies for a set period (such as a day, in which case the figure is updated daily).
  • a set period such as a day, in which case the figure is updated daily.
  • the value of the variable ⁇ TransactionLimit ⁇ is then used throughout that set period.
  • that figure is adjusted with each transaction undertaken; though this will need the payment app to receive data (for example from the trusted administrator) concerning the value of transactions which ought to be taken into account in adjusting the value of ⁇ TransactionLimit ⁇ .
  • the ⁇ LocationStamp ⁇ can be generated by reference to a number of external (i.e. external to the phone 12) references.
  • a preferred external reference is one generated in relation to what may be thought of a 'logical', quasi geographical location rather than actual geographical location.
  • An example of such a location and related reference is a reference that specifies the premises of a retailer.
  • This reference could, for example, be generated by a suitable wireless transmitter beacon which generates a code having an address space which is unique to both the retailer organisation in which the transaction is to take place, and the branch (where the retailer is a multiple branch owner) of that organisation.
  • that code is hashed based on the time of its generation.
  • ⁇ LocationStamp ⁇ generated on such a basis is that it is harder to mimic from another location. GPS coordinates, for example, could conceivably be generated by a user simply typing them in meaning that they do not relate to the actual location of the user 10. By generating a more trustworthy ⁇ LocationStamp ⁇ this parameter can then be used and relied upon to a greater extent as part of the user and transaction authentication process, resulting in a more secure transaction.
  • the application which generates the OneTimeCode is operated by the retailer.
  • this kind of user authorisation will be referred to henceforth as ⁇ OneTimeCode2 ⁇ .
  • the initial interaction involves the user assembling those goods it wishes to purchase. These are then scanned by the retailer 20 in the manner indicated previously to generate a total sum which the user must pay to the retailer to conclude the transaction.
  • the user 10 displays an indicium which is a rendered manifestation of the data element ⁇ UserlD ⁇ to the retailer 20 which is unique to the user 10.
  • the retailer then scans the ⁇ UserlD ⁇ indicium and assimilates an authenticating credential, which may be a PIN or some biometric feature as previously described.
  • the ⁇ UserlD ⁇ and authenticator are encrypted and sent to the trusted administrator together with ⁇ OneTimeCode2 ⁇ , all of which is then bundled with the other data elements described above and sent to the trusted administrator. Thereafter, settlement of the transaction takes place as previously described.

Landscapes

  • Engineering & Computer Science (AREA)
  • Business, Economics & Management (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Accounting & Taxation (AREA)
  • Signal Processing (AREA)
  • Computer Security & Cryptography (AREA)
  • Theoretical Computer Science (AREA)
  • General Physics & Mathematics (AREA)
  • General Business, Economics & Management (AREA)
  • Physics & Mathematics (AREA)
  • Strategic Management (AREA)
  • Computer Hardware Design (AREA)
  • Computing Systems (AREA)
  • General Engineering & Computer Science (AREA)
  • Finance (AREA)
  • Mobile Radio Communication Systems (AREA)
  • Telephonic Communication Services (AREA)

Abstract

Un procédé de transmission de données selon l'invention comprend les étapes consistant à : authentifier l'identité d'un utilisateur auprès d'une application en cours d'exécution sur un dispositif mobile ; générer, avec le dispositif mobile, une autorisation à usage unique qui est personnelle à l'utilisateur et contient une première adresse réseau d'un premier serveur ; encoder l'autorisation dans un indice ; partager l'indice avec un vendeur de biens ou de services ; analyser l'indice pour établir la première adresse réseau et transmettre l'autorisation à la première adresse réseau, conjointement avec des données de transaction contenant l'adresse d'un second serveur sur le réseau ; au premier serveur, établir l'authenticité de l'autorisation à usage unique et, sur la base d'une autorisation à usage unique authentifiée, envoyer des données à la seconde adresse réseau.
EP17705315.4A 2016-01-08 2017-01-09 Système, procédé, et appareil de transmission de données Withdrawn EP3400695A1 (fr)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
GB1600345.1A GB2548073A (en) 2016-01-08 2016-01-08 System, method and apparatus for data transmission
PCT/EP2017/050347 WO2017118763A1 (fr) 2016-01-08 2017-01-09 Système, procédé, et appareil de transmission de données

Publications (1)

Publication Number Publication Date
EP3400695A1 true EP3400695A1 (fr) 2018-11-14

Family

ID=55445728

Family Applications (1)

Application Number Title Priority Date Filing Date
EP17705315.4A Withdrawn EP3400695A1 (fr) 2016-01-08 2017-01-09 Système, procédé, et appareil de transmission de données

Country Status (3)

Country Link
EP (1) EP3400695A1 (fr)
GB (1) GB2548073A (fr)
WO (1) WO2017118763A1 (fr)

Families Citing this family (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US11582225B2 (en) 2017-10-14 2023-02-14 Icrypto, Inc. System and method for detecting the user using a single one-time password
CN114679317B (zh) * 2019-12-26 2024-07-05 支付宝(杭州)信息技术有限公司 数据查看方法以及装置

Family Cites Families (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US7237117B2 (en) * 2001-03-16 2007-06-26 Kenneth P. Weiss Universal secure registry
GB2446423A (en) 2007-02-12 2008-08-13 Hive A method of accessing services using URL obtained from images
WO2013130716A1 (fr) * 2012-02-29 2013-09-06 Patel Upen Système et procédé pour gérer l'information permettant d'effectuer des transactions sécurisées
IN2013DE00375A (fr) * 2013-02-08 2015-06-26 Anant Kochhar
EP3108425A4 (fr) * 2014-02-21 2017-10-18 Visa International Service Association Système et procédé de transmission et de réception d'informations de transaction
US9401895B2 (en) * 2014-04-30 2016-07-26 Fujitsu Limited Device configuration for secure communication

Also Published As

Publication number Publication date
WO2017118763A1 (fr) 2017-07-13
GB2548073A (en) 2017-09-13
GB201600345D0 (en) 2016-02-24

Similar Documents

Publication Publication Date Title
US10594498B2 (en) Method and service-providing server for secure transmission of user-authenticating information
TWI683567B (zh) 安全校驗方法、裝置、伺服器及終端
RU2565368C2 (ru) Аутентификация транзакции на основе жетона
CN110365670A (zh) 黑名单共享方法、装置、计算机设备和存储介质
US20080216172A1 (en) Systems, methods, and apparatus for secure transactions in trusted systems
NO325783B1 (no) Autentisert betaling
CN101218559A (zh) 令牌共享系统和方法
US20120166309A1 (en) Authentication system and authentication method using barcodes
WO2019119541A1 (fr) Procédé et système de transfert de droits et de propriété de marchandise sur la base d'une chaîne de blocs
CN104541475A (zh) 用于交易认证的经提取且随机化的一次性密码
CN101291217A (zh) 网络身份认证方法
CN110489393A (zh) 违约信息查询方法、装置、计算机设备和存储介质
US11233772B1 (en) Methods and systems for secure cross-platform token exchange
US20210166226A1 (en) Deep link authentication
CN110533417B (zh) 一种数字资产管理装置、发行方法及系统
US11133926B2 (en) Attribute-based key management system
EP3400695A1 (fr) Système, procédé, et appareil de transmission de données
CN113627959B (zh) 地理标志产品的数字身份生成方法和装置
KR102346085B1 (ko) 제품의 소유권을 거래하기 위한 방법
KR102347272B1 (ko) 제품의 소유권을 인증하기 위한 방법
KR102320103B1 (ko) 작품에 기재되는 서명을 대체하여 진품을 인증하기 위한 방법
CN114418571B (zh) 一种交易数据快速审核校验方法
CN108960860A (zh) 一种适用于公众平台的防伪防窜货查询方法及系统
CN116263918A (zh) 免密登录数据处理方法以及免密登录数据处理系统
EP2658203A1 (fr) Procédé et système de communication par ordinateur pour l'authentification d'un système client

Legal Events

Date Code Title Description
STAA Information on the status of an ep patent application or granted ep patent

Free format text: STATUS: UNKNOWN

STAA Information on the status of an ep patent application or granted ep patent

Free format text: STATUS: THE INTERNATIONAL PUBLICATION HAS BEEN MADE

PUAI Public reference made under article 153(3) epc to a published international application that has entered the european phase

Free format text: ORIGINAL CODE: 0009012

STAA Information on the status of an ep patent application or granted ep patent

Free format text: STATUS: REQUEST FOR EXAMINATION WAS MADE

17P Request for examination filed

Effective date: 20180808

AK Designated contracting states

Kind code of ref document: A1

Designated state(s): AL AT BE BG CH CY CZ DE DK EE ES FI FR GB GR HR HU IE IS IT LI LT LU LV MC MK MT NL NO PL PT RO RS SE SI SK SM TR

AX Request for extension of the european patent

Extension state: BA ME

DAV Request for validation of the european patent (deleted)
DAX Request for extension of the european patent (deleted)
STAA Information on the status of an ep patent application or granted ep patent

Free format text: STATUS: THE APPLICATION IS DEEMED TO BE WITHDRAWN

18D Application deemed to be withdrawn

Effective date: 20190301