PT11178T - Sistema e método de processamento de transações - Google Patents

Abstract

O SISTEMA DIVULGADO NO PRESENTE PEDIDO RESULTA DA NECESSIDADE DE PROCESSAMENTO DE TRANSAÇÕES EM QUE ESTAS SÃO AUTORIZADAS DE FORMA SEGURA. O SISTEMA COMPREENDE UMA PLATAFORMA MULTISSERVIÇOS (1), UMA APLICAÇÃO (2) COM A QUAL O UTILIZADOR (9) INTERAGE, UM SISTEMA DE ADESÃO (3), UM SISTEMA DE COMERCIANTE (4), PELO MENOS UM CANAL DE COMUNICAÇÃO COM ENTIDADES EXTERNAS (5), UM GESTOR DE COMUNICAÇÕES (6), UM GESTOR DE SEGURANÇA (7) E UM GESTOR DE IDENTIFICADORES CHAVE (8). A SUA APLICABILIDADE É, POR EXEMPLO, TRANSVERSAL A TODOS OS SECTORES DE ATIVIDADE QUE REALIZAM VENDAS EM LOJAS FÍSICAS OU VIRTUAIS, E POR ISSO NECESSITAM DE UMA LIGAÇÃO A UM SISTEMA DE PROCESSAMENTO DE TRANSAÇÕES COM SEGURANÇA E GARANTIA DE AUTENTICAÇÃO.

Description

DESCRIÇÃO "SISTEMA E MÉTODO DE PROCESSAMENTO DE TRANSAÇÕES" Dominio técnico 0 presente pedido diz respeito a um método e sistema de processamento de transações financeiras.

Estado da técnica

Conhecem-se soluções centralizadas para o processamento de transações de pagamento, como por exemplo o documento WO2013078898A1 que divulga um método de pagamento online em que as transações se realizam a partir de informações obtidas num dispositivo com capacidade de leitura de códigos de barras dos produtos. As informações da conta do cliente e as informações de conta de comerciante são enviadas através do dispositivo para uma plataforma de processamento de pagamentos.

Neste tipo de sistema de processamento de transações, o pedido de pagamento compreende os dados de autenticação do cliente. 0 encapsulamento referido coloca informações privadas dos utilizadores em canais que, embora protegidos, são monitorizados por outros agentes para além da plataforma central e do utilizador, como por exemplo os comerciantes.

Numa outra abordagem, o documento EP1710980A2 divulga um tipo de autenticação que se serve da capacidade instalada ao nivel do cartão Módulo de Identificação do Assinante (Subscriber Identity Module - SIM) para autenticar um dispositivo móvel. Esta solução permite isolar a etapa de autenticação, no entanto tem um alto grau de dependência dos Operadores de Redes Moveis (Mobile Network Operator - MNO) .

Sumário 0 presente pedido descreve um método de operação de um sistema de processamento de transações financeiras que compreende as seguintes etapas: - receber um pedido de transação de uma primeira entidade, que compreende: - um identificador chave de uma segunda entidade, e - informações sobre a transação a requerer; - correlacionar um identificador chave com pelos menos um identificador de aplicação; - enviar uma notificação de pedido de transação para pelo menos um identificador de aplicação, que compreende informação sobre a transação requerida pela primeira entidade; - receber uma resposta de notificação de pedido de transação da segunda entidade, que compreende: - informação de aceitação do pedido de transação, e - informação de autenticação da segunda entidade; - realizar uma transação em pelo menos uma entidade externa; e - enviar uma notificação para duas entidades, que compreende informação do sucesso ou insucesso da transação.

Numa forma de realização a etapa de envio de uma notificação de pedido de transação, compreende ainda pelo menos um instrumento de pagamento disponível para a segunda entidade.

Numa outra forma de realização a etapa de recebimento de uma resposta de notificação de pedido de transação, compreende pelo menos um instrumento de pagamento escolhido pela segunda entidade.

Ainda numa outra forma de realização a etapa de recebimento de uma resposta de notificação de pedido de transação, compreende um Token Dinâmico de Autenticação (TDA) da segunda entidade.

Numa forma de realização a etapa de envio de uma notificação, compreende um TDA novo para a segunda entidade. 0 presente pedido divulga ainda uma forma de realização do método anterior que compreende ainda as seguintes etapas: - recolher e enviar um pedido de transação de uma primeira entidade, que compreende: - um identificador chave de uma segunda entidade, e - informações sobre a transação a requerer; - receber uma notificação , que compreende: - informação do sucesso ou insucesso da transação requerida. 0 presente pedido divulqa ainda uma forma de realização do método anterior que compreende ainda as seguintes etapas: - receber e apresentar a uma segunda entidade uma notificação de pedido de transação , que compreende: - informação sobre uma transação requerida por uma primeira entidade, e - informação de pedido de autenticação da segunda entidade; - recolher e enviar uma resposta de notificação de pedido de transação da segunda entidade, que compreende informação de aceitação de um pedido de transação; e - receber uma notificação , que compreende informação do sucesso ou insucesso de um pedido de transação.

