BR102015012232A2 - método para delegar uma implantação de transações, dispositivos e programas correspondentes - Google Patents

método para delegar uma implantação de transações, dispositivos e programas correspondentes Download PDF

Info

Publication number
BR102015012232A2
BR102015012232A2 BR102015012232A BR102015012232A BR102015012232A2 BR 102015012232 A2 BR102015012232 A2 BR 102015012232A2 BR 102015012232 A BR102015012232 A BR 102015012232A BR 102015012232 A BR102015012232 A BR 102015012232A BR 102015012232 A2 BR102015012232 A2 BR 102015012232A2
Authority
BR
Brazil
Prior art keywords
payment server
user
transaction
srvp
server
Prior art date
Application number
BR102015012232A
Other languages
English (en)
Inventor
Pierre Quentin
Original Assignee
Ingenico Group
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Ingenico Group filed Critical Ingenico Group
Publication of BR102015012232A2 publication Critical patent/BR102015012232A2/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/02—Payment architectures, schemes or protocols involving a neutral party, e.g. certification authority, notary or trusted third party [TTP]
    • 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
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00—Payment architectures, schemes or protocols
    • G06Q20/08—Payment architectures
    • G06Q20/085—Payment architectures involving remote charge determination or related payment systems
    • G06Q20/0855—Payment architectures involving remote charge determination or related payment systems involving a third party
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00—Payment architectures, schemes or protocols
    • G06Q20/08—Payment architectures
    • G06Q20/10—Payment architectures specially adapted for electronic funds transfer [EFT] systems; specially adapted for home banking systems
    • 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/22—Payment schemes or models
    • G06Q20/227—Payment schemes or models characterised in that multiple accounts are available, e.g. to the payer
    • 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
    • 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/382—Payment protocols; Details thereof insuring higher security of transaction
    • 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/40—Authorisation, e.g. identification of payer or payee, verification of customer or shop credentials; Review and approval of payers, e.g. check credit lines or negative lists
    • G06Q20/401—Transaction verification
    • G06Q20/4012—Verifying personal identification numbers [PIN]
    • 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/40—Authorisation, e.g. identification of payer or payee, verification of customer or shop credentials; Review and approval of payers, e.g. check credit lines or negative lists
    • G06Q20/405—Establishing or using transaction specific rules

Landscapes

  • Business, Economics & Management (AREA)
  • Accounting & Taxation (AREA)
  • Engineering & Computer Science (AREA)
  • Theoretical Computer Science (AREA)
  • Physics & Mathematics (AREA)
  • General Business, Economics & Management (AREA)
  • General Physics & Mathematics (AREA)
  • Strategic Management (AREA)
  • Finance (AREA)
  • Computer Security & Cryptography (AREA)
  • Development Economics (AREA)
  • Economics (AREA)
  • Information Transfer Between Computers (AREA)
  • Financial Or Insurance-Related Operations Such As Payment And Settlement (AREA)
  • Information Retrieval, Db Structures And Fs Structures Therefor (AREA)
  • Management, Administration, Business Operations System, And Electronic Commerce (AREA)

Abstract

método para delegar uma implantação de transações, dispositivos e programas correspondentes. a invenção se refere a um método para delegar uma implantação de transações para um usuário intermediário. o método compreende: pelo menos uma primeira fase para registrar pelo menos um servidor de pagamento no dito servidor intermediário, sendo que a primeira fase entrega, dentro do dito servidor intermediário, uma estrutura de dados de delegação que compreende pelo menos uma associação entre o dito servidor de pagamento e pelo menos uma lista de tipos de transações delegadas pelo dito servidor de pagamento para o dito servidor intermediário; e pelo menos uma segunda fase para registrar pelo menos um usuário no dito servidor intermediário, sendo que a dita segunda fase entrega, dentro do dito servidor intermediário, uma estrutura de dados de aprovisionamento que compreende pelo menos uma associação entre um identificador de usuário, um identificador de servidor de pagamento e um identificador de usuário com o dito servidor de pagamento.

Description

