BR112013021057A2 - aparelhos, métodos e sistemas de pagamento eletrônico universal - Google Patents

aparelhos, métodos e sistemas de pagamento eletrônico universal Download PDF

Info

Publication number
BR112013021057A2
BR112013021057A2 BR112013021057-5A BR112013021057A BR112013021057A2 BR 112013021057 A2 BR112013021057 A2 BR 112013021057A2 BR 112013021057 A BR112013021057 A BR 112013021057A BR 112013021057 A2 BR112013021057 A2 BR 112013021057A2
Authority
BR
Brazil
Prior art keywords
user
merchant
data
product
purchase
Prior art date
Application number
BR112013021057-5A
Other languages
English (en)
Inventor
Edward Katzin
Diane Salmon
Igor Karpenko
Jennifer Schulz
Miroslav Gavrilov
Peter Ciurea
Patrick Faith
Phillip Kumnick
Saurav Chatterjee
Sebastian Badea
Shaw Li
Julian Hua
Shipra Jha
Stacy Pourfallah
Susan French
Tenni Theurer
Theodore Harris
Thomas Purves
Vanita Pandey
Victoria Graham
Prakash Hariramani
Gregory Kenneth Storey
Michael Mori
Abhinav Shrivastava
Amit Bhargava
Andrew Beck
Ayman Hammad
Ben Pfisterer
Original Assignee
Visa International Service Association
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
Priority claimed from US13/348,634 external-priority patent/US20120233073A1/en
Priority claimed from US13/398,817 external-priority patent/US20120209749A1/en
Application filed by Visa International Service Association filed Critical Visa International Service Association
Publication of BR112013021057A2 publication Critical patent/BR112013021057A2/pt

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/36—Payment architectures, schemes or protocols characterised by the use of specific devices or networks using electronic wallets or electronic money safes
    • 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/20—Point-of-sale [POS] network systems
    • G06Q20/204—Point-of-sale [POS] network systems comprising interface for record bearing medium or carrier for electronic funds transfer or payment credit
    • 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/322—Aspects of commerce using mobile devices [M-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/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/326—Payment applications installed on the mobile 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/30—Payment architectures, schemes or protocols characterised by the use of specific devices or networks
    • G06Q20/36—Payment architectures, schemes or protocols characterised by the use of specific devices or networks using electronic wallets or electronic money safes
    • G06Q20/367—Payment architectures, schemes or protocols characterised by the use of specific devices or networks using electronic wallets or electronic money safes involving electronic purses or money safes
    • 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/384—Payment protocols; Details thereof using social networks
    • 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
    • G06Q30/00—Commerce
    • 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
    • G06Q30/00—Commerce
    • G06Q30/06—Buying, selling or leasing transactions
    • 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
    • G06Q30/00—Commerce
    • G06Q30/06—Buying, selling or leasing transactions
    • G06Q30/0601—Electronic shopping [e-shopping]
    • G06Q30/0623—Item investigation
    • G—PHYSICS
    • G07—CHECKING-DEVICES
    • G07F—COIN-FREED OR LIKE APPARATUS
    • G07F7/00—Mechanisms actuated by objects other than coins to free or to actuate vending, hiring, coin or paper currency dispensing or refunding apparatus
    • G07F7/08—Mechanisms actuated by objects other than coins to free or to actuate vending, hiring, coin or paper currency dispensing or refunding apparatus by coded identity card or credit card or other personal identification means
    • G07F7/0873—Details of the card reader
    • G07F7/088—Details of the card reader the card reader being part of the point of sale [POS] terminal or electronic cash register [ECR] itself
    • G07F7/0886—Details of the card reader the card reader being part of the point of sale [POS] terminal or electronic cash register [ECR] itself the card reader being portable for interacting with a POS or ECR in realizing a payment transaction

Abstract

APARELHOS, MÉTODOS E SISTEMAS DE PAGAMENTO ELETRÔNICO UNIVERSAL. Os aparelhos, métodos e sistemas de pagamento eletrônico universal ("UEP") transformam as entradas de tela sensível ao toque dentro de uma interface de aplicativo móvel de carteira virtual através de componentes UEP em disparadores de transação de compra e avisos de recebimento. Em uma implementação, o UEP fornece, através de um dispositivo de usuário, uma solicitação de pesquisa de informações de produto; e obtém, em resposta à solicitação de pesquisa de informações de produto, informações sobre um primeiro produto à venda por um primeiro comerciante e um segundo produto à venda por um segundo comerciante. O UEP gera uma única solicitação de transação de compra, utilizando as informações sobre o primeiro produto à venda pelo primeiro comerciante e o segundo produto à venda pelo segundo comerciante. O UEP fornece, através do dispositivo de usuário, a única solicitação de transação de compra para processamento de pagamento. Também, o UEP obtém um recebo de compra eletrônico do primeiro produto à venda pelo primeiro comerciante e do segundo produto à venda pelo segundo comerciante.

Description

"APARELHOS, MÉTODOS E SISTEMAS DE PAGAMENTO ELETRÔNICO UNIVERSAL" Este documento de descrição de cartas patente descreve aspectos inventivas que incluem várias inovações (mais adiante "descrição") e contém material que está sujeito a direitos autorais, citações novas, e/ou outra proteção de propriedade intelectual. Os 5 respectivos donos dessa propriedade intelectual não apresentam objeção à reprodução fac- similada da descrição como aparece no arquivo/registros de Escritório de Patentes publicados, porém de outro modo reservam todos os direitos.
REIVINDICAÇÃO DE PRIORIDADE Este pedido reivindica a prioridade sob USC $ 119 de: pedido de patente provisório 1O norte-americano no. de série 61 /445.482 depositado em 22 de fevereiro de 2011, intitulado "UNIVERSAL ELECTRONIC PAYMENT APPARATUSES, METHODS ANO SYSTEMS", no. de Registro Legal P-42051 PRVI 20270-136PV; pedido de patente provisório norte- americano no. de série 61/545.971 depositado em 11 de outubro de 2011, intitulado "UNIVERSAL ELECTRONIC PAYMENT APPARATUSES, METHODS ANO SYSTEMS", no. de Registro Legal P-42051 US01 l20270-136PV1; pedido de patente provisório norte- americano no. de série. 61/473.728 depositado em 8 de abril de 2011, intitulado "APPARATUSES, METHODS ANO SYSTEMS FOR AN APPLICATION INTEGRATION PAYMENT PLATFORM", no. de Registro Legal P-42189PRVl20270-147PV; pedido de patente provisório norte-americano no. de série 61/466.409 depositado em 22 de março de 2011, intitulado "ELECTRONIC WALLET", no. de Registro Legal P-41963PRVl20270- 148PV; pedido de patente provisório norte-americano no. de série 61/469.965 depositado em 31 de março de 2011, intitulado "APPARATUSES, METHODS ANO SYSTEMS FOR A TARGETED ACCEPTANCE PLATFORM", no. de Registro Legal P-41838PRVI 20270- 062PV; e pedido de patente provisório norte-americano no. de série 61/538.761 depositado em 23 de setembro de 2011, intitulado "ELECTRONIC WALLET TRANSAÇÃO CONSUMER LEASH APPARATUSES, METHODS ANO SYSTEMS", no. de Registro Legal 93US01 l20270-194PV. Este pedido também é uma continuação em parte, e reivindica a prioridade sob U.S.C. $$ 120, 365 de: pedido de patente não provisório norte-americano no. de série 13/398.817 depositado em 16 de fevereiro de 2012, intitulado "SNAP MOBILE PAYMENT APPARATUSES, METHODS ANO SYSTEMS", no. de Registro Legal P-42032US01 20270- 127US; e pedido de patente não provisório norte-americano no. de série 13/348.634 depositado em 11 de janeiro de 2012, intitulado "UNIVERSAL VALUE EXCHANGE APPARATUSES, METHODS ANO SYSTEMS", no. de Registro Legal P-41948US01120270- 089US. Os conteúdos totais dos pedidos anteriormente mencionados estão expressamente incorporados aqui a título de referência.
CAMPO As presentes inovações geralmente se referem a aparelhos, métodos, e sistemas para comércio eletrônico, e mais particularmente, incluem APARELHOS, MÉTODOS E SISTEMAS DE PAGAMENTO ELETRÔNICO UNIVERSAL ("UEP"). 5 ANTECEDENTES Transações de consumo tipicamente exigem que um cliente selecione um produto de uma prateleira de loja ou site da Internet, e então finalizar a compra um ponto de venda ou página da web. As informações de produto são selecionadas a partir de um catálogo da página web ou inseridas em um terminal de ponto de venda, ou as informações são 1O inseridas automaticamente através da leitura de um código de barra de item com um scanner de código de barra integrado no terminal de ponto de venda. O cliente geralmente possui inúmeras de opções de pagamento, como dinheiro, cheque, cartão de crédito ou cartão de débito. Uma vez que o pagamento é feito e aprovado, o terminal de ponto de venda memoriza a transação no sistema de computador do comerciante, e um recibo é gerado indicando a realização satisfatória da transação.
BREVE DESCRIÇÃO DOS DESENHOS Os apêndices e/ou desenhos em anexo ilustram vários aspectos inventivas exemplificativos não limitativos de acordo com a presente descrição: A Figura 1 mostra um diagrama de bloco que ilustra os aspectos exemplificativos de compra com carteira móvel virtual em algumas modalidades do UEP; As Figuras 2A-B mostram diagramas de interface de usuário que ilustram os aspectos exemplificativos de um modo de compra de um aplicativo de carteira virtual em algumas modalidades do UEP; As Figuras 3A-C mostram diagramas de interface de usuário que ilustram os aspectos exemplificativos de um modo de compra de descoberta de um aplicativo de carteira virtual em algumas modalidades do UEP; As Figuras 4A-B mostram diagramas de interface de usuário que ilustram os aspectos exemplificativos de um modo de carrinho de compras de um aplicativo de carteira virtual em algumas modalidades do UEP; A Figura 5 mostra um diagrama de interface de usuário que ilustra os aspectos exemplificativos de um modo de pagamento de contas de um aplicativo de carteira virtual em algumas modalidades do UEP; As Figuras 6A-B mostram diagramas de interface de usuário que ilustram os aspectos exemplificativos de um modo de compra de comerciante (proximidade local) de um aplicativo de carteira virtual em algumas modalidades do UEP;
A Figura 7 mostra diagramas de interface de usuário que ilustram os aspectos exemplificativos de fundos de alocação para um pagamento de compra dentro de um aplicativo de carteira virtual em algumas modalidades do UEP; A Figura 8 mostra diagramas de interface de usuário que ilustram os aspectos 5 exemplificativos de seleção de beneficiários para transferências de fundos dentro de um aplicativo de carteira virtual em algumas modalidades do UEP; As Figuras 9A-B mostram diagramas de interface de usuário que ilustram aspectos exemplificativos adicionais do aplicativo de carteira virtual em algumas modalidades do UEP; As Figuras 1OA-8 mostram diagramas de interface de usuário que ilustram os aspectos exemplificativos de um modo de histórico de um aplicativo de carteira virtual em algumas modalidades do UEP; As Figuras 11A-C mostram diagramas de interface de usuário e fluxo lógico que ilustram os aspectos exemplificativos de criação de uma trilha de compra de usuário dentro de um aplicativo de carteira virtual e esquema de partilha de receitas associado em algumas modalidades do UEP; As Figuras 12A-I mostram diagramas de interface de usuário e fluxo lógico que ilustram os aspectos exemplificativos de um modo instantâneo de um aplicativo de carteira virtual em algumas modalidades do UEP; As Figuras 13A-B mostram diagramas de interface de usuário e fluxo lógico que ilustram os aspectos exemplificativos de um modo de ofertas de um aplicativo de carteira virtual em algumas modalidades do UEP; A Figura 14 mostra diagramas de interface de usuário que ilustram os aspectos exemplificativos de um modo de configurações geral de um aplicativo de carteira virtual em algumas modalidades do UEP; A Figura 15 mostra um diagrama de interface de usuário que ilustra os aspectos exemplificativos de um modo de configurações de títulos de carteira de um aplicativo de carteira virtual em algumas modalidades do UEP; As Figuras 16A-C mostram diagramas de interface de usuário que ilustram os aspectos exemplificativos de um modo de configurações de controles de compra de um aplicativo de carteira virtual em algumas modalidades do UEP; As Figuras 17A-C mostram diagramas de fluxo lógico que ilustram os aspectos exemplificativos de configurar as configurações de aplicativo de carteira virtual e implementar configurações de controles de compra em algumas modalidades do UEP; A Figura 18 mostra um diagrama de bloco que ilustra os aspectos exemplificativos de uma plataforma de informações pessoais centralizada em algumas modalidades do UEP;
As Figuras 19A-F mostram diagrama de blocos que ilustram os aspectos exemplificativos de modelos de dados com uma plataforma de informações pessoais centralizada em algumas modalidades do UEP; A Figura 20 mostra um diagrama de bloco que ilustra as configurações de 5 componente UEP exemplificativas em algumas modalidades do UEP; A Figura 21 mostra um diagrama de fluxo de dados que ilustra um procedimento de agregação de resultado de pesquisa exemplificativo em algumas modalidades do UEP; A Figura 22 mostra um diagrama de fluxo lógico que ilustram os aspectos exemplificativos de resultados de agregação de pesquisa em algumas modalidades do UEP, 1O por exemplo, um componente de Agregação de Resultados de Busca ("SRA") 2200; As Figuras 23A-D mostram diagramas de fluxo de dados que ilustram um procedimento de execução de transação baseada em cartão exemplificativo em algumas modalidades do UEP; As Figuras 24A-E mostram diagramas de fluxo lógico que ilustram os aspectos exemplificativos de execução de transação baseada em cartão, que resulta na geração de dados de transação baseada em cartão e dados de uso de serviço, em algumas modalidades do UEP, por exemplo, um componente de Execução de Transação Baseada em Cartão ("CTE") 2400; A Figura 25 mostra um diagrama de fluxo de dados que ilustra um procedimento exemplificativo para agregar dados de transação baseada em cartão data em algumas modalidades do UEP; A Figura 26 mostra um diagrama de fluxo lógico que ilustra os aspectos exemplificativos para agregar dados de transação baseada em cartão em algumas modalidades do UEP, por exemplo, um componente de Agregação de Dados de Transação ("TDA") 2600; A Figura 27 mostra um diagrama de fluxo de dados que ilustra um procedimento de agregação de dados social exemplificativo em algumas modalidades do UEP; A Figura 28 mostra um diagrama de fluxo lógico que ilustra os aspectos exemplificativos para agregar dados sociais em algumas modalidades do UEP, por exemplo, um componente de Agregação de Dados Sociais ("SDA") 2800; A Figura 29 mostra um diagrama de fluxo de dados que ilustra um procedimento exemplificativo para inscrição em serviços de valor agregado em algumas modalidades do UEP; A Figura 30 mostra um diagrama de fluxo lógico que ilustra os aspectos exemplificativos de inscrição de autenticação de pagamento de rede social em algumas modalidades do UEP, por exemplo, um componente de Inscrição de Serviço de Valor Agregado ("VASE") 3000;
As Figuras 31A-B mostram diagramas de fluxo que ilustram os aspectos exemplificativos de normalização de pesquisa agregada, uso de serviço registrado, transação e/ou outros dados agregados em um formato de dados padronizado em algumas modalidades do UEP, por exemplo, um componente de Normalização de Registro de Dados 5 Agregados ("ADRN") 3100; A Figura 32 mostra um diagrama de fluxo lógico que ilustra os aspectos exemplificativos de identificação de campos de dados em registros de dados agregados normalizado em algumas modalidades do UEP, por exemplo, um componente de Identificação de Campo de Dados ("DFR") 3200; A Figura 33 mostra um diagrama de fluxo lógico que ilustra os aspectos exemplificativos de classificação de tipos de entidade em algumas modalidades do UEP, por exemplo, um componente de Classificação de Tipo de Entidade ("ETC") 3300; A Figura 34 mostra um diagrama de fluxo lógico que ilustra os aspectos exemplificativos de identificação de correlação de entidade cruzada em algumas modalidades do UEP, por exemplo, um componente de Correlação de Entidade Cruzada ("CEC") 3400; A Figura 35 mostra um diagrama de fluxo lógico que ilustra os aspectos exemplificativos de associação de atributos a entidades em algumas modalidades do UEP, por exemplo, um componente de Associação de Atributos a Entidades ("EAA") 3500; A Figura 36 mostra um diagrama de fluxo lógico que ilustra os aspectos exemplificativos de atualização de gráficos de perfil de entidade em algumas modalidades do UEP, por exemplo, um componente de Atualização de Gráficos de Perfil de Entidade ("EPGU") 3600; A Figura 37 mostra um diagrama de fluxo lógico que ilustra os aspectos exemplificativos de geração de termos de pesquisa para a atualização de gráficos de perfil em algumas modalidades do UEP, por exemplo, um componente de Geração de Termos de Busca ("STG") 3700; A Figura 38 mostra um diagrama de fluxo lógico que ilustra os aspectos exemplificativos de análise de um comportamento do usuário baseada em dados de transação de consumo agregado em algumas modalidades do UEP, por exemplo, um componente de Análise de Comportamento de Usuário ("UBA") 3800; A Figura 39 mostra um diagrama de fluxo lógico que ilustra os aspectos exemplificativos de geração de recomendações de um usuário baseada no comportamento de transação de consumo agregado em algumas modalidades do UEP, por exemplo, um componente de Recomendações de Oferta Baseadas em Comportamento de Usuário ("UBOR") 3900;
A Figura 40 mostra um diagrama de bloco que ilustra os aspectos exemplificativos de transações de pagamento através de redes sociais em algumas modalidades do UEP; A Figura 41 mostra um diagrama de fluxo de dados que ilustra um procedimento de registro de pagamento social exemplificativo em algumas modalidades do UEP; 5 A Figura 42 mostra um diagrama de fluxo lógico que ilustra os aspectos exemplificativos de registro de pagamento social em algumas modalidades do UEP, por exemplo, um componente de Registro de Pagamento Social ("SPE") 4200; As Figuras 43A-C mostram diagramas de fluxo de dados que ilustram um procedimento gerador de pagamento social exemplificativo em algumas modalidades do UEP; As Figuras 44A-C mostram diagramas de fluxo lógico que ilustram os aspectos exemplificativos de gerador de pagamento social em algumas modalidades do UEP, por exemplo, um componente Gerador de Pagamento Social ("SPT") 4400; As Figuras 45A-B mostram diagramas de fluxo lógico que ilustram os aspectos exemplificativos de implementação de segurança e configurações de carteira em algumas modalidades do UEP, por exemplo, um componente Something ("WSS") 4500; A Figura 46 mostra um diagrama de fluxo de dados que ilustra um procedimento de ligação de comerciante e consumidor social exemplificativo em algumas modalidades do UEP; A Figura 47 mostra um diagrama de fluxo lógico que ilustra os aspectos exemplificativos de ligação de comerciante e consumidor social em algumas modalidades do UEP, por exemplo, um componente de Ligação de Comerciante e Consumidor Social ("SMCB") 4700; A Figura 48 mostra um diagrama de interface de usuário que ilustra uma visão geral de características exemplificativas de aplicativos de carteira virtual em algumas modalidades do UEP; As Figuras 49A-G mostram diagramas de interface de usuário que ilustram características exemplificativas de aplicativos de carteira virtual em um modo de compra, em algumas modalidades do UEP; As Figuras 50A-F mostram diagramas de interface de usuário que ilustram características exemplificativas de aplicativos de carteira virtual em um modo de pagamento, em algumas modalidades do UEP; A Figura 51 mostra um diagrama de interface de usuário que ilustra características exemplificativas de aplicativos de carteira virtual, em um modo de histórico, em algumas modalidades do UEP;
As Figuras 52A-E mostram diagramas de interface de usuário que ilustram características exemplificativas de aplicativos de carteira virtual em um modo instantâneo, em algumas modalidades do UEP; A Figura 53 mostra um diagrama de interface de usuário que ilustra características 5 exemplificativas de aplicativos de carteira virtual, em um modo de oferta, em algumas modalidades do UEP; As Figuras 54A-B mostram diagramas de interface de usuário que ilustram características exemplificativas de aplicativos de carteira virtual, em um modo de segurança e privacidade, em algumas modalidades do UEP; A Figura 55 mostra um diagrama de fluxo de dados que ilustra um procedimento de finalização de compra de usuário exemplificativo em algumas modalidades do UEP; A Figura 56 mostra um diagrama de fluxo lógico que ilustra os aspectos exemplificativos de uma finalização de compra de usuário em algumas modalidades do UEP, por exemplo, um componente de Finalização de Compra de Usuário ("UPC") 5600; As Figuras 57A-B mostram diagramas de fluxo de dados que ilustram um procedimento de autorização de transação de compra exemplificativo em algumas modalidades do UEP; As Figuras 58A-B mostram diagramas de fluxo lógico que ilustram os aspectos exemplificativos de autorização de transação de compra em algumas modalidades do UEP, por exemplo, um componente de Autorização de Transação de Compra ("PTA") 5800; As Figuras 59A-B mostram diagramas de fluxo de dados que ilustram um procedimento de declaração de transação de compra exemplificativo em algumas modalidades do UEP; As Figuras 60A-B mostram diagramas de fluxo lógico que ilustram os aspectos exemplificativos de declaração de transação de compra em algumas modalidades do UEP, por exemplo, um componente de Declaração de Transação de Compra ("PTC") 6000; e A Figura 61 mostra um diagrama de bloco que ilustra as modalidades de um controlador de UEP. O número inicial de cada referência numérica dentro dos desenhos indica a figura na qual a referência numérica está introduzida e/ou detalhada. Com isso, uma discussão detalhada da referência numérica 101 poderia ser encontrada e/ou introduzida na Figura 1. A referência numérica 201 é introduzida na Figura 2, etc.
DESCRIÇÃO DETALHADA PAGAMENTO ELETRÔNICO UNIVERSAL(UEP) Os APARELHOS, MÉTODOS E SISTEMAS DE PAGAMENTO ELETRÔNICO UNIVERSAL (mais adiante "UEP") transformam as entradas de tela sensível ao toque em uma interface de aplicativo móvel de carteira virtual, através de componentes UEP, em geradores de transação de compra e avisos de recebimento.
A Figura 1 mostra um diagrama de bloco que ilustra os aspectos exemplificativos de compra com carteira móvel virtual em algumas modalidades do UEP.
Em algumas implementações, o UEP pode facilitar o uso de uma carteira virtual, por exemplo, 100, para conduzir transações de compra.
Por 5 exemplo, um usuário 101 pode utilizar um dispositivo móvel 102 (por exemplo, smartphone, tablet, etc.) para conduzir uma transação de compra por conteúdos de um carrinho 103 (por exemplo, carrinho físico em um estabelecimento tradicional, carrinho virtual em um site de compra online), opcionalmente em um cliente de ponto de venda (PoS) 104 (por exemplo, terminal legado em um estabelecimento tradicional, dispositivo de computação em um site 1O de compra online, outro usuário com um aplicativo de carteira virtual, para transferências de fundos de pessoa para pessoa, etc.). O usuário pode ser capaz de escolher entre utilizar um ou mais cartões para uma transação, os cartões selecionados a partir de uma carteira virtual de cartões armazenados dentro de um aplicativo de carteira móvel virtual que é executado no dispositivo móvel.
Ao selecionar uma ou mais opções de cartão, o dispositivo móvel pode comunicar (por exemplo, através de comunicação de campo próximo uni/bidirecional [NFC], Bluetooth, Wi-Fi, conexão de celular, criação e captura de imagens de códigos QR, etc.) as informações de seleção de cartão ao terminal PoS para realizar a transação de compra.
Em algumas modalidades, o dispositivo móvel pode obter um recibo de compra mediante a conclusão de autorização da transação.
Várias características adicionais podem ser fornecidas ao usuário através do aplicativo de carteira móvel virtual que é executado no dispositivo móvel, como adicionalmente descrito abaixo na discussão pelo menos com referência às Figuras 2-54. As Figuras 2A-B mostra diagramas de interface de usuário que ilustram os aspectos exemplificativos de um modo de compra de um aplicativo de carteira virtual em algumas modalidades do UEP.
Com referência à Figura 2A, em algumas modalidades, um usuário pode utilizar um aplicativo de carteira virtual 201 para participar de transações de compra.
Em várias modalidades descritas aqui, o aplicativo de carteira virtual pode fornecer inúmeras características para facilitar a experiência de compra do usuário 202. Por exemplo, o aplicativo de carteira virtual pode permitir que um usuário realize amplas buscas de produtos 203, como adicionalmente discutido abaixo na discussão com referência à Figura 28. Em algumas implementações, o aplicativo de carteira virtual pode fornecer um modo de compra de descoberta '211. Por exemplo, o aplicativo de carteira virtual que é executado em um dispositivo de usuário pode se comunicar com um servidor.
O servidor pode fornecer informações à carteira virtual sobre as tendências de consumo através de uma ampla gama de consumidores no agregado.
Por exemplo, o servidor pode indicar os tipos de consumidores de transações no agregado participantes, o que eles estão comprando, as análises que esses observam, e/ou similares.
Em algumas implementações, o aplicativo de carteira virtual pode utilizar essas informações para fornecer uma interface gráfica do usuário para facilitar a navegação do usuário através dessas informações agregadas, como descrito na discussão abaixo com referência às Figuras 3A-C.
Por exemplo, essa geração de informações agregadas pode ser facilitada pelo uso de UEP de componentes de 5 plataforma de informações pessoais centralizada descritos abaixo na discussão com referência às Figuras 18-37. Em algumas implementações, o aplicativo de carteira virtual pode permitir que o usuário mantenha simultaneamente uma pluralidade de carrinhos de compra, por exemplo, 212-213. Esses carrinhos podem ser, em alguma implementação, simplesmente carrinhos 1O virtuais de um site online, porém em implementações alternativas, podem refletir os conteúdos de um carrinho físico em um estabelecimento comercial.
Em algumas implementações, o aplicativo de carteira virtual pode permitir que o usuário especifique um carrinho atual onde os itens que o usuário deseja serão colocados por padrão, exceto que o usuário especifique em contrário.
Em algumas implementações, o aplicativo de carteira virtual pode permitir que o usuário mude o carrinho atual (por exemplo, 213). Em algumas implementações, o aplicativo de carteira virtual pode permitir que o usuário crie listas de desejos que podem ser publicadas online ou em redes sociais para espalhar para os amigos do usuário.
Em algumas implementações, o aplicativo de carteira virtual pode permitir que o usuário visualize, gerencie, e pague contas para o usuário, 214. Por exemplo, o aplicativo de carteira virtual pode permitir que o usuário importe as contas para a interface de aplicativo de carteira virtual tirando uma fotografia instantânea da fatura, inserindo informações sobre a conta suficientes para que o aplicativo de carteira virtual estabeleça uma comunicação com o comerciante associada à conta, etc.
Em algumas implementações, o aplicativo de carteira virtual pode permitir que o usuário faça compra dentro dos estoques de comerciantes que estão participando da carteira virtual.
Por exemplo, os estoques dos comerciantes podem ser fornecidos dentro do aplicativo de carteira virtual para que o usuário realize compras.
Em algumas implementações, o aplicativo de carteira virtual pode fornecer uma vitrine virtual para o usuário dentro da interface gráfica de usuário do aplicativo de carteira virtual.
Assim, o usuário pode ser virtualmente introduzido em uma loja do comerciante que está participando do aplicativo de carteira virtual do UEP.
Em algumas implementações, o aplicativo de carteira virtual pode utilizar as coordenadas de localização do dispositivo de usuário (por exemplo, através de GPS, endereço IP, triangulação de torre de celular, etc.) para identificar os comerciantes que estão nos arredores da localização atual do usuário.
Em algumas implementações, o aplicativo de carteira virtual pode utilizar essas informações para fornecer informações ao usuário sobre os estoques dos comerciantes na localidade, e ou pode inserir o estabelecimento comercial virtualmente no aplicativo de carteira virtual do usuário.
Em algumas implementações, o aplicativo de carteira virtual pode fornecer um assistente de compras 204. Por exemplo, um usuário pode entrar em uma loja físico de um 5 comerciante.
O usuário pode exigir assistência na experiência de compra.
Em algumas implementações, o aplicativo de carteira virtual pode permitir que o usuário ative o assistente de compras (veja 217), e um gerente da loja no estabelecimento comercial pode ser capaz de ajudar o usuário através de outro dispositivo.
Em algumas modalidades, um usuário pode entrar em uma loja (por exemplo, uma loja física tradicional, loja online virtual 1O [através de um dispositivo de computação], etc.) para participar de uma experiência de compra.
O usuário pode ter um dispositivo de usuário.
O dispositivo de usuário 102 pode executar um aplicativo móvel de carteira virtual, inclusive características como aquelas descritas aqui.
Ao entrar na loja, o dispositivo de usuário pode se comunicar com um servidor de gerenciamento de loja.
Por exemplo, o dispositivo de usuário pode comunicar coordenadas de localização geográfica, informações de registro de usuário e/ou informações de entrada similares para entrar automaticamente na loja.
Em algumas modalidades, o UEP pode introduzir o usuário em uma loja de carteira virtual mediante entrada.
Por exemplo, o aplicativo de carteira virtual que é executado no dispositivo de usuário pode fornecer características como descrito abaixo para ampliar a experiência de compra em estoque do usuário.
Em algumas modalidades, o servidor de gerenciamento de loja pode informar um representante de serviço ao cliente ("CSR") da chegada do usuário na loja.
Por exemplo, o CSR pode ter um dispositivo CSR, e um aplicativo ("aplicativo CSR") pode ser executado nesse.
Por exemplo, o aplicativo pode incluir características coimo descrito abaixo na discussão aqui.
O aplicativo CSR pode informar ao CSR da entrada de usuário, inclusive fornecer informações sobre o perfil do usuário, como a identidade do usuário, compras anteriores e recentes do usuário, os padrões de gasto do usuário nos comerciantes atuais e/ou outros, e/ou similares.
Em algumas modalidades, o servidor de gerenciamento de loja pode ter acesso ao comportamento de compra anterior do usuário, o comportamento na loja em tempo real do usuário (por exemplo, o código de barra dos itens que o usuário leu utilizando o dispositivo de usuário, quantas vezes o usuário leu os códigos de barra, se o usuário está envolvido em uma comparação de produtos lendo os códigos de barra de tipos similares de itens, e/ou similares), os padrões de gasto do usuário (por exemplo, determinados ao longo do tempo, comerciantes, lojas, localizações geográficas, etc.), e/ou informações de perfil de usuário similares.
O sistema de gerenciamento de loja pode utilizar essas informações para fornecer ofertas/cupons, recomendações e/ou similares ao CSR e/ou usuário, através do dispositivo CSR e/ou dispositivo de usuário, respectivamente.
Em algumas modalidades, o CSR pode ajudar o usuário na experiência de compra.
Por exemplo, o CSR pode conferir ofertas, cupons, recomendações, comparações de preço, e/ou similares, e pode realizar ações em nome do usuário, como adicionar/remover itens do carrinho físico/virtual do usuário, aplicar/remover cupons das compras do usuário, procurar ofertas, recomendações, fornecer mapas da loja, ou 5 armazenar visualizações de imersão 30, e/ou similares.
Em algumas modalidades, quando o usuário estiver pronto para finalizar a compra, o UEP pode fornecer uma notificação de finalização de compra ao dispositivo do usuário e/ou dispositivo CSR.
O usuário pode finalizar a compra utilizando o aplicativo de carteira virtual do usuário que é executado no dispositivo de usuário, ou pode utilizar um mecanismo de comunicação (por exemplo, 1O comunicação de campo próximo, passagem de cartão, leitor de código QR, etc.) para fornecer informações de pagamento ao dispositivo CSR.
Utilizando as informações de pagamento, o UEP pode iniciar a(s) transação(ões) de compra do usuário, e fornecer um recibo eletrônico ao dispositivo de usuário e/ou dispositivo CSR.
Utilizando o recibo eletrônico, o usuário pode sair da loja com um comprovante de pagamento de compra.
Com referência à Figura 28, em algumas implementações, o aplicativo de carteira virtual 221 pode fornecer uma ampla gama de resultados de pesquisa 222 em resposta a um usuário fornecendo palavras-chave de pesquisa e/ou filtros para uma solicitação de pesquisa.
Por exemplo, na ilustração da Figura 28, um usuário procurou todos os itens inclusive "Acme" que foram obtidos tirando uma foto instantânea de um item (como discutido abaixo em mais detalhes), e foram datados no ano "2052" (veja 223). Em algumas implementações, os resultados de pesquisa podem incluir transações históricas do usuário 231, ofertas (235, de uma nova conta, que o usuário pode importar para o aplicativo de carteira virtual) e/ou recomendações do usuário baseadas nos padrões comportamentais do usuário, cupons 232, contas 234, descontos, solicitações de transferência de pessoa para pessoa 236, etc., ou ofertas baseadas em disponibilidade de estoque de comerciante, e/ou similares.
Por exemplo, os resultados de pesquisa podem ser organizados de acordo com um tipo, data, descrição, ou ofertas.
Em algumas implementações, as descrições podem incluir listagens anteriores (por exemplo, compra anterior), um preço atual no mesmo local onde foi comprado, e/ou outras ofertas relacionadas ao item (veja, por exemplo, 231). Algumas das ofertas podem ser empilhadas, por exemplo, essas podem ser aplicadas à mesma transação.
Em alguns casos, como, por exemplo, o pagamento de contas (veja 234), os itens podem ser pagos por um sistema de pagamento automático.
Em implementações adicionais, o usuário pode ter a capacidade de pagar manualmente, ou programar pagamentos, adiar um pagamento (por exemplo, os alertas de pagamento aparecem após um período de tempo predeterminado, com uma taxa de juros adicional para explicar o pagamento atrasado), e/ou modificar outras configurações (veja 234). Em algumas implementações, o usuário pode adicionar um ou mais itens listados a um carrinho, 224,
237. Por exemplo, o usuário pode adicionar os itens ao carrinho atual padrão, ou pode inserir o nome de um substituto (ou novo carrinho/lista de desejos) para adicionar os itens, e enviar o comando ao ativar um elemento de interface gráfica de usuário ("GUI") 237. As Figuras 3A-C mostram diagramas de interface de usuário que ilustram os 5 aspectos exemplificativos de um modo de compra de descoberta de um aplicativo de carteira virtual em algumas modalidades do UEP.
Em algumas modalidades, o aplicativo de carteira virtual pode fornecer um modo de compra de descoberta ao usuário.
Por exemplo, o aplicativo de carteira virtual pode obter informações sobre o comportamento de compra agregada de uma amostra de uma população relativa ao usuário, e pode fornecer 1O informações estatísticas/agregadas sobre o comportamento de compra do usuário como um guia para facilitar a compra do usuário.
Por exemplo, com referência à Figura 3A, o modo de compra de descoberta 301 pode fornecer uma visão de comportamento de consumo agregado, dividido com base em categoria de produto (veja 302). Por exemplo, os componentes de plataforma de informações pessoais centralizada descritos abaixo na discussão com referência às Figuras 18-37 podem facilitar o fornecimento desses dados ao aplicativo de carteira virtual.
Assim, o aplicativo de carteira virtual pode fornecer a visualização da magnitude de gasto de consumidor em segmento de mercado particular, e gerar descrições visuais representativas dessas magnitudes de gasto de consumidor (veja 303-306). Em algumas modalidades, o aplicativo de carteira virtual também pode fornecer um indicador (veja 309) do gasto relativo do usuário do aplicativo de carteira virtual (veja 21, barras azuis); assim, o usuário pode ser capaz de visualizar as diferenças entre o comportamento de compra do usuário e o comportamento de consumo no agregado.
O usuário pode ser capaz de desligar o indicador de comportamento de compra (veja 310). Em algumas modalidades, o aplicativo de carteira virtual pode permitir que o usuário aproxime ou afaste a visualização, de modo que o usuário possa obter uma visão com a quantidade apropriada de granularidade de acordo com o desejo do usuário (veja 307-308). Em qualquer momento, o usuário pode ser capaz de reajustar a visualização para uma perspectiva padrão (veja 311 ). Similarmente, o modo de compra de descoberta 321 pode fornecer uma visualização de resposta de consumo agregado a opiniões de especialistas, dividida com base em opiniões de especialistas agregados através da web (veja 302). Por exemplo, os componentes de plataforma de informações pessoais centralizada descritos abaixo na discussão com referência às Figuras 18-37 podem facilitar o fornecimento desses dados para o aplicativo de carteira virtual.
Assim, o aplicativo de carteira virtual pode fornecer visualizações de como os consumidores tendem a concordar com opiniões de especialistas variadas sobre várias categorias de produto, e cujas opiniões são importantes para consumidores no agregado (veja 323-326). Em algumas modalidades, o aplicativo de carteira virtual também pode fornecer um indicador (veja 329) do gasto relativo do usuário do aplicativo de carteira virtual (veja as barras azuis); assim, o usuário pode ser capaz de visualizar as diferenças entre o comportamento de compra do usuário e o comportamento de consumo no agregado.
O usuário também pode ser capaz de desligar o indicador de 5 comportamento de compra do usuário (veja 330). Em algumas modalidades, o aplicativo de carteira virtual pode permitir que o usuário aproxime e afaste a visualização, de modo que o usuário possa obter uma visualização com a quantidade apropriada de granularidade de acordo com o desejo do usuário (veja 327-328). Em qualquer momento, o usuário pode ser capaz de reajustar a visualização para uma perspectiva padrão (veja 331 ). Com referência à Figura 38, em algumas implementações, o aplicativo de carteira virtual pode permitir que os usuário criem regras de compra pretendidas para efetuar uma compra (veja Figura 3A, 312, 322). Por exemplo, o usuário pode utilizar o comportamento de consumo agregado e os dados de opinião de especialistas para impor regras quando se deve iniciar compras automaticamente.
Como um exemplo, a regra 341 especifica que a carteira virtual deve vender um iPad2 aos usuários se sua classificação de relatórios de consumo estiver abaixo de 3.75/5.0, antes de 1º de março, desde que um preço de venda de $399 possa ser obtido.
Como outro exemplo, a regra 342 especifica que a carteira virtual deve comprar um iPad3 se a regra 341 suceder antes de 15 de fevereiro.
Como outro exemplo, a regra 343 especifica que a carteira deve comprar um Moto Droid Razr do Android Market por menos de $349.99 se sua classificação Slashdot for maior que 3. 75 antes de 1º de fevereiro.
Similarmente, inúmeras regras com uma grande variedade de variações e dependências podem ser geradas para compra pretendida no modo de descoberta.
Em algumas implementações, o usuário de carteira virtual pode permitir que o usuário modifique uma regra.
Por exemplo, a carteira pode fornecer ao usuário uma interface similar a 346 ou 347. O usuário pode utilizar ferramentas disponíveis na caixa de ferramentas de editor de regra para projetar a regra de acordo com os desejos do usuário.
Em algumas implementações, a carteira também pode fornecer uma condição de mercado dos itens que são submetidos às regras de compra pretendidas.
Com referência à Figura 3C, em algumas implementações, o aplicativo de carteira virtual pode fornecer um recurso de observação de mercado, em que as tendências associadas a itens submetidos a regras de compra pretendidas podem ser rastreadas e visualmente representadas para o usuário.
Por exemplo, a visualização pode assumir, em algumas implementações, a forma de uma tabela de recepção, em que contra cada item 35i(A)-(E) estão listados uma categoria de produto ou grupo de opiniões de especialistas ao qual o produto está relacionado 352, indicadores de preço, inclusive, porém sem caráter limitativo: preço no momento de criação de regra 352, preço no momento de visualização da tela de observação de mercado 353, e um preço pretendido dos itens (A)-(E). Com base nos preços, a tela de observação de mercado pode fornecer um símbolo de tendências (por exemplo, para cima, para baixo, sem mudança, etc.) para cada item que é submetido a uma regra de compra pretendida. Quando um item satisfizer a regra pretendida (veja item (E)), a carteira virtual pode iniciar automaticamente uma transação de compra daquele item uma 5 vez que o preço pretendido é satisfeito. As Figuras 4A-B mostram diagramas de interface de usuário que ilustram os aspectos exemplificativos de um modo de carrinho de compras de um aplicativo de carteira virtual em algumas modalidades do UEP. Com referência à Figura 4A, em algumas implementações, o aplicativo de carteira virtual pode ser capaz de armazenar, manter e 1O gerenciar uma pluralidade de carrinho de compras e/ou listas de desejos (401-406) de um usuário. Os carrinhos podem ser puramente virtuais, ou esses podem representar os conteúdos de um carrinho físico em um estabelecimento comercial. O usuário pode ativar qualquer um dos carrinhos listados para visualizar os itens atualmente armazenados em um carrinho (por exemplo, 410-416). Em algumas implementações, o aplicativo de carteira virtual também pode fornecer listas de desejos, por exemplo, lista de desejos 417, com itens que o usuário deseja ser presenteado (veja 418-419). Em algumas implementações, a carteira virtual pode permitir que o usuário mude rapidamente os carrinhos ou listas de desejos para outro carrinho ou lista de desejos, utilizando um menu pop-up, por exemplo,
420. Com referência à Figura 48, em uma implementação, o usuário pode selecionar um item particular para obter uma visualização detalhada do item, 421. Por exemplo, o usuário pode visualizar os detalhes dos itens associados à transação e a(s) quantidade(s) de cada item, o comerciante, etc., 422. Em várias implementações, o usuário pode ser capaz de realizar operações adicionais nessa visualização. Por exemplo, o usuário pode (re)comprar o item 423, obter críticas de terceiros do item, e escrever críticas do item 424, adicionar um foto do item para organizar as informações relacionadas ao item juntamente com o item 425, adicionar o item a um grupo de itens relacionados (por exemplo, um agregado), 426, fornecer classificações 427, ou visualizar classificações rápidas dos amigos do usuário ou da web de forma geral. Por exemplo, esses sistemas podem ser implementados utilizando os componentes de plataforma de informações pessoais centralizada exemplificativos descritos abaixo na discussão com referência às Figuras 18- 37. O usuário pode adicionar uma foto à transação. Em uma implementação adicional, se o usuário compartilhou anteriormente a compra através de canais sociais, uma postagem que inclui a foto pode ser gerada e enviada para os canais sociais para publicação. Em uma implementação, qualquer compartilhamento pode ser opcional, e o usuário, que não compartilhou a compra através de canais sociais, ainda pode compartilhar a foto através de um ou mais canais sociais de sua escolha diretamente a partir do modo de histórico do aplicativo de carteira. Em outra implementação, o usuário pode adicionar a transação a um grupo como gasto da empresa, gasto da casa, gasto com viagens ou outras categorias configuradas pelo usuário.
Esse agrupamento pode facilitar a contabilidade final de gastos, envio de relatórios de gasto de serviço, envio de reembolsos de impostos sobre valor agregado (VAT), gastos pessoais, 5 e/ou similares.
Ainda em outra implementação, o usuário pode comprar um ou mais itens adquiridos na transação.
O usuário pode então executar uma transação sem consultar o catálogo ou site de comerciante para encontrar os itens.
Em uma implementação adicional, o usuário também pode colocar no carrinho um ou mais itens na transação para compra posterior.
A carteira virtual, em outra modalidade, pode oferecer meios para obter e exibir classificações 427 dos itens na transação.
A fonte das classificações pode ser o usuário, os amigos do usuário (por exemplo, de canais sociais, contatos, etc.), críticas agregadas da web, e/ou similares.
A interface de usuário em algumas implementações também pode permitir que o usuário envie mensagens para outros usuários de canais sociais (por exemplo, TWITTER ou FACEBOOK). Por exemplo, a área de exibição 428 mostra trocas de mensagens no FACEBOOK entre dois usuários.
Em uma implementação, um usuário pode compartilhar um link através de uma mensagem 429. A seleção dessa mensagem com um link incorporado em um produto pode permitir que o usuário visualize uma descrição do produto e/ou compre o produto diretamente a partir do modo de histórico.
Em algumas implementações, o aplicativo de carteira pode exibir uma trilha de compra ao usuário, por exemplo, 430. Por exemplo, um usuário pode ter analisado um produto em inúmeros sites (por exemplo, ElecReports, APPL FanBoys, Gizmo, Bing, Amazon, Visa Smartbuy feature (por exemplo, que verifica várias fontes automaticamente para o melhor preço disponível de acordo com as preferências do usuário, e apresenta a oferta ao usuário), etc.), isso pode conduzir o usuário a um site de comerciante final onde o usuário finalmente comprou o produto.
Em algumas implementações, o UEP pode identificar os sites que o usuário visitou, isso contribui para o usuário decidir comprar o produto, e pode recompensar o mesmo com uma partilha das receitas obtidas pelo site de "ponto de venda" por ter contribuído com o usuário indo até o site de ponto de venda e adquirindo o produto nesse.
Por exemplo, os sites podem ter acordos com os fabricantes de produtos, atacadistas, varejistas, fornecedores de serviço de pagamento, redes de pagamento, entre os mesmos, e/ou similares em relação à promoção de produto, anúncio, redirecionamento de usuário e/ou similares.
Consequentemente, o UEP pode calcular uma partilha de receita para cada site na trilha de compra do usuário utilizando um modelo de partilha de receitas, e fornecer a partilha de receitas para os sites.
Em algumas implementações, a carteira virtual pode fornecer um recurso de compra pretendida SmartBuy.
Por exemplo, o usuário pode estabelecer um preço pretendido 431 do produto 422 que o usuário deseja comprar.
A carteira virtual pode fornecer uma atualização de status de atualização de observação de mercado em tempo real 432 do produto.
Quando o preço de mercado disponível para o usuário estiver abaixo do preço pretendido do usuário 431, a carteira virtual pode comprar automaticamente o produto para o usuário, e fornecer 5 uma remessa/notificação ao usuário.
A Figura 5 mostra um diagrama de interface de usuário que ilustra os aspectos exemplificativos de um modo de pagamento de contas de um aplicativo de carteira virtual em algumas modalidades do UEP.
Em algumas implementações, o aplicativo de carteira virtual pode fornecer uma lista de resultados de pesquisa de contas 501-503 em resposta a um elemento de ativação de usuário 214 na Figura 2A.
Em algumas implementações os resultados de pesquisa podem incluir transações de faturamento históricas do usuário, bem como as próximas contas (por exemplo, 511-515). Por exemplo, os resultados de pesquisa podem ser organizados de acordo com um tipo, data, descrição.
Em algumas implementações, as descrições podem incluir listagens anteriores (por exemplo, compra anterior), um preço atual no mesmo local onde foi comprado, e/ou outras ofertas relacionadas ao item (veja, por exemplo, 511). Em alguns casos, como, por exemplo, o pagamento de contas (veja 514), os itens podem ser pagos por um sistema de pagamento automático.
Em implementações adicionais, o usuário pode ter a capacidade de pagar manualmente, ou programar pagamentos, adiar um pagamento (por exemplo, os alertas de pagamento aparecem após um período de tempo predeterminado, com uma taxa de juros adicional para explicar o pagamento atrasado), e/ou modificar outras configurações (veja 514). As Figuras 6A-B mostram diagramas de interface de usuário que ilustram os aspectos exemplificativos de um modo de compra de comerciante (proximidade local) de um aplicativo de carteira virtual em algumas modalidades do UEP.
Em algumas implementações, ao ativar os elementos 215 e 216 na Figura 2A, o aplicativo de carteira virtual pode apresentar telas 600 e 61 O, respectivamente, como mostrado na Figura 6A.
Na Figura 6, 600, o aplicativo de carteira virtual exibe uma lista de comerciantes que estão participando da carteira virtual do UEP, por exemplo, 601-605. Similarmente, na Figura 6A, 610, o aplicativo de carteira virtual exibe uma lista de comerciantes que estão participando da carteira virtual do UEP e no ou próximo ao local aproximado do usuário.
O usuário pode clicar em qualquer um dos comerciantes listados nas duas telas 600 e 61 O, para ser introduzido no estoque da loja do comerciante.
Mediante a introdução, o usuário pode ser apresentado com uma tela como 620, que é similar à tela discutida acima na descrição com referência à Figura 4A (centro). Também, em alguma implementação, se um usuário clicar em qualquer um dos itens listados na tela 620, o usuário pode ser conduzido para uma tela 630, similar à tela discutida acima na descrição com referência à Figura 48. Com referência à Figura 68, em algumas modalidades, o usuário pode ser introduzido em uma vitrine de realidade virtual 20/30 do comerciante.
Por exemplo, o usuário pode ser apresentado com uma visualização de mapa plano da loja 641. Em algumas visualizações de mapa, o usuário pode receber a localização do usuário (por exemplo, utilizando GPS, ou se não disponível, 5 então utilizando uma aproximação grosseira que utiliza um sinal de celular). Em algumas implementações, as localizações das compras anteriores e atuais do usuário podem ser fornecidas ao usuário, se o usuário desejar (veja 642, o usuário pode desligar as indicações, em algumas implementações). Em algumas implementações, o usuário pode receber uma visualização 30 do corredor dentro de uma vitrine virtual.
O usuário pode aponta a direção 1O de visualização em qualquer um dos objetos para obter ferramentas virtuais de modo a obter itens fora da "prateleira virtual", e colocar os mesmos no carrinho virtual do usuário.
A tela em 650 mostra uma exibição de realidade aumentada de um corredor, onde usuário pode ver marcações de itens sugeridos por um anunciante, ou que foram marcados como favoritos em seu carrinho/lista de desejos destacados através de uma exibição de vídeo ao vivo 65X.
Em outra exibição, uma exibição de corredor de loja virtual (por exemplo, similar a uma Street View do Google maps) pode ser navegada 651 quando o consumidor não estiver na loja, porém gostaria de procurar um produto; o controle direcional 651 permite a navegação para cima e para baixo do corredor, e a rotação e visualizações de itens no local comercial.
Adicionalmente, os consumidores podem tocar os itens nas prateleiras e criar uma nova marcação de produto, esse pode então ser adicionado 652 a um carrinho ou lista de desejos para transação adicional.
A Figura 7 mostra diagramas de interface de usuário que ilustram os aspectos exemplificativos de alocação de fundos para um pagamento de compra dentro de um aplicativo de carteira virtual em algumas modalidades do UEP.
Em uma modalidade, o aplicativo móvel de carteira pode fornecer a um usuário inúmeras opções de pagamento de uma transação através do modo de carteira 701. O modo de carteira pode ajudar um usuário a ajustar as preferências para uma transação de pagamento, inclusive configurações de fontes de fundos 702, beneficiário 703, modos de transação 704, aplicação de ofertas em tempo real à transação 705, e publicar os detalhes de transação socialmente 706, como descrito em mais detalhes abaixo.
Em uma implementação, mostra-se uma interface de usuário exemplificativa 711 para realizar um pagamento.
A interface de usuário pode identificar claramente o montante 712 e a moeda 713 da transação.
O montante pode ser o montante a pagar e a moeda pode incluir moedas reais como dólares e euros, bem como moedas virtuais como resgate de pontos.
O usuário pode selecionar o indicador de fundos 702 para selecionar uma ou mais formas de pagamento 717, que podem incluir vários cartões de crédito, débito, oferta, recompensas e/ou cartões pré-pagos.
O usuário também pode ter a opção de pagamento,
total ou em partes, com resgate de pontos.
Por exemplo, o indicador gráfico 718 na interface de usuário mostra o número de pontos disponíveis, o indicador gráfico 719 mostra o número de pontos que serão usados em relação ao montante devido 234.56 e o equivalente 720 do número de pontos em uma moeda selecionada (USO, por exemplo). 5 Em uma implementação, o usuário pode combinar os fundos de múltiplas fontes para pagar a transação.
O valor 715 exibido na interface de usuário pode fornecer uma indicação do montante total de fundos cobertos até agora pelas formas de pagamento selecionadas (por exemplo, cartão Discover e resgate de pontos). O usuário pode escolher outra forma de pagamento ou ajustar o montante a ser debitado de uma ou mais formas de pagamento até o montante 715 ser compatível com o montante a pagar 714. Uma vez que os montantes a serem debitados de uma ou mais formas de pagamento são finalizados pelo usuário, a autorização de pagamento pode ser iniciada.
Em uma implementação, o usuário pode selecionar uma autorização segura da transação selecionando-se o botão ocultar 722 para efetivamente ocultar ou anonimizar algumas ou todas as informações (por exemplo, pré-configuradas) de identificação de modo que quando o usuário selecionar o botão de pagamento 721, a autorização de transação seja conduzida de maneira segura e anônima.
Em outra implementação, o usuário pode selecionar o botão de pagamento 721 que pode usar técnicas de autorização padrão para processar a transação.
Ainda em outra implementação, quando o usuário selecionar o botão social 723, uma mensagem referente à transação pode ser comunicada a uma ou mais redes sociais (configuradas pelo usuário), esse pode postar ou anunciar a transação de compra em um fórum social como uma publicação no mural ou um tweet.
Em uma implementação, o usuário pode selecionar uma opção de processamento de pagamento social 723. O indicador 724 pode mostrar a autorização e o envio de dados de compartilhamento sociais em progresso.
Em outra implementação, um modo de pagamento restrito 725 pode ser ativado para algumas ativadas de compra como compras com prescrição.
O modo pode ser ativado de acordo com as regras definidas por emissores, seguradores, comerciantes, processador de pagamento e/ou outras entidades para facilitar o processamento de produtos e serviços especializados.
Nesse modo, o usuário pode rolar para baixo a lista de formas de pagamentos 726 sob indicador de fundos para selecionar as contas especializadas como uma conta de gastos flexíveis (FSA), conta de poupança de saúde (HAS) 727, e/ou similares e montantes que serão debitados das contas selecionadas.
Em uma implementação, esse processamento de modo de pagamento restrito 725 pode desabilitar o compartilhamento social de informações de compra.
Em uma modalidade, o aplicativo móvel de carteira pode facilitar a importação de fundos através da interface de usuário de fundos de importação 728. Por exemplo, um usuário que está desempregado pode obter um fundo de auxílio-desemprego 729 através do aplicativo móvel de carteira.
Em uma implementação, a entidade que fornece os fundos também pode configurar as regras utilizando o fundo como mostrado pela mensagem de indicador de processamento 730. A carteira pode ler e aplicar as regras antes, e pode 5 rejeitas quaisquer compras com os fundos de desemprego que não cumprem os critérios estabelecidos pelas regras.
Os critérios exemplificativos podem incluir, por exemplo, código do estabelecimento (MCC), tempo de transação, local de transação, e/ou similares.
Como um exemplo, uma transação com uma mercearia que possui MCC 5411 pode ser aprovada, enquanto uma transação com um bar que possui um MCC 5813 pode ser negada.
A Figura 8 mostra diagramas de interface de usuário que ilustram os aspectos exemplificativos de seleção de beneficiários para transferências de fundos dentro de um aplicativo de carteira virtual em algumas modalidades do UEP.
Em uma modalidade, a tela de beneficiário 801 na interface de usuário de aplicativo móvel de carteira pode facilitar a seleção de usuário de um ou mais beneficiários que recebem os fundos selecionados no indicador de fundos.
Em uma implementação, a interface de usuário pode mostrar uma lista de todos os beneficiários 802 com os quais o usuário realizou transações anteriormente ou disponíveis para transação.
O usuário pode então selecionar um ou mais beneficiários, 803. Por exemplo, uma seleção pode incluir uma entrada de múltiplos comerciantes - esse pode ser o caso quando um usuário está pagando os produtos em um carrinho, em que os próprios produtos são de múltiplos comerciantes.
Em outro exemplo, o usuário pode estar pagando os produtos colocados em uma pluralidade de carrinhos, sendo que cada carrinho inclui produtos de um ou mais comerciantes.
Os beneficiários 803 podem incluir comerciantes maiores como Amazon.com lnc., e indivíduos como Jane P.
Doe.
Próximo a cada nome de beneficiário, uma lista de modos de pagamento aceitos pelo beneficiário pode ser exibida.
Em algumas implementações, o usuário pode importar 804 nomes adicionais para a lista de endereços incluída dentro da interface de usuário 802. Em uma implementação, o usuário pode selecionar o beneficiário Jane P.
Doe 805 para receber o pagamento.
Mediante a seleção, a interface de usuário pode exibir informações de identificação adicionais 806 referentes ao beneficiário.
A interface de usuário pode permitir que o usuário faça contato com o beneficiário (por exemplo, chamada, texto, e-mail), modifique a entrada do beneficiário na lista de endereços (por exemplo, editar, deletar, combinar com outro contato), ou realize um pagamento ao beneficiário 807. Por exemplo, o usuário pode inserir um montante 808 que será pago ao beneficiário.
O usuário pode incluir uma nota para o beneficiário (o para o usuário) relacionada ao pagamento, 809. O usuário também pode incluir sequências anexadas ao pagamento.
Por exemplo, o usuário pode determinar que o processamento de pagamento deve ocorrer apenas se o beneficiário reenviar a nota ao usuário em um site de rede social, 81 O.
O usuário pode, em qualquer momento, modificar as fontes de financiamento para utilizar no pagamento, 811. Também, o usuário pode utilizar inúmeros modos de pagamento diferentes para cada usuário, 812. Por exemplo, modos adicionais como aqueles descritos na discussão com referência à Figura 9B podem ser usados para o pagamento de pessoa para pessoa.
Por exemplo, um 5 mecanismo de pagamento social pode ser empregado para o pagamento de pessoa para pessoa.
Uma descrição adicional sobre o mecanismo de pagamento social pode ser encontrada na discussão com referência às Figuras 40-47 e 490. Como outro exemplo, o pagamento de pessoa para pessoa pode ser realizado através de um mecanismo móvel instantâneo, como descrito adicionalmente abaixo na discussão com referência à Figura 12A.
As Figuras 9A-B mostram diagramas de interface de usuário que ilustram aspectos adicionais exemplificativos do aplicativo de carteira virtual em algumas modalidades do UEP.
Com referência à Figura 9A, em algumas implementações, uma tela de ofertas 901 pode apresentar ofertas em tempo real que são relativas a itens em um carrinho do usuário para seleção pelo usuário.
O usuário pode selecionar uma ou mais ofertas (veja 902) da lista de ofertas aplicáveis 903 para resgate.
Em uma implementação, algumas ofertas podem ser combinadas (veja, por exemplo, 904), enquanto outras não podem (opcionalmente). Quando o usuário seleciona uma oferta que não pode ser combinada com outra oferta, as ofertas não selecionadas podem ser desabilitadas.
Em uma implementação adicional, as ofertas que são recomendadas pelo mecanismo de recomendação de aplicativo de carteira podem ser identificadas por um indicador, como aquele mostrado por 905. Um mecanismo de recomendação de oferta exemplificativo é descrito adicionalmente abaixo na discussão com referência à Figura 39. Em uma implementação adicional, o usuário pode ler os detalhes da oferta expandindo a série de ofertas como mostrado por 905 na interface de usuário.
O usuário pode atualizar as ofertas exibidas na tala de ofertas em tempo real a qualquer momento (veja 906). Com referência à Figura 9B, em algumas implementações, o indicador de modo 911 pode facilitar a seleção de um modo de pagamento aceito pelo beneficiário.
Inúmeros modos de pagamento podem estar disponíveis para seleção.
Modos exemplificativos incluem, Bluetooth 912, sem fio 913, instantâneo por código QR obtido por usuário 914, chip seguro 915, TWITTER 916, comunicação de campo próximo (NFC) 921, celular 920, instantâneo por código QR fornecido por usuário 919, USB 918 e FACEBOOK 917, entre outros.
Em uma implementação, apenas os modos de pagamento que são aceitos pelo beneficiário podem ser selecionáveis pelo usuário.
Outros modos de pagamento não aceitos podem ser desabilitados.
Em uma modalidade, o indicador social 931 pode facilitar a integração do aplicativo de carteira com canais sociais 932. Em uma implementação, um usuário pode selecionar um ou mais canais sociais 932 e pode se conectar ao canal social selecionado do aplicativo de carteira fornecendo ao aplicativo de carteira o nome de usuário e senha de canal social 933 e registro 934. O usuário pode então usar o botão social 935 para enviar ou receber dinheiro através dos canais sociais integrados. Em uma implementação adicional, o usuário pode 5 enviar dados de compartilhamento sociais como informações de compra ou links através de canais sociais integrados. Em outra modalidade, o usuário fornecido com credenciais de conexão pode permitir que UEP participe da análise de intercepção. As Figuras 1OA-B mostram diagramas de interface de usuário que ilustram os aspectos exemplificativos de um modo de histórico de um aplicativo de carteira virtual em 1O algumas modalidades do UEP. Com referência à Figura 1OA, em uma modalidade, um usuário pode selecionar o modo de histórico 1001 para visualizar o histórico de compras anteriores e realizar várias ações nessas compras anteriores. O aplicativo de carteira pode pesquisar as áreas de armazenamento no dispositivo móvel ou outro lugar (por exemplo, um ou mais bancos de dados e/ou tabelas distantes do dispositivo móvel) para transações anteriores. A interface de usuário pode então exibir os resultados da busca como transações
1003. A interface de usuário pode identificar 1004: um tipo da transação (por exemplo, itens anteriormente comprados, contas que foram capturadas por câmera em um modo instantâneo, uma transferência de pessoa para pessoa [por exemplo, através de mecanismo de pagamento social como descrito abaixo na discussão com referência às Figuras 40-47], etc.); a data da transação; uma descrição da transação, inclusive, porém sem caráter limitativo: um nome de carrinho, indicador de conteúdos de carrinho, custo total, comerciante(s) envolvido(s) na transação; um link para obter uma trilha de compra (explicado abaixo em mais detalhes), ofertas referentes à transação, e quaisquer outras informações relevantes. Em alguma implementação, qualquer transação, cupom, conta exibida, etc. pode ser adicionada a um carrinho para (re)compra, 1005. Em uma modalidade, um usuário pode selecionar o modo de histórico 1011 para visualizar um histórico de compras anteriores filtradas e realizar vários ações nessas compras anteriores. Por exemplo, um usuário pode inserir informações de identificação de comerciante como nome, produto, MCC, e/ou similares na barra de pesquisa 1012. Em outra implementação, o usuário pode usar um recurso de pesquisa ativado por voz para pesquisar o histórico. Em outras implementações, o aplicativo de carteira pode exibir uma tela pop up 1016, em que o usuário pode inserir filtros de pesquisa avançada, palavras- chave, e/ou similares. O aplicativo de carteira pode pesquisar as áreas de armazenamento no dispositivo móvel ou outro lugar (por exemplo, um ou mais bancos de dados e/ou tabelas distantes do dispositivo móvel) para transações correspondentes às palavras-chave de pesquisa. A interface de usuário pode então exibir os resultados da pesquisa como transações 1003. A interface de usuário pode identificar 1014: um tipo da transação (por exemplo, itens anteriormente comprados, contas que foram capturadas por câmera em um modo instantâneo, uma transferência de pessoa para pessoa [por exemplo, através de mecanismo de pagamento social como descrito abaixo na discussão com referência às Figuras 40-47], etc.); a data da transação; uma descrição da transação, inclusive, porém 5 sem caráter limitativo: um nome de carrinho, indicador de conteúdos de carrinho, custo total, comerciante(s) envolvido(s) na transação; um link para obter uma trilha de compra (explicado abaixo em mais detalhes), ofertas referentes à transação, e quaisquer outras informações relevantes. Em alguma implementação, qualquer transação, cupom, conta exibida, etc. pode ser adicionada a um carrinho para (re)compra, 1015. 1O Com referência à Figura 108, em uma modalidade, o modo de histórico também pode incluir meios para exportar recibos. A exportação de recibos pop up 1021 pode fornecer inúmeras opções para exportar os recibos de transações no histórico. Por exemplo, um usuário pode usar uma ou mais opções 1022, que incluem salvar (na memória móvel local, no servidor, em uma conta em nuvem, e/ou similares), imprimir em uma impressora, fax, e-mail, e/ou similares. O usuário pode utilizar sua lista de endereços para procurar e- mail ou número de fax para exportação. O usuário também pode especificar opções de formato para exportação de recibos. Opções de formato exemplificativas podem incluir, sem limitação, arquivos de texto (.doe, .txt, .rtf, iif, etc.), planilha (.csv, .xls, etc.), arquivos de imagem (.jpg, .tff, .png, etc.), formato de documento portátil (.pdf), postscript (.ps), e/ou similares. O usuário pode então clicar ou tocar o botão de exportação para iniciar a exportação de recibos. As Figuras 11A-C mostram diagramas de interface de usuário e fluxo lógico que ilustra os aspectos exemplificativos de criação de uma trilha de compra de usuário dentro de um aplicativo de carteira virtual e esquema de partilha de receitas associado em algumas modalidades do UEP. Com referência à Figura 11A, em algumas implementações, um usuário pode selecionar o modo de histórico 1101 para visualizar um histórico de compras anteriores e realizar várias ações nessas compras anteriores. O aplicativo de carteira pode pesquisar as áreas de armazenamento no dispositivo móvel ou outro lugar (por exemplo, um ou mais bancos de dados e/ou tabelas distantes do dispositivo móvel) para transações anteriores. A interface de usuário pode então exibir os resultados da busca como transações
1103. A interface de usuário pode identificar 1104: um tipo da transação (por exemplo, itens anteriormente comprados, contas que foram capturadas por câmera em um modo instantâneo, uma transferência de pessoa para pessoa [por exemplo, através de mecanismo de pagamento social como descrito abaixo na discussão com referência às Figuras 40-47], etc.); a data da transação; uma descrição da transação, inclusive, porém sem caráter limitativo: um nome de carrinho, indicador de conteúdos de carrinho, custo total, comerciante(s) envolvido(s) na transação; um link para obter uma trilha de compra
(explicado abaixo em mais detalhes), ofertas referentes à transação, e quaisquer outras informações relevantes.
Em alguma implementação, qualquer transação, cupom, conta exibida, etc. pode ser adicionada a um carrinho para (re)compra, 1105. Em uma implementação, o usuário pode selecionar uma transação, por exemplo, 5 transação 1106, para visualizar os detalhes da transação.
Por exemplo, o usuário pode visualizar os detalhes dos itens associados à transação e a(s) quantidade(s) de cada item, o comerciante, etc., 1112. Em várias implementações, o usuário pode ser capaz de realizar operações adicionais dessa visualização.
Por exemplo, o usuário pode (re)comprar o item 1113, obter críticas de terceiros do item, e escrever críticas do item 1114, adicionar um foto 1O do item para organizar as informações relacionadas ao item juntamente com o item 1115, adicionar o item a um grupo de itens relacionados (por exemplo, um agregado), fornecer classificações 1117, ou visualizar classificações rápidas dos amigos do usuário ou da web de forma geral.
Por exemplo, esses sistemas podem ser implementados utilizando os componentes de plataforma de informações pessoais centralizada exemplificativos descritos abaixo na discussão com referência às Figuras 18- 37. O usuário pode adicionar uma foto à transação.
Em uma implementação adicional, se o usuário compartilhou anteriormente a compra através de canais sociais, uma postagem que inclui a foto pode ser gerada e enviada para os canais sociais para publicação.
Em uma implementação, qualquer compartilhamento pode ser opcional, e o usuário, que não compartilhou a compra através de canais sociais, ainda pode compartilhar a foto através de um ou mais canais sociais de sua escolha diretamente a partir do modo de histórico do aplicativo de carteira.
Em outra implementação, o usuário pode adicionar a transação a um grupo como gasto com a empresa, gasto com a casa, gasto com viagens ou outras categorias configuradas pelo usuário.
Esse agrupamento pode facilitar a contabilidade final de gastos, envio de relatórios de gasto de serviço, envio de reembolsos de impostos sobre valor agregado (VAT), gastos pessoais, e/ou similares.
Ainda em outra implementação, o usuário pode comprar um ou mais itens adquiridos na transação.
O usuário pode então executar uma transação sem consultar o catálogo ou site de comerciante para encontrar os itens.
Em uma implementação adicional, o usuário também pode colocar no carrinho um ou mais itens na transação para compra posterior.
O modo de histórico, em outra modalidade, pode oferecer meios para obter e exibir classificações 1117 dos itens na transação.
A fonte das classificações podem ser o usuário, os amigos do usuário (por exemplo, de canais sociais, contatos, etc.), críticas de agregados da web, e/ou similares.
A interface de usuário em algumas implementações também pode permitir que o usuário envie mensagens para outros usuários de canais sociais (por exemplo, TWITTER ou FACEBOOK). Por exemplo, a área de exibição 1118 mostra trocas de mensagens no FACEBOOK entre dois usuários.
Em uma implementação, um usuário pode compartilhar um link através de uma mensagem 1119. A seleção dessa mensagem com um link incorporado em um produto pode permitir que o usuário visualize uma descrição do produto e/ou compre o produto diretamente a partir do modo de histórico.
Em algumas implementações, o aplicativo de carteira pode exibir uma trilha de 5 compra ao usuário, por exemplo, 1120. Por exemplo, um usuário pode ter analisado um produto em inúmeros sites (por exemplo, ElecReports, APPL FanBoys, Gizmo, Bing, Amazon, Visa Smartbuy feature (por exemplo, que verifica várias fontes automaticamente para o melhor preço disponível de acordo com as preferências do usuário, e apresenta a oferta ao usuário), etc.), isso pode conduzir o usuário a um site de comerciante final onde o 1O usuário finalmente comprou o produto.
Em algumas implementações, o UEP pode identificar os sites que o usuário visitou, isso contribui para o usuário decidir comprar o produto, e pode recompensar o mesmo com uma partilha das receitas obtidas pelo site de "ponto de venda" por ter contribuído com o usuário indo até o site de ponto de venda e adquirindo o produto nesse.
Por exemplo, os sites podem ter acordos com os fabricantes de produtos, atacadistas, varejistas, fornecedores de serviço de pagamento, redes de pagamento, entre os mesmos, e/ou similares em relação à promoção de produto, anúncio, redirecionamento de usuário e/ou similares.
Consequentemente, o UEP pode calcular uma partilha de receita para cada site na trilha de compra do usuário utilizando um modelo de partilha de receitas, e fornecer a partilha de receitas para os sites.
Em algumas implementações, a carteira virtual pode fornecer um recurso de compra pretendida SmartBuy.
Por exemplo, o usuário pode estabelecer um preço pretendido 1121 do produto 1112 que o usuário deseja comprar.
A carteira virtual pode fornecer uma atualização de status de atualização de observação de mercado em tempo real 1112 do produto.
Quando o preço de mercado disponível para o usuário estiver abaixo do preço pretendido do usuário 1121, a carteira virtual pode comprar automaticamente o produto para o usuário, e fornecer uma remessa/notificação ao usuário.
A Figura 11 B mostra um diagrama de fluxo lógico que ilustra os aspectos exemplificativos de geração de uma trilha de compra de usuário de carteira virtual em algumas modalidades do UEP, por exemplo, um componente de Geração de Trilha de Compra de Usuário ("USTG") 1100. Em algumas implementações, um dispositivo de usuário de um usuário, que executa um aplicativo de carteira virtual para o usuário, pode rastrear as atividades de compra de um usuário para recuperação e/ou análise posterior.
O dispositivo pode obter uma entrada de usuário, 1101, e determinar um tipo de entrada de usuário, 1102. Se o usuário participar de uma atividade de navegação em um site de um comerciante, ou está navegando entre os sites (por exemplo, em algum momento 1103, opção "Não"), o dispositivo pode rastrear essas atividades.
Por exemplo, o dispositivo pode determinar que a entrada do usuário é uma entrada navegacional (1104, opção "Sim"). O dispositivo pode parar um temporizador associado ao URL atual (por exemplo, de um comerciante como amazon.com, ebay.com, newegg.com, etc., ou um site de crítica como shlashdot.org, cnet.com, etc.) onde o usuário está localizado, e determinar uma contagem de tempo que o usuário gastou no URL, 1108. O dispositivo pode atualizar um banco de dados de trilha de 5 compra (por exemplo, um banco de dados local, um banco de dados em nuvem, etc.) com a contagem de tempo do URL atual, 1109. O dispositivo também pode identificar um URL de redirecionamento no qual o usuário estará navegando como resultado da entrada de navegação do usuário, 111 O.
O dispositivo pode ajustar o URL de redirecionamento como o URL atual, e reiniciar a atividade e contadores de tempo do URL atual.
O dispositivo pode 1O gerar uma nova entrada no banco de dados de trilha de compra do URL que se tornou atual pela entrada navegacional do usuário, 1111. Se o usuário envolvido na atividade de navegação em um URL atual (1105, opção "Sim"), o dispositivo pode identificar o URL associado à atividade de navegação (por exemplo, se a navegação puder ser realizada no dispositivo através de múltiplas janelas ou indicadores, etc.). O dispositivo pode adicionar um contador de atividade para determinar um nível de atividade de usuário do usuário no URL onde a atividade de navegação está ocorrendo, 1106. O dispositivo pode atualizar o banco de dados de trilha de compra com a contagem de atividade do URL, 1107. Se o usuário desejar participar de uma transação de compra, por exemplo, após visitar inúmeros URLs sobre o produto (por exemplo, após ler críticas sobre um produto em inúmeros sites de relatório de consumo, o usuário navega em amazon.com para comparar o produto), veja 1103, opção "Sim", o dispositivo pode ajustar o URL atual como o URL de "ponto de venda" (por exemplo, o comerciante do qual o usuário finalmente comprou o produto - por exemplo, amazon.com), 1112. O dispositivo pode parar o tempo do URL atual, e atualizar o banco de dados de trilha de compra do URL atual, 1113. O dispositivo pode gerar um pedido de autorização de cartão para iniciar a transação de compra, 1114, e fornecer o pedido de autorização de cartão para processamento de transação (veja, por exemplo, o componente PTA 5700 descrito abaixo na discussão com referência à Figura 57A-B). Em algumas implementações, o dispositivo também pode executar um componente de partilha de receitas, como o componente exemplificativo STRS 1120 descrito abaixo na discussão com referência à Figura 11 C.
A Figura 11 C mostra um diagrama de fluxo lógico que ilustra os aspectos exemplificativos de implementação de um modelo de partilha de receitas baseado em trilha de compra de usuário em algumas modalidades do UEP, por exemplo, um componente de Partilha de Receitas de Trilha de Compra ("STRS") 1120. Em algumas implementações, um usuário pode ter analisado um produto em inúmeros sites, isso pode conduzir o usuário a um site de comerciante final onde o usuário finalmente comprou o produto.
Em algumas implementações, o UEP pode identificar os sites que o usuário visitou, isso contribui para o usuário decidir comprar o produto, e pode recompensar o mesmo com uma partilha das receitas obtidas pelo site de "ponto de venda" por ter contribuído com o usuário indo até o 5 site de ponto de venda e adquirindo o produto nesse.
Por exemplo, os sites podem ter acordos com os fabricantes de produtos, atacadistas, varejistas, fornecedores de serviço de pagamento, redes de pagamento, entre os mesmos, e/ou similares em relação à promoção de produtos, anúncio, redirecionamento de usuário e/ou similares.
Por exemplo, um servidor pode armazenar uma tabela de razões de partilha de receitas, isso fornece um esquema de 1O partilha de receitas predeterminado de acordo com o qual os sites contribuintes irão receber uma receita da compra do usuário.
Consequentemente, em algumas implementações, um servidor pode obter uma lista de URLs incluídos em uma trilha de compra do usuário, e sua atividade e contagens de tempo associadas, 1121. O servidor pode identificar um URL de ponto de venda onde o usuário realizou a compra com a qual a receita está sendo partilhada entre os URLs na trilha de compra, 1122. O servidor pode calcular uma contagem de atividade total, e uma contagem de tempo total, somando as contagens de atividade e tempo, respectivamente, de todos os URLs na trilha de compra do usuário, 1123. O servidor pode calcular as razões de atividade e tempo de cada URL, 1124. O servidor pode obter um modelo de partilha de receitas (por exemplo, uma tabela/matriz de bancos de dados de ponderação de valores) para converter as razões de atividade e tempo de cada URL em uma razão de receita daquele URL, 1125. O servidor pode calcular uma partilha de receitas, 1126, para cada URL na trilha de compra de usuário utilizando o modelo de partilha de receitas e as razões de receita calculadas para cada URL.
O servidor pode fornecer uma notificação da receita para cada URL (por exemplo, para cada URL e/ou o URL de ponto de venda a partir do qual a receita será obtida para pagar as partilhas de receitas dos outros URLs na trilha de compra do usuário), 1127. Em algumas implementações, o servidor pode gerar solicitações de autorização de cartão e/ou solicitações de declaração de lote de cada pagamento de receita devido aos URLs na trilha de compra do usuário, para processar essas transações de partilha de receitas.
As Figuras 12A-H mostram diagramas de interface de usuário e fluxo lógico que ilustram os aspectos exemplificativos de um modo instantâneo de um aplicativo de carteira virtual em algumas modalidades do UEP.
Com referência à Figura 12A, em algumas implementações, um usuário pode selecionar o modo instantâneo 1201 para acessar seus recursos instantâneos.
O modo instantâneo pode manipular qualquer representação de dados legível por máquina.
Exemplos desses dados podem incluir códigos de barra lineares e 20 como o código UPC e os códigos QR.
Esses códigos podem ser encontrados em recibos 1206, embalagem de produto 1202, cupons 1203, notas de pagamento 1204, faturas 1205, cartões de crédito e/ou outros cartões de plástico de conta de pagamento ou equivalente 1207, e/ou similares. O modo instantâneo pode processar e manipular imagens de recibos, produtos, ofertas, cartões de crédito ou outros dispositivos de pagamento, e/ou 5 similares. Uma interface de usuário exemplificativa 1211 em modo instantâneo é mostrada na Figura 12A. Um usuário pode usar seu telefone celular para tirar uma foto de um código QR 1215 e/ou um código de barra 1214. Em uma implementação, a barra 1216 e o quadro instantâneo 1213 podem ajudar o usuário a tirar instantâneos de códigos adequadamente. Por exemplo, o quadro instantâneo 1213, como mostrado, não captura o código 1214 total. 1O Como isso, o código capturado nessa visualização não pode ser resolúvel visto que as informações no código podem estar incompletas. Quando o código 1215 for completamente enquadrado pelo quadro instantâneo 5215, o dispositivo pode automaticamente tirar uma foto do código, 1219. Ao encontrar o código, em uma implementação, o usuário pode iniciar a captura de código utilizando a câmera de dispositivo móvel, 1212. Em algumas implementações, o usuário pode ajustar o nível de zoom da câmera para ajudar a capturar o código, 1217. Em algumas implementações, o usuário pode adicionar uma etiqueta GPS ao código capturado, 1218. Com referência à Figura 128, em algumas implementações, quando o usuário ainda não tinha interagido com um item, o usuário pode visualizar detalhes do item projetados para ajudar o usuário a comprar o item nas melhores condições possíveis do usuário. Por exemplo, o aplicativo de carteira virtual pode fornecer uma visualização detalhada do item no ponto onde o usuário tirou um instantâneo utilizando o dispositivo de usuário, 1221, inclusive uma descrição de item, preço, nome de comerciante, etc. A visualização também fornece um código QR 1222, que o usuário pode tocar para salvar na carteira para uso posterior, ou para mostrar a outros usuários que podem tirar um instantâneo do código QR para comprar o item. Em algumas implementações, a visualização pode fornecer serviços adicionais ao usuário, inclusive, porém sem caráter limitativo: serviço de anunciante; serviços de remessa, disque-ajuda, e/ou similares, 1223. Em algumas implementações, a visualização pode fornecer os preços de comerciantes concorrentes localmente ou na web,
1224. Esses dados de preço podem ser auxiliados pelos componentes de plataforma de informações pessoais centralizada descritos abaixo na discussão com referência às Figuras 18-37. Em algumas implementações, a visualização pode fornecer ao usuário a opção para (veja 1225): armazenar o código ajustado, começar de novo e gerar um novo código, ligar ou desligar um recurso de marcação GPS, usar um código QR anteriormente ajustado, inserir palavras-chave associadas ao código QR, associar os itens relacionados ao código QR um objeto, e/ou similares. Em algumas implementações, uma carteira virtual pode fornecer um recurso de compra pretendida SmartBuy. Por exemplo, o usuário pode estabelecer um preço pretendido 1226 do produto 1221 que o usuário deseja comprar.
A carteira virtual pode fornecer uma atualização de status de atualização de observação de mercado em tempo real 1227 do produto.
Quando o preço de mercado disponível para o usuário estiver abaixo do preço pretendido do usuário 1226, a carteira virtual pode comprar 5 automaticamente o produto para o usuário, e fornecer uma remessa/notificação ao usuário.
O usuário pode a qualquer momento adicionar o item a um dos carrinhos ou listas de desejos do usuário (veja 1228). Em uma implementação, em particular quando o usuário interagiu anteriormente com o item que é ajustado, o usuário pode visualizar os detalhes dos 1232 e a(s) quantidade(s) de cada item, o comerciante, etc., 1232. Em várias implementações, o usuário pode ser capaz de realizar operações adicionais nessa visualização.
Por exemplo, o usuário pode (re)comprar o item 1233, obter críticas de terceiros do item, e escrever críticas do item 1234, adicionar um foto do item para organizar as informações relacionadas ao item juntamente com o item 1235, adicionar o item a um grupo de itens relacionados (por exemplo, um agregado), fornecer classificações 1237, ou visualizar classificações rápidas dos amigos do usuário ou da web de forma geral.
Por exemplo, esses sistemas podem ser implementados utilizando os componentes de plataforma de informações pessoais centralizada exemplificativos descritos abaixo na discussão com referência às Figuras 18- 37. O usuário pode adicionar uma foto à transação.
Em uma implementação adicional, se o usuário compartilhou anteriormente a compra através de canais sociais, uma postagem que inclui a foto pode ser gerada e enviada para os canais sociais para publicação.
Em uma implementação, qualquer compartilhamento pode ser opcional, e o usuário, que não compartilhou a compra através de canais sociais, ainda pode compartilhar a foto através de um ou mais canais sociais de sua escolha diretamente a partir do modo de histórico do aplicativo de carteira.
Em outra implementação, o usuário pode adicionar a transação a um grupo como gasto com a empresar, gasto com a casa, gasto com viagens ou outras categorias configuradas pelo usuário.
Esse agrupamento pode facilitar a contabilidade final de gastos, envio de relatórios de gasto de serviço, envio de reembolsos de impostos sobre valor agregado (VAT), gastos pessoais, e/ou similares.
Ainda em outra implementação, o usuário pode comprar um ou mais itens adquiridos na transação.
O usuário pode então executar uma transação sem consultar o catálogo ou site de comerciante para encontrar os itens.
Em uma implementação adicional, o usuário também pode colocar no carrinho um ou mais itens na transação para compra posterior.
O modo de histórico, em outra modalidade, pode oferecer meios para obter e exibir classificações 1237 dos itens na transação.
A fonte das classificações pode ser o usuário, os amigos do usuário (por exemplo, de canais sociais, contatos, etc.), críticas agregadas da web, e/ou similares.
A interface de usuário em algumas implementações também pode permitir que o usuário envie mensagens para outros usuários de canais sociais (por exemplo, TWITTER ou FACEBOOK). Por exemplo, a área de exibição 1238 mostra trocas de mensagens no FACEBOOK entre dois usuários.
Em uma implementação, um usuário pode compartilhar um link através de uma mensagem 1239. A seleção dessa mensagem 5 com um link incorporado em um produto pode permitir que o usuário visualize uma descrição do produto e/ou compre o produto diretamente a partir do modo de histórico.
Em algumas implementações, o aplicativo de carteira pode exibir uma trilha de compra ao usuário, por exemplo, 1240. Por exemplo, um usuário pode ter analisado um produto em inúmeros sites (por exemplo, ElecReports, APPL FanBoys, Gizmo, Bing, 1O Amazon, Visa Smartbuy feature (por exemplo, que verifica várias fontes automaticamente para o melhor preço disponível de acordo com as preferências do usuário, e apresenta a oferta ao usuário), etc.), isso pode conduzir o usuário a um site de comerciante final onde o usuário finalmente comprou o produto.
Em algumas implementações, o UEP pode identificar os sites que o usuário visitou, isso contribui para o usuário decidir comprar o produto, e pode recompensar o mesmo com uma partilha das receitas obtidas pelo site de "ponto de venda" por ter contribuído com o usuário indo até o site de ponto de venda e adquirindo o produto nesse.
Por exemplo, os sites podem ter acordos com os fabricantes de produtos, atacadistas, varejistas, fornecedores de serviço de pagamento, redes de pagamento, entre os mesmos, e/ou similares em relação à promoção de produto, anúncio, redirecionamento de usuário e/ou similares.
Consequentemente, o UEP pode calcular uma partilha de receita para cada site na trilha de compra do usuário utilizando um modelo de partilha de receitas, e fornecer a partilha de receitas para os sites.
Em algumas implementações, a carteira virtual pode fornecer um recurso de compra pretendida SmartBuy.
Por exemplo, o usuário pode estabelecer um preço pretendido 1241 do produto 1232 que o usuário deseja comprar.
A carteira virtual pode fornecer uma atualização de status de atualização de observação de mercado em tempo real 1242 do produto.
Quando o preço de mercado disponível para o usuário estiver abaixo do preço pretendido do usuário 1241, a carteira virtual pode comprar automaticamente o produto para o usuário, e fornecer uma remessa/notificação ao usuário.
Com referência às Figuras 12C-D, em uma modalidade, o modo instantâneo pode facilitar a realocação de pagamento de uma transação anteriormente realizada (Figura 12C), ou uma transação realizada neste momento (Figura 120). Por exemplo, um usuário pode comprar itens de mercearia e com prescrição de um varejista Acme Supermarket.
O usuário já pode, inadvertidamente ou para facilidade de finalização de compra, por exemplo, ter usado seu cartão de pagamento tradicional para pagar os itens de mercearia e com prescrição, e recebeu um recibo.
Entretanto, o usuário pode ter uma conta FSA que poderia ser usada para pagar os itens prescritos, e poderia ter fornecido ao usuário o melhor preço ou outros benefícios econômicos.
Nessa situação, o usuário pode usar o modo instantâneo para iniciar a realocação de transação.
Como mostrado, o usuário pode tirar 1251, 1261 uma foto de um código de barra em um recibo 1253, 1263, com o qual o aplicativo de carteira virtual pode apresentar os dados 5 de recibo 1252, 1262 utilizando informações do código de pagamento.
O usuário agora pode realocar os gastos em suas melhores contas 1254, 1264. Em algumas implementações, o usuário também pode disputar a transação 1255, 1265 ou obter o recibo 1256, 1266. Em uma implementação, quando o botão de realocação for selecionado, o aplicativo de carteira pode realizar o reconhecimento óptico de caracteres (OCR) do recibo.
Cada item 1O no recibo pode então ser examinado para identificar um ou mais itens que poderiam ser cobrados no dispositivo de pagamento ou explicar impostos ou outros benefícios como reembolso, resgate de pontos, etc.
Nesse exemplo, há um benefício fiscal se a medicamento prescrito cobrado no cartão Visa do usuário é cobrado na FSA do usuário.
O aplicativo de carteira pode então realizar a realocação como back end.
O processo de realocação pode incluir a carteira que entra em conato com o processador de pagamento para creditar o montante do medicamento prescrito no cartão Visa e debitar o mesmo montante na conta FSA do usuário.
Em uma implementação alternativa, o processador de pagamento (por exemplo, Visa ou MasterCard) pode obter um OCR do recibo, identificar os itens e contas de pagamento para realocação e realizar a realocação.
Em uma implementação, o aplicativo de carteira pode solicitar que o usuário confirme a realocação de encargos dos itens selecionados em outra conta de pagamento.
O recibo pode ser gerado após a conclusão do processo de realocação.
Como discutido, o recibo mostra que alguns encargos foram movidos da conta Visa para a FSA.
Com referência à Figura 12E, em uma modalidade, o modo instantâneo também pode facilitar a identificação, aplicação e armazenamento de ofertas para uso futuro.
Por exemplo, em uma implementação, um usuário pode tirar um instantâneo de um código de conta, um código de oferta 1271 (por exemplo, um código de barra, um código QR, e/ou similares). O aplicativo de carteira pode então gerar um texto de cartão de conta, texto de cupom, texto de oferta 1272 a partir das informações codificadas no código da oferta.
O usuário pode realizar inúmeras ações no código de oferta.
Por exemplo, o usuário pode usar o botão de realocação 1273 para realocar compras anteriores que foram mais bem realizadas utilizando o cartão, cupom, oferta importada, etc., e o aplicativo de carteira virtual pode fornecer uma notificação de realocação mediante a modificação das contas cobradas das transações anteriores do usuário.
Em uma modalidade, o modo instantâneo também pode oferecer meios para adicionar uma fonte de financiamento ao aplicativo de carteira.
Em uma implementação, um cartão de pagamento como um cartão de crédito, cartão de débito, cartão pré-pago, cartão inteligente e outras contas de pagamento podem possuir um código associado como um código de barra ou código QR.
Esse código pode ter informações de cartão de pagamento codificadas nesse, inclusive, porém sem caráter limitativo, nome, endereço, tipo de cartão de pagamento, detalhes de conta de cartão de pagamento, saldo, limite de gastos, saldo de 5 ganhos, e/ou similares.
Em uma implementação, o código pode ser encontrado em uma superfície do cartão de pagamento físico.
Em outra implementação, o código pode ser obtido ao acessar uma conta online associada ou outro local seguro.
Em ainda outra implementação, o código pode ser impresso em uma letra que acompanha o cartão de pagamento.
Um usuário, em uma implementação, pode tirar uma foto do código.
O 1O aplicativo de carteira pode identificar o cartão de pagamento e pode exibir as informações textuais codificadas no cartão de pagamento.
O usuário pode então realizar a verificação das informações ao selecionar um botão de verificação.
Em uma implementação, a verificação pode incluir contatar o emissor do cartão de pagamento para confirmação das informações decodificadas e quaisquer outras informações relevantes.
Em uma implementação, o usuário pode adicionar o cartão de pagamento à carteira ao selecionar um botão adicionar à carteira'. A instrução para adicionar o cartão de pagamento à carteira pode fazer com que o cartão de pagamento apareça como uma das formas de pagamento sob o indicador de fundo discutido acima.
Com referência à Figura 12F, em algumas implementações, um usuário pode ser vantajosamente capaz de fornecer as configurações de usuário a um dispositivo que produz um código QR para uma transação de compra, e então capturar o código QR utilizando o dispositivo móvel do usuário.
Por exemplo, um dispositivo de exibição de um terminal de ponto de venda pode estar exibindo uma tela de finalização de compra, como um navegador da web que é executado em um cliente, por exemplo, 1281, exibindo uma página da web de finalização de compra de um site de compra online, por exemplo, 1282. Em algumas implementações, a tela de finalização de compra pode fornecer um elemento de interface de usuário, por exemplo, 1283a-b, com o qual o usuário pode indicar o desejo de utilizar pagamento móvel instantâneo.
Por exemplo, se o usuário ativar o elemento 1281a, o site pode gerar um código QR utilizando as configurações padrão do usuário, e exibir o código QR, por exemplo, 1285, na tela do cliente para o usuário capturar utilizando o dispositivo móvel do usuário.
Em algumas implementações, o usuário pode ser capaz de ativar um elemento de interface de usuário, por exemplo, 1283b, com o qual o cliente pode exibir um menu pop-up, por exemplo, 1284, com opções adicionais que o usuário pode selecionar.
Em algumas implementações, o site pode modificar o código QR 1285 em tempo real à medida que o usuário modifica as configurações fornecidas ao ativar o elemento de interface de usuário 1283b.
Uma vez que o usuário modificou as configurações utilizando o menu pop-
up, o usuário pode capturar um instantâneo do código QR para iniciar o processamento de transação de compra.
A Figura 12G mostra um diagrama de fluxo lógico que ilustra os aspectos exemplificativos de execução de um pagamento móvel instantâneo em algumas 5 modalidades do UEP, por exemplo, um componente de Execução de Pagamento Móvel Instantâneo ("SMPE") 1200. Em algumas implementações, um usuário pode desejar comprar um produto, serviço, oferta, e/ou similares ("produto"), de um comerciante através de um site online ou no estabelecimento comercial.
O usuário pode se comunicar com um servidor de comerciante através de um cliente.
Por exemplo, o usuário pode fornecer a 1O entrada de usuário, por exemplo, 1201, no cliente indicando o desejo do usuário de verificar itens de compra em um carrinho de compras (virtual). O cliente pode gerar um pedido de finalização de compra, por exemplo, 1202, e fornecer o pedido de finalização de compra ao servidor de comerciante.
O servidor de comerciante pode obter o pedido de finalização de compra do cliente, e extrair o detalhe de finalização de compra (por exemplo, dados XML) do pedido de finalização de compra, por exemplo, 1203. Por exemplo, o servidor de comerciante pode utilizar um analisador como os analisadores exemplificativos descritos abaixo na discussão com referência à Figura 61. O servidor de comerciante pode extrair os dados de produto, bem como os dados de cliente do pedido de finalização de compra.
Em algumas implementações, o servidor de comerciante pode consultar, por exemplo, 1204, um banco de dados de comerciante para obter dados de produto, por exemplo, 1205, como preço de produto, taxa de vendas, ofertas, descontos, recompensas, e/ou outras informações para processar a transação de compra.
Em resposta à obtenção dos dados de produto, o servidor de comerciante pode gerar, por exemplo, 1206, um código de pagamento QR, e/ou elemento de exibição seguro de acordo com as configurações de segurança do usuário.
Por exemplo, o servidor de comerciante pode gerar um código QR incorporando as informações de produto, bem como informações de comerciante exigidas por uma rede de pagamento para processar a transação de compra.
Por exemplo, o servidor de comerciante pode gerar primeiro em tempo real, uma estrutura de dados XML de produto de comerciante específico de usuário com um período de validade de tempo limitado, como a estrutura de dados'QR_data'XML exemplificativa fornecida abaixo: <QR_data> <session_ID>4NFU4RG94</session_ID> <timestamp>2011-02-22 15: 22: 43</timestamp> <expiry_lapse>OO: 00: 30</expiry_lapse> <transaction_cost>$34. 78</ transaction_cost> <user_ID>john. q. public@gmail.com</user_ID>
<client_details> <client_IP>192.168.23.126</client_IP> <client_type>smartphone</client_type> <client_model>HTC Hero</client_model> 5 <OS>Android 2.2</0S> <app_installed_flag>true</app_installed_flag> </client_details> <secure_ element>www merchant comi securedyn/ 0394733/123.png</ secure_ element> <purchase_details> 1O <num_products>l</num_products> <product> <product_type>book</product_type> <product_params> <product_title>XML for dummies</product_title> <ISBN>938-2-14-168710-0</ISBN> <edition>2nd ed. </edition> <cover>hardbound</ cover> <seller>bestbuybooks</seller> </product_params> <quantity>K/quantity> </product> </purchase_details> <merchant_params> <merchant_id>3FBCR41NC</merchant_id> <merchant_name>Books & Things, lnc. </merchant_name> <merchant_auth_key>INNF484MCP59CHB27365</merchant_auth_key> </merchant_params> <QR_data> Em algumas implementações, o comerciante pode gerar um código QR utilizando os dados XML.
Por exemplo, o servidor de comerciante pode utilizar a biblioteca de Código fonte aberto PHP QR (LGPL) para gerar o Código QR, código de barra bidimensional, disponível em http://phpqrcode.sourceforge.net/. Por exemplo, o servidor de comerciante pode emitir comandos PHP similares aos comandos exemplificativos fornecidos abaixo:
<?PHP header ('Content-Type: text/plain'); li Create QR cede image using data stored in $data variable QRcode:: png ($data, 'qrcodeimg . png'); 5 ?> O servidor de comerciante pode fornecer o código de pagamento QR ao cliente, por exemplo, 1206. O cliente pode obter o código de pagamento QR, e exibir o código QR, por exemplo, 1207 em uma tela de exibição associada ao dispositivo de cliente.
Em algumas implementações, o usuário pode utilizar um dispositivo de usuário, por exemplo, 1209, para 1O capturar o código QR apresentado pelo dispositivo de cliente para processamento de pagamento.
O dispositivo de cliente pode decodificar o código QR para extrair as informações incorporadas no código QR.
Por exemplo, o dispositivo de cliente pode utilizar um aplicativo como a biblioteca de processamento de imagem de código de barra 1D/20 ZXing multi-formato, disponível em http://código.google.eom/p/zxing/ para extrair as informações do código QR.
Em algumas implementações, o usuário pode fornecer a entrada de pagamento no dispositivo de usuário, por exemplo, 1208. Mediante a obtenção da entrada de compra do usuário, o dispositivo de usuário pode gerar um pedido de autorização de cartão, por exemplo, 1209, e fornecer o pedido de autorização de cartão a um servidor de rede de pagamento (veja, por exemplo, a Figura 57A). As Figuras 12H-I mostram diagramas de fluxo lógico que ilustram os aspectos exemplificativos de processamento de um código de Resposta Rápida em algumas modalidades do UEP, por exemplo, um componente de Processamento de Código de Resposta Rápida ("QRCP") 1210. Como referência à Figura 12H, em algumas implementações, um aplicativo de carteira virtual que é executado em um dispositivo de usuário pode determinar se um código QR foi capturado em um quadro de imagem obtido por uma câmera operativamente conectada ao dispositivo de usuário, e também pode determinar o tipo, conteúdos do código QR.
Utilizando-se essas informações, o aplicativo de carteira virtual pode redirecionar a experiência de usuário do usuário e/ou iniciar compras, atualizar aspectos do aplicativo de carteira virtual, etc.
Por exemplo, o aplicativo de carteira virtual pode acionar a captura de um quadro de imagem por uma câmera operativamente conectada ao dispositivo de usuário, 1211. O aplicativo de carteira virtual pode utilizar um algoritmo de segmentação de imagem para identificar um primeiro plano na imagem, 1212, e pode recortar o restante da imagem para reduzir o ruído de fundo na imagem, 1213. O aplicativo de carteira virtual pode determinar se a imagem em primeira plano inclui um código QR a partir do qual os dados podem ser confiavelmente lidos (por exemplo, esse pode não ser o caso se a imagem não incluir um código QR, ou o código QR é parcialmente recortado, manchado, etc.}, 1214. Por exemplo, o aplicativo de carteira virtual pode utilizar uma biblioteca de código como a biblioteca de processamento de imagem de código de barra 1D/20 ZXing multi-formato, disponível em http://code.google.eom/p/zxing/ para testar e extrair as informações do código QR. Se o aplicativo de carteira virtual for capaz de detectar um código QR (1215, opção "Sim"), o aplicativo de carteira virtual pode decodificar 5 o código QR, e extrair os dados do código QR, 1217. Se o aplicativo de carteira virtual for incapaz de detectar um código QR (1215, opção "Não"), o aplicativo de carteira virtual pode tentar realizar o Reconhecimento Óptico de Caracteres na imagem. Por exemplo, o aplicativo de carteira virtual pode utilizar o mecanismo OCR de código aberto Tesseract C++, disponível em www.pixel- technology.com/freewarw/tessnet2, para realizar o reconhecimento óptico de caracteres, 1216. Assim, o aplicativo de carteira virtual pode obter os dados codificados na imagem, e pode continuar se os dados puderem ser processados pelo aplicativo de carteira virtual. O aplicativo de carteira virtual pode consultar um banco de dados utilizando campos identificados nos dados extraídos, para um tipo do código QR,
1218. Por exemplo, o código QR poderia incluir uma fatura/conta, um cupom, uma ordem de pagamento (por exemplo, em uma transferência P2P), um novo pacote de informações de conta, informações de produto, comandos de compra, instruções de navegação URL, scripts de automação de navegador, combinações desses, e/ou similares. Em algumas modalidades, o código QR pode incluir dados em uma nova conta que serão adicionados ao aplicativo de carteira virtual (veja 1219). O aplicativo de carteira virtual pode consultar um emissor da nova conta (como obtido a partir dos dados extraídos), para os dados associados à nova conta, 1220. O aplicativo de carteira virtual pode comparar os dados fornecidos por emissor com os dados extraídos do código QR, 611. Se a nova conta for validada (1221, opção "Sim"), o aplicativo de carteira virtual pode atualizar os credenciais de carteira com os detalhes da nova conta, 1223, e atualizar o histórico instantâneo do aplicativo de carteira virtual utilizando os dados do código QR, 1224. Com referência à Figura 121, em algumas modalidades, o código QR pode incluir dados em uma conta, fatura, ou cupom de uma compra utilizando o aplicativo de carteira virtual (veja 1225). O aplicativo de carteira virtual pode pesquisar comerciante(s) associado(s) à compra (como obtido a partir dos dados extraídos), dos dados associados à conta, fatura ou cupom de uma compra (por exemplo, detalhes de oferta, ID de oferta, tempo de expiração, etc.), 1226. O aplicativo de carteira virtual pode comparar os dados fornecidos por comerciante com os dados extraídos do código QR, 1227. Se a conta, fatura, ou cupom de uma compra for validado (1228, opção "Sim"), o aplicativo de carteira virtual pode gerar uma estrutura de dados (veja, por exemplo, a estrutura XML QR_data na descrição acima com referência à Figura 12F) inclusive os dados codificados por QR para gerar e fornecer um pedido de autorização de cartão, 1229, e atualizar o histórico instantâneo do aplicativo de carteira virtual utilizando os dados do código QR, 1230.
Em algumas modalidades, o código QR pode incluir informações de produto, comandos, instruções de navegação de usuário, etc. do aplicativo de carteira virtual (veja 1231 ). O aplicativo de carteira virtual pode consultar um banco de dados de produto utilizando as informações codificadas em QR. O aplicativo de carteira virtual pode fornecer 5 vários recursos inclusive, sem limitação, exibir informações de produto, redirecionar o usuário para: uma página do produto, um site do comerciante, uma página do produto em um site do comerciante, adicionar item(ns) a um carrinho de compra de usuário em um site de comerciante, etc. Em algumas implementações, o aplicativo de carteira virtual pode realizar um procedimento como descrito acima para qualquer quadro de imagem pendente 1O que será processado, e/ou selecionado para processamento pelo usuário (por exemplo, a partir do histórico instantâneo). As Figuras 13A-B mostram diagramas de interface de usuário e fluxo lógico que ilustram os aspectos exemplificativos de um modo de oferta de um aplicativo de carteira virtual em algumas modalidades do UEP. Com referência à Figura 13A, em algumas implementações, um usuário pode desejar obter novas ofertas no aplicativo de carteira virtual do usuário, ou pode desejar trocar uma oferta existente por uma nova (ou uma pluralidade de ofertas) (por exemplo, as ofertas 1301 podem ser substituídas no comando do usuário). Por exemplo, o usuário pode fornecer uma entrada indicando um desejo de substituir a oferta 1302. Em resposta, o aplicativo de carteira virtual pode fornecer um conjunto de ofertas de substituição 1303, a partir do qual o usuário pode selecionar uma ou mais ofertas para substituir a oferta 1302. A Figura 138 mostra um diagrama de fluxo lógico que ilustra os aspectos exemplificativos de geração de troca de recomendações de oferta em algumas modalidades do UEP, por exemplo, um componente de Recomendação e Troca de Oferta ("ORE") 1310. Em algumas implementações, um usuário pode desejar obter novas ofertas no aplicativo de carteira virtual do usuário, ou pode desejar trocar uma oferta existente por uma nova (ou uma pluralidade de ofertas). O usuário pode fornecer uma entrada para a exibição dessas ofertas, 1301. O dispositivo de usuário pode obter a entrada do usuário, e determinar se o usuário deseja obter uma nova oferta, ou obter ofertas em troca de um oferta atualmente armazenada dentro do aplicativo de carteira virtual do usuário executado no dispositivo,
1302. Se o dispositivo determinar que o usuário deseja trocar uma oferta preexistente, por exemplo, 1303, opção "Sim", o dispositivo pode extrair detalhes da oferta que o usuário deseja trocar. Por exemplo, o dispositivo pode correlacionar a posição da entrada de tela sensível ao toque do usuário (por exemplo, onde o dispositivo possui uma interface de tela sensível ao toque) com uma oferta exibida na tela. O dispositivo também pode determinar que o usuário utilizou um gesto associado à oferta exibida na tela que indica o desejo do usuário de trocar a oferta à qual o gesto de usuário está associado. O dispositivo pode consultar seu banco de dados para um oferta correspondente à oferta exibida, e pode extrair os detalhes da oferta, 1304, ao analisar a oferta retornada ao banco de dados utilizando um analisador, como os analisadores exemplificativos descritos abaixo na discussão com referência à Figura 61. Em algumas implementações, o dispositivo pode extrair quaisquer 5 restrições de geração de oferta de entrada de usuário (por exemplo, com tipos de filtros que o usuário pode aplicar às ofertas que o usuário deseja, palavras-chave relacionadas aos tipos de ofertas que o usuário pode desejar, etc.) fornecidas pelo usuário como entrada,
1305. O dispositivo pode gerar um pedido de geração/troca de oferta para um servidor de rede de pagamento utilizando os dados extraídos na oferta que será trocada (se algum), e 1O as preferências de usuário por tipos de ofertas desejadas (se alguma), por exemplo, como um pedido HTTP(S) POST similar aos exemplos fornecidos nas discussões abaixo. Em algumas implementações, o servidor de rede de pagamento pode analisar o pedido de geração/troca de oferta, 1307, utilizando analisadores como o analisador exemplificativo descrito abaixo na discussão com referência à Figura 61. O servidor de rede de pagamento pode gerar uma consulta de dados de comportamento de usuário, 1308. Por exemplo, o servidor pode utilizar comandos PHP/SQL para consultar um banco de dados de rede de pagamento relacional para dados de comportamento de usuário anterior. Por exemplo, o servidor de rede de pagamento pode obter esses dados gerados utilizando componentes de plataforma de informações pessoais centralizada, como aqueles descritos na discussão abaixo com referência às Figuras 18-37, bem como um componente de análise de comportamento de usuário, como o componente UBA exemplificativo descrito abaixo na discussão com referência à Figura 38. O banco de dados pode fornecer esses dados de comportamento de usuário e análise desses ao servidor de rede de pagamento,
1309. Utilizando-se os dados de comportamento de usuário anterior e/ou análise desses, e utilizando-se os detalhes da oferta trocada e/ou restrições de geração de oferta de usuário, o servidor de rede de pagamento pode gerar ofertas para fornecer ao usuário. Por exemplo, o servidor de rede de pagamento pode utilizar um componente de recomendação de oferta baseado em comportamento de usuário como o componente UBOR exemplificativo descrito na discussão abaixo com referência à Figura 39. O servidor pode fornecer as ofertas geradas ao dispositivo, esse pode exibir as ofertas recebidas para o usuário, 1311. Em algumas implementações, o usuário pode fornecer uma entrada indicando um desejo de resgatar uma das ofertas fornecidas pelo servidor de rede de pagamento, 1312. Em resposta, o dispositivo pode gerar um pedido de autorização de cartão incorporando os detalhes da oferta selecionada para resgate pelo usuário, 1313, e fornecer o pedido de autorização de cartão gerada para o processamento de transação de compra (por exemplo, como uma entrada no componente PTA exemplificativo descrito abaixo na discussão com referência às Figuras 57A-B).
A Figura 14 mostra diagramas de interface de usuário que ilustram os aspectos exemplificativos de um modo de configuração geral de um aplicativo de carteira virtual em algumas modalidades do UEP.
Em algumas implementações, o aplicativo de carteira virtual pode fornecer uma 5 interface de usuário em que o usuário pode modificar as configurações da carteira, 1401. Por exemplo, o usuário pode modificar as configurações, porém sem caráter limitativo: as configurações gerais 1411 (por exemplo, informações de usuário, informações de carteira, informações de conta dentro da carteira, dispositivos ligados à carteira, etc.); controles de privacidade 1412 (por exemplo, informações de controle que são fornecidas a comerciantes, redes de pagamento networks, terceiros, etc.); controles de compra 1413 (por exemplo, impondo restrições de gasto específicas, ou proibindo um tipo particular de transação); notificações 1414; títulos de carteira 1415 (por exemplo, relação feita com outras carteiras virtuais, de modo que as informações, configurações, controles (parentais), e/ou fundos possam fluir entre as carteiras de forma contínua); configurações de pagamento sociais 1416 (veja, por exemplo, as Figuras 40-47); listas de desejos psicológica 1417 (por exemplo, controlar o tipo de comportamentos de usuário considerado para gerar ofertas, recomendações - veja, por exemplo, a Figura 39); compra pretendida 1418 (por exemplo, estabelecer preços pretendidos em que a compra de produtos é automaticamente ativada - veja, por exemplo, as Figuras 11A, 128-C); ou configurações pós-compra 1419 (por exemplo, configurações referentes a reembolsos, retornos, recibos, realocação de gastos (por exemplo, em contas FSA ou HAS), combinação de preço (por exemplo, se o preço do item adquirido cair após o usuário comprar o mesmo)) etc.
Em uma categoria de configurações gerais (1411), um usuário pode ser capaz de modificar as configurações como, porém sem caráter limitativo: informações de usuário 1421, dispositivo de usuário 1422, contas de usuário 1423, sessões de compra 1424, comerciantes que são preferidos 1425, produtos e marcas registradas preferidas, modos preferidos (por exemplo, configurações referentes ao uso de NFC, Bluetooth, e/ou similares), etc.
A Figura 15 mostra um diagrama de interface de usuário que ilustra os aspectos exemplificativos de um modo de configuração de títulos de carteira de um aplicativo de carteira virtual em algumas modalidades do UEP.
Em uma categoria de configuração de títulos de carteira (veja a Figura 14, 1415), um usuário pode ser capaz de modificar as configurações como, porém sem caráter limitativo, configurações referentes: carteiras para pais 1501 (por exemplo, aquelas que têm autorização para impor uma restrição sobre a carteira do usuário); carteiras para crianças 1502 (por exemplo, aquelas carteiras sobre as quais o usuário tem autorização para impor restrições); carteiras de pares 1503 (por exemplo, aquelas carteiras que possuem um nível similar de controle e transparência); e carteiras hoc 1504 (por exemplo, aquelas carteiras que são temporariamente conectadas em tempo real, por exemplo, para uma única transferência de fundos); títulos de carteiras parciais (por exemplo, como títulos entre a carteira virtual corporativa do empregador e uma carteira pessoal do empregado, de modo que uma carteira de empregador possa fornecer 5 fundos limitados com sequências anexadas à carteira do empregado para utilização apenas para propósitos comerciais), e/ou similares.
As Figuras 16A-C mostram diagramas de interface de usuário que ilustram os aspectos exemplificativos de um modo de configuração de controles de compra de um aplicativo de carteira virtual em algumas modalidades do UEP.
Com referência à Figura 16A, 1O em algumas implementações, um usuário pode ser capaz de visualizar e/ou modificar controles de compra que permitem apenas a transação que satisfaz os controles de compra que serão iniciados a partir da carteira.
Em uma implementação, um consumidor pode configurar os parâmetros de prevenção contra fraude controlados por consumidor para restringir uma transação de compra através de sua carteira eletrônica, por exemplo, tempo de transação, quantia máxima, tipo, número de transações por dia, e/ou similares.
Por exemplo, um consumidor pode se inscrever em um serviço de carteira eletrônica (por exemplo, Visa V-Wallet) criando uma conta de carteira eletrônica e adicionando uma conta de pagamento à carteira eletrônica (por exemplo, um cartão de crédito, um cartão de débito, uma conta PayPal, etc.). O consumidor pode configurar os parâmetros para restringir as transações de carteira.
Por exemplo, o consumidor pode configurar uma quantia de transação única máxima (por exemplo, $500.00, etc.). Em outro exemplo, o consumidor pode especificar um período de tempo de transações que serão questionáveis (por exemplo, todas as transações que ocorrem entre 2 am - 6 am, etc.). Em outro exemplo, o consumidor pode especificar o número máximo de transações por dia (por exemplo, 20 por dia, etc.). Em exemplos adicionais, o consumidor pode especificar nomes e/ou IDs de comerciantes com os quais as transações podem ser questionáveis (por exemplo, sites de spam na Internet, etc.). Em uma implementação, o consumidor pode configurar as configurações de controle de compra para detectar e bloquear todas as transações susceptíveis.
Por exemplo, quando ocorrer uma tentativa de transação de uma quantia que excede a quantia de transação máxima especificada, a carteira eletrônica pode ser configurada para rejeitar a transação e enviar um alerta ao consumidor.
A transação pode ser retomada uma vez que o consumidor aprova a transação.
Em outra implementação, se o UEP não receber uma configuração do consumidor para retomar uma transação suscetível, o UEP pode enviar uma notificação ao comerciante para cancelar a transação.
Em uma implementação, o consumidor pode configurar o período de tempo de declaração (por exemplo, 12 horas, etc.). Em outra implementação, o UEP pode determinar um período de declaração máximo padrão de acordo com as exigências reguladoras (por exemplo, 24 horas após a postagem, etc.). Em uma implementação, o UEP pode fornecer ao consumidor uma plataforma de pagamento universal, em que um usuário pode associar uma ou mais contas de pagamento 5 a uma plataforma de pagamento universal e pagar com a plataforma de pagamento universal.
Dentro das modalidades, o consumidor pode criar uma conta de serviço de carteira eletrônica e se inscrever na carteira eletrônica (por exemplo, Visa V-Wallet, etc.) através de UEP.
Em modalidades alternativas, um consumidor pode associar uma conta bancária de consumidor a uma carteira eletrônica existente.
Por exemplo, um consumidor 1O pode fornecer informações de pagamento, como número da conta bancária, número de encaminhamento bancário, informações de perfil de usuário, a uma interface de usuário integrada ao consumidor de gerenciamento de carteira eletrônica, para associar uma conta à carteira eletrônica.
Em outra implementação, um consumidor pode se inscrever na carteira eletrônica durante a finalização de compra online.
Por exemplo, um site de comerciante pode fornecer um botão de carteira eletrônica na página de finalização de compra (por exemplo, um logo Visa V-Wallet, etc.), e mediante a seleção do consumidor do botão de carteira eletrônica, o consumidor pode ser induzido a inserir informações de conta bancária (por exemplo, número de cartão, etc.) para registrar um cartão de pagamento (por exemplo, um cartão de crédito, um cartão de débito, etc.) com a carteira eletrônica através de uma janela pop-up.
Em uma implementação, mediante o recebimento de dados de conta bancária de inscrição de consumidor, o UEP pode gerar um pedido de inscrição para a plataforma de carteira eletrônica (por exemplo, rede de pagamento Visa V-Wallet, etc.). Em uma implementação, um pedido de inscrição de consumidor exemplificativa em Linguagem de Marcação extensível (XML). Em implementações adicionais, o consumidor pode issue receber um dispositivo de carteira eletrônica UEP mediante a inscrição, por exemplo, um aplicativo móvel, um cartão magnético, etc.
Em uma implementação, um usuário pode configurar parâmetros de restrição de transação através de uma interface de usuário de inscrição de consumidor.
Por exemplo, em uma implementação, um usuário de carteira eletrônica pode receber um convite de UEP para assinar o serviço UEP, e seguir um link fornecido no convite (por exemplo, um e-mail, etc.), o usuário pode fornecer informações de registro em uma forma de registro.
Em uma implementação, um usuário pode configurar os métodos de pagamento e alertas com UEP.
Por exemplo, o usuário pode adicionar uma conta de pagamento à carteira, e registrar alertas oportunas com transações associadas à conta de pagamento.
Em uma implementação, o usuário pode estabelecer regras customizadas para disparadores de um alerta de transação.
Por exemplo, uma mensagem de alerta pode ser disparada quando ocorrer uma transação suscetível à medida que a quantia de transação excede uma quantia de transação única máxima (por exemplo, $500.00, etc.). Em outro exemplo, um alerta pode ser disparado quando ocorrer uma transação dentro de um período de tempo suscetível (por exemplo, todas as transações que ocorrem entre 2 am - 6 am, 5 etc.). Em outro exemplo, um alerta pode ser disparado quando a frequência de transações exceder um número máximo de transações por dia (por exemplo, 20 por dia, etc.). Em exemplos adicionais, um alerta pode ser disparado quando o comerciante de transação for um comerciante suscetível especificado por consumidor (por exemplo, sites de spam na Internet, etc.). Em outro exemplo, um alerta pode ser disparado quando o tipo da transação 1O for um tipo de transação bloqueado (por exemplo, um usuário pode proibir transações de carteira em um posto de gasolina para abastecer, etc.). Em uma implementação, o usuário pode inscrever alertas UEP ao selecionar canais de alerta.
Por exemplo, o usuário pode fornecer seu número de celular, endereço de e-mail, endereço postal e/ou similares ao UEP, e inscrever alertas através de e-mail, mensagens de texto, chamadas de atendimento ao consumidor, correspondência, e/ou similares.
Em uma implementação, o usuário pode configurar regras e canais de assinatura para uma conta de pagamento diferente associada à carteira eletrônica.
Em uma implementação, mediante o recebimento de parâmetros configurados por usuário através de uma interface de usuário, o UEP (por exemplo, uma rede Visa Wallet) pode fornecer uma mensagem PUT de Protocolo de Transferência de Hipertexto (Secure) ("HTTP(S)") que inclui os parâmetros de controle de usuário sob a forma de dados formatados de acordo com a Linguagem de Marcação extensível ("XML"). Abaixo está uma mensagem PUT HTTP(S) exemplificativa que inclui parâmetros de controle de usuário formatados em XML para armazenamento em um banco de dados: PUT /leash. php HTTP/1.1 Host: www.leash.com Content-Type: Application/XML Content-Length: 718 <?XML version ="1.0" encoding ="UTF-8"?> <UserLeashRule> <UserlD> JDoe <\UserlD> <WalletlD> JD0001 </WalletlD> <Rule1> <RulelD> 00001 </RulelD> <CardNo> 0000 0000 0000 </CardNo> <MaxAmount> 500.00 </MaxAmount> <MaxPerDay> 20 </MaxPerDay>
<Subscription> Mobile 000-000-0000 </Subscription> <Channel> SMS </Channel>
</Rule1 > 5 <Rule2> <RulelD> 00002 </RulelD> <CardNo> 0000 0000 0002 </CardNo> <MaxAmount> 100.00 </MaxAmount> <MaxPerDay> 1O </MaxPerDay> <BlacklistMerchants> <Merchant1 > abc.com </Merchant1 > <Merchant2> xyz </Merchant2> </BlacklistMerchants>
<Subscription> Email </Subscription> <Channel> jdoe@email.com </Channel>
</Rule2>
<\UserleashRule> Em uma implementação, mediante a configuração dos parâmetros de controle, quando um consumidor comprar com um comerciante (por exemplo, um site de compra, etc.), a rede de processador de pagamento pode encaminhar o pedido de compra para a rede Visa, que pode aplicar a inscrição de UEP do consumidor à carteira eletrônica (por exemplo, rede de carteira Visa, etc.). Por exemplo, em uma implementação, o UEP pode recuperar os parâmetros de controle de usuário, e analisar a quantia de transação, tipo de transação, frequência de transação, e/ou similares do pedido de transação recebido com base nos os parâmetros de controle.
Em uma implementação, se a transação proposta disparar um alerta, o UEP pode gerar uma mensagem de alerta, por exemplo, fornecendo uma mensagem PUT de Protocolo de Transferência de Hipertexto (Seguro) ("HTTP(S)") que inclui o conteúdo de alerta sob a forma de dados formatados de acordo com a XML.
Abaixo está uma mensagem PUT HTTP(S) exemplificativa que inclui um alerta formatado em XML:
PUT /alert. php HTTP/ 1 . 1 Host: www.leash.com Content-Type: Application/XML
Content-Length: 718 <?XML version = 11 1 . 011 encoding = UTF-8 11 11 ?> <Alert> <UserlD> JDoe <\UserlD> 5 <WalletlD> JD0001 </WalletlD> <Time> 23: 23: 34 00- 00-1 900 <Time> <TransactionlD> 000000 <TransactionlD> <Trigger> MaxAmount> </Trigger> <AlertTemplatelD> Tem00001 </AlertTemplatelD> <Subscription> Email </Subscription> <Channel> jdoe@email.com </Channel> <Content> <Title> "Transaction Alert: $1000.00 from Amazon.com </Title> <Greeting> 11 Dear Joe11 </Greeting> <8ody> 11We recently note that ... 11 </8ody>
</Content>
<\Alert> Em uma implementação, o UEP também pode gerar uma mensagem e enviar a mesma ao banco emissor, por exemplo, o banco do usuário que emite a conta de pagamento, etc., para alertar o banco emissor para não creditar fundos para o comerciante a menos que uma mensagem de declaração seja recebida subsequentemente.
Com referência à Figura 168, em algumas implementações, o aplicativo de carteira virtual pode fornecer uma interface através da qual o usuário pode ajustar eficientemente controles de compra para transações.
Por exemplo, o usuário pode inserir uma tela de configuração de controle de compra (11 JDOEi 11 ) 1611, em que o usuário pode adicionar parâmetros de restrição à configuração de controle de compra.
Por exemplo, a interface de usuário à esquerda da Figura 168 mostra um controle de compra que permite que apenas transações em pessoa (veja 1612) abaixo de $50 (veja 1613) sejam realizadas de US ou Taiwan (veja 1614), quando realizadas para roupas ou calçados (veja 1615), e não mais de uma vez por mês (veja 1616), e supondo que o gasto total do usuário durante o período de tempo (1 mo) seja menor que $1500 (veja 1617). Essas restrições paramétricas podem ser impostas utilizando os elementos de interface de usuário 1618 (por exemplo, para selecionar um parâmetro) e 1619 (por exemplo, para inserir um valor correspondente ao parâmetro).
Em algumas situações, a carteira virtual pode fornecer um componente de interface gráfica de usuário (por exemplo, 1622) para facilitar a entrada de usuário.
Por exemplo, a carteira virtual pode exibir um mapa do mundo quando o usuário desejar impor uma restrição geográfica sobre um controle de compra, e o usuário pode tocar o mapa no esporte 5 apropriado (por exemplo, 1623, 1624) para ajustar os locais a partir dos quais a transação pode ser permitida (ou alternativamente, impedida). Em algumas implementações, a carteira virtual também pode permitir que o usuário insira manualmente o valor (veja 1626), em vez de utilizar o componente GUI baseado em toque visual fornecido pelo aplicativo de carteira virtual.
Com referência à Figura 16C, em algumas implementações, o aplicativo de carteira virtual pode permitir que um usuário gerencie as configurações de privacidade 1631 associadas ao uso dos usuários da carteira.
Por exemplo, o usuário pode ser capaz de especificar as informações (por exemplo, 1632-1637) sobre o usuário que podem ser compartilhadas durante uma transação de compra.
Por exemplo, na ilustração, o usuário permite que o aplicativo de carteira virtual compartilhe o nome do usuário, e círculo social (1632). O usuário ainda não estabeleceu uma preferência para compartilhar o endereço do usuário; assim pode-se considerar um valor padrão médio (por exemplo, se o risco na transação for avaliado pelo UEP como sendo médio, então o UEP pode ocultar o endereço do usuário durante a transação) dependendo do tipo de transação, em algumas implementações.
O usuário optou explicitamente contra o compartilhamento dos números de conta do usuário (por exemplo, o usuário deseja que a rede de pagamento oculte o número da conta do usuário durante a transação), e a localização ao vivo GPS do usuário (veja 1638). A Figura 17A mostra um diagrama de fluxo lógico que ilustra os aspectos exemplificativos de configuração de configurações de aplicativo de carteira virtual em algumas modalidades do UEP, por exemplo, um componente de Configuração de Carteira Virtual ("VWSC") 1700. Em algumas implementações, um usuário pode desejar modificar uma configuração dentro do aplicativo de carteira virtual do usuário e/ou dentro de um aplicativo de carteira virtual que possui uma relação com a carteira do usuário (por exemplo, carteira vinculada é uma carteira para criança da carteira do usuário). O usuário pode fornecer uma entrada em um dispositivo de usuário, 1701, indicando o desejo de modificar uma configuração de carteira.
Mediante a determinação que o usuário deseja modificar uma configuração de carteira (veja 1702-1703), o dispositivo pode determinar se o pedido de usuário é para a modificação da carteira do usuário, ou para a modificação de uma carteira vinculada à carteira do usuário.
Em algumas implementações, o aplicativo de carteira pode exigir que o usuário insira uma senha ou responda corretamente uma questão desafio antes de permitir que o usuário modifique uma configuração de usuário.
Ademais, em algumas implementações, o dispositivo pode, se o usuário desejar modificar as configurações de carteira de uma carteira vinculada (veja 1705), determinar se o usuário está autorizado a fazer isso, 1706. Por exemplo, o dispositivo pode determinar o tipo de relação entre a carteira do usuário e a carteira vinculada; se a carteira vinculada (ou seu usuário) for exigida 5 para dar permissão antes que as configurações de carteira possam ser modificadas; e/ou similares.
Em implementações que exigem a autorização do usuário da carteira vinculada, o dispositivo pode fornecer um pedido a um dispositivo do usuário da carteira vinculada (por exemplo, através de um sistema de servidor que armazena endereços de rede para os dispositivos de cada usuário que utiliza uma carteira virtual). Mediante a determinação que a 1O carteira do usuário tem autorização para modificar as configurações da carteira vinculada (veja 1707), o dispositivo pode identificar um tipo de modificação que o usuário deseja realizar, 1708. Em algumas implementações, se o usuário estiver autorizado a modificar uma configuração de carteira, isso pode depender da configuração de carteira que o usuário deseja modificar, nesses caso a identificação do tipo de modificação pode ser realizada antes de determinar se o usuário está autorizado a modificar a configuração de carteira.
Com base no tipo de modificação solicitada pelo usuário, o dispositivo pode fornecer um componente de interface gráfica de usuário (GUI) (veja, por exemplo, o mapa geográfico para marcar os países a partir dos quais as transações podem ser iniciadas para uma configuração de controle de compra particular, A Figura 168 [centro]) facilitar a entrada de usuário da modificação em uma configuração de carteira, 1709. O dispositivo pode obter a entrada de valor de configuração de usuário através do componente GUI, 171 O.
Quando a modificação envolve uma carteira vinculada, o dispositivo fornece opcionalmente uma notificação de modificação de uma configuração envolvendo a carteira vinculada, 1711. O dispositivo pode armazenar opcionalmente a modificação da configuração de carteira em um banco de dados, por exemplo, em um banco de dados local ou um banco de dados de armazenamento em nuvem, 1712. As Figuras 178-C mostram diagramas de fluxo lógico que ilustram os aspectos exemplificativos de implementação de configurações de controle de compras em algumas modalidades do UEP, por exemplo, um componente de Configurações de Controles de Compra ("PCS") 1720. Com referência à Figura 178, em algumas implementações, um usuário pode desejar gerar uma configuração de controle de compra para monitorar e/ou impedir que as transações de um caráter específico sejam processadas pelo UEP.
O usuário pode fornecer uma indicação em um dispositivo de usuário que executa um aplicativo de carteira virtual do usuário, 1721. Em resposta, o dispositivo pode fornecer um componente GUI do usuário para selecionar um parâmetro de acordo com o mesmo para restringir as transações iniciadas a partir da carteira virtual do usuário, 1722 (veja, por exemplo, as rodas de rolagem da Figura 168). O usuário pode utilizar o componente GUI para selecionar um parâmetro de restrição, 1723. Com base no parâmetro de restrição selecionado (por exemplo, localização geográfica, valor de transação, cartão de transação, categoria de produto, tempo, data, 5 moeda, saldo(s) de conta, etc.), o dispositivo pode identificar, por exemplo, consultando um banco de dados, um componente GUI para ajudar o usuário a fornecer um valor associado ao parâmetro de restrição (veja, por exemplo, o mapa do mundo da Figura 168 [centro]),
1724. O dispositivo pode fornecer o componente GUI identificado ao usuário, 1725. Utilizando-se o componente GUI, o usuário pode fornecer um valor do parâmetro de 1O restrição, 1726. Em resposta, o dispositivo pode gerar um trecho de dados que inclui uma identificação de um parâmetro de restrição, e um valor associado do parâmetro de restrição,
1727. Por exemplo, o trecho de dados pode ser formatado com uma estrutura de dados XML. Em algumas implementações, a estrutura de dados também pode incluir uma indicação se o valor de parâmetro de restrição representa um limite superior ou limite inferior da faixa de valores permitidos para aquele parâmetro. O dispositivo pode anexar a estrutura de dados do parâmetro de restrição a uma estrutura de dados para a configuração de controle de compra total, 1727. Em algumas implementações, o dispositivo pode determinar se o usuário deseja inserir mais parâmetros de restrição, e pode ajudar o usuário a inserir esses parâmetros de restrição em cima de quaisquer parâmetros de restrição anteriormente fornecidos (veja 1728-1729). Ao obter todos os parâmetros de restrição para uma determinada configuração de controle de compra, o dispositivo pode armazenar a configuração de controle de compra finalizada em um banco de dados (por exemplo, um banco de dados local, um banco de dados de armazenamento em nuvem, etc.), 1730. Com referência à Figura 17C, em algumas implementações, um usuário pode desejar participar de uma transação de compra. O usuário pode fornecer uma entrada no dispositivo de usuário que executa um aplicativo de carteira virtual indicativo do desejo do usuário de participar da transação de compra, 1731. Em resposta, o dispositivo pode identificar os parâmetros da transação (por exemplo, localização geográfica, valor de transação, cartão de transação, categoria de produto, tempo, data, carrinho, tipo de carteira [vinculada, não vinculada], moeda, saldo(s) de conta sobre o tempo de início da transação, etc.), 1732. O dispositivo pode consultar um banco de dados para configurações de controle de compra que podem se aplicar ao pedido de transação de compra, 1733. Por exemplo, esses incluem regras estabelecidas por um usuário de carteira vinculada que tem autorização para estabelecer controles de compra sobre a carteira do usuário. O dispositivo pode processar cada configuração de controle de compra para garantir que nenhuma configuração seja violada. Em esquemas alternativos, o dispositivo pode processar configurações de controle de compra até pelo menos uma configuração de controle de compra permitir que a transação de compra seja realizada (ou a transação de compra pode ser negada se nenhuma configuração permitir isso), veja 1734. The dispositivo pode selecionar uma configuração de controle de compra, e extrair os parâmetros de restrição e seu valor associado da estrutura de dados de configuração de controle de compra.
Por 5 exemplo, o dispositivo pode usar um analisador similar aos analisadores exemplificativos descritos abaixo na discussão com referência à Figura 61. O dispositivo pode selecionar um par de valores de parâmetro de restrição, 1736, e determinar se os parâmetros de transação violam o valor de parâmetro de restrição, 1737. Se a restrição for violada (1738, opção "Sim"), o dispositivo pode negar o pedido de transação de compra.
De outro modo, o 1O dispositivo pode verificar cada parâmetro de restrição na configuração de controle de compra (veja 1739) em um procedimento similar àquele descrito acima.
Se a configuração de controle de compra não restringir a transação, o dispositivo pode executar um procedimento similar para todas as outras configurações de controle de compra, a menos que uma das configurações seja violada (ou, no esquema alternativo, se pelo menos uma configuração de controle de compra permitir a transação de compra) (veja 1740). Se o dispositivo determinar que a transação de compra é permitida pelas configurações de controle de compra do usuário e/ou usuários de carteira vinculada (1740, opção "Não"), o dispositivo pode gerar um pedido de autorização de cartão, 1741, e fornecer o pedido de autorização de cartão para autorização de transação de compra (veja Figura 57 A). Plataforma de Informações Pessoais Centralizada A Figura 18 mostra um diagrama de bloco que ilustra os aspectos exemplificativos de uma plataforma de informações pessoais centralizada em algumas modalidades do UEP.
Em vários cenários, originadores 1811 como comerciantes 1811 b, consumidores 1811 c, emissores de conta, adquirentes 1811a, e/ou similares, desejam utilizar informações de sistemas de rede de pagamento para habilitar vários recursos de consumo.
Esses recursos podem incluir serviços de aplicativo 1812 como alertas 1812a, ofertas 1812c, transferências de fundos1812n, detecção de fraude 1812b, e/ou similares.
Em algumas modalidades do UEP, esses originadores podem solicitar dados para habilitar serviços de aplicativo de uma plataforma de informações comum, segura, centralizada que inclui um banco de dados de gráfico de perfil de entidade cruzada consolidado 1801. Por exemplo, os originadores podem apresentar consultas complexas ao UEP em um formato de estrutura, como o exemplo abaixo.
Nesse exemplo, a consulta inclui uma consulta para determinar uma localização (por exemplo, de um usuário), determinar se está associada à localização, realizar análises nos dados meteorológicos, e fornecer uma visualização gráfica explodida dos resultados da análise:
<int Model_id = " 1 " envi ron ment_type="RT" meta_data=" . I fModels/ robotExample .meta" 5 tumblar_location=". I fModels/robotExample. tumblar. location" input_format="JSON" pmmls="AUTONOMOUS_AGENTS . PMML" Model_type ="AUTONOMOUS_AGENTS" > <vault >
<door:LOCATION> <lock name=" DETERMINE LOCATION" inkey="I NPUT" inkeyname="lat" inkey2="1NPUT" inkeyname2="1ong" function="ROUND" fnctl-prec="-2" function-1 =" JOIN" fnct2-delim=": " tumblar='LAT_LOllG. key' outkey="TEMP" outkeyname="location" type=" STRING" /> <lock name=" DETERMINE WEATHER" inkey="TEMP" inkeyname="location" mesh='MESHRT . RECENTWEATHER' mesh-query='HASH' outkey="TEMP" outkeyname="WEATHERDATA" type="ARRA Y" /> <lock name="EXPLODE DATA" inkey="TEMP" inkeyname="WEATHERDATA" function="EXPLODE" fnct-delim=": " outkey="MODELDATA" outkeystartindex=1 /> <lock name="USER SETTINGS"
inkey= 11 INPUT11 inkeyname= 11 USERID 11 mesh='MESHRT . AUTONOMOUSAGENT . SETTINGS' mesh-query='HASH' outkey= 11TEMP" outkeyname= 11 USERSETTINGS 11 5 type= 11ARRA Y" /> <lock name="EXPLODE USER" inkey= 11TEMP" inkeyname= 11 USERSETTINGS 11 function= 11 EXPLODE 11 fnct-delim= 11 : 11 outkey="USERDATA" outkeystartindex=1 /> <lock name= 11 RUN MODELE" inkey="MODELDATA11 inkeyl= 11 USERDATA11 function="TREE 11 fnc-pmml="AUTONOMOUS_AGENTS . PMML11 outkey= 11 0UTPUT11 outkeyname= 11WEATH ER 11 type= 11 NUMERIC 11 /> </door> </vault> Uma lista de dados não limitativa exemplificativa que o UEP pode retornar com base em uma consulta é fornecida abaixo.
Nesse exemplo, um usuário pode se conectar a um site através de um dispositivo de computação.
O dispositivo de computação pode fornecer um endereço IP, e um carimbo de data e hora ao UEP.
Em resposta, o UEP pode identificar um perfil do usuário a partir de seu banco de dados, e com base no perfil, retorna comerciantes potenciais de ofertas ou cupons:
-------------------------- *Use Case ------------------------ -- User log into a website -- Only IP address, GMT and day of week is passed to Mesh -- Mesh matches profile based on Affinity Group -- Mesh returns potential Merchants for offers or coupons based on tempory -- model using suppression rules
-- Test case 1 IP: 24: 227: 206 Hour: 9 Day:3
-- Test case 2 IP: 148: 181: 75 Hour: 4 Day:5
AffinityGroup Lookup --------------------------
5 Look up test case 1 [OrderedDict ([('ISACTIVE', 'True'), ([ENTITYKEY', '24:227:206:3:1'), ('XML', None), ('AFFINITYGROUPNAME', '24:227:206:3:1'), ('DESCRIPTION', None), ('TYPEOF', None), ('UUID', '5f8df970b9ff11 e09ab9270cf67eca90')]), OrderedDict ([('ISACTIVE', 'True'), ('BASEUUID', 1O '4fbea327b9fflle094f433b5d7 c45677'), ('TOKENENTITYKEY', '4fbea327b9ff11e094f433b5d7c45677:TOKEN:349:F'), ('BASETYPE', 'MODEL_002_001_00'), ('STATUS', 'ACTIVE'), ('ISSUEDDATE', None), ('WEIGHT', '349'), ('CATEGORY', 'F'), ('DOUBLELINKED', None), ('UUID', '6b6aab39b9ff11 e08d850dc270e3ea06')]), OrderedDict ([('ISACTIVE', 'True'), ('BASEUUID', '4fbea328b9ff11e0a5f833b5d7c45677'), ('TOKENENTITYKEY', '4fbea328b9ff11e0a5f833b5d7c45677: TOKEN: 761 :1'), (BASETYPE', 'MODEL_003_001_00'), ('STATUS', 'ACTIVE'), ('ISSUEDDATE', None), ('WEIGHT', '761'), ('CATEGORY', '1'), ('DOUBLELINKED', None), ('UUID', '68aaca40b9ff11 e0ac799fd4e415d9de')]), OrderedDict ([('ISACTIVE', 'True'), ('BASEUUID', '4fbea328b9ff11e0a5f833b5d7c45677'), ('TOKENENTITYKEY', '4fbea328b9ff11e0a5f833b5d7c45677:TOKEN: 637:2'), (BASETYPE)', 'MODEL_003_001_00'), ('STATUS', 'ACTIVE'), ('ISSUEDDATE', None), ('WEIGHT '637'), ('CATEGORY', '2'), ('DOUBLELINKED', None), ('UUID', '6b6dlc38b9ff11e08cel0dc270e3ea06')]), OrderedDict ([('ISACTIVE', 'True'), ('BASEUUID', '4 fbea328b9ff11e0a5f833b5d7c45677'), ('TOKENENTITYKEY', '4fbea328b9ff1 le0a5f833b5d7c45677: TOKEN: 444: 3'), ('BASETYPE)', 'MODEL_003_001_00'), ('STATUS', 'ACTIVE'), ('ISSUEDDATE', None), ('WEIGHT '444'), ('CATEGORY', '3'), ('DOUBLELINKED', None), ('UUID', '6342aa53b9ff11 e0bcdb9fd4e415d9de')]), OrderedDict ([{'ISACTIVE', 'True'), ('BASEUUID', '4fbea328b9ff11e0a5f833b5d7c45677'), ('TOKENENTITYKEY', '4fbea328b9ff11e0a5f833b5d7c45677: TOKEN: 333: 4'), ('BASETYPE'), 'MODEL_003_001_00'), ('STATUS', 'ACTIVE'), ('ISSUEDDATE', None), ('WEIGHT '333'), ('CATEGORY', '4'), ('DOUBLELINKED', None), ('UUID', '62bd26a2b9ff 11 e0bc239fd4e415d9de')]), OrderedDict ([ (' 1SACTIVE', 'True'), ('BASEUUID', '4fbea328b9ff11e0a5f833b5d7c45677'), ('TOKENENTITYKEY', '4fbea328b9ff11 e0a5f833b5d7c45677: TOKEN: 307: 5'), ('BASETYPE'), 'MODEL_003_001_00'), ('STATUS', 'ACTIVE'), ('ISSUEDDATE', None), ('WEIGHT
'307'), ('CATEGORY', '5'), ('DOUBLELINKED', None), ('UUID', '6b6dlc39b9ff11e0986c0dc270e3ea06')]), OrderedDict ([('ISACTIVE', 'True'), ('BASEUU 1D', '4fbea32db9ff 11 e09f3e33b5d7 c45677'), ('TOKENENTITYKEY', '4fbea32db9ff11 e09f3e33b5d7c45677: TOKEN: 801: Spend'), ('BASETYPE'), 5 'MODEL_008_001_00'), ('STATUS', 'ACTIVE'), ('ISSUEDDATE', None), ('WEIGHT '801'), ('CATEGORY', 'Spend'), ('DOUBLELINKED', None), ('UUID', '6b6dlc3ab9ff11e0a4ec0dc270e3ea06')]), OrderedDict ([('ISACTIVE', 'True'), ('BASEUUID', '4 fbea32eb9ff11 e0b55133b5d7 c45677'), ('TOKENENTITYKEY', '4fbea32eb9ff11 e0b55133b5d7 c45677: TOKEN: 1:Volume'), ('BASETYPE', 'MODEL_009_001_00'), ('STATUS', 'ACTIVE'), ('ISSUEDDATE', None), ('WEIGHT' '1'), ('CATEGORY', 'Volume'), ('DOUBLELINKED', None), ('UUID', '62a09df3b9ff11 e090d79fd4e415d9de')])] Found a direct match 148:181:75:1:2 -- Failed to find a direct match -- Try again with only IP address and hour [OrderedDict ([('ISACTIVE', 'True'), ('ENTITYKEY', '148:181:75:1:1'), ('XML', None), ('AFFINITYGROUPNAME', '148:181:75:1:1'), ('DESCRIPTION', None), ('TYPEOF', None)])] -- Found match for case 2
-------------------Temporary model rules-------------------
{1: {'LOWER': 10, 'BASETYPE': ['MODEL_002_001_00', 'MODEL_003_001_00'], 'attribute':'WEIGHT', 'rule':'NEAR', '(Omicron][Rho]':'PROX', 'type':'TOKENENTITY' 'HIGHER': 10}, 2: {'type': ('MERCHANT'], 'rule':'FOLLOW'}, 3: {'rule': 'RESTRICTSUBTYPE', 'BASETYPE'['MODEL_002_001_00', 'MODEL_003_001_00']}}
------------------ Temporary Model Output----------------- ------------------------For Use Case 1 ---------------------
-- Number of Nodes: 102
- - - - - - -LIVRARIASICILIAN --------~GDPCOLT
------------º _ _ _ _ _GOODWILLINDUSTRIES
DISCOUNTDE BARELANCHOE BLOOMINGDALES
PARCWORLDTENNIS 5 STRIDERITEOUTLET
PARCCEANOR PONTO FRIO FNACPAULISTA FINISHLINE
WALMARTCENTRAL ESNllNTERLARGOS
PARCLOJASCOLOMBO BEDBATHBEYOND MACYSWEST PARCRIACHUELOFILIAL JCPENHEYCORPINC PARCLOJASRENNERFL PARCPAQUETAESPORTES MARISALJ PARCLEADERMAGAZINE INTERFLORA DECATHLON PERNAMBUCANASFL KARSTADTDE PARCCEAMCO CHAMPS ACCESSORIZE BLOOMINGDALESDVRS PARCLIVRARIACULTURA PARCCEALOJA ARQUIBANCADA KITBAG FREDERICKSOFHLWD WALMART PARCLOJASINSINUANTE WALMARTCOMTAGEM FOOTLOCKER PARCSANTALOLLA RICARDOELETRO PARCPONTOFRIO
DOTPAYPLPOLSKA 5 CAMICADO
KARSTADT PARCRAMSOS PARCGREGORY GREMIOFBPA WALMARTSJC PRODIRECTSOCCERLTO LAVIEENROSE PARCMARISALJ ORDERS PARCNSNWATALNORTE LOJASINSINUANTE B CITYCOUNTY WALMARTPACAEMBU SOHO
WALMARTOSASCO FOSSILSTORESllNC
MENARDSCLIO PARCPEQUENTE BEALLS THEHOMEDEPOT VIAMIA FARCLOJASRIACHUELO PARCLOJASMILANO NORDSTROM WAI LANACOFFEEHOUSE LANCHOEBELLA PUKET WALMARTSTORESINC PARCPERNAMBUCANASFL SMARTSHOPPER PARCMAGAZIHELUIZASP _ _ _COLUMBIASPORTSWEARCO
- - - - - -BARELANCESTADA _ _ _ _ _ _ _ _ DONATEEBAY _ _ _ _ _ PARCRICARDOELETRO 5 - - - - - - -PARCDISANTINNI _ _ _ _ _ _ _ _SCHUHCOUK _ _ _ _ _ _ _ _ _ _CEANOR
- - - - - - -PARCCAMICADO _ _ _ _ _ _ PARCCENTAUROCE _ _ _ _ _ _ PARCMARLUIJOIAS _ _ _ _ _ _ _ ___..ALBADAH _ _ _ _ _ _ _ _ _MARTINEZ _ _ _ _ _ MONEYBOOKERSLTD _ _ _ _ _ _ _ _ _ _MACYS _ _ _ _ _ _ PARCRIOCENTER _ _ _ _ _ _ PARCCASASBAHIA _ _ _ _ _ PARCSUBMARINOLOJA _ _ _ _ _ _ _ _ _ _ _ INC _ _ _ _ _ _ SUBMARINOLOJA _ _ _ _ _ _ _ LOJASRENNERFL - - - - - - -RIACHUELOFI LIAL - - - - -PARCSONHODOSPES _ _ _ _ _ _ _ _ _ PINKBIJU _ _ _ _ _ _ _ _ PARCCEAMRB
-------------------- Temporary Model Output--------------- -------------------------For Use Case 2 -------------------
-- Number of Nodes: 3 _ _ _ _ _ _ _ _ _ _ KITBAG
_ _ _ COLUMBIASPORTSWEARCO - - - - - - - -GREMIOFBPA
End of Example Use Case
Em algumas modalidades, o UEP pode fornecer acesso a informações em uma base sigilosa para garantir a segurança de dados de entidades onde o UEP armazena informações.
Assim, em algumas modalidades, o acesso a informações da plataforma centralizada pode ser restrito com base no originador bem como serviços de aplicação para 5 os quais os dados são solicitados.
Em algumas modalidades, o UEP pode então permitir que uma variedade de serviços de aplicação flexíveis seja construída em uma infraestrutura de banco de dados comum, enquanto preserva a integridade, segurança, e precisão de dados de entidade.
Em algumas implementações, o UEP pode gerar, atualizar, manter, armazenar e/ou fornecer informações de perfil sobre entidades, bem como um gráfico social 1O que mantém e atualiza inter-relações entre cada entidade armazenada dentro do UEP.
Por exemplo, o UEP pode armazenar informações de perfil em um banco emissor 1802a (veja o perfil 1803a), um banco adquirente 1802b (veja o perfil 1803b), um consumidor 1802c (veja o perfil 1803c), um usuário 1802d (veja o perfil 1803d), um comerciante 1802e (veja o perfil i8o3e), um segundo comerciante 1802f (veja o perfil 1803f). O UEP também pode armazenar relações entre essas entidades.
Por exemplo, o UEP pode armazenar informações sobre uma relação do banco emissor 1802a para o consumidor 1802c que compra no comerciante i802e, que por sua vez pode estar relacionado ao usuário 1802d, que pode realizar o depósito 1802b que serve como o adquirente do comerciante 1802f.
As Figuras 19A-F show diagrama de blocos que ilustra os aspectos exemplificativos de modelos de dados dentro de uma plataforma de informações pessoais centralizada em algumas modalidades do UEP.
Em várias modalidades, o UEP pode armazenar uma variedade de atributos de entidades de acordo com vários modelos de dados.
Alguns modelos de dados exemplificativos não limitativos são fornecidos abaixo.
Em algumas modalidades, o UEP pode armazenar atributos de perfil de usuário.
Por exemplo, um modelo de perfil de usuário pode armazenar informações de identificação de usuário 1901, pseudônimos do usuário 1902, endereços de e-mail 1903, números de telefone 1904, endereços 1905, tipos de endereço de e-mail 1906, tipos de endereço 1907, tipos de pseudônimos do usuário 1908, status de notificação 1909, ISO de país 191 O, tipos de números de telefone 1911, informações de contrato com o UEP 1912, status de autorização de usuário 1913, status de perfil de usuário 1914, resposta de segurança 1915, perguntas de segurança 1916, idioma 1917, fuso horário 1918, e/ou similares, cada um dos tipos de campo acima incluem um ou mais campos e valores de campo.
Como outro exemplo, um modelo de atributos financeiros de usuário pode armazenar informações de identificação de usuário 1920, informações de conta financeira de usuário 1921, informações de contrato de conta 1922, função de conta financeira de usuário 1923, tipo de conta financeira 1924, informações de identificação de conta financeira 1925, informações de contrato 1926, validação de conta financeira 1927, tipo de validação de conta financeira 1928, e/ou similares. Como outro exemplo, um modelo de dados de atributos de cartão de pagamento de usuário pode incluir tipos de campo como, porém sem caráter limitativo: informações de identificação de usuário 1930, informações de conta financeira de usuário 1931, função de conta financeira de usuário 1932, aplicativos para consumidor de conta 1933, aplicativo de 5 consumo de usuário 1934, tipo de conta financeira1935, tipo de validação de conta financeira 1936, informações de conta financeira 1937, informações de aplicativo de consumidor 1938, informações de provedor de aplicativo de consumidor 1939, e/ou similares. Como outro exemplo, um modelo de dados de atributos de serviços de usuário pode incluir tipos de campos como, porém sem caráter limitativo: informações de 1O identificação de usuário 1940, pseudônimo de usuário 1941, status de pseudônimo de usuário de aplicativo de consumidor 1942, status de pseudônimo de usuário 1943, código do motivo de mudança de status 1944, contrato de usuário 1945, informações de contrato 1946, valor de atributo de serviço de usuário 1947, atributos de aplicativo de consumidor 1948, valor de atributo de serviço de conta, contrato de conta 1950, status de perfil de usuário 1951, função de negócios de contrato 1952, negócios de contrato 1953, informações de cliente 1954, função de contrato 1955, aplicativo de consumidor 1956, auditoria de atividade de usuário 1957, resultados de conexão 1958, e/ou similares. Como outro exemplo, um modelo de atributos de uso de serviços de usuário pode incluir tipos de campos como, porém sem caráter limitativo: informações de identificação de usuário i960, pseudônimo de usuário 1961, status de pseudônimo de usuário de aplicativo de consumidor 1962, código de motivo de mudança de status 1963, status de pseudônimo de usuário 1964, aplicativo de consumo de usuário 1965, auditoria de conexão de usuário 1966, resultado de conexão 1967, valor de atributo de serviço de conta 1968, aplicativo de consumidor de conta 1969, aplicativo de consumidor 1970, provedor de aplicativo de consumidor 1971, resultado de conexão 1972, e/ou similares. Como outro exemplo, um modelo de dados de atributos gráficos de usuário pode incluir tipos de campo como, porém sem caráter limitativo: informações de identificação de usuário 1980, contato de usuário 1981 , status de pseudônimo de usuário de aplicativo de consumidor 1982, relação 1983, e/ou similares. Em algumas modalidades, o UEP pode armazenar cada objeto (por exemplo, usuário, comerciante, emissor, adquirente, endereço IP, agregado, etc.) como um nó em banco de dados gráficos, e armazenar dados em relação a cada nó em um formato como o formato exemplificativo fornecido abaixo: **<Nodes Data> ID, Nodes, Label 2fdc7e3fb1 c11 e0be645528b00e8d0e, 2 fdc7e3fbdlc11e0be645528b00e8d0e,
AFFINITYGROUP
NAME: 49:95:0:3:1 32b 1d53ebd1 c11 e094172557fb829fdf, 32b 1d53ebd1 c11 e094172557fb829fdf,
TOKENENTITYKE Y:2b8494f0bd1c11e09c856d888c43f7c2: TOKEN:O:F 5 2e6381e4bd1c11e0b9ffc929a54bb0fd, 2e6381e4bd1c11e0b9ffc929a54bb0fd, MERCHANTNAME: _ _ _ _ _ _ MERCHANT_ABC 2fdc7e3dbd1c11e0a22d5528b00e8d0e, 2fdc7e3dbd1 c11 e0a22d5528b00e8d0e,
AFFINITYGROUP NAME: 49: 95: O: 1: 1 2e6381e7bd1c11e091b7c929a54bb0fd, 2e6381e7bd1c11e091b7c929a54bb0fd, MERCHANTNAME: _ _ _ _ _ _ MERCHANT_XYZ 2cf8cbabbd1c11e0894a5de4f9281135, 2cf8cbabbd1c11e0894a5de4f9281135, USERNAME:OOOO 60FF6557F103 2e6381debd1c11e0b336c929a54bb0fd, 2e6381debd1c11e0b336c929a54bb0fd, MERCHANTNAME: _ _ _ _ _ _MERCHANT_ 123 2e6381e0bd1c11e0b4e8c929a54bb0fd, 2e6381eObd1e1 le0b4e8c929a54bb0fd, MERCHANTNAME: ~~~~~~·MERCHANT_FGH 2cf681 c1 bd1 c11e0b8815de4f9281135, 2cf681 c1bd1 c11 e0b8815de4f9281135, USERNAME:OOOO 30C57080FFE8 2b8494flbd 1c11 e0acbd6d888c43f7 c2, 2b8494flbd 1c11 e0acbd6d888c43f7 c2, MODELNAME:MOD EL_003_001_00 32b44638bd 1c11eObO1 c2557fb829fdf, 32b44638bd1 c11 e0b01 c2557fb829fdf,
TOKENENTITYKE Y:2b8494f1 bd1c11e0acbd6d888c43f7c2: TOKEN:1000:1 2fdc7e40bd1c11e094675528b00e8d0e, 2fdc7e40bd1c11e094675528b00e8d0e,
AFFINITYGROUP NAME:49:95:0:4:1 2b8494f0bd 1c11 e09c856d888c43f7 c2, 2b8494f0bd1 c11 e09c856d888c43f7c2, MODELNAME: MOO E1_002_001_00
32b44639bd1c11e0b15b2557fb829fdf, 32b44639bd1c11e0b1 5b2557 fb829fdf,
TOKENENTITYKE Y:2b8494f1 bd1c11e0acbd6d888c43f7c2: TOKEN:0:2 32ce84febd1 c11 e0b0112557fb829fdf, 32ce84febd 1c11 e0b0112557fb829fdf, 5 TOKENENTITYKE Y:2b8494f1 bd1 c11e0acbd6d888c43f7c2:TOKEN:1000:4 2e6381 e3bd1 c11 e095b1 c929a54bb0fd, 2e6381e3bd1c11e095b1c929a54bb0fd, MERCHANTNAME: _ _ _ _ _ _ MERCHANT_789 34582a87bd1c11e080820167449bc60f, 34582a87bd 1e11e080820167449bc60f,
TOKENENTITYKE Y:2b8494f1 bd1 c11 e0acbd6d888c43f7c2:TOKEN:778:5 2e6381e5bd1c11e0b62cc929a54bb0fd, 2e6381e5bd1 c1 le0b62cc929a54bb0fd, MERCHANTNAME: _ _ _ _ _ _ MERCHANT_ 456 2fdc7e3ebd1c11e088b55528b00e8d0e, 2fdc7e3ebd1c11e088b55528b00e8d0e,
AFFINITYGROUP NAME: 49:95:0:2: 1 32c4e80dbd 1c11 e09e442557fb829fdf, 32c4e80dbd 1c11 e09e442557 fb829fdf,
TOKENENTITYKE Y:2b8494f1bd1 c11 e0acbd6d888c43f7c2: TOKEN:77 4:5 2e6381e1 bd 1e11 e0bf28c929a54bb0fd, 2e6381 e1 bd1 c11 e0bf28c929a54bb0fd, MERCHANTNAME: _ _ _ _ _ _ MERCHANT_WER 2cf681 b8bd1 c11e08be85de4f9281135, 2cf681 b8bd1c11e08be85de4f9281135, USERNAME:OOOO 2552FC930FF8 2cf8cba8bd1c11e09fbc5de4f9281135, 2cf8cba8bd1c11e09fbc5de4f9281135, USERNAME:OOOO 570FF1846A24 32b4463abd 1c11 e0bdaa2557fb829fdf, 32b4463abd 1c11 e0bdaa2557fb829fdf,
TOKENENTITYKE Y:2b8494f1bd1 c11 e0acbd6d888c43f7c2: TOKEN:0:3 2cf8cbaebd1c11e0b6515de4f9281135, 2cf8cbaebd1c11e0b6515de4f9281135, USERNAME:OOOO 64A20FF962D4
2e6381e6bd1c11e08087c929a54bb0fd, 2e6381e6bd1c11e08087c929a54bb0fd, MERCHANTNAME: _ _ _ _ _ _ MERCHANT_ 496 2e6381e2bd1c11e0941dc929a54bb0fd, 2e6381e2bd1c11e0941dc929a54bb0fd, 5 MERCHANTNAME: _ _ _ _ _ _ MERCHANT_SDF <Edge Data>Source, Target, Type, 1abe1, Weight 32ce84febd1c11e0b0112557fb829fdf, 2e6381e6bd1c11e08087c929a54bb0fd, MODEL_003_001 _00, 2b8494f1bd1c11e0acbd6d888c43f7c2: TOKEN:1000:4, 1000 2fdc7e3ebd1c11e088b55528b00e8d0e, 32ce84febd 1c11 e0b0112557fb829fdf, MODEL_003_001 _00, 2b8494f1bd1c11e0acbd6d888c43f7c2: TOKEN:1000:4, 1000 2e6381e2bd1c11e0941dc929a54bb0fd, 34582a87bd1 c11e080820167449bc60f, MODEL_003_001 _00, 2b8494f1 bd1 c11 e0acbd6d888c43f7c2: TOKEN:778:5, 778 2b8494flbd 1c11 e0acbd6d888c43f7 c2, 34582a87bd 1c11e080820167449bc60f, MODEL_003_001 _00, 2b8494 f1 bd1 11e0acbd6d888c43f7c2: TOKEN:778:5, 778 2e6381e1bd1c11e0bf28c929a54bb0fd, 32b44639bd1c11e0b15b2557fb829fdf, MODEL_003_001 _00, 2b8494f1 bd1 c11 e0acbd6d888c43f7c2: TOKEN:0:2, O 2e6381eObd1 c11 e0b4e8c929a54bb0fd, 32ce84 febd 1c11eObO112557fb829fdf, MODEL_003_001 _00, 2b8494f1bd1c11e0acbd6d888c43f7c2: TOKEN:1000:4, 1000 32b44639bd 1c11eOb15b2557fb829fdf, 2e6381e6bd1c11e08087c929a54bb0fd, MODEL_003_001 _00, 2b8494f1bd1c11e0acbd6d888c43f7c2: TOKEN:0:2, O 2e6381e1 bd1 c11 e0bf28c929a54bb0fd, 32ce84febd1c11e0b0112557fb829fdf, MODEL_003_001 _ 00, 2b8494f1bd1 c11 e0acbd6d888c43f7 c2: TOKEN: 1000:4, 1000 2e6381debd1 c11 e0b336c929a54bb0fd, 32ce84 febd 1c11 e0b0112557fb829fdf, MODEL_003_001 _00, 2b8494f1bd1c11e0acbd6d888c43f7c2: TOKEN:1000:4, 1000 2e6381e3bd1 c11e095b1 c929a54bb0fd, 34582a87bd 1c11e080820167449bc60f, MODEL_003_001 _00, 2b8494f1bd1c11e0acbd6d888c43f7c2: TOKEN:778:5, 778
2fdc7e40bd1 c11 e094675528b00e8d0e, 32b44639bd1 c11e0b15b2557fb829fdf, MODEL_003_001 _00, 2b8494f1bd1c11e0acbd6d888c43f7c2: TOKEN:0:2, O 2b8494f1bd1 c11 e0acbd6d888c43f7 c2, 32b4463abd 1c11 e0bdaa2557fb829fdf, 5 MODEL_003_001 _00, 2b8494f1 bd1c11e0acbd6d888c43f7c2:TOKEN:0:3, O 2e6381e3bd1c11e095b1c929a54bb0fd, 32b4463abd 1c11 e0bdaa2557fb829fdf, MODEL_003_001 _00, 2b8494f1bd1c11e0acbd6d888c43f7c2: TOKEN:0:3, O 2e6381e3bd1c11e095b1c929a54bb0fd, 32b1d53ebd1c11e094172557 fb829fdf, MODEL_002_001 _00, 2b8494f0bd1 c11 e09c856d888c43f7c2: TOKEN:O:F, O 2e6381e5bd1c11e0b62cc929a54bb0fd, 34582a87bd1 c11 e080820167449bc60f, MODEL_003_001 _00, 2b8494f1bd1c11e0acbd6d888c43f7c2: TOKEN:778:5, 778 2cf8cbabbd1 c11 e0894a5de4f9281135, 32b44638bd 1c11 e0b01 c2557fb829fdf, MODEL_003_001 _00, 2b8494f1bd1c11e0acbd6d888c43f7c2: TOKEN:1000:1, 1000 2cf681b8bd1 c11 e08be85de4f9281135, 32b 1d53ebd1 c11 e094172557fb829fdf, MODEL_002_001 _00, 2b8494f0bd1c11e09c856d888c43f7c2: TOKEN:O:F, O 32b4463abd1 c11 e0bdaa2557fb829fdf, 2e6381e6bd1c11e08087c929a54bb0fd, MODEL_003_001 _00, 2b8494f1bd1c11e0acbd6d888c43f7c2: TOKEN:0:3, O 2e6381debd1c11e0b336c929a54bb0fd, 32b44639bd1c11e0b15b2557fb829fdf, MODEL_003_001 _00, 2b8494f1 bd1c11e0acbd6d888c43f7c2: TOKEN:0:2, O 2e6381e1bd1 c11 e0bf28c929a54bb0fd, 32b44638bd 1c11eObO1 c2557fb829fdf, MODEL_003_001 _00, 2b8494f1bd1c11e0acbd6d888c43f7c2: TOKEN:1000:1, 1000 2e6381e5bd1 c11 e0b62cc929a54bb0fd, 32ce84 febd 1c11eObO112557fb829fdf, MODEL_003_001 _00, 2b8494f1 bd1c11e0acbd6d888c43f7c2: TOKEN:1000:4, 1000 2e6381e1bd1 c11 e0bf28c929a54bb0fd, 32b4463abd 1c11 e0bdaa2557fb829fdf, MODEL_003_001 _00, 2b8494f1bd1 c11 e0acbd6d888c43f7 c2: TOKEN:0:3, O
2e6381e2bd1c11e0941dc929a54bb0fd, 32b44639bd 1c11eOb15b2557fb829fdf, MODEL_003_001 _00, 2b8494f1 bd1 c11 e0acbd6d888c43f7c2: TOKEN:0:2, O 2b8494f1bd1 c11 e0acbd6d888c43f7 c2, 32c4e80dbd 1c11 e09e442557fb829fdf, 5 MODEL_003_001 _00, 2b8494f1bd1c11e0acbd6d888c43f7c2: TOKEN:774:5, 774 2e6381e2bd1 c11 e0941 dc929a54bb0fd, 32b 1d53ebd1 c11 e094172557fb829fdf, MODEL_002_001 _00, 2b8494f0bd1c11e09c856d888c43f7c2: TOKEN:O:F, O 2e6381e4bd1c11e0b9ffc929a54bb0fd, 32b4463abd1c11e0bdaa2557fb829~~
MODEL_003_001 _00, 2b8494f1bd1c11e0acbd6d888c43f7c2: TOKEN:0:3, O 2fdc7e3fbd1 c11 e0be645528b00e8d0e, 32b4463abd1 c11 e0bdaa2557fb829fdf, MODEL_003_001 _00, 2b8494f1bd1c11e0acbd6d888c43f7c2: TOKEN:0:3, O 2e6381e1bd1 c11 e0bf28c929a54bb0fd, 32b1 d53ebd1 c11 e094172557fb829fdf, MODEL_002_001 _00, 2b8494f0bd1c11e09c856d888c43f7c2: TOKEN:O:F, O 2fdc7e40bd 1c11 e094675528b00e8d0e, 32ce84 febd 1c11 e0b0112557fb829fdf, MODEL_003_001 _00, 2b8494f1 bd1 c11 e0acbd6d888c43f7c2: TOKEN: 1000:4, 1000 2cf8cba8bd 1c11 e09fbc5de4f9281135, 32c4e80dbd 1c11 e09e442557fb829fdf, MODEL_003_001 _00, 2b8494f1bd1c11e0acbd6d888c43f7c2: TOKEN:774:5, 774 2e6381e2bd1c11e0941dc929a54bb0fd, 32b44638bd 1c11 e0b01 c2557fb829fdf, MODEL_003_001 _00, 2b8494f1bd1c11e0acbd6d888c43f7c2: TOKEN:1000:1, 1000 2e6381e4bd1 c11 e0b9ffc929a54bb0fd, 32b 1d53ebd1 c11 e094172557fb829fdf, MODEL_002_001 _00, 2b8494f0bd1c11e09c856d888c43f7c2: TOKEN:O:F, O 2e6381e5bd1c11e0b62cc929a54bb0fd, 32b44639bd 1c11eOb15b2557fb829fdf, MODEL_003_001 _00, 2b8494f1 bd1 c11 e0acbd6d888c43f7c2: TOKEN:0:2, O 32b 1d53ebd 1c11 e094172557fb829fdf, 2e6381e6bd1c11e08087c929a54bb0fd, MODEL_002_001 _00, 2b8494f0bd1 c11 e09c856d888c43f7c2: TOKEN:O:F, O
2b8494f1 bd1 c11 e0acbd6d888c43f7c2, 32b44639bd1 c11e0b15b2557fb829fdf, MODEL_003_001 _00, 2b8494f1 bd1 c11 e0acbd6d888c43f7c2: TOKEN: 0:2, O 2e6381e3bd1c11e095b1c929a54bb0fd, 32b44638bd 1c11 e0b01 c2557fb829fdf, 5 MODEL_003_001 _00, 2b8494f1 bd1 c11 e0acbd6d888c43f7c2: TOKEN: 1000: 1, 1000 2fdc7e3dbd1c11e0a22d5528b00e8d0e, 32ce84 febd1c11e0b0112557fb829fdf, MODEL_003_001 _00, 2b8494f1bd1c11e0acbd6d888c43f7c2: TOKEN:1000:4, 1000 1O 2cf681 c1 bd1 c11e0b8815de4f9281135, 32b44638bd1 c11e0b01 c2557fb829fdf, MODEL_003_001 _00, 2b8494f1bd1c11e0acbd6d888c43f7c2: TOKEN:1000:1, 1000 2cf 681 c1 bd1 c11e0b8815de4f 9281135, 32b1d53ebd1 c11e094172557fb829fdf, MODEL_002_001 _00, 2b8494f0bd1c11e09c856d888c43f7c2: TOKEN:O:F, O 2e6381e3bd1 c11e095b1 c929a54bb0fd, 32b44639bd 1c11e0b15b2557fb829fdf, MODEL_003_001 _00, 2b8494 f1 bd1c11e0acbd6d888c43f7c2: TOKEN:0:2, O 2fdc7e3fbd1c11e0be645528b00e8d0e, 32b 1d53ebd1 c11 e094172557fb829fdf, MODEL_002_001 _00, 2b8494 f0bd1 c1 1e0 9c856d888c43f7c2: TOKEN:O:F, O 32b44638bd 1c11 e0b01 c2557fb829fdf, 2e6381e6bd1 c11 e08087 c929a54bb0fd, MODEL_003_001 _00, 2b8494f1bd1c11e0acbd6d888c43f7c2: TOKEN:1000:1, 1000 2cf8cbaebd 1c11 e0b6515de4f9281135, 32ce84febd 1c11 e0b0112557fb829fdf, MODEL_003_001 _00, 2b8494f1 bd1 c11 e0acbd6d888c43f7c2: TOKEN: 000:4, 1000 2e6381e6bd1 c11 e08087 c929a54bb0fd, 32b 1d53ebd1 c11 e094172557fb829fdf, MODEL_002_001 _00, 2b8494f0bd1c11e09c856d888c43f7c2: TOKEN:O:F, O 2e6381e7bd1c11e091b7c929a54bb0fd, 34582a87bd 1c11e080820167 449bc60f, MODEL_003_001 _00, 2b8494f1 bd1 c11 e0acbd6d888c43f7c2: TOKEN:778:5, 778 2e6381 e1 bd1 c11 e0bf28c929a54bb0fd, 34582a87bd 1c11e080820167449bc60f, MODEL_003_001 _00, 2b8494f1 bd1 c11 e0acbd6d888c43f7c2: TOKEN:778:5, 778
2e6381e5bd1c11e0b62cc929a54bb0fd, 32b 1d53ebd1 c11 e094172557fb829fdf, MODEL_002_001 _00, 2b8494f0bd1c11e09c856d888c43f7c2: TOKEN:O:F, O 2b8494f0bd 1c11 e09c856d888c43f7 c2, 32b 1d53ebd1 c11 e094172557fb829fdf, 5 MODEL_002_001 _00, 2b8494f0bd1c11e09c856d888c43f7c2: TOKEN:O:F, O 2b8494fl bd 1c11 e0acbd6d888c43f7 c2, 32b44638bd 1c11eObO1 c2557fb829fdf, MODEL_003_001 _00, 2b8494f1bd1c11e0acbd6d888c43f7c2: TOKEN:1000:1, 1000 2e6381e6bd1c11e08087c929a54bb0fd, 32b4463abd 1c11 e0bdaa2557fb829fdf, MODEL_003_001 _00, 2b8494f1 bd1 c11 e0acbd6d888c43f7c2: TOKEN: 0:3, O 2b8494f1bd1 c11 e0acbd6d888c43f7 c2, 32ce84febd 1c11 e0b0112557fb829fdf, MODEL_003_001 _00, 2b8494f1bd1c11e0acbd6d888c43f7c2: TOKEN:1000:4, 1000 2cf681 c1 bd1 c11e0b8815de4f 9281135, 32b44639bd1 c11e0b1 5b2557 fb829fdf, MODEL_003_001 _00, 2b8494f1 bd1c11e0acbd6d888c43f7c2: TOKEN:0:2, O 2cf681 c1 bd1c11e0b8815de4f9281135, 32b4463abd 1c11 e0bdaa2557fb829fdf, MODEL_003_001 _00, 2b8494f1bd1c11e0acbd6d888c43f7c2: TOKEN:0:3, O 2e6381e2bd1 c11 e0941 dc929a54bb0fd, 32b4463abd 1c11 e0bdaa2557fb829fdf, MODEL_003_001 _00, 2b8494f1 bd1 c11 e0acbd6d888c43f7c2: TOKEN:0:3, O 2e6381e3bd1c11e095b1c929a54bb0fd, 32ce84febd 1c11eObO112557fb829fdf, MODEL_003_001 _00, 2b8494f1 bd1 c11 e0acbd6d888c43f7 c2: TOKEN: 1000:4, 1000 2e6381e6bd1c11e08087c929a54bb0fd, 32ce84febd 1c11eObO112557fb829fdf, MODEL_003_001 _00, 2b8494f1bd1 c11 e0acbd6d888c43f7 c2: TOKEN: 1000:4, 1000 2e6381e6bd1 c11 e08087 c929a54bb0fd, 34582a87bd 1c11e080820167 449bc60f, MODEL_003_001 _00, 2b8494f1bd1c11e0acbd6d888c43f7c2: TOKEN:778:5, 778 2e6381e6bd1c11e08087c929a54bb0fd, 32b44638bd 1c11 e0b01 c2557fb829fdf, MODEL_003_001 _00, 2b8494f1bd1c11e0acbd6d888c43f7c2: TOKEN:1000:1, 1000
2fdc7e3ebd1c11e088b55528b00e8d0e, 32b44639bd 1e11eOb15b2557fb829fdf, MODEL_003_001 _00, 2b8494f1 bd1 c11 e0acbd6d888c43f7c2: TOKEN:0:2, O 2e6381e5bd1c11e0b62cc929a54bb0fd, 32b4463abd 1c11 e0bdaa2557fb829fdf, 5 MODEL_003_001 _00, 2b8494f1 bd1 c11 e0acbd6d888c43f7c2: TOKEN:0:3, O 2e6381e4bd1 c11 e0b9ffc929a54bb0fd, 34582a87bd 1c11e080820167 449bc60f, MODEL_003_001 _00, 2b8494f1bd1c11e0acbd6d888c43f7c2: TOKEN: 778:5, 778 1O 2e6381e4bd1 c11 e0b9ffc929a54bb0fd, 32b44638bd 1e11 eObO 1c2557fb829fdf, MODEL_003_001 _00, 2b8494f1bd1c11e0acbd6d888c43f7c2: TOKEN:1000:1, 1000 34582a87bd1c11e080820167449bc60f, 2e6381e6bd1c11e08087c929a54bb0fd, MODEL_003_001 _00, 2b8494f1 bd1 c11 e0acbd6d888c43f7c2:TOKEN:778:5, 778 2e6381e6bd1 c11 e08087 c929a54bb0fd, 32b44639bd 1c11eOb15b2557fb829fdf, MODEL_003_001 _00, 2b8494f1 bd1c11e0acbd6d888c43f7c2: TOKEN:0:2, O 2e6381e5bd1c11e0b62cc929a54bb0fd, 32b44638bd1 c11 e0b01 c2557fb829fdf, MODEL_003_001 _00, 2b8494f1bd1c11e0acbd6d888c43f7c2: TOKEN:1000:1, 1000 2fdc7e3fbd1 c11 e0be645528b00e8d0e, 32b44638bd 1c11 e0b01 c2557fb829fdf, MODEL_003_001 _00, 2b8494f1bd1 c11 e0acbd6d888c43f7 c2: TOKEN: 1000: 1, 1000 2cf681 b8bd1 c11 e08be85de4f9281135, 32b44639bd1 c11e0b15b2557fb829fdf, MODEL_003_001 _00, 2b8494f1 bd1c11e0acbd6d888c43f7c2: TOKEN:0:2, O 2e6381e4bd1 e11 e0b9ffc929a54bb0fd, 32b44639bd 1c11e0b15b2557fb829fdf, MODEL_003_001 _00, 2b8494f1 bd1 c11 e0acbd6d888c43f7c2: TOKEN:0:2, O 2cf681 b8bd1 c11 e08be85de4f9281135, 32b4463abd1c11e0bdaa2557fb829~~
MODEL_003_001 _00, 2b8494f1 bd1c11e0acbd6d888c43f7c2: TOKEN: 0:3, O 2e6381e4bd1c11e0b9ffc929a54bb0fd, 32ce84febd 1c11 e0b0112557fb829fdf, MODEL_003_001 _ 00, 2b8494f1bd1 c11 e0acbd6d888c43f7 c2: TOKEN: 1000:4, 1000
2e6381e2bd1c11e0941dc929a54bb0fd, 32ce84febd 1c11eObO112557fb829fdf, MODEL_003_001 _00, 2b8494f1bd1c11e0acbd6d888c43f7c2: TOKEN:1000:4, 1000 2fdc 7e3dbd1 c11 e0a22d5528b00e8d0e, 32b44639bd 1c11eOb15b2557fb829fdf, 5 MODEL_003_001 _00, 2b8494f1 bd1 c11 e0acbd6d888c43f7c2: TOKEN:0:2, O 2cf681 b8bd1 c11e08be85de4f9281135, 32b44638bd1 c11 e0b01 c2557fb829fdf, MODEL_003_001 _00, 2b8494f1bd1c11e0acbd6d888c43f7c2: TOKEN: 1000:1, 1000 1O Em exemplos alternativos, o UEP pode armazenar dados em um formato *JavaScript Object Notation ("JSON"). As informações armazenadas podem incluir dados referentes ao objeto, como, porém sem caráter limitativo: comandos, atributos, informações de grupo, informações de pagamento, informações de conta, etc., como no exemplo abaixo: {'MERCHANT': {'TYPEOFTYPES': ['MERCHANTS', 'SYNTHETICNETWORKS'], 'FUNCTIONS': {'ENTITYCREATION':'putNetwork'} , 'UNIQUEATTIBUTES': ['MERCHANTNAME'], 'TOKENENTITIESRELATIONSHIPS': [ ], 'ATTRIBUTES': {'MERCHANT': (2, 'STRING', O, 'VALUE'), 'MERCH_ZIP_CD': (7, 'STRING', O, 'VALUE'), 'MERCH_NAME': (8, 'STRING', O, 'VALUE'), 'MERCHANTNAME': (3, 'STRING', O, 'VALUE'), 'ACQ_CTRY_NUM': (4, 'STRING', O, 'VALUE'), 'ACQ_PCR': (6, 'STRING', O, 'VALUE'), 'ACQ_REGION_NUM': (5, 'STRING', O, 'VALUE'), 'ISACTIVE': (O, 'BOOL', 1, 'VALUE'), 'ENTITYKEY': (1, 'STRING', O, 'VALUE')} } , 'AFFINITYGROUP': {'TYPEOFTYPES': ['AFFINITYGROUPS'], 'FUNCTIONS': {'ENTITYCREATION':'putNetwork'} 'UNIQUEATTIBUTES': ['AFFINITYGROUPNAME'], 'TOKENENTITIESRELATIONSHIPS': [ ], 'ATTRIBUTES': {'XML': (2, 'STRING', O, 'VALUE'), 'DESCRIPTION': (4, 'STRING', O, 'VALUE'), 'ENTITYKEY': (1, 'STRING', O, 'VALUE'), 'TYPEOF': (5, 'STRING', O, 'VALUE'), 'AFFINITYGROUPNAME': (3, 'STRING', O, 'VALUE'), 'ISACTIVE': (O, 'BOOL', 1, 'VALUE')} } 'CASCADINGPAYMENT': {'TYPEOFTYPES': ['CASCADINGPAYMENT'], 'FUNCTIONS': {'ENTITYCREATION': 'putNetwork'}
'UNIQUEATTIBUTES': ['CASCADINGPAYMENTNAME'], 'TOKENENTITIESRELATIONSHIPS': ['GROUP'], 'ATTRIBUTES': {'STATUS': (2, 'STRING', O, 'VALUE'), 'EXPDT': (6, 'DATETIME', O, 'VALUE'), 'GROUP': (3, 'STRING', O, 'VALUE'), 'RESTRICTIONS': 5 (7, 'DICT', O, 'VALUE'), 'CASCADINGPAYMENTNAME': (4, 'STRING', O, 'VALUE'), 'STARTDT': (5, 'DATETIME', O, 'VALUE'), 'ISACTIVE': {O, 'BOOL', 1, 'VALUE'), 'ENTITYKEY': (1, 'STRING', O, 'VALUE')} } , 'GROUP': {'TYPEOFTYPES': [ ], 'FUNCTIONS': {'ENTITYCREATION':'putNetwork'} , 'UNIQUEATTIBUTES': ['GROUPNAME'], 'TOKENENTITIESRELATIONSHIPS': {} , 'ATTRIBUTES': {'GROUPNAME': (2, 'STRING', O, 'VALUE'), 'DESCRIPTION': (2, 'STRING', O, 'VALUE'), 'ISACTIVE': (O, 'BOOL', 1, 'VALUE'), 'ENTITYKEY': (1, 'STRING', O, 'VALUE')} } , 'USERS': {'TYPEOFTYPES': [], 'FUNCTIONS': {'ENTITYCREATION':'putNetwork'}, 'UNIQUEATTIBUTES': ['USERSID'], 'TOKENENTITIESRELATIONSHIPS': {} , 'ATTRIBUTES': {'USERSID': (2, 'STRING', O, 'VALUE'), 'ISACTIVE': (O, 'BOOL', 1, 'VALUE'), 'ENTITYKEY': (1, 'STRING', O, 'VALUE')} } , 'TWITTERUSER': {'TYPEOFTYPES': ['TOKENENTITY'], 'FUNCTIONS': {'ENTITYCREATION': 'putWGTNetwork'} 'UNIQUEATTIBUTES': ['USERNAME'], 'TOKENENTITIESRELATIONSHIPS': ['USER'], 'ATTRIBUTES': {'USERNAME': (2, 'STRING', O, 'VALUE'), 'CITY': (5, 'STRING', O, 'VALUE'), 'ENTITYKEY': (1, 'STRING', O, 'VALUE'), 'USERLINK': (6, 'STRING', O, 'VALUE'), 'FULLNAME': (4, 'STRING', O, 'VALUE'), 'USERTAG': (3, 'STRING', O, 'VALUE'), 'ISACTIVE': (O, 'BOOL', 1, 'VALUE')} } , 'COUPON': {'TYPEOFTYPES': ['COUPON'], 'FUNCTIONS': {'ENTITYCREATION': 'putNetwork'} , 'UNIQUEATTIBUTES': ['COUPONNAME'], 'TOKENENTITIESRELATIONSHIPS': ['MERCHANT'], 'ATTRIBUTES': {'STATUS': (2, 'STRING', O, 'VALUE'), 'MERCHANT': (3, 'STRING', O, 'VALUE'), 'TITLE': (5, 'STRING', O, 'VALUE'), 'NOTES': (7, 'STRING', O, 'VALUE'), 'UPDATEDBY': (11, 'STRING', O, 'VALUE'), 'ENTITYKEY': (1, 'STRING', O, 'VALUE'), 'DECRIPTION': (6, 'STRING', O, 'VALUE'), 'CREATEDBY': (10, 'STRING', O, 'VALUE'), 'LASTUPDATEDT': (9, 'DATETIME', O, 'VALUE'), 'EXPDT': (13, 'DATETIME', O, 'VALUE'),
'RESTRICTIONS': (14, 'DICT', O, 'VALUE'), 'COUPONNAME': (4, 'STRING', O, 'VALUE'), 'CREATIONDT': (8, 'DATETIME', O, 'VALUE'), 'STARTDT': (12, 'DATETIME', O, 'VALUE'), 'ISACTIVE': (O, 'BOOL', 1, 'VALUE')} } 5 , 'MEMBERSHIP': {'TYPEOFTYPES': ['MEMBERSHIPS'], 'FUNCTIONS': {'ENTITYCREATION':'putNetwork'} 'UNIQUEATTIBUTES': ['MEMBERSHIPNAME'], 'TOKENENTITIESRELATIONSHIPS': ['MERCHANT'], 'ATTRIBUTES': {'STATUS': (2, 'STRING', O, 'VALUE'), 'MERCHANT': (3, 'STRING', O, 'VALUE'), 'RESTRICTIONS': (7, 'DICT', O, 'VALUE'), 'MEMBERSHIPNAME': (4, 'STRING', O, 'VALUE'), 'STARTDT': (5, 'DATETIME', O, 'VALUE'), 'EXPDT': (6, 'DATETIME', O, 'VALUE'), 'ISACTIVE': (O, 'BOOL', 1, 'VALUE'), 'ENTITYKEY': (1, 'STRING', O, 'VALUE')} } 'USERSECURITY': {'TYPEOFTYPES': ['SECURITY'], 'FUNCTIONS': {'ENTITYCREATION': 'putNetwork'} 'UNIQUEATTIBUTES': ['USERSECURITYNAME'], 'TOKENENTITIESRELATIONSHIPS': ['USER'], 'ATTRIBUTES': {'STATUS': (2, 'STRING', O, 'VALUE'), 'EXPDT': (6, 'DATETIME', O, 'VALUE'), 'USERSECURITYNAME': (4, 'STRING', O, 'VALUE'), 'USER': (3, 'STRING', O, 'VALUE'), 'RESTRICTIONS': (7, 'DICT', O, 'VALUE'), 'STARTDT': (5, 'DATETIME', O, 'VALUE'), 'ISACTIVE': (O, 'BOOL', 1, 'VALUE'), 'ENTITYKEY': (1, 'STRING', O, 'VALUE')} } , 'MCC: {'TYPEOFTYPES': ['MCC'], 'FUNCTIONS': {'ENTITYCREATION': 'putWGTNetwork'} , 'UNIQUEATTIBUTES': ['MCCNAME', 'MCC'], 'TOKENENTITIESRELATIONSHIPS': ['MCCSEG'], 'ATTRIBUTES': {'MCCSEG': (4, 'STRING', O, 'VALUE'), 'MCC: (2, 'STRING', O, 'VALUE'), 'MCCNAME': (3, 'STRING', O, 'VALUE'), 'ISACTIVE': (O, 'BOOL', 1, 'VALUE'), 'ENTITYKEY': (1, 'STRING', O, 'VALUE')} } , 'ZIPCODE': {'TYPEOFTYPES': ['LOCATION'], 'FUNCTIONS': {'ENTITYCREATION': 'putNetwork'} , 'UNIQUEATTIBUTES': ['ZIPCODE'], 'TOKENENTITIESRELATIONSHIPS': [ ], 'ATTRIBUTES': {'STATE': (4, 'STRING', O, 'VALUE'), 'POPULATION': (3, 'STRING', O, 'VALUE'), 'ZIPCODE': (2, 'STRING', O, 'VALUE'), 'ISACTIVE': (O,
'BOOL', 1, 'VALUE'), 'ENTITYKEY': (1, 'STRING', O, 'VALUE')} } , 'PAYMENTCARD': {'TYPEOFTYPES': ['PAYMENTCARDS'], 'FUNCTIONS': {'ENTITYCREATION':'putNetwork'} 5 , 'UNIQUEATTIBUTES': ['CARDNUMBER'], 'TOKENENTITIESRELATIONSHIPS': ['USER'], 'ATTRIBUTES': {'EXPDATE': (5, 'DATETIME', O, 'VALUE'), 'ENTITYKEY': (1, 'STRING', O, 'VALUE'), 'CARDTYPE': (4, 'STRING', O, 'VALUE'), 'CARDNUMBER': (2, 'STRING', O, 'VALUE'), 'USER': (3, 'STRING', O, 'VALUE'), 'ISACTIVE': (O, 'BOOL', 1, 'VALUE')} } 'GENERICTOKEN': {'TYPEOFTYPES': ['COUPON'], 'FUNCTIONS': {'ENTITYCREATION': 'putNetwork'} 'UNIQUEATTIBUTES': ['GENERICTOKENNAME'], 'TOKENENTITIESRELATIONSHIPS': ['MERCHANT'], 'ATTRIBUTES': {'STATUS': (2, 'STRING', O, 'VALUE'), 'MERCHANT': (3, 'STRING', O, 'VALUE'), 'TITLE': (5, 'STRING', O, 'VALUE'), 'NOTES': (7, 'STRING', O, 'VALUE'), 'UPDATEDBY': (11, 'STRING', O, 'VALUE'), 'ENTITYKEY': (1, 'STRING', O, 'VALUE'), 'DECRIPTION': (6, 'STRING', O, 'VALUE'), 'CREATEDBY': (1 O, 'STRING', O, 'VALUE'), 'LASTUPDATEDT': (9, 'DATETIME', O, 'VALUE'), 'EXPDT': (13, 'DATETIME', O, 'VALUE'), 'RESTRICTIONS': (14, 'DICT', O, 'VALUE'), 'STARTDT': (12, 'DATETIME', O, 'VALUE'), 'CREATIONDT': ( 8, 'DATETIME', O, 'VALUE'), 'GENERICTOKENNAME': (4, 'STRING', O, 'VALUE'), 'ISACTIVE': (O, 'BOOL', 1, 'VALUE')} } , 'USER': {'TYPEOFTYPES': ['USERS', 'SYNTHETICNETWORKS'], 'FUNCTIONS': {'ENTITYCREATION': 'putNetwork'} 'UNIQUEATTIBUTES': ['USERNAME'], 'TOKENENTITIESRELATIONSHIPS': ['USERS'], 'ATTRIBUTES': {'USERNAME': (5, 'STRING', O, 'VALUE'), 'USERS': (2, 'STRING', O, 'VALUE'), 'FIRSTNAME': (3, 'STRING', O, 'VALUE'), 'LASTNAME': (4, 'STRING', O, 'VALUE'), 'ENTITYKEY': (1, 'STRING', O, 'VALUE'), 'ISACTIVE': (O, 'BOOL', 1, 'VALUE')} }
'TWEETS': {'TYPEOFTYPES': ['TOKENENTITY'], 'FUNCTIONS': {'ENTITYCREATION': 'putWGTNetwork'} , 'UNIQUEATTIBUTES': ['TWEETID'], 'TOKENENTITIESRELATIONSHIPS': 5 ['TWITTERUSER'], 'ATTRIBUTES': {'Title': (4, 'STRING', O, 'VALUE'), 'RawTweet': (5, 'STRING', O, 'VALUE'), 'DATETIME': (3, 'STRING', O, 'VALUE'), 'CLEANEDTWEET': (6, 'STRING', O, 'VALUE'), 'ENTITYKEY': (1, 'STRING', O, 'VALUE'), 'TWEETID': (2, 'STRING', O, 'VALUE'), 'ISACTIVE': (O, 'BOOL', 1, 'VALUE')} } , 'MODEL': {'TYPEOFTYPES': ['MODELS'], 'FUNCTIONS': {'ENTITYCREATION': 'putNetwork'} , 'UNIQUEATTIBUTES': ['MODELNAME'], 'TOKENENTITIESRELATIONSHIPS': ['USER', 'MERCHANT', 'PAYMENTCARD'], 'ATTRIBUTES': {'XML': (2, 'STRING', O, 'VALUE'), 'MODELNAME': (3, 'STRING', O, 'VALUE'), 'DESCRIPTION': (4, 'STRING', O, 'VALUE'), 'ENTITYKEY': (1, 'STRING', O, 'VALUE'), 'TYPEOF': (5, 'STRING', O, 'VALUE'), 'ISACTIVE': (O, 'BOOL', 1, 'VALUE')} } , 'MCCSEG': {'TYPEOFTYPES': ['MCCSEG'], 'FUNCTIONS': {'ENTITYCREATION': 'putWGTNetwork'} , 'UNIQUEATTIBUTES': ['MCCSEGID'], 'TOKENENTITIESRELATIONSHIPS': {} , 'ATTRIBUTES': {'MCCSEGID': (2, 'STRING', O, 'VALUE'), 'MCCSEGNAME': (3, 'STRING', O, 'VALUE'), 'ISACTIVE': (O, 'BOOL', 1, 'VALUE'), 'ENTITYKEY': (1, 'STRING', O, 'VALUE')} } , 'TOKENENTITY': {'TYPEOFTYPES': ['TOKENENTITY'], 'FUNCTIONS': {'ENTITYCREATION': 'putWGTNetwork'} 'UNIQUEATTIBUTES': ['TOKENENTITYKEY'], 'TOKENENTITIESRELATIONSHIPS': { }, 'ATTRIBUTES': {'STATUS': (4, 'STRING', O, 'VALUE'), 'ISSUEDDATE': (5, 'STRING', O, 'VALUE'), 'DOUBLELINKED': ( 8, 'BOOL', 1, 'VALUE'), 'BASEUUID': (1, 'STRING', O, 'VALUE'), 'WEIGHT': ( 6, 'STRING', O, 'VALUE'), 'BASETYPE': ( 3, 'STRING', O, 'VALUE'), 'CATEGORY': ( 7, 'STRING', O, 'VALUE'), 'ISACTIVE': (O, 'BOOL', 1, 'VALUE'), 'TOKENENTITYKEY': ( 2, 'STRING', O, 'VALUE')} }
} A Figura 20 mostra um diagrama de bloco que ilustra configurações de componente UEP exemplificativas em algumas modalidades do UEP.
Em algumas modalidades, o UEP pode agregar dados a partir de uma variedade de fontes para gerar informações pessoais 5 centralizadas.
Esse também pode agregar vários tipos de dados para gerar as informações pessoais centralizadas.
Por exemplo, o UEP pode utilizar componente(s) de agregação de resultados de pesquisa 2001 (por exemplo, como descrito nas Figuras 21-22) para agregar resultados de pesquisa a partir de uma ampla gama de sistemas de rede de computador, por exemplo, a Internet.
Como outro exemplo, o UEP pode utilizar componente(s) de 1O agregação de dados de transação 2002 (por exemplo, como descrito nas Figuras 23-26) para agregar dados de transação, por exemplo, de procedimento de processamento de transação por uma rede de pagamento.
Como outro exemplo, o UEP pode utilizar componente(s) de agregação de dados de uso de serviço 2003 (por exemplo, como descrito nas Figuras 23-26) para agregar dados durante o uso do usuário de vários serviços associados ao UEP.
Como outro exemplo, o UEP pode utilizar componente(s) de dados de inscrição 2004 (por exemplo, como descrito nas Figuras 23-26) para agregar dados durante a inscrição do usuário em vários serviços associados ao UEP.
Como outro exemplo, o UEP pode utilizar componente(s) de agregação de dados sociais 2003 (por exemplo, como descrito nas Figuras 27-28) para agregar dados durante o uso de vários do usuário de vários serviços de rede sociais acessíveis pelo UEP.
Em algumas modalidades, o UEP pode adquirir os dados agregados, e normalizar os dados em formatos que são adequados para armazenamento uniforme, indexação, manutenção e/ou processamento adicional através de componente(s) de normalização de registro de dados 2006 (por exemplo, como descrito na Figura 31). O UEP pode extrair dados dos registros de dados normalizados, e campos de dados reconhecer os campos de dados, por exemplo, o UEP pode identificar os atributos de cada campo de dados incluído nos registros de dados normalizados através de componente(s) de reconhecimento de campo de dados 2007 (por exemplo, como descrito na Figura 32). Por exemplo, o UEP pode identificar nomes, ID(s) de usuário, endereços, endereços de rede, comentários e/ou palavras específicas dentro dos comentários, imagens, publicações em blogs, vídeo, conteúdo dentro do vídeo, e/ou similares dos dados agregados.
Em algumas modalidades, para cada campo de dados, o UEP pode classificar tipos de entidade associados ao campo de dados, bem como identificadores de entidade associados ao campo de dados, por exemplo, através de componente(s) 2008 (por exemplo, como descrito na Figura 33). Por exemplo, o UEP pode identificar um campo de dados de endereço de Protocolo de Internet (IP) que será associado a uma ID de usuário john.q.public (tipo de entidade de consumidor), um usuário John Q.
Public (tipo de entidade de consumidor), um agregado (the Public household - a multi-consumer entity type / household entity type), um tipo de entidade de comerciante com identificador Acme Merchant Store, lnc. a partir do qual as compras são realizadas a partir do endereço IP, um tipo de emissor Bank com identificador First National Bank associado às compras realizadas a partir do endereço IP, e/ou similares.
Em algumas modalidades, o UEP pode utilizar os tipos de entidade e identificadores de entidade para correlacionar as entidades, por exemplo, através de componente(s) de correlação de entidade cruzada 2009 (por exemplo, como descrito na Figura 34). Por exemplo, o UEP pode identificar, a partir dos dados agregados, que uma entidade doméstica com identificador H123 pode incluir uma entidade de usuário com o identificador John Q.
Public e 1O o identificador social john.q.public@facebook.com, uma segunda entidade de usuário com o identificador Jane P.
Doe com o identificador social jpdoe@twitter.com, uma entidade de computador com identificador de endereço IP 192.168.4.5, uma entidade de conta de cartão com identificador ****i234, uma entidade de emissor de banco com o identificador AB23145, uma entidade de comerciante com o identificador Acme Stores, lnc. onde as sub-entidades domésticas realizam compras, e/ou similares.
Em algumas modalidades, o UEP pode utilizar os identificadores de entidade, dados associados a cada entidade e/ou entidades correlacionadas para identificar associações a outras entidades, por exemplo, através de componente(s) de associação de atributo de entidade 201 O (por exemplo, como descrito na Figura 35). Por exemplo, o UEP pode identificar compras específicas feitas através de transações de compra por membros da família, e, assim, identificar atributos de membros da família com base nas compras nas transações de compra feitas por membros da família.
Com base nessas correlações e associações, o UEP pode atualizar um perfil de cada entidade identificada a partir dos dados agregados, bem como um gráfico social que inter- relaciona as entidades identificadas nos dados agregados, por exemplo, através de componente(s) de atualização de gráfico de perfil de entidade 2011 (por exemplo, como descrito na Figura 36). Em algumas modalidades, a atualização de perfil e/ou gráficos sociais de uma entidade pode acionar uma pesquisa de dados adicionais que podem ser relevantes para as correlações e associações recentemente identificadas para cada entidade, por exemplo, através de componente(s) de geração de termo de pesquisa 2013- 2014 (por exemplo, como descrito na Figura 37). Por exemplo, a atualização de um gráfico de perfil e/ou social pode acionar pesquisas pela Internet, sites de rede social, dados de transação de redes de pagamento, serviços inscritos e/ou utilizados pelas entidades, e/ou similares.
Em algumas modalidades, essa atualização de perfis de entidade e/ou gráficos sociais pode ser realizada de forma contínua, periódica, sob demanda, e/ou similares.
A Figura 21 mostra um diagrama de fluxo de dados que ilustra um procedimento de agregação de resultado de pesquisa exemplificativo em algumas modalidades do UEP.
Em algumas implementações, o servidor de rede de pagamento pode obter um disparador para realizar uma pesquisa.
Por exemplo, o servidor de rede de pagamento pode realizar periodicamente uma atualização de pesquisa de seu banco de dados de pesquisa agregado, por exemplo, 2110, com novas informações disponíveis a partir de uma variedade de fontes, como a Internet.
Como outro exemplo, uma solicitação de atualização de pesquisa sob 5 demanda pode ser obtida como resultado de um desejo do usuário de se inscrever em um serviço, com isso o servidor de rede de pagamento pode facilitar a entrada de dados fornecendo um sistema de preenchimento de formulários automático da web utilizando informações sobre o usuário obtidas a partir da atualização de pesquisa.
Em algumas implementações, o servidor de rede de pagamento pode analisar o disparador para extrair 1O palavras-chave utilizadas para realizar uma pesquisa agregada.
O servidor de rede de pagamento pode gerar uma consulta para modelos de interface de programação de aplicativo (API) para vários mecanismos de pesquisa (por exemplo, Google™, Bing®, AskJeeves, mecanismos de pesquisa de dados de mercado, etc.) a partir dos quais coleta- se dados para agregação.
O servidor de rede de pagamento pode consultar, por exemplo, 2112, um banco de dados de rede de pagamento, por exemplo, 2107, para buscar modelos API para os mecanismos de pesquisa.
Por exemplo, o servidor de rede de pagamento pode utilizar comandos PHP/SQL similares aos exemplos fornecidos acima.
O banco de dados pode fornecer, por exemplo, 2113, uma lista de modelos API em resposta.
Com base na lista de modelos API, o servidor de rede de pagamento pode gerar pedidos de pesquisa, por exemplo, 2114. O servidor de rede de pagamento pode emitir os pedidos de pesquisa gerados, por exemplo, 2115a-c, para os servidores de mecanismo de pesquisa, por exemplo, 2101 a-e.
Por exemplo, o servidor de rede de pagamento pode emitir comandos PHP para solicitar ao mecanismo de pesquisa os resultados de pesquisa.
Uma lista exemplificativa de comandos para emitir pedidos de pesquisa 2115a-c, substancialmente sob a forma de comandos PHP, é fornecida abaixo: <?PHP li API URL with access key $url = [ "https:/lajax.googleapis.comlajaxlservicesl searchlweb?v=1.0&" . "q=" $keywords "&key=1234 567890987654&userip=datagraph.cpip.com"];
li Send Search Request $eh = curl_init ( ) ; curl_setopt ($eh, CURLOPT_URL, $url); curl_setopt ($eh, CURLOPT_RETURNTRANSFER, 1) ; curl_setopt ($eh, CURLOPT_REFERER, "datagraph.cpip.com"); $body = curl_exec ($eh); curl_close ( $eh) ;
li Obtain, parse search resulta $json =json_decode ($body); ?> 5 Em algumas modalidades, os servidores de mecanismo de pesquisa podem consultar, por exemplo, 2117a-c, seus bancos de dados de pesquisa, por exemplo, 2102a-c, para resultados de pesquisa dentro do escopo das palavras-chave de pesquisa. 4dados formatados por JavaScript Object Notation (JSON), é fornecida abaixo: {"responseData": { "results": [ { "GsearchResultClass": "GwebSearch", "unescapedUrl": "http: / /en. wikipedia .org/wiki/ John_Q_Public", "url": "http://en.wikipedia.org/wiki/John_Q_Public", "visibleUrl": "en.wikipedia.org", "cacheUrl": "http: / /www.google.com/ search?q\u003dcache: TwrPfhd22hYJ: en . wikipedia . org", "title": "\u003cb\u003eJohn Q.
Public\u003c/b\u003e - Wikipedia, the free encyclopedia", "titleNoFormatting": "John Q.
Public - Wikipedia, the free encyclopedia", "content": "\[1\] ln 2006, he served as Chief Technology Officer... " }, { "GsearchResultClass": "GwebSearch", "unescapedUrl": "http://www.imdb.com/name/nm0385296/", "url": "http://www. imdb. com/name/nm0385296/", "visibleUrl": "www.imdb.com", "cacheUrl": "http://www.google.com/ search?q\u003dcache: li34KkqnsooJ: www . imdb . com", "title": "\u003cb\u003eJohn Q.
Public\u003c/b\u003e", "titleNoFormatting": "John Q.
Public", "content": "Self: Zoolander.
Socialite \u003cb\u003eJohn Q.
Public\u003c/b\u003e ... " },
], "cursor": { "pages": [ { "start": "O", "label": 1 }, 5 { "start": "4", "label": 2 }, { "start": "8", "label": 3 }, { "start": "12 ", "label": 4 }
]' "estimatedResultCount": "59600000", "currentPagelndex": O, "moreResultsUrl": "http://www.google.com/ search?oe\u003dutf8\u0026ie\u003dutf8 ... " } } , "responseDetails": null, "responseStatus": 200} Em algumas modalidades, o servidor de rede de pagamento pode armazenar os resultados de pesquisa agregados, por exemplo, 2120, em um banco de dados de pesquisa agregado, por exemplo, 211 O.
A Figura 22 mostra um diagrama de fluxo lógico que ilustra os aspectos exemplificativos de agregação de resultados de pesquisa em algumas modalidades do UEP, por exemplo, um componente de Agregação de Resultados de Pesquisa ("SRA") 2200. Em algumas implementações, o servidor de rede de pagamento pode obter um disparador para realizar uma pesquisa, por exemplo, 2201. Por exemplo, o servidor de rede de pagamento pode realizar periodicamente uma atualização de pesquisa de seu banco de dados de pesquisa agregado com novas informações disponíveis a partir de uma variedade de fontes, como a Internet.
Como outro exemplo, um pedido de atualização de pesquisa sob demanda pode ser obtido como resultado de um desejo do usuário de se inscrever em um serviço, com isso o servidor de rede de pagamento pode facilitar a entrada de dados fornecendo um sistema de preenchimento de formulários automático da web utilizando informações sobre o usuário obtidas a partir da atualização de pesquisa.
Em algumas implementações, o servidor de rede de pagamento pode analisar o disparador, por exemplo, 2202, para extrair palavras- chave utilizadas para realizar uma pesquisa agregada.
O servidor de rede de pagamento pode determinar os mecanismos de pesquisa para pesquisa, por exemplo, 2203, utilizando as palavras-chave extraídas.
Então, o servidor de rede de pagamento pode gerar uma consulta de modelos de interface de programação de aplicativo (API) para vários mecanismos de pesquisa (por exemplo, Google™, Bing®, AskJeeves, mecanismos de pesquisa de dados de mercado, etc.) a partir dos quais coleta-se dados para agregação, por exemplo, 2204. O servidor de rede de pagamento pode consultar, por exemplo, 2205, um banco de dados de rede de pagamento, por exemplo para buscar modelos API para os mecanismos de pesquisa.
Por exemplo, o servidor de rede de pagamento pode utilizar comandos PHP/SQL similares aos exemplos fornecidos acima.
O banco de dados pode 5 fornecer, por exemplo, 2205, uma lista de modelos API em resposta.
Com base na lista de modelos API, o servidor de rede de pagamento pode gerar pedidos de pesquisa, por exemplo, 2206. O servidor de rede de pagamento pode emitir os pedidos de pesquisa gerados para os servidores de mecanismo de pesquisa.
Os servidores de rede de pagamento podem analisar o(s) resultado(s) de pesquisa, por exemplo, 2207, e consultar, 1O por exemplo, 2208, seu banco de dados de pesquisas para resultados de pesquisa que estão dentro do escopo das palavras-chave de pesquisa.
Em resposta às consultas de pesquisa, os bancos de dados de pesquisa podem fornecer resultados de pesquisa, por exemplo, 2209, aos servidores de mecanismo de pesquisa.
Os servidores de mecanismo de pesquisa podem responder aos resultados de pesquisa obtidos a partir dos bancos de dados de pesquisa, por exemplo, 221 O, para o servidor de rede de pagamento que realiza os pedidos de pesquisa.
O servidor de rede de pagamento pode gerar, por exemplo, 2211, e armazenar os resultados de pesquisa agregados, por exemplo, 2212, em um banco de dados de pesquisa agregado.
As Figuras 23A-D mostram diagramas de fluxo de dados que ilustram um procedimento de execução de transação baseado em cartão exemplificativo em algumas modalidades do UEP.
Em algumas implementações, um usuário, por exemplo, 2301, pode desejar comprar um produto, serviço, oferta e/ou similares ("produto"), de um comerciante.
O usuário pode se comunicar com um servidor de comerciante, por exemplo, 2303., através de um cliente como, porém sem caráter limitativo: um computador pessoal, dispositivo móvel, televisão, terminal de ponto de venda, quiosque, ATM, e/ou similares (por exemplo, 2302). Por exemplo, o usuário pode fornecer uma entrada de usuário, por exemplo, entrada de compra 2311, ao cliente indicando o desejo do usuário de comprar o produto.
Em várias implementações, a entrada de usuário pode incluir, porém sem caráter limitativo: entrada de teclado, passagem de cartão, ativar um dispositivo de hardware habilitado para RFID/NFC (por exemplo, cartão eletrônico com múltiplas contas, smartphone, tablet, etc.), cliques de mouse, pressionamentos de botões em um joystick!console de jogo, comandos de voz, gestos de único/múltiplo toque em uma interface sensível ao toque, tocar os elementos de interface de usuário em uma tela sensível ao toque, e/ou similares.
Por exemplo, o usuário pode direcionar um aplicativo de navegador direto executado no dispositivo de cliente para um site do comerciante, e pode selecionar um produto do site através de clique em um hyperlink apresentado ao usuário através do site.
Como outro exemplo, o cliente pode obter dados de rastreamento do cartão do usuário (por exemplo, cartão de crédito, cartão de débito, cartão pré-pago, cartão de carga, etc.), como os dados de rastreamento exemplificativos fornecidos abaixo: %8123456789012345"PUBLIC/J.Q. "99011200000000000000* *901 * * * * * * ?* (em que'123456789012345'é o número de cartão de 'J.Q.
Public' e possui um 5 número CW de 901 .'990112'é um código de serviço, e *** representa dígitos decimais que mudam aleatoriamente toda vez que o cartão é usado). Em algumas implementações, o cliente pode gerar uma mensagem de pedido de compra, por exemplo, 2312, e fornecer, por exemplo, 2313, a mensagem de pedido de 1O compra gerada ao servidor de comerciante.
Por exemplo, um aplicativo de navegador executado no cliente pode fornecer, em nome do usuário, uma mensagem GET de Protocolo de Transferência de Hipertexto (Secure) que inclui os detalhes de pedido de produto do servidor de comerciante sob a forma de dados formatados de acordo com a Linguagem de Marcação extensível ("XML"). Abaixo está uma mensagem GET HTTP(S) exemplificativa que inclui uma mensagem de pedido de compra formatada em XML do servidor de comerciante: GET /purchase .php HTTP/1.1 Host: www.merchant.com Content-Type: Application/XML Content-Length: 1306 <?XML version = "1.0" encoding = "UTF-8"?> <purchase_order> <order_I D>4NFU4RG94</order_I D> <timestamp>2011-02-22 15: 22: 43</timestamp> <usuário_ID>john.q.publicSgmail. com</user_ID> <client_details> <client_I P> 192.168.23.126</client_I P> <client_type>smartphone</client_type> <client_model>HTC Hero</client_model> <OS>Android 2.2</0S> <app_installed_flag>true</app_installed_flag> </client_details> <purchase_details> <num_products>l</num_products> <product> <prod uct_type>book</prod uct_type> <product_params>
<product_title>XML for dummies</product_title> <ISBN>938-2-14-168710-0</ISBN> <edition>2nd ed. </edition> <cover>hardbound</ cover> <seller>bestbuybooks</seller> </product_params> <q uantity>K/q uantity> </product> </purchase_details> <account_params> <account_name>John Q.
Public</account_name> <account_type>credit</accou nt_type> <account_num>123456789012345</account_num> <billing_address>123 Green St., Norman, OK 98765</billing_address> <phone> 123-456-7809</phone> <sign>/jq p/</sig n> <confirm_type>email</confirm_type> <contact_info>john. q . publicSgmail. com</contact_info> </account_params> <shipping_info> <shipping_adress>same as billing</shipping_address> <ship_type>expedited</ ship_type> <ship_carrier>FedEx</ ship_carrier> <ship_account>123-45-678</ ship_account> <tracking_flag>true</tracking_flag> <sign_flag>false</sign_flag> </ shipping_info> </purchase_order> Em algumas implementações, o servidor de comerciante pode obter a mensagem de pedido de compra do cliente, e pode analisar a mensagem de pedido de compra para extrair detalhes do pedido de compra do usuário.
O servidor de comerciante pode gerar uma solicitação de pesquisa de cartão, por exemplo, 2314 para determinar se a transação pode ser processada.
Por exemplo, o servidor de comerciante pode tentar determinar se o usuário possui fundos suficientes para pagar a compra em uma conta de cartão fornecida com o pedido de compra.
O servidor de comerciante pode fornecer a solicitação de consulta de cartão gerada, por exemplo, 2315, a um servidor adquirente, por exemplo, 2304. Por exemplo, o servidor adquirente pode ser um servidor de uma instituição financeira adquirente ("adquirente") que mantém uma conta do comerciante.
Por exemplo, os lucros de transações processadas pelo comerciante podem ser depositados em uma conta mantida pelo adquirente.
Em algumas implementações, a solicitação de consulta de cartão pode incluir detalhes como, porém sem caráter limitativo: os custos do usuário envolvido na transação, detalhes de conta de cartão do usuário, informações de faturamento e/ou remessa de usuário e/ou similares.
Por exemplo, o servidor de comerciante pode fornecer uma mensagem HTTP(S) POST que inclui uma solicitação de consulta de cartão formatada em XML similar à listagem exemplificativa fornecida abaixo: POST /cardquery.php HTTP/ 1.1 Host: www.acquirer.com Content-Type: Application/XML Content-Length: 624 <?XML version ="1.0" encoding ="UTF-8"?> <card_query_request> <query_ID>VNE139FK</query_ID> <timestamp>2011-02-22 15: 22: 44</timestamp> <purchase_summary> <num_products>l</num_products> <product> <product_summary>Book - XML for dummies</product_summary> <product_quantity>K/product_quantity? </product> </purchase_summary> <transação_cost>$34.78</ transação_cost> <account_params> <account_name>John Q.
Public</account_name> <accou nt_type>cred it</accou nt_type> <account_num>123456789012345</account_num> <billing_address>123 Green St., Norman, OK 98765</billing_address> <phone> 123-456-7809</phone> <sig n>/jq p/</sig n> </account_params> <merchant_params> <merchant_id>3FBCR41NC</merchant_id> <merchant_name>Books & Things, lnc. </merchant_name> <merchant_auth_key>INNF484MCP59CHB27365 </merchant_auth_key> </merchant_params>
</card_q uery_req uest> Em algumas implementações, o servidor adquirente pode gerar um pedido de autorização de cartão, por exemplo, 2316, utilizando a solicitação de consulta de cartão obtida, e fornecer o pedido de autorização de cartão, por exemplo, 2317, a um servidor de rede de pagamento, por exemplo, 2305. Por exemplo, o servidor adquirente pode redirecionar a mensagem HTTP(S) POST no exemplo acima a partir do servidor de comerciante para o servidor de rede de pagamento. Em algumas implementações, o servidor de rede de pagamento pode determinar se o usuário está inscrito em serviços de usuário de valor agregado. Por exemplo, o servidor de rede de pagamento pode consultar 2318 um banco de dados, por exemplo, um banco de dados de rede de pagamento 2307, para dados de inscrição de serviço de usuário. Por exemplo, o servidor pode utilizar comandos PHP/SQL similares ao exemplo fornecido acima para consultar o banco de dados de rede de pagamento. Em algumas implementações, o banco de dados pode fornecer os dados de inscrição de serviço de usuário, por exemplo,
2319. Os dados de inscrição de serviço de usuário podem incluir um sinalizador indicando se os usuários estão ou não inscritos, bem como instruções, dados, URL de conexão, modelo de chamada API de conexão e/ou similares para facilitar o acesso dos serviços inscritos por usuário. Por exemplo, em algumas implementações, o servidor de rede de pagamento pode redirecionar o cliente para um servidor de valor agregado (por exemplo, como um servidor de rede social onde o serviço de valor agregado está relacionado à rede social) fornecendo uma mensagem HTTP(S) REDIRECT 300, similar ao exemplo abaixo: HTTP/ 1 . 1 300 Multiple Choices Location: https://www.facebook.com/dialog/oauth?client_id=snpa_app_ID&redirect_uri= www.paynetwork.com/purchase . php <html> <headxtitle>300 Multiple Choices</title></head> <body><hl>Multiple Choices</h 1></body> </html> Em algumas implementações, o servidor de rede de pagamento pode fornecer informações de pagamento extraídas do pedido de autorização de cartão ao servidor de valor agregado como parte de uma solicitação de serviço de valor agregado, por exemplo,
2320. Por exemplo, o servidor de rede de pagamento pode fornecer uma mensagem HTTP(S) POST ao servidor de valor agregado, similar ao exemplo abaixo: POST /valueservices .php HTTP/1.1 Host: www.valueadd.com Content-Type: Application/XML
Content-Length: 1306 <?XML version ="1.0" encoding ="UTF-8"?> <service_req uest> <req uest_I D>4NFU4RG94</order_I D> 5 <timestamp>2011-02-22 15: 22: 43</timestamp> <user_ID>john. q. publicSgmail. com</user_ID> <client_details> <client_IP>192.168.23.126</client_IP> <client_type>smartphone</client_type> <client_model>HTC Hero</client_model> <OS>Android 2.2</0S> <app_i nstalled_flag>true</app_installed_flag > </client_details> <account_params> <account_name>John Q.
Public</account_name> <account_type>cred it</account_type> <account_num>123456789012345</account_num> <billing_address>123 Green St., Norman, OK 98765</billing_address> <phone> 123-456-7809</phone> <sign>/jqp/</sign> <confirm_type>email</confirm_type> <contact_info>john . q . publicSgmail . com</contact_info> </account_params> < ! --optional--> <merchant> <merchant_id>CQN3Y42N</merchant_id> <merchant_name>Acme Tech, lnc. </merchant_name> <user_name>john. q. public</user_name> <cardlist> www . acme . com/user/john . q. public/cclist . xml<cardlist> <user_account_preference>I 3 2 4 7 6 5<user_account_preference> </merchant> </service_req uest> Em algumas implementações, o servidor de valor agregado pode fornecer um pedido de entrada de serviço, por exemplo, 2321, ao cliente.
Por exemplo, o servidor de valor agregado pode fornecer uma forma de entrada HTML/conexão ao cliente.
O cliente pode exibir, por exemplo, 2322, a forma de conexão 1 do usuário.
Em algumas implementações, o usuário pode fornecer uma entrada de conexão de cliente, por exemplo, 2323, e o cliente pode gerar uma resposta de entrada de serviço, por exemplo, 2324, do servidor de valor agregado.
Em algumas implementações, o servidor de valor agregado pode fornecer serviços de valor agregado de acordo com os dados de inscrição de serviço de valor agregado de usuário, perfil de usuário, etc., armazenados no servidor de valor agregado, e 5 com base na entrada de serviço de usuário.
Com base na provisão de serviços de valor agregado, o servidor de valor agregado pode gerar uma resposta de serviço de valor agregado, por exemplo, 2326, e fornecer a resposta ao servidor de rede de pagamento.
Por exemplo, o servidor de valor agregado pode fornecer uma mensagem HTTP(S) POST similar ao exemplo abaixo: 1O POST /serviceresponse .php HTTP/ 1 . 1 Host: www.paynet.com Content-Type: Application/XML Content-Length: 1 30 6 <?XML version =" 1 . O " encoding ="UTF- 8 " ? > <service_response> <request_ID> 4NFU4RG94</order_ID> <timestamp>2 01 1 - 02 -22 15: 22: 43</timestamp> <resu lt>serviced </result> <servcode> 94 3528 97 6302 - 4 55 69 - 00382 9- 04</servcode> </service_response> Em algumas implementações, mediante o recebimento da resposta de serviço de valor agregado do servidor de valor agregado, o servidor de rede de pagamento pode extrair os dados de serviço de inscrição da resposta para adição a um registro de dados de transação.
Em algumas implementações, o servidor de rede de pagamento pode encaminhar o pedido de autorização de cartão a um servidor de rede de pagamento apropriado, por exemplo, 2328, que pode analisar o pedido de autorização de cartão para extrair detalhes do pedido.
Utilizando-se os campos e os valores de campo extraídos, o servidor de rede de pagamento pode gerar uma consulta, por exemplo, 2329, para um servidor emissor correspondente à conta de cartão do usuário.
Por exemplo, a conta de cartão do usuário, cujos detalhes do usuário podem ser fornecidos através da mensagem de pedido de compra gerada por cliente, pode ser vinculada a uma instituição financeira emissora ("emissor"), como uma instituição bancária, que emitiu a conta de cartão do usuário.
Um servidor emissor, por exemplo, 2308a-n, do emissor pode conter detalhes da conta de cartão do usuário.
Em algumas implementações, um banco de dados, por exemplo, banco de dados de rede de pagamento 2307, pode armazenar detalhes dos servidores emissores e os números de conta de cartão associados aos servidores emissores.
Por exemplo, o banco de dados pode ser um banco de dados relacional responsivo a comandos de Linguagem de Consulta Estruturada ("SQL"). O servidor de rede de pagamento pode executar um script de pré-processador de hipertexto ("PHP") inclusive comandos SQL para consultar o banco de dados para detalhes do servidor emissor.
Uma listagem de comando exemplificativa PHPISQL, que ilustra os aspectos independentes de consultar o banco de 5 dados, é fornecida abaixo: <?PHP header ('Content-Type: textlplain'); mysql_connect ("254.93.179.112", $DBserver, $password) li access database server mysql_select_db (" ISSUERS . SQL" ) ; li select database table to search llcreate query for issuer server data $query ="SELECT issuer_name issuer_address issuer_id ip_address mac_address auth_key port_num security_settings_list FROM lssuerTable WHERE account_num LIKE'%'$accountnum"; $result =mysql_query ( $query) ; li perform the search query mysql_close (" ISSUERS . SQL" ) ; li close database access ?> Em resposta à obtenção da consulta de servidor emissor, por exemplo, 2329, o banco de dados de rede de pagamento pode fornecer, por exemplo, 2330, os dados de servidor emissor solicitados ao servidor de rede de pagamento.
Em algumas implementações, o servidor de rede de pagamento pode utilizar os dados de servidor emissor para gerar um encaminhamento de pedido de autorização de cartão, por exemplo, 2331, para redirecionar o pedido de autorização de cartão a partir do servidor adquirente para o servidor emissor.
O servidor de rede de pagamento pode fornecer o pedido de autorização de cartão, por exemplo, 2332a-n, ao servidor emissor.
Em algumas implementações, o servidor emissor, por exemplo, 2308a-n, pode analisar o pedido de autorização de cartão, e com base nos detalhes de pedido pode consultar o banco de dados 2333a-n, por exemplo, o banco de dados de perfil de usuário 2309a-n, para dados da conta de cartão do usuário.
Por exemplo, o servidor emissor pode emitir comandos PHPISQL similares ao exemplo fornecido abaixo: <?PHP header ('Content-Type: textlplain'); mysql_connect ("254.93.179.112", $DBserver, $password) // access data base server mysql_select_db ( "USERS . SQL" ) ; li select database table to search llcreate query for user data $query ="SELECT user_id user_name user_balance account_type FROM UserTable
WHERE account_num LIKE'%'$accountnum" ; $result = mysql_query ( $query) ; li perform the search query mysql_close ( "USERS . SQL" ) ; li close database access ?> 5 Em algumas implementações, mediante a obtenção dos dados de usuário, por exemplo, 2334a-n, o servidor emissor pode determinar se o usuário pode pagar a transação utilizando fundos disponíveis na conta, por exemplo, 2335a-n.
Por exemplo, o servidor emissor pode determinar se o usuário possui um saldo suficiente restante na conta, crédito suficiente associado à conta, e/ou similares.
Se o servidor emissor determinar que o usuário 1O pode pagar a transação utilizando os fundos disponíveis na conta, o servidor pode fornecer uma mensagem de autorização, por exemplo, 2336a-n, ao servidor de rede de pagamento.
Por exemplo, o servidor pode fornecer uma mensagem HTTP(S) POST similar aos exemplos acima.
Em algumas implementações, o servidor de rede de pagamento pode obter a mensagem de autorização, e analisar a mensagem para extrair detalhes de autorização.
Mediante a determinação que o usuário possui fundos suficientes para a transação, o servidor de rede de pagamento pode gerar um registro de dados de transação do pedido de autorização de cartão recebido, e armazenar, por exemplo, 2339, os detalhes da transação and autorização referentes à transação em um banco de dados, por exemplo, banco de dados de rede de pagamento 2307. Por exemplo, o servidor de rede de pagamento pode emitir comandos PHP/SQL similares à listagem exemplificativa abaixo para armazenar os dados de transação em um banco de dados: <?PHP header ('Content-Type: text/plain'); mysql_connect ( "254.92.185.103", $DBserver, $password) ; li access database serer mysql_select ( "TRANSACTIONS . SQL" ) ; li select database to append mysql_query (" INSERT INTO PurchasesTable (timestamp, purchase_summary_list, num_products, product_summary, product_quantity, transaction_cost, account_params_list, account_name, account_type, account_num, billing_addres, zipcode, phone, sign, merchant_params_list, merchant_id, merchant_name, merchant_auth_key) VALUES (time(), $purchase_summary_list, $num_products, $product_summary, $product_quantity, $transaction_cost, $account_params_list, $account_name, $account_type, $account_num, $billing_addres, $zipcode, $phone, $sign, $merchant_params_list, $merchant_id, $merchant_name, $merchant_auth_key ) " ) ; li add data to table in database mysql_close ("TRANSACTIONS.
SQL") ; li close connection to database ?> Em algumas implementações, o servidor de rede de pagamento pode encaminhar a mensagem de autorização, por exemplo, 2340, para o servidor adquirente, que por sua vez pode encaminhar a mensagem de autorização, por exemplo, 2340, para o servidor de comerciante.
O comerciante pode obter a mensagem de autorização, e determinar a partir dessa que o usuário possui fundos suficientes na conta de cartão para conduzir a transação.
O servidor de comerciante pode adicionar um registro da transação do usuário a um lote de dados de transação referente a transações autorizadas.
Por exemplo, o comerciante pode 1O anexar os dados XML pertencentes à transação de usuário a um arquivo de dados XML que compreende dados XML de transações que foram autorizadas para vários usuários, por exemplo, 2341, e armazenar o arquivo de dados XML, por exemplo, 2342, em um banco de dados, por exemplo, banco de dados de comerciante 2304. Por exemplo, um arquivo de dados XML por lote pode ser estruturado de forma similar ao modelo de estrutura de dados exemplificativo XML fornecido abaixo: <?XML version ="1.0" encoding ="UTF-8"?> <merchant_data> <merchant_id>3FBCR41NC</merchant_id> <merchant_name>Books & Things, lnc. </merchant_name> <merchant_auth_key>INNF484MCP59CHB27365</merchant_auth_key> <account_number>123456789</account_number> </merchant_data> <transaction_data> <transaction 1>
</ transaction 1> <transaction 2>
</ transaction 2>
<transaction n>
</ transaction n> </transaction_data>
Em algumas implementações, o servidor também pode gerar um recibo de compra, por exemplo, 2343, e fornecer o recibo de compra ao cliente.
O cliente pode renderizar e exibir, por exemplo, 2344, o recibo de compra do usuário.
Por exemplo, o cliente pode renderizar uma página da web, mensagem eletrônica, mensagem de texto/SMS, armazenar 5 em buffer um correio de voz, emitir um toque de chamada, e/ou reproduzir uma mensagem de áudio, etc., e fornecer saída inclusive, porém sem caráter limitativo: sons, música, áudio, vídeo, imagens, feedback táctil, alertas de vibração (por exemplo, dispositivos de cliente com capacidade de vibração como um smartphone etc.), e/ou similares.
Com referência à Figura 23C, em algumas implementações, o servidor de 1O comerciante pode iniciar a declaração de um lote de transações autorizadas.
Por exemplo, o servidor de comerciante pode gerar um pedido de dados de lote, por exemplo, 2345, e fornecer o pedido, por exemplo, 2346, a um banco de dados, por exemplo, banco de dados de comerciante 2304. Por exemplo, o servidor de comerciante pode utilizar comandos PHP/SQL similares aos exemplos fornecidos acima para consultar um banco de dados relacional.
Em resposta ao pedido de dados de lote, o banco de dados pode fornecer os dados de lote solicitados, por exemplo, 2347. O servidor pode gerar uma solicitação de declaração de lote, por exemplo, 2348, utilizando os dados de lote obtidos a partir do banco de dados, e fornecer, por exemplo, 2341, a solicitação de declaração de lote a um servidor adquirente, por exemplo, 231 O.
Por exemplo, o servidor de comerciante pode fornecer uma mensagem HTTP(S) POST que inclui dados de lote formatados em XML no corpo da mensagem do servidor adquirente.
O servidor adquirente pode gerar, por exemplo, 2350, uma solicitação de pagamento de lote utilizando a solicitação de declaração de lote, e fornecer a solicitação de pagamento de lote ao servidor de rede de pagamento, por exemplo, 2351. O servidor de rede de pagamento pode analisar a solicitação de pagamento de lote, e extrair os dados de transação de cada transação armazenados na solicitação de pagamento de lote, por exemplo, 2352. O servidor de rede de pagamento pode armazenar os dados de transação, por exemplo, 2353, para cada transação em um banco de dados, por exemplo, banco de dados de rede de pagamento 2307. Para cada transação extraída, o servidor de rede de pagamento pode consultar, por exemplo, 2354-2355, um banco de dados, por exemplo, banco de dados de rede de pagamento 2307, para um endereço de um servidor emissor.
Por exemplo, o servidor de rede de pagamento pode utilizar comandos PHP/SQL similares aos exemplos fornecidos acima.
O servidor de rede de pagamento pode gerar uma solicitação de pagamento individual, por exemplo, 2356, para cada transação da qual os dados de transação são extraídos, e fornecer a solicitação de pagamento individual, por exemplo, 2357, ao servidor emissor, por exemplo, 2308. Por exemplo, o servidor de rede de pagamento pode fornecer uma solicitação HTTP(S) POST similar ao exemplo abaixo:
POST /requestpay.php HTTP/1.1 Host: www.issuer.com Content-Type: Application/XML Content-Length: 788 <?XML version = "1.0" encoding = "UTF-8"?> <pay_request> <request_ID>CN141CNW2</request_ID> <timestamp>2011-02-22 17: 00: 01 </timestamp> <pay_ amount>$34. 78</pay_amount> <account_params> <account_name>John Q.
Public</account_name> <account_type>cred it</account_type> <account_num> 123456789012345</account_num> <billing_address>123 Green St., Norman, OK 98765</billing_address> <phone> 123-456-7809</phone> <sig n>/jq p/</sig n> </account_params> <merchant_params> <merchant_id>3FBCR41NC</merchant_id> <merchant_name>Books & Things, lnc. </merchant_name> <merchant_auth_key>INNF484MCP59CHB27365</merchant_auth_key> </merchant_params> <purchase_summary> <num_products>l</num_products> <product> <product_summary>Book - XML for dummies</product_summary> <product_quantity>K/product_quantity? </product> </purchase_summary> </pay_req uest> Em algumas implementações, o servidor emissor pode gerar um comando de pagamento, por exemplo, 2358. Por exemplo, o servidor emissor pode emitir um comando para debitar fundos da conta do usuário (ou cobrar uma taxa da conta de cartão de crédito do usuário). O servidor emissor pode emitir um comando de pagamento, por exemplo, 2359, a um banco de dados que armazena as informações de conta do usuário, por exemplo, banco de dados de perfil de usuário 2308. O servidor emissor pode fornecer uma mensagem de transferência de fundos, por exemplo, 2360, ao servidor de rede de pagamento, que pode encaminhar, por exemplo, 2361, a mensagem de transferência de fundos para o servidor adquirente.
Uma mensagem de transferência de fundos HTTP(S) POST exemplificativa é fornecida abaixo: POST /clearance .php HTTP/1.1 5 Host: www.acquirer.com Content-Type: Application/XML Content-Length: 206 <?XML version ="1.0" encoding ="UTF-8"?> <deposit_ack> <request_I D>CNl41 CNW2</request_I D> <clear_flag>true</clear_flag> <timestamp>2011-02-22 17: 00: 02</timestamp> <deposit_amount>$34. 78</deposit_amount> </deposit_ack> Em algumas implementações, o servidor adquirente pode analisar a mensagem de transferência de fundos, e correlacionar a transação (por exemplo, utilizando o campo request_ID no exemplo acima) ao comerciante.
O servidor adquirente pode então transferir os fundos especificados na mensagem de transferência de fundos para uma conta do comerciante, por exemplo, 2362. As Figuras 24A-E mostram diagramas de fluxo lógico que ilustram os aspectos exemplificativos de execução de transação baseada em cartão, resultando na geração de dados de transação baseada em cartão e dados de uso de serviço, em algumas modalidades do UEP, por exemplo, um componente de Execução de Transação Baseada em Cartão ("CTE") 2400. Em algumas implementações, um usuário pode fornecer uma entrada de usuário, por exemplo, 2401, a um cliente indicando o desejo do usuário de comprar um produto de um comerciante.
O cliente pode gerar uma mensagem de pedido de compra, por exemplo, 2402, e fornecer a mensagem de pedido de compra gerada ao servidor de comerciante.
Em algumas implementações, o servidor de comerciante pode obter, por exemplo, 2403, a mensagem de pedido de compra do cliente, e pode analisar a mensagem de pedido de compra para extrair detalhes do pedido de compra do usuário.
Analisadores exemplificativos que o cliente de comerciante pode utilizar são discutidos abaixo com referência à Figura 6i.
O comerciante pode gerar uma consulta de dados de produto, por exemplo, 2404, de um banco de dados de comerciante, que em resposta pode fornecer os dados de produto solicitados, por exemplo, 2405. O servidor de comerciante pode gerar uma solicitação de consulta de cartão utilizando os dados de produto, por exemplo, 2404, para determinar se a transação pode ser processada.
Por exemplo, o servidor de comerciante pode processar a transação apenas se o usuário possuir fundos suficientes para pagar a compra em uma conta de cartão fornecida com o pedido de compra.
O servidor de comerciante pode fornecer opcionalmente a solicitação de consulta de cartão gerada a um servidor adquirente.
O servidor adquirente pode gerar um pedido de autorização de cartão utilizando a solicitação de consulta de cartão obtida, e fornecer o 5 pedido de autorização de cartão a um servidor de rede de pagamento.
Em algumas implementações, o servidor de rede de pagamento pode determinar se o usuário está inscrito em serviços de usuário de valor agregado.
Por exemplo, o servidor de rede de pagamento pode consultar um banco de dados, por exemplo, 2407, para dados de inscrição de serviço de usuário.
Por exemplo, o servidor pode utilizar comandos PHP/SQL 1O similares ao exemplo fornecido acima para consultar o banco de dados de rede de pagamento.
Em algumas implementações, o banco de dados pode fornecer os dados de inscrição de serviço de usuário, por exemplo, 2408. Os dados de inscrição de usuário podem incluir um sinalizador que indica se o usuário está ou não inscrito, bem como instruções, dados, URL de conexão, modelo de chamada de conexão API e/ou similares para facilitar o acesso dos serviços inscritos por usuário.
Por exemplo, em algumas implementações, o servidor de rede de pagamento pode redirecionar o cliente para um servidor de valor agregado (por exemplo, como um servidor de rede social onde o serviço de valor agregado está relacionado à rede social) fornecendo uma mensagem HTTP(S) REDIRECT 300. Em algumas implementações, o servidor de rede de pagamento pode fornecer informações de pagamento extraídas do pedido de autorização de cartão ao servidor de valor agregado como parte de uma solicitação de serviço de valor agregado, por exemplo, 241 O.
Em algumas implementações, o servidor de valor agregado pode fornecer uma solicitação de entrada de serviço, por exemplo, 2411, ao cliente.
O cliente pode exibir, por exemplo, 2412, a solicitação de entrada do usuário.
Em algumas implementações, o usuário pode fornecer a entrada ao cliente, por exemplo, 2413, e o cliente pode gerar uma resposta de entrada de serviço do servidor de valor agregado.
Em algumas implementações, o servidor de valor agregado pode fornecer serviços de valor agregado de acordo com os dados de inscrição de serviço de valor agregado do usuário, perfil de usuário, etc., armazenados no servidor de valor agregado, e baseados na entrada de serviço de usuário.
Com base na provisão de serviços de valor agregado, o servidor de valor agregado pode gerar uma resposta de serviço de valor agregado, por exemplo, 2417, e fornecer a resposta ao servidor de rede de pagamento.
Em algumas implementações, mediante o recebimento da resposta de serviço de valor agregado do servidor de valor agregado, o servidor de rede de pagamento pode extrair os dados de serviço de inscrição da resposta para adição a um registro de dados de transação, por exemplo, 2419-2420.
Com referência à Figura 248, em algumas implementações, o servidor de rede de pagamento pode obter o pedido de autorização de cartão do servidor adquirente, e pode analisar o pedido de autorização de cartão para extrair detalhes do pedido, por exemplo,
2420. Utilizando-se os campos e valores de campo extraídos, o servidor de rede de pagamento pode gerar uma consulta, por exemplo, 2421-2422, para um servidor emissor correspondente à conta de cartão do usuário. Em resposta à obtenção da consulta de servidor emissor, o banco de dados de rede de pagamento pode fornecer, por exemplo, 2422, os dados de servidor emissor solicitados ao servidor de rede de pagamento. Em algumas implementações, o servidor de rede de pagamento pode utilizar os dados de 1O servidor emissor para gerar um pedido de autorização de cartão, por exemplo, 2423, para redirecionar o pedido de autorização de cartão do servidor adquirente para o servidor emissor. O servidor de rede de pagamento pode fornecer o pedido de autorização de cartão ao servidor emissor. Em algumas implementações, o servidor emissor pode analisar, por exemplo, 2424, o pedido de autorização de cartão, e com base nos detalhes de pedido pode consultar um banco de dados, por exemplo, 2425, para dados da conta de cartão do usuário. Em resposta, o banco de dados pode fornecer os dados de usuário solicitados. Ao obter os dados de usuário, o servidor emissor pode determinar se o usuário pode pagar a transação utilizando os fundos disponíveis na conta, por exemplo, 2426. Por exemplo, o servidor emissor pode determinar se o usuário possui um saldo suficiente restante na conta, crédito suficiente associado à conta, e/ou similares, porém compara-se os dados do banco de dados com o custo de transação obtido do pedido de autorização de cartão. Se o servidor emissor determinar que o usuário pode pagar a transação utilizando os fundos disponíveis na conta, o servidor pode fornecer uma mensagem de autorização, por exemplo, 2427, ao servidor de rede de pagamento. Em algumas implementações, o servidor de rede de pagamento pode obter a mensagem de autorização, e analisar a mensagem para extrair os detalhes de autorização. Mediante a determinação que o usuário possui fundos suficientes para a transação (por exemplo, 2430, opção "Sim"), o servidor de rede de pagamento pode extrair a transação de cartão da mensagem de autorização e/ou pedido de autorização de cartão, por exemplo, 2433, e gerar um registro de dados de transação utilizando os detalhes de transação de cartão. O servidor de rede de pagamento pode fornecer o registro de dados de transação para armazenamento, por exemplo, 2434, a um banco de dados. Em algumas implementações, o servidor de rede de pagamento pode encaminhar a mensagem de autorização, por exemplo, 2435, para o servidor adquirente, que por sua vez pode encaminhar a mensagem de autorização, por exemplo, 2436, para o servidor de comerciante. O comerciante pode obter a mensagem de autorização, e analisar a mensagem de autorização para extrair seus conteúdos, por exemplo, 2437. O servidor de comerciante pode determinar se o usuário possui fundos suficientes na conta de cartão para conduzir a transação.
Se o servidor de comerciante determinar que o usuário possui fundos suficientes, por exemplo, 2438, opção "Sim", o servidor de comerciante pode adicionar o registro da transação do usuário a um lote de dados de transação referente a transações 5 autorizadas, por exemplo, 2439-2440. O servidor de comerciante também pode gerar um recibo de compra, por exemplo, 2441, do usuário.
Se o servidor de comerciante determinar que o usuário não possui fundos suficientes, por exemplo, 2438, opção "Não", o servidor de comerciante pode gerar uma mensagem de "falha de autorização", por exemplo, 2442. O servidor de comerciante pode fornecer o recibo de compra ou a mensagem de "falha de 1O autorização" ao cliente.
O cliente pode renderizar e exibir, por exemplo, 2443, o recibo de compra do usuário.
Em algumas implementações, o servidor de comerciante pode iniciar a declaração de um lote de transações autorizadas gerando um pedido de dados de lote, por exemplo, 2444, e fornecer o pedido a um banco de dados.
Em resposta ao pedido de dados de lote, o banco de dados pode fornecer os dados de lote solicitados, por exemplo, 2445, ao servidor de comerciante.
O servidor pode gerar um pedido de declaração de lote, por exemplo, 2446, utilizando os dados de lote obtidos do banco de dados, e fornecer o pedido de declaração de lote a um servidor adquirente.
O servidor adquirente pode gerar, por exemplo, 2448, um pedido de pagamento de lote utilizando o pedido de declaração de lote obtido, e fornecer a solicitação de pagamento de lote a um servidor de rede de pagamento.
O servidor de rede de pagamento pode analisar, por exemplo, 2449, a solicitação de pagamento de lote, selecionar uma transação armazenada dentro dos dados de lote, por exemplo, 2450, e extrair os dados de transação da transação armazenados na solicitação de pagamento de lote, por exemplo, 2451. O servidor de rede de pagamento pode gerar um registro de dados de transação, por exemplo, 2452, e armazenar os dados de transação, por exemplo, 2453, a transação em um banco de dados.
Para a transação extraída, o servidor de rede de pagamento pode gerar uma consulta de servidor emissor, por exemplo, 2454, para um endereço de um servidor emissor mantendo a conta do usuário que solicitou a transação.
O servidor de rede de pagamento pode fornecer a consulta a um banco de dados.
Em resposta, o banco de dados pode fornecer os dados de servidor emissor solicitados pelo servidor de rede de pagamento, por exemplo, 2455. O servidor de rede de pagamento pode gerar uma solicitação de pagamento individual, por exemplo, 2456, para a transação da qual os dados transação são extraídos, e fornecer a solicitação de pagamento individual ao servidor emissor utilizando os dados de servidor emissor do banco de dados.
Em algumas implementações, o servidor emissor pode obter a solicitação de pagamento individual, e analisar, por exemplo, 2457, a solicitação de pagamento individual para extrair detalhes da solicitação.
Com base nos dados extraídos, o servidor emissor pode gerar um comando de pagamento, por exemplo, 2458. Por exemplo, o servidor emissor pode emitir um comando para debitar fundos da conta do usuário (ou cobrar uma taxa da conta de cartão de crédito do usuário). O servidor emissor pode emitir um comando de pagamento, por exemplo, 2459, a um banco de dados que armazena as informações de 5 conta do usuário. Em resposta, o banco de dados pode atualizar um registro de dados correspondentes à conta do usuário para ponderar o débito/taxa realizado na conta do usuário. O servidor emissor pode fornecer uma mensagem de transferência de fundos, por exemplo, 2460, ao servidor de rede de pagamento após o comando de pagamento ser executado pelo banco de dados. Em algumas implementações, o servidor de rede de pagamento pode verificar se há transações adicionais no lote que precisam ser compensadas e financiadas. Se houver transações adicionais, por exemplo, 2461, opção "Sim", o servidor de rede de pagamento pode processar cada transação de acordo com o procedimento descrito acima. O servidor de rede de pagamento pode gerar, por exemplo, 2462, uma mensagem de transferência de fundos agregada que ponderar a transferência de todas as transações no lote, e fornecer, por exemplo, 2463, a mensagem de transferência de fundos ao servidor adquirente. O servidor adquirente pode, em resposta, transferir os fundos especificados na mensagem de transferência de fundos para uma conta do comerciante, por exemplo, 2464. A Figura 25 mostra um diagrama de fluxo de dados que ilustra um procedimento exemplificativo para agregar uma transação baseada em cartão data em algumas modalidades do UEP. Em algumas implementações, o servidor de rede de pagamento pode determinar um escopo de agregação de dados exigido para realizar a análise, por exemplo,
2511. O servidor de rede de pagamento pode iniciar a agregação de dados baseada no escopo determinado. O servidor de rede de pagamento pode gerar uma consulta para dados de transação de armazenamento de endereços de servidor dentro do escopo determinado. O servidor de rede de pagamento pode consultar, por exemplo, 2512, um banco de dados de rede de pagamento, por exemplo, 2507a, para endereços de servidores de rede de pagamento que podem possuir dados de transação armazenados dentro do escopo determinado da agregação de dados. Por exemplo, o servidor de rede de pagamento pode utilizar comandos PHP/SQL similares aos exemplos fornecidos acima. O banco de dados pode fornecer, por exemplo, 2513, uma lista de endereços de servidor em resposta à consulta do servidor de rede de pagamento. Com base na lista de endereços de servidor, o servidor de rede de pagamento pode gerar pedidos de dados de transação, por exemplo,
2514. O servidor de rede de pagamento pode emitir os pedidos de dados de transação gerados, por exemplo, 2515a-c, para outros servidores de rede de pagamento, por exemplo, 2505b-d. Os servidores de rede de pagamento podem consultar, por exemplo, 251 ?a-c, seu banco de dados de rede de pagamento, por exemplo, 2507a-d, para dados de transação dentro do escopo dos pedidos de dados de transação. Em resposta às consultas de dados de transação, os bancos de dados de rede de pagamento podem fornecer dados de transação, por exemplo, 2518a-c, aos outros servidores de rede de pagamento. Os outros servidores de rede de pagamento podem retornar os dados de transação obtidos dos 5 bancos de dados de rede de pagamento, por exemplo, 2519a-c, ao servidor de rede de pagamento que realiza os pedidos de dados de transação, por exemplo, 2505a. O servidor de rede de pagamento, por exemplo, 2505a, pode armazenar os dados de transação agregados, por exemplo, 2520, em um banco de dados de transações agregados, por exemplo, 251 Oa. A Figura 26 mostra um diagrama de fluxo lógico que ilustra os aspectos exemplificativos de agregação de dados de transação baseada em cartão em algumas modalidades do UEP, por exemplo, um componente de Agregação de Dados de Transação ("TOA") 2600. Em algumas implementações, um servidor de rede de pagamento pode obter um gerador para agregar os dados de transação, por exemplo, 2601. Por exemplo, o servidor pode ser configurado para iniciar a agregação de dados de transação em uma base regular, periódica (por exemplo, de hora em hora, diariamente, semanalmente, mensalmente, trimestralmente, semi-anualmente, anualmente, etc.). Como outro exemplo, o servidor pode ser configurado para iniciar a agregação de dados de transação mediante a obtenção de informações que o Governo norte-americano (por exemplo, Department of Commerce, Office of Management and Budget, etc) liberou para novos dados estatísticos relacionados à economia U.S .. Como outro exemplo, o servidor pode ser configurado para iniciar a agregação de dados de transação sob demanda, mediante a obtenção de um pedido de análise de estratégia de investimento de usuário para processamento. O servidor de rede de pagamento pode determinar um escopo de agregação de dados exigido para realizar a análise, por exemplo, 2602. Por exemplo, o escopo de agregação de dados pode ser pré-determinado. Como outro exemplo, o escopo de agregação de dados pode ser determinado com base em um pedido de análise de estratégia de investimento de usuário. O servidor de rede de pagamento pode iniciar a agregação de dados com base no escopo determinado. O servidor de rede de pagamento pode gerar uma consulta para endereços de servidor que armazena dados de transação dentro do escopo determinado, por exemplo,
2603. O servidor de rede de pagamento pode consultar um banco de dados para endereços de servidores de rede de pagamento que podem ter dados de transação armazenados dentro do escopo determinado da agregação de dados. O banco de dados pode fornecer, por exemplo, 2604, uma lista de endereços de servidor em resposta à consulta do servidor de rede de pagamento. Com base na lista de endereços de servidor, o servidor de rede de pagamento pode gerar pedidos de dados de transação, por exemplo, 2605. O servidor de rede de pagamento pode emitir os pedidos de dados de transação gerados para os outros servidores de rede de pagamento.
Os outros servidores de rede de pagamento podem obter e analisar os pedidos de dados de transação, por exemplo, 2606. Com base na análise dos pedidos de dados, os outros servidores de rede de pagamento podem gerar consultas de dados de transação, por exemplo, 2607, e fornecer as consultas de dados de transação a 5 seus bancos de dados de rede de pagamento.
Em resposta às consultas de dados de transação, os bancos de dados de rede de pagamento podem fornecer dados de transação, por exemplo, 2608, aos outros servidores de rede de pagamento.
Os outros servidores de rede de pagamento podem retornar, por exemplo, 2609, os dados de transação obtidos dos bancos de dados de rede de pagamento para o servidor de rede de pagamento que realiza 1O os pedidos de dados de transação.
O servidor de rede de pagamento pode gerar registros de dados de transação agregados a partir dos dados de transação recebidos dos outros servidores de rede de pagamento, por exemplo, 261 O, e armazenar os dados de transação agregados em um banco de dados, por exemplo, 2611. A Figura 27 mostra um diagrama de fluxo de dados que ilustra um procedimento de agregação de dados sociais exemplificativo em algumas modalidades do UEP.
Em algumas implementações, o servidor de rede de pagamento pode obter um gerador para realizar uma pesquisa de dados sociais.
Por exemplo, o servidor de rede de pagamento pode realizar periodicamente uma atualização de seu banco de dados sociais agregados, por exemplo, 2710, com novas informações disponíveis a partir de uma variedade de fontes, como os serviços de rede social que operam na Internet.
Como outro exemplo, um pedido de atualização de dados sociais sob demanda pode ser obtido como resultado de um desejo do usuário para se inscrever em um serviço, para o qual o servidor de rede de pagamento pode facilitar a entrada de dados que fornece um sistema de preenchimento de formulários da web automático utilizando informações sobre o usuário obtidas a partir da atualização de dados sociais.
Em algumas implementações, o servidor de rede de pagamento pode analisar o gerador para extrair as palavras-chave utilizando as mesmas para realizar uma atualização de dados sociais agregados.
O servidor de rede de pagamento pode gerar uma consulta para modelos de interface de programação de aplicativo (API) de vários serviços de rede social (por exemplo, Facebook®, Twitter™, etc.) desse para coletar dados sociais para agregação.
O servidor de rede de pagamento pode consultar, por exemplo, 2712, um banco de dados de rede de pagamento, por exemplo, 2707, para modelos de rede social API para os serviços de rede social.
Por exemplo, o servidor de rede de pagamento pode utilizar comandos PHP/SQL similares aos exemplos fornecidos acima.
O banco de dados pode fornecer, por exemplo, 2713, uma lista de modelos API em resposta.
Com base na lista de modelos API, o servidor de rede de pagamento pode gerar pedidos de dados sociais, por exemplo, 2714. O servidor de rede de pagamento pode emitir os pedidos de dados sociais gerados, por exemplo, 2715a-c, para os servidores de rede social, por exemplo, 2701 a-c.
Por exemplo, o servidor de rede de pagamento pode emitir comandos PHP para solicitar aos servidores de rede social os dados sociais.
Uma listagem exemplificativa de comandos para emitir pedidos de dados sociais 2715a-c, substancialmente sob a forma de comandos PHP, é fornecida abaixo: 5 <?PHP header ('Content-Type: text/plain');
li Obtain usuário ID(s) of friends of the logged-in user $friends = json_decode ( file_get_contents ('https: //graph . facebook . com/me/ friends?access token='$cookie ['oauth_access_token'] ), true) ; $friend_ids = array_keys ( $friends) ;
li Obtain mensagem feed associated with the profile of the logged-in user $feed = json_decode ( file_get_contents ( <1 > https: 11 graph . facebook . com/me/ feed?access_tok en='$cookie [ Oauth_access_token'] ), true) ; li Obtain messages by the user's friends $result = mysql_query ('SELECT * FROM content WHERE uid IN (' . implode ($friend_ids, ', ') .')') ; $friend_content = array (); while ($row = mysql_fetch_assoc ( $result ) ) $friend_content [ ] $row; ?> Em algumas modalidades, os servidores de rede social podem consultar, por exemplo, 271 ?a-c, seus bancos de dados, por exemplo, 2702a-c, para resultados de dados sociais que estão dentro do escopo das palavras-chave sociais.
Em resposta às consultas, os bancos de dados podem fornecer dados sociais, por exemplo, 271 Ba-c, aos servidores de mecanismo de pesquisa.
Os servidores de rede social podem retornar os dados sociais obtidos a partir dos bancos de dados, por exemplo, 2719a-c, para o servidor de rede de pagamento que realiza os pedidos de dados sociais.
Uma listagem exemplificativa de dados sociais 2719a-c, substancialmente sob a forma de dados formatados em JavaScript Object Notation (JSON), é fornecida abaixo: [ "data" { "name": "Tabatha Orloff'', "id": "483722"},
{ "name": "Darren Kinnaman", "id": "86[Xi]743"}, { "name": "Sharron Jutras", "id": "091274"} ] } Em algumas modalidades, o servidor de rede de pagamento pode armazenar os resultados de pesquisa agregados, por exemplo, 2720, em um banco de dados de pesquisa agregado, por exemplo, 271 O. A Figura 28 mostra um diagrama de fluxo lógico que ilustra os aspectos exemplificativos de agregação de dados sociais em algumas modalidades do UEP, por exemplo, um componente de Agregação de Dados Sociais ("SOA") 2800. Em algumas implementações, o servidor de rede de pagamento pode obter um gerador para realizar uma pesquisa social, por exemplo, 2801. Por exemplo, o servidor de rede de pagamento pode realizar periodicamente uma atualização de seu banco de dados sociais agregados com novas informações disponíveis a partir de uma variedade de fontes, como a Internet. Como outro exemplo, um pedido de atualização de dados sociais sob demanda pode ser obtido como resultado de um desejo do usuário de se inscrever em um serviço, para o qual o servidor de rede de pagamento pode facilitar a entrada de dados fornecendo um sistema de preenchimento de formulários automático da web utilizando informações sobre o usuário obtidas a partir da atualização de dados sociais. Em algumas implementações, o servidor de rede de pagamento pode analisar o gerador, por exemplo, 2802, para extrair as palavras- chave e/ou ID(s) de usuário utilizadas para realizar uma pesquisa agregada de dados sociais. O servidor de rede de pagamento pode determinar os serviços de rede social de pesquisa, por exemplo, 2803, utilizando as palavras-chave e/ou ID(s) de usuário extraídas. Então, o servidor de rede de pagamento pode gerar uma consulta para modelos de interface de programação de aplicativo (API) para os vários serviços de rede social (por exemplo, Facebook®, Twitter™, etc.) para coletar os dados sociais para agregação, por exemplo,
2804. O servidor de rede de pagamento pode consultar, por exemplo, 2805, um banco de dados de rede de pagamento para pesquisar modelos API dos serviços de rede social. Por exemplo, o servidor de rede de pagamento pode utilizar comandos PHP/SQL similares aos exemplos fornecidos acima. O banco de dados pode fornecer, por exemplo, 2805, uma lista de modelos API em resposta. Com base na lista de modelos API, o servidor de rede de pagamento pode gerar pedidos de dados sociais, por exemplo, 2806. O servidor de rede de pagamento pode emitir os pedidos de dados sociais gerados para os serviços de rede social. Os servidores de rede social pode analisar o(s) resultado(s) de pesquisa obtido(s), por exemplo, 2807, e consultar, por exemplo, 2808, seus bancos de dados para dados sociais estão dentro do escopo das palavras-chave de pesquisa. Em resposta às consultas de dados sociais, os bancos de dados podem fornecer dados sociais, por exemplo, 2809, aos servidores de rede social.
Os servidores de rede social podem retornar os dados sociais obtidos a partir dos bancos de dados, por exemplo, 2810, para o servidor de rede de pagamento fazendo pedidos de dados sociais.
O servidor de rede de pagamento pode gerar, por exemplo, 2811, e armazenar os dados sociais agregados, por exemplo, 2812, em um banco de dados sociais agregados.
A Figura 29 mostra um diagrama de fluxo de dados que ilustra um procedimento exemplificativo para inscrição em serviços de valor agregado em algumas modalidades do UEP.
Em algumas implementações, um usuário, por exemplo, 2901, pode desejar se inscrever em um serviço de valor agregado.
Aqui considera-se um exemplo em que o usuário deseja se inscrever em um pagamento de compra autenticada de rede social como um serviço de valor agregado.
Será entendido que qualquer outro serviço de valor agregado pode substituir o serviço de valor agregado descrito abaixo.
O usuário pode se comunicar com um servidor de rede de pagamento, por exemplo, 2903, através de um cliente como, porém sem caráter limitativo: um computador pessoal, dispositivo móvel, televisão, terminal de ponto de venda, quiosque, ATM, e/ou similares (por exemplo, 2902). Por exemplo, o usuário pode fornecer uma entrada de usuário, por exemplo, entrada de inscrição 2911, ao cliente indicando o desejo do usuário de se inscrever em um pagamento de compra autenticada de rede social.
Em várias implementações, a entrada de usuário pode incluir, porém sem caráter limitativo: um único toque (por exemplo, uma modalidade de compra com aplicativo móvel em um toque) de uma interface de tela sensível ao toque, entrada de teclado, passagem de cartão, ativar um dispositivo de hardware habilitado RFID/NFC (por exemplo, cartão eletrônico com múltiplas contas, smartphone, tablet, etc.) dentro do dispositivo de usuário, cliques de mouse, pressionamentos de botões em um joystick/console de jogo, comandos de voz, gestos de único/múltiplo toque em uma interface sensível ao toque, tocar os elementos de interface de usuário em uma tela sensível ao toque, e/ou similares.
Por exemplo, o usuário pode passar um cartão de pagamento no cliente 2902. Em algumas implementações, o cliente pode obter dados de rastreamento do cartão do usuário como a entrada de inscrição 2911 (por exemplo, cartão de crédito, cartão de débito, cartão pré-pago, cartão de carga, etc.), como os dados de rastreamento exemplificativos fornecidos abaixo: %B123456789012345"PUBLIC/ J.
Q. "99011200000000000000* * 901 * * * * * * ?* (em que '123456789012345' é o número do cartão de V.Q.
Public' e possui um número CW de 901 . '990112 'é um código de serviço, e*** representa os dígitos decimais que mudam aleatoriamente toda vez que o cartão é usado)
Em algumas implementações, utilizando-se a entrada do usuários, o cliente pode gerar um pedido de inscrição, por exemplo, 2912, e fornecer o pedido de inscrição, por exemplo, 2913, ao servidor de rede de pagamento.
Por exemplo, o cliente pode fornecer uma mensagem POST de Protocolo de Transferência de Hipertexto ("HTTP(S)) (Secure) que inclui os dados formatados de acordo com a Linguagem de Marcação extensível ("XML"). Abaixo está uma mensagem POST HTTP(S) exemplificativa que inclui um pedido de inscrição formatado em XML do servidor de rede de pagamento: POST /enroll. php HTTP/1.1 Host: www.merchant.com Content-Type: Application/XML Content-Length: 718 <?XML version ="1.0" encoding ="UTF-8"?> <enrollment_request> <cart_I D>4NFU4RG94</order_I D> <timestamp>2011-02-22 15: 22: 43</timestamp> <usuário_ID>john. q. publicSgmail. com</user_ID> <client_details> <client_I P> 192.168.23.126</client_I P> <cl ient_type>smartphone</cl ient_type> <client_model>HTC Hero</client_model> <OS>Android 2.2</0S> <app_installed_flag>true</app_installed_flag> </client_details> < ! --account_params> <optional> <account_name>John Q.
Public</account_name> <account_type>credit</account_type> <account_num> 123456789012345</account_num> <billing_address>123 Green St., Norman, OK 98765</billing_address> <phone> 123-456-7809</phone> <sig n>/jq p/</sig n> <confirm_type>email</confirm_type> <contact_info>john . q . publicSgmail . com</contact_info> </account_params--> <checkout_purchase_details> <num_products>l</num_products> <product> <prod uct_type>book</prod uct_type>
<product_params> <product_title>XML for dummies<lproduct_title> <ISBN>938-2-14-168710-0<llSBN> <edition>2nd ed. <ledition> 5 <cover>hardbound<I cover> <seller>bestbuybooks<lseller> <lproduct_params> <quantity>K/quantity> <lproduct> </checkout_purchase_details> <len roll ment_req uest> Em algumas implementações, o servidor de rede de pagamento pode obter o pedido de inscrição do cliente, e extrair os detalhes de pagamento do usuário (por exemplo, dados XML) do pedido de inscrição.
Por exemplo, o servidor de rede de pagamento pode utilizar um analisador como os analisadores exemplificativos descritos abaixo na discussão com referência à Figura 6i.
Em algumas implementações, o servidor de rede de pagamento pode consultar, por exemplo, 2914, um banco de dados de rede de pagamento, por exemplo, 2904, para obter um modelo de pedido de rede social, por exemplo, 2915, para processar o pedido de inscrição.
O modelo de pedido de rede social pode incluir instruções, dados, URL de conexão, modelo de chamada API de conexão e/ou similares para facilitar a autenticação de rede social.
Por exemplo, o banco de dados pode ser um banco de dados relacional responsivo a comandos de Linguagem de Consulta Estruturada ("SQL"). O servidor de comerciante pode executar um script de pré-processador de hipertexto ("PHP") que inclui comandos SQL para consultar o banco de dados para dados de produto.
Uma listagem de comando PHP/SQL exemplificativa que ilustra os aspectos independentes de consultar o banco de dados, por exemplo, 2914-2915, é fornecida abaixo: <?PHP header ('Content-Type: textlplain'); mysql_connect ("254.93.179.112", $DBserver, $password) li access database server mysql_select_db ( "SOCIALAUTH . SQL" ) ; li select database table to search //create query $query ="SELECT template FROM EnrollTable WHERE network LIKE'%'$socialnet"
$result =mysql_query ( $query) ; li perform the search query mysql_close ("SOCIALAUTH.
SQL") ; li close database access ?>
Em algumas implementações, o servidor de rede de pagamento pode redirecionar o cliente para um servidor de rede social fornecendo uma mensagem HTIP(S) REDIRECT 300, similar ao exemplo abaixo: HTTP/1.1 300 Multiple Choices Location: https://www.facebook.com/dialog/oauth?client_id=snpa_app_ID&redirect_uri= www . paynetwork . com/enroll . php <html> <headxtitle>300 Multiple Choices</title></head> <body><h1 >Multiple Choices</hlx/body> </html> Em algumas implementações, o servidor de rede de pagamento pode fornecer informações de pagamento extraídas do pedido de autorização de cartão ao servidor de rede social como parte de um pedido de inscrição de autenticação de rede social, por exemplo, 2917. Por exemplo, o servidor de rede de pagamento pode fornecer uma mensagem HTTP(S) POST ao servidor de rede social, similar ao exemplo abaixo: POST /authenticate_enroll .php HTTP/1.1 Host: www.socialnet.com Content-Type: Application/XML Content-Length: 1306 <?XML version = "1.0" encoding = "UTF-8"?> <authenticate_ enrollment_req uest> <request_ID>4NFU4RG94</order_ID> <timestamp>2011-02-22 15: 22: 43</timestamp> <user_ID>john.q. publicSgmail . com</user_ID> <client_details> <client_I P> 192.168 .23.126</client_I P> <client_type>smartphone</client_type> <client_model>HTC Hero</client_model> <OS>Android 2.2</0S> <app_installed_flag>true</app_installed_flag> </client_details> <account_params> <account_name>John Q.
Public</account_name> <account_type>credit</account_type> <account_num> 123456789012345</account_num> <billing_address>123 Green St., Norman, OK 98765</billing_address>
<phone> 123-456-7809</phone> <sign>/jqp/</sign> <confirm_type>email</confirm_type> <contact_info>john.q. public@gmail.com</contact_info> 5 </account_params> </authenticate_enrollment_request> Em algumas implementações, o servidor de rede social pode fornecer um pedido de conexão de rede social, por exemplo, 2918, ao cliente.
Por exemplo, o servidor de rede social pode fornecer um formulário de entrada HTML ao cliente.
O cliente pode exibir, por 1O exemplo, 2919, o formulário de conexão do usuário.
Em algumas implementações, o usuário pode fornecer uma entrada de conexão ao cliente, por exemplo, 2920, e o cliente pode gerar uma resposta de conexão de rede social, por exemplo, 2921, ao servidor de rede social.
Em algumas implementações, o servidor de rede social pode autenticar os credenciais de conexão do usuário, e acessar informações de conta de pagamento do usuário armazenadas dentro da rede social, por exemplo, em um banco de dados de rede social.
Mediante a autenticação, o servidor de rede social pode gerar um registro de dados de autenticação do usuário, por exemplo, 2922, e fornecer uma notificação de inscrição, por exemplo, 2924, ao servidor de rede de pagamento.
Por exemplo, o servidor de rede social pode fornecer uma mensagem HTTP(S) POST similar ao exemplo abaixo: POST /enrollnotification.php HTTP/ 1 . 1 Host: www.paynet.com Content-Type: Application/XML Content-Length: 1306 <?XML version =" 1 . O" encoding ="UTF-8 " ?> <enroll_notification> <request_ID>4NFU4RG94</order_ID> <timestamp>2011- 02 -22 15: 22: 43</timestamp> <result>enrolled</result> </enroll_notification> Mediante o recebimento de notificação de inscrição do servidor de rede social, o servidor de rede de pagamento pode gerar, por exemplo, 2925, um registro de dados de inscrição de usuário, e armazenar o registro de dados de inscrição em um banco de dados de rede de pagamento, por exemplo, 2926, para concluir a inscrição.
Em algumas implementações, o registro de dados de inscrição pode incluir as informações da notificação de inscrição 2924. A Figura 30 mostra um diagrama de fluxo lógico que ilustra os aspectos exemplificativos de inscrição em um serviço de valor agregado em algumas modalidades do
UEP, por exemplo, um componente de Inscrição de Serviço de Valor Agregado ("VASE")
3000. Em algumas implementações, um usuário, por exemplo, 2901, pode desejar se inscrever em um serviço de valor agregado. Aqui considera-se um exemplo em que o usuário deseja se inscrever em um pagamento de compra autenticada de rede social como um serviço de valor agregado. Será entendido que qualquer outro serviço de valor agregado pode substituir o serviço de valor agregado descrito abaixo. O usuário pode se comunicar com um servidor de rede de pagamento através de um cliente. Por exemplo, o usuário pode fornecer uma entrada de usuário, por exemplo, 3001, ao cliente indicando o desejo do usuário de se inscrever em um pagamento de compra autenticada de rede social. Em várias 1O implementações, a entrada de usuário pode incluir, porém sem caráter limitativo: um único toque (por exemplo, uma modalidade de compra com aplicativo móvel em um toque) de uma interface de tela sensível ao toque, entrada de teclado, passagem de cartão, ativação de um dispositivo de hardware habilitado RFID/NFC (por exemplo, cartão eletrônico com múltiplas contas, smartphone, tablet, etc.) dentro do dispositivo de usuário, cliques de mouse, pressionamentos de botões em um joystick/console de jogo, comandos de voz, gestos de único/múltiplo toque em uma interface sensível ao toque, tocar os elementos de interface de usuário em uma tela sensível ao toque, e/ou similares. Em algumas implementações, utilizando-se a entrada do usuário, o cliente pode gerar um pedido de inscrição, por exemplo, 3002, e fornecer o pedido de inscrição ao servidor de rede de pagamento. Em algumas implementações, o SNPA pode gerar um botão de inscrição que pode conduzir o usuário para uma página de inscrição onde as informações de conta podem ser inseridas em campos de formulário da web. Em algumas implementações, o servidor de rede de pagamento pode obter o pedido de inscrição do cliente, e extrair os detalhes de pagamento do usuário do pedido de inscrição. Por exemplo, o servidor de rede de pagamento pode utilizar um analisador como os analisadores exemplificativos descritos abaixo na discussão com referência à Figura 61. Em algumas implementações, o servidor de rede de pagamento pode consultar, por exemplo, 3004, um banco de dados de rede de pagamento para obter um modelo de pedido de rede social, por exemplo, 3005, para processar o pedido de inscrição. O modelo de pedido de rede social pode incluir instruções, dados, URL de conexão, modelo de chamada API de conexão e/ou similares para facilitar a autenticação de rede social. Em algumas implementações, o servidor de rede de pagamento pode fornecer as informações de pagamento extraídas do pedido de autorização de cartão ao servidor de rede social como parte de um pedido de inscrição de autenticação de rede social, por exemplo, 3006. Em algumas implementações, o servidor de rede social pode fornecer um pedido de conexão de rede social, por exemplo, 3007, ao cliente. Por exemplo, o servidor de rede social pode fornecer um formulário de entrada HTML ao cliente. O cliente pode exibir, por exemplo, 3008, o formulário de conexão do usuário. Em algumas implementações, o usuário pode fornecer a entrada de conexão ao cliente, por exemplo, 3009, e o cliente pode gerar uma resposta de conexão de rede social ao servidor de rede social.
Em algumas implementações, o servidor de rede social pode autenticar as credenciais de conexão do usuário, e acessar informações de conta de pagamento do usuário armazenadas dentro da rede social, por exemplo, em um banco de dados de rede social.
Mediante a autenticação, o servidor de rede social pode gerar um registro de dados de autenticação do usuário, por exemplo, 3011, e fornecer uma notificação de inscrição ao servidor de rede de pagamento, por exemplo, 3013. Mediante o recebimento da notificação de inscrição do servidor de rede social, o servidor de rede de pagamento pode gerar, por exemplo, 3014, um registro de 1O dados de inscrição de usuário, e armazenar o registro de dados de inscrição em um banco de dados de rede de pagamento, por exemplo, 3015, para concluir a inscrição.
O servidor de rede de pagamento pode fornecer uma confirmação de inscrição, e fornecer a confirmação de inscrição ao cliente, que pode exibir, por exemplo, 3017, a confirmação para o usuário.
As Figuras 31A-B mostram diagramas de fluxo que ilustram os aspectos exemplificativos de normalização de pesquisa agregada, inscrição, uso de serviço, transação e/ou outros dados agregados em um formato de dados padronizado em algumas modalidades do UEP, por exemplo, um componente de Normalização de Registro de Dados Agregados ("ADRN") 3100. Com referência à Figura 31A, em algumas implementações, um servidor de rede de pagamento ("servidor") pode tentar converter quaisquer registros de dados agregados armazenados em um banco de dados de registros agregados aos quais esse tem acesso em um formato de dados normalizado.
Por exemplo, o banco de dados pode ter um modelo de registro de dados de transação com campos padrão predeterminados que podem armazenar dados em formatos predefinidos (por exemplo, número inteiro longo /double float / 4 dígitos de precisão, etc.) em uma estrutura de dados predeterminada.
Um modelo de registro de dados de transação XML exemplificativo é fornecido abaixo: <?XML version =" 1 . O" encoding ="UTF-8 " ?> <transação_record> <record_I 0>00000000</record_I D> <norm_flag>false</norm_flag> <timestamp>yyyy-mm-dd hh:mm: ss</timestamp> <transação_cost>$0, 000, 000, 00</transaction_cost> <merchant_params> <merchant_id>OOOOOOOO</merchant_id> <merchant_name> TBD</merchant_name> <merchant_auth_key>OOOOOOOOOOOOOOOO</merchant_auth_key> </merchant_params>
<merchant_products> <num_products>OOO</num_products> <product> <product_type>TBD</product_type> 5 <product_name> TBD</product_name> <class_labels_list>TBD<class_labels_list> <product_quantity>OOO</product_quantity> <unit_value>$0, 000, 000.00</unit_value> <sub_total>$0, 000, 000.00</sub_total> <comment>normalized transaction data record template</comment> </product> </merchant_products> <usuário _account_params> <account_name>JTBD</account_name> <account_type>TBD</account_type> <account_num>OOOOOOOOOOOOOOOO</account_num> <billing_linel> TBD</billing_line1 > <billing_line2> TBD</billing_line2> <zipcode> TBD</zipcode> <state> TBD</state> <country> TBD</country> <phone>00-00-000-000-0000</phone> <sign> TBD</sign> </usuário_account_params> </transaction_record> Em algumas implementações, o servidor pode consultar um banco de dados para um modelo de registro de dados normalizado, por exemplo, 3101. O servidor pode analisar o modelo de registro de dados normalizado, por exemplo, 3102. Com base na análise do modelo de registro de dados normalizado, o servidor pode determinar os campos de dados incluídos no modelo de registro de dados normalizado, e o formato dos dados armazenados nos campos do modelo de registro de dados, por exemplo, 3103. O servidor pode obter registros de dados de transação para normalização.
O servidor pode consultar um banco de dados, por exemplo, 3104, para registros não normalizados.
Por exemplo, o servidor pode emitir comandos PHP/SQL para recuperar registros que não possuem o campo 'norm_flag' do modelo exemplificativo acima, ou aqueles em que o valor do campo 'norm_flag' é 'falso'. Mediante a obtenção dos registros de dados de transação não normalizados, o servidor pode selecionar um dos registros de dados de transação não normalizados, por exemplo,
3105. O servidor pode analisar o registro de dados de transação não normalizado, por exemplo, 3106, e determinar os campos presentes no registro de dados de transação não normalizado, por exemplo, 3107. Por exemplo, o servidor pode utilizar um procedimento similar a um descrito abaixo com referência à Figura 32. O servidor pode comparar os 5 campos do registro de dados de transação não normalizado com os campos extraídos do modelo de registro de dados de transação normalizado.
Por exemplo, o servidor pode determinar se os identificadores de campo de campos no registro de dados de transação não normalizado correspondem àqueles do modelo de registro de dados de transação normalizado, (por exemplo, através de um dicionário, thesaurus, etc.), são idênticos, 1O sinônimos, estão relacionados, e/ou similares.
Com base na comparação, o servidor pode gerar um mapeamento 1: 1 entre os campos do registro de dados de transação não normalizado correspondentes àqueles do modelo de registro de dados de transação normalizado, por exemplo, 3109. O servidor pode gerar uma cópia do modelo de registro de dados de transação normalizado, por exemplo, 311 O, e preencher os campos do modelo utilizando valores do registro de dados de transação não normalizado, por exemplo, 3111. O servidor também pode mudar o valor do campo 'norm_flag' para verdadeiro' no exemplo acima.
O servidor pode armazenar o registro preenchido em um banco de dados (for exemplo, substituindo a versão original), por exemplo, 3112. O servidor pode repetir o procedimento acima para cada registro de dados de transação não normalizado (veja, por exemplo, 3113), até todos os registros de dados de transação não normalizados serem normalizados.
Com referência à Figura 31 B, em algumas modalidades, o servidor pode utilizar metadados (por exemplo, dados facilmente configuráveis) para conduzir uma analítica e mecanismo de regra que pode converter quaisquer dados estruturados em um formato XML padronizado ("criptografia" XML). A criptografia XML pode ser então processada por um mecanismo de criptografia que é capaz de analisar, transformar e examinar dados para gerar decisões baseadas nos resultados da análise.
Consequentemente, em algumas modalidades, o servidor pode implementar um mecanismo de interpretação baseado em metadados que analisa dados estruturados, inclusive, porém sem caráter limitativo: conteúdo da web (veja, por exemplo, 3121), bancos de dados gráficos (veja, por exemplo, 3122), micro blogs, imagens ou código de software (veja, por exemplo, 3124), e converte os dados estruturados em comandos no formato de arquivo de criptografia XML.
Por exemplo, os dados estruturados podem incluir, sem limitação, código de software, imagens, texto livre, consultas de banco de dados relacional, consultas de gráficos, entradas sensoriais (veja, por exemplo, 3123, 3125), e/ou similares.
Um mecanismo de interpretação baseado em metadados, por exemplo, 3126, pode preencher um objeto de dados/ comando, por exemplo, 3127, com base em um determinado registro utilizando metadados configuráveis,
por exemplo, 3128. Os metadados configuráveis podem definir uma ação para um determinado glifo ou palavra-chave contida dentro de um registro de dados.
O mecanismo pode então processar o objeto para exportar sua estrutura de dados como uma coleta de valores criptográficos em um formato de arquivo padrão de criptografia XML, por exemplo, 5 3129. O arquivo de criptografia XML pode ser então processado para fornecer vários recursos por um mecanismo de criptografia, por exemplo, 3130. Em algumas modalidades, o servidor pode obter os dados estruturados, e realizar uma rotina de padronização utilizando os dados estruturados como entrada (por exemplo, incluindo comandos de script, para ilustração). Por exemplo, o servidor pode remover 1O quebras de linha, espaços, espaços de tabulação adicionais, etc. dos dados estruturados, por exemplo, 3131. O servidor pode determinar e carregar uma biblioteca de metadados, por exemplo, 3132, utilizando o servidor que pode analisar sub-rotinas ou funções dentro do script, com base nos metadados, por exemplo, 3133-3134. Em algumas modalidades, o servidor pode pré-analisar declarações condicionais com base nos metadados, por exemplo, 3135-3136. O servidor também pode analisar os dados 3137 para preencher um objeto de dados/comando com base nos metadados e análise anterior, por exemplo, 3138. Mediante a finalização do objeto de dados/comando, o servidor pode exportar 3139 o objeto de dados/comando como XML em um formato padronizado.
A Figura 32 mostra um diagrama de fluxo lógico que ilustra os aspectos exemplificativos de reconhecimento de campos de dados em registros de dados agregados normalizados em algumas modalidades do UEP, por exemplo, um componente de Reconhecimento de Campo de Dados ("DFR") 3200. Em algumas implementações, um servidor pode reconhecer o tipo de campos de dados incluído em um registro de dados, por exemplo, data, endereço, código postal, nome, ID de usuário, endereço de e-mail, número de conta de pagamento (PAN), números CW2, e/ou similares.
O servidor pode selecionar um registro de dados não processados para processamento, por exemplo, 3201. O servidor pode analisar a regra de registro de dados, e extrair os campos de dados do registro de dados, por exemplo, 3202. O servidor pode consultar um banco de dados para modelos de campo de dados, por exemplo, 3203. Por exemplo, o servidor pode comparar o formato dos campos do registro de dados com os modelos de registro de dados para identificar uma correspondência entre um dos modelos de campo de dados e cada campo dentro do registro de dados, identificando assim o tipo de cada campo dentro do registro de dados.
O servidor pode então selecionar um campo de dados extraído do registro de dados, por exemplo, 3204. O servidor pode selecionar um modelo de campo de dados para comparação com o campo de dados selecionado, por exemplo, 3205, e comparar o modelo de campo de dados com o campo de dados selecionado, por exemplo, 3206, para determinar se o formato de campo de dados extraído corresponde ao formato de modelo de campo de dados, por exemplo, 3207. Se o formato do campo de dados extraído selecionado corresponder ao formato do modelo de campo de dados, por exemplo, 3208, opção "Sim", o servidor pode atribuir o tipo de modelo de campo de dados ao campo de dados selecionado, por exemplo, 3209. Se o formato do campo de dados extraído não corresponder ao formato 5 do modelo de campo de dados, por exemplo, 3208, opção "Não", o servidor pode experimentar outro modelo de campo de dados até mais nenhum modelo de campo de dados estar disponível para comparação, veja, por exemplo, 321 O.
Se nenhuma correspondência for encontrada, o servidor pode atribuir uma sequência "desconhecida" como o tipo do campo de dados, por exemplo, 3211. O servidor pode armazenar o registro de dados atualizado no banco de dados, por exemplo, 3212. O servidor pode realizar esse reconhecimento de campo de dados para cada campo de dados no registro de dados (e também para cada registro de dados no banco de dados), veja, por exemplo, 3213. A Figura 33 mostra um diagrama de fluxo lógico que ilustra os aspectos exemplificativos de classificação de tipos de entidade em algumas modalidades do UEP, por exemplo, um componente de Classificação de Tipo de Entidade ("ETC") 3300. Em algumas implementações, um servidor pode aplicar um ou mais rótulos de classificação a cada registro de dados.
Por exemplo, o servidor pode classificar os registros de dados de acordo com o tipo de entidade, de acordo com critérios como, porém sem caráter limitativo: área geopolítica, número de itens adquiridos, e/ou similares.
O servidor pode obter as transações de um banco de dados que não são classificadas, por exemplo, 3301, e obter regras e rótulos para classificar os registros, por exemplo, 3302. Por exemplo, o banco de dados pode armazenar as regras de classificação, como a regra de classificação codificada por XML ilustrativa exemplificativa fornecida abaixo: <rule> <id>PURCHASE_44_45</id> <name>Number of purchasers</name> <inputs>num_purchasers</ inputs> <operations> <1 >label = <, >null'</I> <2>1F (num_purchasers > 1) label ='household'</2 > </operations> <outputs>label</outputs> </rule> O servidor pode selecionar um registro de dados não classificado para processamento, por exemplo, 3303. O servidor também pode selecionar uma regra de classificação para processar o registro de dados não classificado, por exemplo, 3304. O servidor pode analisar a regra de classificação, e determinar as entradas exigidas pela regra, por exemplo, 3305. Com base na análise da regra de classificação, o servidor pode analisar o modelo de registro de dados normalizado, por exemplo, 3306, e extrair os valores dos campos que são exigidos para serem fornecidos como entradas para a regra de classificação. O servidor pode analisar a regra de classificação, e extrair as operações que serão realizadas nas entradas fornecidas para o processamento de regra, por exemplo,
3307. Mediante a determinação das operações que serão realizadas, o servidor pode realizar as operações especificadas por regra nas entradas fornecidas para a regra de classificação, por exemplo, 3308. Em algumas implementações, a regra pode fornecer valores limite. Por exemplo, a regra pode especificar que o número de produtos na 1O transação, valor total da transação, classificação média de luxo dos produtos vendidos na transação, etc. pode precisar ultrapassar um limite do(s) rótulo(s) associado(s) para que a regra seja aplicada ao registro de dados de transação. O servidor pode analisar a regra de classificação para extrair quaisquer valores limite exigidos para que a regra seja aplicada, por exemplo, 3309. O servidor pode comparar os valores computados com os limites de regra, por exemplo, 3310. Se o(s) limite(s) de regra for/forem ultrapassado(s), por exemplo, 3311, opção "Sim", o servidor pode aplicar um ou mais rótulos ao registro de dados de transação como especificado pela regra de classificação, por exemplo, 3312. Por exemplo, o servidor pode aplicar uma regra de classificação a um produto individual dentro da transação, e/ou à transação como um todo. Em algumas implementações, o servidor pode processar o registro de dados de transação utilizando cada regra (veja, por exemplo, 3313). Uma vez que todas as regras de classificação foram processadas para o registro de transação, por exemplo, 3313, opção "Não", o servidor pode armazenar o registro de dados de transação em um banco de dados, por exemplo, 3314. O servidor pode realizar esse processamento para cada registro de dados de transação até todos os registros de dados de transação serem classificados (veja, por exemplo, 3315). A Figura 34 mostra um diagrama de fluxo lógico que ilustra os aspectos exemplificativos de identificação de correlação de entidade cruzada em algumas modalidades do UEP, por exemplo, um componente de Correlação de Entidade Cruzada ("CEC") 3400. Em algumas implementações, um servidor pode reconhecer que duas entidades no UEP compartilham campos de dados comuns ou relacionados, por exemplo, data, endereço, código postal, nome, ID de usuário, endereço de e-mail, número de conta de pagamento (PAN), números CW2, e/ou similares, e assim identificar as entidades como sendo correlacionadas. O servidor pode selecionar um registro de dados para correlação de entidade cruzada, por exemplo, 3401. O servidor pode analisar a regra de registro de dados, e extrair os campos de dados do registro de dados, por exemplo, 3402-3403. O servidor pode selecionar um campo de dados extraído do registro de dados, por exemplo, 3404, e consultar um banco de dados para outros registros de dados que possuem o mesmo campo de dados que o campo de dados extraído, por exemplo, 3405. A partir da lista de registros de dados recuperados da consulta de banco de dados, o servidor pode selecionar um registro para análise adicional. O servidor pode identificar, por exemplo, 3407, uma entidade associada ao registro de dados recuperado, por exemplo, utilizando o componente ETC 5 3300 discutido acima na descrição com referência à Figura 33. O servidor pode adicionar um campo de dados ao registro de dados obtido para correlação de entidade cruzada especificando a correlação ao registro de dados selecionado recuperado, por exemplo,
3408. Em algumas modalidades, o servidor pode utilizar cada campo de dados no registro de dados obtido para correlação de entidade cruzada para identificar as entidades 1O correlacionadas, veja, por exemplo, 3409. O servidor pode adicionar, uma vez concluído, um sinalizador "correlacionado" ao registro de dados obtido para a correlação de entidade cruzada, por exemplo, 341 O, por exemplo, juntamente com um carimbo de data e hora especificando o horário no qual a correlação de entidade cruzada foi realizada. Por exemplo, esse carimbo de data e hora pode ser usado para determinar posteriormente se o registro de dados deve ser processado novamente para correlação de entidade cruzada. O servidor pode armazenar o registro de dados atualizado em um banco de dados. A Figura 35 mostra um diagrama de fluxo lógico que ilustra os aspectos exemplificativos de associação de atributos a entidades em algumas modalidades do UEP, por exemplo, um componente de Associação de Atributo de Entidade ("EAA") 3500. Em algumas implementações, um servidor pode associar os atributos a uma entidade, por exemplo, se a entidade for uma pessoa, o servidor pode identificar uma demografia (por exemplo, masculino/feminino), um caráter de gasto, uma lista de preferências de compra, uma lista de preferências de comerciantes, e/ou similares, com base nos valores de campo de campos de dados nos registros de dados que estão relacionados à entidade. Em algumas implementações, um servidor pode obter um registro de dados para associação de atributos de entidade, por exemplo, 3501. O servidor pode analisar a regra de registro de dados, e extrair campos de dados do registro de dados, por exemplo, 3502-3503. O servidor pode selecionar um campo de dados extraído do registro de dados, por exemplo, 3504, e identificar um valor de campo para o campo de dados extraído selecionado do registro de dados, por exemplo, 3505. O servidor pode consultar um banco de dados para dados demográficos, dados comportamentais, e/ou similares, por exemplo, 3506, utilizando o valor de campo e tipo de campo. Em resposta, o banco de dados pode fornecer uma lista de atributos potenciais, bem como um nível de confiança nessas associações de atributos à entidade, veja, por exemplo, 3507. O servidor pode adicionar campos de dados ao registro de dados obtidos para associação de atributos de entidade especificando os atributos potencialmente associados e seus níveis de confiança associados, por exemplo, 3508. Em algumas modalidades, o servidor pode utilizar cada campo de dados no registro de dados obtidos para correlação de entidade cruzada para identificar as entidades correlacionadas, veja, por exemplo, 3509. O servidor pode armazenar o registro de dados atualizado em um banco de dados, por exemplo, 3510. A Figura 36 mostra um diagrama de fluxo lógico que ilustra os aspectos 5 exemplificativos de atualização de gráficos de perfil de entidade em algumas modalidades do UEP, por exemplo, um componente de Atualização de Gráfico de Perfil de Entidade ("EPGU") 3600. Em algumas implementações, um servidor pode gerar/atualizar um perfil para uma entidade cujos dados são armazenados dentro do UEP.
O servidor pode obter um registro de perfil de entidade para atualização, por exemplo, 3601. O servidor pode analisar 1O o registro de perfil de entidade, e extrair um campo de dados de identificador de entidade do registro de dados, por exemplo, 3602. O servidor pode consultar um banco de dados para outros registros de dados que são relacionados à mesma entidade, por exemplo, 3603, utilizando o valor do campo de dados de identificador de entidade.
Em resposta, o banco de dados pode fornecer uma lista de outros registros de dados para processamento adicional.
O servidor pode selecionar um dos registros de dados para atualizar o registro de perfil de entidade, por exemplo, 3604. O servidor pode analisar o registro de dados, e extrair todas as correlações, associações, e novos dados do outro registro, por exemplo, 3605. O servidor pode comparar as correlações, atributos, associações, etc., do outro registro de dados com as correlações, associações e atributos do perfil de entidade.
Com base nessa comparação, o servidor pode identificar quaisquer novas correlações, associações, etc., e gerar um registro de perfil de entidade atualizado utilizando as novas correlações, associações; novas correlações de sinalizador, associações para processamento adicional, por exemplo, 3607. Em algumas modalidades, o servidor pode utilizar cada registro de dados obtido para atualizar o registro de perfil de entidade bem como seu gráfico social (por exemplo, como determinado pelas correlações e associações da entidade), veja, por exemplo, 3609. O servidor pode armazenar o registro de perfil de entidade atualizado em um banco de dados, por exemplo, 3608. A Figura 37 mostra um diagrama de fluxo lógico que ilustra os aspectos exemplificativos de geração de termos de pesquisa para atualização de gráfico de perfil em algumas modalidades do UEP, por exemplo, um componente de Geração de Termo de Pesquisa ("STG") 3700. Em algumas implementações, um servidor pode gerar/atualizar um perfil para uma entidade cujos dados são armazenados dentro do UEP, realizando uma pesquisa de novos dados, por exemplo, através da Internet e serviços de rede social.
O servidor pode obter um registro de perfil de entidade par atualização, por exemplo, 3701. O servidor pode analisar o registro de perfil de entidade, e extrair tipos de campo de dados e valores de campo do registro de perfil de entidade, por exemplo, 3702. O servidor pode consultar um banco de dados para outros registros de dados que são relacionados à mesma entidade, por exemplo, 3703, utilizando os valores dos campos de dados extraídos.
Em resposta, o banco de dados pode fornecer uma lista de outros registros de dados para processamento adicional.
O servidor pode analisar os registros de dados, e extrair todas as correlações, associações, e dados dos registros de dados, por exemplo, 3704. O servidor 5 pode agregar todos os valores de dados de todos os registros e o registro de perfil de entidade, por exemplo, 3705. Com base nisso, o servidor pode retornar os valores de dados agregados como termos de pesquisa para ativar os processos de pesquisa (veja, por exemplo, FIG.20, 2001-2005), por exemplo, 3706. Recomendação Baseada em Comportamento de Usuário A Figura 38 mostra um diagrama de fluxo lógico que ilustra os aspectos exemplificativos de análise de um comportamento de usuário baseada em dados de transação de compra agregados em algumas modalidades do UEP, por exemplo, um componente de Análise de Comportamento de Usuário ("UBA") 3800. Em algumas implementações, um servidor de rede de pagamento ("servidor") pode obter uma ID de usuário de um usuário para o qual se exige que o servidor gere padrões comportamentais de usuário, por exemplo, 3801. O servidor pode consultar um banco de dados, por exemplo, um banco de dados de rede de pagamento, para registros de dados de transação de cartão agregados do usuário, por exemplo, 3802. O servidor também pode consultar, por exemplo, 3803, o banco de dados de rede de pagamento para todos os valores de campo possíveis que podem ser obtidos por cada valor de campo (por exemplo, AM/PM, código postal, merchant_ID, merchant_name, transação de custo, etc.). Utilizando-se os valores de campo de todos os campos nos registros de dados de transação, o servidor pode gerar pares de valores de campo, para realizar uma análise de correlação nos pares de valores de campo, por exemplo, 3804. Um par de valores de campo exemplificativo é: 'horário' é 'AM' e 'comerciante' é 'Walmart'. O servidor pode então gerar estimativas de probabilidade para cada par de valores de campo que ocorrem nos registros de dados de transação agregados.
Por exemplo, o servidor pode selecionar um par de valores de campo, por exemplo, 3805. O servidor pode determinar o número de registros dentro dos registros de dados de transação agregados onde o par de valores de campo ocorre, por exemplo, 3806. O servidor pode então calcular um quociente de probabilidade para o par de valores de campo dividindo o número determinado das ocorrências do par de valores de campo pelo número total de registros de dados de transação agregados, por exemplo, 3807. O servidor também pode atribuir um nível de confiança ao quociente de probabilidade com base no tamanho de amostra, por exemplo, número total de registros nos registros de dados de transação agregados, por exemplo, 3808. O servidor pode gerar e armazenar um trecho XML, inclusive o par de valores de campo, o quociente de probabilidade, e o nível de confiança associado ao quociente de probabilidade, por exemplo, 3809. O servidor pode realizar essa computação para cada par de valores de campo (veja 381 O) gerado em 3804. A Figura 39 mostra um diagrama de fluxo lógico que ilustra os aspectos exemplificativos de geração de recomendações para um usuário com base no 5 comportamento de transação de compra agregada anterior do usuário em algumas modalidades do UEP, por exemplo, um componente de Recomendações de Oferta Baseadas em Comportamento de Usuário ("UBOR") 3900. Em algumas implementações, um servidor de rede de pagamento ("servidor") pode obter uma ID de usuário de um usuário para o qual se exige que servidor gere recomendações de oferta, por exemplo, 3901. O 1O servidor pode obter uma lista de produtos incluída em um pedido de autorização de cartão para processar a transação de compra do usuário, por exemplo, 3902. O servidor também pode consultar um banco de dados para correlações por pares pré-geradas de várias variáveis relacionadas à transação de usuário, por exemplo, 3902b, como aquelas geradas pelo componente UBA 3800 descrito acima com referência à Figura 38. O servidor pode selecionar um produto da lista de produtos incluída no pedido de autorização de cartão, por exemplo, 3903. O servidor pode identificar todos os valores de correlação de pares de campo onde o produto selecionado é o campo independente na correlação de pares de campo, por exemplo, 3904. O servidor pode, por exemplo, 3905, a partir de valores de pares de campos identificados, identificar o produto que é o valor de campo dependente do par de valores de campo que possui o maior quociente de probabilidade (por exemplo, produto mais provável de ser comprado juntamente com o produto selecionado da lista de produtos incluída no pedido de autorização de cartão). O servidor pode armazenar o produto identificado, juntamente com seu nível de confiança de previsão associado, em uma fila de produtos para recomendação, por exemplo, 3906. O servidor pode realizar a análise de cada produto incluído na lista de produtos do pedido de autorização de cartão, veja, por exemplo, 3907. Em algumas implementações, mediante a conclusão dessa análise de todos os produtos no pedido de autorização de cartão, o servidor pode classificar a fila de acordo com seu quociente de probabilidade associado e nível de confiança de previsão, por exemplo, 3908. Por exemplo, se o nível de confiança de previsão de um produto for maior que um limite, então esse pode ser mantido na fila, porém não se o nível de confiança de previsão for menor que o limite.
Também, os produtos mantidos podem ser classificados em ordem decrescente de seus quocientes de probabilidade associados.
Em algumas implementações, o servidor pode eliminar quaisquer produtos duplicados da fila, por exemplo, 3909. O servidor pode retornar a fila de produtos classificada para a recomendação de oferta de produto, por exemplo, 391 O.
Plataforma de Pagamento Social
A Figura 40 mostra um diagrama de bloco que ilustra os aspectos exemplificativos de transações de pagamento através de redes sociais em algumas modalidades do UEP.
Em algumas modalidades, o UEP pode facilitar transferências entre duas pessoas 401 O de dinheiro através redes sociais.
Por exemplo, um usuário (usuário1 4011) pode desejar 5 disponibilizar fundos (dólares, gratificações, pontos, milhas, etc. 4014) para outro usuário (usuário2 4016). O usuário pode utilizar uma carteira virtual para disponibilizar uma fonte de fundos.
Em algumas modalidades, o usuário pode utilizar um dispositivo 4012 (como um smartphone, dispositivo móvel, laptop, computador de mesa, e/ou similares) para enviar uma mensagem social através da rede social 4015. Em algumas modalidades, a mensagem 1O social pode incluir informações sobre uma quantia de fundos que será transferida e uma identidade de outro usuário para o qual os fundos devem ser transferidos.
O UEP pode interceptar a mensagem antes de a mesma ser enviada para o serviço de rede social, ou esse pode obter a mensagem do serviço de rede social.
Utilizando-se a mensagem social, o UEP pode separar as identidades de um pagador e beneficiário na transação.
O UEP pode identificar as contas do pagador e beneficiário para/do qual os fundos serão creditados ou debitados, e uma quantia de crédito/débito para aplicar a cada conta.
O UEP pode, com base na separação dessas informações, executar uma transação para transferir fundos do pagador para o beneficiário.
Por exemplo, o UEP pode permitir que um pagador, enviando- se um tweet no Twitter™ como "$25 @jfdoe #ackpls" transfira fundos para um beneficiário (ID de usuário jfdoe), e solicitar uma confirmação do UEP de recebimento de fundos.
Em outro exemplo, o UEP pode permitir que um beneficiário potencial solicite fundos de outro usuário ao enviar um tweet no Twitter™ como "@johnq, you owe me 50000 Visa rewards points #idi234"; o UEP pode fornecer automaticamente um alerta dentro de um aplicativo de carteira virtual do usuário com a ID de usuário johnq para disponibilizar os fundos para o usuário beneficiário potencial.
O usuário johnq pode responder enviando um tweet em resposta, id (#idi234), como "50000 vpts @jfdoe #idi234"; o UEP pode transferir os fundos e reconhecer o pedido de transação #idi234 como concluído.
Em algumas modalidades, o UEP pode gerar números de ID de transação/pedido para os usuários para impedir que números de ID de transação/pedido de transação/pedidos diferentes coincidam.
Em algumas modalidades, o UEP pode utilizar um ou mais serviços de rede social (por exemplo, Facebook®, Twitter™, MySpace™, etc.). Em algumas modalidades, o UEP pode permitir que os usuários através de redes sociais diferentes realizem transações entre si.
Por exemplo, um usuário pode realizar um pedido de pagamento em uma rede social.
Como um exemplo, um usuário de Twitter™ pode tuitar "@johnq@facebook.com, you owe me 500 vpts #107890"). O UEP pode fornecer um alerta ao usuário com a ID johnq@facebook.com através da outra rede social ou através da carteira virtual do usuário.
Em resposta, o beneficiário pode postar no Facebook® uma mensagem "@jfdoe: here's your
500 vpts #107890", e o UEP pode facilitar a transação de pagamento e fornecer um recibo/confirmação aos dois usuários em suas respectivas redes sociais ou carteiras virtuais.
Em algumas modalidades, o UEP pode facilitar as transferências de fundos para 5 mais de um beneficiário por um pagador através de uma única mensagem social.
Em algumas modalidades, o UEP pode facilitar o uso de mais de uma fonte de fundos de um beneficiário para financiar o pagamento de fundos para um ou mais pagadores através de uma única mensagem.
Por exemplo, o UEP pode utilizar configurações padrão ou regras customizadas, armazenadas dentro de uma carteira virtual de um pagador, para determinar 1O quais fontes de financiamento utilizar para financiar uma transação de pagamento para um ou mais beneficiários através de uma mensagem social.
Em algumas implementações, o UEP pode ajudar os comerciantes a fazerem ofertas de produtos e/ou serviços para consumidores através de redes sociais 4020. Por exemplo, um comerciante 4026 pode se registrar para participar do UEP.
O UEP pode agregar as transações de um usuário, e determinar quaisquer produtos ou serviços que podem ser relevantes para oferecer ao usuário.
O UEP pode determinar se quaisquer comerciantes participantes estão disponíveis para fornecer os produtos ou serviços aos usuários.
Se for o caso, o UEP pode fornecer mensagens sociais através de uma rede social 4025 em nome dos comerciantes (ou, alternativamente, informar os comerciantes que podem então enviar mensagens sociais para os usuários) proporcionando as ofertas 4024a ao usuário 4021. Um exemplo de uma oferta para os seguidores de um comerciante pode ser "@amazon offers the new Kindle™ at only $149.99 <_> click here to buy". Nesse exemplo, a oferta postada no site de rede social pode possuir um link incorporado (por exemplo, "aqui") que os usuários podem clicar para realizar a compra (que pode ser automaticamente realizada com um clique se esses estiverem atualmente conectados em suas contas de carteira virtual 4023). Outro exemplo de uma oferta de comerciante pode ser "@amazon offers the new Kindle™ at only $149.99 <_> reply with #offer1Di23456 to buy". Nesse exemplo, o valor de hashtag serve como um identificador da oferta que os usuários podem mencionar quando estão realizando sua compra através de suas mensagens sociais (por exemplo, "buy from @amazon #offer1Di23456"). Em algumas modalidades, os comerciantes podem apresentar duas ou mais ofertas através de uma única mensagem social.
Em algumas modalidades, os usuários podem mencionar duas ou mais ofertas na mesma mensagem social.
Em algumas implementações, os usuários e/ou comerciantes podem utilizar modos de trocas de mensagens alternativos.
Por exemplo, um usuário pode ser capaz de utilizar o correio eletrônico, mensagens SMS, chamadas telefônicas, etc., para se comunicar com o UEP e as redes sociais.
Por exemplo, um comerciante pode apresentar uma oferta de mensagem social como ""@amazon offers the new Kindle™ at only $149.99 < > text
#offer1Di23456 to buy". Quando um usuário utiliza um telefone celular para enviar uma mensagem de texto para resgatar a oferta, o UEP pode utilizar um perfil de usuário do usuário armazenado no serviço de rede social para identificar um atributo de identificação do telefone celular do usuário (por exemplo, um número de telefone), utilizando o UEP que 5 pode correlacionar a mensagem de texto a um usuário particular.
Assim, o UEP pode ser capaz de processar uma transação com o comerciante em nome do usuário, utilizando as informações de usuário da carteira virtual do usuário.
Em algumas modalidades, quando uma rede social for incapaz de gerenciar um modo particular de comunicação, o UEP pode servir como um tradutor intermediário para converter a mensagem para uma forma que 1O possa ser utilizada pela rede social.
A Figura 41 mostra um diagrama de fluxo de dados que ilustra um procedimento de inscrição de pagamento social exemplificativo em algumas modalidades do UEP.
Em algumas modalidades, um usuário, por exemplo, 4101, pode desejar se inscrever no UEP.
O usuário pode se comunicar com um servidor de pagamento social, por exemplo, 4103a, através de um cliente como, porém sem caráter limitativo: um computador pessoal, dispositivo móvel, televisão, terminal de ponto de venda, quiosque, ATM, e/ou similares (por exemplo, 4102). Por exemplo, o usuário pode fornecer uma entrada de usuário, por exemplo, entrada de inscrição de pagamento social 4111, ao cliente indicando o desejo do usuário de se inscrever no pagamento de compra autenticada de rede social.
Em várias implementações, a entrada de usuário pode incluir, porém sem caráter limitativo: um único toque (por exemplo, uma modalidade de compra com aplicativo móvel em um toque) de uma interface de tela sensível ao toque, entrada de teclado, passagem de cartão, ativação de um dispositivo de hardware habilitado RFID/NFC (por exemplo, cartão eletrônico com múltiplas contas, smartphone, tablet, etc.) dentro do dispositivo de usuário, cliques de mouse, pressionamentos de botões em um joystick/console de jogo, comandos de voz, gestos de único/múltiplo toque em uma interface sensível ao toque, tocar os elementos de interface de usuário em uma tela sensível ao toque, e/ou similares.
Em algumas implementações, utilizando-se a entrada do usuário, o cliente pode gerar um pedido de inscrição de pagamento social, por exemplo, 4112, e fornecer o pedido de inscrição ao servidor de pagamento social 4103a.
Por exemplo, o cliente pode fornecer uma mensagem POST de Protocolo de Transferência de Hipertexto ("HTTP(S)") (Secure) que inclui os dados formatados de acordo com a Linguagem de Marcação extensível ("XML"). Abaixo está uma mensagem POST HTTP(S) exemplificativa que inclui um pedido de inscrição formatado em XML para o servidor de pagamento social: POST /enroll. php HTTP/ 1.1 Host: www.socialpay.com Content-Type: Application/XML
Content-Length: 484 <?XML version =" 1 . O " encoding ="UTF- 8 " ? > <enrollment_req uest> <request_ID> 4NFU4RG94</request_ID> 5 <timestamp>2011-02 -22 15: 22: 43</timestamp> <user_ID>john. q. public@facebook.com</user_ID> <wallet_account_I D> 7865493028712345</wallet_account_I D> <client details> <client_IP>192.168.23.126</client_IP> <client_type>smartphone</client_type> <client_model>HTC Hero</client_model> <OS>Android 2.2</0S> <app_installed_flag>true</app_installed_flag> </client_details> </enrollment_request> Em algumas modalidades, o servidor de pagamento social pode obter o pedido de inscrição do cliente, e extrair os detalhes de pagamento do usuário (por exemplo, XML data) do pedido de inscrição.
Por exemplo, o servidor de pagamento social pode utilizar um analisador como os analisadores exemplificativos descritos abaixo na discussão com referência à Figura 61. Em algumas implementações, o servidor de pagamento social pode consultar, por exemplo, 4113, um banco de dados de pagamento social, por exemplo, 4103b, para obter um modelo de pedido de rede social, por exemplo, 4114, para processar o pedido de inscrição.
O modelo de pedido de rede social pode incluir instruções, dados, URL de conexão, modelo de chamada API de conexão e/ou similares para facilitar a autenticação de rede social.
Por exemplo, o banco de dados pode ser um banco de dados relacional responsivo a comandos de Linguagem de Consulta Estruturada ("SQL"). O servidor de comerciante pode executar um script de pré-processador de hipertexto ("PHP") que inclui comandos SQL para consultar o banco de dados para dados de produto.
Uma listagem de comando PHP/SQL exemplificativa que ilustra os aspectos independentes de consulta do banco de dados, por exemplo, 4114-4115, é fornecida abaixo: <?PHP header ('Content-Type: text/plain'); mysql_connect ("254.93.179.112", $DBserver, $password); llaccess database server mysql_select_db ("SOCIALPAY . SQL"); li select database table to search //create query $query = "SELECT template FROM EnrollTable WHERE network LIKE'%'$socialnet"
$result =mysql_query ( $query); li perform the search query mysql_close ( "SOCIALAUTH . SQL") ; li close database access ?> Em algumas implementações, o servidor de pagamento social pode redirecionar o cliente para um servidor de rede social, por exemplo, 4104a, fornecendo uma mensagem 5 HTTP(S) REDIRECT 300, similar ao exemplo abaixo: HTTP/1.1 300 Multiple Choices Location: https://www.facebook.com/d ialog/oauth?client_id=sn pa_app_I D&redirect_uri= www.paynetwork.com/enroll.php <html> <headxtitle>300 Multiple Choices</title></head> <body><h1 >Multiple Choices</hlx/body> </html> Em algumas implementações, o servidor de pagamento social pode fornecer as informações extraídas do pedido de inscrição de pagamento social ao servidor de rede social como parte de um pedido de inscrição de aplicativo de autenticação de usuário/pagamento social, por exemplo, 4115. Por exemplo, o servidor de pagamento social pode fornecer uma mensagem POST HTTP(S) ao servidor de rede social, similar ao exemplo abaixo: POST /authenticate_enroll .php HTTP/1.1 Host: www.socialnet.com Content-Type: Application/XML Content-Length: 484 <?XML version = "1.0" encoding = "UTF-8"?> <enrollment_request> <request_ID>4NFU4RG94</request_ID> <timestamp>2011-02-22 15: 22: 43</timestamp> <user_ID>john.q.public@facebook.com</user_ID> <waltter_account_I D> 7865493028712345</waltter_account_I D> <client_details> <client_IP>192.168.23.126</client_IP> <client_type>smartphone</client_type> <client_model>HTC Hero</client_model> <OS>Android 2.2</0S> <app_installed_flag>true</app_installed_flag> </client_details> </enrollment_request>
Em algumas implementações, o servidor de rede social pode fornecer um pedido de conexão de rede social, por exemplo, 4116, ao cliente.
Por exemplo, o servidor de rede social pode fornecer um formulário de entrada HTML ao cliente.
O cliente pode exibir, por exemplo, 4117, o formulário de conexão do usuário.
Em algumas implementações, o usuário 5 pode fornecer uma entrada de conexão de cliente, por exemplo, 4118, e o cliente pode gerar uma resposta de conexão de rede social, por exemplo, 4119, do servidor de rede social.
Em algumas implementações, o servidor de rede social pode autenticar os credenciais de conexão do usuário, e com isso, atualizar o perfil do usuário para indicar a inscrição do usuário no sistema de pagamento social.
Por exemplo, em um serviço de rede social como 1O Facebook®, o servidor de rede social pode conceder permissão a um aplicativo desenvolvedor de terceiros de pagamento social para acessar as informações de usuário armazenadas dentro da rede social.
Em algumas modalidades, essa inscrição pode permitir que um aplicativo de carteira virtual instalado em um dispositivo de usuário acesse as informações de perfil social do usuário armazenadas dentro da rede social.
Mediante a autenticação, o servidor de rede social pode gerar um registro de dados atualizado do usuário, por exemplo, 4120, e fornecer uma notificação de inscrição, por exemplo, 4121, ao servidor de pagamento social.
Por exemplo, o servidor de rede social pode fornecer uma mensagem POST HTTP(S) similar ao exemplo abaixo: POST /enrollnotification.php HTTP/ 1 . 1 Host: www.socialpay.com Content-Type: Application/XML Content-Length: 1306 <?XML version = 11 11 1 . 0 encoding = UTF-8 11 11 ?> <enroll_notification> <request_ID>4NFU4RG94</order_ID> <timestamp>2011- 02 -22 15: 22: 43</timestamp> <result>enrolled</result> </enroll_notification> Mediante o recebimento da notificação de inscrição do servidor de rede social, o servidor de pagamento social pode gerar, por exemplo, 4122, um registro de dados de inscrição de usuário, e armazenar o registro de dados de inscrição em um banco de dados de pagamento social, por exemplo, 4123, para concluir a inscrição.
Em algumas implementações, o registro de dados de inscrição pode incluir as informações da notificação de inscrição 4121. A Figura 42 mostra um diagrama de fluxo lógico que ilustra os aspectos exemplificativos de inscrição de pagamento social em algumas modalidades do UEP, por 11 exemplo, um componente de Inscrição de Pagamento Social ( SPE 11 } 4200. Em algumas modalidades, um usuário pode desejar se inscrever em UEP.
O usuário pode fornecer uma entrada de usuário, por exemplo, entrada de inscrição de pagamento social 4201, ao cliente indicando o desejo do usuário de se inscrever em um pagamento de compra autenticada de rede social.
Em várias implementações, utilizando-se a entrada de usuário o cliente pode 5 gerar um pedido de inscrição de pagamento social, por exemplo, 4202, e fornecer o pedido de inscrição ao servidor de pagamento social.
Em algumas modalidades, o servidor de pagamento social pode obter o pedido de inscrição do cliente, e extrair os detalhes de pagamento do usuário (por exemplo, dados XML) do pedido de inscrição.
Por exemplo, o servidor de rede de pagamento pode utilizar um analisador como os analisadores 1O exemplificativos descritos abaixo na discussão com referência à Figura 61. Em algumas implementações, o servidor de rede de pagamento pode consultar, por exemplo, 4203, um banco de dados de rede de pagamento para obter um modelo de pedido de rede social para processar o pedido de inscrição.
O modelo de pedido de rede social pode incluir instruções, dados, URL de conexão, modelo de chamada API de conexão e/ou similares para facilitar a autenticação de rede social.
Em algumas implementações, o servidor de rede de pagamento pode redirecionar o cliente para um servidor de rede social.
Em algumas implementações, o servidor de pagamento social pode fornecer as informações extraídas do pedido de inscrição de pagamento social ao servidor de rede social como parte de um pedido de autenticação de usuário/inscrição de aplicativo de pagamento social, por exemplo, 4205. Em algumas implementações, o servidor de rede social pode fornecer um pedido de conexão de rede social, por exemplo, 4206, ao cliente.
Por exemplo, o servidor de rede social pode fornecer um formulário de entrada HTML ao cliente.
O cliente pode exibir, por exemplo, 4207, o formulário de conexão do usuário.
Em algumas implementações, o usuário pode fornecer uma entrada de conexão ao cliente, por exemplo, 4208, e o cliente pode gerar uma resposta de conexão de rede social, por exemplo, 4209, ao servidor de rede social.
Em algumas implementações, o servidor de rede social pode autenticar os credenciais de conexão do usuário, e ao fazer isso, atualizar o perfil do usuário para indicar a inscrição do usuário no sistema de pagamento social.
Por exemplo, em um serviço de rede social como Facebook®, o servidor de rede social pode conceder permissão a um aplicativo desenvolvedor de terceiros de pagamento social para acessar as informações de usuário armazenadas dentro da rede social.
Em algumas modalidades, essa inscrição pode permitir que um aplicativo de carteira virtual instalado em um dispositivo de usuário acesse as informações de perfil social do usuário armazenadas dentro da rede social.
Mediante a autenticação, o servidor de rede social pode gerar um registro de dados atualizado do usuário, por exemplo, 4210-4211, e fornecer uma notificação de inscrição, por exemplo, 4212, ao servidor de pagamento social.
Mediante o recebimento da notificação de inscrição do servidor de rede social, o servidor de rede de pagamento pode gerar, por exemplo, 4213,
um registro de dados de inscrição de usuário, e armazenar o registro de dados de inscrição em um banco de dados de rede de pagamento, por exemplo, 314, para concluir a inscrição.
Em algumas implementações, o registro de dados de inscrição pode incluir as informações da notificação de inscrição. 5 As Figuras 43A-C mostram diagramas de fluxo de dados que ilustram um procedimento de ativação de pagamento social exemplificativo em algumas modalidades do UEP.
Com referência à Figura 43A, em algumas modalidades, um usuário, por exemplo, usuário1 4301 a, pode desejar fornecer ou solicitar fundos de outro (por exemplo, um usuário, um comerciante participante, etc.). O usuário pode se comunicar com um servidor de rede social, por exemplo, 4303a, através de um cliente (cliente1 4302a) como, porém sem caráter limitativo: um computador pessoal, dispositivo móvel, televisão, terminal de ponto de venda, quiosque, ATM, e/ou similares.
Por exemplo, o usuário pode fornecer uma entrada de usuário 4311, ao cliente indicando o desejo do usuário de fornecer ou solicitar fundos de outros.
Em várias modalidades, a entrada de usuário pode incluir, porém sem caráter limitativo: um único toque (por exemplo, uma modalidade de compra com aplicativo móvel em um toque) de uma interface de tela sensível ao toque, entrada de teclado, passagem de cartão, ativação de um dispositivo de hardware habilitado RFID/NFC (por exemplo, cartão eletrônico com múltiplas contas, smartphone, tablet, etc.) dentro do dispositivo de usuário, cliques de mouse, pressionamentos de botões em um joystick/console de jogo, comandos de voz, gestos de único/múltiplo toque em uma interface sensível ao toque, tocar os elementos de interface de usuário em uma tela sensível ao toque, e/ou similares.
Em resposta, o cliente pode fornecer uma solicitação de mensagem social 4312 ao servidor de rede social.
Em algumas implementações, um aplicativo de carteira virtual executado no cliente pode fornecer ao usuário uma interface de fácil uso para gerar e enviar a solicitação de mensagem social.
Em implementações alternativas, o usuário pode utilizar outros aplicativos para fornecer a solicitação de mensagem social.
Por exemplo, o cliente pode fornecer uma solicitação de mensagem social ao servidor de rede social como uma mensagem POST HTTP(S) que inclui dados formatados em XML.
Uma listagem exemplificativa de uma solicitação de mensagem social 4312, substancialmente sob a forma de uma mensagem POST HTTP(S) que inclui dados formatados em XML, é fornecida abaixo: POST /socialpost.php HTTP/1.1 Host: www.socialnetwork.com Content-Type: Application/XML Content-Length: 31 O <?XML version = "1.0" encoding = "UTF-8"?> <message_post_req uest>
<req uest_I D>value</req uest_I D> <timestamp>2011-02-02 03: 04: 05</timestamp> <sender_id>j fdoe@facebook.com</ sender_id> <receiver_id>johnqp@facebook.com</ receiver_id> <message>$25 Sjohnqp #thanksforagreattimelastnite</message> </message_post_req uest> Em algumas modalidades, o servidor de rede social 4304a pode consultar seu banco de dados de rede social para um gráfico social do usuário, por exemplo, 4313. Por exemplo, o servidor de rede social pode emitir comandos PHP/SQL para consultar uma tabela de 1O banco de dados (como a Figura 61, Gráfico Social 6119p) para dados de gráfico social associados ao usuário.
Uma consulta de gráfico social de usuário exemplificativa 4313, substancialmente sob a forma de comandos PHP/SQL, é fornecida abaixo: <?PHP header ('Content-Type: text/plain'); mysql_connect ("254.93.179.112", $DBserver, $password) ; li access database server mysql_select_db ( "UEP_DB . SQL" ) ; li select database table to search llcreate query $query ="SELECT friend_name friend_type friend_weight message_params_list messaging_restrictions FROM SocialGraphTable WHERE user LIKE '%'$user_id"; $result =mysql_query ( $query) ; li perform the search query mysql_close ( "UEP_DB . SQL" ) ; li close database access ?> Em algumas modalidades, o banco de dados de rede social pode fornecer os dados de gráfico social solicitados em resposta, por exemplo, 4314. Utilizando-se os dados de gráfico social, o servidor de rede social pode gerar mensagem(ns) como adequado para o usuário e/ou membros do gráfico social do usuário, por exemplo, 4315, e armazenar as mensagens 4316 do usuário e/ou membros de gráfico social.
Com referência à Figura 438, em algumas modalidades, essa postagem de mensagens sociais pode gerar as ações do UEP.
Por exemplo, um servidor de pagamento social 4303a pode ser gerado para verificar os dados sociais para comandos de pagamento.
Em modalidades onde cada mensagem social é criada a partir do aplicativo de carteira virtual de um usuário, o UEP pode obter opcionalmente os comandos de pagamento dos aplicativos de carteira virtual, e pular a verificação das redes sociais para comandos de pagamento associados ao usuário.
Em modalidades onde permite-se que um usuário emita comandos de pagamento de qualquer dispositivo (mesmo aqueles não vinculados à carteira virtual do usuário), o UEP pode periodicamente, ou ainda continuamente verificar as redes sociais para comandos de pagamento, por exemplo, 4321. Em modalidades onde o UEP verifica as redes sociais, o servidor de pagamento social pode consultar um banco de dados de pagamento social para um perfil do usuário. Por exemplo, o servidor de pagamento social pode solicitar uma ID e senha de usuário das redes sociais que o usuário forneceu ao servidor de pagamento social durante a fase de inscrição (veja, por exemplo, as Figuras 41- 42). Por exemplo, o servidor de pagamento social servidor pode emitir comandos PHP/SQL para consultar uma tabela de banco de dados (como a Figura 61, Usuários 6119a) para dados de perfil de usuário. Uma consulta de dados de perfil de usuário exemplificativa 4322, substancialmente sob a forma de comandos PHP/SQL, é fornecida abaixo: <?PHP 1O header ('Content-Type: text/plain'); mysql_connect ("254.93.179.112", $DBserver, $password) li access database server mysql_select_db ( "UEP_DB.SQL") ; li select database table to search llcreate query $query = "SELECT network_id network_name network_api user_login user_pass
FROM UsersTable WHERE userid LIKE'%'$user_id"; $result = mysql_query ( $query) ; li perform the search query mysql_close ( "UEP_DB . SQL" ) ; li close database access ?> Em resposta, o banco de dados de pagamento social pode fornecer as informações solicitadas, por exemplo, 4323. Em algumas modalidades, o servidor de pagamento social pode fornecer um pedido de dados sociais de usuário 4324 ao servidor de rede social. Uma listagem exemplificativa de comandos para emitir um pedido de dados sociais de usuário 4324, substancialmente sob a forma de comandos PHP, é fornecida abaixo: <?PHP header ('Content-Type: text/plain'); li Obtain user ID(s) of friends of the logged-in user $friends = json_decode ( file_get_contents ('https: llgraph.facebook.com/me/ friends?access token='$cookie ['oauth_access_token'] ), true) ; $friend_ids = array_keys ( $friends) ; li Obtain mensagem feed associated with the profile of the logged-in user $feed = json_decode (file_get_contents (https: 11 graph.facebook.com/me/ feed?access_tok en='$cookie ["oauth_access_token'] ), true) ;
li Obtain messages by the user's friends 5 $result = mysql_query ('SELECT * FROM content WHERE uid IN (' . implode ($friend_ids, ', ') .')') ; $friend_content = array ( ); while ($row = mysql_fetch_assoc ( $result ) ) $friend_content [] $row; ?> Em algumas modalidades, o servidor de rede social pode consultar, por exemplo, 4326, seu banco de dados de rede social 4304b para resultados de dados sociais que estão dentro do escopo do pedido.
Em resposta à consulta, o banco de dados pode fornecer dados sociais, por exemplo, 4327. O servidor de rede social pode retornar os dados sociais obtidos dos bancos de dados, por exemplo, 4328, para o servidor de pagamento social.
Uma listagem exemplificativa de dados sociais de usuário 4328, substancialmente sob a forma de dados formatados em JavaScript Object Notation (JSON), é fornecida abaixo: [ "data" { "name": "Tabatha Orloff'', "id": "483722"}, { "name": "Darren Kinnaman", "id": "86S743"}, { "name": "Sharron Jutras", "id": "091274"} ] } Em algumas modalidades, o servidor de pagamento social pode consultar o banco de dados de pagamento social para regras de pagamento social, por exemplo, 4329. Por exemplo, o servidor de pagamento social pode emitir comandos PHP/SQL para consultar uma tabela de banco de dados (como a Figura 61, Regras de Pagamento Social 6119q) para as regras de pagamento social 4330. Uma consulta de regras de pagamento exemplificativa 4329, substancialmente sob a forma de comandos PHP/SQL, é fornecida abaixo: <?PHP header ('Content-Type: text/plain'); mysql_connect ("254.93.179.112", $DBserver, $password) ; li access database sever mysql_select_db ( "UEP_DB . SQL" ) ; li select database table to search llcreate query
$query ="SELECT rule_id rule_type rule_description rule_priority rule_source FROM SocialPayRulesTable WHERE rule_type LIKE pay_rules"; $result =mysql_query ( $query) ; li perform the search query mysql_close ( "UEP_DB . SQL" ) ; li close database access 5 ?> Em algumas modalidades, o servidor de pagamento social pode processar os dados sociais de usuário utilizando as regras de pagamento social para identificar comandos de pagamento, pedidos de pagamento, ofertas de comerciante, e/ou conteúdo similar dos dados sociais de usuário.
Em algumas modalidades, as regras podem ser fornecidas pelo 1O UEP para garantir a privacidade e segurança dos dados sociais e carteira virtual do usuário.
Como outro exemplo, as regras podem incluir procedimentos para detectar tentativas de transação fraudulenta, e solicitar a verificação de usuário antes de proceder, ou cancelar completamente o pedido de transação.
Em algumas modalidades, o servidor de pagamento social pode utilizar um componente de segurança e configurações de carteira, como o componente WSS exemplificativo 4500 descrito adicionalmente abaixo na discussão com referência às Figuras 45A-B.
Com referência à Figura 43C, em algumas modalidades, o servidor de pagamento social pode determinar opcionalmente que, com base no processamento das regras, a verificação de usuário é necessária para processar uma transação indicada em um comando de pagamento.
Por exemplo, se o processamento de regras indicar que há uma probabilidade de o comando de pagamento ser uma tentativa em uma tentativa de transação fraudulenta, o servidor de pagamento social pode determinar que o usuário deve ser contatado para verificação de pagamento antes que transação possa ser processada.
Nesses cenários, o servidor de pagamento social pode fornecer um pedido de verificação de comando de pagamento 4333 ao cliente, que o cliente pode exibir, por exemplo, 4334, ao usuário.
Por exemplo, o servidor de pagamento social pode fornecer um pedido de verificação de comando de pagamento ao cliente 4302a como uma mensagem POST HTP(S) que inclui dados formatados em XML.
Uma listagem exemplificativa de um pedido de verificação de comando de pagamento 4333, substancialmente sob a forma de uma mensagem POST HTP(S) que inclui dados formatados em XML, é fornecida abaixo: POST /verifyrequest .php HTTP/ 1 . 1 Host: www.client.com Content-Type: Application/XML Content-Length: 2 56 <?XML version =" 1 . O " encoding ="UTF- 8 " ? > <verify_req uest> <transaction_ID>AE 12 34 </ transaction_ID>
<timestamp>2 01 1 - 02 - 02 03: 04: 05</timestamp> <amount> 50000 vpts</amount> <message_string>5000000 vpts Sjfdoe #thx</message_string> </verify_request> 5 Em algumas modalidades, o usuário pode fornecer uma entrada de verificação 4335 ao cliente, que pode fornecer uma resposta de verificação de comando de pagamento ao servidor de pagamento social. O servidor de pagamento social pode determinar se o pagador verificou o pagamento, se as informações de beneficiário disponíveis são suficientes para processar a transação, e/ou similares. Em cenários onde informações de 1O beneficiário suficientes estão indisponíveis, o servidor de pagamento social pode fornecer opcionalmente uma mensagem social 4338 a um serviço de rede social associado ao beneficiário potencial solicitando que o beneficiário se inscreva no serviço de pagamento social (por exemplo, utilizando o componente SPE 4200 descrito acima na discussão com referência às Figuras 41-42), que o servidor de rede social pode postar 4339 ao beneficiário. Se todas as exigências forem cumpridas para processar a transação, o servidor de pagamento social pode gerar um gerador de transação exclusivo associado à geração de mensagem social, por exemplo, 4337, e armazenar uma ID de gerador de transação, gerar a mensagem social, etc., para registro de informações ou propósitos analíticos, por exemplo,
4340. O servidor de pagamento social pode fornecer o gerador de transação para gerar uma transação de compra 4341, por exemplo, através de uma autorização de transação de compra como o componente PTA exemplificativo descrito abaixo na discussão com referência à Figura 58. As Figuras 44A-C mostram diagramas de fluxo lógico que ilustram os aspectos exemplificativos de geração de pagamento social em algumas modalidades do UEP, por exemplo, um componente Gerador de Pagamento Social ("SPT") 4400. Com referência à Figura 44A, em algumas modalidades, um usuário pode desejar fornecer ou solicitar fundos de outros (por exemplo, um usuário, um comerciante participante, etc.). O usuário pode se comunicar com um servidor de rede social através de um cliente. Por exemplo, o usuário pode fornecer uma entrada de pagamento social 4401, ao cliente indicando o desejo do usuário de fornecer ou solicitar fundos de outros. Em resposta, o cliente pode gerar e fornecer uma solicitação de mensagem social 4402 ao servidor de rede social. Em algumas implementações, um aplicativo de carteira virtual executado no cliente pode fornecer ao usuário uma interface de fácil uso para gerar e enviar a solicitação de mensagem social. Em implementações alternativas, o usuário pode utilizar outros aplicativos para fornecer a solicitação de mensagem social. Em algumas modalidades, o servidor de rede social pode consultar seu banco de dados de rede social para um gráfico social do usuário, por exemplo,
4403. Em resposta, o banco de dados de rede social pode fornecer os dados de gráfico social solicitados, por exemplo, 4404. Utilizando-se os dados de gráfico social, o servidor de rede social pode gerar mensagem(ns) como adequado para o usuário e/ou membros do gráfico social do usuário, por exemplo, 4405, e armazenar as mensagens 4406 do usuário e/ou membros de gráfico social. 5 Com referência à Figura 448, em algumas modalidades, essa postagem de mensagens sociais pode gerar ações do UEP.
Por exemplo, um servidor de pagamento social pode ser gerado para verificar os dados sociais para comandos de pagamento, por exemplo, 4407. Em modalidades onde cada mensagem social é criada a partir do aplicativo de carteira virtual de um usuário, o UEP pode obter opcionalmente os comandos de 1O pagamento dos aplicativos de carteira virtual, e pular a verificação das redes sociais para comandos de pagamento associados ao usuário.
Em modalidades onde permite-se que um usuário emita comandos de pagamento de qualquer dispositivo (mesmo aqueles não vinculados à carteira virtual do usuário), o UEP pode periodicamente, ou ainda continuamente verificar as redes sociais para comandos de pagamento.
Em modalidades onde o UEP verifica as redes sociais, o servidor de pagamento social pode consultar um banco de dados de pagamento social para um perfil do usuário, 4408. Por exemplo, o servidor de pagamento social pode solicitar uma ID e senha de usuário das redes sociais que o usuário forneceu ao servidor de pagamento social durante a fase de inscrição (veja, por exemplo, as Figuras 41-42). Em resposta, o banco de dados de pagamento social pode fornecer as informações solicitadas, por exemplo, 4409. Em algumas modalidades, o servidor de pagamento social pode gerar e fornecer um pedido de dados sociais de usuário 441 O ao servidor de rede social.
Em algumas modalidades, o servidor de rede social pode extrair uma ID de usuário do pedido de dados sociais de usuário, por exemplo, 4411. O servidor de rede social pode consultar, por exemplo, 4412, seu banco de dados de rede social para determinar se o usuário está inscrito no UEP com a rede social (por exemplo, "o usuário habilitou o aplicativo UEP Facebook® para acessar dados de usuário?"). Em resposta, o banco de dados de rede social pode fornecer dados de inscrição de usuário referentes ao UEP.
O servidor de rede social pode determinar se o usuário está inscrito, e, desse modo, se o servidor de pagamento social está autorizado a acessar os dados sociais de usuário, 4414. Se o servidor de rede social determinar que o servidor de pagamento social não está autorizado, 4415, opção "Não", esse pode gerar uma mensagem de negação de serviço, 4416, e fornecer a mensagem ao servidor de pagamento social.
Se o servidor de rede social determinar que o servidor de pagamento social está autorizado a acessar os dados sociais de usuário, 4415, opção "Sim", o servidor de rede social pode gerar uma consulta de dados sociais de usuário 4417, e fornecer a mesma ao banco de dados de rede social.
Em resposta, o banco de dados de rede social pode fornecer os dados sociais de usuário solicitados, 4418. O servidor de rede social pode fornecer os dados sociais de usuário 4419 ao servidor de pagamento social.
Em algumas modalidades, o servidor de pagamento social pode consultar o banco de dados de pagamento social para regras de pagamento social, por exemplo, 4420-4421. Em algumas modalidades, o servidor de pagamento social pode processar os dados sociais de usuário utilizando as regras de pagamento social para identificar comandos de pagamento, pedidos de pagamento, ofertas de comerciante, e/ou conteúdo similar dos dados sociais de usuário.
Em algumas modalidades, as regras podem ser fornecidas pelo UEP para garantir a privacidade e segurança dos dados sociais e carteira virtual do usuário. 1O Como outro exemplo, as regras podem incluir procedimentos para detectar tentativas de transação fraudulenta, e solicitar a verificação de usuário antes de proceder, ou cancelar completamente o pedido de transação.
Em algumas modalidades, o servidor de pagamento social pode utilizar um componente de segurança e configurações de carteira, como o componente WSS exemplificativo 4500 descrito adicionalmente abaixo na discussão com referência às Figuras 45A-B.
Com referência à Figura 44C, em algumas modalidades, o servidor de pagamento social pode determinar opcionalmente que, com base no processamento das regras, a verificação de usuário é necessária para processar uma transação indicada em um comando de pagamento, 4423, opção "Sim". Por exemplo, se o processamento de regras indicar que há uma probabilidade de o comando de pagamento ser uma tentativa em uma tentativa de transação fraudulenta, o servidor de pagamento social pode determinar que o usuário deve ser contatado para verificação de pagamento antes que a transação possa ser processada.
Nesses cenários, o servidor de pagamento social pode fornecer um pedido de verificação de comando de pagamento 4425 ao cliente, que o cliente pode exibir, por exemplo, 4426, ao usuário.
Em algumas modalidades, o usuário pode fornecer uma entrada de verificação 4427 ao cliente, que pode fornecer uma resposta de verificação de comando de pagamento ao servidor de pagamento social, 4428. O servidor de pagamento social pode determinar se o pagador verificou o pagamento, se as informações de beneficiário disponíveis são suficientes para processar a transação, e/ou similares, 4429. Em cenários onde informações de beneficiário suficientes estão indisponíveis ou o pagador precisa ser contatado para verificação de pagamento, 4430, opção "Não", o servidor de pagamento social pode fornecer opcionalmente uma mensagem social 4431 a um serviço de rede social associado ao beneficiário/pagador potencial solicitando que o beneficiário se inscreva no serviço de pagamento social (por exemplo, utilizando o componente SPE 4200 descrito acima na discussão com referência às Figuras 41-42) ou fornecer uma verificação, que o servidor de rede social pode postar 4432-4422 para o beneficiário.
Se todas as exigências forem cumpridas para processar a transação, 4430, opção "Sim", o servidor de pagamento social pode gerar um gerador de transação exclusivo associado à geração de mensagem social, por exemplo, 4434, e pode opcionalmente armazenar uma ID de gerador de transação, gerando a mensagem social, etc., para registro de informações ou propósitos analíticos.
O servidor de pagamento social pode fornecer o gerador de transação para gerar 5 uma transação de compra, por exemplo, através de um componente de autorização de transação de compra.
As Figuras 45A-B mostram diagramas de fluxo lógico que ilustram os aspectos exemplificativos de implementação de segurança e configurações de carteira em algumas modalidades do UEP, por exemplo, um componente Something ("WSS") 4500. Em algumas 1O modalidades, o servidor de pagamento social pode processar os dados sociais de usuário utilizando as regras de pagamento social para identificar comandos de pagamento, pedidos de pagamento, ofertas de comerciante, e/ou conteúdo similar dos dados sociais de usuário.
Em algumas modalidades, as regras podem ser fornecidas pelo UEP para garantir a privacidade e segurança dos dados sociais e carteira virtual do usuário.
Como outro exemplo, as regras podem incluir procedimentos para detectar tentativas de transação fraudulenta, e solicitar a verificação de usuário antes de proceder, ou cancelar completamente o pedido de transação.
Consequentemente, com referência à Figura 45A, em algumas modalidades, o UEP pode obter um gerador para processar os dados sociais do usuário (por exemplo, da Figura 448, elemento 4431), 4501. O UEP pode obter os dados sociais de usuário e/ou membro de gráfico social de usuário, bem como regras e modelos de comando de pagamento (por exemplo, para identificar os comandos de pagamento padrão), 4502. O UEP pode analisar os dados sociais de usuário obtidos na preparação de processamento de regras, 4503. Por exemplo, o UEP pode utilizar analisadores como os analisadores exemplificativos descritos abaixo na discussão com referência à Figura 61. O UEP pode selecionar uma regra/modelo de comando de pagamento para processamento.
O UEP pode pesquisar os dados sociais de usuário analisados, por exemplo, de maneira sequencial, para o comando de pagamento selecionado, 4512, e determinar se o comando de pagamento está presente nos dados sociais de usuário, 4513. Se o comando de pagamento for identificado, 4514, opção "Sim", o UEP pode colocar a sequência de comando de pagamento identificada, uma identificação da regra/modelo, a listagem real da regra/modelo, e/ou similares em uma fila para processamento adicional, 4515. O UEP pode realizar esse procedimento até todos os dados sociais do usuário serem pesquisados (veja 4516). Em algumas modalidades, o UEP pode realizar o procedimento acima para todas as regras/modelos disponíveis, para identificar todas as sequências de comando de pagamento incluídas nos dados sociais de usuário (veja 4517).
Em algumas modalidades, o UEP pode processar cada comando de pagamento identificado dos dados sociais de usuário, 4520. Por exemplo, o UEP pode selecionar uma sequência de comando de pagamento da fila e seu modelo/regra de identificação associado,
4521. Utilizando a regra/modelo e a sequência de comando de pagamento, o UEP pode 5 determinar se a sequência representa um pedido de pagamento, ou um pedido a pagar,
4523. Se a sequência de comando de pagamento representar um pedido de pagamento (por exemplo, "hey @jfdoe, you owe me 25 bucks #cashflowblues"), 4524, opção "Sim", o UEP pode determinar se o usuário para o qual o componente WSS é executado é o pagador solicitado, ou o beneficiário, 4525. Se for exigido que o usuário efetue o pagamento, 4526, opção "Sim", o UEP pode adicionar um aviso de pagamento à conta de carteira de usuário,
4527. De outro modo, o UEP pode gerar um registro de pedido de pagamento de usuário que inclui os detalhes de comando de pagamento, 4528, e armazenar o registro de pedido de pagamento na conta de carteira do usuário para propósitos de registro de informações ou processamento analítico futuro, 4529. Com referência à Figura 458, em algumas modalidades, o UEP pode extrair uma identificação de um pagador e beneficiário na transação, 4531. O UEP pode consultar um banco de dados para dados de conta de beneficiário para processamento de pagamento,
4532. Se os dados de beneficiário disponíveis forem insuficientes, 4533, opção "Sim", o UEP pode gerar uma mensagem social para a conta de rede social do beneficiário 4534, solicitando que o beneficiário se inscreva no UEP (se já não o estiver), ou fornecer informações adicionais de modo que o UEP possa processar a transação. O UEP pode fornecer, 4535, a mensagem social ao serviço de rede social associado ao beneficiário. Se informações de beneficiário suficientes estiverem disponíveis, 4533, opção "Não", o UEP pode consultar a conta de carteira do pagador para regras de segurança associadas à utilização da conta de carteira virtual, 4536. O UEP pode selecionar uma regra de segurança de carteira, 4537, e processar a regra de segurança utilizando a sequência de comando de pagamento como dados de entrada, 4538. Com base no processamento, o UEP pode determinar se o comando de pagamento cumpre a regra de segurança, ou em vez disso apresenta um risco de segurança à carteira do usuário. Se a regra de segurança não for cumprida, 4540, opção "Não", o UEP pode determinar se a verificação do usuário pode recuperar a sequência de comando de pagamento, 4541. Se o UEP determinar que o risco é muito grande, o UEP pode descontinuar diretamente a transação e remover a sequência de comando de pagamento da fila de processamento. De outro modo (4541, opção "Sim"), o UEP pode gerar um pedido de verificação de comando de pagamento para o usuário, 4542, e fornecer o pedido de verificação de comando de pagamento como uma saída do componente, 4543. Se todas as regras de segurança forem cumpridas pela sequência de comando de pagamento, 4544, opção "Não", o UEP pode gerar um gerador de transação com uma ID de gerador (como um pedido de autorização de cartão), e fornecer o gerador de transação para processamento de pagamento. A Figura 46 mostra um diagrama de fluxo de dados que ilustra um procedimento de ligação de consumidor a comerciante social exemplificativo em algumas modalidades do 5 UEP. Em algumas implementações, um servidor de pagamento social 4613a pode ser gerado, por exemplo, 4621, para fornecer serviços que liguem os consumidores e comerciantes através de redes sociais. Por exemplo, o servidor de pagamento social pode identificar um consumidor com necessidade de ofertas de produtos ou serviços, e pode identificar comerciantes participantes em UEP que podem fornecer os produtos ou serviços 1O necessários. O servidor de pagamento social pode gerar ofertas em nome dos comerciantes participantes, e fornecer as ofertas aos consumidores através de redes sociais. Em algumas modalidades, o servidor de pagamento social pode iniciar periodicamente serviços de ligação de comerciante-consumidor para um usuário. Em modalidades alternativas, o servidor de pagamento social pode iniciar a ligação de comerciante-consumidor mediante a notificação de um consumidor envolvido em uma transação (por exemplo, um consumidor pode solicitar a finalização de compra de uma compra através da carteira virtual do usuário; para ilustração, veja o componente de Finalização de Compra de Compra do Usuário exemplificativo (UPC) 5600 descrito adicionalmente abaixo na discussão com referência à Figura 56), ou quando uma autorização for solicitada para uma transação de compra (veja o componente de Autorização de Transação de Compra exemplificativo (PTA) 5800 descrito adicionalmente abaixo na discussão com referência à Figura 58). Mediante a obtenção de um gerador para realizar a ligação de comerciante-consumidor, o servidor de pagamento social pode solicitar 4622 um componente de agregação de dados de transação, por exemplo, o componente TOA 2600 descrito adicionalmente abaixo na discussão com referência à Figura 26. O servidor de pagamento social pode consultar um banco de dados de pagamento social 4603b para regras de geração de oferta, por exemplo, 4623. Por exemplo, o servidor de pagamento social pode utilizar comandos PHP/SQL similares aos outros exemplos descritos aqui. Em resposta, o banco de dados pode fornecer as regras de geração de oferta solicitadas, por exemplo, 4624. Utilizando-se os dados de transação agregados e as regras de geração de oferta, o servidor de pagamento social pode gerar mensagens sociais de oferta de comerciante(s) para postar nos perfis do usuário em redes sociais, por exemplo, 4625. Por exemplo, o servidor de pagamento social pode solicitar um componente de geração de oferta baseado em transação, como o componente UBOR exemplificativo 3900 descrito adicionalmente abaixo na discussão com referência à Figura
39. O servidor de pagamento social pode fornecer as mensagens de sociais geradas 4626 a um servidor de rede social 4614a. O servidor de rede social pode armazenar as mensagens sociais 4627 em um banco de dados de rede social 4614b para distribuição para o usuário
(por exemplo, quando o usuário se conectar ao serviço de rede social fornecido pelo servidor de rede social). A Figura 47 mostra um diagrama de fluxo lógico que ilustra os aspectos exemplificativos de uma ligação de comerciante e consumidor social em algumas 5 modalidades do UEP, por exemplo, um componente de Ligação de Consumidor e Comerciante Social ("SMCB") 4700. Em algumas implementações, um servidor de pagamento social pode ser gerado para fornecer serviços que liguem os consumidores e comerciantes através de redes sociais, por exemplo, 4701. Mediante a obtenção de um gerador para realizar a ligação de comerciante-consumidor, o servidor de pagamento social 1O pode solicitar um componente de agregação de dados de transação como o componente TOA 2600 descrito adicionalmente abaixo na discussão com referência à Figura 26, por exemplo, 4702. O servidor de pagamento social pode consultar um banco de dados de pagamento social 4603b para regras de geração de oferta, por exemplo, 4703. Por exemplo, o servidor de pagamento social pode utilizar comandos PHP/SQL similares aos outros exemplos descritos aqui. Em resposta, o banco de dados pode fornecer as regras de geração de oferta solicitadas, por exemplo, 4704. Utilizando-se os dados de transação agregados e as regras de geração de oferta, o servidor de pagamento social pode gerar mensagens sociais de oferta, o servidor de pagamento social pode gerar mensagens sociais de oferta de comerciante(s) pra postar nos perfis do usuário em redes sociais, por exemplo,
4705. Por exemplo, o servidor de pagamento social pode solicitar um componente de geração de oferta baseado em transação, como o componente UBOR exemplificativo 3900 descrito adicionalmente abaixo na discussão com referência à Figura 39. O servidor de pagamento social pode fornecer as mensagens de sociais geradas a um servidor de rede social. O servidor de rede social pode armazenar as mensagens sociais em um banco de dados de rede social para distribuição para o usuário (por exemplo, quando o usuário se conectar ao serviço de rede social fornecido pelo servidor de rede social). Em algumas modalidades, o servidor de rede social pode gerar, utilizando dados de gráfico social do usuário, mensagens sociais do usuário e/ou membros do gráfico social do usuário, por exemplo, 4706, e armazenar a mensagem social em um banco de dados de rede social para postar em seus perfis, por exemplo, 4707. Modalidades de UI de Carteira Virtual A Figura 48 mostra um diagrama de interface de usuário que ilustra uma visão geral de características exemplificativas de aplicativos de carteira virtual em algumas modalidades do UEP. A Figura 48 mostra uma ilustração de várias características exemplificativas de um aplicativo móvel de carteira virtual 4800. Algumas das características exibidas incluem uma carteira 4801, integração social através de TWITTER, FACEBOOK, etc., ofertas e fidelidade
4803, compra 4804, alertas 4805 e segurança, configuração e analítica 4896. Essas características são exploradas em mais detalhes abaixo.
As Figuras 49A-G mostram diagramas de interface de usuário que ilustram características exemplificativas de aplicativos de carteira virtual em um modo de compra, em 5 algumas modalidades do UEP.
Com referência à Figura 49A, algumas modalidades do aplicativo móvel de carteira virtual facilitam e melhoram bastante a experiência de compra de consumidores.
Uma variedade de modos de compra, como mostrado na Figura 49A, pode estar disponível para um consumidor analisar.
Em uma implementação, por exemplo, um usuário pode executar o modo de compra ao selecionar o ícone de compra 491 O na 1O parte inferior da interface de usuário.
Um usuário pode digitar um item no campo de pesquisa 4912 para pesquisar e/ou adicionar um item a um carrinho 4911. Um usuário também pode usar um modo de compra ativado por voz falando o nome ou descrição de um item que será pesquisado e/ou adicionado ao carrinho em um microfone 4913. Em uma implementação adicional, um usuário também pode selecionar outras opções de compra 4914 como itens atuais 4915, faturas 4916, lista de endereços 4917, comerciantes 4918 e proximidade local 4919. Em uma modalidade, por exemplo, um usuário pode selecionar a opção itens atuais 4915, como mostrado na interface de usuário mais à esquerda da Figura 49A.
Quando a opção de itens atuais 4915 for selecionada, a interface de usuário intermediária pode ser exibida.
Como mostrado, a interface de usuário intermediária pode fornecer uma lista atual de itens 4915a-h em um carrinho de compra do usuário 4911. Um usuário pode selecionar um item, por exemplo, item 4915a, para visualizar a descrição do produto 4915j do item e/ou outros itens selecionados do mesmo comerciante.
O preço e informações pagáveis totais também podem ser exibidos, juntamente com um código QR 4915k que captura as informações necessárias para efetuar uma transação de compra.
Com referência à Figura 498, em outra modalidade, um usuário pode selecionar a opção de faturas 4916. Mediante a seleção da opção de faturas 4916, a interface de usuário pode exibir uma lista de faturas e/ou recibos 4916a-h de um ou mais comerciantes.
Próximo a cada fatura, informações adicionais como data de visita, se itens de várias lojas estiverem presentes, data de último pagamento de fatura, auto-pagamento, número de itens, e/ou similares pode ser exibidas.
Em um exemplo, a fatura de compra de carteira 4916a datada em 20 de janeiro de 2011 pode ser selecionada.
A seleção de fatura de compra de carteira pode exibir uma interface de usuário que fornece uma variedade de informações referentes à fatura selecionada.
Por exemplo, a interface de usuário pode exibir uma lista de itens 4916k adquiridos, <<4916i>>, o número total de itens e o valor correspondente.
Por exemplo, 7 itens com valor de $102.54 estão na fatura de compra de carteira selecionada.
Um usuário pode selecionar agora qualquer um dos itens e selecionar comprar novamente para adicionar os itens de compra.
O usuário também pode atualizar as ofertas 4916j para apagar quaisquer ofertas inválidas da última vez e/ou pesquisar novas ofertas que possam ser aplicáveis à compra atual.
Como mostrado na Figura 49B, um usuário pode selecionar dois itens para repetir a compra.
Mediante a adição, uma mensagem 49161 pode ser exibida para confirmar a adição dos dois itens, que estima o número total de itens no carrinho 14. Com referência à Figura 49C, em ainda outra modalidade, um usuário pode selecionar a opção de lista de endereços 4917 para visualizar a lista de endereços 4917a que inclui uma lista de contatos 4917b e realiza quaisquer transferências de dinheiro ou pagamentos.
Em uma modalidade, a lista de endereços pode identificar cada contato 1O utilizando seus nomes e modos de pagamento disponíveis e/ou preferidos.
Por exemplo, um contato Amanda G. pode ser pago através de pagamento social (por exemplo, através de FACEBOOK) como indicado pelo ícone 4917c.
Em outro exemplo, o dinheiro pode ser transferido para Brian S. através do código QR como indicado pelo ícone de código QR 4917d.
Ainda em outro exemplo, Charles B. pode aceitar o pagamento através de comunicação de campo próximo 4917e, Bluetooth 49i7f e e-mail 49i7g.
O pagamento também pode ser realizado através de USB 4917b (por exemplo, por conexão física de dois dispositivos móveis) bem como outros canais sociais como TWITTER.
Em uma implementação, um usuário pode selecionar Joe P. para pagamento.
Joe P., como mostrado na interface de usuário, possui um ícone de e-mail 4917g próximo a seu nome indicando que Joe4 P. aceita o pagamento através de e-mail.
Quando seu nome for selecionado, a interface de usuário pode exibir suas informações de contato como e-mail, telefone, etc.
Se um usuário desejar efetuar um pagamento para Joe P. por meio de um método diferente do e-mail, o usuário pode adicionar outro modo de transferência 4917j a suas informações de contato e realizar uma transferência de pagamento.
Com referência à Figura 490, pode-se apresentar ao usuário uma tela 4917k onde o usuário pode inserir uma quantia para enviar para Joe, bem como adicionar outro texto para proporcionar a Joe o contexto para a transação de pagamento 49171. O usuário pode selecionar modos (por exemplo, SMS, e-mail, rede social) através dos quais Joe pode ser contatado através de elementos de interface gráfica de usuário, 4917m.
À medida que o usuário2 digita, o texto inserido pode ser fornecido para análise dentro de um elemento GUI 4917n.
Quando o usuário concluir a introdução das informações necessárias, o usuário pode apertar o botão enviar 49170 para enviar a mensagem social para Joe.
Se Joe também possuir um aplicativo de carteira virtual, Joe pode ser capaz de analisar 4917P a mensagem de pagamento social dentro do aplicativo, ou diretamente no site da rede social (por exemplo, para Twitter™, Facebook®, etc.). As mensagens podem ser agregadas das várias redes sociais e outras fontes (por exemplo, SMS, e-mail). O método de resgate adequado para cada modo de troca de mensagens pode ser indicado juntamente com a mensagem de pagamento social.
Na ilustração na Figura 490, o SMS 491 ?q que Joe recebeu indica que Joe pode resgatar os $5 obtidos através de SMS respondendo ao SMS e inserido o valor de hashtag '#1234'. Na mesma ilustração, Joe também recebeu uma mensagem 49i7r através do Facebook®, que inclui um link URL que Joe pode ativar para iniciar o resgate do pagamento de $25. Com referência à Figura 49E, em algumas outras modalidades, um usuário pode selecionar os comerciantes 4918 da lista de opções no modo de compra para visualizar uma lista de seleção de comerciantes 49i8a-e.
Em uma implementação, os comerciantes na lista podem estar associados à carteira, ou possuir relação de afinidade com a carteira.
Em outra 1O implementação, os comerciantes podem incluir uma lista de comerciantes que cumprem um critério definido por usuário ou outros.
Por exemplo, a lista pode ser uma que é protegida pelo usuário, comerciantes onde o usuário compra mais frequentemente ou gasta mais de uma quantia x ou fez compras durante três meses consecutivos, e/ou similares.
Em uma implementação, o usuário pode selecionar ainda um dos comerciantes, Amazon 491 Ba, por exemplo.
O usuário pode então navegar através das listagens de comerciante para encontrar itens de interesse como 4918f-j.
Diretamente através da carteira e sem visitar o site de comerciante de uma página separada, o usuário pode fazer uma seleção de um item 49i8j do catálogo de Amazon 4918a.
Como mostrado na interface de usuário mais à direita da Figura 490, o item selecionado pode ser então adicionado ao carrinho.
A mensagem 4918k indica que o item selecionado foi adicionado ao carrinho, e o número atualizado de itens no carrinho agora é 13. Com referência à Figura 49F, em uma modalidade, pode haver uma opção de proximidade local 4919 que pode ser selecionada por um usuário para visualizar uma lista de comerciantes que estão geograficamente em estreita proximidade ao usuário.
Por exemplo, a lista de comerciantes 4919a-e pode ser os comerciantes que estão localizados próximos ao usuário.
Em uma implementação, o aplicativo móvel pode ainda identificar quando o usuário está em uma loja com base na localização do usuário.
Por exemplo, o ícone posição 4919d pode ser exibido próximo a uma loja (por exemplo, Walgreens) quando o usuário estiver em estreita proximidade à loja.
Em uma implementação, o aplicativo móvel pode atualizar sua localização periodicamente no caso de o usuário se afastar da loja (por exemplo, Walgreens). Em uma implementação adicional, o usuário pode navegar nas ofertas da loja Walgreens selecionada através do aplicativo móvel.
Por exemplo, o usuário pode navegar, utilizando o aplicativo móvel, por itens 4919f-j disponíveis no corredor 5 de Walgreens.
Em uma implementação, o usuário pode selecionar milho 49191 de seu aplicativo móvel para adicionar ao carrinho 4919k.
Com referência à Figura 49G, em outra modalidade, a opção proximidade local 4919 pode incluir um mapa da loja e recursos de mapa em tempo real entre outros.
Por exemplo,
mediante a seleção da loja Walgreens, o usuário pode executar um mapa do corredor 49191 que exibe um mapa 4919m que mostra a organização da loja e o posicionamento do usuário (indicado por um círculo amarelo). Em uma implementação, o usuário pode configurar facilmente o mapa para adicionar um ou mais usuários (por exemplo, filhos do usuário) para 5 compartilhar uns com os outros sua localização dentro da loja.
Em outra implementação, o usuário pode ter a opção de iniciar uma "visualização da loja" similar a visualizações de ruas em mapas.
A visualização de loja 4919n pode exibir imagens/vídeo nos arredores do usuário.
Por exemplo, se o usuário estiver prestes a entrar no corredor 5, o mapa de visualização da loja pode mostrar a visualização do corredor 5. Ademais, o usuário pode 1O manipular a orientação do mapa utilizando a ferramenta de navegação 49190 para mover a visualização da loja para frente, para trás, direita, esquerda bem como rotação horaria e anti-horária.
As Figuras 50A-F mostram diagramas de interface de usuário que ilustram características exemplificativas de aplicativos de carteira virtual em um modo de pagamento, em algumas modalidades do UEP.
Com referência à Figura 50A, em uma modalidade, a carteira aplicativo móvel pode fornecer a um usuário inúmeras opções de pagamento de uma transação através do modo de carteira 501 O.
Em uma implementação, uma interface de usuário 5011 exemplificativa para efetuar um pagamento é mostrada.
A interface de usuário pode identificar claramente a quantia 5012 e a moeda 5013 para a transação.
A quantia pode ser a quantia pagável e a moeda pode incluir moedas reais como dólares e euros, em como moedas virtuais com pontos de recompensa.
A quantia da transação 5014 também pode ser destacadamente exibida na interface de usuário.
O usuário pode selecionar o indicador de fundos 5016 para selecionar uma ou mais formas de pagamento 5017, que podem incluir vários cartões de crédito, débito, gratificação, recompensas e/ou pré-pagos.
O usuário também pode ter a opção de pagar, totalmente ou em parte, com pontos de recompensa.
Por exemplo, o indicador gráfico 5018 na interface de usuário mostra o número de pontos disponíveis, o indicador gráfico 5019 mostra o número de pontos que serão usados em relação ao montante devido 234.56 e o equivalente 5020 do número de pontos em uma moeda selecionada (USO, por exemplo). Em uma implementação, o usuário pode combinar os fundos de múltiplas fontes para pagar a transação.
A quantia 5015 exibida na interface de usuário pode fornecer uma indicação da quantia de fundos totais cobertos até agora pelas formas selecionadas de pagamento (por exemplo, Discover card e pontos de recompensa). O usuário pode selecionar outra forma de pagamento ou ajustar a quantia a ser debitada de uma ou mais formas de pagamento até a quantia 5015 corresponder à quantia pagável 5014. Uma vez que as quantias que serão debitadas de uma ou mais formas de pagamento são finalizadas pelo usuário, a autorização de pagamento pode ser iniciada.
Em uma implementação, o usuário pode selecionar uma autorização segura da transação ao selecionar o botão ocultar 5022 para ocultar efetivamente ou anonimizar algumas ou todas as informações de identificação (por exemplo, pré-configuradas) de modo que quando o usuário selecionar o botão pagar 5021, a autorização de transação seja 5 realizada de maneira segura e anônima.
Em outra implementação, o usuário pode selecionar o botão pagar 5021 que pode usar técnicas de autorização padrão para processar a transação.
Ainda em outra implementação, quando o usuário selecionar o botão social 5023, uma mensagem referente à transação pode ser comunicada a uma ou mais redes sociais (configuradas pelo usuário) que podem postar ou anunciar a transação de 1O compra em um fórum social como uma publicação de mural um tuíte.
Em uma implementação, o usuário pode selecionar uma opção de processamento de pagamento social 5023. O indicador 5024 pode mostrar a autorização e envio de dados de compartilhamento social em progresso.
Em outra implementação, um modo de pagamento restrito 5025 pode ser ativado para algumas atividades de compra como compras com prescrição.
O modo pode ser ativado de acordo com as regras definidas por emissores, seguradores, comerciantes, processador de pagamento e/ou outras entidades para facilitar o processamento de produtos e serviços especializados.
Nesse modo, o usuário pode rolar para baixo a lista de formas de pagamentos 5026 sob indicador de fundos para selecionar as contas especializadas como uma conta de gastos flexíveis (FSA), conta de poupança de saúde (HAS), e/ou similares e montantes que serão debitados das contas selecionadas.
Em uma implementação, esse processamento de modo de pagamento restrito 5025 pode desabilitar o compartilhamento social de informações de compra.
Em uma modalidade, o aplicativo móvel de carteira pode facilitar a importação de fundos através da interface de usuário de fundos de importação 5028. Por exemplo, um usuário que está desempregado pode obter um fundo de auxílio-desemprego 5029 através do aplicativo móvel de carteira.
Em uma implementação, a entidade que fornece os fundos também pode configurar as regras utilizando o fundo como mostrado pela mensagem de indicador de processamento 5030. A carteira pode ler e aplicar as regras antes, e pode rejeitar quaisquer compras com os fundos de desemprego que não cumprem os critérios estabelecidos pelas regras.
Os critérios exemplificativos podem incluir, por exemplo, código do estabelecimento (MCC), tempo de transação, local de transação, e/ou similares.
Como um exemplo, uma transação com uma mercearia que possui MCC 5411 pode ser aprovada, enquanto uma transação com um bar que possui um MCC 5813 pode ser negada.
Com referência à Figura SOB, em uma modalidade, a carteira aplicativo móvel pode facilitar a otimização de pagamento dinâmico com base em fatores como localização, preferências e preferências de valor de moeda de usuário entre outros.
Por exemplo,
quando um usuário estiver nos Estados Unidos, o indicador de país S031 pode exibir um sinalizador dos Estados Unidos e pode ajustar a moeda S033 para os Estados Unidos.
Em uma implementação adicional, a carteira aplicativo móvel pode rearranjar automaticamente a ordem na qual as formas de pagamento S03S são listadas para refletir a popularidade ou S aceitabilidade de várias formas de pagamento.
Em uma implementação, a disposição pode refletir a preferência do usuário, que não pode ser alterada pela carteira aplicativo móvel.
Similarmente, quando um usuário alemão operar uma carteira na Alemanha, a interface de usuário de aplicativo de carteira móvel pode ser dinamicamente atualizada para refletir o país de operação S032 e a moeda S034. Em uma implementação adicional, o 1O aplicativo de carteira pode rearranjar a ordem na qual diferentes formas de pagamento S036 são listadas com base em seu nível de aceitação naquele país.
Naturalmente, a ordem dessas formas de pagamentos pode ser modificada pelo usuário para se adequar às suas próprias preferências.
Com referência à Figura soe, em uma modalidade, o indicador de beneficiário S037 1S na interface de usuário de carteira aplicativo móvel pode facilitar a seleção de usuário de um ou mais beneficiários que recebem os fundos selecionados no indicador de fundos.
Em uma implementação, a interface de usuário pode mostrar uma lista de todos os beneficiários S038 com os quais o usuário realizou transações anteriormente ou estão disponíveis para realizar transações.
O usuário pode então selecionar um ou mais beneficiários.
Os beneficiários S038 pode incluir comerciantes maiores como Amazon.com lnc., e indivíduos como Jane P.
Doe.
Próximo a cada nome de beneficiário, uma lista de modos de pagamento aceitos pelo beneficiário pode ser exibida.
Em uma implementação, o usuário pode selecionar o beneficiário Jane P.
Doe S039 para receber o pagamento.
Mediante a seleção, a interface de usuário pode exibir informações de identificação adicionais referentes ao 2S beneficiário.
Com referência à Figura SOO, em uma modalidade, o indicador de modo S040 pode facilitar a seleção de um modo de pagamento aceito pelo beneficiário.
Inúmeros modos de pagamento podem estar disponíveis para seleção.
Modos exemplificativos incluem, bluetooth S041, sem fio S042, instantâneo por código obtido por usuário QR S043, chip seguro S044, TWITTER S04S, comunicação de campo próximo (NFC) S046, celular S047, instantâneo por código fornecido por usuário QR S048, USB S049 e FACEBOOK SOSO, entre outros.
Em uma implementação, apenas os modos de pagamento que são aceitos pelo beneficiário podem ser selecionáveis pelo usuário.
Outros modos de pagamento não aceitos podem ser desabilitados. 3S Com referência à Figura SOE, em uma modalidade, os indicadores de oferta 50S1 pode fornecer ofertas em tempo real que são relativas a itens em um carrinho do usuário para seleção pelo usuário.
O usuário pode selecionar uma ou mais ofertas da lista de ofertas aplicáveis 5052 para resgate.
Em uma implementação, algumas ofertas podem ser combinadas, enquanto outras não podem.
Quando o usuário selecionar uma oferta que não pode ser combinada com outra oferta, as ofertas não selecionadas podem ser desabilitadas.
Em uma implementação adicional, as ofertas que são recomendadas pelo mecanismo de 5 recomendação do aplicativo de carteira podem ser identificadas por um indicador, como aquele mostrado por 5053. Em uma implementação adicional, o usuário pode ler os detalhes da oferta expandindo a fileira de ofertas como mostrado por 5054 na interface de usuário.
Com referência à Figura 50F, em uma modalidade, o indicador social 5055 pode facilitar a integração do aplicativo de carteira com canais sociais 5056. Em uma 1O implementação, um usuário pode selecionar um ou mais canais sociais 5056 e pode se inscrever no canal social selecionado do aplicativo de carteira fornecendo ao aplicativo de carteira o nome e senha de usuário de canal social 5057 e registro 5058. O usuário pode então usar o botão social 5059 para enviar ou receber dinheiro através dos canais sociais integrados.
Em uma implementação adicional, o usuário pode enviar dados de compartilhamento social como as informações de compra ou links através de canais sociais integrados.
Em outra modalidade, o usuário que forneceu os credenciais de conexão pode permitir que UEP participe da análise de interceptação.
A Figura 51 mostra um diagrama de interface de usuário que ilustra características exemplificativas de aplicativos de carteira virtual, em um modo de histórico, em algumas modalidades do UEP.
Em uma modalidade, um usuário pode selecionar o modo de histórico 5110 para visualizar um histórico de compras anteriores e realizar várias ações nessas compras anteriores.
Por exemplo, um usuário pode inserir informações de identificação de comerciante como nome, produto, MCC, e/ou similares na barra de pesquisa 5111. Em outra implementação, o usuário pode usar um recurso de pesquisa ativado por voz clicando no ícone de microfone 5114. O aplicativo de carteira pode consultar as áreas de armazenamento no dispositivo móvel ou outro lugar (por exemplo, um ou mais bancos de dados e/ou tabelas remotas do dispositivo móvel) para transações correspondentes às palavras-chave de pesquisa.
A interface de usuário pode então exibir os resultados da consulta como a transação 5115. A interface de usuário também pode identificar a data 5112 da transação, os comerciantes e itens 5113 referentes à transação, um código de barra do recibo confirmando que uma transação foi realizada, a quantia da transação e quaisquer outras informações relevantes.
Em uma implementação, o usuário pode selecionar uma transação, por exemplo, transação 5115, para visualizar os detalhes da transação.
Por exemplo, o usuário pode visualizar os detalhes dos itens associados à transação e as quantias 5116 de cada item.
Em uma implementação adicional, o usuário pode selecionar a opção mostrar 5117 para visualizar as ações 5118 que o usuário pode realizar em relação à transação ou aos itens na transação. Por exemplo, o usuário pode adicionar uma foto à transação (por exemplo, uma foto do usuário e do iPad que o usuário comprou). Em uma implementação adicional, se o usuário compartilhou anteriormente a compra através de canais sociais, uma postagem que inclui a foto pode ser gerada e enviada para os canais sociais para publicação. Em uma implementação, qualquer compartilhamento pode ser opcional, e o usuário, que não compartilhou a compra através de canais sociais, ainda pode compartilhar a foto através de um ou mais canais sociais de sua escolha diretamente a partir do modo de histórico do aplicativo de carteira. Em outra implementação, o usuário pode adicionar a transação a um grupo como gastos da empresa, gastos da casa, gastos com viagens ou outras categorias 1O configuradas pelo usuário. Esse agrupamento pode facilitar a contabilidade final de gastos, envio de relatórios de gastos de serviço, envio de reembolsos de impostos sobre valor agregado (VAT), gastos pessoais, e/ou similares. Ainda em outra implementação, o usuário pode comprar um ou mais itens adquiridos na transação. O usuário pode então executar uma transação sem consultar o catálogo ou site de comerciante para encontrar os itens. Em uma implementação adicional, o usuário também pode colocar no carrinho um ou mais itens no carrinho na transação para compra posterior. O modo de histórico, em outra modalidade, pode oferecer instalações para a obtenção e exibição de classificações 5119 dos itens na transação. A fonte das classificações pode ser o usuário, os amigos do usuário (por exemplo, dos canais sociais, contatos, etc.), avaliações agregadas a partir da web, e/ou similares. A interface de usuário em algumas implementações também pode permitir que o usuário poste mensagens para outros usuários de canais sociais (por exemplo, TWITTER ou FACEBOOK). Por exemplo, a área de exibição 5120 mostra trocas de mensagem de FACEBOOK entre dois usuários. Em uma implementação, um usuário pode compartilhar um link através de uma mensagem
5121. A seleção de tal mensagem que tem o link incorporado a um produto pode permitir que o usuário visualize uma descrição do produto e/ou compre o produto diretamente a partir do modo de histórico. Em uma modalidade, o modo de histórico também pode incluir facilidades de para exportar recibos. O pop up de recibos de exportação 5122 pode proporcionar inúmeras opções para exportar os recibos de transações no histórico. Por exemplo, um usuário pode usar uma ou mais das opções 5125, que incluem salvar (na memória local móvel, no servidor, em uma conta em nuvem, e/ou similares), imprimir em uma impressora, fax, email, e/ou similares. O usuário pode utilizar sua lista de endereços 5123 para procurar email ou número de fax para exportação. O usuário também pode especificar opções de formato 5124 para exportar recibos. As opções de formato exemplificativas incluem, sem limitação, arquivos de texto (.doe, .txt, .rtf, iif, etc.), planilha (.csv, .xls, etc.), arquivos de imagem (.jpg, .tff, .png, etc.), formato de documento portátil (.pdf), postscript (.ps), e/ou similares. O usuário, então, pode clicar ou tocar o botão exportar 5127 para iniciar a exportação de recibos.
As Figuras 52A-E mostram diagramas de interface de usuário que ilustram características exemplificativas de aplicativos de carteira virtual em um modo instantâneo, 5 em algumas modalidades do UEP.
Com referência à Figura 52A, em uma modalidade, um usuário pode selecionar o modo instantâneo 211 O para acessar suas características de ajuste.
O modo instantâneo pode lidar com qualquer representação legível por máquina de dados.
Os exemplos de tais dados podem incluir códigos de barra lineares e 20, tais como, código UPC e códigos QR.
Estes códigos podem ser encontrados em recibos, embalagem 1O de produtos, e/ou similares.
O modo instantâneo também pode processar e manipular imagens de recibos, produtos, ofertas, cartões de crédito ou outros dispositivos de pagamento, e/ou similares.
Uma interface de usuário exemplificativa em modo instantâneo é mostrada na Figura 52A.
Um usuário pode usar seu telefone celular para tirar uma foto de um código QR 5215 e/ou um código de barra 5214. Em uma implementação, a barra 5213 e o quadro instantâneo 5215 podem ajudar o usuário a ajustar os códigos adequadamente.
Por exemplo, o quadro instantâneo 5215, conforme mostrado, não captura o código 5216 total.
Como isso, o código capturado nessa visualização não pode ser resolúvel visto que as informações no código podem estar incompletas.
Isto é indicado pela mensagem na barra 5213 que indica que o modo instantâneo ainda está buscando o código.
Quando o código 5216 for completamente enquadrado pelo quadro instantâneo 5215, a mensagem de barra pode ser atualizada, por exemplo, para "instantâneo encontrado". Ao encontrar o código, em uma implementação, o usuário pode iniciar a captura de código usando a câmera de dispositivo móvel.
Em outra implementação, o modo instantâneo pode ajustar automaticamente o código usando a câmera de dispositivo móvel.
Com referência à Figura 528, em uma modalidade, o modo instantâneo pode facilitar a transação de pós-realocação de pagamento.
Por exemplo, um usuário pode comprar itens alimentícios e de prescrição a partir de um Acme Supermarket varejista.
O usuário pode, de maneira inadvertida ou para facilidade de finalização de compra, por exemplo, usar seu cartão Visa para pagar tanto itens alimentícios, como de prescrição.
Entretanto, o usuário pode ter uma conta FSA que pode ser usada para itens de prescrição, e que pode proporcionar benefícios fiscais ao usuário.
Em tal situação, o usuário pode usar o modo instantâneo para iniciar a realocação de transação.
Conforme mostrado, o usuário pode procurar um termo de pesquisa (por exemplo, faturas) na barra de pesquisa 2121. O usuário pode, então, identificar na guia 5222 o recibo 5223 que o usuário deseja realocar.
De maneira alternativa, o usuário pode ajustar diretamente uma imagem de um código de barra em um recibo, e o modo instantâneo pode gerar e exibir um recibo 5223 usando informações a partir do código de barra.
O usuário agora pode realocar 5225. Em algumas implementações, o usuário também pode contestar a transação 5224 ou arquivar o recibo 5226. Em uma implementação, quando o botão realocar 5225 for selecionado, o aplicativo de carteira pode realizar o reconhecimento óptico de caracteres (OCR) do recibo.
Cada um 5 dos itens no recibo pode, então, ser examinado para identificar um ou mais itens que podem ser cobrados em qual dispositivo de pagamento ou conta para taxa ou outros benefícios, tais como, reembolso, pontos de fidelidade, etc.
Neste exemplo, existe um benefício fiscal se o medicamento de prescrição cobrado no cartão Visa do usuário for cobrado da FSA do usuário.
O aplicativo de carteira pode, então, realizar a realocação como o back end.
O 1O processo de realocação 1 pode incluir a carteira que entra em contato com o processador de pagamento para creditar um valor do medicamento de prescrição do cartão Visa e debitar a mesma quantia da conta FSA do usuário.
Em uma implementação alternativa, o processador de pagamento (por exemplo, Visa ou MasterCard) pode obter e OCR o recibo, identificar itens e contas de pagamento para realocação e realizar a realocação.
Em uma implementação, o aplicativo de carteira pode solicitar ao usuário para confirmar a realocação de cobranças para os itens selecionados em outra conta de pagamento.
O recibo 5227 pode ser gerado após a conclusão do processo de realocação.
Conforme discutido, o recibo mostra que algumas cobranças foram movidas da conta Visa para a FSA.
Com referência à Figura 52C, em uma modalidade, o modo instantâneo pode facilitar o pagamento através do código de pagamento, tais como, códigos de barra ou códigos QR.
Por exemplo, um usuário pode ajustar um código QR de uma transação que ainda não foi concluída.
O código QR pode ser exibido em um terminal POS do estabelecimento, um site da web ou um aplicativo da Web e pode ser codificado com informações que identificam itens para compra, detalhes de estabelecimento e outras informações relevantes.
Quando o usuário ajusta tal código QR, o modo instantâneo pode decodificar as informações no código QR e pode usar as informações decodificadas para gerar um recibo 5232. Uma vez que o código QR é identificado, a barra de navegação 5231 pode indicar que o código de pagamento é identificado.
O usuário agora pode ter uma opção de adicionar ao carrinho 5233, pagar com uma conta de pagamento padrão 5234 ou pagar com carteira 5235. Em uma implementação, o usuário pode decidir pagar com a conta padrão 5234. O aplicativo de carteira pode, então, usar o método de pagamento padrão do usuário, neste exemplo, a carteira, para concluir a transação de compra.
Mediante a conclusão da transação, um recibo pode ser automaticamente gerado para prova de compra.
A interface de usuário também pode ser atualizada para proporcionar outras opções para manipulação de uma transação concluída.
As opções exemplificativas incluem social 5237 para compartilhar informações de compra com outros, realocar 5238, conforme discutido em relação à Figura 528, e arquivar 5239 para armazenar o recibo.
Com referência à Figura 520, em uma modalidade, o modo instantâneo também pode facilitar a identificação, aplicação e armazenamento de oferta para uso futuro.
Por exemplo, em uma implementação, um usuário pode ajustar um código de oferta 5241 (por exemplo, um código de barra, um código QR, e/ou similares). O aplicativo de carteira, então, pode gerar um texto de oferta 5242 a partir das informações codificadas no código de oferta.
O usuário pode realizar inúmeras ações no código de oferta.
Por exemplo, o usuário usa o botão localizar 5243 para encontrar todos os estabelecimentos que aceitam o código de oferta, estabelecimentos nas proximidades que aceitam o código de oferta, produtos de estabelecimento qualificados para o código de oferta, e/ou similares.
O usuário também 1O pode aplicar o código de oferta aos itens que estão atualmente no carrinho usando o botão adicionar ao carrinho 5244. Além disso, o usuário também pode salvar a oferta para uso futuro selecionando-se o botão salvar 5245. Em uma implementação, após a oferta ou cupom 5246 ser aplicado, o usuário pode ter a opção de encontrar estabelecimentos e/ou produtos qualificados usando localizar, o usuário pode se dirigir até a carteira usando 5248, e o usuário também pode salvar a oferta ou cupom 5246 para uso posterior.
Com referência à Figura 52E, em uma modalidade, o modo instantâneo também pode oferecer instalações para adicionar uma fonte de financiamento ao aplicativo de carteira.
Em uma implementação, um cartão de pagamento, tal como, um cartão de crédito, cartão de débito, cartão pré-pago, cartão inteligente e outras contas de pagamento podem ter um código associado, tal como, um código de barra ou código QR.
Tal código pode ter codificado neste, informações de cartão de pagamento que incluem, porém, sem caráter limitativo, nome, endereço, tipo de cartão de pagamento, detalhes de conta de cartão de pagamento, saldo, limite de gastos, saldo de premiações, e/ou similares.
Em uma implementação, o código pode ser encontrado em uma face do cartão de pagamento físico.
Em outra implementação, o código pode ser obtido acessando-se uma conta online associada ou outro local seguro.
Em ainda outra implementação, o código pode ser impresso em uma carta que acompanha o cartão de pagamento.
Um usuário, em uma implementação, pode ajustar uma imagem do código.
O aplicativo de carteira pode identificar o cartão de pagamento 5251 e pode exibir as informações de texto 5252 codificadas no cartão de pagamento.
O usuário pode, então, realizar a verificação das informações 5252 selecionando-se o botão verificar 5253. Em uma implementação, a verificação pode incluir entrar em contato com o emissor do cartão de pagamento para confirmação das informações decodificadas 5252 e quaisquer outras informações relevantes.
Em uma implementação, o usuário pode adicionar o cartão de pagamento à carteira selecionando-se o botão 'adicionar à carteira' 5254. A instrução para adicionar o cartão de pagamento à carteira pode fazer com que o cartão de pagamento apareça como uma das formas de pagamento sob a guia de fundos 5016 discutida na Figura SOA. O usuário também pode cancelar a importação do cartão de pagamento como uma fonte de financiamento selecionando-se o botão cancelara 5255. Quando o cartão de pagamento tiver sido adicionado à carteira, a interface de usuário pode ser atualizada para indicar que a 5 importação é concluída através da tela de notificação 5256. O usuário pode, então, acessar a carteira 5257 para começar a usar o cartão de pagamento adicionado como uma fonte de financiamento. A Figura 53 mostra um diagrama de interface de usuário que ilustra características exemplificativas de aplicativos de carteira virtual, em um modo de ofertas, em algumas modalidades do UEP. Em algumas implementações, o UEP pode permitir que um usuário procure por ofertas de produtos e/ou serviços de dentro do aplicativo móvel de carteira virtual. Por exemplo, o usuário pode inserir texto em um elemento de interface gráfica de usuário ("GUI") 5311, ou emitir comandos de voz ativando-se o elemento de GUI 5312 e comandos de fala no dispositivo. Em algumas implementações, o UEP pode proporcionar ofertas com base no comportamento anterior do usuário, demografia, localização atual, seleção de carrinho atual ou itens de compra, e/ou similares. Por exemplo, se um usuário se encontra em uma loja física ou um site da web de compras online, e sai da loja (virtual), então, o comerciante associado à loja pode desejar proporcionar um incentivo para atrair o consumidor de volta à loja (virtual). O comerciante pode proporcionar tal oferta 5313. Por exemplo, a oferta pode proporcionar um desconto, e pode incluir um tempo de expiração. Em algumas implementações, outros usuários podem proporcionar presentes (por exemplo, 5314) para o usuário, que o usuário pode resgatar. Em algumas implementações, a seção de ofertas pode incluir alertas para pagamento de fundos excelentes para outros usuários (por exemplo, 5315). Em algumas implementações, a seção de ofertas pode incluir alertas para solicitar o recebimento de fundos de outros usuários (por exemplo, 5316). Por exemplo, tal recurso pode identificar fundos recebíveis a partir de outros aplicativos (por exemplo, correio, calendário, tarefas, notas, programas de lembrete, alarme, etc.), ou através de uma entrada manual através do usuário no aplicativo de carteira virtual. Em algumas implementações, a seção de ofertas pode proporcionar ofertas de estabelecimentos participantes no UEP, por exemplo, 5317-5319, 5320. Estas ofertas algumas vezes podem ser montadas usando uma combinação de estabelecimentos participantes, por exemplo,
5317. Em algumas implementações, o próprio UEP pode proporcionar ofertas para contingente de usuários para o usuário que utiliza formas de pagamento particulares a partir do aplicativo de carteira virtual, por exemplo, 5320. As Figuras 54A-B mostram diagramas de interface de usuário que ilustram características exemplificativas de aplicativos de carteira virtual, em um modo de segurança e privacidade, em algumas modalidades do UEP. Com referência à Figura 54A, em algumas implementações, o usuário pode ser capaz de visualizar e/ou modificar o perfil e/ou configurações de usuário do usuário, por exemplo, ativando-se um elemento de interface de usuário.
Por exemplo, o usuário pode ser capaz de visualizar/modificar um nome de usuário (por exemplo, 54iia-b), número de conta (por exemplo, 54i2a-b), código de acesso de 5 segurança de usuário (por exemplo, 5413-b), pin do usuário (por exemplo, 5414-b), endereço de usuário (por exemplo, 5415-b), número de seguro social associado ao usuário (por exemplo, 5416-b), localização por GPS de dispositivo atual (por exemplo, 5417-b), conta de usuário do comerciante em cuja loja o usuário se encontra atualmente (por exemplo, 5418-b), as contas de recompensas do usuário (por exemplo, 5419-b), e/ou 1O similares.
Em algumas implementações, o usuário pode ser capaz de selecionar quais dos campos de dados e seus valores associados devem ser transmitidos para facilitar a transação de compra proporcionando, deste modo, a segurança de dados aprimorada para o usuário.
Por exemplo, na ilustração exemplificativa na Figura 54A, o usuário selecionou o nome 5411a, número de conta 5412a, código de segurança 5413a, ID de conta de comerciante 5418a e ID de conta de premiações 5419a como os campos a serem enviados como parte da notificação para o processo da transação de compra.
Em algumas implementações, o usuário pode ativar/desativar os campos e/ou valores de dados que são enviados como parte da notificação para o processo das transações de compra.
Em algumas implementações, o aplicativo pode proporcionar múltiplas telas de campos e/ou valores de dados associados armazenados para o usuário selecionar como parte da transmissão de pedido de compra.
Em algumas implementações, o app pode proporcionar o UEP com a localização por GPS do usuário.
Com base na localização por GPS do usuário, o UEP pode determinar o contexto do usuário (por exemplo, se o usuário se encontra em uma loja, consultório médico, hospital, escritório do serviço postal, etc.). Com base no contexto, o app de usuário pode apresentar os campos apropriados para o usuário, a partir do qual o usuário pode selecionar campos e/ou valores de campo para enviar como parte da transmissão de pedido de compra.
Por exemplo, um usuário pode ir até o consultório médico e desejar pagar o co- pagamento para a consulta médica.
Além das informações de transação básicas, tais como, número e nome de conta, o app pode proporcionar ao usuário a capacidade de selecionar a transferir registros médicos, informações sobre saúde, que podem ser proporcionadas para o prestador de serviços médicos, companhia de seguros, assim como, o processador de transação para conciliar os pagamentos entre as partes.
Em algumas implementações, os registros podem ser enviados em um formato de dados compatível com a Lei de Portabilidade e Responsabilidade de Seguros de Saúde (HIPAA) e criptografados, e apenas os destinatários que estão autorizados a visualizar tais registros podem ter chaves de descriptografia apropriadas para descriptografar e visualizar as informações de usuário privadas.
Com referência à Figura 548, em algumas implementações, a app que executa no dispositivo do usuário pode proporcionar um recursos "VerifyChat" para prevenção de fraude.
Por exemplo, o UEP pode detectar uma transação incomum e/ou suspeita.
O UEP pode utilizar o recurso VerifyChat para se comunicar com o usuário, e verificar a autenticidade do originador da transação de compra.
Em diversas implementações, o UEP pode enviar mensagem de correio eletrônico, mensagens de texto (SMS), mensagens de Facebook®, tweets do Twitter™, chat de texto, chat de voz, chat de vídeo (por exemplo, 1O Apple FaceTime), e/ou similares, para se comunicar com o usuário.
Por exemplo, o UEP pode iniciar um desafio de vídeo para o usuário, por exemplo, 5421. Por exemplo, o usuário pode precisar se apresentar através de um chat de vídeo, por exemplo, 5422. Em algumas implementações, um representante de serviço ao cliente, por exemplo, agente 5424, pode determinar manualmente a autenticidade do usuário que usa o vídeo do usuário.
Em algumas implementações, o UEP pode utilizar reconhecimento de face, biométrico e/ou similar (por exemplo, usando técnicas de classificação padrão) para determinar a identidade do usuário.
Em algumas implementações, o app pode proporcionar marcador de referência (por exemplo, miras, caixa de destino, etc.), por exemplo, 5423, de modo que o usuário possa fazer com que o vídeo facilite o reconhecimento automatizado do UEP do usuário.
Em algumas implementações, o usuário pode não ter iniciado a transação, por exemplo, a transação é fraudulenta.
Em tais implementações, o usuário pode cancelar o desafio.
O UEP pode, então, cancelar a transação, e/ou iniciar procedimentos de investigação de fraude em nome do usuário.
Em algumas implementações, o UEP pode utilizar um procedimento de desafio de texto para verificar a autenticidade do usuário, por exemplo, 5425. Por exemplo, o UEP pode se comunicar com o usuário através de chat de texto, mensagens SMS, correio eletrônico, mensagens de Facebook®, tweets do Twitter™, e/ou similares.
O UEP pode representar uma questão de desafio, por exemplo, 5426, para o usuário.
O app pode proporcionar um elemento de interface de entrada de usuário (por exemplo, teclado virtual 5428) para responder à questão de desafio representada pelo UEP.
Em algumas implementações, a questão de desafio pode ser aleatoriamente selecionada pelo UEP de maneira automática; em algumas implementações, um representante de serviço ao cliente pode se comunicar manualmente com o usuário.
Em algumas implementações, o usuário pode não ter iniciado a transação, por exemplo, a transação é fraudulenta.
Em tais implementações, o usuário pode cancelar o desafio de texto.
O UEP pode cancelar a transação, e/ou iniciar a investigação de fraude em nome do usuário.
Plataforma de Transação UEP A Figura 55 mostra um diagrama de fluxo de dados que ilustra um procedimento de finalização de compra de usuário exemplificativo em algumas modalidades do UEP.
Em algumas modalidades, um usuário, por exemplo, 5501 a, pode desejar adquirir um produto, 5 serviço, oferta, e/ou similares ("produto"), a partir de um de um comerciante através de um site online do comerciante ou na loja do comerciante.
O usuário pode se comunicar com um servidor de comerciante/adquirente ("comerciante"), por exemplo, 5503a, através de um cliente, tal como, porém, sem caráter limitativo: um computador pessoal, dispositivo móvel, televisão, terminal de ponto de venda, quiosque, ATM, e/ou similares (por exemplo, 5502). 1O Por exemplo, o usuário pode proporcionar entrada de usuário, por exemplo, entrada de finalização de compra 5511, para o cliente que indica o desejo do usuário em comprar o produto.
Em diversas modalidades, a entrada de usuário pode incluir, porém, sem caráter limitativo: um único toque (por exemplo, uma modalidade de aquisição de app móvel em um toque) de uma interface sensível ao toque, entrada de teclado, cartão magnético, que ativa um dispositivo de hardware habilitado para RFID/NFC (por exemplo, cartão eletrônico que tem múltiplas contas, smartphone, tablet, etc.) dentro do dispositivo de usuário, cliques do mouse, pressionamento de botões em um joystick/console de jogo, comandos de voz, gestos de toque único/multitoque em uma interface sensível ao toque, toque de elementos de interface de usuário em uma tela sensível ao toque, e/ou similares.
Como um exemplo, um usuário em uma loja comercial pode varrer um código de barra de produto do produto através de um scanner de código de barra em um terminal de ponto de venda.
Como outro exemplo, o usuário pode selecionar um produto a partir de um catálogo de página da web no site da web do comerciante, e adicionar o produto a um carrinho de compras virtual no site da web do comerciante.
O usuário pode, então, indicar o desejo de o usuário finalizar a compra dos itens no carrinho de compras (virtual). Por exemplo, o usuário pode ativar um elemento de interface de usuário proporcionado pelo cliente para indicar o desejo de o usuário finalizar a compra.
O cliente pode gerar uma solicitação de finalização de compra, por exemplo, 5512, e proporcionar a solicitação de finalização de compra, por exemplo, 5513, para o servidor de comerciante.
Por exemplo, o cliente pode proporcionar uma mensagem de Protocolo de Transferência de Hipertexto (Seguro) ("HTTP(S)") POST que inclui os detalhes de produto para o servidor de comerciante na forma de dados formatados de acordo com a Linguagem de Marcação extensível ("XML"). Uma listagem exemplificativa de uma solicitação de finalização de compra 5512, substancialmente na forma de uma mensagem HTTP(S) POST que inclui dados formatados XML, é proporcionada abaixo:
POST /checkoutrequest .php HTTP/ 1 . 1 Host: www.merchant.com Content-Type: Application/XML Content-Length: 667 5 <?XML version =" 1 . O" encoding ="UTF-8 " ?> <checkout_request> <checkout_I D>4NFU4RG94</checkout_I D> <timestamp>2011- 02 -22 15: 22: 43</timestamp> <purchase_detail> <num_products>5</num_products> <product_I D>AE95049324</product_I D> <product_I D>MD09808755</product_I D> <product_ID>OC 12345764</product_I D> <prod uct_I D>KE76549043</prod uct_I D> <product_ID>SP27674509</product_ID> </purchase_detail> <!--opcional parameters--> <user_ID>john. q. publicSgmail. com</user_ID> <PoS_ client_detail> <client_IP>192.168.23.126</client_IP> <client_type>smartphone</client_type> <client_model>HTC Hero</client_model> <OS>Android 2.2</0S> <app_installed_flag>true</app_installed_flag> </PoS_ client_detail> </checkout_request> Em algumas modalidades, o servidor de comerciante pode obter a solicitação de finalização de compra a partir do cliente, e extrair o detalhe de finalização de compra (por exemplo, dados XML) da solicitação de finalização de compra.
Por exemplo, o servidor de comerciante pode utilizar um analisador, tais como, exemplo os analisadores descritos abaixo na discussão com referência à Figura 61. Com base na análise da solicitação de finalização de compra 5512, o servidor de comerciante pode extrair dados de produto (por exemplo, identificadores de produto), assim como, dados de cliente PoS disponíveis, a partir da solicitação de finalização de compra.
Em algumas modalidades, usando os dados de produto, o servidor de comerciante pode consultar, por exemplo, 551, um banco de dados de comerciante/adquirente ("comerciante"), por exemplo, 5503b, para obter dados de produto, por exemplo, 5515, tais como, informações de produto, preço de produtos, taxa de vendas, ofertas, descontos, prêmios, e/ou outras informações para processar a transação de compra e/ou proporcionar serviços de valor agregado para o usuário.
Por exemplo, o banco de dados de estabelecimento pode ser um banco de dados relacional responsivo aos comandos de Linguagem de Consulta Estruturada ("SQL"). O servidor de comerciante pode 5 executar um script de pré-processador de hipertexto ("PHP") que inclui comandos SQL para consultar uma tabela de banco de dados (tal como, a Figura 61, Produtos 61191) para dados de produto.
Uma consulta de dados de produto exemplificativa 5514, substancialmente na forma de comandos PHP/SQL, é proporcionada abaixo: <?PHP header ('Content-Type: text/plain'); mysql_connect ("254.93.179.112", $DBserver, $password) li access database server mysql_select_db ( "UEP_DB . SQL") ; li select database table to search llcreate query $query ="SELECT product_title product_attributes_list product_price tax_info_list related_products_list offers_list discounts_list rewards_list merchants_list merchant_availability_list FROM ProductsTable WHERE product_ID LIKE'%'$prodlD"; $result =mysql_query ( $query) ; li perform the search query mysql_close ( "UEP_DB . SQL" ) ; li close database access ?> Em algumas modalidades, em resposta à obtenção dos dados de produto, o servidor de comerciante pode gerar, por exemplo, 5516, dados de finalização de compra para proporcionar para o cliente PoS.
Em algumas modalidades, tais dados de finalização de compra, por exemplo, 5517, podem ser incorporados, em parte, em uma página de Linguagem de Marcação de Hipertexto ("HTML") que inclui dados para exibição, tais como, detalhe de produto, preço de produtos, preço total, informações fiscais, informações de entrega, ofertas, descontos, prêmios, informações de serviço de valor agregado, etc., e campos de entrada para proporcionar informações de pagamento para processar a transação de compra, tais como, nome do titular da conta, número de conta, endereço de cobrança, endereço de entrega, quantia de gorjeta, etc.
Em algumas modalidades, os dados de finalização de compra podem ser incorporados, em parte, em uma imagem de código de Resposta Rápida ("QR") que o cliente PoS pode exibir, de modo que o usuário possa capturar o código QR usando um dispositivo do usuário para obter dados de estabelecimento e/ou dados de produto para gerar uma solicitação de processamento de transação de compra.
Em algumas modalidades, um mecanismo de alerta de usuário pode ser embutido nos dados de finalização de compra.
Por exemplo, o servidor de comerciante pode incorporar um URL específico para a transação nos dados de finalização de compra.
Em algumas modalidades, os alertas URL podem ser adicionalmente embutidos nos dados de nível opcional em pedidos de autorização de cartão, tais como, aqueles discutidos adicionalmente abaixo com referência às Figuras 57-58. O URL pode apontar para uma página da web, arquivo de dados, script executável, etc., armazenado no servidor do comerciante dedicado à transação que é o assunto do pedido de autorização de cartão.
Por exemplo, o objetivo apontado pelo URL pode incluir detalhes sobre a transação de compra, por exemplo, produtos que são adquiridos, custo de compra, tempo de expiração, estado de processamento de ordem, e/ou similares.
Deste modo, o servidor de comerciante pode 1O proporcionar para a rede de pagamento os detalhes da transação passando-se o URL da página da web para a rede de pagamento.
Em algumas modalidades, a rede de pagamento pode proporcionar notificações para o usuário, tais como, um recibo de pagamento, mensagem de confirmação de autorização de transação, notificação de entrega, e/ou similares.
Em tais mensagens, a rede de pagamento pode proporcionar o URL para o dispositivo de usuário.
O usuário pode navegar o URL no dispositivo do usuário para obter alertas que se referem à compra do usuário, assim como, outras informações, tais como, ofertas, cupons, produtos relacionados, notificações de premiações, e/ou similares.
Uma listagem exemplificativa de dados de finalização de compra 5517, substancialmente na forma de dados formatados XML, é proporcionada abaixo: <?XML version = "1.0" encoding = "UTF- 8"? > <checkout_data> <session_I D>4NFU4RG94</session_I D> <timestamp>2011-02-22 15: 22: 43</timestamp> <expiry_lapse>OO: 00: 30</expiry_lapse> <transação_cost>$34. 78</ transaction_cost> <alerts_URL>www. merchant com/shopcarts .php?sessionlD=4NFU4RG94</alerts_URL> <!--opcional data--> <user_ID>john.q.publicSgmail. com</user_ID> <client_details> <client_IP>192.168.23.126</client_IP> <client_type>smartphone</client_type> <client model>HTC Hero</client model> <OS>Android 2.2</[0S> <app_installed_flag>true</app_installed _flag > </client_details> <purchase_details>
<num_products>K/num_products> <product> <product_type>book</product_type> <product_params> 5 <product_title> XML for dummies</product_title> <ISBN>938-2-14-168710-0</ISBN> <edition>2nd ed. </edition> <cover>hardbound</ cover> <seller>bestbuybooks</seller> </product_params> <quantity>1 </quantity> </product> </purchase_details> <offers_details> <num_offers>1 </num_offers> <product> <product_type>book</product_type> <product_params> <product_title>Here's more XML </product_title> <ISBN>922-7-14-165720-K/ISBN> <edition>lnd ed. </edition> <cover>hardbound</ cover> <seller>d ig ibooks</seller> </product_params> <quantity>1 </quantity> </product> </offers_details> <secure_element>www merchant comi securedyn/ 0394733/123.png</ secure_ element> <merchant_params> <merchant_id>3FBCR41NC</merchant_id> <merchant_name>Books & Things, lnc . </merchant_name> <merchant_auth_key>INNF484MCP59CHB27365</merchant_auth_key> </merchant_params> <checkout_data>
Mediante a obtenção dos dados de finalização de compra, por exemplo, 5517, o cliente PoS pode renderizar e exibir, por exemplo, 5518, os dados de finalização de compra para o usuário.
A Figura 56 mostra a diagrama de fluxo lógico que ilustra os aspectos 5 exemplificativos de uma finalização de compra de usuário em algumas modalidades do UEP, por exemplo, um componente de Finalização de Compra de Usuário ("UPC") 5600. Em algumas modalidades, um usuário pode desejar adquirir um produto, serviço, oferta, e/ou similares ("produto"), a partir de um comerciante através de um site online do comerciante ou na loja do comerciante.
O usuário pode se comunicar com um servidor do 1O comerciante/adquirente ("comerciante") através de um cliente PoS.
Por exemplo, o usuário pode proporcionar entrada de usuário, por exemplo, 5601, para o cliente que indica o desejo do usuário em adquirir o produto.
O cliente pode gerar uma solicitação de finalização de compra, por exemplo, 5602, e proporcionar a solicitação de finalização de compra para o servidor de comerciante.
Em algumas modalidades, o servidor de comerciante pode obter a solicitação de finalização de compra a partir do cliente, e extrair o detalhe de finalização de compra (por exemplo, dados XML) a partir da solicitação de finalização de compra.
Por exemplo, o servidor de comerciante pode utilizar um analisador, tais como, os analisadores exemplificativos descritos abaixo na discussão com referência à Figura 61. Com base na análise da solicitação de finalização de compra, o servidor de comerciante pode extrair dados de produto (por exemplo, identificadores de produto), assim como, dados de cliente PoS disponíveis, da solicitação de finalização de compra.
Em algumas modalidades, usando os dados de produto, o servidor de comerciante pode consultar, por exemplo, 5603, um banco de dados de comerciante/adquirente ("comerciante") para obter dados de produto, por exemplo, 5604, tais como, as informações de produto, preço de produtos, taxa de vendas, ofertas, descontos, prêmios, e/ou outras informações para processar a transação de compra e/ou proporcionar serviços de valor agregado para o usuário.
Em algumas modalidades, em resposta à obtenção dos dados de produto, o servidor de comerciante pode gerar, por exemplo, 5605, dados de finalização de compra para proporcionar, por exemplo, 5606, para o cliente PoS.
Mediante a obtenção dos dados de finalização de compra, o cliente PoS pode renderizar e exibir, por exemplo, 5607, os dados de finalização de compra para o usuário.
As Figuras 57 A-B mostram diagramas de fluxo de dados que ilustram um procedimento de autorização de transação de compra exemplificativo em algumas modalidades do UEP.
Com referência à Figura 57A, em algumas modalidades, um usuário, por exemplo, 5701 a, pode desejar utilizar uma conta de carteira virtual para adquirir um produto, serviço, oferta, e/ou similares ("produto"), a partir de um comerciante através de um site online do comerciante ou na loja do comerciante.
O usuário pode utilizar um cartão físico, ou um dispositivo de carteira de usuário, por exemplo, 5701 b, para acessar a conta de carteira virtual do usuário.
Por exemplo, o dispositivo de carteira de usuário pode ser um computador pessoal/laptop, telefone celular, smartphone, tablet, leitor de eBook, netbook, console de jogo, e/ou similares.
O usuário pode proporcionar uma entrada de acesso de carteira, por exemplo, 5711 no dispositivo de carteira de usuário.
Em diversas modalidades, 5 a entrada de usuário pode incluir, porém, sem caráter limitativo: um toque único (por exemplo, uma modalidade de aquisição de app móvel em um toque) de uma interface sensível ao toque, entrada de teclado, cartão magnético, que ativa um dispositivo de hardware habilitado para RFID/NFC (por exemplo, cartão eletrônico que tem múltiplas contas, smartphone, tablet, etc.) dentro do dispositivo de usuário, cliques do mouse, 1O pressionamento de botões em um joystick/console de jogo, comandos de voz, gestos de toque único/multitoque em uma interface sensível ao toque, toque de elementos de interface de usuário em uma tela sensível ao toque, e/ou similares.
Em algumas modalidades, o dispositivo de carteira de usuário pode autenticar o usuário com base na entrada de acesso de carteira do usuário, e proporcionar recursos de carteira virtual para o usuário.
Em algumas modalidades, mediante a autenticação do usuário para acessar os recursos de carteira virtual, o dispositivo de carteira de usuário pode proporcionar uma entrada de autorização de transação, por exemplo, 5714, para um cliente de ponto de venda ("PoS"), por exemplo, 5702. Por exemplo, o dispositivo de carteira de usuário pode se comunicar com o cliente PoS através de Bluetooth, Wi-Fi, comunicação celular, comunicação de campo próximo unidirecional ou bidirecional ("NFC"), e/ou similares.
Nas modalidades em que o usuário utiliza um cartão de plástico em vez do dispositivo de carteira de usuário, o usuário pode passar o cartão de plástico no cliente PoS para transferir informações a partir do cartão de plástico para o cliente PoS.
Por exemplo, o cliente PoS pode obter, como a entrada de autorização de transação 5714, rastrear os dados a partir do cartão de plástico do usuário (por exemplo, cartão de crédito, cartão de débito, cartão pré- pago, cartão de carga, etc.), tais como, os dados de rastreamento 1 exemplificativos proporcionados abaixo: %8123456789012345PUBLIC/ J.
Q./\99011200000000000000** 901 ******?* (wherein '123456789012345' is the card number of V.O.
Public'and has a CW number of 901. '990112' is a service code, and *** represents decimal digits which change randomly each time the card is used.) Nas modalidades em que o usuário utiliza um dispositivo de carteira de usuário, o dispositivo de carteira de usuário pode proporcionar informações de pagamento para o cliente PoS, formatadas de acordo com um protocolo de formatação de dados apropriado para o mecanismo de comunicação empregado na comunicação entre o dispositivo de carteira de usuário e o cliente PoS.
Uma listagem exemplificativa da entrada de autorização de transação 5714, substancialmente na forma de dados formatados XML, é proporcionada abaixo: <?XML version ="1.0" encoding ="UTF-8"?> <transction_authorization_input> 5 <payment_data> <account_source> <charge_priority>I</ charge_priority> <charge_type>rewards</ charge_type> <charge_issuer>lssuerl</ charge_issuer> <charge_mode>FNC</ charge_mode> <charge_ratio>40%</charge_ratio> <account_number>123456789012345</account_number> <account_name>John Q.
Public</account_name> <bill_add>987 Green St #456, Chicago, IL 94652</bill_add> <ship_add>987 Green St #456, Chicago, IL 94652</ship_add> <CW>123</CW> </account_source> <account_source> <charge_priority>I</ charge_priority> <charge_type>points</charge_type> <charge_mode>FNC</ charge_mode> <charge_issuer>lssuer2</ charge_issuer> <charge_ratio>60%</charge_ratio> <account number>234567890123456</account number> <account_name>John Q.
Public</account_name> <bill_add>987 Green St #456, Chicago, IL 94652</bill_add> <ship_add>987 Green St #456, Chicago, IL 94652</ship_add> <CW>173</CW> </account_source> <account_source> <charge_priority>2</ charge_priority> <charge_type>credit</charge_type> <charge_mode>FNC</ charge_mode> <charge_issuer>lssuerl</ charge_issuer> <charge_ratio>100%</ charge_ratio> <account_number>345678901234567 </account_number> <account_name>John Q.
Public</account_name>
<bill_add>987 Green St #456, Chicago, IL 94652</bill_add> <ship_add>987 Green St #456, Chicago, IL 94652</ship_add> <CW>695</CW> </account_source> </pagamento_data> <! --optional data--> <timestamp>2011-02-22 15: 22: 43</timestamp> <expiry_lapse>OO: 00: 30</expiry_lapse> <secure_key>0445329070598623487956543322</secure_key> <alerts_track_flag>TRUE</alerts_track_flag> <wallet_device_ details> <device_IP>192.168.23.126</client_IP> <device_ type>smartphone</client_type> < device_model>HTC Hero</client_model> <OS>Android 2.2</0S> <wallet_app_installed_flag>true</wallet_app_installed_flag> </wallet_device_details> </transaction_authorization_input> Em algumas modalidades, o cliente PoS pode gerar um pedido de autorização de cartão, por exemplo, 5715, usando a entrada de autorização de transação obtida a partir do dispositivo de carteira de usuário, e/ou dados de produto/finalização de compra (vide, por exemplo, Figura 55, 5515-5517). Uma listagem exemplificativa de um pedido de autorização de cartão 5715, substancialmente na forma de uma mensagem HTTP(S) POST que inclui dados formatados XML, é proporcionada abaixo: POST /authorizationrequests .php HTTP/1.1 Host: www.acquirer.com Content-Type: Application/XML Content-Length: 1306 <?XML version = "1.0" encoding = "UTF-8"?> <card_authorization_request> <session_I D>4NFU4RG94</order_I D> <timestamp>2011-02-22 15: 22: 43</timestamp> <expiry>OO: 00: 30</expiry> <alerts_URL>www merchant comi shopcarts php?sessionlD=AEBB4356</alerts_URL> <!--opcional data--> <user_ID>john. q. publicSgmail. com</user_ID>
<PoS details> <PoS_IP>192.168.23.126</client_IP> <PoS_type>smartphone</ client_type> <PoS_model>HTC Hero</client_model> 5 <OS>Android 2.2</0S> <app_installed_flag>true</app_installed_flag> </PoS_ details> <purchase_details> <cart1> <num_products>l</num_products> <product> <product_type>book</product_type> <product_params> <product_title> XML for dummies</product_title> <ISBN>938-2-14-168710-0</ISBN> <edition>2nd ed. </edition> <cover>hardbound</ cover> <seller>bestbuybooks</seller> </product_params> <quantity>1 </quantity> </product> <mode>socialpay</mode> <payee> <I D>merchantl</I D> <Address>123 Baker St, Chicago, IL 00000</Address> </payee> <offer>id#23456768543_ 2052</offer> <social status> <type>twitter</type> <message>thx4thetip</message> </ social status> <cloak>ON</cloak> </cart1> <cart2> <num_products>K/num_products> <product> <product_type>book</product_type>
<product_params> <product_title>XML for dummies</product_title> <ISBN>938-2-14-168710-0</ISBN> <edition>2nd ed. </edition> 5 <cover>hardbound</cover> <seller>bestbuybooks</seller> </product_params> <quantity>K/quantity> </product> <mode>NFC</mode> <payee> <I D>johnqpublic</ID> <Address>123 Baker St, Chicago, IL 00000</Address> </payee> <offer>id#23456768543_ 2052</offer> <social_status> <type>facebook</ type> <message>@jqp: dinner was great ! </message> </ social_status> <cloak>OFF</cloak> </cart2> </purchase_details> <merchant_params> <merchant_id>3FBCR41NC</merchant_id> <merchant_name>Books & Things, lnc. </merchant_name> <merchant_auth_key>INNF484MCP59CHB27365</merchant_auth_key> <merchant_mode>snap</merchant_mode> </merchant_params> <account_params> <account_name>John Q.
Public</account_name> <account_type>credit</account_type> <account_num>123456789012345</account_num> <billing_address>123 Green St., Norman, OK 98765</billing_address> <phone> 123-456-7809</phone> <sign>/jqp/</sign> <confirm_type>email</confirm_type> <contact_info>john.q . public@gmail.com</contact_info>
</account_params> <shipping_info> <shipping_adress>same as billing</shipping_address> <ship_type>expedited</ ship_type> <ship_carrier>FedEx</ ship_carrier> <ship_account>123-45-678</ ship_account> <tracking_flag>true</tracking_flag> <sign_flag>false</sign_flag> </ shipping_info> </card_authorization_request> Em algumas modalidades, o pedido de autorização de cartão gerado pelo dispositivo de usuário pode incluir um mínimo de informações requeridas para processar a transação de compra.
Por exemplo, isto pode aprimorar a eficiência de comunicação da solicitação de transação de compra, e também pode aprimorar vantajosamente as proteções de privacidade proporcionadas para o usuário e/ou comerciante.
Por exemplo, em algumas modalidades, o pedido de autorização de cartão pode incluir pelo menos um ID de sessão para a sessão de compras do usuário com o comerciante.
O ID de sessão pode ser utilizado por qualquer componente e/ou entidade que tenha uma autoridade de acesso apropriada para acessar um site seguro no servidor de comerciante para obter alertas, lembretes e/ou outros dados sobre a transação dentro da sessão de compras entre o usuário e o comerciante.
Em algumas modalidades, o cliente PoS pode proporcionar o pedido de autorização de cartão gerado para o servidor de comerciante, por exemplo, 5716. O servidor de comerciante pode encaminhar o pedido de autorização de cartão para um servidor de gateway de pagamento, por exemplo, 5704a, para rotear o pedido de autorização de cartão até a rede de pagamento apropriada para o processamento de pagamento.
Por exemplo, o servidor de gateway de pagamento pode ser capaz de selecionar a partir das redes de pagamento, tais como, Visa, Mastercard, American Express, Paypal, etc., para processar diversos tipos de transações que incluem, porém, sem caráter limitativo: cartão de crédito, cartão de débito, cartão pré-pago, 828 e/ou transações similares.
Em algumas modalidades, o servidor de comerciante pode consultar um banco de dados, por exemplo, banco de dados de comerciante/adquirente 5703b, para um endereço de rede do servidor de gateway de pagamento, por exemplo, usando-se uma parte de um número de cartão de pagamento de usuário, ou um ID de usuário (tal como, um endereço de email) como uma palavra-chave para a consulta de banco de dados.
Por exemplo, o servidor de comerciante pode emitir comandos PHP/ SQL para consultar uma tabela de banco de dados (tal como, a Figura 61, Gateways de Pagamento 611911) para um URL do servidor de gateway de pagamento.
Uma consulta de endereço de gateway de pagamento exemplificativo 5717, substancialmente na forma de comandos PHP/SQL, é proporcionada abaixo: <?PHP header ('Content-Type: text/plain'); 5 mysql_connect ("254.93.179.112", $D8server, $password) // access database server mysql_select_db ( "UEP_08 . SQL" ) ; li select database table to search //create query $query = "SELECT paygate_id paygate_address paygate_URL paygate_name
FROM PayGatewayTable WHERE card_num LIKE'%'$cardnum"; $result =mysql_query ( $query) ; li perform the search query mysql_close ( "UEP_08 . SQL" ) ; li close database access ?> Em resposta, o banco de dados de comerciante/adquirente pode proporcionar o endereço de gateway de pagamento solicitado, por exemplo, 5718. O servidor de comerciante pode encaminhar o pedido de autorização de cartão para o servidor de gateway de pagamento usando o endereço proporcionado, por exemplo, 5719. Em algumas modalidades, mediante o recebimento do pedido de autorização de cartão a partir do servidor de comerciante, o servidor de gateway de pagamento pode invocar um componente a proporcionar um ou mais serviços associados à autorização de transação de compra. Por exemplo, o servidor de gateway de pagamento pode invocar um componente para prevenção de fraude, fidelidade e/ou premiações, e/ou outros serviços para os quais a combinação de usuário-comerciante é autorizada. O servidor de gateway de pagamento pode encaminhar o pedido de autorização de cartão para um servidor de rede de pagamento, por exemplo, 5705a, para processamento de pagamento. Por exemplo, o servidor de gateway de pagamento pode ser capaz de selecionar a partir de redes de pagamento, tais como, Visa, Mastercard, American Express, Paypal, etc., para processar diversos tipos de transações que incluem, porém, sem caráter limitativo: cartão de crédito, cartão de débito, cartão pré-pago, 828 e/ou transações similares. Em algumas modalidades, o servidor de gateway de pagamento pode consultar um banco de dados, por exemplo, banco de dados de gateway de pagamento 5704b, para um endereço de rede do servidor de rede de pagamento, por exemplo, usando-se uma parte de um número de cartão de pagamento de usuário, ou um ID de usuário (tal como, um endereço de email) como uma palavra-chave para a consulta de banco de dados. Por exemplo, o servidor de gateway de pagamento pode emitir comandos PHP/SQL para consultar uma tabela de banco de dados (tal como, a Figura 61, Gateways de Pagamento 611911) para um URL do servidor de rede de pagamento. Uma consulta de endereço de rede de pagamento exemplificativa 5721, substancialmente na forma de comandos PHP/SQL, é proporcionada abaixo: <?PHP header ('Content-Type: text/plain'); 5 mysql_connect (" 254. 93. 179. 112 ", $DBserver, $password); li access database server mysql_select_db ( "UEP_DB . SQL" ) ; li select database table to search llcreate query $query = "SELECT payNET_id payNET_address payNET_URL payNET_name
FROM PayGatewayTable WHERE card_num LIKE'%'$cardnum"; $result = mysql_query ( $query) ; li perform the search query mysql_close ( "UEP_DB. SQL"); li close database access ?> Em resposta, o banco de dados de gateway de pagamento pode proporcionar o endereço de rede de pagamento solicitado, por exemplo, 5722. O servidor de gateway de pagamento pode encaminhar o pedido de autorização de cartão para o servidor de rede de pagamento usando o endereço proporcionado, por exemplo, 5723. Com referência à Figura 578, em algumas modalidades, o servidor de rede de pagamento pode processar a transação, a fim de transferir fundos para a compra em uma conta armazenada em um adquirente do comerciante. Por exemplo, o adquirente pode ser uma instituição financeira que mantém uma conta do comerciante. Por exemplo, os rendimentos de transações processadas pelo comerciante podem ser depositados em uma conta mantida em um servidor do adquirente. Em algumas modalidades, o servidor de rede de pagamento pode gerar uma consulta, por exemplo, 5724, para o servidor emissor que corresponde às opções de pagamento selecionadas pelo usuário. Por exemplo, a conta do usuário pode ser vinculada a uma ou mais instituições financeiras emissoras ("emissoras"), tais como, instituições bancárias, que emitiram a conta para o usuário. Por exemplo, tais contas podem incluir, porém, sem caráter limitativo: cartão de crédito, cartão de débito, cartão pré-pago, conta corrente, poupança, mercado monetário, certificados de depósito, contas de valor armazenadas (em dinheiro), e/ou similares. O servidor emissor, por exemplo, 5706a, dos emissores pode manter os detalhes da conta do usuário. Em algumas modalidades, um banco de dados, por exemplo, banco de dados de rede de pagamento 5705b, pode armazenar detalhes do servidor emissor associado ao emissor. Em algumas modalidades, o servidor de rede de pagamento pode consultar um banco de dados, por exemplo, banco de dados de rede de pagamento 5705b, para um endereço de rede do servidor emissor, por exemplo, usando-se uma parte um número de cartão de pagamento de usuário, ou um ID de usuário (tal como, um endereço de email) como uma palavra-chave para a consulta de banco de dados.
Por exemplo, o servidor de comerciante pode emitir comandos PHP/SQL para consultar uma tabela de banco de dados (tal como, a Figura 61, emissores 61191) para 5 o endereço de rede do servidor emissor.
Uma consulta de endereço de servidor emissor exemplificativa 5724, substancialmente na forma de comandos PHP/SQL, é proporcionada abaixo: <?PHP header ('Content-Type: text/plain'); mysql_connect ("254.93.179.112", $DBserver, $password) // access database server mysql_select_db ( "UEP_DB . SQL" ) ; li select database table to search //create query $query ="SELECT issuer_id issuer_address issuer_URL issuer_name FROM lssuersTable WHERE card_num LIKE'%'$cardnum"; $result =mysql_query ( $query) ; li perform the search query mysql_close ( "UEP_DB . SQL" ) ; li close database access ?> Em resposta à obtenção da consulta do servidor emissor, por exemplo, 5724, o banco de dados de rede de pagamento pode proporcionar, por exemplo, 5725, os dados de emissor servidor solicitados para o servidor de rede de pagamento.
Em algumas modalidades, o servidor de rede de pagamento pode utilizar os dados de servidor emissor para gerar solicitação de autorização de fundos, por exemplo, 5726, para cada um dos servidores emissores selecionados com base nas configurações de pagamento pré- definidas associadas à carteira virtual do usuário, e/ou à entrada de opções de pagamento do usuário, e proporcionar a solicitação de autorização de fundos para o servidor emissor.
Em algumas modalidades, a solicitação de autorização de fundos pode incluir detalhes, tais como, porém, sem caráter limitativo: os custos para o usuário envolvido na transação, detalhes de conta de cartão do usuário, informações de cobrança de usuário e/ou de entrega, e/ou similares.
Uma listagem exemplificativa de uma solicitação de autorização de fundos 5726, substancialmente na forma de uma mensagem HT P(S) POST que inclui dados formatados XML, é proporcionada abaixo: POST /fundsauthorizationrequest .php HTTP/ 1 . 1 Host: www.issuer.com Content-Type: Application/XML Content-Length: 624 <?XML version =" 1.0 "encoding ="UTF- 8 " ? >
<funds_authorization_request> <query_ID>VNEI 39 FK</query_ID> <timestamp>2 01 1 - 02 -22 15: 22: 44</timestamp> <transaction_cost> $22.61 </ transaction_cost> 5 <account_params> <account_type>checking</account_type> <account_num>123456789012345 6< /account_num> </account_params> <!--opcional parameters-> <purchase_summary> <num_products>l</num_products> <product> <product_summary>Book - XML for dummies</product_summary> <product_quantity>K/product_quantity? </product> </purchase_summary> <merchant_params> <merchant_id>3FBCR41NC</merchant_id> <merchant_name>Books & Things, lnc . </merchant_name> <merchant_auth_key>INNF484MCP59CHB27365</merchant_auth_key> </merchant_params> </funds_authorization_request> Em algumas modalidades, um servidor emissor pode analisar a solicitação de autorização, e com base nos detalhes solicitados pode consultar um banco de dados, por exemplo, banco de dados de perfil de usuário 5706b, para dados associados a uma conta vinculada ao usuário.
Por exemplo, o servidor de comerciante pode emitir comandos PHP/SQL para consultar uma tabela de banco de dados (tal como, a Figura 61, Contas 6119d) para dados de conta de usuário.
Uma consulta de conta de usuário exemplificativa 5727, substancialmente na forma de comandos PHP/SQL, é proporcionada abaixo: <?PHP header ('Content-Type: text/plain'); mysql_connect ("254.93.179.112", $DBserver, $password) li access database server mysql_select_db ( "UEP_DB . SQL" ) ; li select database table to search llcreate query $query ="SELECT issuer user_id user_name user_balance account_type FROM AccountsTable WHERE account_num LIKE'%'$accountnum";
$result = mysql_query ( $query) ; li perform the search query mysql_close ( "UEP_DB . SQL") ; li close database access ?> Em algumas modalidades, ao obter os dados de conta de usuário, por exemplo, 5 5728, o servidor emissor pode determinar se o usuário pode pagar a transação usando fundos disponíveis na conta, 5729. Por exemplo, o servidor emissor pode determinar se o usuário tem um saldo suficiente remanescente na conta, crédito suficiente associado à conta, e/ou similares.
Com base na determinação, o servidor emissor pode proporcionar uma resposta de autorização de fundos, por exemplo, 5730, para o servidor de rede de 1O pagamento.
Por exemplo, o servidor emissor pode proporcionar uma mensagem HTTP(S) POST similar aos exemplos acima.
Em algumas modalidades, se pelo menos um servidor emissor determinar que o usuário não pode pagar a transação usando os fundos disponíveis na conta, o servidor de rede de pagamento pode solicitar as opções de pagamento novamente a partir do usuário (por exemplo, proporcionando-se uma mensagem de falha de autorização para o dispositivo de usuário e solicitando-se que o dispositivo de usuário proporcione novas opções de pagamento), e tentando novamente a autorização para a transação de compra.
Em algumas modalidades, se o número de tentativas de autorização falhadas exceder um limite, o servidor de rede de pagamento pode abortar o processo de autorização, e proporcionar uma mensagem de "falha de autorização" para o servidor de comerciante, dispositivo de usuário e/ou cliente.
Em algumas modalidades, o servidor de rede de pagamento pode obter a resposta de autorização de fundos que inclui uma notificação de autorização bem sucedida, e analisar a mensagem para extrair os detalhes de autorização.
Mediante a determinação que o usuário possui fundos suficientes para a transação, por exemplo, 5731, o servidor de rede de pagamento pode invocar um componente a proporcionar serviços de valor agregado para o usuário.
Em algumas modalidades, o servidor de rede de pagamento pode gerar um registro de dados de transação a partir da solicitação de autorização e/ou resposta de autorização, e armazenar os detalhes da transação e da autorização que se refere à transação em um banco de dados de transações.
Por exemplo, o servidor de rede de pagamento pode emitir comandos PHP/SQL para armazenar os dados em uma tabela de banco de dados (tal como, a Figura 61, Transações 61191 ). Um comando de armazenamento de transação exemplificativo, substancialmente na forma de comandos PHP/SQL, é proporcionado abaixo: <?PHP header ('Content-Type: text/plain');
mysql_connect ( "254.92.185.1 03 ", $DBserver, $password) ; li access database server mysql_select ( "UEP_DB . SQL" ) ; li select database to append mysql_query (" INSERT INTO TransactionsTable (PurchasesTable (timestamp, 5 purchase_summary_list, num_products, product_summary, product_quantity, transaction_cost, account_params_list, account_name, account_type, account_num, billing_addres, zipcode, phone, sign, merchant_params_list, merchant_id, merchant_name, merchant_auth_key) VALUES (time(), $purchase_summary_list, $num_products, $product_summary, $product_quantity, $transaction_cost, $account_params_list, $account_name, $account_type, $account_num, $billing_addres, $zipcode, $phone, $sign, $merchant_params_list, $merchant_id, $merchant_name, $merchant_auth_key)"); li add data to table in database mysql_close ( "UEP _DB . SQL" ) ; li close connection to database ?> Em algumas modalidades, o servidor de rede de pagamento pode encaminhar uma resposta de autorização de transação, por exemplo, 5732, para o dispositivo de carteira de usuário, cliente PoS e/ou servidor de comerciante.
O comerciante pode obter a resposta de autorização de transação, e determinar a partir da mesma que o usuário possui fundos suficientes na conta de cartão para conduzir a transação.
O servidor de comerciante pode adicionar um registro da transação para o usuário em um lote de dados de transação que se refere às transações autorizadas.
Por exemplo, o comerciante pode anexar os dados XML relacionados à transação de usuário em um arquivo de dados XML que compreende dados XML para transações que foram autorizadas para diversos usuários, por exemplo, 5733, e armazenar o arquivo de dados XML, por exemplo, 5734, em um banco de dados, por exemplo, banco de dados de estabelecimento 404. Por exemplo, um arquivo de dados XML em lote pode ser estruturado de maneira similar ao modelo de estrutura de dados XML exemplificativo proporcionado abaixo: <?XML version = "1.0" encoding = "UTF-8"?> <merchant_data> <merchant_id>3FBCR41NC</merchant_id> <merchant_name>Books & Things, lnc. </merchant_name> <merchant_auth_key>INNF484MCP59CHB27365</merchant_auth_key> <account_number>12345678 9< /account_number> </merchant data> <transaction_data> <transaction 1 >
</ transaction 1 > <transaction 2>
5 </ transaction 2>
<transaction n>
</ transaction n> </transaction_data> Em algumas modalidades, o servidor também pode gerar um recibo de compra, por exemplo, 5733, e proporcionar o recibo de compra para o cliente, por exemplo, 5735. O cliente pode renderizar e exibir, por exemplo, 5736, o recibo de compra para o usuário.
Em algumas modalidades, o dispositivo de carteira do usuário também pode proporcionar uma notificação de autorização bem sucedida para o usuário.
Por exemplo, o cliente PoS/dispositivo de usuário pode renderizar uma página da web, mensagem eletrônica, mensagem de texto/SMS, armazenar em buffer uma mensagem de voz, emitir um tom de chamada, e/ou reproduzir uma mensagem de áudio, etc., e proporcionar saída incluindo, porém, sem caráter limitativo: sons, música, áudio, vídeo, imagens, realimentação tátil, alertas vibratórios (por exemplo, dispositivos de cliente capazes de vibração, tal como, um smartphone, etc.), e/ou similares.
As Figuras 58A-B mostram diagramas de fluxo lógico que ilustram os aspectos exemplificativos da autorização de transação de compra em algumas modalidades do UEP, por exemplo, um componente de Autorização de Transação de Compra ("PTA") 5800. Com referência à Figura 58A, em algumas modalidades, um usuário pode desejar utilizar uma conta de carteira virtual para adquirir um produto, serviço, oferta, e/ou similares, ("produto"), a partir de um comerciante através de um site online do comerciante ou na loja do comerciante.
O usuário pode utilizar a cartão físico, ou um dispositivo de carteira de usuário para acessar uma conta de carteira virtual do usuário.
Por exemplo, o dispositivo de carteira de usuário pode ser um computador pessoal/laptop, telefone celular, smartphone, tablet, leitor de eBook, netbook, console de jogo, e/ou similares.
O usuário pode proporcionar uma entrada de acesso de carteira, por exemplo, 5801, para o dispositivo de carteira de usuário.
Em diversas modalidades, a entrada de usuário pode incluir, porém, sem caráter limitativo: um toque único (por exemplo, uma modalidade de aquisição de app móvel em um toque) de uma interface sensível ao toque, entrada de teclado, cartão magnético, que ativa um dispositivo de hardware habilitado para RFID/NFC (por exemplo, cartão eletrônico que tem múltiplas contas, smartphone, tablet, etc.) dentro do dispositivo de usuário, cliques do mouse, pressionamento de botões em um joystick/console de jogo, comandos de voz, gestos de toque único/multitoque em uma interface sensível ao toque, toque de elementos 5 de interface de usuário em uma tela sensível ao toque, e/ou similares.
Em algumas modalidades, o dispositivo de carteira de usuário pode autenticar o usuário com base na entrada de acesso de carteira do usuário, e proporcionar recursos de carteira virtual para o usuário, por exemplo, 5802-5803. Em algumas modalidades, mediante a autenticação do usuário para acessar os 1O recursos carteira virtual, o dispositivo de carteira de usuário pode proporcionar uma entrada de autorização de transação, por exemplo, 5804, para um cliente de ponto de venda ("PoS"). Por exemplo, o dispositivo de carteira de usuário pode se comunicar com o cliente PoS através de Bluetooth, Wi-Fi, comunicação celular comunicação de campo próximo unidirecional ou bidirecional ("NFC"), e/ou similares.
Nas modalidades em que o usuário utiliza um cartão de plástico em vez do dispositivo de carteira de usuário, o usuário pode passar o cartão de plástico no cliente PoS para transferir informações a partir do cartão de plástico para o cliente PoS.
Nas modalidades em que o usuário utiliza um dispositivo de carteira de usuário, o dispositivo de carteira de usuário pode proporcionar informações de pagamento para o cliente PoS, formatadas de acordo com um protocolo de formatação de dados apropriado para o mecanismo de comunicação empregado na comunicação entre o dispositivo de carteira de usuário e o cliente PoS. 1 Em algumas modalidades, o cliente PoS pode obter a entrada de autorização de transação, e analisar a entrada para extrair informações de pagamento da entrada de autorização de transação, por exemplo, 5805. Por exemplo, o cliente PoS pode utilizar um analisador, tal como, os analisadores exemplificativos proporcionados abaixo na discussão com referência à Figura 61. O cliente PoS pode gerar um pedido de autorização de cartão, por exemplo, 5806, usando uma entrada de autorização de transação obtida a partir do dispositivo de carteira de usuário, e/ou dados de produto/finalização de compra(vide, por exemplo, Figura 55, 5515-5517). Em algumas modalidades, o cliente PoS pode proporcionar o pedido de autorização de cartão gerado para o servidor de comerciante.
O servidor de comerciante pode encaminhar o pedido de autorização de cartão para um servidor de gateway de pagamento, para rotear o pedido de autorização de cartão até a rede de pagamento apropriada para o processamento de pagamento.
Por exemplo, o servidor de gateway de pagamento pode ser capaz de selecionar a partir de redes de pagamento, tais como, Visa, Mastercard, American Express, Paypal, etc., para processar diversos tipos de transações que incluem, porém, sem caráter limitativo: cartão de crédito, cartão de débito, cartão pré-pago, 828 e/ou transações similares. Em algumas modalidades, o servidor de comerciante pode consultar um banco de dados, por exemplo, 5808, para um endereço de rede do servidor de gateway de pagamento, por exemplo, usando-se uma parte de um número de cartão de pagamento de usuário, ou um ID de usuário (tal como, um endereço de email) como uma palavra-chave para a consulta de banco de dados. Em resposta, o banco de dados de comerciante/adquirente pode proporcionar o endereço de gateway de pagamento solicitado, por exemplo, 581 O. O servidor de comerciante pode encaminhar o pedido de autorização de cartão para o servidor de gateway de pagamento usando o endereço proporcionado. Em algumas modalidades, mediante o recebimento do pedido de autorização de cartão a partir 1O do servidor de comerciante, o servidor de gateway de pagamento pode invocar um componente a proporcionar um ou mais serviços associados à autorização de transação de compra, por exemplo, 5811. Por exemplo, o servidor de gateway de pagamento pode invocar um componente para prevenção de fraude, fidelidade e/ou premiações, e/ou outros serviços para os quais a combinação de usuário-comerciante é autorizada. O servidor de gateway de pagamento pode encaminhar o pedido de autorização de cartão para um servidor de rede de pagamento para processamento de pagamento, por exemplo, 5814. Por exemplo, o servidor de gateway de pagamento pode ser capaz de selecionar a partir de redes de pagamento, tais como, Visa, Mastercard, American Express, Paypal, etc., para processar diversos tipos de transações que incluem, porém, sem caráter limitativo: cartão de crédito, cartão de débito, cartão pré-pago, 828 e/ou transações similares. Em algumas modalidades, o servidor de gateway de pagamento pode consultar um banco de dados, por exemplo, 5812, para um endereço de rede do servidor de rede de pagamento, por exemplo, usando-se uma parte de um número de cartão de pagamento de usuário, ou um ID de usuário (tal como, um endereço de email) como uma palavra-chave para a consulta de banco de dados. Em resposta, o banco de dados de gateway de pagamento pode proporcionar o endereço de rede de pagamento solicitado, por exemplo,
5813. O servidor de gateway de pagamento pode encaminhar o pedido de autorização de cartão para o servidor de rede de pagamento usando o endereço proporcionado, por exemplo, 5814. Com referência à Figura 588, em algumas modalidades, o servidor de rede de pagamento pode processar a transação, a fim de transferir fundos para a compra em uma conta armazenada em um adquirente do comerciante. Por exemplo, o adquirente pode ser uma instituição financeira que mantém uma conta do comerciante. Por exemplo, os rendimentos de transações processadas pelo comerciante podem ser depositados em uma conta mantida em um servidor do adquirente. Em algumas modalidades, o servidor de rede de pagamento pode gerar uma consulta, por exemplo, 5815, para o servidor emissor que corresponde às opções de pagamento selecionadas pelo usuário. Por exemplo, a conta do usuário pode ser vinculada a uma ou mais instituições financeiras emissoras ("emissoras"), tais como, instituições bancárias, que emitiram a conta para o usuário.
Por exemplo, tais contas podem incluir, porém, não se limitam a: cartão de crédito, cartão de débito, cartão pré-pago, conta corrente, poupança, mercado monetário, certificados de depósito, contas de 5 valor armazenadas (em dinheiro), e/ou similares.
O servidor emissor do emissor pode manter os detalhes da conta do usuário.
Em algumas modalidades, um banco de dados, por exemplo, um banco de dados de rede de pagamento, pode armazenar detalhes do servidor emissor associado ao emissor.
Em algumas modalidades, o servidor de rede de pagamento pode consultar um banco de dados, por exemplo, 5815, para um endereço de rede do 1O servidor emissor, por exemplo, usando-se uma parte de um número de cartão de pagamento de usuário, ou um ID de usuário (tal como, um endereço de email) como uma palavra-chave para a consulta de banco de dados.
Em resposta à obtenção da consulta do servidor emissor, o banco de dados de rede de pagamento pode proporcionar, por exemplo, 5816, os dados de emissor servidor solicitados para o servidor de rede de pagamento.
Em algumas modalidades, o servidor de rede de pagamento pode utilizar os dados de servidor emissor para gerar a solicitação de autorização de fundos, por exemplo, 5817, para cada um dos servidores emissores selecionados com base nas configurações de pagamento pré-definidas associadas à carteira virtual do usuário, e/ou à entrada de opções de pagamento do usuário, e proporcionar a solicitação de autorização de fundos para o servidor emissor.
Em algumas modalidades, a solicitação de autorização de fundos pode incluir detalhes, tais como, porém, sem caráter limitativo: os custos para o usuário envolvido na transação, detalhes de conta de cartão do usuário, cobrança de usuário e/ou informações de entrega, e/ou similares.
Em algumas modalidades, um servidor emissor pode analisar a solicitação de autorização, por exemplo, 5818, e com base nos detalhes solicitados pode consultar um banco de dados, por exemplo, 5819, para dados associados a uma conta vinculada ao usuário.
Em algumas modalidades, mediante a obtenção dos dados de conta de usuário, por exemplo, 5820, o servidor emissor pode determinar se o usuário pode pagar a transação usando os fundos disponíveis na conta, por exemplo, 5821. Por exemplo, o servidor emissor pode determinar se o usuário tem um saldo suficiente remanescente na conta, crédito suficiente associado à conta, e/ou similares.
Com base na determinação, o servidor emissor pode proporcionar uma resposta de autorização de fundos, por exemplo, 5822, para o servidor de rede de pagamento.
Em algumas modalidades, se pelo menos um servidor emissor determinar que o usuário não pode pagar a transação usando os fundos disponíveis na conta, o servidor de rede de pagamento pode solicitar as opções de pagamento novamente a partir do usuário (por exemplo, proporcionando-se uma mensagem de falha de autorização para o dispositivo de usuário e solicitando-se que o dispositivo de usuário proporcione novas opções de pagamento), e tentando novamente a autorização para a transação de compra.
Em algumas modalidades, se o número de tentativas de autorização falhadas exceder um limite, o servidor de rede de pagamento pode abortar o processo de autorização, e proporcionar uma mensagem de "falha de autorização" para o servidor de 5 comerciante, dispositivo de usuário e/ou cliente.
Em algumas modalidades, o servidor de rede de pagamento pode obter a resposta de autorização de fundos que inclui uma notificação de autorização bem sucedida, e analisar a mensagem para extrair os detalhes de autorização.
Mediante a determinação que o usuário possui fundos suficientes para a transação, por exemplo, 5823, o servidor de rede 1O de pagamento pode invocar um componente para proporcionar serviços de valor agregado para o usuário, por exemplo, 5823. Em algumas modalidades, o servidor de rede de pagamento pode encaminhar uma resposta de autorização de transação para o dispositivo de carteira de usuário, cliente PoS e/ou servidor de comerciante.
O comerciante pode analisar, por exemplo, 5824, a resposta de autorização de transação, e determinar a partir da mesma que o usuário possui fundos suficientes na conta de cartão para conduzir uma transação, por exemplo, 5825, opção "Sim". O servidor de comerciante pode adicionar um registro da transação para o usuário em um lote de dados de transação que se refere às transações autorizadas.
Por exemplo, pode anexar os dados XML relacionados à transação de usuário em um arquivo de dados XML que compreende dados XML para transações que foram autorizadas para diversos usuários, por exemplo, 5826, e armazenar o arquivo de dados XML, por exemplo, 5827, em um banco de dados.
Em algumas modalidades, o servidor também pode gerar um recibo de compra, por exemplo, 5828, e proporcionar o recibo de compra para o cliente.
O cliente pode renderizar e exibir, por exemplo, 5829, o recibo de compra para o usuário.
Em algumas modalidades, o dispositivo de carteira do usuário também pode proporcionar uma notificação de autorização bem sucedida para o usuário.
Por exemplo, o cliente PoS/dispositivo de usuário pode renderizar uma página da web, mensagem eletrônica, mensagem de texto/SMS, armazenar em buffer uma mensagem de voz, emitir um tom de chamada, e/ou reproduzir uma mensagem de áudio, etc., e proporcionar saída incluindo, porém, sem caráter limitativo: sons, música, áudio, vídeo, imagens.O realimentação tátil, alertas vibratórios (por exemplo, dispositivos de cliente capazes de vibração, tal como, um smartphone, etc.), e/ou similares.
As Figuras 59A-B mostram diagramas de fluxo de dados que ilustram um procedimento de autorização de transação de compra exemplificativo, em algumas modalidades do UEP.
Com referência à Figura 59A, em algumas modalidades, um servidor de comerciante, por exemplo, 5903a, pode iniciar a autorização de um lote de transações autorizadas.
Por exemplo, o servidor de comerciante pode gerar uma solicitação de dados em lote, por exemplo, 5911, e proporcionar a solicitação para um banco de dados de estabelecimento, por exemplo, 5903b.
Por exemplo, o servidor de comerciante pode utilizar comandos PHP/SQL similares aos exemplos proporcionados acima para consultar um banco de dados relacional.
Em resposta à solicitação de dados em lote, o banco de dados pode proporcionar os dados em lote solicitados, por exemplo, 5912. O servidor pode gerar uma solicitação de autorização em lote, por exemplo, 5913, usando os dados em lote obtidos a partir do banco de dados, e proporcionar, por exemplo, 5914, a solicitação de autorização em lote para um servidor adquirente, por exemplo, 5907a.
Por exemplo, o servidor de comerciante pode proporcionar uma mensagem HTTP(S) POST que inclui 1O dados XML formatados em lote no corpo de mensagem para o servidor adquirente.
O servidor adquirente pode gerar, por exemplo, 5915, uma solicitação de pagamento em lote usando a solicitação de autorização em lote obtida, e proporcionar, por exemplo, 5918, a solicitação de pagamento em lote para o servidor de rede de pagamento, por exemplo, 5905a.
O servidor de rede de pagamento pode analisar a solicitação de pagamento em lote, e extrair os dados de transação para cada transação armazenada na solicitação de pagamento em lote, por exemplo, 5919. O servidor de rede de pagamento pode armazenar os dados de transação, por exemplo, 5920, para cada transação em um banco de dados, por exemplo, banco de dados de rede de pagamento 5905b.
Em algumas modalidades, o servidor de rede de pagamento pode invocar um componente a proporcionar serviços analíticos de valor agregado com base na análise das transações do comerciante para quem o UEP está autorizando as transações de compra.
Deste modo, em algumas modalidades, o servidor de rede de pagamento pode proporcionar serviços analíticos baseados em valor agregado para o comerciante e/ou os usuários do estabelecimento.
Com referência à Figura 598, em algumas modalidades, para cada transação extraída, o servidor de rede de pagamento pode consultar, por exemplo, 5923, um banco de dados, por exemplo, banco de dados de rede de pagamento 5905b, para um endereço de um servidor emissor.
Por exemplo, o servidor de rede de pagamento pode utilizar comandos PHP/SQL similares aos exemplos proporcionados acima.
O servidor de rede de pagamento pode gerar uma solicitação de pagamento individual, por exemplo, 5925, para cada transação para a qual se extraiu os dados de transação, e proporcionar a solicitação de pagamento individual, por exemplo, 5925, para o servidor emissor, por exemplo, 5906a.
Por exemplo, o servidor de rede de pagamento pode proporcionar uma solicitação de pagamento individual para o servidor emissor como a mensagem HTTP(S) POST que inclui os dados formatados XML.
Uma listagem exemplificativa de uma solicitação de pagamento individual 5925, substancialmente na forma de uma mensagem HTTP(S) POST que inclui dados formatados XML, é proporcionada abaixo:
POST /paymentrequest.php HTTP/1.1 Host: www.issuer.com Content-Type: Application/XML Content-Length: 788 <?XML version ="1.0" encoding ="UTF-8"?> < pay_req uest> <request_ID>CNl41CNW2</request_ID> <timestamp>2011-02-22 17: 00: 01 </timestamp> <pay_amount>$34. 78</pay_amount> <account_params> <account_name>John Q.
Public</account_name> <account_type>cred it</accou nt_type> <account_num> 123456789012345</account_num> <billing_address>123 Green St., Norman, OK 98765</billing_address> <phone>123-456-7809</phone> <sign>/jqp/</sign> </account_params> <merchant_params> <merchant_id>3FBCR41NC</merchant_id> <merchant_name>Books & Things, lnc . </merchant_name> <merchant_auth_key>INNF484MCP59CHB27365</merchant_auth_key> </merchant_params> <purchase_summary> <num_products>l</num_products> <product> <product_summary>Book - XML for dummies</product_summary> <product_quantity>K/product_quantity? </product> </purchase_summary> </pay_request> Em algumas modalidades, o servidor emissor pode gerar um comando de pagamento, por exemplo, 5927. Por exemplo, o servidor emissor pode emitir um comando para deduzir fundos da conta do usuário (ou adicionar uma cobrança à conta de cartão de crédito do usuário). O servidor emissor pode emitir um comando de pagamento, por exemplo, 5927, para um banco de dados que armazena as informações de conta do usuário, por exemplo, banco de dados de perfil de usuário 5906b.
O servidor emissor pode proporcionar uma confirmação de pagamento individual, por exemplo, 5928, para o servidor de rede de pagamento, que pode encaminhar, por exemplo, 5929, a mensagem de transferência de fundos para o servidor adquirente.
Uma listagem exemplificativa de uma confirmação de pagamento individual 5928, substancialmente na forma de uma mensagem HTTP(S) POST que inclui dados formatados XML, é proporcionada abaixo: 5 POST /clearance .php HTTP/1.1 Host: www.acquirer.com Content-Type: Application/XML Content-Length: 206 <?XML version ="1.0" encoding ="UTF-8"?> <deposit_ack> <request_ID>CNl41CNW2</request_ID> <clear_flag>true</clear_flag> <timestamp>2011-02-22 17: 00: 02</timestamp> <deposit_amount>$34. 78</deposit_amount> </deposit_ack> Em algumas modalidades, o servidor adquirente pode analisar a confirmação de pagamento individual, e correlacionar a transação (por exemplo, usando o campo request_ID no exemplo acima) ao comerciante.
O servidor adquirente pode, então, transferir os fundos especificados na mensagem de transferência de fundos para uma conta do comerciante.
Por exemplo, o servidor adquirente pode consultar, por exemplo, 5930, um banco de dados adquirente 5907b para dados de razão de pagamento e/ou conta de comerciante, por exemplo, 5931. O servidor adquirente pode utilizar dados de razão de pagamento e/ou conta de comerciante a partir do banco de dados adquirente, junto com a confirmação de pagamento individual, para gerar dados de razão de pagamento e/ou conta de comerciante atualizados, por exemplo, 5932. O servidor adquirente pode, então, armazenar, por exemplo, 5933, os dados de razão de pagamento e/ou conta de comerciante atualizados no banco de dados adquirente.
As Figuras 60A-B mostram diagramas de fluxo lógico que ilustram os aspectos exemplificativos de autorização de transação de compra em algumas modalidades do UEP, por exemplo, um componente de Autorização de Transação de Compra ("PTC") 6000. Com referência à Figura 60A, em algumas modalidades, um servidor de comerciante pode iniciar a autorização de um lote de transações autorizadas.
Por exemplo, o servidor de comerciante pode gerar uma solicitação de dados em lote, por exemplo, 6001, e proporcionar uma solicitação para um banco de dados de estabelecimento.
Em resposta à solicitação de dados em lote, o banco de dados pode proporcionar os dados em lote solicitados, por exemplo, 6002. O servidor pode gerar uma solicitação de autorização em lote, por exemplo, 6003, usando os dados em lote obtidos a partir do banco de dados, e proporcionar a solicitação de autorização em lote para um servidor adquirente.
O servidor adquirente pode analisar, por exemplo, 6004, a solicitação de autorização em lote obtida, e gerar, por exemplo, 6007, uma solicitação de pagamento em lote usando uma solicitação de autorização em lote obtida para proporcionar a solicitação de pagamento em lote para um servidor de rede de pagamento.
Por exemplo, o servidor adquirente pode consultar, por exemplo, 6005, um banco de dados adquirente para um endereço de um servidor de rede de pagamento, e utilizar o endereço obtido, por exemplo, 6006, para encaminhar a solicitação de pagamento em lote gerada para o servidor de rede de pagamento.
O servidor de rede de pagamento pode analisar a solicitação de pagamento em lote 1O obtido a partir do servidor adquirente, e extrair os dados de transação para cada transação armazenada na solicitação de pagamento em lote, por exemplo, 6008. O servidor de rede de pagamento pode armazenar os dados de transação, por exemplo, 6009, para cada transação em um banco de dados de rede de pagamento.
Em algumas modalidades, o servidor de rede de pagamento pode invocar um componente, por exemplo, 601 O, a proporcionar serviços analíticos com base nas transações do comerciante para quem a transação de compra está sendo autorizada.
Com referência à Figura 608, em algumas modalidades, para cada transação extraída, o servidor de rede de pagamento pode consultar, por exemplo, 6011, um banco de dados de rede de pagamento para um endereço de um servidor emissor.
O servidor de rede de pagamento pode gerar uma solicitação de pagamento individual, por exemplo, 6013, para cada transação para a qual se extraiu os dados de transação, e proporcionar a solicitação de pagamento individual para o servidor emissor.
Em algumas modalidades, o servidor emissor pode analisar a solicitação de pagamento individual, por exemplo, 6014, e gerar um comando de pagamento, por exemplo, 6015, com base na solicitação de pagamento individual analisada.
Por exemplo, o servidor emissor pode emitir um comando para deduzir fundos da conta do usuário (ou adicionar uma cobrança à conta de cartão de crédito do usuário). O servidor emissor pode emitir um comando de pagamento, por exemplo, 6015, para um banco de dados que armazena as informações de conta do usuário, por exemplo, um banco de dados de perfil de usuário.
O servidor emissor pode proporcionar uma confirmação de pagamento individual, por exemplo, 6017, para o servidor de rede de pagamento, que pode encaminhar, por exemplo, 6018, a confirmação de pagamento individual para o servidor adquirente.
Em algumas modalidades, o servidor adquirente pode analisar a confirmação de pagamento individual, e correlacionar a transação (por exemplo, usando o campo request_ID no exemplo acima) ao comerciante.
O servidor adquirente pode, então, transferir os fundos especificados na mensagem de transferência de fundos para uma conta do comerciante.
Por exemplo, o servidor adquirente pode consultar, por exemplo, 6019, um banco de dados adquirente para dados de razão de pagamento e/ou conta de comerciante, por exemplo, 6020. O servidor adquirente pode utilizar dados de razão de pagamento e/ou conta de comerciante a partir do banco de dados adquirente, junto com a confirmação de pagamento individual, para gerar dados de razão de pagamento e/ou conta de comerciante 5 atualizados, por exemplo, 6021. O servidor adquirente pode, então, armazenar, por exemplo, 6022, o dados de razão de pagamento e/ou conta de comerciante atualizados no banco de dados adquirente.
Controlador UEP A Figura 61 mostra um diagrama de bloco que ilustra as modalidades de um 1O controlador UEP 6101. Nesta modalidade, o controlador UEP 6101 pode servir para agregar, processar, armazenar, pesquisar, servir, identificar, instruir, gerar, combinar e/ou facilitar as interações com um computador através de diversas tecnologias e/ou outros dados relacionados.
De maneira típica, os usuários, por exemplo, 6133a, que podem ser pessoas e/ou outros sistemas, podem envolver sistemas de tecnologia da informação (por exemplo, computadores) para facilitar o processamento de informações.
Por sua vez, os computadores empregam processadores para processar informações; tais como, os processadores 6103 podem ser referidos como unidades de processamento central (CPU). Uma forma de processador é referida como um microprocessador.
As CPUs usam circuitos comunicativos para passar sinais codificados binários que atuam como instruções para permitir diversas operações.
Estas instruções podem ser instruções operacionais e/ou de dados que contêm e/ou se referem a outras instruções e dados em diversas áreas acessíveis e operáveis por processador da memória 6129 (por exemplo, registros, memória cache , memória de acesso aleatório, etc.). Tais instruções comunicativas podem ser armazenadas e/ou transmitidas em lotes (por exemplo, lotes de instruções) como programas e/ou componentes de dados para facilitar as operações desejadas.
Estes códigos de instrução armazenados, por exemplo, programas, podem envolver os componentes de circuito de CPU e outros componentes de placa-mãe e/ou sistema para realizar as operações desejadas.
Um tipo de programa é um sistema de operação de computador, que pode ser executado pela CPU em um computador; o sistema de operação permite e facilita que os usuários acessem e operem a tecnologia e os recursos de informações de computador.
Alguns recursos que podem ser empregados nos sistemas de tecnologia da informação incluem: mecanismos de entrada e saída através dos quais os dados podem passar para dentro e para fora de um computador; armazenamento de memória na qual os dados podem ser salvos; e processadores através dos quais as informações podem ser processadas.
Estes sistemas de tecnologia da informação podem ser usados para coletar dados para posterior recuperação, análise e manipulação, o que pode ser facilitado através de um programa de banco de dados.
Estes sistemas de tecnologia da informação proporcionam interfaces que permitem que os usuários acessem e operem diversos componentes de sistema.
Em uma modalidade, o controlador UEP 6101 pode ser conectado a e/ou se 5 comunicar com entidades, tais como, porém, sem caráter limitativo: um ou mais more usuários de dispositivos de entrada de usuário 6111; dispositivos periféricos 6112; um dispositivo processador criptográfico opcional 6128; e/ou uma rede de comunicações 6113. Por exemplo, o controlador UEP 6101 pode ser conectado a e/ou se comunicar com usuários, por exemplo, 6133a, operar o dispositivo de cliente, por exemplo, 6133b, incluindo, 1O porém, sem caráter limitativo, computador pessoal, servidor e/ou diversos dispositivos móveis incluindo, porém, sem caráter limitativo, telefone celular, smartphone (por exemplo, iPhone®, Blackberry®, telefones baseados em Android OS, etc.), computador tablet (por exemplo, Apple iPad™, HP Slate™, Motorola Xoom™, etc.), leitor de eBook (por exemplo, Amazon Kindle™, Barnes and Noble's Nook™ eReader, etc.), computador laptop, notebook, netbook, console de jogo (por exemplo, XBOX Live™, Nintendo® OS, Sony Playstation® Portable, etc.), scanner portátil, e/ou similares.
As redes são comumente imaginadas para compreender a interconexão e interoperação de clientes, servidores e nós intermediários em uma topologia de gráfico.
Deve-se notar que o termo "servidor", conforme usado ao longo deste pedido se refere geralmente a um computador, outro dispositivo, programa, ou combinação destes que processe e responda as solicitações de usuários remotos ao longo de uma rede de comunicações.
Os servidores servem suas informações para solicitar "clientes". O termo "cliente", conforme usado no presente documento, se refere geralmente a um computador, programa, outro dispositivo, usuário e/ou combinação destes que seja capaz de processar e efetuar solicitações e obter e processar quaisquer respostas a partir dos servidores ao longo de uma rede de comunicações.
Um computador, outro dispositivo, programa, ou combinação destes que facilite, processe informações e solicitações, e/ou promova a passagem de informações a partir de um usuário de origem para um usuário de destino é comumente referido como um "nó". As redes são geralmente imaginadas para facilitar a transferência de informações a partir de pontos de origem para pontos de destino.
Um nó especificamente encarregado de promover a passagem de informações a partir de uma origem até um destino é comumente chamado de um "roteador". Existem muitas formas de redes, tais como, Redes de Área Local (LANs), redes Pico, Redes de Longa Distância (WANs), Redes sem Fio (WLANs), etc.
Por exemplo, a Internet geralmente é aceita como uma interconexão de uma multiplicidade de redes por meio da qual clientes e servidores remotos podem acessar e interoperar uns com os outros.
O controlador UEP 6101 pode se basear em sistemas de computador que podem compreender, porém, sem caráter limitativo, componentes, tais como: uma sistematização do computador 6102 conectada à memória 6129. Sistematização do Computador 5 Uma sistematização do computador 6102 pode compreender um clock 6130, unidade de processamento central ("CPU" e/ou "processador" (estes termos são usados de maneira intercambiável ao longo da descrição, exceto quando indicado em contrário)) 6103, uma memória 6129 (por exemplo, uma memória somente leitura (ROM) 6106, uma memória de acesso aleatório (RAM) 6105, etc.) e/ou um barramento de interface 6107, e quase 1O frequentemente, embora não necessariamente, todas são interconectadas e/ou se comunicam através de um barramento de sistema 6104 em uma ou mais placa(s)(mãe) 6102 que têm caminhos de circuito condutor e/ou, de outro modo, caminhos de circuito de transporte através dos quais as instruções (por exemplo, sinais codificados binários) podem se deslocar para efetuar comunicações, operações, armazenamento, etc.
A sistematização do computador pode ser conectada a uma fonte de alimentação 6186; por exemplo, de maneira opcional, a fonte de alimentação pode ser interna.
De maneira opcional, um processador criptográfico 6126 e/ou transceptores (por exemplo, ICs) 6174 podem ser conectados ao barramento de sistema.
Em outra modalidade, o processador criptográfico e/ou transceptores podem ser conectados como dispositivos periféricos internos e/ou externos 6112 através do barramento de interface 1/0. Por sua vez, os transceptores podem ser conectados à antena 6175 efetuando, deste modo, a transmissão e recepção sem fio de diversos protocolos de comunicação e/ou sensor; por exemplo, a antena pode se conectar: a um chip transceptor Texas lnstruments Wilink WL 1283 (fornecendo, por exemplo, 802, 1m, Bluetooth 3.0, FM, sistema de posicionamento global (GPS) (permitindo, deste modo, que o controlador UEP determine sua localização)); chip transceptor Broadcom BCM4329FKUBG (fornecendo, por exemplo, 802,1m, Bluetooth 2.1 + EDR, FM, etc.); um chip receptor Broadcom BCM47501UB8 (por exemplo, GPS); um X-Gold 618-PMB9800 lnfineon Technologies (fornecendo, por exemplo, comunicações 2G/3G HSDPNHSUPA); e/ou similares.
O relógio do sistema tem, de maneira típica, um oscilador de cristal e gera um sinal de base através dos caminhos de circuito da sistematização do computador.
O clock é acoplado, de maneira típica, ao barramento de sistema e diversos multiplicadores de clock que irão aumentar ou diminuir a frequência de operação de base para outros componentes interconectados na sistematização do computador.
O clock e diversos componentes em sinais de acionamento de sistematização do computador que incorporam informações ao longo do sistema.
Tal transmissão e recepção de informações que incorporam instruções ao longo de uma sistematização do computador podem ser comumente referidas como comunicações.
Estas instruções comunicativas podem ser adicionalmente transmitidas, recebidas, e a causa de retorno e/ou resposta de comunicações além da sistematização imediata do computador para: redes de comunicações, dispositivos de entrada, outras sistematizações do computador, dispositivos periféricos, e/ou similares.
Deve-se entender que em modalidades alternativas, qualquer um 5 dos componentes acima pode ser diretamente conectado um ao outro, conectado à CPU e/ou organizado em inúmeras variações empregadas, conforme exemplificado pelos diversos sistemas de computador.
A CPU compreende pelo menos um processador de dados de alta velocidade adequado para executar componentes de programa para executar solicitações geradas pelo 1O usuário e/ou sistema.
Muitas vezes, os próprios processadores irão incorporar diversas unidades de processamento especializadas, tais como, porém, sem caráter limitativo: controladores de sistema integrado (barramento), unidades de controle de gerenciamento de memória, unidades de ponto flutuante, e ainda subunidades de processamento especializado como unidades de processamento gráfico, unidades de processamento de sinal digital, e/ou similares.
De maneira adicional, os processadores podem incluir memória endereçável interna de acesso rápido, e ser capazes de mapear e endereçar a memória 6129 além do próprio processador; a memória interna pode incluir, porém, sem caráter limitativo a: registros rápidos, diversos níveis de memória cache (por exemplo, nível 1, 2, 3, etc.), RAM, etc.
O processador pode acessar esta memória através do uso de um espaço de endereço de memória que é acessível através do endereço de instruções, cujo processador pode construir e decodificar permitindo que este acesse um caminho de circuito em um espaço de endereço de memória específico que tem um estado de memória.
A CPU pode ser um microprocessador, tal como: Athlon, Duron e/ou Opteron fabricado pela AMO; aplicativo ARM, processadores embutidos e seguros; DragonBall e PowerPC da IBM e/ou Motorola; processador celular da IBM e Sony; Celeron da Intel, processadores Core (2) Duo, ltanium, Pentium, Xeon, e/ou XScale; e/ou similares.
A CPU interage com a memória através da instrução que passa através de canais condutores e/ou de transporte (por exemplo, circuitos eletrônicos (impressos) e/ou ópticos) para executar as instruções armazenadas (isto é, código de programa) de acordo com as técnicas de processamento de dados convencionais.
Tal passagem de instrução facilita a comunicação dentro do controlador UEP e através das diversas interfaces.
Se os requisitos de processamento ditarem uma quantidade maior de velocidade e/ou capacidade, processadores distribuídos (por exemplo, UEP Distribuído), arquiteturas de mainframe, multi-core, paralelas e/ou de supercomputador podem ser similarmente empregadas.
De maneira alternativa, se os requisitos de implantação ditarem uma maior portabilidade, Assistentes Digitais Pessoais (PDAs) menores podem ser empregados.
Dependendo da implementação particular, as características do UEP podem ser obtidas através da implementação de um microcontrolador, tal como, o microcontrolador R8051XC2 da CAST; MCS 51 da Intel (isto é, microcontrolador 8051); e/ou similares.
Também, para implementar determinadas características do UEP, algumas implementações 5 de característica podem dependem dos componentes embutidos, tais como: Circuito Integrado de Aplicação Específica ("ASIC"), Processamento de Sinal Digital ("DSP"), Arranjo de Porta Programável em Campo ("FPGA"), e/ou tecnologias incorporadas similares.
Por exemplo, qualquer um entre a coleção de componentes UEP (distribuída, ou de outro modo) e/ou características podem ser implementadas através do microprocessador e/ou através de componentes embutidos; por exemplo, através de ASIC, coprocessador, DSP, FPGA, e/ou similares.
De maneira alternativa, algumas implementações do UEP podem ser implementadas com componentes embutidos que são configurados e usados para alcançar uma variedade de recursos ou processamento de sinal.
Dependendo da implementação particular, os componentes embutidos podem incluir soluções de software, soluções de hardware, e/ou alguma combinação de soluções de hardware/software.
Por exemplo, os recursos UEP discutidos no presente documento podem ser obtidos através da implementação de FPGAs, que são dispositivos semicondutores contendo componentes lógicos programáveis chamados de "blocos lógicos", e interconexões programáveis, tais como, high performance FPGA Virtex series e/ou Spartan series de baixo custo, fabricados pela Xilinx.
Os blocos lógicos e interconexões podem ser programados pelo cliente ou designer, após o FPGA ser fabricado, para implementar qualquer um dos recursos UEP.
Uma hierarquia de interconexões programáveis permite que os blocos lógicos sejam interconectados, conforme necessário, pelo designer/administrador do sistema UEP, um pouco como uma placa de ensaio programável de um chip.
Um bloco lógico do FPGA pode ser programado para realizar a operação de portas lógicas básicas, tais como, AND e XOR, ou operadores combinatórios mais complexos, tais como, decodificadores ou operações matemáticas simples.
Na maioria dos FPGAs, os blocos lógicos também incluem elementos de memória, que podem ser circuitos flip-flops ou blocos de memória mais completos.
Em algumas circunstâncias, o UEP pode ser desenvolvido em FPGAs regulares e, então, migrados em uma versão fixa que mais se assemelha às implementações ASIC.
As implementações alternadas ou coordenadas podem migrar recursos de controlador UEP até um ASIC final em vez de, ou além de, FPGAs.
Dependendo da implementação, todos os componentes e microprocessadores embutidos mencionados acima podem ser considerados a "CPU" e/ou "processador" para o UEP.
Fonte de Alimentação A fonte de alimentação 6186 pode ser de qualquer forma padrão para alimentar pequenos dispositivos de placa de circuito eletrônico, tais como, as seguintes células de energia: alcalina, hidreto de lítio, íon de lítio, polímero de lítio, níquel-cádmio, células 5 solares, e/ou similares.
Outros tipos de fontes de alimentação AC ou DC também podem ser usados.
No caso de células solares, em uma modalidade, proporciona-se uma abertura através da qual a célula solar pode capturar energia fotônica.
A célula de energia 6186 é conectada a pelo menos um dos componentes interconectados subsequentes do UEP proporcionando, deste modo, uma corrente elétrica para todos os componentes 1O subsequentes.
Em um exemplo, a fonte de alimentação 6186 é conectada ao componente de barramento de sistema 6104. Em uma modalidade alternativa, uma fonte de alimentação externa 6186 é proporcionada através de uma conexão ao longo da interface de 1/0 6108. Por exemplo, uma conexão USB e/ou IEEE 1394 transmite tanto dados como energia ao longo da conexão e, portanto, é uma fonte de alimentação adequada.
Adaptadores de Interface Os barramentos de interface 6107 podem aceitar, se conectar e/ou se comunicar com inúmeros adaptadores de interface, de maneira convencional, embora, não necessariamente na forma de placas adaptadoras, tais como, porém, sem caráter limitativo: interfaces de entrada e saída (1/0) 6108, interfaces de armazenamento 6109, interfaces de rede 6110, e/ou similares.
De maneira opcional, as interfaces de processador criptográfico 6127 podem ser similarmente conectadas ao barramento de interface.
O barramento de interface proporciona as comunicações de adaptadores de interface entre si, assim como, com outros componentes da sistematização do computador.
Os adaptadores de interface são adaptados para um barramento de interface compatível.
Os adaptadores de interface se conectam convencionalmente ao barramento de interface através de uma arquitetura de slot.
As arquiteturas de slot convencionais podem ser empregadas, tais como, porém, sem caráter limitativo: Porta Gráfica Acelerada (AGP), Barramento de Cartão, Arquitetura Padrão da Indústria (Estendida) ((E)ISA), Arquitetura de Micro Canal (MCA), NuBus, Interconexão do Componente Periférico (Estendida) (PCl(X)), PCI Express, Associação Internacional de Placas de Memória em Computadores Pessoais (PCMCIA), e/ou similares.
As interfaces de armazenamento 6109 podem aceitar, se comunicar e/ou se conectar a inúmeros dispositivos, tais como, porém, sem caráter limitativo: dispositivos de armazenamento 6114, dispositivos de disco removível, e/ou similares.
As interfaces de armazenamento podem empregar protocolos de conexão, tais como, porém, sem caráter limitativo: Acessório da Tecnologia Avançada (Ultra) (Serial) (Interface de Pacote) (ATA(PI) (Ultra) (Serial)), Eletrônica de Unidade Integrada (Avançada) ((E)IDE), Instituto de
Engenheiros Eletricistas e Eletrônicos (IEEE) 1394, canal de fibra, Interface para Sistemas de Computadores Pequenos (SCSI), Barramento Serial Universal (USB), e/ou similares. As interfaces de rede 611 O podem aceitar, se comunicar e/ou se conectar a uma rede de comunicações 6113. Através de uma rede de comunicações 6113, o controlador UEP é acessível através de clientes remotos 6133b (por exemplo, computadores com navegadores da Web) pelos usuários 6133a. As interfaces de rede podem empregar protocolos de conexão, tais como, porém, sem caráter limitativo: conexão direta, Ethernet (grossa, fina, par trançado 10/100/1000 Base T, e/ou similares), Token Ring, conexão sem fio, tal como, IEEE 802.11 a-x, e/ou similares. Se os requisitos de processamento ditarem 1O uma quantidade maior de velocidade e/ou capacidade, controladores de rede distribuída (por exemplo, UEP Distribuído), as arquiteturas podem ser similarmente empregadas para pool, balanceamento de carga, e/ou de outro modo aumentar a largura de banda comunicativa requerida pelo controlador UEP. Uma rede de comunicações pode ser qualquer uma entre e/ou combinação a seguir: uma interconexão direta; a Internet; uma Rede de Área Local (LAN); uma Rede de Área Metropolitana (MAN); Operating Missions as Nades on the Internet (OMNI); uma conexão personalizada segura; uma Rede de Longa Distância (WAN); uma rede sem fio (por exemplo, que emprega protocolos, tais como, porém, sem caráter limitativo, um Protocolo para Aplicações Sem Fio (WAP), 1-mode, e/ou similares); e/ou similares. Uma interface de rede pode ser considerada como uma forma especializada de uma interface de entrada e saída. Ademais, múltiplas interfaces de rede 6110 podem ser usadas para se engatar a diversos tipos de rede de comunicações 6113. Por exemplo, múltiplas interfaces de rede podem ser empregadas para permitir a comunicação por radiodifusão, redes multicast e/ou unicast. As interfaces de entrada e saída (1/0) 6108 podem aceitar, se comunicar e/ou se conectar aos dispositivos de entrada de usuário 6111, dispositivos periféricos 6112, dispositivos de processador criptográfico 6128, e/ou similares. A 1/0 pode empregar protocolos de conexão, tais como, porém, sem caráter limitativo: áudio: analógico, digital, monaural, RCA, estéreo, e/ou similares; dados: Apple Desktop Bus (ADB), IEEE 1394a-b, serial, barramento serial universal (USB); infravermelho; joystick; teclado; midi; óptico; PC AT; PS/2; paralelo; rádio; interface de vídeo: Apple Desktop Connector (ADC), BNC, coaxial, componente, composta, digital, Interface Visual Digital (DVI), interface multimídia de alta definição (HDMI), RCA, antenas RF, S-Video, VGA, e/ou similares; transceptores sem fio:
802.na/b/g/n/x; Bluetooth; celular (por exemplo, acesso múltiplo por divisão de código (COMA), acesso de pacote de alta velocidade (HSPA(+)),acesso de pacote downlink de alta velocidade (HSDPA), sistema global para comunicações móveis (GSM), evolução de longo prazo (LTE), WiMax, etc.); e/ou similares. Um dispositivo de saída típico pode incluir uma tela de vídeo que, de maneira típica, compreende um Tubo de Raios Catódicos (CRT) ou monitor baseado em Tela de Cristal Líquido (LCD) com uma interface (por exemplo, conjunto de circuitos e cabos DVI) que aceita sinais a partir de uma interface de vídeo, pode ser usado.
A interface de vídeo compõe informações geradas por uma sistematização do computador e gera sinais de vídeo baseados nas informações compostas em um quadro de 5 memória de vídeo.
Outro dispositivo de saída é um aparelho de televisão, que aceita sinais a partir de uma interface de vídeo.
De maneira típica, a interface de vídeo proporciona as informações de vídeo compostas através de uma interface de conexão de vídeo que aceita uma interface de exibição de vídeo (por exemplo, um conector de vídeo composto RCA que aceita um cabo de vídeo composto RCA; um conector DVI que aceita um cabo de vídeo DVI, etc.). Os dispositivos de entrada de usuário 6111 muitas vezes são um tipo de dispositivo periférico 6112 (vide abaixo) e pode incluir: leitores de cartão, dongles, leitores de impressão digital, luvas, tablets gráficos, joysticks, teclados, microfones, dispositivo apontador (mouses), controles remotos, leitores de retina, telas sensíveis ao toque (por exemplo, capacitivas, resistivas, etc.), trackballs, trackpads, sensores (por exemplo, acelerômetros, luz ambiente, GPS, giroscópios, proximidade, etc.), canetas stylus, e/ou similares.
Os dispositivos periféricos 6112 podem ser conectados e/ou se comunicar com 1/0 e/ou outras instalações similares, tais como, interfaces de rede, interfaces de armazenamento, diretamente ao barramento de interface, barramento de sistema, CPU, e/ou similares.
Os dispositivos periféricos podem ser externos, internos e/ou parte do controlador UEP.
Os dispositivos periféricos podem incluir: antena, dispositivos de áudio (por exemplo, linha de entrada, linha de saída, entrada de microfone, alto-falantes, etc.), câmeras (por exemplo, fotográficas, de vídeo, webcam, etc.), dongles (por exemplo, para proteção contra cópia, que asseguram transações seguras com uma assinatura digital, e/ou similares), processadores externos (para capacidades adicionadas; por exemplo, dispositivo de criptografia 6128), dispositivos de realimentação de força (por exemplo, motores de vibração), interfaces de rede, impressoras, scanners, dispositivos de armazenamento, transceptores (por exemplo, celular, GPS, etc.), dispositivos de vídeo (por exemplo, óculos de proteção, monitores, etc.), fontes de vídeo, visores, e/ou similares.
Os dispositivos periféricos muitas vezes incluem tipos de dispositivos de entrada (por exemplo, câmeras). Deve-se notar que embora os dispositivos de entrada de usuário e dispositivos periféricos possam ser empregados, o controlador UEP pode ser embutido como um dispositivo embutido, dedicado e/ou sem monitor (isto é, sem periféricos), em que o acesso pode ser proporcionado através de uma conexão de interface de rede.
As unidades criptográficas, tais como, porém, sem caráter limitativo, microcontroladores, processadores 6126, interfaces 6127, e/ou dispositivos 6128 podem ser conectadas e/ou se comunicar com o controlador UEP.
Um microcontrolador MC68HC16,
fabricado pela Motorola lnc., pode ser usado para e/ou dentro das unidades criptográficas.
O microcontrolador MC68HC16 utiliza uma instrução multiplicar e acumular de 16-bits na configuração de 16 MHz e requer menos de um segundo para realizar uma operação de chave privada de RSA 512-bits.
As unidades criptográficas suportam a autenticação de comunicações a partir dos agentes de interação, assim como, permitem transações.
As unidades criptográficas também podem ser configuradas como parte da CPU.
Microcontroladores e/ou processadores equivalentes também podem ser usados.
Outros processadores criptográficos especializados comercialmente disponíveis incluem: o CryptoNetX da Broadcom e outros Processadores de Segurança; nShield da nCipher, Luna 1O PCI (por exemplo, 7100) series da SafeNet; 40 MHz Roadrunner 184 da Semaphore Communications; Aceleradores Criptográficos da Sun (por exemplo, Accelerator 6000 PCle Board, Accelerator 500 Daughtercard); linha de Processador Via Nano (por exemplo, L2100, L2200, U2400), que é capaz de realizar 500+ MB/s de instruções criptográficas; 33 MHz 6868 da VLSI Technology; e/ou similares.
Memória Geralmente, qualquer mecanização e/ou modalidade que permita que um processador afete o armazenamento e/ou recuperação de informações seja considerada como a memória 6129. Entretanto, a memória consiste em uma tecnologia e recurso fungíveis, deste modo, qualquer número de modalidades de memória pode ser empregado no lugar de ou em conjunto umas com as outras.
Deve-se entender que o controlador UEP e/ou uma sistematização do computador pode empregar diversas formas de memória 6129. Por exemplo, uma sistematização do computador pode ser configurada em que a operação de memória de CPU em chip (por exemplo, registros), RAM, ROM, e quaisquer outros dispositivos de armazenamento são proporcionados por um mecanismo de fita papel perfurado ou papel cartão perfurado; entretanto, tal modalidade pode resultar em uma taxa de operação extremamente lenta.
Em uma configuração típica, a memória 6129 irá incluir ROM 6106, RAM 6105, e um dispositivo de armazenamento 6114. Um dispositivo de armazenamento 6114 pode ser qualquer armazenamento de sistema de computador convencional.
Os dispositivos de armazenamento podem incluir um tambor; uma unidade de disco magnético (fixa e/ou removível); uma unidade magneto-óptica; uma unidade óptica (isto é, Blueray, CD ROM/RAM/Gravável (R)/Regravável (RW), DVD R/RW, HD DVD R/RW etc.); uma variedade de dispositivos (por exemplo, Matriz Redundante de Discos Independentes (RAIO)); dispositivos de memória de estado sólido (memória USB, unidades de estado sólido (SSD), etc.); outros meios de armazenamento legíveis por processador; e/ou outros dispositivos, ou similares.
Deste modo, uma sistematização do computador geralmente requer e faz uso da memória.
Coleção de Componentes A memória 6129 pode conter uma coleção de componentes e/ou dados de programa e/ou banco de dados, tais como, porém, sem caráter limitativo: componente de sistema de operação 6115 (sistema de operação); componente de servidor de informações(s) 6116 5 (servidor de informações); componente de interface de usuário 6117 (interface de usuário); O componente de navegador da web 6118 (navegador da Web); banco de dados 6119; componente de servidor de email 6121; componente cliente de email 6122; componente de servidor criptográfico 6120 (servidor criptográfico); o componente UEP 6135; e/ou similares (isto é, coletivamente uma coleção de componentes). Estes componentes podem ser 1O armazenados e acessados a partir dos dispositivos de armazenamento e/ou dos dispositivos de armazenamento acessíveis através de um barramento de interface.
Embora componentes de programa não convencionais, tais como, aqueles na coleção de componentes, de maneira típica, sejam armazenados em um dispositivo de armazenamento local 6114, eles também podem ser carregados e/ou armazenados na memória, tais como: dispositivos periféricos, RAM, instalações de armazenamento remoto através de uma rede de comunicações, ROM, diversas formas de memória, e/ou similares.
Sistema de Operação O componente de sistema de operação 6115 é um componente de programa executável que facilita a operação do controlador UEP.
De maneira típica, o sistema de operação facilita o acesso de 1/0, interfaces de rede, dispositivos periféricos, dispositivos de armazenamento, e/ou similares.
O sistema de operação pode ser um sistema altamente tolerante a falhas, escalonável e seguro, tal como: Apple Macintosh OS X (Servidor); AT& T Plan 9; Be OS; distribuições de sistema Unix e semelhante a Unix (tais como, AT&T's UNIX; Berkley Software Distribution (BSD), variações, tais como, FreeBSD, NetBSD, OpenBSD, e/ou similares; distribuições Linux, tais como, Red Hat, Ubuntu, e/ou similares); e/ou sistemas de operação similares.
Entretanto, sistemas de operação mais limitados e/ou menos seguros também podem ser empregados, tais como, Apple Macintosh OS, IBM OS/2, Microsoft DOS, Microsoft Windows 2000/2003/3.1/95/98/CE/Millenium/NTNista/XP (Server), Palm OS, e/ou similares.
Um sistema de operação pode se comunicar e/ou com outros componentes em uma coleção de componentes, que inclui a si mesmo, e/ou similares.
De maneira mais frequente, o sistema de operação se comunica com outros componentes de programa, interfaces de usuário, e/ou similares.
Por exemplo, o sistema de operação pode conter, se comunicar, gerar, obter e/ou proporcionar componente de programa, comunicações de sistema, usuário, e/ou dados, solicitações e/ou respostas.
O sistema de operação, uma vez executado pela CPU, pode permitir a interação com redes de comunicações, dados, 110, dispositivos periféricos, componentes de programa, memória, dispositivos de entrada de usuário, e/ou similares.
O sistema de operação pode proporcionar protocolos de comunicações que permitem que o controlador UEP se comunique com outras entidades através de uma rede de comunicações 6113. Diversos protocolos de comunicação podem ser usados pelo controlador UEP como um mecanismo de transporte de subportadora para interação, tais como, porém, sem caráter limitativo: multicast, TCP/IP, 5 UDP, unicast, e/ou similar.
Servidor de Informações Um componente de servidor de informações 6116 é um componente de programa armazenado que é executado por uma CPU.
O servidor de informações pode ser um servidor de informações de Internet convencional, tais como, porém, sem caráter limitativo 1O Apache da Apache Software Foundation, Servidor de Informações de Internet da Microsoft, e/ou similares.
O servidor de informações pode permitir a execução de componentes de programa através de instalações, tais como, Página de Servidor Ativa (ASP), ActiveX, (ANSI) (Objective-) C (++), C# e/ou .NET, scripts de Interface de Gateway Comum (CGI), linguagem de marcação de hipertexto (HTML) dinâmica (D), FLASH, Java, JavaScript, Linguagem Prática de Extração e Relatório (PERL), Pré-processador de Hipertexto (PHP), pipes, Python, protocolo para aplicações sem fio (WAP), WebObjects, e/ou similares.
O servidor de informações pode suportar protocolos de comunicações seguros, tais como, porém, sem caráter limitativo, Protocolo de Transferência de Arquivos (FTP); Protocolo de Transferência de Hipertexto (HTTP); Protocolo de Transferência de Hipertexto Seguro (HTTPS), Camada de Soquete Seguro (SSL), protocolos de troca de mensagens (por exemplo, America Online (AOL) lnstant Messenger (AIM), Application Exchange (APEX), ICQ, Internet Relay Chat (IRC), Microsoft Network (MSN) Messenger Service, Presence and lnstant Messaging Protocol (PRIM), Força-Tarefa de Engenharia de Internet (IETF's) Protocolo de Iniciação de Sessão (SIP), SIP for lnstant Messaging and Presence Leveraging Extensions (SIMPLE), open XML-based Extensible Messaging and Presence Protocol (XMPP) (isto é, lnstant Messaging and Presence Service (IMPS) da Jabber ou Open Mobile Alliance (OMA)), Yahoo! lnstant Messenger Service, e/ou similares.
O servidor de informações proporciona resultados na forma de páginas da Web para navegadores da Web, e permite a geração manipulada das páginas da Web através da interação com outros componentes de programa.
Após uma parte de resolução de Sistema de Nomes de Domínios (DNS) de uma solicitação HTTP ser resolvida em um servidor de informações particular, o servidor de informações resolve as solicitações para informações em locais específicos no controlador UEP com base no restante de solicitação HTTP.
Por exemplo, uma solicitação, tal como, http:/1123.124.125.126/mylnformation.html pode ter a parte de IP da solicitação "123.124.125.126" resolvida por um servidor DNS em um servidor de informações naquele endereço IP; este servidor de informações, por sua vez, pode analisar adicionalmente a solicitação http para a parte "/mylnformation.html" da solicitação e resolver a mesma em um local na memória que contém as informações "mylnformation.html." De maneira adicional, outros protocolos de servidor de informações podem ser empregados através de diversas portas, por exemplo, comunicações FTP através da porta 21, e/ou similares.
Um servidor de informações pode se comunicar e/ou com outros componentes em 5 uma coleção de componentes, que inclui a si mesmo e/ou instalações similares.
De maneira mais frequente, o servidor de informações se comunica com o banco de dados UEP 6119, sistemas de operação, outros componentes de programa, interfaces de usuário, navegadores da Web, e/ou similares.
O acesso ao banco de dados UEP pode ser alcançado através de inúmeros 1O mecanismos de ponte de banco de dados, tais como, através de linguagem de script, conforme enumerado abaixo (por exemplo, CGI) e através de canais de comunicação entre aplicações, conforme enumerado abaixo, (por exemplo, CORSA, WebObjects, etc.). Quaisquer solicitações de dados através de um navegador da Web são analisados através do mecanismo de ponte em gramáticas apropriadas, conforme requerido pelo UEP.
Em uma modalidade, o servidor de informações pode proporcionar uma forma de Web acessível através de um navegador Web5. As entradas feitas nos campos fornecidos na forma de Web são marcadas sendo inseridas nos campos particulares, e analisadas Como isso.
Os termos inseridos são, então, passados junto com as marcas de campo, que atuam para instruir o analisador a gerar consultas direcionadas às tabelas e/ou campos apropriados.
Em uma modalidade, o analisador pode gerar consultas no padrão SQL ao exemplificar uma sequência de pesquisa com os comandos baseados nas entradas de texto marcadas, em que o comando resultante é proporcionado ao longo do mecanismo de ponte para o UEP como uma consulta.
Mediante a geração de resultados de consulta a partir da consulta, os resultados são passados ao longo do mecanismo de ponte, e podem ser analisados para formatação e geração de uma página da Web de novos resultados através do mecanismo de ponte.
Tal página da Web de novos resultados, então, é proporcionada para o servidor de informações, que pode fornecer a mesma para o navegador da Web solicitante.
Também, um servidor de informações pode conter, comunicar, gerar, obter e/ou proporcionar componente de programa, comunicações de sistema, usuário, e/ou dados, solicitações e/ou respostas.
Interface de Usuário As interfaces de computador em alguns aspectos são similares às interfaces de operação de automóvel.
Os elementos de interface de operação de automóvel, tais como, volantes, câmbios e velocímetros facilitam o acesso, operação e exibição de recursos de automóveis, e estado.
Os elementos de interface de operação de computador, tais como, caixas de seleção, cursores, menus, controles de rolagem, e janelas (referidas de maneira coletiva e comum como widgets) facilitam de maneira similar o acesso, capacidades,
operação e exibição de dados e recursos de hardware e sistema de operação de computador, e estado.
As interfaces de operação são comumente chamadas de interfaces de usuário.
As interfaces gráficas de usuário (GUls), tais como, o Aqua da Apple Macintosh Operating System', OS/2 da IBM, Windows 2000/2003/3. i/95/98/CE/Millenium/NT/XPNista/7 5 (isto é, Aero) da Microsoft, X-Windows da Unix (por exemplo, que pode incluir bibliotecas e camadas de interface gráfica Unix adicionais, tais como, K Desktop Environment (KDE), mythTV e GNU Network Object Model Environment (GNOME)), bibliotecas de interface da web (por exemplo, ActiveX, AJAX, (D)HTML, FLASH, Java, JavaScript, etc. bibliotecas de interface, tais como, porém, sem caráter limitativo, Dojo, jQuery(UI), MooTools, Prototype, script.aculo.us, SWFObject, Yahoo! User Interface, qualquer uma destas pode ser usada) e proporcionar uma linha de base e meios de acesso e exibição de informações graficamente para usuários.
Um componente de interface de usuário 6117 é um componente de programa armazenado que é executado por uma CPU.
A interface de usuário pode ser uma interface gráfica de usuário convencional, conforme proporcionada pelos, com e/ou em cima dos sistemas de operação e/ou ambientes de operação, tal como, já discutido.
A interface de usuário pode permitir a exibição, execução, interação, manipulação e/ou operação dos componentes de programa e/ou instalações de sistema através de instalações textuais e/ou gráficas.
A interface de usuário proporciona uma instalação através da qual os usuários podem afetar, interagir e/ou operar um sistema de computador.
Uma interface de usuário pode se comunicar e/ou com outros componentes em uma coleção de componentes, que inclui a si mesma, e/ou instalações similares.
De maneira mais frequente, a interface de usuário se comunica com sistemas de operação, outros componentes de programa, e/ou similares.
A interface de usuário pode conter, comunicar, gerar, obter, e/ou proporcionar componente de programa, comunicações de sistema, usuário, e/ou dados, solicitações e/ou respostas.
Navegador da Web Um componente de navegador da web 6118 é um componente de programa armazenado que é executado por uma CPU.
O navegador da Web pode ser um aplicativo de visualização de hipertexto convencional, tal como, Microsoft Internet Explorer ou Netscape Navigator.
A navegação segura na Web pode ser dotada de criptografia de 128bits (ou maior) por meio de HTTPS, SSL, e/ou similares.
Os navegadores da Web que permitem a execução de componentes de programa através de instalações, tais como, ActiveX, AJAX, (D)HTML, FLASH, Java, JavaScript, APls plug-in de navegador da Web (por exemplo, FireFox, Safari Plug-in, e/ou APls similares), e/ou similares.
Os navegadores da Web e ferramentas de acesso de informações similares podem ser integrados em PDAs, telefones celulares e/ou outros dispositivos móveis.
Um navegador da Web pode se comunicar e/ou com outros componentes em uma coleção de componentes, que inclui a si mesmo, e/ou instalações similares.
De maneira mais frequente, o navegador da Web se comunica com servidores de informações, sistemas de operação, componentes de programa integrados (por exemplo, plug-ins), e/ou similares; por exemplo, este pode conter, 5 comunicar, gerar, obter, e/ou proporcionar componente de programa, comunicações de sistema, usuário, e/ou dados, solicitações e/ou respostas.
Também, no lugar de um navegador da Web e servidor de informações, uma aplicação combinada pode ser desenvolvida para realizar operações similares de ambos.
A aplicação combinada pode afetar, de maneira similar, a obtenção e o fornecimento de informações para usuários, 1O agentes de usuário, e/ou similares a partir dos nós habilitados por UEP.
A aplicação combinada pode ser insignificante em sistemas que empregam navegadores da Web padrão.
Servidor de Email Um componente de servidor de email 6121 é um componente de programa armazenado que é executado por uma CPU 6103. O servidor de email pode ser um servidor de email de Internet convencional, tais como, porém, sem caráter limitativo sendmail, Microsoft Exchange, e/ou similares.
O servidor de email pode permitir a execução de componentes de programa através de instalações, tais como, ASP, ActiveX, (ANSI) (Objective-) C (++), C# e/ou .NET, CGI scripts, Java, JavaScript, PERL, PHP, pipes, Python, WebObjects, e/ou similares.
O servidor de email pode suportar protocolos de comunicações, tais como, porém, sem caráter limitativo: protocolo de acesso a mensagem de Internet (IMAP), Interface de Programação de Aplicativo de Troca de Mensagens (MAPl)/Microsoft Exchange, protocolo dos correios (POP3), protocolo de transferência de correio simples (SMTP), e/ou similares.
O servidor de email pode rotear, encaminhar e processar as mensagens de email de entrada e saída que foram enviadas, retransmitidas e/ou, de outro modo, transferidas através e/ou para o UEP.
O acesso ao correio UEP pode ser obtido através de inúmeros APls oferecidos pelos componentes de servidor da Web individuais e/ou pelo sistema de operação.
Também, um servidor de email pode conter, comunicar, gerar, obter, e/ou proporcionar componente de programa, comunicações de sistema, usuário, e/ou dados, solicitações, informações e/ou respostas.
Cliente de Email Um componente cliente de email 6122 é um componente de programa armazenado que é executado por uma CPU 6103. O cliente de email pode ser um aplicativo de visualização de email convencional, tais como, Apple Mail, Microsoft Entourage, Microsoft Outlook, Microsoft Outlook Express, Mozilla, Thunderbird, e/ou similares.
Os clientes de email podem suportar inúmeros protocolos de transferência, tais como: IMAP, Microsoft
Exchange, POP3, SMTP, e/ou similares.
Um cliente de email pode se comunicar e/ou com outros componentes em uma coleção de componentes, que inclui a si mesmo, e/ou instalações similares.
De maneira mais frequente, o cliente de email se comunica com servidores de email, sistemas de operação, outros clientes de email, e/ou similares; por exemplo, este pode conter, comunicar, gerar, obter, e/ou proporcionar componente de programa, comunicações de sistema, usuário, e/ou dados, solicitações, informações e/ou respostas.
Geralmente, o cliente de email proporciona uma instalação para compor e transmitir mensagens de correio eletrônico.
Servidor Criptográfico Um componente de servidor criptográfico 6120 é um componente de programa armazenado que é executado por uma CPU 6103, processador criptográfico 6126, interface de processador criptográfico 6127, dispositivo processador criptográfico 6128, e/ou similares.
As interfaces de processador criptográfico irão permitir a expedição de solicitações de criptografia e/ou descriptografia através do componente criptográfico; entretanto, o componente criptográfico, de maneira alternativa, pode executar em uma CPU convencional.
O componente criptográfico permite a criptografia e/ou descriptografia dos dados proporcionados.
O componente criptográfico permite a criptografia e/ou descriptografia simétrica ou assimétrica (por exemplo, Pretty Good Protection (PGP)). O componente criptográfico pode empregar técnicas criptográficas, tais como, porém, sem caráter limitativo: certificados digitais (por exemplo, X.509 authentication framework), assinaturas digitais, assinaturas duplas, envelopamento, proteção ao acesso de senha, gerenciamento de chave pública, e/ou similares.
O componente criptográfico irá facilitar inúmeros protocolos de segurança (criptografia e/ou descriptografia), tais como, porém, sem caráter limitativo: soma de verificação, Padrão de Criptografia de Dados (DES), Criptografia de Curva Elíptica (ECC), Algoritmo de Criptografia de Dados Internacional (IDEA), Resumo da Mensagem 5 (MD5, que é uma operação hash unidirecional), senhas, Cifrador de Rivest (RC5), Rijndael, RSA (que é um sistema de criptografia e autenticação da Internet que usa um algoritmo desenvolvido em 1977 por Ron Rivest, Adi Shamir e Leonard Adleman), Algoritmo de Hash Seguro (SHA), Camada de Soquete Seguro (SSL), Protocolo de Transferência de Hipertexto Seguro (HTTPS), e/ou similares.
Empregando-se tais protocolos de segurança de criptografia, o UEP pode criptografar todas as comunicações de entrada e/ou saída e pode servir como o nó dentro de uma rede virtual privada (VPN) com uma rede de comunicações mais ampla.
O componente criptográfico facilita o processo de "autorização de segurança" por meio do qual o acesso a um recurso é impedido por um protocolo de segurança em que o componente criptográfico efetua o acesso autorizado ao recurso seguro.
Além disso, o componente criptográfico pode proporcionar identificadores exclusivos de conteúdo empregando, por exemplo, hash MOS para obter uma assinatura exclusiva para um arquivo de áudio digital.
Um componente criptográfico pode se comunicar e/ou com outros componentes em uma coleção de componentes, que inclui a si mesmo, e/ou instalações similares.
O componente criptográfico suporta esquemas de criptografia que permitem a transmissão segura de informações ao longo de uma rede de comunicações 5 para permitir que o componente UEP se envolva em transações seguras, se desejado.
O componente criptográfico facilita o acesso de recursos protegidos no UEP e facilita o acesso de recursos protegidos em sistemas remotos; isto é, este pode atuar como um cliente e/ou servidor de recursos protegidos.
De maneira mais frequente, o componente criptográfico se comunica com servidores de informações, sistemas de operação, outros componentes de 1O programa, e/ou similares.
O componente criptográfico pode conter, comunicar, gerar, obter, e/ou proporcionar componente de programa, comunicações de sistema, usuário, e/ou dados, solicitações e/ou respostas.
O Banco de Dados UEP O componente de banco de dados UEP 6119 pode ser incorporado em um banco de dados e seus dados armazenados.
O banco de dados é um componente de programa armazenado, que é executado pela CPU; a parte do componente de programa armazenado configura a CPU para processar os dados armazenados.
O banco de dados pode ser um banco de dados convencional, tolerante a falhas, relacional, escalonável, seguro, tal como, Oracle ou Sybase.
Os bancos de dados relacionais são uma extensão de um arquivo simples.
Os bancos de dados relacionais consistem em uma série de tabelas relacionadas.
As tabelas são interconectadas através de um campo-chave.
O uso do campo-chave permite a combinação das tabelas ao indexar contra o campo-chave; isto é, os campos- chave atuam como os pontos dinâmicos dimensionais para combinar informações a partir de diversas tabelas.
As relações geralmente identificam os links mantidos entre as tabelas combinando-se as chaves primárias.
As chaves primárias representam campos que identificam exclusivamente as linhas de uma tabela em um banco de dados relacional.
De maneira mais precisa, elas identificam exclusivamente as linhas de uma tabela em "um" lado de uma relação um-para-muitos.
De maneira alternativa, o banco de dados de UEP pode ser implementado usando diversas estruturas de dados padrão, tais como, uma matriz, hash, lista (vinculada), struct, arquivo de texto estruturado (por exemplo, XML), tabela, e/ou similares.
Tais estruturas de dados podem ser armazenadas na memória e/ou em arquivos (estruturados). Em outra alternativa, um banco de dados orientado a objeto pode ser usado, tais como, Frontier, ObjectStore, Poet, Zope, e/ou similares.
Os bancos de dados orientados a objeto podem incluir inúmeras coleções de objetos que são agrupados e/ou ligados por atributos comuns; eles podem ser relacionados a outras coleções de objetos por alguns atributos comuns.
Os bancos de dados orientados a objeto executam de maneira similar aos bancos de dados relacionais, exceto pelo fato de que os objetos não são apenas pedaços de dados, porém, podem ter outros tipos de capacidades encapsuladas dentro de um determinado objeto.
Se o banco de dados UEP for implementado como uma estrutura de dados, o uso do banco de dados UEP 6119 pode ser integrado em outro componente, tal como, o componente UEP 5 6135. Também, o banco de dados pode ser implementado como uma mistura de estruturas de dados, objetos e estruturas relacionais.
Os bancos de dados podem ser consolidados e/ou distribuídos em variações incontáveis por meio de técnicas de processamento de dados padrão.
As porções de bancos de dados, por exemplo, tabelas, podem ser exportadas e/ou importadas e, deste modo, descentralizadas e/ou integradas.
Em uma modalidade, o componente de banco de dados 6119 inclui diversas tabelas 6119a-o.
Uma tabela de Usuários 6119a pode incluir campos, tais como, porém, sem caráter limitativo: user_id, ssn, dob, first_name, last_name, age, state, address_firstline, address_secondline, zipcode, devices_list, contact_info, contact_type, alt_contact_info, alt_contact_type, e/ou similares.
A tabela de Usuários pode suportar e/ou rastrear múltiplas contas de entidade em um UEP.
Uma tabela de Dispositivos 6119b pode incluir campos, tais como, porém, sem caráter limitativo: device_ID, device_name, device_IP, device_MAC, device_type, device_model, device_version, device_OS, device_apps_list, device_securekey, carteira_app_installed_flag, e/ou similares.
Uma tabela de Apps 6119c pode incluir campos, tais como, porém, sem caráter limitativo: app_ID, app_name, app_type, app_dependencies, e/ou similares.
Uma tabela de contas 6119d pode incluir campos, tais como, porém, sem caráter limitativo: account_number, account_security_code, account_name, issuer_acquirer_flag, issuer_name, adquirente_name, account_address, routing_number, access_APl_call, linked_wallets_list, e/ou similares.
Uma tabela de Comerciantes 6119e pode incluir campos, tais como, porém, sem caráter limitativo: merchant_id, merchant_name, merchant_address, ip_address, mac_address, auth_key, port_num, security_settings_list, e/ou similares.
Uma tabela de Emissores 6119f pode incluir campos, tais como, porém, sem caráter limitativo: issuer_id, issuer_name, issuer_address, ip_address, mac_address, auth_key, port_num, security_settings_list, e/ou similares.
Uma tabela de Adquirentes 6119g pode incluir campos, tais como, porém, sem caráter limitativo: account_firstname, account_lastname, account_type, account_num, account_ balance_list, billingaddress_ line1, billingaddress_ line2, billing_zipcode, billing_state, shipping_preferences, shippingaddress_line1, shippingaddress_line2, shipping_ zipcode, shipping_state, e/ou similares.
Uma tabela de Gateways de Pagamento 6119h pode incluir campos, tais como, porém, sem caráter limitativo: gateway_ID, gateway_IP, gateway_MAC, gateway_secure_key, gateway_access_list, gateway_APl_call_list, gateway_services_list, e/ou similares.
Uma tabela de Transações 6119i pode incluir campos, tais como, porém, sem caráter limitativo: order_id, user_id, timestamp, transaction_cost,
purchase_detalhes_list, num_products, products_list, product_type, product_params_list, product_title, product_summary, quantity, user_id, client_id, client_ip, client_type, client_model, operating_sistema, os_version, app_installed_flag, user_id, account_firstname, account_lastname, account_type, account_num, account_priority_account_ratio, 5 billingaddress_line1, billingaddress_line2, billing_zipcode, billing_state, shipping_preferences, shippingaddress_line1, shippingaddress_line2, shipping_ zipcode, shipping_state, merchant_id, merchant_name, merchant_auth_key, e/ou similares.
Uma tabela de Lotes 6119j pode incluir campos, tais como, porém, sem caráter limitativo: batch_id, transaction_id_list, timestamp_list, cleared_flag_list, clearance_trigger_ settings, e/ou similares.
Uma tabela de Razão 6119k pode incluir campos, tais como, porém, sem caráter limitativo: request_id, timestamp, deposit_amount, batch_id, transaction_id, clear_flag, deposit_account, transaction_summary, payor_ name, payor_account, e/ou similares.
Uma tabela de Produtos 61191 pode incluir campos, tais como, porém, sem caráter limitativo: product_ID, product_title, product_attributes_list, product_price, tax_info_list, related_products_ list, offers_list, discounts_list, rewards_list, merchants_list, merchant_availability_list, e/ou similares.
Uma tabela de Ofertas 6119m pode incluir campos, tais como, porém, sem caráter limitativo: offer_ID, offer_title, offer_attributes_list, offer_price, offer_expiry, related_products_ list, discounts_list, rewards_list, merchants_list, merchant_availability_list, e/ou similares.Uma tabela de Dados de Comportamento 6119n pode incluir campos, tais como, porém, sem caráter limitativo: user_id, timestamp, activity_type, activity_location, activity_attribute_list, activity_attribute_values_list, e/ou similares.
Uma tabela de Análise 61190 pode incluir campos, tais como, porém, sem caráter limitativo: report_id, user_id, report_type, report_algorithm_id, report_destination_address, e/ou similares.
Uma tabela de Dados de Mercado 6119p pode incluir campos, tais como, porém, sem caráter limitativo: market_data_feed_ID, asset_ID, asset_symbol, asset_name, spot_price, bid_price, ask_price, e/ou similares; em uma modalidade, a tabela de dados de mercado é preenchida através de um feed de dados de mercado (por exemplo, Bloomberg's PhatPipe, Dun & Bradstreet, Reuter's Tib, Triarch, etc.), por exemplo, através da Active Template Library da Microsoft e real-time toolkit Rtt.Multi da Dealing Object Technology.
Em uma modalidade, o banco de dados UEP pode interagir com outros sistemas de banco de dados.
Por exemplo, o emprego de um sistema de banco de dados distribuído, consultas e acesso de dados pesquisando-se o componente UEP pode tratar a combinação do banco de dados UEP, um banco de dados de camada de segurança de dados integrado como uma unidade entidade de banco de dados.
Em uma modalidade, os programas de usuário podem conter diversas interfaces de usuário primitivas, que podem servir para atualizar o UEP.
Também, diversas contas podem requerer tabelas de bancos de dados personalizadas dependendo dos ambientes e dos tipos de clientes que o UEP pode precisar servir.
Deve-se notar que quaisquer campos exclusivos podem ser designados como um campo-chave.
Em uma modalidade alternativa, estas tabelas foram descentralizadas em seus próprios bancos de dados e seus respectivos controladores de banco de dados (isto é, controladores de banco de dados individuais para 5 cada uma das tabelas acima). Empregando-se técnicas de processamento de dados padrão, alguém pode distribuir adicionalmente os bancos de dados ao longo de diversas sistematizações do computador e/ou dispositivos de armazenamento.
De maneira similar, as configurações dos controladores de banco de dados descentralizados podem ser variadas consolidando-se e/ou distribuindo-se os diversos componentes de banco de dados 6119a-o. 1O O UEP pode ser configurado para acompanhar as diversas configurações, entradas e parâmetros através de controladores de banco de dados.
O banco de dados UEP pode se comunicar e/ou com outros componentes em uma coleção de componentes, que inclui a si mesmo, e/ou instalações similares.
De maneira mais frequente, o banco de dados UEP se comunica com o componente UEP, outros componentes de programa, e/ou similares.
O banco de dados pode conter, reter e proporcionar informações que se referem a outros nós e dados.
Os UEPs O componente UEP 6135 é um componente de programa armazenado que é executado por uma CPU.
Em uma modalidade, o componente UEP incorpora qualquer um e/ou todas as combinações dos aspectos do UEP discutido nas Figuras anteriores.
Como isso, o UEP afeta o acesso, obtenção e o fornecimento de informações, serviços, transações, e/ou similares, ao longo das diversas redes de comunicações.
O componente UEP pode transformar entradas sensíveis ao toque em uma interface de aplicativos móveis de carteira virtual através de componentes UEP em disparadores e avisos de recebimento de transação de compra, e/ou similares e uso do UEP.
Em uma modalidade, o componente UEP 6135 adota entradas (por exemplo, solicitação de finalização de compra 5511; dados de produto 5515; entrada de acesso de carteira 5711; entrada de autorização de transação 5714; endereço de gateway de pagamento 5718; endereço de rede de pagamento 5722; endereço de servidor emissor 5725; solicitação de autorização de fundos 5726; dados de conta de usuário 5728; dados em lote 5912; endereço de rede de pagamento 5916; endereço de servidor emissor 5924; solicitação de pagamento individual 5925; dados de razão de pagamento, conta de comerciante 5931; e/ou similares) etc., e transforma as entradas através de diversos componentes (por exemplo, UPC 6141; PTA 6142; PTC 6143; STG 6144; EPGU 6145; EAA 6146; CEC 6147; ETC 6148; DFR 6149; ADRN 6150; VASE 6151; SOA 6152; TOA 6153; CTDA 6154; SRA 6155; UBA 6156; UBOR 6157; SPE 6158; SPT 6159; WSS 6160; SMCB 6161; VWSC 6162; ORE 6163; QRCP 6164; SMPE 6165; PCS 6166; UST 6167; STRS 6168; USTG 6169; e/ou similares), em saídas (por exemplo, mensagem de solicitação de finalização de compra 5513; dados de finalização de compra 5517; pedido de autorização de cartão 5716, 5723; resposta de autorização de fundos 5730; resposta de autorização de transação 5732; dados acrescentados em lote 5734; recibo de compra 5735; solicitação de autorização em lote 5 5914; solicitação de pagamento em lote 5918; dados de transação 5920; confirmação de pagamento individual 5928, 5929; razão de pagamento atualizada, dados de conta de comerciante 5933; e/ou similares). O componente UEP que permite o acesso de informações entre os nós pode ser desenvolvido empregando-se ferramentas e linguagens de desenvolvimento padrão, tais 1O como, porém, sem caráter limitativo: componentes Apache, Assembly, ActiveX, executáveis binários, (ANSI) (Objective-) C (++), C# e/ou .NET, adaptadores de banco de dados, CGI scripts, Java, JavaScript, ferramentas de mapeamento, ferramentas de desenvolvimento de procedimento e orientadas a objeto, PERL, PHP, Python, shell scripts, comandos SQL, extensões de servidor de aplicativo da Web, ambientes e bibliotecas de desenvolvimento da web (por exemplo, ActiveX da Microsoft; Adobe AIR, FLEX & FLASH; AJAX; (D)HTML; Dojo, Java; JavaScript; jQuery(UI); MooTools; Prototype; script.aculo.us; Protocolo Simples de Acesso a Objetos (SOAP); SWFObject; Yahoo! User Interface; e/ou similares), WebObjects, e/ou similares.
Em uma modalidade, o servidor UEP emprega um servidor criptográfico para criptografar e descriptografar comunicações.
O componente UEP pode se comunicar e/ou com outros componentes em uma coleção de componentes, que inclui a si mesmo, e/ou instalações similares.
De maneira mais frequente, o componente UEP se comunica com o banco de dados UEP, sistemas de operação, outros componentes de programa, e/ou similares.
O UEP pode conter, comunicar, gerar, obter, e/ou proporcionar componente de programa, comunicações de sistema, usuário, e/ou dados, solicitações e/ou respostas.
UEP Distribuídos A estrutura e/ou operação de qualquer um dos componentes de controlador de nó UEP pode ser combinada, consolidada e/ou distribuída em qualquer número de maneiras para facilitar o desenvolvimento e/ou implantação.
De maneira similar, a coleção de componentes pode ser combinada em qualquer número de maneira para facilitar a implantação e/ou desenvolvimento.
Para realizar isto, alguém pode integrar os componentes em um código base comum ou em uma instalação que pode carregar dinamicamente os componentes em demanda de uma forma integrada.
A coleção de componentes pode ser consolidada e/ou distribuída em variações incontáveis através de técnicas de processamento e/ou desenvolvimento de dados padrão.
Múltiplos exemplos de qualquer um dos componentes de programa na coleção de componentes de programa podem ser exemplificados em um único nó e/ou ao longo de muitos nós para aprimorar o desempenho através de técnicas de equilíbrio de carga e/ou processamento de dados.
Além disso, instâncias únicas também podem ser distribuídas ao longo de múltiplos controladores e/ou dispositivos de armazenamento; por exemplo, bancos de dados.
Todas as instâncias e controladores de componente de programa que funcionam em conjunto podem efetuar isto através de técnicas de processamento de comunicação de dados padrão.
A configuração do controlador UEP irá depender do contexto de implantação do sistema.
Fatores, tais como, porém, sem caráter limitativo, o orçamento, capacidade, localização e/ou uso dos recursos de hardware subjacentes podem afetar os requisitos de implantação e configuração.
Independente de os resultados de configuração em 1O componentes de programa mais consolidados e/ou integrados, resultarem em uma série mais distribuída de componentes de programa, e/ou resultados em alguma combinação entre uma configuração consolidada e distribuída, os dados podem ser comunicados, obtidos e/ou proporcionados.
Instâncias de componentes consolidados em um código base comum a partir da coleção de componentes de programa podem comunicar, obter e/ou proporcionar dados.
Isto pode ser realizado através de técnicas de processamento de comunicação de dados entre aplicações, tais como, porém, sem caráter limitativo: referenciação de dados (por exemplo, ponteiros), troca de mensagens interna, comunicação variável de instância de objeto, espaço de memória compartilhado, passagem variável, e/ou similares.
Se os componentes da coleção de componentes forem discretos, separados, e/ou externos uns aos outros, então, a comunicação, obtenção e/ou fornecimento de dados com e/ou em outros componentes podem ser realizados através de técnicas de processamento de comunicação de dados entre aplicações, tais como, porém, sem caráter limitativo: passagem de informações de Interfaces de Programa de Aplicativo (API); Modelo de Objeto Componente ((D)COM) (distribuído), Vinculação e Incorporação de Objetos ((D)OLE) (Distribuída), e/ou similares), Arquitetura de Agente de Solicitação de Objetos Comuns (CORSA), interfaces de programas aplicativos locais e remotas Jini, Notação de Objeto JavaScript (JSON), Invocação de Método Remoto (RMI), SOAP, tubos de processo, arquivos compartilhados, e/ou similares.
As mensagens enviadas entre componentes de componente discreto para comunicação entre aplicações ou dentro de espaço de memória de um único componente para comunicação entre aplicações podem ser facilitadas através da criação e análise de uma gramática.
Uma gramática pode ser desenvolvida usando ferramentas de desenvolvimento, tais como, lex, yacc, XML, e/ou similares, que permitem as capacidades de geração e análise de gramática, que por sua vez pode formar a base de mensagens de comunicação dentro e entre componentes.
Por exemplo, uma gramática pode ser disposta para reconhecer os tokens de um posto de comando HTTP, por exemplo:
w3c -post http: li ... Value1 onde o Value1 é discernido como um parâmetro porque "http:ll" faz parte da sintaxe gramatical, e o que se segue é considerado uma parte do valor posterior.
De maneira similar, com tal gramática, um "Value1" variável pode ser inserido em um posto de comando 5 "http:ll" e, então, enviado.
A própria sintaxe gramatical pode ser apresentada como dados estruturados que são interpretados e/ou de outro modo usados para gerar o mecanismo de análise (por exemplo, um arquivo de texto de descrição de sintaxe como processado por lex, yacc, etc.). Também, uma vez que o mecanismo de análise é gerado e/ou instanciado, o próprio pode processar e/ou analisar dados estruturados, tais como, porém, sem caráter 1O limitativo: texto delineado por caractere (por exemplo, guia), HTML, fluxos de texto estruturado, XML, e/ou dados estruturados similares.
Em outra modalidade, os próprios protocolos de processamento de dados entre aplicações podem ter analisadores integrados e/ou prontamente disponíveis (por exemplo, JSON, SOAP, e/ou analisadores similares) que podem ser empregados para analisar dados (por exemplo, comunicações). Ademais, a gramática de análise pode ser usada além da análise de mensagem, mas, também pode ser usada para analisar: bancos de dados, coleções de dados, repositórios de dados, dados estruturados, e/ou similares.
Novamente, a configuração desejada irá depender do contexto, ambiente e requisitos de implantação do sistema.
Por exemplo, em algumas implementações, o controlador UEP pode estar executando um script PHP que implementa um servidor de soquete de Camada de Soquete Seguro ("SSL") através do servidor de informações, que ouve as comunicações de entrada em uma porta de servidor na qual um cliente pode enviar dados, por exemplo, dados codificados em formato JSON.
Mediante a identificação de uma comunicação de entrada, o script PHP pode ler a mensagem de entrada a partir do dispositivo de cliente, analisar os dados de texto codificados JSON recebidos para extrair informações dos dados de texto codificados JSON em variáveis de script PHP, e armazenar os dados (por exemplo, informações de identificação de cliente, etc.) e/ou informações extraídas em um banco de dados relacional acessível usando uma Linguagem de Consulta Estruturada ("SQL"). Uma listagem exemplificativa, gravada substancialmente na forma de comandos PHP/SQL, para aceitar os dados de entrada codificados por JSON a partir de um dispositivo de cliente através de uma conexão SSL, analisa os dados para extrair variáveis, e armazena os dados em um banco de dados, é proporcionada abaixo: <?PHP header ('Content-Type: text/plain');
li set ip address and port to listen to for incoming data $address =<1>192.168.0.100';
$port = 255;
li create a servidor-side SSL socket, listen for/accept incoming communication $sock = socket_create (AF_INET, SOCK_STREAM, O); 5 socket_bind ($sock, $address, $port) ar die ('Could not bind to address'); socket_listen ($sock) ; $client = socket_accept ($sock) ;
li read input data from dispositivo de cliente in 1024 byte blocks until end of mensagem do { $input=""; $input = socket_read ( $client, 1024); $data .= $input; } while ($ input != "") ;
li parse data to extract variables $obj = j son_decode ( $data, true) ;
li store input data in a banco de dados mysql_connect ( "201.408.185.132 ", $DBserver, $password) ; li access database server mysql_select ( "CLIENT_DB . SQL") ; li select database to append mysql_query ("INSERT INTO UserTable (transmission) VALUES ($data)"); li add data to UserTable table in a CLIENT database mysql_close ( "CLIENT_DB.
SQL" ) ; li close connection to database ?>
Também, os seguintes recursos podem ser usados para proporcionar modalidades exemplificativas que se referem à implementação de analisador SOAP:
http: / /www . xav . com/perl/ site/ lib/ SOAP/Parser . html http: I /publib.boulder. ibm . comi infocenter/tivihelp/v2rl/ índex. j sp?topic=/com . ibm
IBMDI . doei referenceguide295. Htm e outras implementações de analisador:
http: I /publib . boulder . ibm . comi infocenter/tivihelp/v2r 1 I index. j sp?topic=/com . ibm . IBMDI . doei referenceguide259. htm 5 todas as quais são expressamente incorporadas no presente documento a título de referência.
A fim de lidar com diversas questões e avançar a técnica, a totalidade deste pedido para UNIVERSAL ELECTRONIC PAYMENT APPARATUSES, METHODS / ANO SYSTEMS 1O (que inclui a Folha de Rosto, Título, Cabeçalho, Campo, Antecedentes da Invenção, Sumário, Breve Descrição dos Desenhos, Descrição Detalhada, Reivindicações, Resumo, Figuras, Anexos e/ou de outro modo) mostra por meio de ilustração diversas modalidades nas quais as inovações reivindicadas podem ser praticadas.
As vantagens e recursos do pedido são apenas uma amostra representativa das modalidades, e não devem ser exaustivos e/ou exclusivos.
Eles são apresentados apenas para auxiliar no entendimento e ensinar os princípios reivindicados.
Deve-se entender que eles não são representativos de todas as inovações reivindicadas.
Como isso, determinados aspectos da descrição não foram discutidos no presente documento.
Estas modalidades alternativas que podem não ter sido apresentadas para uma porção específica das inovações ou estas modalidades alternativas não descritas adicionais que podem estar disponíveis para uma porção não devem ser consideradas uma rejeição a estas modalidades alternativas.
Será avaliado que muitas destas modalidades não descritas incorporam os mesmos princípios das inovações e outros são equivalentes.
Deste modo, deve-se entender que outras modalidades podem ser utilizadas e modificações funcionais, lógicas, operacionais, organizacionais, estruturais e/ou topológicas podem ser efetuadas sem sair do escopo e/ou espírito da descrição.
Como isso, todos os exemplos e/ou modalidades são considerados não limitativos ao longo desta descrição.
Também, nenhuma inferência deve ser delineada em relação a estas modalidades discutidas no presente documento em relação àquelas não discutidas no presente documento, exceto o que serve, como tal, para propósitos de redução de espaço e repetição.
Por exemplo, deve-se entender que a estrutura lógica e/ou topológica de qualquer combinação de quaisquer componentes de programa (uma coleção de componentes), outros componentes e/ou quaisquer conjuntos de características presentes, conforme descrito nas Figuras e/ou completamente, não deve se limitar a uma ordem e/ou disposição de operação fixa, mas, de preferência, qualquer ordem descrita e todos os equivalentes exemplificativos, independente da ordem, são contemplados pela descrição.
Além disso, deve-se entender que tais recursos não se limitam à execução serial, mas, de preferência, qualquer número de threads, processos, serviços, servidores, e/ou similares que possam executar de maneira assíncrona, concorrente, paralela, simultânea, síncrona, e/ou similares, são contemplados pela descrição.
Como isso, algumas destas características podem ser mutuamente contraditórias, pelo fato de que não podem estar simultaneamente presentes em uma única modalidade.
De maneira similar, algumas características são aplicáveis a um 5 aspecto das inovações, e inaplicáveis a outros.
Além disso, a descrição inclui outras inovações não presentemente reivindicadas.
O requerente reserva todos os direitos sobre estas inovações presentemente não reivindicadas, incluindo o direito de reivindicar tais inovações, depositar pedidos adicionais, continuações, continuações em parte, divisões, e/ou similares destes.
Como isso, deve-se entender que as vantagens, modalidades, 1O exemplos, aspectos funcionais, característicos, lógicos, operacionais, organizacionais, estruturais, topológicos e/ou outros aspectos da descrição não devem ser considerados limitações da descrição, conforme definido pelas reivindicações ou limitações dos equivalentes às reivindicações.
Deve-se entender que, dependendo das necessidades e/ou características particulares de um usuário individual e/ou empresarial UEP, a configuração de banco de dados e/ou modelo relacional, tipo de dados, transmissão de dados e/ou estrutura de rede, estrutura de sintaxe, e/ou similares, pode ser implementada em diversas modalidades do UEP que permitam uma grande flexibilidade e personalização.
Por exemplo, os aspectos do UEP podem ser adaptados à negociação financeira; segurança de operações; gerenciamento de recursos; e/ou similares.
Embora diversas modalidades e discussões do UEP tenham sido voltadas ao comércio eletrônico, entretanto, deve-se entender que as modalidades descritas no presente documento podem ser prontamente configuradas e/ou personalizadas para uma ampla variedade de outras aplicações e/ou implementações.

Claims (21)

REIVINDICAÇÕES
1. Método implementado por processador de compra de carteira virtual com múltiplos comerciantes, caracterizado pelo fato de que compreende: fornecer, a partir de um dispositivo de usuário, uma solicitação de pesquisa de 5 informações de produto; obter, em resposta à solicitação de pesquisa de informações de produto, informações sobre um primeiro produto à venda por um primeiro comerciante e um segundo produto à venda por um segundo comerciante; gerar uma única solicitação de transação de compra, utilizando as informações sobre 1O o primeiro produto à venda pelo primeiro comerciante e o segundo produto à venda pelo segundo comerciante; fornecer, através do dispositivo de usuário, a única solicitação de transação de compra para processamento de pagamento; e obter um recibo de compra eletrônico do primeiro produto à venda pelo primeiro comerciante e do segundo produto à venda pelo segundo comerciante.
2. Método, de acordo com a reivindicação 1, caracterizado pelo fato de que o dispositivo de usuário é um dispositivo móvel.
3. Método, de acordo com a reivindicação 1, caracterizado pelo fato de que a solicitação de pesquisa de informações de produto é gerada em resposta à entrada de uso de uma palavra-chave de pesquisa no aplicativo de carteira virtual.
4. Método, de acordo com a reivindicação 1, caracterizado pelo fato de que a solicitação de pesquisa de informações de produto é gerada utilizando informações sobre uma compra anterior através do aplicativo de carteira virtual.
5. Método, de acordo com a reivindicação 1, caracterizado pelo fato de que a solicitação de pesquisa de informações de produto é fornecida através de um aplicativo de carteira virtual que é executado no dispositivo de usuário.
6. Método, de acordo com a reivindicação 1, caracterizado pelo fato de que o primeiro comerciante e o segundo comerciante são diferentes.
7. Método, de acordo com a reivindicação 1, caracterizado pelo fato de que a solicitação de pesquisa de informações de produto inclui informações que identificam uma localização do dispositivo de usuário, bem como uma solicitação de informações de produto de comerciante nas proximidades do dispositivo de usuário.
8. Aparelho de compra de carteira virtual com múltiplos comerciantes, caracterizado pelo fato de que compreende: um processador; e uma memória disposta em comunicação com o processador e armazenando instruções executáveis por processador para:
fornecer, a partir de um dispositivo de usuário, uma solicitação de pesquisa de informações de produto; obter, em resposta à solicitação de pesquisa de informações de produto, informações sobre um primeiro produto à venda por um primeiro comerciante e um segundo 5 produto à venda por um segundo comerciante; gerar uma única solicitação de transação de compra, utilizando as informações sobre o primeiro produto à venda pelo primeiro comerciante e o segundo produto à venda pelo segundo comerciante; fornecer, através do dispositivo de usuário, a única solicitação de transação de 1O compra para processamento de pagamento; e obter um recibo de compra eletrônico do primeiro produto à venda pelo primeiro comerciante e do segundo produto à venda pelo segundo comerciante.
9. Aparelho, de acordo com a reivindicação 8, caracterizado pelo fato de que o dispositivo de usuário é um dispositivo móvel.
1 O. Aparelho, de acordo com a reivindicação 8, caracterizado pelo fato de que a solicitação de pesquisa de informações de produto é gerada em resposta à entrada de uso de uma palavra-chave de pesquisa no aplicativo de carteira virtual.
11. Aparelho, de acordo com a reivindicação 8, caracterizado pelo fato de que a solicitação de pesquisa de informações de produto é gerada utilizando informações sobre uma compra anterior através do aplicativo de carteira virtual.
12. Aparelho, de acordo com a reivindicação 8, caracterizado pelo fato de que a solicitação de pesquisa de informações de produto é fornecida através de um aplicativo de carteira virtual que é executado no dispositivo de usuário.
13. Aparelho, de acordo com a reivindicação 8, caracterizado pelo fato de que o primeiro comerciante e o segundo comerciante são diferentes.
14. Aparelho, de acordo com a reivindicação 8, caracterizado pelo fato de que a solicitação de pesquisa de informações de produto inclui informações que identificam uma localização do dispositivo de usuário, bem como uma solicitação de informações de produto de comerciante nas proximidades do dispositivo de usuário.
15. Meio tangível legível por processador, caracterizado pelo fato de que armazena instruções executáveis por processador de compra com carteira virtual de múltiplos comerciantes para: fornecer, a partir de um dispositivo de usuário, uma solicitação de pesquisa de informações de produto; obter, em resposta à solicitação de pesquisa de informações de produto, informações sobre um primeiro produto à venda por um primeiro comerciante e um segundo produto à venda por um segundo comerciante;
gerar uma única solicitação de transação de compra, utilizando as informações sobre o primeiro produto à venda pelo primeiro comerciante e o segundo produto à venda pelo segundo comerciante; fornecer, através do dispositivo de usuário, a única solicitação de transação de 5 compra para processamento de pagamento; e obter um recibo de compra eletrônico do primeiro produto à venda pelo primeiro comerciante e do segundo produto à venda pelo segundo comerciante.
16. Meio, de acordo com a reivindicação 15, caracterizado pelo fato de que o dispositivo de usuário é um dispositivo móvel.
17. Meio, de acordo com a reivindicação 15, caracterizado pelo fato de que a solicitação de pesquisa de informações de produto é gerada em resposta à entrada de uso de uma palavra-chave de pesquisa no aplicativo de carteira virtual.
18. Meio, de acordo com a reivindicação 15, caracterizado pelo fato de que a solicitação de pesquisa de informações de produto é gerada utilizando informações sobre uma compra anterior através do aplicativo de carteira virtual.
19. Meio, de acordo com a reivindicação 15, caracterizado pelo fato de que a solicitação de pesquisa de informações de produto é fornecida através de um aplicativo de carteira virtual que é executado no dispositivo de usuário.
20. Meio, de acordo com a reivindicação 15, caracterizado pelo fato de que o primeiro comerciante e o segundo comerciante são diferentes.
21. Meio, de acordo com a reivindicação 15, caracterizado pelo fato de que a solicitação de pesquisa de informações de produto inclui informações que identificam uma localização do dispositivo de usuário, bem como uma solicitação de informações de produto de comerciante nas proximidades do dispositivo de usuário.
BR112013021057-5A 2011-02-22 2012-02-22 aparelhos, métodos e sistemas de pagamento eletrônico universal BR112013021057A2 (pt)

Applications Claiming Priority (19)

Application Number Priority Date Filing Date Title
US201161445482P 2011-02-22 2011-02-22
US61/445,482 2011-02-22
US201161466409P 2011-03-22 2011-03-22
US61/466,409 2011-03-22
US201161469965P 2011-03-31 2011-03-31
US61/469,965 2011-03-31
US201161473728P 2011-04-08 2011-04-08
US61/473,728 2011-04-08
US201161538761P 2011-09-23 2011-09-23
US61/538,761 2011-09-23
US201161539969P 2011-09-27 2011-09-27
US61/539,969 2011-09-27
US201161545971P 2011-10-11 2011-10-11
US61/545,971 2011-10-11
US13/348,634 2012-01-11
US13/348,634 US20120233073A1 (en) 2011-01-11 2012-01-11 Universal Value Exchange Apparatuses, Methods and Systems
US13/398,817 US20120209749A1 (en) 2011-02-16 2012-02-16 Snap mobile payment apparatuses, methods and systems
US13/398,817 2012-02-16
PCT/US2012/026205 WO2012116125A1 (en) 2011-02-22 2012-02-22 Universal electronic payment apparatuses, methods and systems

Publications (1)

Publication Number Publication Date
BR112013021057A2 true BR112013021057A2 (pt) 2020-11-10

Family

ID=48221724

Family Applications (1)

Application Number Title Priority Date Filing Date
BR112013021057-5A BR112013021057A2 (pt) 2011-02-22 2012-02-22 aparelhos, métodos e sistemas de pagamento eletrônico universal

Country Status (7)

Country Link
US (2) US10223691B2 (pt)
EP (1) EP2678812A4 (pt)
CN (1) CN103635920A (pt)
AU (2) AU2012220669A1 (pt)
BR (1) BR112013021057A2 (pt)
SG (1) SG193510A1 (pt)
WO (1) WO2012116125A1 (pt)

Families Citing this family (236)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US10862994B1 (en) * 2006-11-15 2020-12-08 Conviva Inc. Facilitating client decisions
US8874725B1 (en) 2006-11-15 2014-10-28 Conviva Inc. Monitoring the performance of a content player
US9177313B1 (en) * 2007-10-18 2015-11-03 Jpmorgan Chase Bank, N.A. System and method for issuing, circulating and trading financial instruments with smart features
US9100288B1 (en) * 2009-07-20 2015-08-04 Conviva Inc. Augmenting the functionality of a content player
US9691055B2 (en) 2010-12-17 2017-06-27 Google Inc. Digital wallet
US20120209749A1 (en) * 2011-02-16 2012-08-16 Ayman Hammad Snap mobile payment apparatuses, methods and systems
US10586227B2 (en) 2011-02-16 2020-03-10 Visa International Service Association Snap mobile payment apparatuses, methods and systems
CN103635920A (zh) 2011-02-22 2014-03-12 维萨国际服务协会 通用电子付款装置、方法与系统
US9582598B2 (en) 2011-07-05 2017-02-28 Visa International Service Association Hybrid applications utilizing distributed models and views apparatuses, methods and systems
US20130159154A1 (en) * 2011-08-18 2013-06-20 Thomas Purves Wallet service enrollment platform apparatuses, methods and systems
US9355393B2 (en) 2011-08-18 2016-05-31 Visa International Service Association Multi-directional wallet connector apparatuses, methods and systems
AU2012278963B2 (en) 2011-07-05 2017-02-23 Visa International Service Association Electronic wallet checkout platform apparatuses, methods and systems
WO2013022999A1 (en) * 2011-08-08 2013-02-14 Bloomberg Finance Lp System and method for electronic distribution of software and data
US9710807B2 (en) * 2011-08-18 2017-07-18 Visa International Service Association Third-party value added wallet features and interfaces apparatuses, methods and systems
US10825001B2 (en) 2011-08-18 2020-11-03 Visa International Service Association Multi-directional wallet connector apparatuses, methods and systems
US10242358B2 (en) 2011-08-18 2019-03-26 Visa International Service Association Remote decoupled application persistent state apparatuses, methods and systems
US10223730B2 (en) 2011-09-23 2019-03-05 Visa International Service Association E-wallet store injection search apparatuses, methods and systems
CA2862020C (en) * 2012-01-19 2018-03-20 Mastercard International Incorporated System and method to enable a network of digital wallets
AU2013214801B2 (en) 2012-02-02 2018-06-21 Visa International Service Association Multi-source, multi-dimensional, cross-entity, multimedia database platform apparatuses, methods and systems
EP2634738A1 (en) * 2012-03-02 2013-09-04 Alcatel Lucent Decentralized electronic transfer system
SG193649A1 (en) * 2012-03-08 2013-10-30 Wee Ping Chua A consolidated merchant programs system
US10453105B2 (en) * 2012-03-30 2019-10-22 Ent. Services Development Corporation Lp Encrypted payment image
US9477984B2 (en) * 2012-05-05 2016-10-25 Soldsie, Inc. Social media transactions system and methods
US9818093B1 (en) * 2012-06-14 2017-11-14 Amazon Technologies, Inc. Third party check-in associations with cloud wallet
US10373184B1 (en) 2012-06-18 2019-08-06 Groupon, Inc. Facilitating consumer payments and redemptions of deal offers
US9053312B2 (en) 2012-06-19 2015-06-09 Paychief, Llc Methods and systems for providing bidirectional authentication
US11899711B2 (en) 2012-06-19 2024-02-13 Ondot Systems Inc. Merchant logo detection artificial intelligence (AI) for injecting user control to ISO back-end transaction approvals between acquirer processors and issuer processors over data communication networks
US11636489B2 (en) 2013-10-19 2023-04-25 Ondot Systems Inc. System and method for authorizing a transaction based on dynamic location updates from a user device
US20190147450A1 (en) 2012-06-19 2019-05-16 Ondot System Real-time enrichment of raw merchant data from iso transactions on data communication networks for preventing false declines in fraud prevention systems
US20130346291A1 (en) * 2012-06-22 2013-12-26 Paychief Llc Systems and methods for purchasing products or services through the use of a symbology
US8997184B2 (en) 2012-06-22 2015-03-31 Paychief Llc Systems and methods for providing a one-time authorization
US20140006219A1 (en) * 2012-06-29 2014-01-02 Rita H. Wouhaybi Counteroffer generation service
US20150199751A1 (en) * 2012-08-07 2015-07-16 Twentieth Century Fox Home Entertainment Llc System and method for a virtual storefront
US10552919B2 (en) * 2012-08-08 2020-02-04 International Business Machines Corporation Conducting various actions indicated by a financial card
US9246965B1 (en) 2012-09-05 2016-01-26 Conviva Inc. Source assignment based on network partitioning
US10182096B1 (en) 2012-09-05 2019-01-15 Conviva Inc. Virtual resource locator
KR101943319B1 (ko) * 2012-09-13 2019-01-29 엘지전자 주식회사 이동 단말기 및 이의 제어 방법
AU2013334480A1 (en) * 2012-10-23 2015-06-04 Jenand (Vic) Pty Ltd Mobile payments
US10528385B2 (en) * 2012-12-13 2020-01-07 Microsoft Technology Licensing, Llc Task completion through inter-application communication
US9313162B2 (en) 2012-12-13 2016-04-12 Microsoft Technology Licensing, Llc Task completion in email using third party app
US10380583B1 (en) 2012-12-17 2019-08-13 Wells Fargo Bank, N.A. System and method for interoperable mobile wallet
CN103971243A (zh) * 2013-01-25 2014-08-06 乐金信世股份有限公司 电子交易文档
US9978099B2 (en) * 2013-01-30 2018-05-22 Capital One Financial Corporation System and method for providing purchase history to an account holder
US20140249885A1 (en) * 2013-03-04 2014-09-04 Catalina Marketing Corporation System and method for customized search results based on a shopping history of a user, retailer identifications, and items being promoted by retailers
US9934523B1 (en) 2013-03-05 2018-04-03 Square, Inc. On-device directory search
US20140279426A1 (en) * 2013-03-15 2014-09-18 Elwha Llc Devices, methods, and systems for technologically shifting options and modalities
US10909590B2 (en) 2013-03-15 2021-02-02 Square, Inc. Merchant and item ratings
KR101761882B1 (ko) * 2013-05-16 2017-07-26 한국전자통신연구원 클라우드 ｉｄ 카드를 이용하여 개인 정보를 제공하기 위한 시스템 및 그 방법
US20160224950A1 (en) * 2015-02-02 2016-08-04 Michael J. Attar Method for Consolidating Multiple Merchants Under a Common Merchant Payment System
US20140379578A1 (en) * 2013-06-20 2014-12-25 Mastercard International Incorporated Method and system for conducting on-behalf electronic financial transaction
US20150025919A1 (en) * 2013-07-17 2015-01-22 Alan West Notification System
US10346822B2 (en) * 2013-08-23 2019-07-09 Visa International Service Association Dynamic account selection
US20150081545A1 (en) * 2013-09-18 2015-03-19 Greg Gissler Secure payment by mobile phone
US11216871B2 (en) * 2013-09-27 2022-01-04 Insperity Services, L.P. Method, apparatus and system for automated funding
CN104574050B (zh) 2013-10-28 2018-09-07 腾讯科技（深圳）有限公司 在线结算的方法、装置及系统
US20150120462A1 (en) * 2013-10-29 2015-04-30 Tencent Technology (Shenzhen) Company Limited Method And System For Pushing Merchandise Information
US10088973B2 (en) * 2013-11-08 2018-10-02 Google Llc Event scheduling presentation in a graphical user interface environment
US10810682B2 (en) 2013-12-26 2020-10-20 Square, Inc. Automatic triggering of receipt delivery
US9654571B2 (en) * 2014-01-21 2017-05-16 Time Warner Cable Enterprises Llc Publish-subscribe messaging in a content network
US9635108B2 (en) 2014-01-25 2017-04-25 Q Technologies Inc. Systems and methods for content sharing using uniquely generated idenifiers
SG2014008932A (en) * 2014-02-06 2015-09-29 Mastercard Asia Pacific Pte Ltd A method and a corresponding proxy server, system, computer-readable storage medium and computer program
US9647999B2 (en) 2014-02-07 2017-05-09 Bank Of America Corporation Authentication level of function bucket based on circumstances
US9223951B2 (en) 2014-02-07 2015-12-29 Bank Of America Corporation User authentication based on other applications
US9965606B2 (en) 2014-02-07 2018-05-08 Bank Of America Corporation Determining user authentication based on user/device interaction
US9208301B2 (en) 2014-02-07 2015-12-08 Bank Of America Corporation Determining user authentication requirements based on the current location of the user in comparison to the users's normal boundary of location
US9286450B2 (en) 2014-02-07 2016-03-15 Bank Of America Corporation Self-selected user access based on specific authentication types
US9830597B2 (en) 2014-03-04 2017-11-28 Bank Of America Corporation Formation and funding of a shared token
US9600817B2 (en) 2014-03-04 2017-03-21 Bank Of America Corporation Foreign exchange token
US9406065B2 (en) 2014-03-04 2016-08-02 Bank Of America Corporation Customer token preferences interface
US9721268B2 (en) 2014-03-04 2017-08-01 Bank Of America Corporation Providing offers associated with payment credentials authenticated in a specific digital wallet
US9424572B2 (en) * 2014-03-04 2016-08-23 Bank Of America Corporation Online banking digital wallet management
US9600844B2 (en) 2014-03-04 2017-03-21 Bank Of America Corporation Foreign cross-issued token
US10002352B2 (en) 2014-03-04 2018-06-19 Bank Of America Corporation Digital wallet exposure reduction
US9721248B2 (en) 2014-03-04 2017-08-01 Bank Of America Corporation ATM token cash withdrawal
US9495670B2 (en) 2014-03-10 2016-11-15 Square, Inc. Quick legend receipt system
US10692064B2 (en) 2014-03-19 2020-06-23 Square, Inc. Merchant platform
US20150278783A1 (en) 2014-03-31 2015-10-01 Comr.Se Corp. Native e-commerce transactables for familiar user environments
US11429948B2 (en) * 2014-04-15 2022-08-30 Capital One Services, Llc System and method for inter-bank and intra-bank mobile banking communications and transfers
US10346846B2 (en) * 2014-04-24 2019-07-09 Swoop Ip Holdings Llc SMS and social media dual authorization, management oversight, and non-password security in email based e-commerce
US11610197B1 (en) 2014-04-30 2023-03-21 Wells Fargo Bank, N.A. Mobile wallet rewards redemption systems and methods
US11461766B1 (en) 2014-04-30 2022-10-04 Wells Fargo Bank, N.A. Mobile wallet using tokenized card systems and methods
US11615401B1 (en) 2014-04-30 2023-03-28 Wells Fargo Bank, N.A. Mobile wallet authentication systems and methods
US11748736B1 (en) 2014-04-30 2023-09-05 Wells Fargo Bank, N.A. Mobile wallet integration within mobile banking
US11288660B1 (en) 2014-04-30 2022-03-29 Wells Fargo Bank, N.A. Mobile wallet account balance systems and methods
US9652770B1 (en) 2014-04-30 2017-05-16 Wells Fargo Bank, N.A. Mobile wallet using tokenized card systems and methods
US10997592B1 (en) 2014-04-30 2021-05-04 Wells Fargo Bank, N.A. Mobile wallet account balance systems and methods
US20150348024A1 (en) * 2014-06-02 2015-12-03 American Express Travel Related Services Company, Inc. Systems and methods for provisioning transaction data to mobile communications devices
US10445739B1 (en) 2014-08-14 2019-10-15 Wells Fargo Bank, N.A. Use limitations for secondary users of financial accounts
FR3025910B1 (fr) * 2014-09-15 2016-11-11 Bull Sas Procede d'archivage de donnees relatives a un utilisateur
US9449318B2 (en) * 2014-10-01 2016-09-20 Paypal, Inc. Systems and methods for providing payment hotspots
US9697517B1 (en) * 2014-10-03 2017-07-04 State Farm Mutual Automobile Insurance Company Token generation in providing a secure credit card payment service without storing credit card data on merchant servers
TWI612431B (zh) * 2014-10-03 2018-01-21 物聯智慧科技（深圳）有限公司 對等網路裝置社群之搜尋系統、搜尋方法及其對等網路裝置
US9692752B2 (en) 2014-11-17 2017-06-27 Bank Of America Corporation Ensuring information security using one-time tokens
US9928371B2 (en) 2014-11-19 2018-03-27 Papal, Inc. Systems and methods for protecting information displayed on a user interface of a device
US10359914B2 (en) * 2014-11-25 2019-07-23 Sap Se Dynamic data source binding
US10305955B1 (en) 2014-12-08 2019-05-28 Conviva Inc. Streaming decision in the cloud
US10178043B1 (en) 2014-12-08 2019-01-08 Conviva Inc. Dynamic bitrate range selection in the cloud for optimized video streaming
US9886598B2 (en) * 2014-12-29 2018-02-06 Paypal, Inc. Automatic adjustment of a display to obscure data
US20180005213A1 (en) * 2015-02-23 2018-01-04 Kojo Benjamin Dickson Quartey The automated salesman machine (asm)/automated electronic trolley (aet)
US11853919B1 (en) * 2015-03-04 2023-12-26 Wells Fargo Bank, N.A. Systems and methods for peer-to-peer funds requests
KR102410264B1 (ko) * 2015-03-26 2022-06-17 에스케이플래닛 주식회사 원바코드 서비스 제공 방법, 이를 위한 시스템
CN106156130B (zh) * 2015-04-09 2019-11-12 阿里巴巴集团控股有限公司 一种数据处理方法及装置
US20160321637A1 (en) * 2015-04-30 2016-11-03 Kevin Carvalho Point of sale payment using mobile device and checkout credentials
US9824351B2 (en) 2015-05-27 2017-11-21 Bank Of America Corporation Providing access to account information using authentication tokens
US9830591B2 (en) 2015-05-27 2017-11-28 Bank Of America Corporation Providing access to account information using authentication tokens
WO2016197115A1 (en) * 2015-06-05 2016-12-08 Arris Enterprises Llc Virtual wallet for set-top-box
USD769296S1 (en) * 2015-07-27 2016-10-18 Qondado Llc Display screen or portion thereof with graphical user interface
US10853317B2 (en) * 2015-08-07 2020-12-01 Adp, Llc Data normalizing system
CA2999776A1 (en) * 2015-09-23 2017-03-30 Mroute Corp. System and method for settling multiple payees from a single electronic and/or check payment
EP3147853A1 (en) * 2015-09-23 2017-03-29 Mastercard International Incorporated Transaction control
US9928372B2 (en) 2015-10-23 2018-03-27 Paypal, Inc. Selective screen privacy
US9729536B2 (en) 2015-10-30 2017-08-08 Bank Of America Corporation Tiered identification federated authentication network system
CN105512880A (zh) * 2015-12-08 2016-04-20 努比亚技术有限公司 无线支付装置和方法
US10489777B2 (en) * 2016-01-05 2019-11-26 Visa International Service Association Universal access to an electronic wallet
US10977639B2 (en) 2016-01-25 2021-04-13 Freelancer Technology Pty Limited Adaptive gateway switching system
CN105682253A (zh) 2016-03-02 2016-06-15 上海小蚁科技有限公司 建立通信的方法、设备、终端和计算机可读存储介质
KR20170112569A (ko) * 2016-03-31 2017-10-12 삼성전자주식회사 상품 결제 방법 및 이를 지원하는 전자 장치
US20170300896A1 (en) * 2016-04-13 2017-10-19 Paypal, Inc. Omni-channel data processing using hierarchical vault data structures
US20170300894A1 (en) * 2016-04-13 2017-10-19 Mastercard International Incorporated System and method for providing reports on usage of payment token
US9715793B1 (en) 2016-04-15 2017-07-25 Bank Of America Corporation Banking systems controlled by data bearing records
US9792752B1 (en) 2016-04-15 2017-10-17 Bank Of America Corporation Banking systems controlled by data bearing records
US9747758B1 (en) 2016-04-15 2017-08-29 Bank Of America Corporation Banking systems controlled by data bearing records
US10460367B2 (en) 2016-04-29 2019-10-29 Bank Of America Corporation System for user authentication based on linking a randomly generated number to the user and a physical item
US20180114268A1 (en) * 2016-05-10 2018-04-26 Hassan S. Abhari Methods and apparatus for conducting trade exchange purchase and sale transactions using partial virtual currency and partial cash payments
JP6813281B2 (ja) 2016-05-23 2021-01-13 東芝テック株式会社 チェックアウトシステム
US9836772B1 (en) * 2016-06-01 2017-12-05 Jane Technologies, Inc. Real-time internet capable device information interchange for coordinated queuing at locations
US10572870B1 (en) 2016-06-09 2020-02-25 Wells Fargo Bank, N.A. Binding mobile wallet elements with payees
US10268635B2 (en) 2016-06-17 2019-04-23 Bank Of America Corporation System for data rotation through tokenization
GB2556337A (en) * 2016-09-20 2018-05-30 Gelliner Ltd Bill payment system and method
US10587628B2 (en) * 2016-09-29 2020-03-10 Microsoft Technology Licensing, Llc Verifiable outsourced ledgers
US11468414B1 (en) 2016-10-03 2022-10-11 Wells Fargo Bank, N.A. Systems and methods for establishing a pull payment relationship
US11645697B2 (en) * 2016-10-06 2023-05-09 Bread Financial Payments, Inc. Simple checkout
US10839325B2 (en) 2016-11-06 2020-11-17 Microsoft Technology Licensing, Llc Efficiency enhancements in task management applications
US10212157B2 (en) 2016-11-16 2019-02-19 Bank Of America Corporation Facilitating digital data transfers using augmented reality display devices
US10158634B2 (en) 2016-11-16 2018-12-18 Bank Of America Corporation Remote document execution and network transfer using augmented reality display devices
US20180150810A1 (en) * 2016-11-29 2018-05-31 Bank Of America Corporation Contextual augmented reality overlays
US10943229B2 (en) 2016-11-29 2021-03-09 Bank Of America Corporation Augmented reality headset and digital wallet
US10600111B2 (en) 2016-11-30 2020-03-24 Bank Of America Corporation Geolocation notifications using augmented reality user devices
US10685386B2 (en) 2016-11-30 2020-06-16 Bank Of America Corporation Virtual assessments using augmented reality user devices
US10339583B2 (en) 2016-11-30 2019-07-02 Bank Of America Corporation Object recognition and analysis using augmented reality user devices
US10586220B2 (en) 2016-12-02 2020-03-10 Bank Of America Corporation Augmented reality dynamic authentication
US10311223B2 (en) 2016-12-02 2019-06-04 Bank Of America Corporation Virtual reality dynamic authentication
US10607230B2 (en) 2016-12-02 2020-03-31 Bank Of America Corporation Augmented reality dynamic authentication for electronic transactions
US10481862B2 (en) 2016-12-02 2019-11-19 Bank Of America Corporation Facilitating network security analysis using virtual reality display devices
US10109095B2 (en) 2016-12-08 2018-10-23 Bank Of America Corporation Facilitating dynamic across-network location determination using augmented reality display devices
US10109096B2 (en) 2016-12-08 2018-10-23 Bank Of America Corporation Facilitating dynamic across-network location determination using augmented reality display devices
US10217375B2 (en) 2016-12-13 2019-02-26 Bank Of America Corporation Virtual behavior training using augmented reality user devices
US10210767B2 (en) 2016-12-13 2019-02-19 Bank Of America Corporation Real world gamification using augmented reality user devices
CN108255535A (zh) * 2016-12-28 2018-07-06 乐视汽车（北京）有限公司 车机升级方法和车机
CN108256848A (zh) * 2016-12-29 2018-07-06 北京京东尚科信息技术有限公司 一种电子商品的充值方法和装置
US10762495B2 (en) * 2016-12-30 2020-09-01 Square, Inc. Third-party access to secure hardware
WO2018140828A1 (en) 2017-01-27 2018-08-02 Visa International Service Association Browser extension for client-side tokenized authentication
CN110476177A (zh) * 2017-02-06 2019-11-19 维萨国际服务协会 物联网商家订单和支付实现
US10679232B2 (en) * 2017-02-14 2020-06-09 International Business Machines Corporation Real-time product selection guidance for conditional sales
US10810556B2 (en) * 2017-02-24 2020-10-20 Mastercard International Incorporated Systems and methods for managing receipts for payment account transactions
CN107169895A (zh) * 2017-03-31 2017-09-15 中国认证认可协会 基于顾客体验感知的服务认证多方参与协查系统
US11127018B2 (en) * 2017-03-31 2021-09-21 Ncr Corporation Secure access-based resource delegation
US10656190B2 (en) * 2017-04-13 2020-05-19 Oracle International Corporation Non-parametric statistical behavioral identification ecosystem for electricity fraud detection
SG10201703299TA (en) * 2017-04-21 2018-11-29 Mastercard Asia Pacific Pte Ltd A system and method for carrying out two factor authentication using augmented/virtual reality
USD826955S1 (en) 2017-04-28 2018-08-28 Qondado Llc Display screen or portion thereof with graphical user interface
AU2018267278A1 (en) 2017-05-12 2019-11-07 Bae Systems Plc A system for improved data storage and retrieval
WO2018206974A1 (en) 2017-05-12 2018-11-15 Bae Systems Plc A system for improved data storage and retrieval
WO2018206975A1 (en) * 2017-05-12 2018-11-15 Bae Systems Plc A system for improved data storage and retrieval
KR101879416B1 (ko) * 2017-06-12 2018-07-18 고려대학교 산학협력단 이상 금융거래 탐지 방법 및 그 전자 장치
US10511692B2 (en) 2017-06-22 2019-12-17 Bank Of America Corporation Data transmission to a networked resource based on contextual information
US10313480B2 (en) 2017-06-22 2019-06-04 Bank Of America Corporation Data transmission between networked resources
US10524165B2 (en) 2017-06-22 2019-12-31 Bank Of America Corporation Dynamic utilization of alternative resources based on token association
US11144894B2 (en) * 2017-09-28 2021-10-12 DineGigs Inc. Multi-level network-based access coordination
US20190108535A1 (en) * 2017-10-05 2019-04-11 Netsolace, Inc. Self-review systems and methods
US11503015B2 (en) * 2017-10-12 2022-11-15 Mx Technologies, Inc. Aggregation platform portal for displaying and updating data for third-party service providers
CN107993118A (zh) * 2017-11-01 2018-05-04 浙江圣地物联科技有限公司 一种基于共享系统关联用户信息的方法
US11436585B2 (en) * 2017-12-19 2022-09-06 American Express Travel Related Services Company, Inc. Virtual point of sale
EP3502993A1 (en) * 2017-12-22 2019-06-26 Mastercard International Incorporated A method and system for conducting a transaction
US10977659B2 (en) * 2017-12-22 2021-04-13 Visa International Service Association Real-time monitoring system
US11055790B2 (en) * 2018-01-29 2021-07-06 Mastercard International Incorporated Systems and methods for providing an indication of local sales tax rates to a user
US11295297B1 (en) 2018-02-26 2022-04-05 Wells Fargo Bank, N.A. Systems and methods for pushing usable objects and third-party provisioning to a mobile wallet
CN108551468B (zh) * 2018-03-15 2020-12-29 宇宙世代信息技术（深圳）有限公司 基于账户视角切换的信息推送方法及系统
US20220172179A1 (en) * 2018-03-30 2022-06-02 Block, Inc. Itemized digital receipts
US11301838B2 (en) * 2018-05-09 2022-04-12 Mastercard International Incorporated Systems and methods for using network extensions
US11775955B1 (en) 2018-05-10 2023-10-03 Wells Fargo Bank, N.A. Systems and methods for making person-to-person payments via mobile client application
US11074577B1 (en) 2018-05-10 2021-07-27 Wells Fargo Bank, N.A. Systems and methods for making person-to-person payments via mobile client application
KR102306960B1 (ko) * 2018-08-17 2021-09-30 김금철 Url매체와 서버 등을 이용한 결제 및 충전시스템
WO2020041145A1 (en) * 2018-08-20 2020-02-27 Hutchinson Shawn Scheduling, booking, and pricing engines
USD969816S1 (en) * 2018-10-01 2022-11-15 Caterpillar Paving Products Inc. Display screen or portion thereof having a graphical user interface
JP7231378B2 (ja) * 2018-10-26 2023-03-01 東芝テック株式会社 情報処理装置及びその制御プログラム
SG10201810001YA (en) 2018-11-09 2020-06-29 Mastercard International Inc Payment methods and systems by scanning qr codes already present in a user device
CN110012048B (zh) 2018-11-22 2021-11-12 创新先进技术有限公司 信息识别码生成方法、装置、电子设备及计算机存储介质
FR3090934A1 (fr) * 2018-12-21 2020-06-26 Orange Procédé et système de sécurisation d’opérations, et poste utilisateur associé
US11922489B2 (en) 2019-02-11 2024-03-05 A9.Com, Inc. Curated environments for augmented reality applications
US10909523B2 (en) 2019-02-25 2021-02-02 Capital One Services, Llc Generation of a combinatorial payment QR code
US11250462B2 (en) 2019-04-18 2022-02-15 Benjamin D. Smith System and method for trading and tracking digitized coupons
CN111861452A (zh) * 2019-04-30 2020-10-30 中国银联股份有限公司 聚合支付方法和系统
US11663602B2 (en) * 2019-05-15 2023-05-30 Jpmorgan Chase Bank, N.A. Method and apparatus for real-time fraud machine learning model execution module
US20220230230A1 (en) * 2019-05-20 2022-07-21 Rezolve Ltd. Initiating requests in response to triggers on client
CN110619086B (zh) * 2019-05-23 2022-02-25 北京无限光场科技有限公司 用于处理信息的方法和装置
CN110197367B (zh) * 2019-05-31 2021-12-21 四川长虹电器股份有限公司 基于电商平台的大数据量自动结算方法
US11551190B1 (en) 2019-06-03 2023-01-10 Wells Fargo Bank, N.A. Instant network cash transfer at point of sale
US10839369B1 (en) 2019-07-22 2020-11-17 Capital One Services, Llc Dynamic electronic communication with variable messages using encrypted quick response codes
US11036802B2 (en) * 2019-08-05 2021-06-15 Morgan Stanley Services Group Inc. Classification rules engine and API generator
US11282118B2 (en) * 2019-09-17 2022-03-22 Salesforce.Com, Inc. Order management user interface
CN111061785B (zh) * 2019-10-23 2022-03-25 深圳智慧园区信息技术有限公司 一种管理平台中订单的分类存储方法和系统
WO2021091415A1 (ru) * 2019-11-08 2021-05-14 Публичное Акционерное Общество "Сбербанк России" Способ и система авторизации пользователя
MX2019014846A (es) * 2019-12-09 2020-02-12 Todito Pagos S A De C V Metodo y sistema para acreditar un premio en una cuenta de monedero electronico.
RU2754083C2 (ru) * 2019-12-09 2021-08-26 Ильмира Рафилевна Сулейманова Способ проведения платежной транзакции с использованием систем мгновенного обмена сообщениями и файлами
US20210182842A1 (en) * 2019-12-17 2021-06-17 Toshiba Tec Kabushiki Kaisha Information processing device and control program for information processing device
KR20220106824A (ko) * 2020-01-08 2022-07-29 로브록스 코포레이션 전자 구독 지불의 사기 탐지
US11097192B2 (en) 2020-01-08 2021-08-24 Roblox Corporation Fraud detection in electronic subscription payments
US20210312528A1 (en) * 2020-04-01 2021-10-07 Capital One Services, Llc System, method and computer-accessible medium for repeating prior purchases
US11455606B2 (en) * 2020-04-30 2022-09-27 Capital One Services, Llc Tap to pay a credit bill via a computing device
US11823175B2 (en) * 2020-04-30 2023-11-21 Capital One Services, Llc Intelligent card unlock
WO2021226335A1 (en) * 2020-05-08 2021-11-11 Aldelo, LP Virtual gift cards with instant delivery and secured remote redemption
CN113890944B (zh) * 2020-07-03 2023-07-21 中移互联网有限公司 一种通话方法、系统和装置
USD946594S1 (en) * 2020-07-20 2022-03-22 Bank Of America Corporation Device display screen with graphical user interface for payments
USD930702S1 (en) 2020-09-03 2021-09-14 Wepay Global Payments Llc Display screen portion with animated graphical user interface
USD931899S1 (en) 2020-09-03 2021-09-28 Etla, Llc Display screen portion with animated graphical user interface
USD931330S1 (en) 2020-09-05 2021-09-21 Wepay Global Payments Llc Display screen portion with animated graphical user interface
WO2022074569A1 (en) * 2020-10-05 2022-04-14 Securter Systems Inc. Unattended mobile point of sale system
US20220129895A1 (en) * 2020-10-28 2022-04-28 Piggy Llc Secure transaction process utilizing integration layer
CN114490698A (zh) * 2020-10-28 2022-05-13 北京中祥英科技有限公司 产品履历查询方法、装置、设备及介质
US11720886B2 (en) 2021-03-04 2023-08-08 The Toronto-Dominion Bank System and method for generating notifications based on digital wallet pass data
US20220358489A1 (en) * 2021-05-10 2022-11-10 Core Scientific Operating Company Cost management in distributed computing teams
US11790353B2 (en) * 2021-06-16 2023-10-17 Song Hwan KIM System and method for online/offline payment with virtual currency for nodes included in mobile-based blockchain distributed network
US11232514B1 (en) 2021-06-23 2022-01-25 Phinge Corporation System and method of providing auctions and real-time bidding for users of platforms operating on a rewards-based, universal, integrated code base
US11282174B1 (en) * 2021-06-23 2022-03-22 Phinge Corporation System and method of providing privacy by blurring images of people in unauthorized photos and videos
US11861693B2 (en) * 2021-07-30 2024-01-02 Ramp Business Corporation User interface for recurring transaction management
US11687519B2 (en) 2021-08-11 2023-06-27 T-Mobile Usa, Inc. Ensuring availability and integrity of a database across geographical regions
USD989097S1 (en) 2021-09-16 2023-06-13 FedNow Cash Consortium Display screen portion with animated graphical user interface
USD1001153S1 (en) 2021-09-16 2023-10-10 PocktBank Corporation Display screen portion with animated graphical user interface
USD997185S1 (en) 2021-09-16 2023-08-29 7ollar Corp FedNow IP Holdings Display screen portion with animated graphical user interface
USD991955S1 (en) 2021-09-16 2023-07-11 ACH Direct LLC Display screen portion with animated graphical user interface
USD945453S1 (en) 2021-09-16 2022-03-08 Fintech Innovation Associates Llc Display screen portion with animated graphical user interface
USD993265S1 (en) 2021-09-20 2023-07-25 CardPay NCUA Licensing Group Display screen portion with animated graphical user interface
US20230093871A1 (en) * 2021-09-30 2023-03-30 Expensify, Inc. Computing system implementing automated transaction execution based on messaging triggers
CN114140888B (zh) * 2021-12-08 2023-11-03 浙江浙石油综合能源销售有限公司 一种基于etc端云协同的油站无感支付方法及系统
US11748721B1 (en) * 2022-03-14 2023-09-05 Andre Temnorod Procuring and presenting deposit transaction details
US11716290B1 (en) 2022-05-12 2023-08-01 Bank Of America Corporation Electronic system for dynamic linking of resource data structures across distributed networks

Family Cites Families (1169)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US789106A (en) 1904-10-29 1905-05-02 Howard Preston Tweed Combined cash-slip and refunding-voucher.
US4896363A (en) 1987-05-28 1990-01-23 Thumbscan, Inc. Apparatus and method for matching image characteristics such as fingerprint minutiae
US5237164A (en) 1989-05-12 1993-08-17 Sony Corporation Card having retroreflective bar codes and a magnetic stripe
US5459656A (en) 1989-09-12 1995-10-17 Park City Group, Inc. Business demand projection system and method
US5177342A (en) 1990-11-09 1993-01-05 Visa International Service Association Transaction approval system
US5221838A (en) 1990-12-24 1993-06-22 Motorola, Inc. Electronic wallet
US5383113A (en) 1991-07-25 1995-01-17 Checkfree Corporation System and method for electronically providing customer services including payment of bills, financial analysis and loans
CA2078246C (en) 1991-09-23 1998-02-03 Randolph J. Pilc Improved method for secure access control
US5446890A (en) 1991-11-27 1995-08-29 Hewlett-Packard Company System for using subsets of rules applied to a database for updating and generating the rule knowledge base and forecasts of system demand
US5384449A (en) 1992-04-28 1995-01-24 Visa International Service Association Authorization matching system
US5311594A (en) 1993-03-26 1994-05-10 At&T Bell Laboratories Fraud protection for card transactions
US7082426B2 (en) 1993-06-18 2006-07-25 Cnet Networks, Inc. Content aggregation method and apparatus for an on-line product catalog
US5649118A (en) 1993-08-27 1997-07-15 Lucent Technologies Inc. Smart card with multiple charge accounts and product item tables designating the account to debit
US5526409A (en) 1993-10-26 1996-06-11 Visa International Service Association Adaptive communication system within a transaction card network
US5500513A (en) 1994-05-11 1996-03-19 Visa International Automated purchasing control system
CN1057178C (zh) 1994-05-19 2000-10-04 黄金富 非现金即时付款的防盗保全的方法和设备系统
US5521362A (en) 1994-06-08 1996-05-28 Mci Communications Corporation Electronic purse card having multiple storage memories to prevent fraudulent usage and method therefor
US5590038A (en) 1994-06-20 1996-12-31 Pitroda; Satyan G. Universal electronic transaction card including receipt storage and system and methods of conducting electronic transactions
US6925439B1 (en) 1994-06-20 2005-08-02 C-Sam, Inc. Device, system and methods of conducting paperless transactions
US5640193A (en) 1994-08-15 1997-06-17 Lucent Technologies Inc. Multimedia service access by reading marks on an object
US5655007A (en) 1994-10-13 1997-08-05 Bell Atlantic Network Services, Inc. Telephone based credit card protection
US5748737A (en) 1994-11-14 1998-05-05 Daggar; Robert N. Multimedia electronic wallet with generic card
US5613012A (en) 1994-11-28 1997-03-18 Smarttouch, Llc. Tokenless identification system for authorization of electronic transactions and electronic transmissions
US5536045A (en) 1994-12-28 1996-07-16 Adams; Thomas W. Debit/credit card system having primary utility in replacing food stamps
US5530438A (en) 1995-01-09 1996-06-25 Motorola, Inc. Method of providing an alert of a financial transaction
US6321208B1 (en) 1995-04-19 2001-11-20 Brightstreet.Com, Inc. Method and system for electronic distribution of product redemption coupons
US5708422A (en) 1995-05-31 1998-01-13 At&T Transaction authorization and alert system
US5615264A (en) 1995-06-08 1997-03-25 Wave Systems Corp. Encrypted data package record for use in remote transaction metered data system
US5790677A (en) 1995-06-29 1998-08-04 Microsoft Corporation System and method for secure electronic commerce transactions
US5794221A (en) 1995-07-07 1998-08-11 Egendorf; Andrew Internet billing method
US5796832A (en) 1995-11-13 1998-08-18 Transaction Technology, Inc. Wireless transaction and information system
US5781438A (en) 1995-12-19 1998-07-14 Pitney Bowes Inc. Token generation process in an open metering system
US5822737A (en) 1996-02-05 1998-10-13 Ogram; Mark E. Financial transaction system
US6044360A (en) 1996-04-16 2000-03-28 Picciallo; Michael J. Third party credit card
US5815657A (en) 1996-04-26 1998-09-29 Verifone, Inc. System, method and article of manufacture for network electronic authorization utilizing an authorization instrument
US5963924A (en) 1996-04-26 1999-10-05 Verifone, Inc. System, method and article of manufacture for the use of payment instrument holders and payment instruments in network electronic commerce
US6439345B1 (en) 1996-05-22 2002-08-27 Sears, Roebuck And Co. Item pick-up system
US7555458B1 (en) 1996-06-05 2009-06-30 Fraud Control System.Com Corporation Method of billing a purchase made over a computer network
US8229844B2 (en) 1996-06-05 2012-07-24 Fraud Control Systems.Com Corporation Method of billing a purchase made over a computer network
US5892838A (en) 1996-06-11 1999-04-06 Minnesota Mining And Manufacturing Company Biometric recognition using a classification neural network
US5850446A (en) 1996-06-17 1998-12-15 Verifone, Inc. System, method and article of manufacture for virtual point of sale processing utilizing an extensible, flexible architecture
US5943624A (en) 1996-07-15 1999-08-24 Motorola, Inc. Contactless smartcard for use in cellular telephone
US5903830A (en) 1996-08-08 1999-05-11 Joao; Raymond Anthony Transaction security apparatus and method
US7096003B2 (en) 1996-08-08 2006-08-22 Raymond Anthony Joao Transaction security apparatus
US5991749A (en) 1996-09-11 1999-11-23 Morrill, Jr.; Paul H. Wireless telephony for collecting tolls, conducting financial transactions, and authorizing other activities
US8156026B2 (en) 2000-05-12 2012-04-10 Nintendo of America Ltd. Method and apparatus for enabling purchasers of products to obtain return information and to initiate product returns via an on-line network connection
US5913203A (en) 1996-10-03 1999-06-15 Jaesent Inc. System and method for pseudo cash transactions
US5953710A (en) 1996-10-09 1999-09-14 Fleming; Stephen S. Children's credit or debit card system
US6385655B1 (en) 1996-10-24 2002-05-07 Tumbleweed Communications Corp. Method and apparatus for delivering documents over an electronic network
GB9624127D0 (en) 1996-11-20 1997-01-08 British Telecomm Transaction system
US5961593A (en) 1997-01-22 1999-10-05 Lucent Technologies, Inc. System and method for providing anonymous personalized browsing by a proxy system in a network
US6243688B1 (en) 1997-04-14 2001-06-05 Dyan T. Kalina Internet-based credit interchange system of converting purchase credit awards through credit exchange system for purchase of investment vehicle
US6202052B1 (en) 1997-05-08 2001-03-13 Simplification, Llc Fully-automated system for tax reporting, payment and refund
US5949044A (en) 1997-06-13 1999-09-07 Walker Asset Management Limited Partnership Method and apparatus for funds and credit line transfers
US20060190347A1 (en) 1997-06-16 2006-08-24 Vincent Cuervo System and process for sales, validation, rewards and delivery of prepaid debit cards
US20040039639A1 (en) 1997-07-08 2004-02-26 Walker Jay S. Method and apparatus for identifying potential buyers
KR20060022734A (ko) 1997-08-13 2006-03-10 마츠시타 덴끼 산교 가부시키가이샤 이동 전자 상거래 시스템
US6163771A (en) 1997-08-28 2000-12-19 Walker Digital, Llc Method and device for generating a single-use financial account number
US7177835B1 (en) 1997-08-28 2007-02-13 Walker Digital, Llc Method and device for generating a single-use financial account number
US5914472A (en) 1997-09-23 1999-06-22 At&T Corp Credit card spending authorization control system
US6000832A (en) 1997-09-24 1999-12-14 Microsoft Corporation Electronic online commerce card with customer generated transaction proxy number for online transactions
US5883810A (en) 1997-09-24 1999-03-16 Microsoft Corporation Electronic online commerce card with transactionproxy number for online transactions
US20060069619A1 (en) 1997-10-09 2006-03-30 Walker Jay S Systems and methods for facilitating group rewards
US6226624B1 (en) 1997-10-24 2001-05-01 Craig J. Watson System and method for pre-authorization of individual account remote transactions
US20020004783A1 (en) 1997-11-12 2002-01-10 Cris T. Paltenghe Virtual wallet system
US6014635A (en) 1997-12-08 2000-01-11 Shc Direct, Inc. System and method for providing a discount credit transaction network
US6535855B1 (en) 1997-12-09 2003-03-18 The Chase Manhattan Bank Push banking system and method
US7328350B2 (en) 2001-03-29 2008-02-05 Arcot Systems, Inc. Method and apparatus for secure cryptographic key generation, certification and use
US6195447B1 (en) 1998-01-16 2001-02-27 Lucent Technologies Inc. System and method for fingerprint data verification
US8346663B2 (en) 1998-01-30 2013-01-01 Citicorp Development Center, Inc. Method and system of contactless interfacing for smart card banking
US6385596B1 (en) 1998-02-06 2002-05-07 Liquid Audio, Inc. Secure online music distribution system
US6980670B1 (en) 1998-02-09 2005-12-27 Indivos Corporation Biometric tokenless electronic rewards system and method
US6202933B1 (en) 1998-02-19 2001-03-20 Ernst & Young U.S. Llp Transaction card and methods and apparatus therefor
US6208973B1 (en) 1998-02-27 2001-03-27 Onehealthbank.Com Point of service third party financial management vehicle for the healthcare industry
US6055513A (en) 1998-03-11 2000-04-25 Telebuyer, Llc Methods and apparatus for intelligent selection of goods and services in telephonic and electronic commerce
US6636833B1 (en) 1998-03-25 2003-10-21 Obis Patents Ltd. Credit card system and method
US6422462B1 (en) 1998-03-30 2002-07-23 Morris E. Cohen Apparatus and methods for improved credit cards and credit card transactions
US6064990A (en) 1998-03-31 2000-05-16 International Business Machines Corporation System for electronic notification of account activity
US6052675A (en) 1998-04-21 2000-04-18 At&T Corp. Method and apparatus for preauthorizing credit card type transactions
US6160903A (en) 1998-04-24 2000-12-12 Dew Engineering And Development Limited Method of providing secure user access
US20030171992A1 (en) 1999-04-23 2003-09-11 First Data Corporation System and methods for redeeming rewards associated with accounts
EP1080415B1 (en) 1998-05-21 2017-01-18 Equifax Inc. System and method for authentication of network users
US6006200A (en) 1998-05-22 1999-12-21 International Business Machines Corporation Method of providing an identifier for transactions
US6131811A (en) 1998-05-29 2000-10-17 E-Micro Corporation Wallet consolidator
US6161130A (en) 1998-06-23 2000-12-12 Microsoft Corporation Technique which utilizes a probabilistic classifier to detect "junk" e-mail by automatically updating a training and re-training the classifier based on the updated training set
IL125826A (en) 1998-08-17 2001-05-20 Ur Jonathan Shem Method for preventing unauthorized use of credit cards in remote payments and an optional supplemental-code card for use therein
US8799153B2 (en) 1998-08-31 2014-08-05 Mastercard International Incorporated Systems and methods for appending supplemental payment data to a transaction message
US7379901B1 (en) 1998-09-11 2008-05-27 Lv Partners, L.P. Accessing a vendor web site using personal account information retrieved from a credit card company web site
US7248855B2 (en) 1998-09-15 2007-07-24 Upaid Systems, Ltd. Convergent communications system and method with a rule set for authorizing, debiting, settling and recharging a mobile commerce account
US6601761B1 (en) 1998-09-15 2003-08-05 Citibank, N.A. Method and system for co-branding an electronic payment platform such as an electronic wallet
US6607136B1 (en) 1998-09-16 2003-08-19 Beepcard Inc. Physical presence digital authentication system
US6317722B1 (en) 1998-09-18 2001-11-13 Amazon.Com, Inc. Use of electronic shopping carts to generate personal recommendations
US7533064B1 (en) 1998-10-07 2009-05-12 Paypal Inc. E-mail invoked electronic commerce
US6092053A (en) 1998-10-07 2000-07-18 Cybercash, Inc. System and method for merchant invoked electronic commerce
US7617125B1 (en) 1998-10-07 2009-11-10 Paypal, Inc. System and method for storage and retrieval of information subject to authorization by a data controller
US7337119B1 (en) 1998-10-26 2008-02-26 First Data Corporation System and method for detecting purchasing card fraud
US6182894B1 (en) 1998-10-28 2001-02-06 American Express Travel Related Services Company, Inc. Systems and methods for authorizing a transaction card
US6473500B1 (en) 1998-10-28 2002-10-29 Mastercard International Incorporated System and method for using a prepaid card
US7047416B2 (en) 1998-11-09 2006-05-16 First Data Corporation Account-based digital signature (ABDS) system
US6164533A (en) 1998-11-12 2000-12-26 Barton; Blain Point of sale automatic savings program contribution system
US7379899B1 (en) 1998-11-13 2008-05-27 Nintendo Of America Inc. Method and apparatus for verifying product sale transactions and processing product returns
US6339766B1 (en) 1998-12-02 2002-01-15 Transactionsecure Electronic payment system employing limited-use account number
US7937325B2 (en) 1998-12-08 2011-05-03 Yodlee.Com, Inc. Interactive bill payment center
US6327578B1 (en) 1998-12-29 2001-12-04 International Business Machines Corporation Four-party credit/debit payment protocol
US8005731B1 (en) 1999-01-14 2011-08-23 Autobytel.Com, Inc. Real time vehicle purchase request management method and system
AU3355900A (en) 1999-02-03 2000-08-25 Steven M. Koehler System and method for monitoring a credit account
US7571139B1 (en) 1999-02-19 2009-08-04 Giordano Joseph A System and method for processing financial transactions
US7590575B2 (en) 1999-03-08 2009-09-15 Microsoft Corporation Method and apparatus for converting, formatting, and displaying currency values
US7117172B1 (en) 1999-03-11 2006-10-03 Corecard Software, Inc. Methods and systems for managing financial accounts
US6944595B1 (en) 1999-03-25 2005-09-13 International Business Machines Corporation Apparatus and method for performing conversion between different units of currency using an encapsulated conversion path of exchange rates
US20040139004A1 (en) 1999-04-08 2004-07-15 Aceinc Pty Ltd. Secure online commerce transactions
US20020198791A1 (en) 1999-04-21 2002-12-26 Perkowski Thomas J. Internet-based consumer product brand marketing communication system which enables manufacturers, retailers and their respective agents, and consumers to carry out product-related functions along the demand side of the retail chain in an integrated manner
US7792947B1 (en) 1999-04-26 2010-09-07 Mainstream Scientific, Llc Apparatus and method for dynamically coordinating the delivery of computer readable media
JP5116920B2 (ja) 1999-04-30 2013-01-09 ペイパル， インコーポレイテッド 分散型ユーザ間で価値を電子的に交換するためのシステムおよび方法
US6609113B1 (en) 1999-05-03 2003-08-19 The Chase Manhattan Bank Method and system for processing internet payments using the electronic funds transfer network
US6227447B1 (en) 1999-05-10 2001-05-08 First Usa Bank, Na Cardless payment system
US6385591B1 (en) 1999-05-11 2002-05-07 Jeffrey W. Mankoff Method and system for electronic organization of coupons
US7194437B1 (en) 1999-05-14 2007-03-20 Amazon.Com, Inc. Computer-based funds transfer system
US7685067B1 (en) 1999-05-14 2010-03-23 Amazon.Com, Inc. Computer-assisted funds transfer system
US6456984B1 (en) 1999-05-28 2002-09-24 Qwest Communications International Inc. Method and system for providing temporary credit authorizations
US7540012B1 (en) 1999-06-08 2009-05-26 International Business Machines Corporation Video on demand configuring, controlling and maintaining
DE19926472C2 (de) 1999-06-10 2001-11-15 Call A Bike Mobilitaetssysteme Verfahren zum Übermitteln eines Codes
US7249097B2 (en) 1999-06-18 2007-07-24 Echarge Corporation Method for ordering goods, services, and content over an internetwork using a virtual payment account
US7593862B2 (en) 1999-07-07 2009-09-22 Jeffrey W. Mankoff Delivery, organization, and redemption of virtual offers from the internet, interactive-TV, wireless devices and other electronic means
US7908216B1 (en) 1999-07-22 2011-03-15 Visa International Service Association Internet payment, authentication and loading system using virtual smart card
US20060178994A1 (en) 1999-07-26 2006-08-10 Stolfo Salvatore J Method and system for private shipping to anonymous users of a computer network
AU6229000A (en) 1999-07-26 2001-02-13 Iprivacy Llc Electronic purchase of goods over a communication network including physical delivery while securing private and personal information
WO2001009793A1 (en) 1999-07-29 2001-02-08 Privacash.Com, Inc. Method and system for transacting an anoymous purchase over the internet
US7644037B1 (en) 1999-08-16 2010-01-05 Vladimir Ostrovsky Method and system for transferring electronic funds
US6873974B1 (en) 1999-08-17 2005-03-29 Citibank, N.A. System and method for use of distributed electronic wallets
US7343351B1 (en) 1999-08-31 2008-03-11 American Express Travel Related Services Company, Inc. Methods and apparatus for conducting electronic transactions
US7953671B2 (en) 1999-08-31 2011-05-31 American Express Travel Related Services Company, Inc. Methods and apparatus for conducting electronic transactions
US6748367B1 (en) 1999-09-24 2004-06-08 Joonho John Lee Method and system for effecting financial transactions over a public network without submission of sensitive information
US7319986B2 (en) 1999-09-28 2008-01-15 Bank Of America Corporation Dynamic payment cards and related management systems and associated methods
FR2799289B1 (fr) 1999-10-01 2001-12-28 Air Liquide Procede et dispositif pour realiser un shema d'une installation comportant des appareils alimentes avec du gaz
US8275704B2 (en) 1999-11-05 2012-09-25 Lead Core Fund, L.L.C. Systems and methods for authorizing an allocation of an amount between transaction accounts
US7899744B2 (en) 1999-11-05 2011-03-01 American Express Travel Related Services Company, Inc. Systems and methods for approval of an allocation
US8195565B2 (en) 1999-11-05 2012-06-05 Lead Core Fund, L.L.C. Systems and methods for point of interaction based policy routing of transactions
WO2001035304A1 (en) 1999-11-10 2001-05-17 Krasnyansky Serge M On-line payment system
US7130807B1 (en) 1999-11-22 2006-10-31 Accenture Llp Technology sharing during demand and supply planning in a network-based supply chain environment
US8296228B1 (en) 1999-11-22 2012-10-23 Harry Thomas Kloor Dual transaction authorization system and method
US7603311B1 (en) 1999-11-29 2009-10-13 Yadav-Ranjan Rani K Process and device for conducting electronic transactions
US7966259B1 (en) 1999-12-09 2011-06-21 Amazon.Com, Inc. System and methods for facilitating transactions on, and personalizing web pages of, third party web sites
KR20010055426A (ko) 1999-12-10 2001-07-04 구홍식 지문을 이용한 전자 결제시스템 및 그 방법
US7668747B2 (en) 1999-12-13 2010-02-23 Autosavings Network, Inc. System and method for providing incentives to purchasers
EP1245009A1 (en) 1999-12-17 2002-10-02 Chantilley Corporation Limited Secure transaction systems
US7536335B1 (en) 1999-12-30 2009-05-19 Bloomberg L.P. System and method for implementing foreign exchange currency forwards
US20020178370A1 (en) 1999-12-30 2002-11-28 Gurevich Michael N. Method and apparatus for secure authentication and sensitive data management
WO2001050429A1 (en) 2000-01-05 2001-07-12 American Express Travel Related Services Company, Inc. Smartcard internet authorization system
US6516056B1 (en) 2000-01-07 2003-02-04 Vesta Corporation Fraud prevention system and method
US7268668B2 (en) 2003-05-09 2007-09-11 American Express Travel Related Services Company, Inc. Systems and methods for managing multiple accounts on a RF transaction instrument
US7024383B1 (en) 2000-01-31 2006-04-04 Goldman, Sachs & Co. Online sales risk management system
JP2001222316A (ja) 2000-02-09 2001-08-17 Sony Corp ロボットの管理システム及びロボットの管理方法
US20010056359A1 (en) 2000-02-11 2001-12-27 Abreu Marcio Marc System and method for communicating product recall information, product warnings or other product-related information to users of products
AU2001238300A1 (en) 2000-02-16 2001-08-27 Mastercard International Incorporated System and method for conducting electronic commerce with a remote wallet server
US20060178986A1 (en) 2000-02-17 2006-08-10 Giordano Joseph A System and method for processing financial transactions using multi-payment preferences
US7426750B2 (en) 2000-02-18 2008-09-16 Verimatrix, Inc. Network-based content distribution system
US20030018550A1 (en) 2000-02-22 2003-01-23 Rotman Frank Lewis Methods and systems for providing transaction data
KR20030011070A (ko) 2000-02-22 2003-02-06 윤인선 인터넷 상에서 신용 카드 구매력을 최대화하고 이자비용을 최소화하는 방법 및 시스템
US20010029485A1 (en) 2000-02-29 2001-10-11 E-Scoring, Inc. Systems and methods enabling anonymous credit transactions
US7865414B2 (en) 2000-03-01 2011-01-04 Passgate Corporation Method, system and computer readable medium for web site account and e-commerce management from a central location
TW550477B (en) 2000-03-01 2003-09-01 Passgate Corp Method, system and computer readable medium for Web site account and e-commerce management from a central location
US20010049635A1 (en) 2000-03-01 2001-12-06 Peoplepublish, Inc. User interface and associated data source
AU2001243473A1 (en) 2000-03-07 2001-09-17 American Express Travel Related Services Company, Inc. System for facilitating a transaction
US20010037297A1 (en) 2000-03-09 2001-11-01 Mcnair Edward Parry Bill paying with the aid of a scanner
US6999943B1 (en) 2000-03-10 2006-02-14 Doublecredit.Com, Inc. Routing methods and systems for increasing payment transaction volume and profitability
US9672515B2 (en) 2000-03-15 2017-06-06 Mastercard International Incorporated Method and system for secure payments over a computer network
US7412422B2 (en) 2000-03-23 2008-08-12 Dekel Shiloh Method and system for securing user identities and creating virtual users to enhance privacy on a communication network
AUPQ677400A0 (en) 2000-04-07 2000-05-11 Clift, John Lawrence A business method
US7177848B2 (en) 2000-04-11 2007-02-13 Mastercard International Incorporated Method and system for conducting secure payments over a computer network without a pseudo or proxy account number
US7379919B2 (en) 2000-04-11 2008-05-27 Mastercard International Incorporated Method and system for conducting secure payments over a computer network
US20100228668A1 (en) 2000-04-11 2010-09-09 Hogan Edward J Method and System for Conducting a Transaction Using a Proximity Device and an Identifier
US6990470B2 (en) 2000-04-11 2006-01-24 Mastercard International Incorporated Method and system for conducting secure payments over a computer network
US20100223186A1 (en) 2000-04-11 2010-09-02 Hogan Edward J Method and System for Conducting Secure Payments
US8032453B2 (en) 2000-04-14 2011-10-04 Citicorp Development Center, Inc. Method and system for notifying customers of transaction opportunities
US20070129955A1 (en) 2000-04-14 2007-06-07 American Express Travel Related Services Company, Inc. System and method for issuing and using a loyalty point advance
CA2305249A1 (en) 2000-04-14 2001-10-14 Branko Sarcanin Virtual safe
WO2001079966A2 (en) 2000-04-14 2001-10-25 American Express Travel Related Services Company, Inc. A system and method for using loyalty points
GB2361560B (en) 2000-04-17 2002-12-18 Robert Kaplan Method and apparatus for transferring or receiving data via the internet securely
AU5728001A (en) 2000-04-24 2001-11-07 Visa Int Service Ass Online payer authentication service
US6592044B1 (en) 2000-05-15 2003-07-15 Jacob Y. Wong Anonymous electronic card for generating personal coupons useful in commercial and security transactions
US20010056409A1 (en) 2000-05-15 2001-12-27 Bellovin Steven Michael Offline one time credit card numbers for secure e-commerce
US6805288B2 (en) 2000-05-15 2004-10-19 Larry Routhenstein Method for generating customer secure card numbers subject to use restrictions by an electronic card
US7206847B1 (en) 2000-05-22 2007-04-17 Motorola Inc. Smart card with back up
AU2001265107A1 (en) 2000-05-26 2001-12-11 Interchecks, Llc Methods and systems for network based electronic purchasing system
BR0111249A (pt) 2000-06-01 2003-12-23 Worldcom Inc Sistema e método para proporcionar serviços pré-pagos via um sistema de rede de protocolo da internet
JP2001344544A (ja) 2000-06-02 2001-12-14 Koji Sugano 携帯端末およびそれを用いた電子決済システム
US7499872B1 (en) 2000-06-02 2009-03-03 Tuition Fund, Llc Methods and systems for applying rebates to higher education
AU2001267188A1 (en) 2000-06-06 2001-12-17 Albert D. March System and method for transferring funds
US8489669B2 (en) 2000-06-07 2013-07-16 Apple Inc. Mobile data processing system moving interest radius
US7996259B1 (en) 2000-06-07 2011-08-09 Perfect Web Technologies, Inc. Method for developing electronic documents providing e-commerce tools
US7805494B1 (en) 2000-06-09 2010-09-28 Schwab Barry H System for transferring desktop computer configuration
US7505935B2 (en) 2000-06-21 2009-03-17 Chikka Pte Ltd Trading and auction system, and methods for the authentication of buyers and sellers and for the transmission of trading instructions in a trading and auction system
US10185936B2 (en) 2000-06-22 2019-01-22 Jpmorgan Chase Bank, N.A. Method and system for processing internet payments
GB2364586B (en) 2000-06-23 2004-06-16 Ebs Nominees Ltd Deal matching in an anonymous trading system
US6891953B1 (en) 2000-06-27 2005-05-10 Microsoft Corporation Method and system for binding enhanced software features to a persona
GB2364482B (en) 2000-06-30 2002-10-09 Motorola Inc Server-based electronic wallet system
KR100409263B1 (ko) 2000-07-01 2003-12-18 주식회사 올앳 은행계좌번호를 담은 전자지갑을 이용한 전자 지불 시스템및 그 방법
US7430537B2 (en) 2000-07-10 2008-09-30 Paypal, Inc. System and method for verifying a financial instrument
US7359880B2 (en) 2000-07-11 2008-04-15 Abel Luther C System and method for consumer control over card-based transactions
US6666377B1 (en) 2000-07-18 2003-12-23 Scott C. Harris Bar code data entry device
CA2417922C (en) 2000-08-04 2013-03-12 Lynn Henry Wheeler Person-centric account-based digital signature system
WO2002015603A2 (en) 2000-08-15 2002-02-21 Zonamovil.Com, Inc. Method and apparatus for a network independent short message delivery system
US6915294B1 (en) 2000-08-18 2005-07-05 Firstrain, Inc. Method and apparatus for searching network resources
US6938019B1 (en) 2000-08-29 2005-08-30 Uzo Chijioke Chukwuemeka Method and apparatus for making secure electronic payments
US20020029193A1 (en) 2000-09-01 2002-03-07 Infospace, Inc. Method and system for facilitating the transfer of funds utilizing a telephonic identifier
AU2001292725A1 (en) 2000-09-12 2002-03-26 American Express Travel Related Services Company, Inc. Microchip-enabled online transaction system
US7155411B1 (en) 2000-09-28 2006-12-26 Microsoft Corporation Integrating payment accounts and an electronic wallet
US7337144B1 (en) 2000-09-28 2008-02-26 Microsoft Corporation Method and system for restricting the usage of payment accounts
JP2002109098A (ja) 2000-10-04 2002-04-12 Fujitsu Ltd 商品情報管理方法及び修理依頼方法
US20020073045A1 (en) 2000-10-23 2002-06-13 Rubin Aviel D. Off-line generation of limited-use credit card numbers
US7499889B2 (en) 2000-10-23 2009-03-03 Cyota Inc. Transaction system
US7844489B2 (en) 2000-10-30 2010-11-30 Buyerleverage Buyer-driven targeting of purchasing entities
US7016532B2 (en) 2000-11-06 2006-03-21 Evryx Technologies Image capture and identification system and process
US7680324B2 (en) 2000-11-06 2010-03-16 Evryx Technologies, Inc. Use of image-derived information as search criteria for internet and other search engines
US7398225B2 (en) 2001-03-29 2008-07-08 American Express Travel Related Services Company, Inc. System and method for networked loyalty program
WO2002039342A1 (fr) 2000-11-08 2002-05-16 Matsushita Electric Industrial Co., Ltd. Systeme de banque de valeurs electroniques privees
US20070234224A1 (en) 2000-11-09 2007-10-04 Leavitt Joseph M Method for developing and implementing efficient workflow oriented user interfaces and controls
US20020099656A1 (en) 2000-11-14 2002-07-25 Poh Wong Kenneth Tien Electronic funds transfer system for processing multiple currency transactions
US7996288B1 (en) 2000-11-15 2011-08-09 Iprivacy, Llc Method and system for processing recurrent consumer transactions
US7318049B2 (en) 2000-11-17 2008-01-08 Gregory Fx Iannacci System and method for an automated benefit recognition, acquisition, value exchange, and transaction settlement system using multivariable linear and nonlinear modeling
US20020120864A1 (en) 2000-12-13 2002-08-29 Wu Jackie Zhanhong Automatable secure submission of confidential user information over a computer network
TW564361B (en) 2000-12-14 2003-12-01 Manugistics Inc System and method for enabling collaborative procurement of products in a supply chain
US6993507B2 (en) 2000-12-14 2006-01-31 Pacific Payment Systems, Inc. Bar coded bill payment system and method
US6934528B2 (en) 2000-12-20 2005-08-23 American Management Systems, Inc. Method for creating self-built customer hierarchies
US8396810B1 (en) 2000-12-29 2013-03-12 Zixit Corporation Centralized authorization and fraud-prevention system including virtual wallet for network-based transactions
US7941669B2 (en) 2001-01-03 2011-05-10 American Express Travel Related Services Company, Inc. Method and apparatus for enabling a user to select an authentication method
US6931382B2 (en) 2001-01-24 2005-08-16 Cdck Corporation Payment instrument authorization technique
GB2372616A (en) 2001-02-23 2002-08-28 Hewlett Packard Co Transaction method and apparatus using two part tokens
US7292999B2 (en) 2001-03-15 2007-11-06 American Express Travel Related Services Company, Inc. Online card present transaction
US7237117B2 (en) 2001-03-16 2007-06-26 Kenneth P. Weiss Universal secure registry
US9219708B2 (en) 2001-03-22 2015-12-22 DialwareInc. Method and system for remotely authenticating identification devices
US8595055B2 (en) 2001-03-27 2013-11-26 Points.Com Apparatus and method of facilitating the exchange of points between selected entities
WO2002077745A2 (en) 2001-03-26 2002-10-03 Wolfram Johannes Bernd Reiners Transaction authorisation system
US20060053056A1 (en) 2001-03-29 2006-03-09 American Express Marketing & Development Corporati Card member discount system and method
US7117183B2 (en) 2001-03-31 2006-10-03 First Data Coroporation Airline ticket payment and reservation system and methods
US20020147913A1 (en) 2001-04-09 2002-10-10 Lun Yip William Wai Tamper-proof mobile commerce system
US7167903B2 (en) 2001-04-25 2007-01-23 Teacherweb, Inc. System and method for user updateable web sites and web pages
US7028052B2 (en) 2001-05-10 2006-04-11 Equifax, Inc. Systems and methods for notifying a consumer of changes made to a credit report
US7313546B2 (en) 2001-05-23 2007-12-25 Jp Morgan Chase Bank, N.A. System and method for currency selectable stored value instrument
US7650314B1 (en) 2001-05-25 2010-01-19 American Express Travel Related Services Company, Inc. System and method for securing a recurrent billing transaction
US8060448B2 (en) 2001-05-30 2011-11-15 Jones Thomas C Late binding tokens
JP4363800B2 (ja) 2001-06-11 2009-11-11 ソニー株式会社 電子商取引支援装置，電子商取引支援方法およびコンピュータプログラム
WO2003001866A1 (en) 2001-06-27 2003-01-09 Snapcount Limited Transcation processing
US7742984B2 (en) 2001-07-06 2010-06-22 Hossein Mohsenzadeh Secure authentication and payment system
US8346659B1 (en) 2001-07-06 2013-01-01 Hossein Mohsenzadeh Secure authentication and payment system
US20060237528A1 (en) 2001-07-10 2006-10-26 Fred Bishop Systems and methods for non-traditional payment
US7996324B2 (en) 2001-07-10 2011-08-09 American Express Travel Related Services Company, Inc. Systems and methods for managing multiple accounts on a RF transaction device using secondary identification indicia
US7805378B2 (en) 2001-07-10 2010-09-28 American Express Travel Related Servicex Company, Inc. System and method for encoding information in magnetic stripe format for use in radio frequency identification transactions
US20030014307A1 (en) 2001-07-16 2003-01-16 General Motors Corporation Method and system for mobile commerce advertising
US20030018524A1 (en) 2001-07-17 2003-01-23 Dan Fishman Method for marketing and selling products to a user of a wireless device
US7890375B2 (en) 2001-07-31 2011-02-15 Half.Com, Inc. Method and system to facilitate pre-ordering via an electronic commerce facility, and to automatically facilitate satisfying of a pre-order upon listing of an appropriate offer via the electronic commerce facility
US7013290B2 (en) 2001-08-03 2006-03-14 John Allen Ananian Personalized interactive digital catalog profiling
US6898598B2 (en) 2001-08-09 2005-05-24 International Business Machines Corporation Smart receipt
US7133862B2 (en) 2001-08-13 2006-11-07 Xerox Corporation System with user directed enrichment and import/export control
US8737954B2 (en) 2001-08-21 2014-05-27 Bookit Oy Ajanvarauspalvelu Managing recurring payments from mobile terminals
US8050997B1 (en) 2001-08-23 2011-11-01 Paypal Inc. Instant availability of electronically transferred funds
US7613640B2 (en) 2001-08-29 2009-11-03 Ebs Group Limited Electronic trading system
US7444676B1 (en) 2001-08-29 2008-10-28 Nader Asghari-Kamrani Direct authentication and authorization system and method for trusted network of financial institutions
US7111789B2 (en) 2001-08-31 2006-09-26 Arcot Systems, Inc. Enhancements to multi-party authentication and other protocols
KR20010090081A (ko) 2001-09-11 2001-10-18 엄기문 바코드 및 이동통신 단말기를 이용한 신용카드 결제시스템 및 신용카드 결제 방법
US20030055785A1 (en) 2001-09-20 2003-03-20 International Business Machines Corporation System and method for electronic wallet transactions
AU2001100395B4 (en) 2001-09-20 2002-06-27 Warin Marc Georges Payment method and system
US7103576B2 (en) 2001-09-21 2006-09-05 First Usa Bank, Na System for providing cardless payment
US20030080185A1 (en) 2001-10-26 2003-05-01 Werther Ellen R. Money transfer method and system
US8332275B2 (en) 2001-10-31 2012-12-11 Ebay Inc. Method and apparatus to facilitate a transaction within a network-based facility
US7958049B2 (en) 2001-11-01 2011-06-07 Metavante Corporation System and method for obtaining customer bill information and facilitating bill payment at biller websites
AU2002358013A1 (en) 2001-11-14 2003-05-26 Encorus Technologies Gmbh Payment protocol and data transmission method and data transmission device for conducting payment transactions
US20030101134A1 (en) 2001-11-28 2003-05-29 Liu James C. Method and system for trusted transaction approval
ZA200209009B (en) 2001-11-30 2003-06-10 Valentin Stefanov Dr Kisimov E-commerce payment systems.
US7805376B2 (en) 2002-06-14 2010-09-28 American Express Travel Related Services Company, Inc. Methods and apparatus for facilitating a transaction
US6901387B2 (en) 2001-12-07 2005-05-31 General Electric Capital Financial Electronic purchasing method and apparatus for performing the same
US7212979B1 (en) 2001-12-14 2007-05-01 Bellsouth Intellectuall Property Corporation System and method for identifying desirable subscribers
AU2002366902A1 (en) * 2001-12-21 2003-07-09 Nokia Corporation Location-based novelty index value and recommendation system and method
US20030126076A1 (en) 2001-12-27 2003-07-03 Telefonaktiebolaget L.M. Ericsson (Publ) Systems and methods for secure authorization of electronic transactions
US6755342B1 (en) 2001-12-31 2004-06-29 Bellsouth Intellectual Property Corporation Credit card validation for an interactive wireless network
US20030144935A1 (en) 2002-01-30 2003-07-31 Sobek Michael F. Methods and systems for processing, accounting, and administration of stored value cards
KR100432430B1 (ko) 2002-02-01 2004-05-22 이효제 전자증권을 이용한 전자지불 시스템 및 그 방법
US7904360B2 (en) 2002-02-04 2011-03-08 Alexander William EVANS System and method for verification, authentication, and notification of a transaction
US7890393B2 (en) 2002-02-07 2011-02-15 Ebay, Inc. Method and system for completing a transaction between a customer and a merchant
MXPA04007821A (es) 2002-02-14 2005-04-19 Pessin Zachary Aparato y metodo para un sistema de capital distribuido.
EP2521106A1 (en) 2002-02-15 2012-11-07 Coinstar, Inc. Methods and systems for exchanging and/or transferring various forms of value
AUPS087602A0 (en) 2002-03-04 2002-03-28 Ong, Yong Kin (Michael) Electronic fund transfer system
US7389275B2 (en) 2002-03-05 2008-06-17 Visa U.S.A. Inc. System for personal authorization control for card transactions
RS50747B (sr) 2002-03-14 2010-08-31 Euronet Worldwide Inc. Sistem i postupak za kupovinu robe i servisa kroz pristupne tačke mreže podataka preko tačke prodajne mreže
GB2387929B (en) 2002-03-18 2005-11-16 Mainline Corporate Holdings A tax voucher system
US20030179230A1 (en) 2002-03-25 2003-09-25 Gerry Seidman Method and apparatus for providing remote peer-to-peer collaborative user interfaces
US8352499B2 (en) 2003-06-02 2013-01-08 Google Inc. Serving advertisements using user request information and user information
US20040210498A1 (en) 2002-03-29 2004-10-21 Bank One, National Association Method and system for performing purchase and other transactions using tokens with multiple chips
US8751391B2 (en) 2002-03-29 2014-06-10 Jpmorgan Chase Bank, N.A. System and process for performing purchase transactions using tokens
US20030191709A1 (en) 2002-04-03 2003-10-09 Stephen Elston Distributed payment and loyalty processing for retail and vending
US20060059110A1 (en) 2002-04-03 2006-03-16 Ajay Madhok System and method for detecting card fraud
GB2387253B (en) 2002-04-03 2004-02-18 Swivel Technologies Ltd System and method for secure credit and debit card transactions
US8180669B2 (en) 2002-04-04 2012-05-15 Catalina Marketing Corporation Product recall using customer prior shopping history data
US7707120B2 (en) 2002-04-17 2010-04-27 Visa International Service Association Mobile account authentication service
WO2003091849A2 (en) 2002-04-23 2003-11-06 The Clearing House Service Company L.L.C. Payment identification code system
US20030200142A1 (en) 2002-04-23 2003-10-23 Heather Hicks On-line employee incentive system
US7200577B2 (en) 2002-05-01 2007-04-03 America Online Incorporated Method and apparatus for secure online transactions
US7987491B2 (en) 2002-05-10 2011-07-26 Richard Reisman Method and apparatus for browsing using alternative linkbases
US20030212589A1 (en) 2002-05-13 2003-11-13 Kish William Elmer Enhancement incentive system using transaction events for user rewards, for workforce productivity on a distributed network
US20030216996A1 (en) 2002-05-14 2003-11-20 Capital One Financial Corporation Methods and systems for providing financial payment services
US7174292B2 (en) 2002-05-20 2007-02-06 Microsoft Corporation Method of determining uncertainty associated with acoustic distortion-based noise reduction
US8611919B2 (en) 2002-05-23 2013-12-17 Wounder Gmbh., Llc System, method, and computer program product for providing location based services and mobile e-commerce
US8209245B2 (en) 2002-05-28 2012-06-26 United Services Automobile Association Electronic financial transaction warehouse
US7680688B2 (en) 2002-05-28 2010-03-16 American Express Travel Related Services Company, Inc. System and method for exchanging loyalty points for acquisitions
US20050101309A1 (en) 2002-05-29 2005-05-12 Martin Croome Method and apparatus for selective configuration based upon expansion card presence
AU2003243523B2 (en) 2002-06-12 2008-04-10 Cardinalcommerce Corporation Universal merchant platform for payment authentication
US7047041B2 (en) 2002-06-17 2006-05-16 Nokia Corporation Method and device for storing and accessing personal information
US7110980B2 (en) 2002-06-21 2006-09-19 American Express Bank Ltd. System and method for facilitating electronic transfer of funds
US7797215B1 (en) 2002-06-26 2010-09-14 Power Financial Group, Inc. System and method for analyzing and searching financial instrument data
US7254548B1 (en) 2002-07-10 2007-08-07 Union Beach, L.P. System and method for the administration of financial accounts using profiles
US8412623B2 (en) 2002-07-15 2013-04-02 Citicorp Credit Services, Inc. Method and system for a multi-purpose transactional platform
US7305242B2 (en) 2002-07-17 2007-12-04 Nokia Corporation System, apparatus, and method for facilitating link selection on electronic devices
US7209561B1 (en) 2002-07-19 2007-04-24 Cybersource Corporation System and method for generating encryption seed values
US20040127256A1 (en) 2002-07-30 2004-07-01 Scott Goldthwaite Mobile device equipped with a contactless smart card reader/writer
US7606560B2 (en) 2002-08-08 2009-10-20 Fujitsu Limited Authentication services using mobile device
US7801826B2 (en) 2002-08-08 2010-09-21 Fujitsu Limited Framework and system for purchasing of goods and services
US7353382B2 (en) 2002-08-08 2008-04-01 Fujitsu Limited Security framework and protocol for universal pervasive transactions
US7784684B2 (en) 2002-08-08 2010-08-31 Fujitsu Limited Wireless computer wallet for physical point of sale (POS) transactions
US7822688B2 (en) 2002-08-08 2010-10-26 Fujitsu Limited Wireless wallet
US20050038724A1 (en) 2002-08-30 2005-02-17 Navio Systems, Inc. Methods and apparatus for enabling transaction relating to digital assets
US6805287B2 (en) 2002-09-12 2004-10-19 American Express Travel Related Services Company, Inc. System and method for converting a stored value card to a credit card
US7124098B2 (en) 2002-10-07 2006-10-17 The Kroger Company Online shopping system
WO2004038997A1 (en) 2002-10-18 2004-05-06 American Express Travel Related Services Company, Inc. Device independent authentication system and method
US20040128197A1 (en) 2002-10-23 2004-07-01 Vayusa, Inc. System and method of generating, distributing, and/or redeeming promotional offers using electronic devices
CA2505030A1 (en) 2002-11-05 2004-05-21 Aaron Whiteman Remote purchasing system and method
AU2003295415B2 (en) 2002-11-07 2010-12-09 Planet Payment, Inc. Time-of-transaction foreign currency conversion
US7231354B1 (en) 2002-11-12 2007-06-12 Bellsouth Intellectual Property Corporation Method, apparatus, and computer-readable medium for administering the implementation of product change notices
US7047251B2 (en) 2002-11-22 2006-05-16 Accenture Global Services, Gmbh Standardized customer application and record for inputting customer data into analytic models
US20040103037A1 (en) 2002-11-26 2004-05-27 Sears, Roebuck And Co. Methods and apparatus for organizing retail product information
US20040111698A1 (en) 2002-12-06 2004-06-10 Anew Technology Corporation System and method for design, development, and deployment of distributed applications that share data from heterogeneous and autonomous sources over the Web
US7571140B2 (en) 2002-12-16 2009-08-04 First Data Corporation Payment management
GB2396472A (en) 2002-12-18 2004-06-23 Ncr Int Inc System for cash withdrawal
US7827101B2 (en) 2003-01-10 2010-11-02 First Data Corporation Payment system clearing for transactions
US20040138999A1 (en) 2003-01-13 2004-07-15 Capital One Financial Corporation Systems and methods for managing a credit account having a credit component associated with healthcare expenses
TW200412524A (en) 2003-01-15 2004-07-16 Lee Fung Chi A small amount paying/receiving system
US7228011B1 (en) 2003-02-28 2007-06-05 L-I Identity Solutions, Inc. System and method for issuing a security unit after determining eligibility by image recognition
JP4117550B2 (ja) 2003-03-19 2008-07-16 ソニー株式会社 通信システム、決済管理装置および方法、携帯情報端末および情報処理方法、並びにプログラム
CN100351789C (zh) 2003-03-28 2007-11-28 索尼株式会社 信息提供设备、方法和信息提供系统
US7664733B2 (en) 2003-04-11 2010-02-16 Ricoh Company, Ltd. Techniques for performing operations on a source symbolic document
US20040215560A1 (en) 2003-04-25 2004-10-28 Peter Amalraj Integrated payment system and method
WO2004097688A1 (en) 2003-04-28 2004-11-11 Sony Pictures Entertainment Inc. Support applications for rich media publishing
US8082210B2 (en) 2003-04-29 2011-12-20 The Western Union Company Authentication for online money transfers
US7827077B2 (en) 2003-05-02 2010-11-02 Visa U.S.A. Inc. Method and apparatus for management of electronic receipts on portable devices
US7268667B2 (en) 2003-05-09 2007-09-11 American Express Travel Related Services Company, Inc. Systems and methods for providing a RF transaction device operable to store multiple distinct accounts
US7895119B2 (en) 2003-05-13 2011-02-22 Bank Of America Corporation Method and system for pushing credit payments as buyer initiated transactions
US7689483B2 (en) 2003-05-20 2010-03-30 Amegy Bank of Texas System to facilitate payments for a customer through a foreign bank, software, business methods, and other related methods
JP3981043B2 (ja) 2003-06-13 2007-09-26 三菱電機インフォメーションシステムズ株式会社 ポイント交換システムおよびポイント交換プログラム
US7266557B2 (en) 2003-06-25 2007-09-04 International Business Machines Corporation File retrieval method and system
US7398291B2 (en) 2003-06-26 2008-07-08 International Business Machines Corporation Method, system and program product for providing a status of a transaction with an application on a server
WO2005010790A1 (en) 2003-06-27 2005-02-03 Bear, Stearns & Co, Inc. Method and system for initiating pairs trading across multiple markets having automatic foreign exchange price hedge
US8321267B2 (en) 2003-06-30 2012-11-27 Mindspark Interactive Network, Inc. Method, system and apparatus for targeting an offer
US20050004811A1 (en) 2003-07-02 2005-01-06 Babu Suresh Rangaswamy Automated recall management system for enterprise management applications
US7676432B2 (en) 2003-07-08 2010-03-09 Paybyclick Corporation Methods and apparatus for transacting electronic commerce using account hierarchy and locking of accounts
US7180457B2 (en) 2003-07-11 2007-02-20 Raytheon Company Wideband phased array radiator
US7156311B2 (en) 2003-07-16 2007-01-02 Scanbuy, Inc. System and method for decoding and analyzing barcodes using a mobile device
US7668754B1 (en) 2003-07-21 2010-02-23 Symbol Technologies, Inc. Architecture for secure reverse mobile commerce
US20050080821A1 (en) 2003-07-21 2005-04-14 Breil Peter D. System and method for managing collections accounts
GB0318000D0 (en) 2003-07-31 2003-09-03 Ncr Int Inc Mobile applications
US20090132347A1 (en) 2003-08-12 2009-05-21 Russell Wayne Anderson Systems And Methods For Aggregating And Utilizing Retail Transaction Records At The Customer Level
US7373669B2 (en) 2003-08-13 2008-05-13 The 41St Parameter, Inc. Method and system for determining presence of probable error or fraud in a data set by linking common data values or elements
US7624068B1 (en) 2003-08-18 2009-11-24 Jpmorgan Chase Bank, N.A. Method and system for dynamically adjusting discount rates for a card transaction
WO2005020033A2 (en) 2003-08-26 2005-03-03 Waves Licensing, Llc Exchange trade currency fund instrument and system
US8156042B2 (en) 2003-08-29 2012-04-10 Starbucks Corporation Method and apparatus for automatically reloading a stored value card
CN101073219A (zh) 2003-09-12 2007-11-14 Rsa安全公司 用于基于风险的验证的系统和方法
US20050065819A1 (en) 2003-09-19 2005-03-24 Schultz Pamela Lynn Electronic reimbursement process for provision of medical services
US20050199709A1 (en) 2003-10-10 2005-09-15 James Linlor Secure money transfer between hand-held devices
US7387238B2 (en) 2003-10-14 2008-06-17 Foss Jr Sheldon H Customer enrollment in a stored value card program
US7567936B1 (en) 2003-10-14 2009-07-28 Paradox Technical Solutions Llc Method and apparatus for handling pseudo identities
US20050080730A1 (en) 2003-10-14 2005-04-14 First Data Corporation System and method for secure account transactions
WO2005038623A2 (en) 2003-10-17 2005-04-28 Nexxo Financial Corporation Systems and methods for money sharing
US20050108178A1 (en) 2003-11-17 2005-05-19 Richard York Order risk determination
US20050192893A1 (en) 2003-11-24 2005-09-01 Keeling John E. Authenticated messaging-based transactions
US7543739B2 (en) 2003-12-17 2009-06-09 Qsecure, Inc. Automated payment card fraud detection and location
US20050137969A1 (en) 2003-12-19 2005-06-23 Dharmesh Shah Secure financial transaction gateway and vault
US6948656B2 (en) 2003-12-23 2005-09-27 First Data Corporation System with GPS to manage risk of financial transactions
US8145898B2 (en) 2003-12-23 2012-03-27 Hewlett-Packard Development Company, L.P. Encryption/decryption pay per use web service
US20050144082A1 (en) * 2003-12-30 2005-06-30 Coolman Jeron W. Systems and methods for ordering from multiple vendors
WO2005079050A1 (en) 2004-01-20 2005-08-25 Kamfu Wong A-computer accounting system with a lock using in a bank and the corresponding method used for secure payment by phone
CA2495949A1 (en) 2004-02-05 2005-08-05 Simon Law Secure wireless authorization system
US20050192895A1 (en) 2004-02-10 2005-09-01 First Data Corporation Methods and systems for processing transactions
CN1922623A (zh) 2004-02-17 2007-02-28 富士通株式会社 无线钱包
US20080288889A1 (en) 2004-02-20 2008-11-20 Herbert Dennis Hunt Data visualization application
US20070038515A1 (en) 2004-03-01 2007-02-15 Signature Systems Llc Method and system for issuing, aggregating and redeeming merchant reward points with a credit card network
US7584153B2 (en) 2004-03-15 2009-09-01 Qsecure, Inc. Financial transactions with dynamic card verification values
US7580898B2 (en) 2004-03-15 2009-08-25 Qsecure, Inc. Financial transactions with dynamic personal account numbers
CN101124597A (zh) 2004-03-26 2008-02-13 花旗信贷服务公司 用于整合多个奖励计划的方法和系统
GB0407369D0 (en) 2004-03-31 2004-05-05 British Telecomm Trust tokens
US20060081714A1 (en) 2004-08-23 2006-04-20 King Martin T Portable scanning device
US20050220326A1 (en) 2004-04-06 2005-10-06 Rf Intelligent Systems, Inc. Mobile identification system and method
US20130054470A1 (en) 2010-01-08 2013-02-28 Blackhawk Network, Inc. System for Payment via Electronic Wallet
US20140019352A1 (en) 2011-02-22 2014-01-16 Visa International Service Association Multi-purpose virtual card transaction apparatuses, methods and systems
WO2005103874A2 (en) 2004-04-16 2005-11-03 Cascade Basic Research Corp. Modelling relationships within an on-line connectivity universe
US20050234817A1 (en) 2004-04-16 2005-10-20 First Data Corporation Methods and systems for private label transaction processing
US20080027218A1 (en) 2004-04-29 2008-01-31 Daugs Edward D Hydroformylation Process for Pharmaceutical Intermediate
US8762283B2 (en) 2004-05-03 2014-06-24 Visa International Service Association Multiple party benefit from an online authentication service
US20050254714A1 (en) 2004-05-13 2005-11-17 Ramakrishna Anne Systems and methods for data transfer with camera-enabled devices
US7798415B1 (en) 2004-05-20 2010-09-21 American Express Travel Realted Services Company, Inc. Wireless transaction fobs and methods of using the same
US20050269402A1 (en) 2004-06-03 2005-12-08 Tyfone, Inc. System and method for securing financial transactions
US20050269401A1 (en) 2004-06-03 2005-12-08 Tyfone, Inc. System and method for securing financial transactions
US8412837B1 (en) 2004-07-08 2013-04-02 James A. Roskind Data privacy
US7264154B2 (en) 2004-07-12 2007-09-04 Harris David N System and method for securing a credit account
US7383231B2 (en) 2004-07-19 2008-06-03 Amazon Technologies, Inc. Performing automatically authorized programmatic transactions
US20060020542A1 (en) 2004-07-21 2006-01-26 Litle Thomas J Method and system for processing financial transactions
US7413113B1 (en) 2004-07-28 2008-08-19 Sprint Communications Company L.P. Context-based card selection device
US7287692B1 (en) 2004-07-28 2007-10-30 Cisco Technology, Inc. System and method for securing transactions in a contact center environment
US7392222B1 (en) 2004-08-03 2008-06-24 Jpmorgan Chase Bank, N.A. System and method for providing promotional pricing
US7623823B2 (en) 2004-08-31 2009-11-24 Integrated Media Measurement, Inc. Detecting and measuring exposure to media content items
US7506812B2 (en) 2004-09-07 2009-03-24 Semtek Innovative Solutions Corporation Transparently securing data for transmission on financial networks
US7870071B2 (en) 2004-09-08 2011-01-11 American Express Travel Related Services Company, Inc. Systems, methods, and devices for combined credit card and stored value transaction accounts
GB0420409D0 (en) 2004-09-14 2004-10-20 Waterleaf Ltd Online commercial transaction system and method of operation thereof
US8199195B2 (en) 2004-09-30 2012-06-12 Martin Renkis Wireless video surveillance system and method with security key
US20060163349A1 (en) 2004-09-30 2006-07-27 W5 Networks, Inc. Wireless systems suitable for retail automation and promotion
US8489583B2 (en) 2004-10-01 2013-07-16 Ricoh Company, Ltd. Techniques for retrieving documents using an image capture device
US7051929B2 (en) 2004-10-18 2006-05-30 Gongling Li Secure credit card having daily changed security number
US8204774B2 (en) 2004-10-29 2012-06-19 American Express Travel Related Services Company, Inc. Estimating the spend capacity of consumer households
US8155975B1 (en) 2004-11-05 2012-04-10 Rdm Corporation System and method for providing configuration and settlement processing of financial transactions using a hierarchy node model
US7783539B2 (en) 2004-11-08 2010-08-24 First Data Corporation Derivative currency-exchange transactions
US8417633B1 (en) 2004-11-08 2013-04-09 Rockstar Consortium Us Lp Enabling improved protection of consumer information in electronic transactions
US20060129427A1 (en) 2004-11-16 2006-06-15 Health Dialog Services Corporation Systems and methods for predicting healthcare related risk events
US7958087B2 (en) 2004-11-17 2011-06-07 Iron Mountain Incorporated Systems and methods for cross-system digital asset tag propagation
US8224754B2 (en) 2004-12-15 2012-07-17 Microsoft Corporation Generation, distribution and verification of tokens using a secure hash algorithm
WO2006063628A1 (en) 2004-12-15 2006-06-22 Unisys Corporation Communication system and method using visual interfaces for mobile transactions
EP1831613B1 (en) 2004-12-20 2013-02-20 Koninklijke Philips Electronics N.V. Method of operating a flow-through heating
US7720436B2 (en) 2006-01-09 2010-05-18 Nokia Corporation Displaying network objects in mobile devices based on geolocation
US7210620B2 (en) 2005-01-04 2007-05-01 Ameriprise Financial, Inc. System for facilitating online electronic transactions
US20060208065A1 (en) 2005-01-18 2006-09-21 Isaac Mendelovich Method for managing consumer accounts and transactions
US7548889B2 (en) 2005-01-24 2009-06-16 Microsoft Corporation Payment information security for multi-merchant purchasing environment for downloadable products
US20060212434A1 (en) 2005-03-11 2006-09-21 Sallie Mae, Inc. System and method for customization and streamlining of Web site navigation
US7357310B2 (en) 2005-03-11 2008-04-15 Gerry Calabrese Mobile phone charge card notification and authorization method
US8060463B1 (en) 2005-03-30 2011-11-15 Amazon Technologies, Inc. Mining of user event data to identify users with common interests
CN1841425A (zh) 2005-03-31 2006-10-04 华为技术有限公司 移动终端购物方法及其系统
US7527195B2 (en) 2005-04-11 2009-05-05 Bill Me Later, Inc. Method and system for risk management in a transaction
US7970671B2 (en) 2005-04-12 2011-06-28 Syncada Llc Automated transaction processing system and approach with currency conversion
EP1872188A4 (en) 2005-04-19 2011-04-27 Microsoft Corp NETWORK COMMERCIAL TRANSACTIONS
US7849020B2 (en) 2005-04-19 2010-12-07 Microsoft Corporation Method and apparatus for network transactions
US20060235795A1 (en) 2005-04-19 2006-10-19 Microsoft Corporation Secure network commercial transactions
US20060282332A1 (en) 2005-04-28 2006-12-14 Pfleging Gerald W Method for transmitting a wireless receipt to a personal digital device
US20100082480A1 (en) 2008-09-30 2010-04-01 Jason Alexander Korosec Payments with virtual value
US20080035738A1 (en) 2005-05-09 2008-02-14 Mullen Jeffrey D Dynamic credit card with magnetic stripe and embedded encoder and methods for using the same to provide a copy-proof credit card
US7793851B2 (en) 2005-05-09 2010-09-14 Dynamics Inc. Dynamic credit card with magnetic stripe and embedded encoder and methods for using the same to provide a copy-proof credit card
KR100662026B1 (ko) 2005-05-13 2006-12-27 (주)베스텍컴 네트워크를 통한 부가세 환급 처리 시스템 및 그 방법
US7731086B2 (en) 2005-06-10 2010-06-08 American Express Travel Related Services Company, Inc. System and method for mass transit merchant payment
US7810720B2 (en) 2005-06-13 2010-10-12 Robert Lovett Account payment using barcode information exchange
US7343149B2 (en) 2005-06-13 2008-03-11 Lucent Technologies Inc. Network support for credit card notification
US20070022007A1 (en) 2005-06-14 2007-01-25 Mystorecredit.Com System and method for a customer loyalty reward system utilizing a shopping search portal, a payment transfer agent and email marketing
US9104773B2 (en) 2005-06-21 2015-08-11 Microsoft Technology Licensing, Llc Finding and consuming web subscriptions in a web browser
US7290704B1 (en) 2005-06-21 2007-11-06 Robert Ball Method and system relating to a multi-lateral trade engine for payment transactions
US7742942B2 (en) 2005-06-22 2010-06-22 Excentus Corporation System and method for discounting fuel
JP2008545210A (ja) 2005-06-30 2008-12-11 アール． エッシグ、ジョン 消費者主導の生産前ワクチンの予約システムおよびワクチン予約システムの使用方法
US7970626B2 (en) 2005-07-08 2011-06-28 Oltine Acquistitions NY LLC Facilitating payments to health care providers
US8335720B2 (en) 2005-08-10 2012-12-18 American Express Travel Related Services Company, Inc. System, method, and computer program product for increasing inventory turnover using targeted consumer offers
US20070038516A1 (en) 2005-08-13 2007-02-15 Jeff Apple Systems, methods, and computer program products for enabling an advertiser to measure user viewing of and response to an advertisement
US20070150413A1 (en) 2005-08-29 2007-06-28 Frederick Morgenstern Apparatus and Method for Creating and Using Electronic Currency on Global Computer Networks
US8166068B2 (en) 2005-09-02 2012-04-24 Qwest Location based authorization of financial card transactions systems and methods
US7584884B2 (en) 2005-09-06 2009-09-08 Capital One Financial Corporation System and method for capturing sales tax deduction information from monetary card transactions
US8762263B2 (en) 2005-09-06 2014-06-24 Visa U.S.A. Inc. System and method for secured account numbers in proximity devices
US8209344B2 (en) 2005-09-14 2012-06-26 Jumptap, Inc. Embedding sponsored content in mobile applications
US8364540B2 (en) 2005-09-14 2013-01-29 Jumptap, Inc. Contextual targeting of content using a monetization platform
US7660581B2 (en) 2005-09-14 2010-02-09 Jumptap, Inc. Managing sponsored content based on usage history
US8326689B2 (en) 2005-09-16 2012-12-04 Google Inc. Flexible advertising system which allows advertisers with different value propositions to express such value propositions to the advertising system
US8660862B2 (en) 2005-09-20 2014-02-25 Visa U.S.A. Inc. Determination of healthcare coverage using a payment account
US20070214078A1 (en) 2005-09-28 2007-09-13 Transpayment, Inc. Bill payment apparatus and method
US20070106627A1 (en) 2005-10-05 2007-05-10 Mohit Srivastava Social discovery systems and methods
US8205791B2 (en) 2005-10-11 2012-06-26 National Payment Card Association Payment system and methods
US8352376B2 (en) 2005-10-11 2013-01-08 Amazon Technologies, Inc. System and method for authorization of transactions
US20080004116A1 (en) 2006-06-30 2008-01-03 Andrew Stephen Van Luchene Video Game Environment
US7645194B2 (en) 2005-10-14 2010-01-12 Leviathan Entertainment, Llc Financial institutions and instruments in a virtual environment
US20070089016A1 (en) 2005-10-18 2007-04-19 Nokia Corporation Block serial pipelined layered decoding architecture for structured low-density parity-check (LDPC) codes
US7672865B2 (en) 2005-10-21 2010-03-02 Fair Isaac Corporation Method and apparatus for retail data mining using pair-wise co-occurrence consistency
US7819307B2 (en) 2005-10-27 2010-10-26 Hewlett-Packard Development Company, L.P. Method and system for managing monetary value on a mobile device
US7877790B2 (en) 2005-10-31 2011-01-25 At&T Intellectual Property I, L.P. System and method of using personal data
US7844490B2 (en) 2005-11-02 2010-11-30 Visa U.S.A. Inc. Method and system for conducting promotional programs
US8538875B2 (en) 2005-11-04 2013-09-17 Instamed Communications Llc Process for linked healthcare and financial transaction initiation
US7853995B2 (en) 2005-11-18 2010-12-14 Microsoft Corporation Short-lived certificate authority service
US20070162350A1 (en) 2005-11-23 2007-07-12 Friedman Paul R Method and apparatus for retrieving remote data based on local indicia
US8046260B2 (en) 2005-12-02 2011-10-25 Welcome Real-Time Pte Ltd Method and system for authorising returns
US20070125840A1 (en) 2005-12-06 2007-06-07 Boncle, Inc. Extended electronic wallet management
US7827288B2 (en) 2005-12-08 2010-11-02 International Business Machines Corporation Model autocompletion for composite services synchronization
WO2007066506A1 (ja) 2005-12-09 2007-06-14 Konica Minolta Holdings, Inc. 画像処理方法、画像処理装置及び画像処理プログラム
US20070136193A1 (en) 2005-12-13 2007-06-14 Bellsouth Intellectual Property Corporation Methods, transactional cards, and systems using account identifers customized by the account holder
US7711640B2 (en) 2005-12-20 2010-05-04 Bgc Partners, Inc. Methods and apparatus for composite trading order processing
WO2007076459A2 (en) 2005-12-21 2007-07-05 Digimarc Corporation Rules driven pan id metadata routing system and network
US8275312B2 (en) 2005-12-31 2012-09-25 Blaze Mobile, Inc. Induction triggered transactions using an external NFC device
US8352323B2 (en) 2007-11-30 2013-01-08 Blaze Mobile, Inc. Conducting an online payment transaction using an NFC enabled mobile communication device
US8290433B2 (en) 2007-11-14 2012-10-16 Blaze Mobile, Inc. Method and system for securing transactions made through a mobile communication device
US7706740B2 (en) 2006-01-06 2010-04-27 Qualcomm Incorporated Apparatus and methods of selective collection and selective presentation of content
US20070162369A1 (en) 2006-01-09 2007-07-12 Hardison Joseph H Iii Internet-based method of and system for transfering and exercising monetary rights within a financial marketplace
US20070170247A1 (en) 2006-01-20 2007-07-26 Maury Samuel Friedman Payment card authentication system and method
EP1979864A1 (en) 2006-01-30 2008-10-15 CPNI Inc. A system and method for authorizing a funds transfer or payment using a phone number
US8149771B2 (en) 2006-01-31 2012-04-03 Roundbox, Inc. Reliable event broadcaster with multiplexing and bandwidth control functions
WO2007092715A2 (en) 2006-02-06 2007-08-16 Solidus Networks, Inc. Method and system for providing online authentication utilizing biometric data
JP4822863B2 (ja) 2006-02-08 2011-11-24 富士通株式会社 数値解析データ作成方法及び装置並びにプログラム及び記憶媒体
US8345931B2 (en) 2006-02-10 2013-01-01 The Western Union Company Biometric based authorization systems for electronic fund transfers
KR100731809B1 (ko) 2006-02-13 2007-06-22 삼성전자주식회사 이동통신 단말기 간의 착 발신 전환에 따른 과금 처리 방법
US7966239B2 (en) 2006-02-14 2011-06-21 Leviathan Entertainment, Llc Software-based commerce engine deployed in video game environment
CN101025806B (zh) 2006-02-20 2012-09-05 普天信息技术研究院 一种用移动通信终端进行费用支付的方法
US8001055B2 (en) 2006-02-21 2011-08-16 Weiss Kenneth P Method, system and apparatus for secure access, payment and identification
US8234220B2 (en) 2007-02-21 2012-07-31 Weiss Kenneth P Universal secure registry
US8453925B2 (en) 2006-03-02 2013-06-04 Visa International Service Association Method and system for performing two factor authentication in mail order and telephone order transactions
US8335822B2 (en) 2006-03-13 2012-12-18 Ebay Inc. Peer-to-peer trading platform with search caching
US8176416B1 (en) 2006-03-17 2012-05-08 Wells Fargo Bank, N.A. System and method for delivering a device-independent web page
US20070226152A1 (en) 2006-03-21 2007-09-27 Austin Jones System and method for anonymous transactions and conveyances
US8225385B2 (en) 2006-03-23 2012-07-17 Microsoft Corporation Multiple security token transactions
US7873573B2 (en) 2006-03-30 2011-01-18 Obopay, Inc. Virtual pooled account for mobile banking
US8249965B2 (en) 2006-03-30 2012-08-21 Obopay, Inc. Member-supported mobile payment system
DE602006007804D1 (de) 2006-03-31 2009-08-27 Sony Deutschland Gmbh Zusammensetzung die mindestens eine Art von Flüssigkristall enthält
US7818264B2 (en) 2006-06-19 2010-10-19 Visa U.S.A. Inc. Track data encryption
US9065643B2 (en) 2006-04-05 2015-06-23 Visa U.S.A. Inc. System and method for account identifier obfuscation
CA2648565A1 (en) 2006-04-07 2007-10-18 Bloomberg Finance L.P. System and method for facilitating foreign currency management
US8028041B2 (en) 2006-04-07 2011-09-27 Ebay Inc. Dynamic content for online transactions
US7809632B2 (en) 2006-04-12 2010-10-05 Uat, Inc. System and method for assigning responsibility for trade order execution
US20070245414A1 (en) 2006-04-14 2007-10-18 Microsoft Corporation Proxy Authentication and Indirect Certificate Chaining
KR20070104087A (ko) 2006-04-21 2007-10-25 주식회사 아이캐시 구매 인증 번호를 이용한 신용카드 회원에 대한 판매품목별 로열티 서비스 방법 및 시스템
US20070288377A1 (en) 2006-04-26 2007-12-13 Yosef Shaked System and method for authenticating a customer's identity and completing a secure credit card transaction without the use of a credit card number
FR2900481B1 (fr) 2006-04-27 2009-04-24 Arjowiggins Soc Par Actions Si Systeme de lecture d'au moins un code a barres
US8095602B1 (en) 2006-05-30 2012-01-10 Avaya Inc. Spam whitelisting for recent sites
US8016192B2 (en) 2006-06-06 2011-09-13 Motorola Mobility, Inc. User-configurable priority list for mobile device electronic payment applications
JP2007328549A (ja) 2006-06-07 2007-12-20 Inax Corp 商品・サービスの購入代金を決済する決済方法
US20070291995A1 (en) 2006-06-09 2007-12-20 Rivera Paul G System, Method, and Apparatus for Preventing Identity Fraud Associated With Payment and Identity Cards
US8725711B2 (en) 2006-06-09 2014-05-13 Advent Software, Inc. Systems and methods for information categorization
US20080015988A1 (en) 2006-06-28 2008-01-17 Gary Brown Proxy card authorization system
US8290819B2 (en) 2006-06-29 2012-10-16 Microsoft Corporation Electronic commerce transactions over a peer-to-peer communications channel
US9135626B2 (en) 2006-06-30 2015-09-15 Nokia Technologies Oy Advertising middleware
US7644042B2 (en) 2006-06-30 2010-01-05 Amazon Technologies, Inc. Managing transaction accounts
US8160959B2 (en) 2006-07-06 2012-04-17 Firethorn Mobile, Inc. Methods and systems for payment transactions in a mobile environment
US8489067B2 (en) 2006-07-06 2013-07-16 Qualcomm Incorporated Methods and systems for distribution of a mobile wallet for a mobile device
US20080021829A1 (en) 2006-07-06 2008-01-24 Kranzley Arthur D Rule-based selection of financial account for payment card transaction
JP5431636B2 (ja) 2006-07-14 2014-03-05 株式会社小糸製作所 車両用標識灯
JP4819608B2 (ja) 2006-07-31 2011-11-24 富士フイルム株式会社 液体吐出ヘッド、液体吐出装置、及び画像形成装置
US7844530B2 (en) 2006-07-31 2010-11-30 Insight Catastrophe Solutions Apparatuses, methods, and systems for providing a risk scoring engine user interface
US8220047B1 (en) 2006-08-09 2012-07-10 Google Inc. Anti-phishing system and method
US7708194B2 (en) 2006-08-23 2010-05-04 Verizon Patent And Licensing Inc. Virtual wallet
US10019708B2 (en) 2006-08-25 2018-07-10 Amazon Technologies, Inc. Utilizing phrase tokens in transactions
US20080059370A1 (en) 2006-08-30 2008-03-06 Cardit, Llc System and Method for Third Party Payment Processing of Credit Cards
US7469151B2 (en) 2006-09-01 2008-12-23 Vivotech, Inc. Methods, systems and computer program products for over the air (OTA) provisioning of soft cards on devices with wireless communications capabilities
US20080077489A1 (en) 2006-09-21 2008-03-27 Apple Inc. Rewards systems
US8078497B1 (en) 2006-09-21 2011-12-13 Google Inc. Distinguishing search results associated with an electronic commerce system
US7802719B2 (en) 2006-09-29 2010-09-28 Sony Ericsson Mobile Communications Ab System and method for presenting multiple transaction options in a portable device
US7660749B2 (en) 2006-09-29 2010-02-09 Apple Inc. Method, system, and medium for representing visitor activity in an online store
US20080082424A1 (en) 2006-09-29 2008-04-03 Matthew Walton System for optimizing pickup of goods by a purchaser from a vendor using location-based advertising
US20080228646A1 (en) 2006-10-04 2008-09-18 Myers James R Method and system for managing a non-changing payment card account number
WO2008045354A2 (en) 2006-10-05 2008-04-17 Richard Zollino Method for analyzing credit card transaction data
CN1928907A (zh) 2006-10-13 2007-03-14 钟杨 一种利用移动终端设备进行交易支付方法、系统及装置
EP2097864A4 (en) 2006-10-24 2011-10-05 Mastercard International Inc METHOD AND APPARATUS FOR AWARDS TRANSFER, DISCOUNT AND INTERSECTION AT THE INTERACTION PLACE
US20080103795A1 (en) 2006-10-25 2008-05-01 Microsoft Corporation Lightweight and heavyweight interfaces to federated advertising marketplace
US7669760B1 (en) 2006-10-31 2010-03-02 United Services Automobile Association (Usaa) GPS validation for transactions
EP1921578A1 (en) 2006-11-13 2008-05-14 Yellow One Asset Management Ltd. Payment method and system between the buyer and seller by means of a third party
US20080114737A1 (en) 2006-11-14 2008-05-15 Daniel Neely Method and system for automatically identifying users to participate in an electronic conversation
US20080114639A1 (en) 2006-11-15 2008-05-15 Microsoft Corporation User interaction-biased advertising
AP3361A (en) 2006-11-16 2015-07-31 Net1 Ueps Technologies Inc Secure financial transactions
US20090037255A1 (en) 2006-12-06 2009-02-05 Leo Chiu Behavior aggregation
US7878393B2 (en) 2006-12-07 2011-02-01 Moneygram International, Inc. Method and apparatus for distribution of money transfers
WO2008070781A2 (en) 2006-12-07 2008-06-12 Ticketmaster L.L.C. Methods and systems for access control using a networked turnstele
US7848980B2 (en) 2006-12-26 2010-12-07 Visa U.S.A. Inc. Mobile payment system and method using alias
US10311427B2 (en) 2006-12-29 2019-06-04 Google Technology Holdings LLC Method and system for monitoring secure application execution events during contactless RFID/NFC communication
US20090006262A1 (en) 2006-12-30 2009-01-01 Brown Kerry D Financial transaction payment processor
US20080167965A1 (en) 2007-01-09 2008-07-10 Von Nothaus Bernard Apparatus, system, and method for extracting real world value from a virtual account
US8452277B2 (en) 2007-01-11 2013-05-28 David A. Hurowitz Data delivered to targeted mobile device
US20080172331A1 (en) 2007-01-16 2008-07-17 Graves Phillip C Bill Payment Card Method and System
CA2575063C (en) 2007-01-16 2017-07-11 Bernard Jobin Method and system for developing and evaluating and marketing products through use of intellectual capital derivative rights
US20080177574A1 (en) 2007-01-22 2008-07-24 Marcos Lara Gonzalez Systems and Methods To Improve The Efficiencies Of Immunization Registries
US20080177672A1 (en) 2007-01-23 2008-07-24 Robert Brunner Method for managing liability
US7676434B2 (en) 2007-01-28 2010-03-09 Bora Payment Systems, Llc Payer direct hub
US7841539B2 (en) 2007-02-15 2010-11-30 Alfred Hewton Smart card with random temporary account number generation
US20080201264A1 (en) 2007-02-17 2008-08-21 Brown Kerry D Payment card financial transaction authenticator
US20090018895A1 (en) 2007-03-12 2009-01-15 Lee S. Weinblatt Technique for correlating purchasing behavior of a consumer to advertisements
US20080223918A1 (en) 2007-03-15 2008-09-18 Microsoft Corporation Payment tokens
WO2008137204A1 (en) 2007-03-20 2008-11-13 Massachusetts Institute Of Technology Modulator for frequency-shift keying of optical signals
US20080235261A1 (en) 2007-03-21 2008-09-25 Microsoft Corporation Generating a new file using instance information
US7963441B2 (en) 2007-03-26 2011-06-21 Sears Brands, Llc System and method for providing self service checkout and product delivery using a mobile device
US7962418B1 (en) 2007-03-30 2011-06-14 Amazon Technologies, Inc. System and method of fulfilling a transaction
US8214079B2 (en) 2007-03-30 2012-07-03 Sungkyunkwan University Foundation For Corporate Collaboration Central information processing system and method for service robot having layered information structure according to recognition and reasoning level
US20080243702A1 (en) 2007-03-30 2008-10-02 Ricoh Company, Ltd. Tokens Usable in Value-Based Transactions
US7896238B2 (en) 2007-04-03 2011-03-01 Intellectual Ventures Holding 32 Llc Secured transaction using color coded account identifiers
US7938318B2 (en) 2007-04-03 2011-05-10 Intellectual Ventures Holding 32 Llc System and method for controlling secured transaction using directionally coded account identifiers
US8156543B2 (en) 2007-04-17 2012-04-10 Visa U.S.A. Method and system for authenticating a party to a transaction
US8706914B2 (en) 2007-04-23 2014-04-22 David D. Duchesneau Computing infrastructure
US7784685B1 (en) 2007-04-26 2010-08-31 United Services Automobile Association (Usaa) Secure card
US7959076B1 (en) 2007-04-26 2011-06-14 United Services Automobile Association (Usaa) Secure card
US8109436B1 (en) 2007-04-26 2012-02-07 United Services Automobile Association (Usaa) Secure card
US20080288376A1 (en) 2007-04-27 2008-11-20 Cashedge, Inc. Centralized payment hub method and system
US8688570B2 (en) 2007-04-27 2014-04-01 American Express Travel Related Services Company, Inc. System and method for performing person-to-person funds transfers via wireless communications
US8131592B2 (en) 2007-04-27 2012-03-06 Sojern, Inc. Method and system for providing targeted content with verification information
US20080272188A1 (en) 2007-05-02 2008-11-06 I4 Commerce Inc. Distributed system for commerce
US20080221945A1 (en) 2007-05-16 2008-09-11 Robert Pace Ecosystem allowing compliance with prescribed requirements or objectives
US7770789B2 (en) 2007-05-17 2010-08-10 Shift4 Corporation Secure payment card transactions
US7841523B2 (en) 2007-05-17 2010-11-30 Shift4 Corporation Secure payment card transactions
EP2156397B1 (en) 2007-05-17 2019-06-26 Shift4 Corporation Secure payment card transactions
US7891563B2 (en) 2007-05-17 2011-02-22 Shift4 Corporation Secure payment card transactions
US20080300980A1 (en) * 2007-05-31 2008-12-04 Goodstorm, Inc. Method and system of synchronizing data processed through web widgets distributed across network nodes
US20080301055A1 (en) 2007-05-31 2008-12-04 Microsoft Corporation unified platform for reputation and secure transactions
GB2450193A (en) 2007-06-12 2008-12-17 Cvon Innovations Ltd Method and system for managing credits via a mobile device
US7971261B2 (en) 2007-06-12 2011-06-28 Microsoft Corporation Domain management for digital media
US9483769B2 (en) 2007-06-20 2016-11-01 Qualcomm Incorporated Dynamic electronic coupon for a mobile environment
US7739169B2 (en) 2007-06-25 2010-06-15 Visa U.S.A. Inc. Restricting access to compromised account information
CN101075316A (zh) * 2007-06-25 2007-11-21 陆航程 一种电子票证交易认证管理方法、载体结构、系统、终端
US8121942B2 (en) 2007-06-25 2012-02-21 Visa U.S.A. Inc. Systems and methods for secure and transparent cardless transactions
US7756755B2 (en) 2007-06-28 2010-07-13 Hewlett-Packard Devlopment Company, L.P. Capturing and utilizing consumer purchase intent information
JP2009015548A (ja) 2007-07-04 2009-01-22 Omron Corp 運転支援装置および方法、並びに、プログラム
US8527404B2 (en) 2007-07-19 2013-09-03 First Data Corporation Merchant-initiated adjustments
US8327450B2 (en) 2007-07-19 2012-12-04 Wells Fargo Bank N.A. Digital safety deposit box
US8151328B1 (en) 2007-07-20 2012-04-03 Sprint Communications Company L.P. Accessing secure network areas by utilizing mobile-device authentication
US20090037326A1 (en) 2007-07-30 2009-02-05 Sriram Chitti Virtual Card Selector for a Portable Electronic Device
US8195233B2 (en) 2007-07-30 2012-06-05 Motorola Mobility, Inc. Methods and systems for identity management in wireless devices
US8326758B2 (en) 2007-08-06 2012-12-04 Enpulz, L.L.C. Proxy card representing many monetary sources from a plurality of vendors
US8494959B2 (en) 2007-08-17 2013-07-23 Emc Corporation Payment card with dynamic account number
US8788278B2 (en) 2007-08-28 2014-07-22 Moneygram International, Inc. Consumer database loyalty program for a money transfer system
US7849014B2 (en) 2007-08-29 2010-12-07 American Express Travel Related Services Company, Inc. System and method for facilitating a financial transaction with a dynamically generated identifier
US9070129B2 (en) 2007-09-04 2015-06-30 Visa U.S.A. Inc. Method and system for securing data fields
US8667422B2 (en) 2007-09-04 2014-03-04 Apple Inc. Graphical user interface with location-specific interface elements
US9268849B2 (en) 2007-09-07 2016-02-23 Alexander Siedlecki Apparatus and methods for web marketing tools for digital archives—web portal advertising arts
US8041338B2 (en) 2007-09-10 2011-10-18 Microsoft Corporation Mobile wallet and digital payment
US8341083B1 (en) 2007-09-12 2012-12-25 Devicefidelity, Inc. Wirelessly executing financial transactions
CN101388125A (zh) 2007-09-12 2009-03-18 上海亿动信息技术有限公司 一种用户终端控制自动售物设备售物的控制系统以及方法
US7937324B2 (en) 2007-09-13 2011-05-03 Visa U.S.A. Inc. Account permanence
US20090076953A1 (en) 2007-09-18 2009-03-19 First Data Corporation ATM/Debit Expedited Bill Payments
US20090083065A1 (en) 2007-09-24 2009-03-26 Discover Financial Services Llc Automatic Substantiation of Health-Related Purchases Using a HIPAA-Unregulated Network
US8249654B1 (en) 2007-09-27 2012-08-21 Sprint Communications Company L.P. Dynamic smart card application loading
US8175235B2 (en) 2007-09-27 2012-05-08 Verizon Patent And Licensing Inc. Lease model for avoiding permanent card locking
US10679196B2 (en) 2007-09-28 2020-06-09 The Western Union Company Bill payment aggregation service
US7707113B1 (en) 2007-09-28 2010-04-27 Sprint Communications Company L.P. Method and system for setting levels of electronic wallet security
US8108261B2 (en) 2007-10-01 2012-01-31 Apple Inc. Store affiliation system
US8515840B2 (en) 2007-10-02 2013-08-20 American Express Travel Related Services Company, Inc. Modular electronic wallet
US9747598B2 (en) 2007-10-02 2017-08-29 Iii Holdings 1, Llc Dynamic security code push
US8565723B2 (en) 2007-10-17 2013-10-22 First Data Corporation Onetime passwords for mobile wallets
US8095113B2 (en) 2007-10-17 2012-01-10 First Data Corporation Onetime passwords for smart chip cards
US20090106151A1 (en) 2007-10-17 2009-04-23 Mark Allen Nelsen Fraud prevention based on risk assessment rule
US8157178B2 (en) 2007-10-19 2012-04-17 First Data Corporation Manufacturing system to produce contactless devices with switches
US20090106160A1 (en) 2007-10-19 2009-04-23 First Data Corporation Authorizations for mobile contactless payment transactions
US8214291B2 (en) 2007-10-19 2012-07-03 Ebay Inc. Unified identity verification
US20090112767A1 (en) 2007-10-25 2009-04-30 Ayman Hammad Escrow system and method
US7774076B2 (en) 2007-10-29 2010-08-10 First Data Corporation System and method for validation of transactions
CN101425894B (zh) 2007-10-30 2012-03-21 阿里巴巴集团控股有限公司 一种业务实现系统及方法
US20090108080A1 (en) 2007-10-31 2009-04-30 Payscan America, Inc. Bar coded monetary transaction system and method
CA2643621A1 (en) 2007-11-02 2009-05-02 Citicorp Credit Services, Inc. Methods and systems for interchange adjustment
US11244289B2 (en) 2007-11-02 2022-02-08 Citicorp Credit Services, Inc. (Usa) Methods and systems for managing financial institution customer accounts
US8494978B2 (en) 2007-11-02 2013-07-23 Ebay Inc. Inferring user preferences from an internet based social interactive construct
US20100023457A1 (en) 2007-11-09 2010-01-28 Barclays Capital Inc. Methods and systems for tracking commodity performance
US20090132366A1 (en) 2007-11-15 2009-05-21 Microsoft Corporation Recognizing and crediting offline realization of online behavior
US8249985B2 (en) 2007-11-29 2012-08-21 Bank Of America Corporation Sub-account mechanism
US20090144104A1 (en) 2007-11-30 2009-06-04 Scott Kevin Johnson System and Method of Selectively Notifying Consumers of Product Recalls
US9299078B2 (en) 2007-11-30 2016-03-29 Datalogix, Inc. Targeting messages
US20090157555A1 (en) 2007-12-12 2009-06-18 American Express Travel Related Services Company, Bill payment system and method
US8145569B2 (en) 2007-12-13 2012-03-27 Google Inc. Multiple party on-line transactions
US8117129B2 (en) 2007-12-21 2012-02-14 American Express Travel Related Services Company, Inc. Systems, methods and computer program products for performing mass transit merchant transactions
JP2009151730A (ja) 2007-12-22 2009-07-09 Duaxes Corp 会計管理装置
US8011577B2 (en) 2007-12-24 2011-09-06 Dynamics Inc. Payment cards and devices with gift card, global integration, and magnetic stripe reader communication functionality
US8585503B2 (en) 2007-12-26 2013-11-19 Scientific Games Holdings Limited System and method for collecting and using player information
US7837125B2 (en) 2007-12-27 2010-11-23 Apple Inc. Methods and systems for encoding a magnetic stripe
US8224702B2 (en) 2007-12-28 2012-07-17 Ebay, Inc. Systems and methods for facilitating financial transactions over a network
US8214288B2 (en) 2007-12-28 2012-07-03 Ebay Inc. System and method of a passphrase account identifier for use in a network environment
US10262303B2 (en) 2007-12-28 2019-04-16 Mastercard International Incorporated Methods and systems for applying a rewards program promotion to payment transactions
US7958052B2 (en) 2007-12-31 2011-06-07 Mastercard International Incorporated Methods and systems for cardholder initiated transactions
US7922082B2 (en) 2008-01-04 2011-04-12 M2 International Ltd. Dynamic card validation value
US20090182664A1 (en) 2008-01-15 2009-07-16 Trombley Austin D Integrating social networking with financial services
US20090241159A1 (en) 2008-03-18 2009-09-24 Avaya Technology Llc Open cable application platform set-top box (stb) personal profiles and communications applications
JP2009176259A (ja) 2008-01-24 2009-08-06 Katsumi Tanaka Ｑｒコードを使った無人駐車場自動取引決済システム
FR2926938B1 (fr) 2008-01-28 2010-03-19 Paycool Dev Procede d'authentification et de signature d'un utilisateur aupres d'un service applicatif, utilisant un telephone mobile comme second facteur en complement et independamment d'un premier facteur
US9558485B2 (en) 2008-01-30 2017-01-31 Paypal, Inc. Two step near field communication transactions
US11159909B2 (en) 2008-02-05 2021-10-26 Victor Thomas Anderson Wireless location establishing device
US8401900B2 (en) 2008-02-14 2013-03-19 At&T Intellectual Property I, Lp System and method for presenting advertising data based on end user trick-play trend data
CN101231727A (zh) 2008-02-20 2008-07-30 深圳矽感科技有限公司 一种电子支票支付方法及其实现系统
US8255971B1 (en) 2008-03-03 2012-08-28 Jpmorgan Chase Bank, N.A. Authentication system and method
US8396582B2 (en) 2008-03-08 2013-03-12 Tokyo Electron Limited Method and apparatus for self-learning and self-improving a semiconductor manufacturing tool
US20100063903A1 (en) 2008-03-10 2010-03-11 Thayne Whipple Hierarchically applied rules engine ("hare")
US7707089B1 (en) 2008-03-12 2010-04-27 Jpmorgan Chase, N.A. Method and system for automating fraud authorization strategies
US8285643B2 (en) 2008-06-12 2012-10-09 Monncello Enterprises, LLC System and method for processing gift cards
US8060413B2 (en) 2008-03-14 2011-11-15 Research In Motion Limited System and method for making electronic payments from a wireless mobile device
US20090234751A1 (en) 2008-03-14 2009-09-17 Eric Chan Electronic wallet for a wireless mobile device
US8321338B2 (en) 2008-03-21 2012-11-27 First Data Corporation Electronic network access device
US20090240620A1 (en) 2008-03-24 2009-09-24 Propay Usa, Inc. Secure payment system
US8578176B2 (en) 2008-03-26 2013-11-05 Protegrity Corporation Method and apparatus for tokenization of sensitive sets of characters
ES2436117T3 (es) 2008-03-27 2013-12-27 Motorola Mobility Llc Método y aparato para la selección automática de aplicaciones en un dispositivo electrónico utilizando múltiples administradores de descubrimiento
US7967196B1 (en) 2008-03-28 2011-06-28 Sprint Communications Company L.P. Electronic wallet ready to pay timer
US20090248583A1 (en) 2008-03-31 2009-10-01 Jasmeet Chhabra Device, system, and method for secure online transactions
US8271506B2 (en) 2008-03-31 2012-09-18 Yahoo! Inc. System and method for modeling relationships between entities
US8301500B2 (en) 2008-04-02 2012-10-30 Global 1 Enterprises Ghosting payment account data in a mobile telephone payment transaction system
US8175979B2 (en) 2008-04-02 2012-05-08 International Business Machines Corporation Method and system for anonymous electronic transactions using a mobile device
US20090254535A1 (en) 2008-04-02 2009-10-08 International Business Machines Corporation Search engine to improve product recall traceability activities
US20090254471A1 (en) 2008-04-03 2009-10-08 Seidel Peter Stuart Settlement of futures contracts in foreign currencies
US20090271246A1 (en) 2008-04-28 2009-10-29 American Express Travel Related Services Company, Inc. Merchant recommendation system and method
US20090271265A1 (en) 2008-04-28 2009-10-29 Cyndigo, Corp. Electronic receipt system and method
US20090327131A1 (en) 2008-04-29 2009-12-31 American Express Travel Related Services Company, Inc. Dynamic account authentication using a mobile device
US7890370B2 (en) 2008-04-30 2011-02-15 Target Brands, Inc. Using alerts to bring attention to in-store information
US8180705B2 (en) 2008-04-30 2012-05-15 Intuit Inc. Method and apparatus for initiating a funds transfer using a mobile device
US7630937B1 (en) 2008-04-30 2009-12-08 Intuit Inc. Method and system for processing a financial transaction
US20090276347A1 (en) 2008-05-01 2009-11-05 Kargman James B Method and apparatus for use of a temporary financial transaction number or code
US9715709B2 (en) 2008-05-09 2017-07-25 Visa International Services Association Communication device including multi-part alias identifier
US8209744B2 (en) 2008-05-16 2012-06-26 Microsoft Corporation Mobile device assisted secure computer network communication
AU2009249272B2 (en) * 2008-05-18 2014-11-20 Google Llc Secured electronic transaction system
US20100004989A1 (en) 2008-05-20 2010-01-07 American Express Travel Related Services Company, Inc. Systems, methods, apparatus and computer program products for interfacing payment systems to a network associated with a referral
US8745166B2 (en) 2008-05-28 2014-06-03 Visa U.S.A. Inc. Gateway service platform
US8176554B1 (en) 2008-05-30 2012-05-08 Symantec Corporation Malware detection through symbol whitelisting
EP2728528A1 (en) 2008-05-30 2014-05-07 MR.QR10 GmbH & Co. KG Server device for controlling a transaction, first entity and second entity
US8651374B2 (en) 2008-06-02 2014-02-18 Sears Brands, L.L.C. System and method for payment card industry enterprise account number elimination
US20100106642A1 (en) 2008-06-05 2010-04-29 Namedepot.Com, Inc. Method and system for delayed payment of prepaid cards
US8117085B1 (en) 2008-06-05 2012-02-14 Amazon Technologies, Inc. Data mining processes for supporting item pair recommendations
US20090307140A1 (en) 2008-06-06 2009-12-10 Upendra Mardikar Mobile device over-the-air (ota) registration and point-of-sale (pos) payment
US20090307060A1 (en) 2008-06-09 2009-12-10 Merz Christopher J Methods and systems for determining a loyalty profile for a financial transaction cardholder
US8788350B2 (en) 2008-06-13 2014-07-22 Microsoft Corporation Handling payment receipts with a receipt store
WO2009158417A1 (en) 2008-06-25 2009-12-30 Visa U.S.A. Inc. Generating retail sales report
US20090327088A1 (en) 2008-06-26 2009-12-31 Utstarcom, Inc. System and Method for performing International Transactions
US20100042456A1 (en) 2008-07-07 2010-02-18 Incentalign, Inc. Integrated market-based allocation of resources within an enterprise
US9824366B2 (en) 2008-07-08 2017-11-21 First Data Corporation Customer pre-selected electronic coupons
CN102089759A (zh) 2008-07-09 2011-06-08 凯森公司 生成用于输入分析模型的分析数据集的方法
CN101625779A (zh) 2008-07-11 2010-01-13 深圳富泰宏精密工业有限公司 移动终端及通过该移动终端进行信用卡消费的方法
US9269010B2 (en) 2008-07-14 2016-02-23 Jumio Inc. Mobile phone payment system using integrated camera credit card reader
US8295898B2 (en) 2008-07-22 2012-10-23 Bank Of America Corporation Location based authentication of mobile device transactions
US20100023386A1 (en) 2008-07-23 2010-01-28 Sol Avisar Social networking platform for intellectual property assets
US8285640B2 (en) 2008-07-23 2012-10-09 Ebay, Inc. System and methods for facilitating fund transfers over a network
US8229853B2 (en) 2008-07-24 2012-07-24 International Business Machines Corporation Dynamic itinerary-driven profiling for preventing unauthorized card transactions
US8090650B2 (en) 2008-07-24 2012-01-03 At&T Intellectual Property I, L.P. Secure payment service and system for interactive voice response (IVR) systems
US8219489B2 (en) 2008-07-29 2012-07-10 Visa U.S.A. Inc. Transaction processing using a global unique identifier
US8227936B1 (en) 2008-07-31 2012-07-24 Bank Of America Corporation Cash handling device having integrated uninterruptible power supply
US20100036741A1 (en) 2008-08-04 2010-02-11 Marc Cleven Application currency code for dynamic currency conversion transactions with contactless consumer transaction payment device
US9053474B2 (en) 2008-08-04 2015-06-09 At&T Mobility Ii Llc Systems and methods for handling point-of-sale transactions using a mobile device
US8281991B2 (en) 2008-08-07 2012-10-09 Visa U.S.A. Inc. Transaction secured in an untrusted environment
US20100036775A1 (en) 2008-08-08 2010-02-11 Edens Corey D Foreign currency gain/loss analysis for foreign currency exposure management
US20100036884A1 (en) 2008-08-08 2010-02-11 Brown Robert G Correlation engine for generating anonymous correlations between publication-restricted data and personal attribute data
US8744959B2 (en) 2008-08-13 2014-06-03 Moneygram International, Inc. Electronic bill payment with variable payment options
US8175975B2 (en) 2008-08-18 2012-05-08 Alcatel Lucent IMS device operable for financial transaction authorization and ID cards display
WO2010027739A2 (en) 2008-08-27 2010-03-11 Globys, Inc. Targeted customer offers based on predictive analytics
US8255324B2 (en) 2008-09-02 2012-08-28 Ebay Inc. Systems and methods for facilitating financial transactions over a network with a gateway adapter
US8403211B2 (en) 2008-09-04 2013-03-26 Metabank System, program product and methods for retail activation and reload associated with partial authorization transactions
US10970777B2 (en) 2008-09-15 2021-04-06 Mastercard International Incorporated Apparatus and method for bill payment card enrollment
US20100076873A1 (en) 2008-09-22 2010-03-25 Wachovia Corporation Fee refund management
US20100082490A1 (en) 2008-09-30 2010-04-01 Apple Inc. Systems and methods for secure wireless transactions
US20100078471A1 (en) 2008-09-30 2010-04-01 Apple Inc. System and method for processing peer-to-peer financial transactions
US9037513B2 (en) 2008-09-30 2015-05-19 Apple Inc. System and method for providing electronic event tickets
US20100078472A1 (en) 2008-09-30 2010-04-01 Apple Inc. Group peer-to-peer financial transactions
US20100082455A1 (en) 2008-09-30 2010-04-01 Apple Inc. Real-time bargain hunting
US20100082485A1 (en) 2008-09-30 2010-04-01 Apple Inc. Portable point of purchase devices and methods
US10380573B2 (en) 2008-09-30 2019-08-13 Apple Inc. Peer-to-peer financial transaction devices and methods
US8215546B2 (en) 2008-09-30 2012-07-10 Apple Inc. System and method for transportation check-in
US9026462B2 (en) 2008-09-30 2015-05-05 Apple Inc. Portable point of purchase user interfaces
US20100082445A1 (en) 2008-09-30 2010-04-01 Apple Inc. Smart menu options
US8239276B2 (en) 2008-09-30 2012-08-07 Apple Inc. On-the-go shopping list
US8965811B2 (en) 2008-10-04 2015-02-24 Mastercard International Incorporated Methods and systems for using physical payment cards in secure E-commerce transactions
WO2010042560A2 (en) 2008-10-06 2010-04-15 Vivotech, Inc. Systems, methods, and computer readable media for payment and non-payment virtual card transfer between mobile devices
KR101632438B1 (ko) 2008-10-07 2016-06-21 삼성전자주식회사 사용자 맞춤형 휴대 광고 서비스를 제공하는 시스템 및 방법
KR20110073502A (ko) 2008-10-08 2011-06-29 톰톰 인터내셔날 비.브이. 이미지 데이터를 기록하기 위한 내비게이션 장치 및 방법
US20100094755A1 (en) 2008-10-09 2010-04-15 Nelnet Business Solutions, Inc. Providing payment data tokens for online transactions utilizing hosted inline frames
US8131666B2 (en) 2008-10-21 2012-03-06 Fmr Llc Context-based user authentication, workflow processing, and data management in a centralized application in communication with a plurality of third-party applications
US20100106644A1 (en) 2008-10-23 2010-04-29 Diversinet Corp. System and Method for Authorizing Transactions Via Mobile Devices
US8126449B2 (en) 2008-11-13 2012-02-28 American Express Travel Related Services Company, Inc. Servicing attributes on a mobile device
US20100121707A1 (en) 2008-11-13 2010-05-13 Buzzient, Inc. Displaying analytic measurement of online social media content in a graphical user interface
US20100125492A1 (en) 2008-11-14 2010-05-20 Apple Inc. System and method for providing contextual advertisements according to dynamic pricing scheme
US20100125516A1 (en) 2008-11-14 2010-05-20 Wankmueller John R Methods and systems for secure mobile device initiated payments
US20100125495A1 (en) 2008-11-17 2010-05-20 Smith Steven M System and method of providing a mobile wallet at a mobile telephone
US20100125803A1 (en) 2008-11-17 2010-05-20 Tyler Johnson Online System for Communications Between Service Providers and Consumers
EP2189932B1 (en) 2008-11-24 2020-07-15 BlackBerry Limited Electronic payment system using mobile wireless communications device and associated methods
US20120101881A1 (en) 2008-11-25 2012-04-26 Mary Theresa Taylor Loyalty promotion apparatuses, methods and systems
US8117127B1 (en) 2008-11-25 2012-02-14 Bank Of America Corporation Currency recycler user roles
US8870089B2 (en) 2008-12-01 2014-10-28 Stubhub, Inc. System and methods for variable distribution and access control for purchased event tickets
US8196813B2 (en) 2008-12-03 2012-06-12 Ebay Inc. System and method to allow access to a value holding account
US8838503B2 (en) 2008-12-08 2014-09-16 Ebay Inc. Unified identity verification
US8151336B2 (en) 2008-12-10 2012-04-03 At&T Intellectual Property Ii, Lp Devices and methods for secure internet transactions
US9032312B2 (en) 2008-12-15 2015-05-12 Mastercard International Incorporated Platform for generating composite applications
US8225997B1 (en) 2008-12-22 2012-07-24 Sprint Communications Company L.P. Single transit card to multiple rider trip methods and architecture
US8376223B2 (en) 2008-12-23 2013-02-19 John S. Woronec Method and apparatus for securely activating a credit card for a limited period of time
US20100162126A1 (en) 2008-12-23 2010-06-24 Palm, Inc. Predictive cache techniques
US20100174599A1 (en) 2009-01-05 2010-07-08 Apple Inc. System and method for providing content associated with a product or service
US8060449B1 (en) 2009-01-05 2011-11-15 Sprint Communications Company L.P. Partially delegated over-the-air provisioning of a secure element
US8145561B1 (en) 2009-01-05 2012-03-27 Sprint Communications Company L.P. Phone usage pattern as credit card fraud detection trigger
US8200582B1 (en) 2009-01-05 2012-06-12 Sprint Communications Company L.P. Mobile device password system
US8255323B1 (en) 2009-01-09 2012-08-28 Apple Inc. Motion based payment confirmation
US8140418B1 (en) 2009-01-09 2012-03-20 Apple Inc. Cardholder-not-present authorization
US8127982B1 (en) 2009-01-09 2012-03-06 Apple Inc. Parental controls
US8150723B2 (en) 2009-01-09 2012-04-03 Yahoo! Inc. Large-scale behavioral targeting for advertising over a network
US8965784B2 (en) 2009-01-14 2015-02-24 Signature Systems Llc Reward exchange method and system implementing data collection and analysis
AU2010204567A1 (en) 2009-01-15 2011-08-11 Visa U.S.A. Inc. Incentives associated with linked financial accounts
US10354321B2 (en) 2009-01-22 2019-07-16 First Data Corporation Processing transactions with an extended application ID and dynamic cryptograms
US8831976B2 (en) 2009-01-22 2014-09-09 Maritz Holdings Inc. System and method for transacting purchases with a cash vendor using points and a virtual credit card
US10037524B2 (en) 2009-01-22 2018-07-31 First Data Corporation Dynamic primary account number (PAN) and unique key per card
US20100191770A1 (en) 2009-01-27 2010-07-29 Apple Inc. Systems and methods for providing a virtual fashion closet
US20100191622A1 (en) 2009-01-28 2010-07-29 Zvi Reiss Distributed Transaction layer
US8893009B2 (en) 2009-01-28 2014-11-18 Headwater Partners I Llc End user device that secures an association of application to service policy with an application certificate check
US8364587B2 (en) 2009-01-28 2013-01-29 First Data Corporation Systems and methods for financial account access for a mobile device via a gateway
US20100198626A1 (en) 2009-02-04 2010-08-05 Apple Inc. Systems and methods for accessing shopping center services using a portable electronic device
CN102326175A (zh) 2009-02-10 2012-01-18 4361423加拿大有限公司 用于使用通信设备进行商业交易的装置和方法
US9721238B2 (en) 2009-02-13 2017-08-01 Visa U.S.A. Inc. Point of interaction loyalty currency redemption in a transaction
US20100211499A1 (en) 2009-02-13 2010-08-19 Bank Of America Corporation Systems, methods and computer program products for optimizing routing of financial payments
US20100211452A1 (en) 2009-02-16 2010-08-19 D Angelo Giovanni Digital voucher processing system
US20100217613A1 (en) 2009-02-26 2010-08-26 Brian Kelly Methods and apparatus for providing charitable content and related functions
US20100217682A1 (en) 2009-02-26 2010-08-26 Research In Motion Limited System and method for capturing user inputs in electronic forms
US8606638B2 (en) 2009-03-02 2013-12-10 First Data Corporation Systems, methods and apparatus for facilitating transactions using a mobile device
US20100235284A1 (en) 2009-03-13 2010-09-16 Gidah, Inc. Method and systems for generating and using tokens in a transaction handling system
US8595098B2 (en) 2009-03-18 2013-11-26 Network Merchants, Inc. Transmission of sensitive customer information during electronic-based transactions
US8255278B1 (en) 2009-03-23 2012-08-28 United Services Automobile Association Systems and methods for payment at a point of sale using a virtual check
US8567670B2 (en) 2009-03-27 2013-10-29 Intersections Inc. Dynamic card verification values and credit transactions
US8317090B2 (en) 2009-03-27 2012-11-27 Mastercard International Incorporated Methods and systems for performing a financial transaction
US8799060B2 (en) * 2009-03-30 2014-08-05 Transactis, Inc Method for electronic coupon creation, deployment, transference, validation management, clearance, redemption and reporting system and and method for interactive participation of individuals and groups with coupons
US8214292B2 (en) 2009-04-01 2012-07-03 American Express Travel Related Services Company, Inc. Post-authorization message for a financial transaction
US8584251B2 (en) 2009-04-07 2013-11-12 Princeton Payment Solutions Token-based payment processing system
US20100258620A1 (en) 2009-04-10 2010-10-14 Denise Torreyson Methods and systems for linking multiple accounts
US8762275B2 (en) 2009-04-15 2014-06-24 First Data Corporation Systems and methods providing multiple account holder functionality
US9572025B2 (en) 2009-04-16 2017-02-14 Telefonaktiebolaget Lm Ericsson (Publ) Method, server, computer program and computer program product for communicating with secure element
WO2010126509A2 (en) 2009-04-30 2010-11-04 Donald Michael Cardina Systems and methods for randomized mobile payment
US8423462B1 (en) 2009-05-01 2013-04-16 Amazon Technologies, Inc. Real-time mobile wallet server
US20100276484A1 (en) 2009-05-01 2010-11-04 Ashim Banerjee Staged transaction token for merchant rating
US8751628B2 (en) 2009-05-05 2014-06-10 Suboti, Llc System and method for processing user interface events
US20100293032A1 (en) 2009-05-12 2010-11-18 Motorola, Inc. System and method for sharing commercial information
US8725122B2 (en) 2009-05-13 2014-05-13 First Data Corporation Systems and methods for providing trusted service management services
US8356001B2 (en) 2009-05-19 2013-01-15 Xybersecure, Inc. Systems and methods for application-level security
US8583511B2 (en) 2009-05-19 2013-11-12 Bradley Marshall Hendrickson Systems and methods for storing customer purchasing and preference data and enabling a customer to pre-register orders and events
US10140598B2 (en) 2009-05-20 2018-11-27 Visa International Service Association Device including encrypted data for expiration date and verification value creation
US9767209B2 (en) 2009-05-28 2017-09-19 Apple Inc. Search filtering based on expected future time and location
US20100306076A1 (en) 2009-05-29 2010-12-02 Ebay Inc. Trusted Integrity Manager (TIM)
US20100306075A1 (en) 2009-06-02 2010-12-02 Apple Inc. Systems and methods for accessing cruise services using a portable electronic device
US20100312645A1 (en) 2009-06-09 2010-12-09 Boku, Inc. Systems and Methods to Facilitate Purchases on Mobile Devices
US8256671B2 (en) 2009-06-09 2012-09-04 Ebay Inc. Progressive categoration and treatment of refund abusers
US8584956B2 (en) 2009-10-13 2013-11-19 Square, Inc. Systems and methods for passive identification circuitry
CN101924690B (zh) 2009-06-10 2012-10-03 华为技术有限公司 一种数据路由方法及设备
US8191775B2 (en) 2009-06-16 2012-06-05 Ncr Corporation Gift card account system and methods of a merchant processing a gift card
US8396750B1 (en) 2009-06-16 2013-03-12 Amazon Technologies, Inc. Method and system for using recommendations to prompt seller improvement
US8244559B2 (en) 2009-06-26 2012-08-14 Microsoft Corporation Cloud computing resource broker
US20100332283A1 (en) 2009-06-29 2010-12-30 Apple Inc. Social networking in shopping environments
US8020763B1 (en) 2009-06-30 2011-09-20 Intuit Inc. Method and system for assessing merchant risk during payment transaction
US20110004498A1 (en) 2009-07-01 2011-01-06 International Business Machines Corporation Method and System for Identification By A Cardholder of Credit Card Fraud
TWI402775B (zh) 2009-07-16 2013-07-21 Mxtran Inc 金融交易系統、自動櫃員機、與操作自動櫃員機的方法
US20110035273A1 (en) 2009-08-05 2011-02-10 Yahoo! Inc. Profile recommendations for advertisement campaign performance improvement
CA2770893A1 (en) 2009-08-10 2011-02-17 Visa International Service Association Systems and methods for enrolling users in a payment service
CN201532668U (zh) 2009-08-12 2010-07-21 钒创科技股份有限公司 电子钱包装置
US20110047075A1 (en) 2009-08-19 2011-02-24 Mastercard International Incorporated Location controls on payment card transactions
US20110047018A1 (en) 2009-08-21 2011-02-24 Valassis Communications, Inc. Offer Management Method And System
US20110047076A1 (en) 2009-08-24 2011-02-24 Mark Carlson Alias reputation interaction system
US8090351B2 (en) 2009-09-01 2012-01-03 Elliot Klein Geographical location authentication method
US8214289B2 (en) 2009-09-29 2012-07-03 Ebay Inc. Short codes for bill pay
US20110082789A1 (en) 2009-10-06 2011-04-07 Apple Inc. Vendor payment consolidation system
US20110083018A1 (en) 2009-10-06 2011-04-07 Validity Sensors, Inc. Secure User Authentication
US8447699B2 (en) 2009-10-13 2013-05-21 Qualcomm Incorporated Global secure service provider directory
KR20110040604A (ko) 2009-10-14 2011-04-20 삼성전자주식회사 클라우드 서버, 클라이언트 단말, 디바이스, 클라우드 서버의 동작 방법 및 클라이언트 단말의 동작 방법
WO2011047331A2 (en) 2009-10-16 2011-04-21 Visa International Service Association Anti-phishing system and method including list with user data
US20110093335A1 (en) 2009-10-19 2011-04-21 Visa U.S.A. Inc. Systems and Methods for Advertising Services Based on an SKU-Level Profile
US20110099057A1 (en) 2009-10-22 2011-04-28 Jet Lithocolor, Inc. System and method for using a card having a 2d barcode to direct a consumer to content on a global communications network
US20110246317A1 (en) 2009-10-23 2011-10-06 Apriva, Llc System and device for facilitating a transaction through use of a proxy account code
US8296568B2 (en) 2009-10-27 2012-10-23 Google Inc. Systems and methods for authenticating an electronic transaction
US20110099507A1 (en) 2009-10-28 2011-04-28 Google Inc. Displaying a collection of interactive elements that trigger actions directed to an item
US8433116B2 (en) 2009-11-03 2013-04-30 Mela Sciences, Inc. Showing skin lesion information
CA2780059C (en) 2009-11-06 2021-03-09 Edatanetworks Inc. Method, system, and computer program for attracting local and regional businesses to an automated cause marketing environment
US20110137740A1 (en) 2009-12-04 2011-06-09 Ashmit Bhattacharya Processing value-ascertainable items
US20110137742A1 (en) 2009-12-09 2011-06-09 Ebay Inc. Payment using unique product identifier codes
US8595812B2 (en) 2009-12-18 2013-11-26 Sabre Inc. Tokenized data security
US10255591B2 (en) 2009-12-18 2019-04-09 Visa International Service Association Payment channel returning limited use proxy dynamic value
US9324066B2 (en) 2009-12-21 2016-04-26 Verizon Patent And Licensing Inc. Method and system for providing virtual credit card services
US8170921B2 (en) 2009-12-29 2012-05-01 Ebay, Inc. Dynamic hosted shopping cart
US8788429B2 (en) 2009-12-30 2014-07-22 First Data Corporation Secure transaction management
CN101800762B (zh) 2009-12-30 2014-03-19 中兴通讯股份有限公司 一种对多个业务进行融合的业务云系统及业务实现方法
CN101789151A (zh) 2009-12-31 2010-07-28 中兴通讯股份有限公司 移动终端电子钱包的应用方法及移动终端
CN109118241A (zh) 2010-01-19 2019-01-01 维萨国际服务协会 远程可变认证处理
US8417575B2 (en) 2010-01-19 2013-04-09 Apple Inc. On-device offline purchases using credits
CN102754116B (zh) 2010-01-19 2016-08-03 维萨国际服务协会 基于令牌的交易认证
US9367834B2 (en) 2010-01-22 2016-06-14 Iii Holdings 1, Llc Systems, methods, and computer products for processing payments using a proxy card
DE112011100329T5 (de) 2010-01-25 2012-10-31 Andrew Peter Nelson Jerram Vorrichtungen, Verfahren und Systeme für eine Digitalkonversationsmanagementplattform
US8615468B2 (en) 2010-01-27 2013-12-24 Ca, Inc. System and method for generating a dynamic card value
JP5446944B2 (ja) 2010-01-29 2014-03-19 富士通株式会社 光ネットワークおよびその制御方法
KR20130009754A (ko) 2010-02-01 2013-01-23 점프탭, 인크. 통합형 광고 시스템
US9501773B2 (en) 2010-02-02 2016-11-22 Xia Dai Secured transaction system
CN102143290B (zh) 2010-02-03 2014-08-20 中兴通讯股份有限公司 一种对等网络中网络电话业务的中转节点选择方法及系统
US20110208852A1 (en) 2010-02-25 2011-08-25 Looney Erin C Regionally-Tiered Internet Banner Delivery and Platform for Transaction Fulfillment of E-Commerce
WO2011106716A1 (en) 2010-02-25 2011-09-01 Secureauth Corporation Security device provisioning
US8458487B1 (en) 2010-03-03 2013-06-04 Liaison Technologies, Inc. System and methods for format preserving tokenization of sensitive information
US9245267B2 (en) 2010-03-03 2016-01-26 Visa International Service Association Portable account number for consumer payment account
JP2011186660A (ja) 2010-03-05 2011-09-22 Yasushi Sato 電子商取引システム、決済サーバ、およびプログラム
EP2545508A4 (en) 2010-03-07 2014-01-29 Gilbarco Inc PAYMENT SYSTEM FOR CONTAINER COLUMNS
US7971782B1 (en) 2010-03-08 2011-07-05 Apple Inc. Multi-point transaction system
US20110218870A1 (en) 2010-03-08 2011-09-08 Apple Inc. Communication method for a roaming point-of-sale system
US8282002B2 (en) 2010-03-08 2012-10-09 Apple Inc. Multi-barcode scan process
FR2957266B1 (fr) 2010-03-11 2012-04-20 Parrot Procede et appareil de telecommande d'un drone, notamment d'un drone a voilure tournante.
US8402555B2 (en) 2010-03-21 2013-03-19 William Grecia Personalized digital media access system (PDMAS)
US8887308B2 (en) 2010-03-21 2014-11-11 William Grecia Digital cloud access (PDMAS part III)
US8533860B1 (en) 2010-03-21 2013-09-10 William Grecia Personalized digital media access system—PDMAS part II
US8140403B2 (en) 2010-03-23 2012-03-20 Amazon Technologies, Inc. User profile and geolocation for efficient transactions
US20110238573A1 (en) 2010-03-25 2011-09-29 Computer Associates Think, Inc. Cardless atm transaction method and system
US9922354B2 (en) 2010-04-02 2018-03-20 Apple Inc. In application purchasing
US8380177B2 (en) 2010-04-09 2013-02-19 Paydiant, Inc. Mobile phone payment processing methods and systems
WO2011130228A2 (en) 2010-04-12 2011-10-20 Google Inc. Scrolling in large hosted data set
US9558494B2 (en) 2010-04-19 2017-01-31 Tokenex, L.L.C. Devices, systems, and methods for tokenizing sensitive information
US8180804B1 (en) 2010-04-19 2012-05-15 Facebook, Inc. Dynamically generating recommendations based on social graph information
US20110282780A1 (en) 2010-04-19 2011-11-17 Susan French Method and system for determining fees and foreign exchange rates for a value transfer transaction
US8336088B2 (en) 2010-04-19 2012-12-18 Visa International Service Association Alias management and value transfer claim processing
US8626921B2 (en) 2010-04-22 2014-01-07 Cisco Technology, Inc. Device and service management based on layer 2 through layer 7 device attributes
US20110270665A1 (en) 2010-04-29 2011-11-03 Visa U.S.A. Expiring Virtual Gift Card Statement Credit Exchange for Loyalty Reward
US8355987B2 (en) 2010-05-06 2013-01-15 Boku, Inc. Systems and methods to manage information
CN101840550A (zh) 2010-05-17 2010-09-22 李黎明 实现账单现场生成和支付的方法
US9014848B2 (en) 2010-05-20 2015-04-21 Irobot Corporation Mobile robot system
US8364959B2 (en) 2010-05-26 2013-01-29 Google Inc. Systems and methods for using a domain-specific security sandbox to facilitate secure transactions
US8856901B2 (en) 2010-05-26 2014-10-07 Marcel Van Os Digital handshake for authentication of devices
WO2011150369A2 (en) 2010-05-27 2011-12-01 Vivotech Inc. Methods, systems and computer readable media for utilizing a consumer opt-in management system
CN102939613A (zh) 2010-06-04 2013-02-20 维萨国际服务协会 支付令牌化装置、方法和系统
US8069088B1 (en) 2010-06-04 2011-11-29 Google Inc. Method and system for crediting a retailer for an internet purchase
WO2011156832A1 (en) 2010-06-13 2011-12-22 Bnc Ventures B.V. Method and system for managing customer relationships
US8328642B2 (en) 2010-06-16 2012-12-11 Zynga Inc. Game based incentives for commerce
US20110320300A1 (en) 2010-06-23 2011-12-29 Managed Audience Share Solutions LLC Methods, Systems, and Computer Program Products For Managing Organized Binary Advertising Asset Markets
US8442913B2 (en) 2010-06-29 2013-05-14 Visa International Service Association Evolving payment device
US20110320345A1 (en) 2010-06-29 2011-12-29 Ebay, Inc. Smart wallet
US8595312B2 (en) 2010-06-30 2013-11-26 Microsafe Sa De Cv Master device detecting or host computer detecting new device attempting to connect to controller area network (CAN)
US8442914B2 (en) 2010-07-06 2013-05-14 Mastercard International Incorporated Virtual wallet account with automatic-loading
US8571939B2 (en) 2010-07-07 2013-10-29 Toshiba Global Commerce Solutions Holdings Corporation Two phase payment link and authorization for mobile devices
US8453226B2 (en) 2010-07-16 2013-05-28 Visa International Service Association Token validation for advanced authorization
US10269057B2 (en) 2010-07-19 2019-04-23 Payme, Inc. Mobile system and method for payments and non-financial transactions
WO2012012445A2 (en) 2010-07-19 2012-01-26 Universal Commerce, Inc. Mobile system and method for payments and non-financial transactions
JP5518615B2 (ja) 2010-07-27 2014-06-11 株式会社日本総合研究所 決済システム、決済方法および決済プログラム
US20120028609A1 (en) 2010-07-27 2012-02-02 John Hruska Secure financial transaction system using a registered mobile device
US8751395B2 (en) 2010-08-03 2014-06-10 Moneygram International, Inc. Verification methods for fraud prevention in money transfer receive transactions
US9342832B2 (en) 2010-08-12 2016-05-17 Visa International Service Association Securing external systems with account token substitution
CN101973031B (zh) 2010-08-24 2013-07-24 中国科学院深圳先进技术研究院 云机器人系统及实现方法
WO2012027694A2 (en) 2010-08-27 2012-03-01 Visa International Service Association Account number based bill payment platform apparatuses, methods and systems
CN101958025B (zh) 2010-09-06 2014-06-18 广东铭鸿数据有限公司 一种应用条码技术的手机支付方法、现场支付终端及系统
CN101938520B (zh) 2010-09-07 2015-01-28 中兴通讯股份有限公司 一种基于移动终端签名的远程支付系统及方法
US20120066078A1 (en) 2010-09-10 2012-03-15 Bank Of America Corporation Overage service using overage passcode
CN101945127B (zh) 2010-09-10 2012-11-14 华中科技大学 一种VoIP系统中的语音动态中转方法
US20120066065A1 (en) 2010-09-14 2012-03-15 Visa International Service Association Systems and Methods to Segment Customers
US9760943B2 (en) 2010-09-17 2017-09-12 Mastercard International Incorporated Methods, systems, and computer readable media for preparing and delivering an ordered product upon detecting a customer presence
US8898086B2 (en) 2010-09-27 2014-11-25 Fidelity National Information Services Systems and methods for transmitting financial account information
US20120095852A1 (en) 2010-10-15 2012-04-19 John Bauer Method and system for electronic wallet access
US9558481B2 (en) 2010-09-28 2017-01-31 Barclays Bank Plc Secure account provisioning
WO2012050927A2 (en) 2010-09-28 2012-04-19 Beyond Oblivion Inc. Content discovery and delivery platform apparatuses, methods and systems
US11055693B2 (en) 2010-09-30 2021-07-06 Mastercard International Incorporated Methods, systems and computer readable media for issuing and redeeming co-branded electronic certificates
US8458079B2 (en) 2010-10-14 2013-06-04 Morgan Stanley Computer-implemented systems and methods for determining liquidity cycle for tradable financial products and for determining flow-weighted average pricing for same
US20120095865A1 (en) 2010-10-15 2012-04-19 Ezpayy, Inc. System And Method For Mobile Electronic Purchasing
US20120239556A1 (en) 2010-10-20 2012-09-20 Magruder Andrew M Latency payment settlement apparatuses, methods and systems
US20120209677A1 (en) 2010-10-20 2012-08-16 Mehta Kaushal N Person-2-person social network marketing apparatuses, methods and systems
US20120109728A1 (en) 2010-10-29 2012-05-03 Google Inc. Incentives for media sharing
US8589355B2 (en) 2010-10-29 2013-11-19 International Business Machines Corporation Data storage in a cloud
US8424756B2 (en) 2010-11-11 2013-04-23 Apple Inc. Combined business/gift card with redemption notification
US10176477B2 (en) 2010-11-16 2019-01-08 Mastercard International Incorporated Methods and systems for universal payment account translation
US20120265685A1 (en) 2010-11-17 2012-10-18 Sequent Software Inc. System and Method for Physical-World Based Dynamic Contactless Data Emulation in a Portable Communication Device
US8577336B2 (en) 2010-11-18 2013-11-05 Mobilesphere Holdings LLC System and method for transaction authentication using a mobile communication device
US20130275308A1 (en) 2010-11-29 2013-10-17 Mobay Technologies Limited System for verifying electronic transactions
US9141945B2 (en) 2010-12-02 2015-09-22 Appmobi Iplc, Inc. Secure distributed single action payment system
US8312096B2 (en) 2010-12-08 2012-11-13 Google Inc. Priority inbox notifications and synchronization for mobile messaging application
AU2011343618A1 (en) 2010-12-15 2013-05-30 Visa International Service Association Social media payment platform apparatuses, methods and systems
US8762284B2 (en) 2010-12-16 2014-06-24 Democracyontheweb, Llc Systems and methods for facilitating secure transactions
US8646059B1 (en) 2010-12-17 2014-02-04 Google Inc. Wallet application for interacting with a secure element application without a trusted server for authentication
US20120158792A1 (en) 2010-12-17 2012-06-21 Microsoft Corporation Aggregated profile and online concierge
US8335921B2 (en) 2010-12-17 2012-12-18 Google, Inc. Writing application data to a secure element
US8352749B2 (en) 2010-12-17 2013-01-08 Google Inc. Local trusted services manager for a contactless smart card
US9691055B2 (en) 2010-12-17 2017-06-27 Google Inc. Digital wallet
US8645491B2 (en) 2010-12-18 2014-02-04 Qualcomm Incorporated Methods and apparatus for enabling a hybrid web and native application
WO2012085675A2 (en) 2010-12-20 2012-06-28 Eram Antonio Claudiu System, method and apparatus for mobile payments enablement and order fulfillment
US9292368B2 (en) 2010-12-27 2016-03-22 Verizon Patent And Licensing Inc. Method and apparatus for invoking native functions of a mobile device to control a set-top box
TW201227190A (en) 2010-12-28 2012-07-01 Hon Hai Prec Ind Co Ltd System and method for controlling robots via cloud computing
US20120173431A1 (en) 2010-12-30 2012-07-05 First Data Corporation Systems and methods for using a token as a payment in a transaction
US8200868B1 (en) 2010-12-30 2012-06-12 Google Inc. Peripheral device detection with short-range communication
KR20120077000A (ko) 2010-12-30 2012-07-10 한국전자통신연구원 확장필드를 응용한 온라인 애플리케이션 장치 및 방법
US20130218657A1 (en) 2011-01-11 2013-08-22 Diane Salmon Universal value exchange apparatuses, methods and systems
US20120185386A1 (en) 2011-01-18 2012-07-19 Bank Of America Authentication tool
WO2012098555A1 (en) 2011-01-20 2012-07-26 Google Inc. Direct carrier billing
US8725644B2 (en) 2011-01-28 2014-05-13 The Active Network, Inc. Secure online transaction processing
US8195576B1 (en) 2011-01-31 2012-06-05 Bank Of America Corporation Mobile transaction device security system
US20120197691A1 (en) 2011-01-31 2012-08-02 Bank Of America Corporation Mobile wallet payment vehicle preferences
US20120197794A1 (en) 2011-01-31 2012-08-02 Bank Of America Corporation Shared mobile wallet
US10204327B2 (en) 2011-02-05 2019-02-12 Visa International Service Association Merchant-consumer bridging platform apparatuses, methods and systems
US20120203664A1 (en) 2011-02-09 2012-08-09 Tycoon Unlimited, Inc. Contactless wireless transaction processing system
US20120203666A1 (en) 2011-02-09 2012-08-09 Tycoon Unlimited, Inc. Contactless wireless transaction processing system
US20120203695A1 (en) 2011-02-09 2012-08-09 American Express Travel Related Services Company, Inc. Systems and methods for facilitating secure transactions
US20120209749A1 (en) 2011-02-16 2012-08-16 Ayman Hammad Snap mobile payment apparatuses, methods and systems
CN103635920A (zh) 2011-02-22 2014-03-12 维萨国际服务协会 通用电子付款装置、方法与系统
US20130024364A1 (en) 2011-02-22 2013-01-24 Abhinav Shrivastava Consumer transaction leash control apparatuses, methods and systems
US8521607B2 (en) 2011-02-22 2013-08-27 Ricoh Company, Ltd. Archiving system and process for transaction records
US20130024371A1 (en) 2011-02-22 2013-01-24 Prakash Hariramani Electronic offer optimization and redemption apparatuses, methods and systems
US8751381B2 (en) 2011-02-23 2014-06-10 Mastercard International Incorporated Demand deposit account payment system
US9773212B2 (en) 2011-02-28 2017-09-26 Visa International Service Association Secure anonymous transaction apparatuses, methods and systems
US20120239417A1 (en) 2011-03-04 2012-09-20 Pourfallah Stacy S Healthcare wallet payment processing apparatuses, methods and systems
KR101895243B1 (ko) 2011-03-04 2018-10-24 비자 인터네셔널 서비스 어소시에이션 지불 능력을 컴퓨터들의 보안 엘리먼트들에 통합
US20120233004A1 (en) 2011-03-11 2012-09-13 James Bercaw System for mobile electronic commerce
US20120231844A1 (en) 2011-03-11 2012-09-13 Apriva, Llc System and device for facilitating a transaction by consolidating sim, personal token, and associated applications for electronic wallet transactions
US20120246071A1 (en) 2011-03-21 2012-09-27 Nikhil Jain System and method for presentment of nonconfidential transaction token identifier
AU2012201745B2 (en) 2011-03-24 2014-11-13 Visa International Service Association Authentication using application authentication element
US20130218765A1 (en) 2011-03-29 2013-08-22 Ayman Hammad Graduated security seasoning apparatuses, methods and systems
US20130144785A1 (en) 2011-03-29 2013-06-06 Igor Karpenko Social network payment authentication apparatuses, methods and systems
US20120254108A1 (en) 2011-03-30 2012-10-04 Microsoft Corporation Synchronization Of Data For A Robotic Device
US9280765B2 (en) 2011-04-11 2016-03-08 Visa International Service Association Multiple tokenization for authentication
US9818111B2 (en) 2011-04-15 2017-11-14 Shift4 Corporation Merchant-based token sharing
WO2012142370A2 (en) 2011-04-15 2012-10-18 Shift4 Corporation Method and system for enabling merchants to share tokens
US8688589B2 (en) 2011-04-15 2014-04-01 Shift4 Corporation Method and system for utilizing authorization factor pools
US9256874B2 (en) 2011-04-15 2016-02-09 Shift4 Corporation Method and system for enabling merchants to share tokens
US8412630B2 (en) 2011-04-15 2013-04-02 Bank Of America Corporation Social network payment settlement system
WO2012145530A2 (en) 2011-04-20 2012-10-26 Visa International Service Association Managing electronic tokens in a transaction processing system
US8527360B2 (en) 2011-04-29 2013-09-03 Daon Holdings Limited Methods and systems for conducting payment transactions
US20120284035A1 (en) 2011-05-02 2012-11-08 Relay Network, Llc Method and Apparatus for Registering Closed and Open Loop Prepaid Gift Cards and Other Prepaid Card Products
US20130110658A1 (en) 2011-05-05 2013-05-02 Transaction Network Services, Inc. Systems and methods for enabling mobile payments
US8386078B1 (en) 2011-05-06 2013-02-26 Google Inc. Methods and systems for providing a data library for robotic devices
US8380349B1 (en) 2011-05-06 2013-02-19 Google Inc. Methods and systems for providing instructions to a robotic device
CN102779304A (zh) 2011-05-10 2012-11-14 中国联合网络通信集团有限公司 电子钱包中赠予金额的处理方法及服务器
US20130204793A1 (en) 2011-05-17 2013-08-08 Kevin S. Kerridge Smart communication device secured electronic payment system
US9137304B2 (en) 2011-05-25 2015-09-15 Alcatel Lucent Method and apparatus for achieving data security in a distributed cloud computing environment
US9106633B2 (en) 2011-05-26 2015-08-11 First Data Corporation Systems and methods for authenticating mobile device communications
US8943574B2 (en) 2011-05-27 2015-01-27 Vantiv, Llc Tokenizing sensitive data
US10395256B2 (en) 2011-06-02 2019-08-27 Visa International Service Association Reputation management in a transaction processing system
US8538845B2 (en) 2011-06-03 2013-09-17 Mozido, Llc Monetary transaction system
BR112013031147A2 (pt) 2011-06-03 2017-02-07 Visa Int Service Ass aparelhos, métodos e sistema de seleção de cartão de carteira virtual
RU2602394C2 (ru) 2011-06-07 2016-11-20 Виза Интернешнл Сервис Ассосиэйшн Устройства, способы и системы токенизации конфиденциальности платежей
US10318932B2 (en) 2011-06-07 2019-06-11 Entit Software Llc Payment card processing system with structure preserving encryption
WO2012167941A1 (en) 2011-06-09 2012-12-13 Gemalto Sa Method to validate a transaction between a user and a service provider
US8620901B2 (en) 2011-06-09 2013-12-31 Salesforce.Com, Inc. Methods and systems for processing graphs using distributed memory and set operations
US20120323664A1 (en) 2011-06-16 2012-12-20 Apple Inc. Integrated coupon storage, discovery, and redemption system
US8326769B1 (en) 2011-07-01 2012-12-04 Google Inc. Monetary transfer in a social network
US9355393B2 (en) 2011-08-18 2016-05-31 Visa International Service Association Multi-directional wallet connector apparatuses, methods and systems
AU2012278963B2 (en) 2011-07-05 2017-02-23 Visa International Service Association Electronic wallet checkout platform apparatuses, methods and systems
US9582598B2 (en) 2011-07-05 2017-02-28 Visa International Service Association Hybrid applications utilizing distributed models and views apparatuses, methods and systems
US20130159081A1 (en) 2011-07-08 2013-06-20 Vishwanath Shastry Bidirectional bandwidth reducing notifications and targeted incentive platform apparatuses, methods and systems
US8893008B1 (en) 2011-07-12 2014-11-18 Relationship Science LLC Allowing groups expanded connectivity to entities of an information service
US9639828B2 (en) 2011-07-15 2017-05-02 Visa International Service Association Method and system for hosted order page/silent order post plus fraud detection
WO2013019567A2 (en) 2011-07-29 2013-02-07 Visa International Service Association Passing payment tokens through an hop/sop
US20150154588A1 (en) 2011-08-18 2015-06-04 Visa International Service Association Reversed User Account Generation Apparatuses, Methods and Systems
US9710807B2 (en) 2011-08-18 2017-07-18 Visa International Service Association Third-party value added wallet features and interfaces apparatuses, methods and systems
US20130054337A1 (en) 2011-08-22 2013-02-28 American Express Travel Related Services Company, Inc. Methods and systems for contactless payments for online ecommerce checkout
US20130218769A1 (en) 2011-08-23 2013-08-22 Stacy Pourfallah Mobile Funding Method and System
WO2013028901A2 (en) 2011-08-23 2013-02-28 Visa International Service Association Authentication process for value transfer machine
US10032171B2 (en) 2011-08-30 2018-07-24 Simplytapp, Inc. Systems and methods for secure application-based participation in an interrogation by mobile device
US20130339253A1 (en) 2011-08-31 2013-12-19 Dan Moshe Sincai Mobile Device Based Financial Transaction System
US8171525B1 (en) 2011-09-15 2012-05-01 Google Inc. Enabling users to select between secure service providers using a central trusted service manager
US8838982B2 (en) 2011-09-21 2014-09-16 Visa International Service Association Systems and methods to secure user identification
US20130080238A1 (en) 2011-09-22 2013-03-28 Bryan Kelly Method and System for Operating a Customer or Player Loyalty System Including a Portable Device Such as a Smartcard
US8453223B2 (en) 2011-09-23 2013-05-28 Jerome Svigals Method, device and system for secure transactions
US8180289B1 (en) 2011-09-26 2012-05-15 Google Inc. Public kiosk providing near field communication services
US8878794B2 (en) 2011-09-27 2014-11-04 Z124 State of screen info: easel
US20130085877A1 (en) 2011-09-30 2013-04-04 Andreas Rührig Intermediary-based transaction system
WO2013048538A1 (en) 2011-10-01 2013-04-04 Intel Corporation Cloud based credit card emulation
CN104106276B (zh) 2011-10-12 2019-03-19 万事达移动交易方案公司 多层安全移动交易使能平台
US20130103574A1 (en) 2011-10-19 2013-04-25 First Data Corporation Payment Delegation Transaction Processing
US9229964B2 (en) 2011-10-27 2016-01-05 Visa International Business Machines Corporation Database cloning and migration for quality assurance
CA2854277C (en) 2011-11-01 2016-06-07 Jvl Ventures, Llc Systems, methods, and computer program products for managing secure elements
US9830596B2 (en) 2011-11-01 2017-11-28 Stripe, Inc. Method for conducting a transaction between a merchant site and a customer's electronic device without exposing payment information to a server-side application of the merchant site
US20130117126A1 (en) 2011-11-07 2013-05-09 Apriva, Llc System and method for secure management of customer data in a loyalty program
US20130124364A1 (en) 2011-11-13 2013-05-16 Millind Mittal System and method of electronic payment using payee provided transaction identification codes
US9165321B1 (en) 2011-11-13 2015-10-20 Google Inc. Optimistic receipt flow
US8401904B1 (en) 2011-11-13 2013-03-19 Google Inc. Real-time payment authorization
WO2013075071A1 (en) 2011-11-18 2013-05-23 Ayman Hammad Mobile wallet store and service injection platform apparatuses, methods and systems
US9348896B2 (en) 2011-12-05 2016-05-24 Visa International Service Association Dynamic network analytics system
US9152947B2 (en) 2011-12-05 2015-10-06 Sap Portals Isreal Ltd Real-time social networking
US8555079B2 (en) 2011-12-06 2013-10-08 Wwpass Corporation Token management
US8656180B2 (en) 2011-12-06 2014-02-18 Wwpass Corporation Token activation
US8972719B2 (en) 2011-12-06 2015-03-03 Wwpass Corporation Passcode restoration
WO2013090611A2 (en) 2011-12-13 2013-06-20 Visa International Service Association Dynamic widget generator apparatuses, methods and systems
US20130159178A1 (en) 2011-12-14 2013-06-20 Firethorn Mobile, Inc. System and Method For Loading A Virtual Token Managed By A Mobile Wallet System
US20130159184A1 (en) 2011-12-15 2013-06-20 Visa International Service Association System and method of using load network to associate product or service with a consumer token
US8788340B2 (en) 2011-12-16 2014-07-22 Facebook, Inc. Advertisement based on application-created social content
US20140040139A1 (en) 2011-12-19 2014-02-06 Sequent Software, Inc. System and method for dynamic temporary payment authorization in a portable communication device
EP2795549A4 (en) 2011-12-21 2015-09-23 Mastercard International Inc METHOD AND SYSTEMS FOR PROVIDING A PAYMENT ACCOUNT WITH ADAPTIVE REPLACEMENT
US9077769B2 (en) 2011-12-29 2015-07-07 Blackberry Limited Communications system providing enhanced trusted service manager (TSM) verification features and related methods
US20130254117A1 (en) 2011-12-30 2013-09-26 Clay W. von Mueller Secured transaction system and method
US8566168B1 (en) 2012-01-05 2013-10-22 Sprint Communications Company L.P. Electronic payment using a proxy account number stored in a secure element
RU2017131424A (ru) 2012-01-05 2019-02-06 Виза Интернэшнл Сервис Ассосиэйшн Защита данных с переводом
JP6153947B2 (ja) 2012-01-05 2017-06-28 ヴィザ インターナショナル サーヴィス アソシエイション 取引映像キャプチャ装置、方法およびシステム
EP2801063A4 (en) 2012-01-06 2015-08-05 David S Kidder SYSTEM AND METHOD FOR ADVERTISING SOFTWARE MANAGEMENT AND CLIENT RELATIONSHIP MANAGEMENT
US8812396B2 (en) 2012-01-09 2014-08-19 Mastercard International Incorporated E-wallet with cross-border capability
US8839087B1 (en) 2012-01-26 2014-09-16 Amazon Technologies, Inc. Remote browsing and searching
WO2013113004A1 (en) 2012-01-26 2013-08-01 Visa International Service Association System and method of providing tokenization as a service
US10643191B2 (en) 2012-01-27 2020-05-05 Visa International Service Association Mobile services remote deposit capture
US8595850B2 (en) 2012-01-30 2013-11-26 Voltage Security, Inc. System for protecting sensitive data with distributed tokenization
US9218624B2 (en) 2012-02-03 2015-12-22 Paypal, Inc. Adding card to mobile/cloud wallet using NFC
EP2624190A1 (en) 2012-02-03 2013-08-07 Pieter Dubois Authentication of payment transactions using an alias
US8321364B1 (en) 2012-02-08 2012-11-27 Google Inc. Method and system for including robots into social networks
US20130204776A1 (en) 2012-02-08 2013-08-08 F. Charles King E-commerce Payment and Delivery System and Method
US8893250B2 (en) 2012-02-10 2014-11-18 Protegrity Corporation Tokenization in mobile environments
US20130212017A1 (en) 2012-02-14 2013-08-15 N.B. Development Services Inc. Transaction system and method of conducting a transaction
US20130226813A1 (en) 2012-02-23 2013-08-29 Robert Matthew Voltz Cyberspace Identification Trust Authority (CITA) System and Method
US20130246199A1 (en) 2012-03-14 2013-09-19 Mark Carlson Point-of-transaction account feature redirection apparatuses, methods and systems
US9092776B2 (en) 2012-03-15 2015-07-28 Qualcomm Incorporated System and method for managing payment in transactions with a PCD
US20130246267A1 (en) 2012-03-15 2013-09-19 Ebay Inc. Systems, Methods, and Computer Program Products for Using Proxy Accounts
US9105021B2 (en) 2012-03-15 2015-08-11 Ebay, Inc. Systems, methods, and computer program products for using proxy accounts
US20130246259A1 (en) 2012-03-15 2013-09-19 Firethorn Mobile, Inc. System and method for managing payment in transactions with a pcd
US20130254102A1 (en) 2012-03-20 2013-09-26 First Data Corporation Systems and Methods for Distributing Tokenization and De-Tokenization Services
US9818098B2 (en) 2012-03-20 2017-11-14 First Data Corporation Systems and methods for facilitating payments via a peer-to-peer protocol
US20130254028A1 (en) 2012-03-22 2013-09-26 Corbuss Kurumsal Telekom Hizmetleri A.S. System and method for conducting mobile commerce
US20130262315A1 (en) 2012-03-30 2013-10-03 John Hruska System for Secure Purchases Made by Scanning Barcode Using a Registered Mobile Phone Application Linked to a Consumer-Merchant Closed Loop Financial Proxy Account System
US10515359B2 (en) 2012-04-02 2019-12-24 Mastercard International Incorporated Systems and methods for processing mobile payments by provisioning credentials to mobile devices without secure elements
WO2013151807A1 (en) 2012-04-02 2013-10-10 Jvl Ventures, Llc Systems, methods, and computer program products for provisioning payment accounts into mobile wallets and managing events
US10528944B2 (en) 2012-04-13 2020-01-07 Mastercard International Incorporated Systems, methods, and computer readable media for conducting a transaction using cloud based credentials
CA2869208C (en) 2012-04-18 2015-11-17 Google, Inc. Processing payment transactions without a secure element
US20130282588A1 (en) 2012-04-22 2013-10-24 John Hruska Consumer, Merchant and Mobile Device Specific, Real-Time Dynamic Tokenization Activation within a Secure Mobile-Wallet Financial Transaction System
US8639621B1 (en) 2012-04-25 2014-01-28 Wells Fargo Bank, N.A. System and method for a mobile wallet
US10275764B2 (en) 2012-05-04 2019-04-30 Mastercard International Incorporated Transaction data tokenization
WO2013166501A1 (en) 2012-05-04 2013-11-07 Visa International Service Association System and method for local data conversion
US8484133B1 (en) 2012-05-18 2013-07-09 MoviePass Inc. Secure targeted personal buying/selling method and system
US20130311382A1 (en) 2012-05-21 2013-11-21 Klaus S. Fosmark Obtaining information for a payment transaction
US9521548B2 (en) 2012-05-21 2016-12-13 Nexiden, Inc. Secure registration of a mobile device for use with a session
WO2013179271A2 (en) 2012-06-01 2013-12-05 Mani Venkatachalam Sthanu Subra Method and system for human assisted secure payment by phone to an insecure third-party service provider
US20130325579A1 (en) 2012-06-04 2013-12-05 Visa International Service Association Systems and methods to process loyalty benefits
US9524501B2 (en) 2012-06-06 2016-12-20 Visa International Service Association Method and system for correlating diverse transaction data
US10089625B2 (en) 2012-06-13 2018-10-02 First Data Corporation Systems and methods for tokenizing financial information
US20130346302A1 (en) 2012-06-20 2013-12-26 Visa International Service Association Remote Portal Bill Payment Platform Apparatuses, Methods and Systems
US20130346305A1 (en) 2012-06-26 2013-12-26 Carta Worldwide Inc. Mobile wallet payment processing
US20140007213A1 (en) 2012-06-29 2014-01-02 Wepay, Inc. Systems and methods for push notification based application authentication and authorization
US9092773B2 (en) 2012-06-30 2015-07-28 At&T Intellectual Property I, L.P. Generating and categorizing transaction records
US20140006283A1 (en) 2012-07-02 2014-01-02 Serve Virtual Enterprises, Inc. Systems and methods for managing multiple identifiers
WO2014008403A1 (en) 2012-07-03 2014-01-09 Visa International Service Association Data protection hub
US9059972B2 (en) 2012-07-03 2015-06-16 International Business Machines Corporation Issuing, presenting and challenging mobile device identification documents
US9043609B2 (en) 2012-07-19 2015-05-26 Bank Of America Corporation Implementing security measures for authorized tokens used in mobile transactions
US20140025585A1 (en) 2012-07-19 2014-01-23 Bank Of America Corporation Distributing authorized tokens to conduct mobile transactions
US20140025581A1 (en) 2012-07-19 2014-01-23 Bank Of America Corporation Mobile transactions using authorized tokens
US9846861B2 (en) 2012-07-25 2017-12-19 Visa International Service Association Upstream and downstream data conversion
US9256871B2 (en) 2012-07-26 2016-02-09 Visa U.S.A. Inc. Configurable payment tokens
US10339524B2 (en) 2012-07-31 2019-07-02 Worldpay, Llc Systems and methods for multi-merchant tokenization
US10152711B2 (en) 2012-07-31 2018-12-11 Worldpay, Llc Systems and methods for arbitraged enhanced payment processing
US10346838B2 (en) 2012-07-31 2019-07-09 Worldpay, Llc Systems and methods for distributed enhanced payment processing
DK2885904T3 (en) 2012-08-03 2018-08-06 Onespan Int Gmbh PROCEDURE FOR USER-EASY AUTHENTICATION AND DEVICE USING A MOBILE APPLICATION FOR AUTHENTICATION
US9665722B2 (en) 2012-08-10 2017-05-30 Visa International Service Association Privacy firewall
US9130932B2 (en) 2012-08-13 2015-09-08 Cellco Partnership Hybrid network application architecture
WO2014028926A1 (en) 2012-08-17 2014-02-20 Google Inc. Wireless reader and payment transaction terminal functionality
CN104704505B (zh) 2012-08-28 2018-04-17 维萨国际服务协会 保护设备上的资产
US8560004B1 (en) 2012-08-31 2013-10-15 Google Inc. Sensor-based activation of an input device
AU2013315510B2 (en) 2012-09-11 2019-08-22 Visa International Service Association Cloud-based Virtual Wallet NFC Apparatuses, methods and systems
US9699272B2 (en) 2012-09-29 2017-07-04 Oracle International Corporation Mechanism for initiating behavior in a native client application from a web client application via a custom URL scheme
US9390412B2 (en) 2012-10-16 2016-07-12 Visa International Service Association Dynamic point of sale system integrated with reader device
CA3126471A1 (en) 2012-10-17 2014-04-17 Royal Bank Of Canada Virtualization and secure processing of data
US10176478B2 (en) 2012-10-23 2019-01-08 Visa International Service Association Transaction initiation determination system utilizing transaction data elements
US9910833B2 (en) 2012-11-13 2018-03-06 International Business Machines Corporation Automatically rendering web and/or hybrid applications natively in parallel
US9911118B2 (en) 2012-11-21 2018-03-06 Visa International Service Association Device pairing via trusted intermediary
US20140164243A1 (en) 2012-12-07 2014-06-12 Christian Aabye Dynamic Account Identifier With Return Real Account Identifier
US9741051B2 (en) 2013-01-02 2017-08-22 Visa International Service Association Tokenization and third-party interaction
US9249241B2 (en) 2013-03-27 2016-02-02 Ut-Battelle, Llc Surface-functionalized mesoporous carbon materials
US20140310183A1 (en) 2013-04-15 2014-10-16 Lance Weber Embedded acceptance system
US20140331265A1 (en) 2013-05-01 2014-11-06 Microsoft Corporation Integrated interactive television entertainment system
US20140330722A1 (en) 2013-05-02 2014-11-06 Prasanna Laxminarayanan System and method for using an account sequence identifier
US11055710B2 (en) 2013-05-02 2021-07-06 Visa International Service Association Systems and methods for verifying and processing transactions using virtual currency
US9760886B2 (en) 2013-05-10 2017-09-12 Visa International Service Association Device provisioning using partial personalization scripts
WO2014183213A1 (en) 2013-05-13 2014-11-20 Gpvtl Canada Inc. Dynamic rendering for software applications
US9978062B2 (en) 2013-05-15 2018-05-22 Visa International Service Association Mobile tokenization hub
US10878422B2 (en) 2013-06-17 2020-12-29 Visa International Service Association System and method using merchant token
KR102442663B1 (ko) 2013-07-15 2022-09-13 비자 인터네셔널 서비스 어소시에이션 보안 원격 지불 거래 처리
KR102070451B1 (ko) 2013-07-24 2020-01-28 비자 인터네셔널 서비스 어소시에이션 상호운영 가능한 네트워크 토큰 처리 시스템 및 방법
US10496986B2 (en) 2013-08-08 2019-12-03 Visa International Service Association Multi-network tokenization processing
AU2014306259A1 (en) 2013-08-08 2016-02-25 Visa International Service Association Methods and systems for provisioning mobile devices with payment credentials
KR102428897B1 (ko) 2013-08-15 2022-08-04 비자 인터네셔널 서비스 어소시에이션 보안 요소를 이용한 보안 원격 지불 거래 처리
US9740676B2 (en) 2013-09-20 2017-08-22 Oracle International Corporation Automatic column resizing
AU2014321178A1 (en) 2013-09-20 2016-04-14 Visa International Service Association Secure remote payment transaction processing including consumer authentication
US9978094B2 (en) 2013-10-11 2018-05-22 Visa International Service Association Tokenization revocation list
CA2927052C (en) 2013-10-11 2021-09-21 Visa International Service Association Network token system
US10515358B2 (en) 2013-10-18 2019-12-24 Visa International Service Association Contextual transaction token methods and systems
US10489779B2 (en) 2013-10-21 2019-11-26 Visa International Service Association Multi-network token bin routing with defined verification parameters
US10366387B2 (en) 2013-10-29 2019-07-30 Visa International Service Association Digital wallet system and method
US20150127529A1 (en) 2013-11-05 2015-05-07 Oleg Makhotin Methods and systems for mobile payment application selection and management using an application linker
US20150142673A1 (en) 2013-11-18 2015-05-21 Mark Nelsen Methods and systems for token request management
SG10201900029SA (en) 2013-11-19 2019-02-27 Visa Int Service Ass Automated account provisioning
US9626351B2 (en) 2013-11-26 2017-04-18 Oracle International Corporation Status viewer
US20150161597A1 (en) 2013-12-09 2015-06-11 Kaushik Subramanian Transactions using temporary credential data
RU2686014C1 (ru) 2013-12-19 2019-04-23 Виза Интернэшнл Сервис Ассосиэйшн Способы и системы облачных транзакций
US10445718B2 (en) 2013-12-27 2019-10-15 Visa International Service Association Processing a transaction using multiple application identifiers
US10108409B2 (en) 2014-01-03 2018-10-23 Visa International Service Association Systems and methods for updatable applets
US10433128B2 (en) 2014-01-07 2019-10-01 Visa International Service Association Methods and systems for provisioning multiple devices
US20150199679A1 (en) 2014-01-13 2015-07-16 Karthikeyan Palanisamy Multiple token provisioning
US9846878B2 (en) 2014-01-14 2017-12-19 Visa International Service Association Payment account identifier system
CA2936985A1 (en) 2014-02-04 2015-08-13 Visa International Service Association Token verification using limited use certificates
US20150269566A1 (en) 2014-03-18 2015-09-24 Ajit Gaddam Systems and methods for locally derived tokens
CA2888078C (en) 2014-04-14 2023-10-17 Edatanetworks Inc. Systems and methods for loyalty programs
US9942043B2 (en) 2014-04-23 2018-04-10 Visa International Service Association Token security on a communication device
SG10202007850WA (en) 2014-05-05 2020-09-29 Visa Int Service Ass System and method for token domain control
CN106462843A (zh) 2014-05-13 2017-02-22 维萨国际服务协会 用于安全远程支付处理的主小应用程序
US10467689B2 (en) 2014-05-20 2019-11-05 Paypal, Inc. Unified payment account establishment and incorporation in a main payment account
US11023890B2 (en) 2014-06-05 2021-06-01 Visa International Service Association Identification and verification for provisioning mobile application
US9780953B2 (en) 2014-07-23 2017-10-03 Visa International Service Association Systems and methods for secure detokenization
US9779345B2 (en) 2014-08-11 2017-10-03 Visa International Service Association Mobile device with scannable image including dynamic data
CN111756533B (zh) 2014-08-29 2023-07-04 维萨国际服务协会 用于安全密码生成的系统、方法和存储介质
AU2015319804B2 (en) 2014-09-26 2019-03-14 Visa International Service Association Remote server encrypted data provisioning system and methods
US11257074B2 (en) 2014-09-29 2022-02-22 Visa International Service Association Transaction risk based token
US9448972B2 (en) 2014-10-09 2016-09-20 Wrap Media, LLC Wrap package of cards supporting transactional advertising
WO2016058006A1 (en) 2014-10-10 2016-04-14 Visa International Service Association Methods and systems for partial personalization during mobile application update
US10015147B2 (en) 2014-10-22 2018-07-03 Visa International Service Association Token enrollment system and method
US9524089B1 (en) 2014-10-30 2016-12-20 Amazon Technologies, Inc. Common web component
US11501288B2 (en) 2016-02-09 2022-11-15 Visa International Service Association Resource provider account token provisioning and processing
US9904537B2 (en) 2016-04-19 2018-02-27 Dropbox, Inc. Providing a hybrid application
US10447759B2 (en) 2016-05-27 2019-10-15 Microsoft Technology Licensing, Llc Web page accelerations for web application hosted in native mobile application
US10509779B2 (en) 2016-09-14 2019-12-17 Visa International Service Association Self-cleaning token vault
WO2021056397A1 (zh) 2019-09-27 2021-04-01 瑞湾科技（珠海）有限公司 一种离子控制和质量分析装置

Also Published As

Publication number Publication date
WO2012116125A1 (en) 2012-08-30
CN103635920A (zh) 2014-03-12
US20190244192A1 (en) 2019-08-08
US20140337175A1 (en) 2014-11-13
AU2016203811B2 (en) 2017-12-07
AU2016203811A1 (en) 2016-06-30
SG193510A1 (en) 2013-10-30
US11023886B2 (en) 2021-06-01
AU2012220669A1 (en) 2013-05-02
EP2678812A1 (en) 2014-01-01
EP2678812A4 (en) 2015-05-20
US10223691B2 (en) 2019-03-05

Similar Documents

Publication Publication Date Title
US11727392B2 (en) Multi-purpose virtual card transaction apparatuses, methods and systems
US11023886B2 (en) Universal electronic payment apparatuses, methods and systems
US11900359B2 (en) Electronic wallet checkout platform apparatuses, methods and systems
US11093919B2 (en) Merchant-consumer bridging platform apparatuses, methods and systems
US11250352B2 (en) Secure anonymous transaction apparatuses, methods and systems
US10853797B2 (en) Cloud-based virtual wallet NFC apparatuses, methods and systems
RU2602394C2 (ru) Устройства, способы и системы токенизации конфиденциальности платежей
CN106803175B (zh) 快拍移动支付装置，方法和系统
US8577803B2 (en) Virtual wallet card selection apparatuses, methods and systems
US20130024364A1 (en) Consumer transaction leash control apparatuses, methods and systems
US20130024371A1 (en) Electronic offer optimization and redemption apparatuses, methods and systems
US20130166332A1 (en) Mobile wallet store and service injection platform apparatuses, methods and systems
US20130159081A1 (en) Bidirectional bandwidth reducing notifications and targeted incentive platform apparatuses, methods and systems
AU2017202809A1 (en) Social media payment platform apparatuses, methods and systems
WO2014011691A1 (en) Multi-purpose virtual card transaction apparatuses, methods and systems
WO2013009660A1 (en) Bidirectional bandwidth reducing notifications and targeted incentive platform apparatuses, methods and systems
WO2013049329A1 (en) Electronic offer optimization and redemption apparatuses, methods and systems
WO2013044175A1 (en) Consumer transaction leash control apparatuses, methods and systems

Legal Events

Date Code Title Description
B06U Preliminary requirement: requests with searches performed by other patent offices: procedure suspended [chapter 6.21 patent gazette]
B11B Dismissal acc. art. 36, par 1 of ipl - no reply within 90 days to fullfil the necessary requirements
B350 Update of information on the portal [chapter 15.35 patent gazette]