Numa forma de realização, a etapa de recebimento e apresentação de uma notificação de pedido de transação, compreende pelo menos um instrumento de pagamento disponível para a segunda entidade.

Numa outra forma de realização a etapa de recolha e envio de uma resposta de notificação de pedido de transação, compreende pelo menos um instrumento de pagamento escolhido pela segunda entidade.

Ainda numa outra forma de realização a etapa de recolha e envio de uma resposta de notificação de pedido de transação, compreende um TDA da segunda entidade.

Numa forma de realização a etapa de recebimento de uma notificação, compreende um TDA novo para a segunda entidade. 0 presente pedido divulga ainda uma forma de realização do método anterior que compreende ainda as etapas: - receber um pedido de registo de identificador de aplicação , que compreende: - um identificador chave, e - um código de autenticação de uma entidade, - enviar um código de ativação através de uma forma de comunicação relacionada com um identificador chave; - receber um código de ativação de uma entidade; - se o código de ativação enviado for igual ao recebido, então registar uma relação entre um identificador chave e um identificador de aplicação; - enviar uma notificação , que compreende informação de sucesso do pedido de registo de identificador de aplicação.

Numa forma de realização o método compreende ainda a etapa de gerar um primeiro TDA.

Numa outra forma de realização a etapa de envio de uma notificação, compreende ainda o envio do primeiro TDA gerado. 0 presente pedido divulga ainda uma forma de realização do método anterior que compreende ainda as etapas: - recolher e enviar um pedido de registo de identificador de aplicação , que compreende: - um identificador chave, e - um código de autenticação de uma entidade, - recolher e enviar um código de ativação de uma entidade; e - receber uma notificação , que compreende a informação de sucesso de um pedido de registo de identificador de aplicação.

Numa forma de realização a etapa de recebimento de uma notificação, compreende ainda um primeiro TDA.

Numa outra forma de realização a etapa de recebimento de uma notificação, compreende ainda pelo menos um instrumento de pagamento disponível para a segunda entidade. 0 presente pedido divulga ainda um sistema de processamento de transações financeiras que compreende uma plataforma multisserviços que compreende um gestor de comunicações configurado para implementar as etapas: - receber um pedido de transação de uma primeira entidade, que compreende: - um identificador chave de uma segunda entidade, e - informações sobre a transação a requerer; - enviar uma notificação de pedido de transação para pelo menos um identificador de aplicação, que compreende informação sobre a transação requerida pela primeira entidade; - receber uma resposta de notificação de pedido de transação da segunda entidade, que compreende: - informação de aceitação do pedido de transação , e - informação de autenticação da segunda entidade; - enviar uma notificação para duas entidades, que compreende informação do sucesso ou insucesso da transação. uma base de dados de endereçamento de aplicações configurada para implementar a etapa: - correlacionar um identificador chave com pelos menos um identificador de aplicação, e pelo menos um canal de comunicação com entidades externas para implementar a etapa: - realizar uma transação em pelo menos uma entidade externa.

Numa forma de realização gestor de comunicações é configurado para implementar a etapa de envio de uma notificação de pedido de transação, que compreende ainda pelo menos um instrumento de pagamento disponível para a segunda entidade.

Numa outra forma de realização o gestor de comunicações é configurado para implementar a etapa de recebimento de uma resposta de notificação de pedido de transação, que compreende pelo menos um instrumento de pagamento escolhido pela segunda entidade.

Ainda numa outra forma de realização o gestor de comunicações é configurado para implementar a etapa de recebimento de uma resposta de notificação de pedido de transação, que compreende um Token Dinâmico de Autenticação (TDA) da segunda entidade.

Numa forma de realização o gestor de comunicações é configurado para implementar a etapa de envio de uma notificação, que compreende um TDA novo para a segunda entidade. 0 presente pedido divulga ainda uma forma de realização do sistema que compreende ainda pelo menos um sistema de comerciante configurado para implementar as etapas: - recolher e enviar um pedido de transação de uma primeira entidade, que compreende: - um identificador chave de uma segunda entidade, e - informações sobre a transação a requerer; - receber uma notificação , que compreende: - informação do sucesso ou insucesso da transação requerida. 0 presente pedido divulga ainda uma forma de realização do sistema que compreende ainda pelo menos uma aplicação configurada para implementar as etapas: - receber e apresentar a uma segunda entidade uma notificação de pedido de transação , que compreende: - informação sobre uma transação requerida por uma primeira entidade, e - informação de pedido de autenticação da segunda entidade; - recolher e enviar uma resposta de notificação de pedido de transação da segunda entidade, que compreende informação de aceitação de um pedido de transação; e - receber uma notificação, que compreende informação do sucesso ou insucesso de um pedido de transação.

Numa forma de realização a aplicação é configurada para implementar a etapa de recebimento e apresentação de uma notificação de pedido de transação, que compreende pelo menos um instrumento de pagamento disponível para a segunda entidade.