“MÉTODO PARA DELEGAR UMA IMPLANTAÇÃO DE TRANSAÇÕES, DISPOSITIVOS E PROGRAMAS CORRESPONDENTES” CAMPO DA INVENÇÃO
[001] A invenção refere-se ao campo das transações, especialmente transações financeiras, realizadas por um usuário por meio de um terminal de comunicações. A mesma visa, mais particularmente, a simplificação do uso de um serviço de terceiros para implantar essas transações.
TÉCNICA ANTERIOR
[002] O principal desenvolvimento das redes de comunicações e a distribuição comercial de terminais moveis conectados de desempenho cada vez mais alto a custos cada vez mais acessíveis significou que os consumidores gerais têm agora acesso quase permanente à Internet. Seja através de redes WiFi ou através das redes de telefonia móvel da última geração com o uso de smartphones, computadores do tipo tablets ou computadores do tipo laptop, todos podem, agora, acessar informações pessoais ou informações gerais a qualquer momento e em qualquer lugar.
[003] Esses desenvolvimentos levaram ao surgimento de serviços inovadores que permitem que um usuário faça transações, especialmente transações financeiras, tais como operações de pagamento para uma compra ou para transferir fundos entre contas, diretamente de seu terminal móvel. Os exemplos que podem ser citados são serviços tais como Paypal™ ou Flashiz™ no campo de pagamento online ou, novamente, serviços desenvolvidos por instituições bancárias para seus clientes. Embora um determinado número de funções oferecidas por esses serviços seja comum a todos, cada um dos mesmos, no entanto, tem seus recursos específicos. Assim, um serviço tal como Flashiz™ permite que uma compra seja feita de modo mais rápido e simplesmente passando um código de barras do tipo código QR com um dispositivo móvel. O sucesso do Paypal™, um serviço pioneiro nesse campo, permite que as compras sejam feitas sem ter que inserir detalhes bancários, colocou o mesmo na posição de um meio de pagamento ampla e geralmente reconhecido que é proposto e aceito pelos usuários de anúncios classificados online. Finalmente, as instituições bancárias, como titulares de uma conta ou contas do cliente, oferecem funções específicas, tais como a emissão de detalhes de identificação de banco ou a transferência de dinheiro de uma conta corrente para uma conta de poupança.
[004] Já que cada serviço tem seus próprios recursos especiais, um usuário pode assinar diversos dos mesmos para satisfazer várias necessidades. Por exemplo, um usuário instalaria classicamente os aplicativos a seguir em seu terminal móvel: seu próprio aplicativo da instituição bancária a fim de gerenciar suas contas, um aplicativo que permite que o mesmo faça uma compra simplesmente digitalizando um código de barras de produto e, finalmente, um aplicativo do tipo Paypal™ que oferece a ele um meio simples de fazer compras em um site de propaganda classificada, por exemplo.
[005] Para poder executar as transações para as quais os mesmos foram designados, todos esses aplicativos precisam estar vinculados a uma conta bancária do usuário. Isso pode ser feito, por exemplo, através do fornecimento, pelo usuário, dos dados associados a um cartão de banco para um provedor de serviço de pagamento.
[006] Obviamente, é essencial assegurar o acesso a esses serviços: um usuário que perdeu ou teve seu dispositivo móvel roubado (seu telefone portátil, por exemplo) deve ter a garantia de que uma pessoa mal-intencionada que encontre seu produto não seja capaz de acessar seus serviços ou informações bancárias, permitindo a realização de transações financeiras em seu nome.
[007] Assim, o uso desses serviços exige uma etapa preliminar de autenticação do usuário. Embora outros meios existam e tendam a se desenvolver (por exemplo, meios de identificação biométrica), essa etapa é mais frequentemente implantada por meio de uma solicitação para o usuário inserir um identificador e uma senha normalmente conhecida apenas por ele. Esse identificador e senha terá sido definido preliminarmente durante a assinatura do serviço pelo usuário.
[008] Já que cada serviço é livre para estabelecer suas próprias regras em relação ao formato do identificador e à senha, é bem provável que um usuário que tenha assinado diversos serviços desse tipo tenha diversos identificadores e/ou senhas associadas para memorizar. Assim, a memorização das informações de início de sessão ou detalhes de início de sessão que variam de um serviço para o outro pode logo provar ser uma tarefa complicada para o usuário.
[009] Para lidar com esses problemas, há serviços que atuam como intermediários. Esses serviços que usam um aplicativo instalado no terminal de comunicações do usuário permitem o agrupamento, dentro de uma mesma interface, das informações vindo de diferentes serviços de terceiros que o usuário assinou. Assim, através desse ponto de entrada exclusivo, o usuário pode acessar os dados de inúmeros serviços nos quais o mesmo se registrou anteriormente por meio do aplicativo sem ter que inserir os identificadores e senhas apropriados para cada serviço de terceiros assim vinculados toda vez que irá utilizá-los.
[010] Essa abordagem tem, entretanto, desvantagens para o usuário. Os detalhes de início de sessão sensíveis para os diferentes serviços que retêm seus dados são revelados a um serviço intermediário com todos os riscos que isso acarreta. Um exemplo que pode ser citado é o risco de que a infraestrutura do serviço intermediário possa ser acessada ilegalmente, permitindo que pessoas mal-intencionadas recuperam vários detalhes de início de sessão que pertencem ao usuário ou, novamente, o risco de uso indevido da confiança por parte do serviço intermediário ao qual foi concedido acesso total aos dados sem qualquer meio de limitar o escopo desse acesso.
[011] Implantar o protocolo oAuth entre os serviços intermediários e o serviço que retém os dados do usuário é um meio de superar as desvantagens mencionadas acima. Isso permite, de fato, que o serviço intermediário obtenha autorização para acessar os dados do usuário sem qualquer comunicação de detalhes para iniciar uma sessão no serviço de terceiros que retém esses dados. Entretanto, um dos pontos fracos regularmente propostos com esse protocolo é que o mesmo favorece precisamente o tipo de interação implantado por pessoas mal-intencionadas durante tentativas de phishing, ou seja, um redirecionamento do usuário para uma interface de terceiros para inserir seus detalhes para iniciar uma sessão em um serviço.
[012] Existe, portanto, uma necessidade de um método que permita que um servidor intermediário execute transações em nome de um servidor de pagamento e não tenha pelo menos algumas das desvantagens explicadas aqui acima.
SUMÁRIO DA INVENÇÃO
[013] A invenção não tem pelo menos algumas dessas desvantagens da técnica anterior. De fato, a mesma propõe um método para delegar uma implantação de transações a um usuário intermediário. De acordo com a invenção, o método compreende: - pelo menos uma primeira fase para registrar pelo menos um servidor de pagamento no dito servidor intermediário, sendo que a primeira fase entrega, dentro do dito servidor intermediário, uma estrutura de dados de delegação que compreende pelo menos uma associação entre o dito servidor de pagamento e pelo menos uma lista de tipos de transações delegadas pelo dito servidor de pagamento ao dito servidor intermediário; e - pelo menos uma segunda fase para registrar pelo menos um usuário no dito servidor intermediário, sendo que a dita segunda fase entrega, dentro do dito servidor intermediário, uma estrutura de dados de aprovisionamento que compreende pelo menos uma associação entre um identificador de usuário, um identificador de servidor de pagamento e um identificador de usuário com o dito servidor de pagamento.
[014] Assim, o servidor intermediário tem a capacidade de associar, dentro de si mesmo, os servidores de pagamento, os tipos de transações delegadas e os usuários identificados com os diferentes servidores de pagamento.
[015] De acordo com uma modalidade particular, a dita primeira fase do método compreende: - uma etapa para transmitir uma solicitação para o dito servidor de pagamento para delegar os tipos de transações, sendo que a dita solicitação compreende uma lista de tipos de transações delegáveis, que o servidor intermediário deseja implantar em nome do dito servidor de pagamento; - uma etapa para receber dados que representam uma decisão da assinatura pelo servidor de pagamento para pelo menos um tipo de transição da lista de tipos de transações delegáveis, chamada de lista de tipos de transações delegadas; - uma etapa para a gravação, dentro da dita estrutura de dados de delegação, de uma associação entre a dita lista de tipos de transações delegadas e o servidor de pagamento (SrvP).
[016] Assim, o servidor intermediário pode executar ou implantar transações em nome de um servidor de pagamento. Essas transações são listadas na lista de tipos de transações delegadas que é transmitida pelo servidor de pagamento. Esse servidor de pagamento mantém, portanto, seu poder discricionário para atribuir uma delegação como uma função dos servidores intermediários com o qual o mesmo lida. O servidor de pagamento tem, assim, de forma complementar, um meio disponível de aliviar sua carga de processamento de dados já que o mesmo pode depender, por assim dizer, de servidores de proximidades para executar determinados tipos de transação.
[017] De acordo com uma modalidade particular, a dita primeira fase do método compreende, adicionalmente, - uma etapa para receber uma lista de tipos de transações implantadas pelo servidor de pagamento chamada de lista de tipos de transações não delegadas; - uma etapa para a gravação, dentro da dita estrutura de dados de delegação, de uma associação entre a dita lista de tipos de transações não delegadas e o servidor de pagamento.
[018] Assim, o servidor intermediário pode diferenciar as transações que o mesmo não pode executar por si próprio. Assim, o servidor intermediário pode diferenciar as transações que o mesmo pode implantar por si próprio daquelas que o mesmo não pode implantar por si próprio e que o mesmo deve retransmitir para o servidor de pagamento. O servidor de pagamento pode, portanto, concordar ou recusar delegar o desempenho de determinados tipos de transações ao servidor intermediário.
[019] De acordo com uma modalidade particular, a dita segunda fase do método compreende: - uma etapa para receber uma solicitação de registro por um usuário, que vem de um terminal de comunicações, sendo que a dita solicitação compreende pelo menos um identificador do dito usuário, pelo menos um identificador de um servidor de pagamento e pelo menos um identificador do dito usuário ao dito servidor de pagamento; - uma etapa para transmitir o dito identificador de usuário com o dito servidor de pagamento para o dito servidor de pagamento; - uma etapa para receber dados que representam uma decisão de registrar o dito usuário; e - quando os ditos dados que representam uma decisão de registrar o usuário são positivos, uma etapa para gravar, dentro da dita estrutura de dados de aprovisionamento, uma associação entre o dito identificador de usuário, o dito identificador de servidor de pagamento e o dito identificador de usuário com o dito servidor de pagamento.
[020] Assim, os usuários e os provedores de serviço de pagamento são registrados dentro de um e do mesmo servidor intermediário que tem a capacidade de implantar uma lista de transações predeterminadas. Isso significa que, do ponto de vista do usuário, a execução das transações é simplificada.
[021] De acordo com uma modalidade particular, a dita segunda fase do método compreende, adicionalmente, - uma etapa para transmitir uma solicitação para delegar os tipos de transações ao dito terminal de comunicações, sendo que a dita solicitação compreende uma lista de tipos de transações delegáveis que o servidor intermediário deseja implantar; - uma etapa para receber, do dito terminal de comunicações, dados que representam uma decisão de assinatura pelo dito usuário para pelo menos um tipo de transição da lista de tipos de transações delegáveis, chamada de lista de tipos de transações delegadas; - uma etapa para gravar, dentro da estrutura de dados de delegação, uma associação entre a dita lista de tipos de transações delegadas e o dito usuário.
[022] Assim, o usuário permanece em controle total da aceitação ou não aceitação da delegação de um tipo de transição ao servidor intermediário, incluindo os tipos de transações delegadas por um servidor de pagamento ao servidor intermediário.
[023] Em outra modalidade, a invenção também se refere a um método para o processamento, por um servidor intermediário, de uma transação que vem de um terminal de telecomunicações do usuário. De acordo com a invenção, tal método de processamento compreende: - uma etapa para receber uma solicitação para executar uma transação; - uma etapa para obter, a partir da dita solicitação, pelo menos um identificador do dito usuário, pelo menos um identificador de um servidor de pagamento e pelo menos um tipo da dita transação; - uma etapa para buscar, dentro de uma estrutura de dados de aprovisionamento, um identificador do dito usuário com o servidor de pagamento; - uma etapa para buscar, dentro de uma estrutura de dados de delegação, dados de delegação associado ao dito tipo da dita transação que entrega uma decisão de delegar; - quando a dita decisão de delegar é positiva, uma etapa para a implantação, pelo dito servidor intermediário, da dita transação; - quando a dita decisão de delegar é negativa, uma etapa para transmitir o dito tipo de transição e o dito identificador de usuário com o dito servidor de pagamento para o dito servidor de pagamento.
[024] Assim, é possível executar uma transação diretamente de um servidor intermediário.
[025] De acordo com uma modalidade particular, o dito método para processamento é caracterizado pelo fato de que, quando a dita decisão de delegar é positiva, a dita etapa para implantar a dita transação compreende: - uma etapa para estabelecer, com o servidor de pagamento, um enlace seguro para a transmissão de dados; - uma etapa para transmitir uma solicitação, para o servidor de pagamento, para obter um fragmento de dados bancários, sendo que a dita solicitação compreende o dito identificador do dito usuário com o dito servidor de pagamento; - uma etapa para receber os ditos dados bancários associado ao dito usuário; - uma etapa para executar a dita transação por meio dos dados bancários.
[026] Assim, o servidor intermediário, através de seu enlace seguro com o servidor de pagamento, tem a capacidade de obter as informações complementares necessárias para implantar a transação. Essas informações não são salvas pelo servidor intermediário. Assim, mesmo quando o servidor intermediário está exposto a perigo, o roubo de dados presentes nesse servidor intermediário não permitirá que a transação seja realizada.
[027] De acordo com uma característica particular, quando a dita decisão de delegar é negativa, o dito método para processar compreende, adicionalmente, uma etapa para receber uma situação da implantação da dita transação do servidor de pagamento.
[028] Assim, o servidor intermediário sabe a situação de uma transação feita pelo servidor de pagamento. O mesmo é especialmente informado do final de uma transação.
[029] De acordo com outra característica particular, o dito método para processar compreende, adicionalmente, uma etapa para transmitir uma situação da implantação da dita transação para o dito terminal de comunicações do usuário.
[030] Assim, o servidor intermediário tem a capacidade de alertar um usuário sobre a situação de uma transação, especialmente o fato de que a mesma foi apropriadamente executada.
[031] De acordo com uma modalidade particular, o canal de comunicações entre o servidor intermediário e o servidor de pagamento é seguro.
[032] De acordo com uma modalidade particular, o canal de comunicações entre o servidor intermediário e o terminal de comunicações é seguro.
[033] Assim, a linha de comunicações inteira é segura. Assim, o servidor intermediário, através de seu enlace seguro com o terminal de comunicações, tem a capacidade de obter as informações necessárias para implantar a transação. Apenas esse identificador é salvo pelo servidor intermediário. Assim, mesmo quando o servidor intermediário está exposto a perigo, o roubo dos dados apresentados por esse servidor intermediário não permitirá que a transação seja realizada.
[034] Em outra modalidade, a invenção também se refere a um servidor intermediário para delegar a implantação das transações de acordo com o método de delegação explicado aqui acima. De acordo com a invenção, tal servidor intermediário compreende: - meios para registrar pelo menos um servidor de pagamento no dito servidor intermediário, sendo que os ditos meios entregam, dentro do dito servidor intermediário, uma estrutura de dados de delegação que compreende pelo menos uma associação entre o dito servidor de pagamento e pelo menos uma lista de tipos de transações delegadas pelo dito servidor de pagamento para o dito servidor intermediário; e - meios para registrar pelo menos um usuário no dito servidor intermediário, sendo que os ditos meios entregam, dentro do dito servidor intermediário, uma estrutura de dados de aprovisionamento que compreende pelo menos uma associação entre um identificador de usuário, um identificador de servidor de pagamento e um identificador de usuário com o dito servidor de pagamento.
[035] De acordo com uma implantação preferencial, as diferentes etapas dos métodos de acordo com a invenção são implantadas por um ou mais programas de software ou programas de computador que compreendem instruções de software a serem executadas por um processador de dados de um módulo de retransmissão de acordo com a invenção e que são projetados para comandar a execução das diferentes etapas dos métodos.
[036] Consequentemente, a invenção também se refere a um programa que tem a capacidade de ser executado por um computador ou um processador de dados, sendo que esse programa compreende instruções para comandar a execução das etapas de um método conforme mencionado aqui acima.
[037] Esse programa pode usar qualquer linguagem de programação, seja qual for, e pode estar na forma de um código de fonte, código de objeto ou um código intermediário entre o código de fonte e o código de objeto como em uma forma parcialmente compilada ou em qualquer outra forma desejável.
[038] A invenção também visa fornecer uma portadora de informações legível por um processador de dados que compreende as instruções de um programa conforme mencionado aqui acima.
[039] A portadora de informações pode ser qualquer entidade ou dispositivo que tenha a capacidade de armazenar o programa. Por exemplo, a portadora pode compreender um meio de armazenamento tal como uma ROM, por exemplo, um CD ROM ou uma ROM de circuito microeletrônico ou, novamente, um meio de gravação magnética, por exemplo, um disquete ou uma unidade de disco rígido.
[040] Além disso, a portadora de informações pode ser uma portadora transmissível tal como um sinal elétrico ou óptico, que pode ser conduzido por meio de um cabo elétrico ou óptico, por rádio ou por outro meio. O programa de acordo com a invenção pode ser especialmente transferido por download a partir de uma rede do tipo Internet.
[041] Como uma alternativa, a portadora de informações pode ser um circuito integrado no qual o programa é incorporado, sendo que o circuito é adaptado para executar ou ser usado na execução do método em questão.
[042] De acordo com uma modalidade, a invenção é implantada por meio de componentes de software e/ou hardware. A este respeito, o termo “módulo” neste documento pode corresponder igualmente bem a um componente de software assim como a um componente de hardware ou a um conjunto de componentes de hardware ou software.
[043] Um componente de software corresponde a um ou mais programas de computador ou diversos subprogramas de um programa ou mais geralmente a qualquer elemento de um programa ou um pacote de software que tem a capacidade de implantar uma função ou um conjunto de funções, de acordo com o que é descrito aqui acima para o módulo em questão. Tal componente de software é executado por um processador de dados de uma entidade física (terminal, servidor, porta de comunicação, roteador, etc.) e tem a capacidade de acessar recursos de hardware dessa entidade física (memória, mídia de gravação, barramentos de comunicações, placas eletrônicas de entrada/saída, interfaces de usuário, etc.).
[044] Do mesmo modo, um componente de hardware corresponde a qualquer elemento de uma montagem de hardware que tem a capacidade de implantar uma função ou um conjunto de funções de acordo com o que é descrito aqui abaixo para o módulo em questão. O mesmo pode ser um componente de hardware programável ou um componente com um processador integrado para a execução do software, por exemplo, um circuito integrado, um cartão inteligente, um cartão de memória, um cartão eletrônico para executar firmware, etc.
[045] Cada componente do sistema descrito aqui acima implanta naturalmente seus próprios módulos de software.
[046] As diferentes modalidades mencionadas aqui acima podem ser combinadas entre si para implantar a invenção.
LISTA DE FIGURAS
[047] Outros recursos e vantagens da invenção devem aparecer mais claramente a partir da descrição a seguir de diversas modalidades, dada por meio de exemplos simples, ilustrativos e não exaustivos e a partir das figuras anexas, dentre as quais: - A Figura 1 descreve uma modalidade que tem uma fase para registrar um servidor de pagamento em um servidor intermediário; - A Figura 2 descreve uma modalidade complementar que tem uma fase para registrar um usuário em um servidor intermediário; - A Figura 3 ilustra a implantação das etapas para processar uma transação; - A Figura 4 ilustra um dispositivo para delegar a implantação de transações de acordo com a técnica proposta; - A Figura 5 ilustra um dispositivo para processar as transações delegadas de acordo com a técnica proposta.
DESCRIÇÃO DE UMA MODALIDADE DA INVENÇÃO PRINCÍPIO GERAL
[048] Conforme explicado aqui acima, foi observado que as soluções atuais que permitem que o serviço intermediário execute a transação em nome de um serviço de pagamento podem expor um usuário a determinados riscos: acesso ilegal aos dados no serviço intermediário, um nível excessivamente alto de privilégio concebido ao serviço intermediário, risco aumentado de phishing. O uso de um serviço intermediário para agrupar os serviços de pagamento é, entretanto, de interesse ao usuário, já que essa solução libera o mesmo da necessidade de memorizar e inserir repetidamente uma variedade de detalhes de início de sessão. O objetivo do método proposto é, portanto, permitir que um usuário associe um serviço de pagamento que ele mesmo assinou preliminarmente com um serviço intermediário, de modo que o último possa executar transações em nome do primeiro sem mostrar pelo menos algumas das desvantagens explicadas aqui acima e sem alterar os hábitos de costume do usuário. O mesmo é, portanto, um método para delegar a implantação das transações a um servidor intermediário. Essa delegação não é sistemática: por várias razões: por exemplo, para transações complexas, as transações ativam grandes quantias ou, por qualquer outra razão, o servidor de pagamento deve poder deter o controle total sobre determinados tipos de transações.
[049] O princípio geral da invenção depende da implantação de duas fases de registro em relação a um servidor intermediário: uma primeira fase para registrar pelo menos um servidor de pagamento no servidor intermediário e uma segunda fase para registrar pelo menos um usuário no servidor intermediário.
[050] A fase para registrar pelo menos um servidor de pagamento em um servidor intermediário permite a constituição, dentro do servidor intermediário, de uma estrutura de dados chamada de estrutura de dados de delegação que compreende pelo menos uma associação entre o dito servidor de pagamento (SrvP) e pelo menos uma lista de tipos de transações delegadas (LTDe) pelo dito servidor de pagamento (SrvP) para o dito servidor intermediário (Srvlnt). Assim, o servidor intermediário conhece, em relação a um dado servidor de pagamento, os tipos de transação que são delegadas ao mesmo por esse servidor de pagamento.
[051] A fase para registrar pelo menos um usuário no servidor intermediário, por sua vez, permite a constituição, dentro do servidor intermediário, de uma estrutura de dados chamada de estrutura de dados de aprovisionamento que compreende pelo menos uma associação entre um identificador de usuário (id), um identificador de servidor de pagamento (idSrvP) e um identificador de usuário (idP) com o dito servidor de pagamento (SrvP). Assim, o servidor intermediário conhece os servidores de pagamento associados a um dado usuário e os identificadores desse usuário com esses servidores de pagamento.
[052] Aqui abaixo, é apresentada uma implantação do princípio explicado acima. Essa implantação não, de modo algum, completa e qualquer outra implantação que compreenda as mesmas características que aquelas explicadas pode ser contemplada.
DESCRIÇÃO DE UMA MODALIDADE
[053] Nessa modalidade apresentada em referência às Figuras 1 e 2, em uma primeira fase (1), um servidor de pagamento é registrado em um servidor intermediário. Então, em uma segunda fase (2), um usuário é registrado no servidor intermediário de acordo com o princípio geral da invenção descrito aqui acima.
[054] Nessa modalidade, a primeira fase (1) do método para delegar implantada compreende, em referência à Figura 1: - uma etapa para transmitir (10), para um servidor de pagamento (SrvP), uma solicitação para delegar os tipos de transações, sendo que a dita solicitação compreende uma lista de tipos de transações delegáveis (LTDa) que o servidor intermediário (Srvlnt) deseja implantar em nome do dito servidor de pagamento (SrvP); - uma etapa para receber (11) dados que representam uma decisão da assinatura pelo servidor de pagamento (SrvP) para pelo menos um tipo de transição da lista de tipos de transações delegáveis (LTDa), chamada de lista de tipos de transações delegadas (LTDe); - uma etapa para registrar (12), dentro da dita estrutura de dados de delegação (StructDel), uma associação entre a dita lista de tipos de transações delegadas (LTDe) e o servidor de pagamento (SrvP).
[055] Na modalidade particular explicada em referência à Figura 1, essa primeira fase (1) compreende, adicionalmente, - uma etapa para receber (13) uma lista de tipos de transações implantadas pelo servidor de pagamento (SrvP) chamada de lista de tipos de transações não delegadas (LTND); - uma etapa para registrar (14), dentro da estrutura de dados de delegação (StructDel), uma associação entre a dita lista de tipos de transações não delegadas (LTND) e o servidor de pagamento (SrvP).
[056] Em outras modalidades, essa primeira fase (1) pode compreende somente uma ou outra dentre as sequências das etapas (10) a (12), por um lado, ou (13) a (14), por outro lado.
[057] Essa primeira fase (1) para registrar um servidor de pagamento em um servidor intermediário torna possível estabelecer uma relação de confiança entre esses dois servidores e fixar o perímetro de ação de cada um dos mesmos, sendo que esse perímetro de ação é definido pelas associações gravadas na estrutura de dados de delegação. O servidor intermediário submete, portanto, uma lista de tipos de transações, chamadas de transações delegáveis, ao servidor de pagamento. Essas são transações que o mesmo propõe executar em nome do servidor de pagamento. O servidor de pagamento, por sua vez, informa o servidor intermediário dos tipos de transações que devem permanecer em seu perímetro e que o mesmo não deseja delegar. Assim, no final dessa primeira fase e antes de qualquer ação pelo usuário do serviço intermediário, o servidor intermediário e o servidor de pagamento são identificados um em relação ao outro e o servidor intermediário sabe diferenciar os tipos de transações que o mesmo pode realizar por si próprio daqueles que o mesmo deve retransmitir para o servidor de pagamento. Através desse mecanismo, o servidor intermediário pode executar ou implantar transações em nome do servidor de pagamento. A delegação ou não delegação dos tipos de transação continua a ser a responsabilidade do servidor de pagamento que mantém, portanto, seu poder discricionário de designar delegações como uma função dos servidores intermediários com os quais o mesmo lida. O servidor de pagamento tem, assim, de modo complementar, um meio disponível de aliviar sua carga de processamento de dados já que o mesmo pode depender, por assim dizer, de servidores próximos para executar determinados tipos de transação. Os tipos de transações delegadas podem, por exemplo, se referir aos tipos de transações considerados como sendo de baixa complexidade ou, novamente, às transações que, no caso de transações financeiras, envolvem quantias bastante pequenas (por exemplo, menores do que uma quantia gravada nas definições de delegação). Ao contrário, o tipo de transação não delegada para qual o servidor de pagamento deseja manter o controle sobre a execução pode se referira operações mais complexas ou operações mais sensíveis para um usuário, por exemplo, transações financeiras que envolvem grandes quantias. Esses exemplos são, naturalmente, dados apenas a título de ilustração e não são, portanto, completos.
[058] A essa uma primeira fase (1) para registrar um servidor de pagamento em um servidor intermediário, uma segunda fase (2) é adicionada para registrar um usuário em o servidor intermediário. Esse usuário assinou, preliminarmente, os serviços propostos pelo dito servidor de pagamento e tem, portanto, detalhes de tipo de senha e identificador disponíveis para iniciar uma sessão com esse servidor.
[059] Nessa segunda fase (2), as etapas a seguir são implantadas em referência à Figura 2: - uma etapa para receber (20) uma solicitação para registar um usuário, que vem de um terminal de comunicações (TC), sendo que a dita solicitação compreende pelo menos um identificador do dito usuário (id), pelo menos um identificador de um servidor de pagamento (idSrvP) e pelo menos um identificador do dito usuário (idP) com o dito servidor de pagamento (SrvP); - uma etapa para transmitir (21), para o dito servidor de pagamento (SrvP), o dito identificador de usuário (idP) com o dito servidor de pagamento (SrvP); - uma etapa para receber (22) dados que representam uma decisão de registrar o dito usuário (Usr); e - quando os ditos dados que representam uma decisão de registro do usuário são positivos, uma etapa para registrar (23), dentro da dita estrutura de dados de aprovisionamento (StructProv), uma associação entre o dito identificador de usuário (id), o dito identificador de servidor de pagamento (idSrvP) e o dito identificador de usuário (idP) no dito servidor de pagamento (SrvP).
[060] A estrutura de dados de aprovisionamento constituída assim no níve! do servidor intermediário permite que o mesmo, para um dado usuário, conheça o serviço de pagamentos que esse usuário escolheu agrupar dentro desse servidor intermediário e, para cada um dos mesmos, seu identificador de usuário com esse serviço. Essa segunda fase (2) para registrar um usuário com o servidor intermediário torna, adicionalmente, possível estabelecer uma relação de confiança entre o usuário e o servidor intermediário, uma relação que se presume que seja segura através do uso de um meio seguro de transição entre o terminal do usuário e o servidor intermediário. Assim, uma vez que o servidor de pagamento é registrado no servidor intermediário, um usuário que tem uma conta com esse servidor de pagamento pode, então, vincular o mesmo ao servidor intermediário, executando um registro apropriado. Em uma modalidade, o usuário é identificado com o servidor intermediário pelo uso de um par de identificador/senha. Em uma modalidade preferencial, ou o usuário é identificado pelo usuário do equipamento criptográfico instalado tanto no terminal de comunicações do usuário quanto no servidor intermediário ou por outros meios. Essa modalidade tem diversas vantagens. Primeiro, a mesma permite que o usuário vincula a conta que o mesmo retém com o servidor de pagamento ao servidor intermediário fornecendo, durante o registro com o servidor intermediário, apenas seu identificador de usuário com esse servidor de pagamento. A comunicação da senha associada não é mais necessária já que uma relação de confiança é preliminarmente estabelecida entre o servidor intermediário e o servidor de pagamento. Isso resulta em uma simplificação da entrada, em comparação com as soluções da técnica anterior, para o usuário que deseja vincular uma conta de pagamento a um servidor intermediário. Segundo, uma intrusão maliciosa do servidor intermediário no sistema não comprometerá os servidores de pagamento vinculados pelo usuário já que as senhas das contas associadas não são conhecidas pelo servidor intermediário.
[061] Em outra modalidade particular, o usuário tem a possibilidade de não deixar o servidor intermediário executar determinados tipos de transações em nome do servidor de pagamento e de fazer isso mesmo se o servidor de pagamento tiver autorizado preliminarmente a delegação dos ditos tipos de transações ao servidor intermediário durante a primeira fase de registro. Nesse caso, a decisão do usuário tem a prioridade e as transações em questão são executadas pelo servidor de pagamento.
[062] Assim, em comparação com a modalidade anterior, a segunda fase (2) para registrar um usuário no serviço intermediário compreenderá, adicionalmente, - uma etapa para transmitir uma solicitação para delegação dos tipos de transações para o dito terminal de comunicações (TC), sendo que a dita solicitação compreende uma lista de tipos de transações delegáveis (LTDaUsr) que o servidor intermediário (Srvlnt) deseja implantar; - uma etapa para receber dados que vêm do dito terminal de comunicações (TC), sendo que esses dados que representam uma decisão de assinatura pelo dito usuário (Usr) a pelo menos um tipo de transição da lista de tipos de transações delegáveis (LTDaUsr), chamada de lista de tipos de transações delegadas (LTDeUsr); - uma etapa para a registrar uma associação, dentro da estrutura de dados de delegação (StructDel), entre a dita lista de tipos de transações delegadas (LTDeUsr) e o dito usuário (Usr).
[063] Nessa modalidade, a estrutura de delegação constituída durante a primeira fase (1) para registrar um servidor de pagamento em um servidor intermediário é, portanto, enriquecida pela adição de associações entre um usuário e os tipos de transações para as quais esse usuário autoriza, efetivamente, a delegação, ou seja, a implantação de uma transação pelo servidor intermediário. Os tipos de transações que podem ser consideradas por esse mecanismo são apenas aqueles que o servidor de pagamento escolheu delegar ao servidor intermediário na primeira fase. Assim, um usuário não tem a capacidade de impor uma delegação de um tipo de transição ao servidor intermediário se o tipo de transição em questão não for parte da lista de tipos de transações delegáveis (LTDe) ao servidor intermediário pelo servidor de pagamento.
USO E MODALIDADES ASSOCIADAS
[064] Uma vez que os registros foram feitos no servidor intermediário, primeiro, de um servidor de pagamento (de acordo com a primeira fase do método para delegar) e segundo, de um usuário que tem disponível uma conta nesse servidor de pagamento (de acordo com a segunda fase do método para delegar), o mecanismo de delegação pode ser usado para processar uma transação. Assim, o usuário pode solicitar a execução de uma transação de um terminal de comunicações em sua posse, por meio do dito servidor intermediário. Esse terminal de comunicações pode, por exemplo, ser um smartphone, um computador do tipo tablet, um computador de mesa ou um computador do tipo laptop. O serviço associado a esse servidor intermediário pode ser acessível, por exemplo, por meio de um aplicativo dedicado instalado no terminal de comunicações do usuário ou, novamente, o mesmo pode ser um site da Internet que pode ser consultado diretamente a partir de um navegador presente no terminal de comunicações. O uso desse serviço pode exigir uma entrada preliminar de um detalhe de início de sessão para iniciar uma sessão no servidor, tal como o par de identificador/senha ou, novamente, um código de número de identificação pessoal (PIN) ou pode exigir o uso de qualquer outro meio de autenticação incluindo meios biométricos.
[065] No servidor intermediário, as etapas implantadas nesse método para processar uma transação são as seguintes em referência à Figura 3: - uma etapa para receber (100) uma solicitação para executar uma transação (ReqExecTr); - uma etapa para obter (101), com base na dita solicitação (ReqExecTr), pelo menos um identificador (id) do dito usuário, pelo menos um identificador de um servidor de pagamento (idSrvP) e pelo menos um tipo (typeTr) da dita transação; - uma etapa para buscar (102), dentro de uma estrutura de dados de aprovisionamento (StructProv), um identificador do dito usuário (idP) com o servidor de pagamento (SrvP); - uma etapa para buscar (103), dentro de uma estrutura de dados de delegação (StructDel), dados de delegação (dd) associado ao dito tipo (typeTr) da dita transação que representa uma decisão de delegar; - quando o dito fragmento de dados de delegação (dd) é positivo, uma etapa para implantar (104) a dita transição; - quando o dito fragmento de dados de delação (dd) é negativo, uma etapa para transmitir (105), para o dito servidor de pagamento (SrvP), o dito tipo de transição (typeTr) e o dito identificador de usuário (idP) com o dito servidor de pagamento (SrvP).
[066] A estrutura de dados de delegação (StructDel) e a estrutura de dados de aprovisionamento (StructProv) são aquelas constituídas durante a implantação das duas fases do método para delegar explicado aqui acima, ou seja, as fases para registrar pelo menos um servidor de pagamento e pelo menos um usuário no servidor intermediário.
[067] Em uma modalidade particular, quando o fragmento de dados de delação é positivo, a etapa (104) para implantação da transação por meio do servidor intermediário inclui um diálogo adicional entre o dito servidor intermediário e o servidor de pagamento que compreende as etapas a seguir: - uma etapa para estabelecer, com o servidor de pagamento (SrvP), um enlace seguro de transmissão de dados; - uma etapa para transmitir, para o servidor de pagamento (SrvP), uma solicitação para obter um fragmento de dados bancários, sendo que a dita solicitação compreende o dito identificador (IdP) do dito usuário com o dito servidor de pagamento (SrvP); - uma etapa para receber os dados bancários associados ao dito usuário; - uma etapa para executar a dita transação por meio dos ditos dados bancários.
[068] Essas etapas adicionais possibilitam que o servidor intermediário obtenha, se o tipo de transição a ser realizado exigir o mesmo, os dados complementares que permitirão que o mesmo execute eficazmente a transação. Essas informações não são salvas pelo servidor intermediário. Assim, mesmo quando o servidor intermediário está exposto a perigo, o roubo de dados presentes nesse servidor intermediário não permitirá que a transação seja executada.
[069] Em outra modalidade particular, quando o fragmento de dados de delegação é negativo, o método para processar uma transação compreende, adicionalmente, uma etapa para receber uma situação de implantação de um tipo de transição não delegada. Essa situação permite que o servidor intermediário conheça a situação atual de uma transação realizada pelo servidor de pagamento. A título de exemplos não exaustivos, as situações a seguir podem ser contempladas: sob execução, terminada, cancelada.
[070] Em ainda outra modalidade particular e qualquer que seja o valor dos dados de delegação, o método para processar uma transação inclui uma etapa adicional para transmitir uma situação da implantação da transação para o terminal de comunicações do usuário. O objetivo, dessa vez, é informar ao usuário a situação atual de uma transação, se feita pelo servidor intermediário ou pelo servidor de pagamento. Aqui, novamente, é possível, por exemplo, considerar as situações a seguir de modo não abrangente: sob execução, terminada, cancelada.
[071] Nas modalidades derivadas e a fim de reforçar a segurança do método, os canais de comunicações entre o servidor intermediário e o terminal de comunicações, por um lado, e entre o servidor intermediário e terminal de pagamento, por outro lado, são seguros. Isso pode ser implantado pelo uso de protocolos de codificação de dados, por exemplo, SSL ou TLS, que garantem um determinado grau de confidencialidade dos dados transmitidos. A segurança do canal de comunicações entre o servidor intermediário e o servidor de pagamento pode também, por exemplo, ser garantida pela criação de uma rede privada virtual (VPN) entre esses dois servidores. Os dados que percorrem de uma extremidade da VPN para a outra são codificados por meio de um protocolo de tunelamento, por exemplo, SSL ou TLS, e são, portanto, inacessíveis a qualquer pessoa externa à VPN.
DISPOSITIVOS PARA IMPLANTAR A INVENÇÃO
[072] Referindo-se à Figura 4, é descrito um servidor intermediário (Srvlnt) que compreende meios para executar o método descrito acima para delegar as transações. Assim, tal servidor compreende: - meios para registar pelo menos um servidor de pagamento (SrvP) no dito servidor intermediário (Srvlnt), sendo que os ditos meios entregam, dentro do dito servidor intermediário (Srvlnt), uma estrutura de dados de delegação (StructDel) que compreende pelo menos uma associação entre o dito servidor de pagamento (SrvP) e pelo menos uma lista dos tipos de transações delegadas (LTDe) pelo dito servidor de pagamento (SrvP) ao dito servidor intermediário (Srvlnt); e - meios para registrar pelo menos um usuário (Usr) com o dito servidor intermediário (Srvlnt), sendo que os ditos meios entregam, dentro do dito servidor intermediário (Srvlnt), uma estrutura de dados de aprovisionamento (StructProv) que compreende pelo menos uma associação entre um identificador de usuário (id), um identificador de servidor de pagamento (idSrvP) e um identificador de usuário (idP) com o dito servidor de pagamento (SrvP).
[073] Por exemplo, o servidor intermediário compreende uma memória 41 constituída por uma memória de armazenamento temporário, uma unidade de processamento 42 equipada, por exemplo, com um microprocessador e acionada pelo programa de computador 43 que implanta o método para delegar de acordo com a invenção.
[074] Na inicialização, as instruções de código do programa de computador 43 são, por exemplo, carregadas em uma memória e, então, executadas pelo processador da unidade de processamento 42. A unidade de processamento 42 insere (E), por exemplo, dados para identificar um servidor de pagamento e/ou dados para identificar um usuário e/ou dados que representam os tipos de transações e delegações associadas. O microprocessador da unidade de processamento 42 executa as etapas do método para delegar a implantação das transações, de acordo com as instruções do programa de computador 43 para gravar as associações entre os servidores de pagamento e as listas das transações delegadas, por um lado, e as associações entre os identificadores de usuário, identificadores de servidor de pagamento e identificadores de usuário com esses servidores de pagamento, por outro lado, e notificar o sucesso ou a falha dessas gravações na saída (S).
[075] Para essa finalidade, o servidor intermediário compreende, adicionalmente à memória de armazenamento temporário 41, meios para transmissão/recebimento dos dados que podem se tornar concretos na forma de uma interface de conexão para a conexão a uma ou mais redes de comunicações, sendo que esses meios tornam possível, se necessário, estabelecer um enlace de ponto a ponto seguro com servidor de um provedor de serviços de pagamento. Os mesmos podem ser interfaces de software ou interfaces de hardware (tal como um cartão de rede ou módulos de hardware de comunicações de rede). De acordo com a invenção, tal servidor intermediário compreende, adicionalmente, meios de armazenamento que podem tomar a forma de um banco de dados ou um acesso a tais meios de armazenamento. Esses meios de armazenamento compreendem estruturas de delegação e aprovisionamento.
[076] Além disso, referindo-se à Figura 5, é descrito um servidor para processar uma transação que vem de um terminal de comunicações (TC) de um usuário que compreende meios para executar o método para processar as transações descritas aqui acima. Assim, tal servidor de processamento compreende: - meios para receber uma solicitação para executar uma transação (ReqExecTr); - meios para obter, a partir da dita solicitação (ReqExecTr), pelo menos um identificador do dito usuário (id), pelo menos um identificador de um servidor de pagamento (idSrvP) e pelo menos um tipo (typeTr) da dita transação; - meios para buscar, dentro de uma estrutura de dados de aprovisionamento (StructProv), um identificador do dito usuário (idP) com o servidor de pagamento (SrvP); - meios para buscar, dentro de uma estrutura de dados de delegação (StructDel), dados de delação associados ao dito tipo (typeTr) da dita estrutura que entrega uma decisão de delegar (dd); - quando a dita decisão de delegar (dd) é positiva, meios para implantar a dita transação; - quando a dita decisão de delegar (dd) é negativa, meios para transmitir (105), para o dito servidor de pagamento (SrvP), o dito tipo de transição (typeTr) e o dito identificador de usuário (idP) com o dito servidor de pagamento (SrvP).
[077] Por exemplo, o servidor, para processar uma transação, compreende uma memória 51 constituída por uma memória de armazenamento temporário, uma unidade de processamento 52 equipada, por exemplo, com um microprocessador e acionada pelo programa de computador 53 que implanta o método para delegar de acordo com a invenção.
[078] Na inicialização, as instruções do programa de computador 53 são, por exemplo, carregadas em uma memória e, então, executadas pelo processador da unidade de processamento 52. A unidade de processamento 52 insere (E), por exemplo, dados para identificar um servidor de pagamento e/ou dados para identificar um usuário e/ou dados para representar um tipo de transição. O microprocessador da unidade de processamento 52 executa as etapas do método para processar transações, de acordo com as instruções do programa de computador 53 para implantar a transação ou retransmitir a mesma para o servidor de pagamento, dependendo de se a mesma é do tipo delegada ou não delegada e notificar o sucesso ou a falha dessa ação para implantar ou transmitir na saída (S).
[079] Para essa finalidade, o servidor intermediário compreende, adicionalmente à memória de armazenamento temporário 51, meios para transmitir/receber os dados que podem tomar a forma de uma interface de conexão para a conexão a uma ou mais redes de comunicações, sendo que esses meios tornam possível, se necessário, estabelecer um enlace de ponto a ponto seguro com um terminal de comunicações do usuário e/ou um servidor de um provedor de serviços de pagamento. Os mesmos podem ser interfaces de software ou interfaces de hardware (tal como um cartão de rede ou módulos de hardware de comunicações de rede). De acordo com a invenção, tai servidor de processamento compreende, adicionalmente, meios de armazenamento que podem tomar a forma de um banco de dados ou um acesso a tais meios de armazenamento. Esses meios de armazenamento compreendem estruturas de delegação e aprovisionamento.
REIVINDICAÇÕES