Numa outra forma de realização a aplicação é configurada para implementar a etapa de recolha e envio de uma resposta de notificação de pedido de transação, que compreende pelo menos um instrumento de pagamento escolhido pela segunda entidade.

Ainda numa outra forma de realização a aplicação é configurada para implementar a etapa de recolha e envio de uma resposta de notificação de pedido de transação, compreende um TDA da segunda entidade.

Numa forma de realização a aplicação é configurada para implementar a etapa de recebimento de uma notificação, que compreende um TDA novo para a segunda entidade. 0 presente pedido divulga ainda uma forma de realização do sistema em que o gestor de comunicações é configurado para implementar as etapas: - receber um pedido de registo de identificador de aplicação , que compreende: - um identificador chave, e - um código de autenticação de uma entidade, - enviar um código de ativação através de uma forma de comunicação relacionada com um identificador chave; - receber um código de ativação de uma entidade; - enviar uma notificação , que compreende informação de sucesso do pedido de registo de identificador de aplicação, e uma base de dados de endereçamento de aplicações configurada ainda para implementar a etapa: - se o código de ativação enviado for igual ao recebido, então registar uma relação entre um identificador chave e um identificador de aplicação.

Numa forma de realização o gestor de comunicações é configurado para implementar ainda a etapa de gerar um primeiro TDA.

Numa outra forma de realização o gestor de comunicações é configurado para implementar a etapa de envio de uma notificação, que compreende ainda o envio do primeiro TDA gerado. 0 presente pedido divulga ainda uma forma de realização do sistema que compreende pelo menos uma aplicação configurada para implementar as etapas: - recolher e enviar um pedido de registo de identificador de aplicação , que compreende: - um identificador chave, e - um código de autenticação de uma entidade, - recolher e enviar um código de ativação de uma entidade; e - receber uma notificação , que compreende a informação de sucesso de um pedido de registo de identificador de aplicação.

Numa forma de realização a aplicação é configurada para implementar a etapa de recebimento de uma notificação, que compreende ainda um primeiro TDA.

Numa outra forma de realização a aplicação é configurada para implementar a etapa de recebimento de uma notificação, que compreende ainda pelo menos um instrumento de pagamento disponível para a segunda entidade. 0 presente pedido divulga ainda a utilização do sistema anterior numa loja física. 0 presente pedido divulga ainda a utilização do sistema anterior numa loja virtual.

Descrição geral 0 sistema divulgado no presente pedido resulta da necessidade de processamento de transações em que estas são autorizadas de forma segura.

Verifica-se uma tendência de alargamento dos canais ao dispor de utilizadores e comerciantes para realizar transações de pagamento. Dos principais canais disponibilizados destaca-se a Internet, o telemóvel e a televisão. A tendência vem acentuar a criticidade do pagamento simples, cómodo e seguro. 0 sistema divulgado no presente pedido compreende um ambiente de processamento de transações financeiras, chamado de plataforma multisserviços, que recebe um pedido de transação num canal e a instrução de aceitação e autenticação consequente num outro canal de comunicação seguro com pelo menos uma aplicação.

Recorrendo a um canal de comunicação isolado, a introdução de uma etapa de aceitação e autenticação anterior à concretização efetiva da transação garante maior segurança à transação. 0 processamento efetivo das transações realiza-se posteriormente à aceitação e autenticação positiva na aplicação, através de um canal de comunicação com instituições de processamento de transações.

Para que a etapa de aceitação e autenticação se realize, é necessário que a plataforma multisserviços notifique a aplicação de uma entidade da existência de um pedido de transação. Mais especificamente, é necessário resolver o problema de encaminhar um pedido de transação para uma aplicação com base no identificador chave (alias) fornecido no pedido de transação. Nesse sentido, a plataforma multisserviços compreende uma base de dados que relaciona identificadores chave com identificadores de aplicação. 0 serviço de processamento de transações fornecido pelo sistema é agnóstico ao tipo de operação financeira de cada transação, podendo o lado cliente do serviço assentar em duas vertentes: - utilizador, disponibilizando, por exemplo, uma forma de efetuar uma compra ou uma maneira de realizar uma transferência para outra entidade; - comerciante, disponibilizando, por exemplo, uma forma de aceitar pagamentos numa loja física ou virtual. A sua aplicabilidade é, por exemplo, transversal a todos os sectores de atividade que realizam vendas em lojas físicas ou virtuais, e por isso necessitam de uma ligação a um sistema de processamento de transações com segurança e garantia de autenticação.

Breve descrição das figuras

Para uma mais fácil compreensão do presente pedido juntam-se em anexo figuras, as quais, representam realizações preferenciais que, contudo, não pretendem limitar a técnica aqui divulgada. A Figura 1 ilustra a arquitetura do sistema, em que os sinais de referência representam: 1 - Plataforma multisserviços; 2 - Dispositivo e Aplicação; 3 - Canal de adesão; 4 - Sistemas de comerciante; 5 - Sistemas das entidades externas; 6 - Gestor de comunicações; 7 - Gestor de segurança; 8 - Gestor de identificador chave; e 9 - Utilizador A Figura 2 ilustra os elementos envolvidos no processo de adesão, em que os sinais de referência representam: 1 - Plataforma multisserviços; 2 - Dispositivo e aplicação; 3 - Canal de adesão; 5 - Sistemas das entidades externas; 9 - Utilizador; 101 - Cliente acede a frontend de pré registo de adesão de serviço; 102 - Adesão de serviço enviada para plataforma multisserviços, plataforma multisserviços pronta para aceitar adesão via aplicação; 103 - Aplicação realiza um primeiro acesso da aplicação, enviando um pedido de registo de indentificador de aplicação com o identificador chave (por exemplo o número de telemóvel), o código de autenticação do utilizador e o identificador de aplicação; 104 - Plataforma multisserviços envia mensagem para o identificador chave (por exemplo o número de telemóvel) com um código de ativação; 105 - Envio para a plataforma multisserviços do código de ativação lido a partir da mensagem; 106 - Plataforma multisserviços envia notificação com a informação de sucesso do pedido de registo de identificador de aplicação; 107 - Gestão de informação financeira; 108 - Plataforma multisserviços envia dados de informação financeira, e sincroniza Token Dinâmico de Autenticação (TDA) para a aplicação; 109 - Ações de gestão do serviço via canal de adesão; e 110 - Ações de gestão do serviço através da aplicação. A Figura 3 ilustra a os elementos envolvidos no processamento de uma transacção, em que os sinais de referência representam: 1 - Plataforma multisserviços; 2 - Dispositivo e aplicação; 4 - Sistemas de comerciante; 5 - Sistemas das entidades externas; 9 - Utilizador; 212 - Cliente interage com comerciante fornecendo o seu identificador chave; 213 - Pedido de transação enviado à plataforma multisserviços; 214 - Envio de notificação de pedido de transação ao cliente; 215 - Resposta a notificação de pedido de transação com informação sobre autorização. Plataforma

Multisserviços valida dispositivo de cliente com base no TDA; 216 - Processamento da autorização da transação financeira em real time; e 217 - Informação sobre o resultado da transação.

Descrição de formas de realização

Fazendo referência às figuras, algumas formas de realização vão ser agora descritas de forma mais pormenorizada, as quais não pretendem contudo limitar o âmbito do presente pedido.

Numa forma de realização, a arquitetura do sistema, ilustrada na figura 1, para receber, tratar e encaminhar pedidos de pagamentos efetuados em canais remotos com base num identificador chave, por exemplo o número de telemóvel utilizado por um cliente de uma loja, compreende: - uma plataforma multisserviços (1) para a autenticação, encaminhamento e processamento de transações; - pelo menos uma aplicação (2), que irá garantir a segurança na captura do código pessoal do utilizador e a sua comunicação para a plataforma, e permite a transmissão de instruções de gestão de transações financeiras e não financeiras inerentes à gestão do serviço, como por exemplo alterar o código de autenticação ou associar um identificador chave; - pelo menos um canal de adesão (3), para que o utilizador possa aderir ao serviço de forma segura; - pelo menos um sistema de comerciante (4), utilizado por parte dos comerciantes nos seus canais de venda, com acesso a Interfaces de Programação de Aplicação (Application Programming Interface - API) disponibilizadas através de serviços web, para acesso ao processamento das suas transações através da plataforma multisserviços; - pelo menos um canal de comunicação com entidades externas (5), para realizar o processamento de transações; - um gestor de comunicações (6) que é responsável por fornecer uma camada de serviços em formato standard da arquitetura para o envio e receção de mensagens. Esta componente deve fornecer uma interface aplicacional que permita outras componentes da arquitetura fornecerem os dados para envio de mensagens, como por exemplo, a origem, o destino, o modelo e meios de mensagem a utilizar, os dados a incluir na mensagem e outros que sejam cruciais ao cumprimento das suas funções. É responsabilidade desta componente a obtenção do modelo a utilizar, a partir de repositório próprio ou externo, e realizar as correspondentes substituições pelos dados fornecidos via interface aplicacional; - um gestor de identificadores chave (8), para associar e identificar dados financeiros, evitando que estes sejam colocados ou dados a conhecer através dos canais de comunicação. A plataforma multisserviços (1) será central na solução, sendo responsável pela gestão integral do serviço, nas vertentes de configuração de serviço e seus parâmetros, gestão de identificadores chave, como por exemplo o registo de associações entre identificadores chave de serviço, e.g. n° de telemóvel, matricula automóvel, ID set-top-box, etc., a dados financeiros, e.g. cartões bancários e contas, gestão de transações de pagamentos, obtenção de dados estatísticos de utilização de serviço, entre outras que possam ser identificadas como importantes para a correta prestação do serviço. A aplicação (2) é a ferramenta do utilizador final para interação e gestão do serviço. A aplicação tem como função principal a implementação do processo de aceitação e autenticação do cliente em resposta a um pedido de transação. Essa autenticação deverá fornecer o grau suficiente de segurança e confidencialidade, de modo a evitar potenciais utilizações fraudulentas. Caso o utilizador (9) tenha vários dispositivos, como por exemplo um tablet e um smartphone, com a aplicação instalada, este receberá notificações de pedido de transação e notificações replicadas nos vários identificadores de aplicação.