Claims (11)

1. Método para delegar uma implantação de transações a um usuário intermediário (Srvlnt), sendo que o método é caracterizado pelo fato de que compreende: - pelo menos uma primeira fase (1) para registar pelo menos um servidor de pagamento (SrvP) com o dito servidor intermediário (Srvlnt), sendo que a dita primeira fase entrega, dentro do dito servidor intermediário (Srvlnt), uma estrutura de dados de delegação (StructDel) que compreende pelo menos uma associação entre o dito servidor de pagamento (SrvP) e pelo menos uma lista dos tipos de transações delegadas (LTDe) pelo dito servidor de pagamento (SrvP) ao dito servidor intermediário (Srvlnt); e - pelo menos uma segunda fase (2) para registrar pelo menos um usuário (Usr) no dito servidor intermediário (Srvlnt), sendo que a dita segunda fase entrega, dentro do dito servidor intermediário (Srvlnt), uma estrutura de dados de aprovisionamento (StructProv) que compreende pelo menos uma associação entre um identificador de usuário (id), um identificador de servidor de pagamento (idSrvP) e um identificador de usuário (idP) com o dito servidor de pagamento (SrvP),
2. Método para delegar, de acordo com a reivindicação 1, caracterizado pelo fato de que a dita primeira fase (1) compreende: - uma etapa para transmitir (10) uma solicitação para o dito servidor de pagamento (SrvP) para delegar os tipos de transações, sendo que a dita solicitação compreende uma lista de tipos de transações delegáveis (LTDa), que o servidor intermediário (Srvlnt) deseja implantar em nome do dito servidor de pagamento (SrvP); - uma etapa para receber (11) um fragmento de dados que representa uma decisão de assinatura pelo servidor de pagamento (SrvP) para pelo menos um tipo de transição da lista de tipos de transações delegáveis (LTDa), chamada de lista de tipos de transações delegadas (LTDe); - uma etapa para a gravação (12), dentro da dita estrutura de dados de delegação (StructDel), de uma associação entre a dita lista de tipos de transações delegadas (LTDe) e o servidor de pagamento (SrvP).
3. Método, de acordo com a reivindicação 1 ou 2, caracterizado pelo fato de que a dita primeira fase (1) compreende: - uma etapa para receber (13) uma lista de tipos de transações implantadas pelo servidor de pagamento (SrvP) chamada de lista de tipos de transações não delegadas (LTND); - uma etapa para a gravação (14), dentro da estrutura de dados de delegação (StructDel), de uma associação entre a dita lista de tipos de transações não delegadas (LTND) e o servidor de pagamento (SrvP).
4. Método para delegar, de acordo com qualquer uma das reivindicações 1 a 3, caracterizado pelo fato de que a dita segunda fase (2) compreende: - uma etapa para receber (20) uma solicitação de registro por um usuário, que vem de um terminal de comunicações (TC), sendo que a dita solicitação compreende pelo menos um identificador do dito usuário (id), pelo menos um identificador de um servidor de pagamento (idSrvP) e pelo menos um identificador do dito usuário (idP) com o dito servidor de pagamento (SrvP); - uma etapa para transmitir (21) o dito identificador de usuário (idP) com o dito servidor de pagamento (SrvP) para o dito servidor de pagamento (SrvP); - uma etapa para receber (22) um fragmento de dados que representa uma decisão de registrar o dito usuário (Usr); e - quando os ditos dados que representam uma decisão de registrar o usuário são positivos, uma etapa para gravar (23), dentro da dita estrutura de dados de aprovisionamento (StructProv), uma associação entre o dito identificador de usuário (id), o dito identificador de servidor de pagamento (idSrvP) e o dito identificador de usuário (idP) com o dito servidor de pagamento (SrvP).
5. Método, de acordo com a reivindicação 4, caracterizado pelo fato de que a dita segunda fase (1) compreende, adicionalmente, - uma etapa para transmitir uma solicitação para delegar os tipos de transações ao dito terminal de comunicações (TC), sendo que a dita solicitação compreende uma lista de tipos de transações delegáveis (LTDaUsr) que o servidor intermediário (Srvlnt) deseja implantar; - uma etapa para receber, do dito terminal de comunicações (TC), um fragmento de dados que representa uma decisão de assinatura pelo dito usuário (Usr) para pelo menos um tipo de transição da lista de tipos de transações delegáveis (LTDaUsr), chamada de lista de tipos de transações delegadas (LTDeUsr); - uma etapa para gravar, dentro da estrutura de dados de delegação (StructDel), uma associação entre a dita lista de tipos de transações delegadas (LTDeUsr) e o dito usuário (Usr).
6. Método para o processamento, por um servidor intermediário (Srvlnt), de uma transação que vem de um terminal de telecomunicações (TC) do usuário, caracterizado pelo fato de que compreende: - uma etapa para receber (100) uma solicitação para executar uma transação (ReqExecTr); - uma etapa para obter (101), a partir da dita solicitação (ReqExecTr), pelo menos um identificador do dito usuário (id), pelo menos um identificador de um servidor de pagamento (idSrvP) e pelo menos um tipo (typeTr) da dita transação; - uma etapa para buscar (102), dentro de uma estrutura de dados de aprovisionamento (StructProv), um identificador do dito usuário (idP) com o servidor de pagamento (SrvP); - uma etapa para buscar (103), dentro de uma estrutura de dados de delegação (StructDel), dados de delegação associado ao dito tipo (typeTr) da dita transação que entrega uma decisão de delegar (dd); - quando a dita decisão de delegar (dd) é positiva, uma etapa para a implantação (104), pelo dito servidor intermediário (Srvlnt), da dita transação; - quando a dita decisão de delegar (dd) é negativa, uma etapa para transmitir (105) o dito tipo de transição (typeTr) e o dito identificador de usuário (idP) com o dito servidor de pagamento (SrvP) para o dito servidor de pagamento (SrvP).
7. Método, de acordo com a reivindicação 6, caracterizado pelo fato de que, quando a dita decisão de delegar é positiva, a dita etapa para implantar a dita transição por meio do dito servidor intermediário (Srvlnt) compreende: - uma etapa para estabelecer, com o servidor de pagamento (SrvP), um enlace seguro para a transmissão de dados; - uma etapa para transmitir uma solicitação, para o servidor de pagamento (SrvP), para obter dados bancários, sendo que a dita solicitação compreende o dito identificador (IdP) do dito usuário com o dito servidor de pagamento (SrvP); - uma etapa para receber o dito fragmento de dados bancários associado ao dito usuário; - uma etapa para executar a dita transação por meio do dito fragmento de dados bancários.
8. Método, de acordo com a reivindicação 6, caracterizado pelo fato de que compreende, adicionalmente, quando a dita decisão de delegar é negativa, uma etapa para receber uma situação da implantação da dita transação que vem do servidor de pagamento (SrvP).
9. Método, de acordo com qualquer uma das reivindicações 6 a 8, caracterizado pelo fato de que compreende uma etapa para transmitir uma situação da implantação da dita transação para o dito terminal de comunicações (TC) do usuário.
10. Servidor intermediário (Srvlnt) para delegar a implantação de transações caracterizado pelo fato de que compreende: - meios para registrar pelo menos um servidor de pagamento (SrvP) no dito servidor intermediário, sendo que os ditos meios entregam, dentro do dito servidor intermediário (Srvibt), uma estrutura de dados de delegação (SructDel) que compreende pelo menos uma associação entre o dito servidor de pagamento (Srvp) e pelo menos uma lista de tipos de transações delegadas (LTDe) pelo dito servidor de pagamento (SrvP) para o dito servidor intermediário; e - meios para registrar pelo menos um usuário (Usr) no dito servidor intermediário (Srvlnt), sendo que os ditos meios entregam, dentro do dito servidor intermediário (Srvlnt), uma estrutura de dados de aprovisionamento (StructProv) que compreende pelo menos uma associação entre um identificador de usuário (id), um identificador de servidor de pagamento (idSrvP) e um identificador de usuário (idP) com o dito servidor de pagamento (SrvP).
11. Produto de programa de computador transferível por download a partir de uma rede de comunicações e/ou gravado em uma portadora legível por computador e/ou executável por um microprocessador caracterizado pelo fato de que compreende instruções de código de programa para a execução de um método para delegar, conforme definido na reivindicação 1, quando o mesmo é executado em um computador.
BR102015012232A 2014-05-28 2015-05-27 método para delegar uma implantação de transações, dispositivos e programas correspondentes BR102015012232A2 (pt)

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
FR1454880A FR3021791B1 (fr) 2014-05-28 2014-05-28 Procede de delegation d'une mise en œuvre de transactions, dispositifs et programmes correspondants