Numa forma de realização, a plataforma multisserviços compreende ainda um gestor de segurança (7), que permite a verificação e reatribuição do TDA. 0 TDA serve para estabelecer uma sequência de confiança e é sempre gerado pela plataforma multisserviços (1) . 0 envio de um novo TDA para a aplicação é realizado na instalação da mesma para inicialização, e sempre que uma transação com o servidor ocorre com sucesso. 0 gestor de segurança trata ainda da verificação e gestão dos códigos de autenticação e de ativação da aplicação auxiliando a gestão segura do ciclo de vida da aplicação. A aplicação que recolhe o código de autenticação está registada e é unívoca sendo a sua segurança mantida por uma gestão interna de TDAs.

Esta robustez é incrementada através da utilização de um método dinâmico de autenticação atualizado em cada interação entre a plataforma e a aplicação, e de um jogo de dinâmica associadas ao uso e time out de códigos de autenticação e processos de verificação de uso de terminais ou identificador chave. Associado a estas medidas de segurança estão definidos vários parâmetros de gestão do serviço que passam pela visualização de estado das aplicações a partir do próprio dispositivo, e gestão do funcionamento dos mesmos pelo utilizador, meios de gestão do ciclo de vida do serviço e da aplicação, e regras de ativação de aplicações ou associação de produtos financeiros ao serviço.

De modo a garantir essa função principal é necessário que a aplicação detenha a capacidade de gerir instrumentos de pagamento, como por exemplo referências para contas bancárias ou virtuais em diferentes entidades externas, associados ao serviço do cliente, assegurando, entre outras, as seguintes funcionalidades: - receber notificações de novos instrumentos de pagamento associados, bem como os dissociados do serviço; - permitir que o cliente veja que instrumentos de pagamento se encontram associados ao serviço; - permitir ao cliente a escolha de instrumentos de pagamento a utilizar no momento do pagamento e que este defina um novo instrumentos de pagamento por omissão; e - permitir ao cliente a consulta dos pagamentos: a) que efetuou através deste serviço independentemente do instrumentos de pagamento de pagamento; b) que efetuou por instrumentos de pagamento associado ao serviço.

Como funções acessórias, o utilizador deve poder definir algumas personalizações, como por exemplo: - visualização e gestão dos dispositivos ligados ao serviço; - consultar identificadores chave associado à aplicação; e - definir o seu perfil financeiro, como por exemplo informação sobre o número de contribuinte e outros dados financeiros.

Instalação na vertente de utilizador

Um utilizador (9), enquanto cliente final, realiza transações com base no seu identificador chave na introdução de um código de autenticação numa aplicação (2). 0 utilizador (9) da aplicação (2), para poder utilizar o serviço, terá que aderir ao mesmo através de um canal de adesão (3) seguro, tal como ilustrado na figura 2, associar o seu identificador chave ao instrumento de pagamento, definir o seu código de autenticação para o serviço e definir um valor de gasto máximo diário.

Uma vez terminado este registo inicial, o utilizador (9) deverá descarregar a aplicação (2) para, por exemplo, um dispositivo móvel. Além disso, o utilizador (9) deverá aceitar os termos de utilização do serviço e efetuar o seu primeiro início de sessão, com base no identificador chave e código definido previamente no canal de adesão (3) seguro.

Qualquer identificador chave associado pelo cliente ou comerciante, carece sempre de validação de existência e ligação ao utilizador. Se estivermos a considerar um identificador chave pessoal, as verificações são direcionadas ao utilizador e obrigam a uma ação manual por parte do utilizador, como por exemplo, a receção de um código através de mensagem curta no dispositivo móvel ou através de correio eletrónico que tem que ser manualmente copiado para a aplicação móvel. No caso de um identificador chave atribuído por uma entidade, como por exemplo uma matrícula, uma Set Top Box, ou um cartão de sócio de um clube, a verificação é feita tendo por base que o pedido chega à plataforma multisserviços através de um comerciante, ou mesmo que tenha origem no utilizador, o mesmo terá interação com um comerciante na verificação da elegibilidade do identificador chave.

Ao efetuar o primeiro início de sessão, é enviado uma mensagem com um código de ativação através do gestor de comunicações (6), componente interna da plataforma multisserviços (1), nomeadamente através de uma forma de comunicação relacionada com um identificador chave. Este código de ativação deverá ser inserido na aplicação para ativar o serviço com sucesso. Este passo representa a troca de um conjunto de informação e de dados de cliente e aplicação do serviço com a plataforma multisserviços (1). A partir do momento em que o código for colocado com o sucesso esperado, a aplicação é configurada com os dados do cliente e o serviço estará pronto a ser utilizado. 0 envio da mensagem valida assim a titularidade do identificador chave do cliente, e da aplicação, ao utilizar processos de autenticação seguros utilizados, por exemplo, em redes de telecomunicações.

Instalação na vertente de comerciante

Para que um comerciante aceite pagamentos através do serviço, este tem que implementar interfaces próprios, como por exemplo funções na frente de loja para recolha do identificador chave do cliente para processamento da transação, que permitirão canalizar as transações de pagamento para processamento na plataforma multisserviços (1) . A loja do comerciante pode existir em vários ambientes, como por exemplo fisicamente ou remotamente na Internet.

Todas as comunicações entre os sistemas do comerciante (4) e a plataforma multisserviços (1) serão efetuadas através de um protocolo seguro, como por exemplo o Hypertext Transfer Protocol Secure (HTTPS). As comunicações entre ο comerciante e plataforma são autenticadas em ambos os lados do canal de comunicação através de certificados digitais, emitidos por uma entidade de certificação de confiança.

Em algumas formas de realização, o pagamento pode ser iniciado a partir de sistemas de comerciantes que tenham os interfaces técnicos implementados, como por exemplo: websites de comércio online (e-commerce), comércio móvel (m-commerce), comércio televisivo (tv commerce), máquinas de pagamento de estacionamento, máquinas de venda automática (vending machines) ou caixas de pagamento self-service .

Exemplo 1: Compra presencial ou remota A figura 3 ilustra um exemplo de uma transação de pagamento numa loja física ou virtual em que o cliente tem em seu poder um dispositivo móvel com a aplicação instalada. 0 cliente começa por indicar ao comerciante o seu identificador chave. Com essa informação, o comerciante utiliza um sistema de comerciante (4), para dar inicio do pedido de pagamento, realizando neste caso o papel de requerente de transação. Este pedido compreende o valor a cobrar ao cliente e o identificador chave indicado, entre outros dados necessários e criticos ao correcto processamento financeiro da transacção.

Após efetuar algumas validações da informação do pedido, como por exemplo verificar se o identificador chave está registado no serviço ou se o instrumento de pagamento associado é válido, a plataforma multisserviços envia uma notificação de pedido de transação para a aplicação (2) instalada no dispositivo móvel do cliente. 0 pedido de autenticação da operação é feito com base numa conversão interna da plataforma multisserviços onde interpreta os identificadores chave do cliente e converte num identificador de aplicação que vai permitir a aceitação, escolha do instrumento de pagamento e autenticação da operação. 0 cliente recebe a notificação de pedido de autenticação de transação no seu dispositivo móvel que o direciona para um ecrã da aplicação (2) . Aqui são apresentados os dados de pagamento, permitindo ao utilizador selecionar o instrumento de pagamento a utilizar. Em seguida, é solicitado ao cliente que digite o seu código de autenticação. Depois de digitar e confirmar o código, é enviada resposta para a plataforma multisserviços que permitirá dar inicio ao processamento do pagamento.

Numa outra forma de realização, pode não ser solicitado o código, ficando-se pela confirmação dos dados de pagamento.

Numa forma de realização, se o utilizador (9) possuir dois dispositivos móveis com aplicações (2) instaladas de forma correta e completa, a notificação enviada pela plataforma multisserviços (1) é recebida nos dois dispositivos. Um identificador chave é assim associado a mais do que uma aplicação na base de dados de identificação de aplicações. 0 processo termina com a comunicação da plataforma multisserviços (1) quer para o sistema de comerciante (4), quer para a aplicação (2). Esta mensaqem transmite a informação relacionada com o resultado de sucesso ou insucesso da transação financeira. São exemplos de insucesso o saldo insuficiente ou código errado. A presente realização não é, naturalmente, de modo algum restrita às realizações descritas neste documento e uma pessoa com conhecimentos médios da área poderá prever muitas possibilidades de modificação da mesma sem se afastar da ideia geral, tal como definido nas reivindicações.

As realizações preferenciais acima descritas são obviamente combináveis entre si. As seguintes reivindicações definem adicionalmente realizações preferenciais.

Lisboa, 22 de maio de 2015.

Claims (36)

1. REIVINDICAÇÕES

   1. Um método de operação de um sistema de processamento de transações financeiras, caracterizado por compreender as seguintes etapas: - receber um pedido de transação (213) de uma primeira entidade, que compreende: - um identificador chave de uma segunda entidade, e - informações sobre a transação a requerer; - correlacionar um identificador chave com pelos menos um identificador de aplicação; - enviar uma notificação de pedido de transação (214) para pelo menos um identificador de aplicação, que compreende informação sobre a transação requerida pela primeira entidade; - receber uma resposta de notificação de pedido de transação (215) da segunda entidade, que compreende: - informação de aceitação do pedido de transação (213), e - informação de autenticação da segunda entidade; - realizar uma transação em pelo menos uma entidade externa; e - enviar uma notificação (217) para duas entidades, que compreende informação do sucesso ou insucesso da transação.