Publications (1)

Publication Number Publication Date
BR102015012232A2 true BR102015012232A2 (pt) 2015-12-29

Family

ID=51168253

Family Applications (1)

Application Number Title Priority Date Filing Date
BR102015012232A BR102015012232A2 (pt) 2014-05-28 2015-05-27 método para delegar uma implantação de transações, dispositivos e programas correspondentes

Country Status (6)

Country Link
US (1) US10055713B2 (pt)
EP (1) EP2950255A1 (pt)
BR (1) BR102015012232A2 (pt)
CA (1) CA2892841C (pt)
FR (1) FR3021791B1 (pt)
RU (1) RU2015120070A (pt)

Family Cites Families (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
FR2789785A1 (fr) * 1999-02-11 2000-08-18 Didier Badaire Procede et systeme de delegation de paiement, notamment d'une pluralite de services, serveur de liquidation, terminal d'acceptation et dispositif portatif associes
US20050015332A1 (en) * 2003-07-18 2005-01-20 Grace Chen Cashless payment system
US20120150748A1 (en) * 2010-12-14 2012-06-14 Xtreme Mobility Inc. System and method for authenticating transactions through a mobile device
US9519902B2 (en) * 2013-06-25 2016-12-13 Quisk, Inc. Fraud monitoring system with distributed cache
US20150046327A1 (en) * 2013-08-07 2015-02-12 Cashcloud Ag Server-based payment system

Also Published As

Publication number Publication date
US20150347988A1 (en) 2015-12-03
US10055713B2 (en) 2018-08-21
FR3021791A1 (fr) 2015-12-04
CA2892841A1 (en) 2015-11-28
EP2950255A1 (fr) 2015-12-02
FR3021791B1 (fr) 2018-05-18
RU2015120070A (ru) 2016-12-20
CA2892841C (en) 2023-08-22

Similar Documents

Publication Publication Date Title
CN104639534B (zh) 网站安全信息的加载方法和浏览器装置
US9867043B2 (en) Secure device service enrollment
US8694795B1 (en) Method and apparatus for secure application execution
CN104618108B (zh) 安全通信系统
US8387119B2 (en) Secure application network
US9203842B2 (en) Establishing connections for secure element communications
AU2014272654B2 (en) Systems and methods for verification conducted at a secure element
CN110770695A (zh) 物联网(iot)设备管理
US10757089B1 (en) Mobile phone client application authentication through media access gateway (MAG)
US9300674B2 (en) System and methods for authorizing operations on a service using trusted devices
US20150067793A1 (en) Method for Secure, Entryless Login Using Internet Connected Device
KR20190039603A (ko) 보안 프로세서 칩 및 단말 장치
US20190080079A1 (en) Method and device for verifying security of application
US20220239467A1 (en) System and method for blockchain-based device authentication based on a cryptographic challenge
EP4348472A1 (en) System and method for hosting and remotely provisioning a payment hsm by way of out-of-band management
CN114024751B (zh) 一种应用访问控制方法、装置、计算机设备及存储介质
CN105814834B (zh) 用于公共云应用的基于推送的信任模型
WO2015117323A1 (zh) 一种实现远程支付的方法及装置
US11972419B2 (en) Method for authenticating payment data, corresponding devices and programs
BR102015012232A2 (pt) método para delegar uma implantação de transações, dispositivos e programas correspondentes
WO2015117326A1 (zh) 一种实现远程支付的方法、装置及智能卡
ES2770087T3 (es) Procedimiento de procesamiento de datos transaccionales, dispositivo y programa correspondientes
Gunasinghe CLOUD BASED SECURE ELEMENT IMPLEMENTATION FOR ANDROID HOST CARD EMULATION
Park A Methodology for UICC-Based Security Services in Pervasive Fixed Mobile Convergence Systems
BR102015031254A2 (pt) método para autenticar um usuário, servidor correspondente, terminal de comunicações e programas

Legal Events

Date Code Title Description
B03A Publication of a patent application or of a certificate of addition of invention [chapter 3.1 patent gazette]
B11A Dismissal acc. art.33 of ipl - examination not requested within 36 months of filing
B11Y Definitive dismissal - extension of time limit for request of examination expired [chapter 11.1.1 patent gazette]