2. 2. Método de acordo com a reivindicação anterior, caracterizado por a etapa de envio de uma notificação de pedido de transação (214), compreender ainda pelo menos um instrumento de pagamento disponível para a segunda entidade.
3. 3. Método de acordo com qualquer uma das reivindicações anteriores, caracterizado por a etapa de recebimento de uma resposta de notificação de pedido de transação (215), compreender pelo menos um instrumento de paqamento escolhido pela sequnda entidade.
4. 4. Método de acordo com qualquer uma das reivindicações anteriores, caracterizado por a etapa de recebimento de uma resposta de notificação de pedido de transação (215), compreender um Token Dinâmico de Autenticação (TDA) da sequnda entidade.
5. 5. Método de acordo com qualquer uma das reivindicações anteriores, caracterizado por a etapa de envio de uma notificação (217), compreender um TDA novo para a sequnda entidade.
6. 6. Método de acordo com qualquer uma das reivindicações anteriores, caracterizado por compreender ainda as seguintes etapas: - recolher e enviar um pedido de transação (213) de uma primeira entidade, que compreende: - um identificador chave de uma segunda entidade, e - informações sobre a transação a requerer; - receber uma notificação (217), que compreende: - informação do sucesso ou insucesso da transação requerida.
7. 7. Método de acordo com qualquer uma das reivindicações anteriores, caracterizado por compreender ainda as seguintes etapas: - receber e apresentar a uma segunda entidade uma notificação de pedido de transação (214), que compreende: - informação sobre uma transação requerida por uma primeira entidade, e - informação de pedido de autenticação da segunda entidade; - recolher e enviar uma resposta de notificação de pedido de transação (215) da segunda entidade, que compreende informação de aceitação de um pedido de transação; e - receber uma notificação (217), que compreende informação do sucesso ou insucesso de um pedido de transação.
8. 8. Método de acordo com a reivindicação anterior, caracterizado por a etapa de recebimento e apresentação de uma notificação de pedido de transação (214), compreender pelo menos um instrumento de pagamento disponível para a segunda entidade.
9. 9. Método de acordo com qualquer uma das reivindicações de 7 a 8, caracterizado por a etapa de recolha e envio de uma resposta de notificação de pedido de transação (215), compreender pelo menos um instrumento de pagamento escolhido pela segunda entidade.
10. 10. Método de acordo com qualquer uma das reivindicações de 7 a 9, caracterizado por a etapa de recolha e envio de uma resposta de notificação de pedido de transação (215), compreender um TDA da segunda entidade.
11. 11. Método de acordo com qualquer uma das reivindicações de 7 a 10, caracterizado por a etapa de recebimento de uma notificação (217), compreender um TDA novo para a segunda entidade.
12. 12. Método de acordo com qualquer uma das reivindicações anteriores, caracterizado por compreender ainda as etapas: - receber um pedido de registo de identificador de aplicação (103), que compreende: - um identificador chave, e - um código de autenticação de uma entidade, - enviar um código de ativação (104) através de uma forma de comunicação relacionada com um identificador chave; - receber um código de ativação (105) de uma entidade; - se o código de ativação (105) enviado for igual ao recebido, então registar uma relação entre um identificador chave e um identificador de aplicação; - enviar uma notificação (106), que compreende informação de sucesso do pedido de registo de identificador de aplicação.
13. 13. Método de acordo com a reivindicação anterior, caracterizado por compreender ainda a etapa de gerar um primeiro TDA.
14. 14. Método de acordo com qualquer uma das reivindicações 12 13, caracterizado por a etapa de envio de uma notificação (106), compreender ainda o envio do primeiro TDA gerado.
15. 15. Método de acordo com qualquer uma das reivindicações anteriores, caracterizado por compreender ainda as etapas: - recolher e enviar um pedido de reqisto de identificador de aplicação (103), que compreende: - um identificador chave, e - um códiqo de autenticação de uma entidade, - recolher e enviar um códiqo de ativação (105) de uma entidade; e - receber uma notificação (106), que compreende a informação de sucesso de um pedido de reqisto de identificador de aplicação.
16. 16. Método de acordo com a reivindicação anterior, caracterizado por a etapa de recebimento de uma notificação (106), compreender ainda um primeiro TDA.
17. 17. Método de acordo com qualquer umas das reivindicações 15 a 16, caracterizado por a etapa de recebimento de uma notificação (106), compreender ainda pelo menos um instrumento de paqamento disponível para a sequnda entidade.
18. 18. Um sistema para o processamento de transações financeiras, caracterizado por compreender uma plataforma multisserviços confiqurada para implementar as etapas do método da reivindicação 1, que compreende um qestor de comunicações confiqurado para implementar as etapas: - receber um pedido de transação (213) de uma primeira entidade; - enviar uma notificação de pedido de transação (214) para pelo menos um identificador de aplicação; - receber uma resposta de notificação de pedido de transação (215) da segunda entidade; e - enviar uma notificação (217) para duas entidades, uma base de dados de endereçamento de aplicações configurada para implementar a etapa: - correlacionar um identificador chave com pelos menos um identificador de aplicação, e pelo menos um canal de comunicação com entidades externas para implementar a etapa: - realizar uma transação em pelo menos uma entidade externa.
19. 19. Sistema de acordo com a reivindicação anterior, caracterizado por o gestor de comunicações ser configurado para implementar a etapa de envio de uma notificação de pedido de transação (214) do método da reivindicação 2.
20. 20. Sistema de acordo com qualquer uma das reivindicações 18 a 19, caracterizado por o gestor de comunicações ser configurado para implementar a etapa de recebimento de uma resposta de notificação de pedido de transação (215) do método da reivindicação 3.
21. 21. Sistema de acordo com qualquer uma das reivindicações 18 a 20, caracterizado por o gestor de comunicações ser configurado para implementar a etapa de recebimento de uma resposta de notificação de pedido de transação (215) do método da reivindicação 4.
22. 22. Sistema de acordo com qualquer uma das reivindicações 18 a 21, caracterizado por o qestor de comunicações ser confiqurado para implementar a etapa de envio de uma notificação (217) do método da reivindicação 5.
23. 23. Sistema de acordo com qualquer uma das reivindicações 18 a 22, caracterizado por compreender ainda pelo menos um sistema de comerciante confiqurado para implementar as etapas: - recolher e enviar um pedido de transação (213); e - receber uma notificação (217), do método da reivindicação 6.
24. 24. Sistema de acordo com qualquer das reivindicações de 18 a 23, caracterizado por compreender ainda pelo menos uma aplicação confiqurada para implementar as etapas: - receber e apresentar a uma sequnda entidade uma notificação de pedido de transação (214); - recolher e enviar uma resposta de notificação de pedido de transação (215) de uma sequnda entidade; - receber uma notificação (217), do método da reivindicação 7.
25. 25. Sistema de acordo com a reivindicação anterior, caracterizado por a aplicação ser confiqurada para implementar a etapa de recebimento e apresentação de uma notificação de pedido de transação (214) do método da reivindicação 8.
26. 26. Sistema de acordo com a qualquer uma das reivindicações de 24 a 25, caracterizado por a aplicação ser confiqurada para implementar a etapa de recolha e envio de uma resposta de notificação de pedido de transação (215) do método da reivindicação 9.
27. 27. Sistema de acordo com a qualquer uma das reivindicações de 18 a 2 6, caracterizado por a aplicação ser configurada para implementar a etapa de recolha e envio de uma resposta de notificação de pedido de transação (215) do método da reivindicação 10.
28. 28. Sistema de acordo com a qualquer uma das reivindicações de 18 a 26, caracterizado por a aplicação ser configurada para implementar a etapa de recebimento de uma notificação (217) do método da reivindicação 11.
29. 29. Sistema de acordo com qualquer uma das reivindicações de 18 a 28, caracterizado por a plataforma multisserviços ser configurada para implementar as etapas do método da reivindicação 12, compreender o gestor de comunicações configurado para implementar as etapas: - receber um pedido de registo de identificador de aplicação (103); - enviar um código de ativação (104) através de uma forma de comunicação relacionada com um identificador chave; - receber um código de ativação (105) de uma entidade; e - enviar uma notificação (106), e uma base de dados de endereçamento de aplicações configurada ainda para implementar a etapa: - se o código de ativação enviado for igual ao recebido, então registar uma relação entre um identificador chave e um identificador de aplicação.
30. 30. Sistema de acordo com a reivindicação anterior, caracterizado por o gestor de comunicações ser configurado para implementar ainda a etapa de gerar um primeiro TDA do método da reivindicação 13.
31. 31. Sistema de acordo com qualquer uma das reivindicações de 29 a 30, caracterizado por o gestor de comunicações ser configurado para implementar a etapa de envio de uma notificação (106) do método da reivindicação 14.
32. 32. Sistema de acordo com qualquer uma das reivindicações de 18 a 31, caracterizado por compreender pelo menos uma aplicação configurada para implementar as etapas: - recolher e enviar um pedido de registo de identificador de aplicação (103); - recolher e enviar um código de ativação (105) de uma entidade; e - receber uma notificação (106), do método da reivindicação 15.
33. 33. Sistema de acordo com a reivindicação anterior, caracterizado por a aplicação ser configurada para implementar a etapa de recebimento de uma notificação (106) do método da reivindicação 16.
34. 34. Sistema de acordo com a reivindicação anterior, caracterizado por a aplicação ser configurada para implementar a etapa de recebimento de uma notificação (106) do método da reivindicação 17.
35. 35. Loja física, caracterizada por utilizar o sistema descrito em qualquer uma das reivindicações de 18 a 34.
36. 36. Loja virtual, caracterizada por utilizar o sistema descrito em qualquer uma das reivindicações de 18 a 34. Lisboa, 22 de maio de 2015.