BRPI0621426A2 - sistema e método de gerenciamento de informação - Google Patents
sistema e método de gerenciamento de informação Download PDFInfo
- Publication number
- BRPI0621426A2 BRPI0621426A2 BRPI0621426-6A BRPI0621426A BRPI0621426A2 BR PI0621426 A2 BRPI0621426 A2 BR PI0621426A2 BR PI0621426 A BRPI0621426 A BR PI0621426A BR PI0621426 A2 BRPI0621426 A2 BR PI0621426A2
- Authority
- BR
- Brazil
- Prior art keywords
- card
- management system
- information
- card product
- module
- Prior art date
Links
- 238000000034 method Methods 0.000 title claims abstract description 55
- 238000004891 communication Methods 0.000 claims abstract description 43
- 230000008569 process Effects 0.000 claims abstract description 24
- 239000003795 chemical substances by application Substances 0.000 claims description 75
- 238000013475 authorization Methods 0.000 claims description 32
- 238000012545 processing Methods 0.000 claims description 15
- 230000036541 health Effects 0.000 claims description 7
- 230000003993 interaction Effects 0.000 claims description 4
- 238000007726 management method Methods 0.000 description 121
- 230000015654 memory Effects 0.000 description 17
- 238000004590 computer program Methods 0.000 description 14
- 230000006870 function Effects 0.000 description 14
- 238000012546 transfer Methods 0.000 description 12
- 230000004044 response Effects 0.000 description 11
- 230000033001 locomotion Effects 0.000 description 8
- 230000000694 effects Effects 0.000 description 7
- 230000004913 activation Effects 0.000 description 6
- 238000001914 filtration Methods 0.000 description 6
- 230000000737 periodic effect Effects 0.000 description 6
- 238000013524 data verification Methods 0.000 description 4
- 238000010586 diagram Methods 0.000 description 4
- 238000013519 translation Methods 0.000 description 4
- 230000009471 action Effects 0.000 description 3
- 230000008901 benefit Effects 0.000 description 3
- 208000010587 benign idiopathic neonatal seizures Diseases 0.000 description 3
- 238000010606 normalization Methods 0.000 description 3
- 238000012552 review Methods 0.000 description 3
- 230000001131 transforming effect Effects 0.000 description 3
- 230000015556 catabolic process Effects 0.000 description 2
- 230000008859 change Effects 0.000 description 2
- 238000012790 confirmation Methods 0.000 description 2
- 238000007796 conventional method Methods 0.000 description 2
- 238000013502 data validation Methods 0.000 description 2
- 238000005516 engineering process Methods 0.000 description 2
- 239000000463 material Substances 0.000 description 2
- 238000012986 modification Methods 0.000 description 2
- 230000004048 modification Effects 0.000 description 2
- 238000012795 verification Methods 0.000 description 2
- 101150010802 CVC2 gene Proteins 0.000 description 1
- 230000009118 appropriate response Effects 0.000 description 1
- 238000013474 audit trail Methods 0.000 description 1
- 230000005540 biological transmission Effects 0.000 description 1
- 238000006243 chemical reaction Methods 0.000 description 1
- 238000013461 design Methods 0.000 description 1
- 238000011161 development Methods 0.000 description 1
- 230000018109 developmental process Effects 0.000 description 1
- 238000004049 embossing Methods 0.000 description 1
- 230000012010 growth Effects 0.000 description 1
- 238000009434 installation Methods 0.000 description 1
- 230000002452 interceptive effect Effects 0.000 description 1
- OYIKARCXOQLFHF-UHFFFAOYSA-N isoxaflutole Chemical compound CS(=O)(=O)C1=CC(C(F)(F)F)=CC=C1C(=O)C1=C(C2CC2)ON=C1 OYIKARCXOQLFHF-UHFFFAOYSA-N 0.000 description 1
- 238000013507 mapping Methods 0.000 description 1
- 239000011159 matrix material Substances 0.000 description 1
- 230000007246 mechanism Effects 0.000 description 1
- 230000003287 optical effect Effects 0.000 description 1
- 239000013307 optical fiber Substances 0.000 description 1
- 230000001105 regulatory effect Effects 0.000 description 1
- 238000011160 research Methods 0.000 description 1
- 239000004065 semiconductor Substances 0.000 description 1
- 230000009885 systemic effect Effects 0.000 description 1
- 230000035899 viability Effects 0.000 description 1
Classifications
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L41/00—Arrangements for maintenance, administration or management of data switching networks, e.g. of packet switching networks
- H04L41/04—Network management architectures or arrangements
- H04L41/046—Network management architectures or arrangements comprising network management agents or mobile agents therefor
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L67/00—Network arrangements or protocols for supporting network services or applications
- H04L67/01—Protocols
- H04L67/12—Protocols specially adapted for proprietary or special-purpose networking environments, e.g. medical networks, sensor networks, networks in vehicles or remote metering networks
- H04L67/125—Protocols specially adapted for proprietary or special-purpose networking environments, e.g. medical networks, sensor networks, networks in vehicles or remote metering networks involving control of end-device applications over a network
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L41/00—Arrangements for maintenance, administration or management of data switching networks, e.g. of packet switching networks
- H04L41/22—Arrangements for maintenance, administration or management of data switching networks, e.g. of packet switching networks comprising specially adapted graphical user interfaces [GUI]
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L63/00—Network architectures or network communication protocols for network security
- H04L63/12—Applying verification of the received information
- H04L63/123—Applying verification of the received information received data contents, e.g. message integrity
Landscapes
- Engineering & Computer Science (AREA)
- Computer Networks & Wireless Communication (AREA)
- Signal Processing (AREA)
- Computing Systems (AREA)
- General Health & Medical Sciences (AREA)
- Medical Informatics (AREA)
- Health & Medical Sciences (AREA)
- Financial Or Insurance-Related Operations Such As Payment And Settlement (AREA)
- Business, Economics & Management (AREA)
- Accounting & Taxation (AREA)
- Finance (AREA)
- Management, Administration, Business Operations System, And Electronic Commerce (AREA)
- Development Economics (AREA)
- Economics (AREA)
- Marketing (AREA)
- Strategic Management (AREA)
- Physics & Mathematics (AREA)
- General Business, Economics & Management (AREA)
- General Physics & Mathematics (AREA)
- Theoretical Computer Science (AREA)
- Technology Law (AREA)
Abstract
SISTEMA E MéTODO DE GERENCIAMENTO DE INFORMAçãO. Um sistema de gerenciamento da informação inclui um servidor de computador. O servidor de computador inclui um módulo de interface. O sistema de gerenciamento da informação também inclui uma pluralidade de processadores de cartão em comunicação com o servidor de computador através do módulo de interface. O servidor de computador é configurado para fazer interface com cada um da pluralidade de processadores de cartões através do módulo de interface. O servidor de computador é configurado para escolher um da pluralidade de processadores de cartões de acordo com um identificador singular associado ao produto do cartão para processar informação associada ao produto do cartão.
Description
SISTEMA E MÉTODO DE GERENCIAMENTO DE INFORMAÇÃO AVISO DE DIREITO DO AUTOR
Uma parte da revelação deste documento de patente contém material que está submetido à proteção por copyright. O proprietário do copyright não objeta à reprodução por fac-simile por qualquer um do documento de patente ou da revelação de patente, conforme ela aparece nos arquivos ou registros de patente do U.S. Patent and Trademark Office, mas afora isso reserva todos os direitos autorais sejam quais forem.
HISTÓRICO
CAMPO DA INVENÇÃO
A presente invenção relaciona-se a sistemas de gerenciamento da informação com base em computador. Mais particularmente, a presente invenção relaciona-se a um sistema e método para gerenciar a informação associada a produtos de cartão.
HISTÓRICO DA INVENÇÃO
Números crescentes de instituições do varejo e outras estão agora oferecendo valor equivalente a dinheiro na forma de cartões de presente. A indústria de cartões de presente experimentou um crescimento substancial pelos últimos anos. 0 total das vendas de cartões de presente atingiu aproximadamente 20 bilhões de dólares em 2004. A gama de cartões de presente oferecida pelas instituições tornou-se expansiva, incluindo cartões de varejistas, de supermercados, de drogarias, de postos de combustíveis, de restaurantes, de lojas de conveniências, e de salões de cabeleireiros, para citar apenas alguns.
A maioria dos cartões de presentes está associada a determinado varejista ou comerciante. Em outras palavras, qualquer valor armazenado no cartão de presente só pode ser utilizado para adquirir mercadorias e serviços no varejista ou comerciante particular de quem o cartão de presente foi adquirido, de modo que o comerciante pode ganhar o benefício de uma venda garantida. Esses cartões de presente proprietários podem ser referidos como cartões de "sistema fechado". Os comerciantes podem cobrir o custo de seus programas de cartão de presente da margem em seus produtos, que pode, por exemplo, ser de 15 dólares ou mais em uma venda de 50 dólares.
No entanto, uma tendência crescente na indústria é para instituições financeiras oferecerem cartões de presente de marca pré-pagos ou de "sistema aberto". Cartões de sistema aberto são emitidos por uma instituição financeira regulamentada pelo governo federal e portam uma marca de rede importante, como, por exemplo, MasterCard™, Visa™, Discover™ e assemelhados, e inclui redes de débito como STAR™, Pulse™, NYCE™, e outros. Por exemplo, o cartão de presente pré-pago da VISA™ pode ser utilizado em qualquer varejista ou comerciante que aceite cartões de débito VISA™, o que inclui milhões de localidades no mundo inteiro, bem como a Internet e comerciantes de pedidos pelo Correio e de pedidos por' telefone. Esses cartões de presente pré-pagos podem ser utilizados para incentivos empresariais, abatimentos e promoções, e podem ser vendidos em filiais de uma instituição financeira, através do sítio da Web do consumidor da instituição financeira, ou distribuído através de clientes empresariais. 0 mercado para cartões de presente emitidos pelo banco está previsto para crescer de 3 bilhões de dólares em 2003 para aproximadamente 31 bilhões de dólares em 2007.
Os cartões de presente de marca no sistema aberto diferem dos cartões de presente "da loja" proprietários em vários aspectos. Por exemplo, os cartões de presente emitidos pelo banco podem ser utilizados em qualquer comerciante. Exceto por uma pequena quantidade de intercâmbio, o banco ou outra instituição financeira não tira proveito da venda dos produtos/serviços adquiridos com o cartão ou partilham dos lucros da venda. Em vez disso, taxas administrativas mensais podem ser utilizadas para manter a viabilidade econômica do produto de cartão de presente emitido pelo banco.
Os cartões de presente de marca no sistema aberto partilham muitos recursos básicos. Por exemplo, esses cartões são garantidos pela rede e pela instituição financeira. Os recursos são mantidos e controlados pela instituição financeira. Os cartões podem ser utilizados em qualquer lugar onde marcas de rede são aceitas. Cartões podem ser substituídos se forem perdidos, roubados, ou quando expirados. Além disso, os consumidores podem ganhar proteção contra atividades fraudulentas.
No entanto, os métodos convencionais de adquirir esses cartões de presente têm sido relativamente complexos. Por exemplo, consumidores podem esperar por pontos períodos de tempo em um ponto de venda enquanto o atendente ou agente de vendas processa a compra do cartão de presente. Sítios de compra de cartão de presente online pouco fazem para aliviar a complexidade de comprar cartões de presente. Por exemplo, muitos sítios da Web online experimentam dificuldade em designar usuários, apresentam telas múltiplas e complexas através das quais os usuários precisam navegar para comprar cartões de presente, e outras dificuldades assemelhadas.
Adicionalmente, como cada um desses cartões de presente é associado a uma instituição financeira em particular, consumidores são forçados a interagir com muitas entidades diferentes para comprar e gerenciar esses cartões de presente. Por exemplo, se um consumidor ou outro usuário possui vários cartões de presente, cada um emitido por uma instituição financeira diferente, o usuário precisa navegar até e acessar um sítio da Web diferente para cada cartão de presente de cada instituição financeira para assinar e administrar cada cartão em separado.
Portanto, há necessidade de um sistema que possa reduzir a complexidade e enxugar o processo de gerenciar e de administrar cartões de presente e outros produtos de cartão não recarregáveis e recarregáveis através de muitas instituições financeiras.
SINOPSE DA INVENÇÃO
São revelados um sistema para gerenciar a informação associada a produtos de cartão e um método para gerenciar a informação do produto de cartão através de múltiplos processadores de cartão. De acordo com versões exemplares da presente invenção, de acordo com um primeiro aspecto da presente invenção, um sistema de gerenciamento da informação inclui um servidor de computador. O servidor de computador inclui um módulo de interface. O sistema de gerenciamento da informação inclui uma pluralidade de processadores de cartão em comunicação com o servidor de computador através do módulo de interface. 0 servidor de computador é configurado para fazer interface com cada um da pluralidade de processadores de cartão através do módulo de interface. O servidor do computador é configurado para escolher um da pluralidade de processadores de cartão de acordo com um identificador singular associado a um produto de cartão para processar a informação associada ao produto de cartão.
De acordo com o primeiro aspecto, o módulo de interface pode ser configurado para transformar mensagens para comunicação a um processador de cartão respectivo em um formato utilizado pelo processador de cartão respectivo. Mensagens para os processadores de cartão podem incluir uma consulta que compreende um endereço de rede de computador de um arquivo. A criptografação do endereço de rede de computador pode ser apensada ao final da consulta. O módulo de interface pode ser configurado para detectar adulterações do endereço de rede de computador ao comparar o endereço de rede de computador e uma descriptografação do endereço de rede de computador criptografado. Alternativamente, o módulo de interface pode ser configurado para detectar adulterações do endereço de rede de computador ao comparar o endereço de rede de computador criptografado e uma re-criptografação do endereço de rede de computador. O módulo de interface pode ser configurado para receber informação associada a produtos de cartão de cada um dos processadores de cartão. A informação de cada um dos processadores de cartão pode ser normalizada para transformar a informação em um formato uniforme utilizado pelo servidor de computador. A informação transformada pode ser validada para assegurar a precisão da informação.
De acordo com o primeiro aspecto, o sistema de gerenciamento da informação pode incluir uma base de dados em comunicação com o servidor de computador. O módulo de base de dados pode ser configurado para armazenar informação associada a produtos de cartão. O sistema de gerenciamento da informação pode incluir um módulo de gerenciamento em comunicação com a base de dados. O módulo de gerenciamento pode ser configurado para gerenciar o sistema de gerenciamento da informação. Os processadores de cartão podem ser configurados para associar números de identificação de banco correspondentes (BINs) aos produtos de cartão. O servidor de computador pode ser configurado para alocar números de cartão correspondentes a cada BIN para os produtos de cartão. O servidor de computador pode ser configurado para exibir um resumo de números de cartão para cada BIN através da interface gráfica de usuário. Cada produto de cartão pode compreender um número de cartão. O número de cartão pode compreender uma primeira parte de dígitos e uma segunda parte de dígitos. A primeira parte de dígitos pode compreender um BIN. Os processadores de cartão podem ser configurados para associar BINs aos produtos de cartão. O servidor de computador pode ser configurado para alocar números de cartão a substancialmente toda a segunda parte de dígitos para cada BIN.
De acordo com um segundo aspecto da presente invenção, um sistema de gerenciamento de produto de cartão inclui um módulo de portal de agente. O sistema de gerenciamento de produto de cartão inclui uma pluralidade de processadores de cartão em comunicação com o módulo de portal de agente. O módulo de portal de agente é configurado para escolher uma da pluralidade de processadores de cartão. O módulo de portal de agente é configurado para escolher um da pluralidade de processadores de cartão de acordo com um identificador único associado ao produto de cartão para processar informação associada ao produto de cartão.
De acordo com o segundo aspecto, o módulo de portal de agente pode ser configurado para gerenciar a informação associada a produtos de cartão para a pluralidade de processadores de cartão. O módulo de portal de agente pode incluir um módulo servidor de aplicação do cliente. 0 módulo servidor de aplicação do cliente pode ser configurado para transformar mensagens para comunicação a um processador de cartão respectivo dentro de um formato utilizado pelo processador de cartão respectivo. Mensagens aos processadores de cartão podem incluir uma consulta que compreende um endereço de rede de computador de um arquivo. A criptografia do endereço de rede de computador pode ser apensada ao final da consulta. 0 módulo servidor de aplicação do cliente pode ser configurado para detectar adulterações do endereço de rede do computador ao comparar o endereço de rede do computador e uma descriptografação do endereço de rede de computador criptografado. Alternativamente, o módulo servidor de aplicação do cliente pode ser configurado para detectar adulterações do endereço de rede do computador ao comparar o endereço de rede de computador criptografado e a re-criptografação do endereço de rede do computador. Por exemplo, a criptografação do endereço de rede de computador pode compreender uma função aleatória (hash) criptográfica. O módulo servidor de aplicação do cliente pôde ser configurado para receber informação associada a produtos de cartão de cada ura dos processadores de cartão. A informação de cada um dos processadores de cartão pode ser normalizada para transformar a informação em um formato uniforme utilizado pelo módulo de porta de agente. A informação de cada processador de cartão pode compreender uma pluralidade de relatórios. A pluralidade de relatórios pode compreender pelo menos um de um relatório geral, um relatório lançado e um relatório de autorização. A informação transformada pode ser validada para assegurar a precisão da informação.
De acordo com o segundo aspecto, o módulo servidor de aplicação do cliente pode ser configurado para gerar relatórios para a informação associada a produtos de cartão. Cada relatório pode ser preenchido com informação de acordo com a identificação do usuário. O sistema de gerenciamento de produto de cartão pode compreender um módulo de base de dados em comunicação com o módulo servidor de aplicação do cliente. O módulo de base de dados pode ser configurado para armazenar informação associada a produtos de cartão. 0 sistema de gerenciamento de produto de cartão pode incluir um módulo servidor de aplicação de gerenciamento em comunicação com o módulo de base de dados. O módulo servidor de aplicação de gerenciamento pode ser configurado para gerenciar o sistema de gerenciamento de produto de cartão. O módulo de portal de agente pode ser configurado para permitir o acesso pelos usuários para gerenciar a informação associada aos produtos de cartão. O módulo de portal de agente pode incluir um módulo de interface gráfica do usuário. O módulo de interface gráfica do usuário pode ser configurado para exibir uma interface gráfica do usuário através da qual os usuários interagem com o sistema de gerenciamento de produto de cartão.
De acordo com o segundo aspecto, o usuário pode ter acesso concedido ao sistema de gerenciamento de produto de cartão através da interface gráfica do usuário utilizando uma senha e um endereço de rede de computador associada do usuário. Produtos podem ser apresentados ao usuário através da interface gráfica do usuário de acordo com pelo menos um de uma identificação do usuário e uma associação com uma instituição financeira. O tema da interface gráfica do usuário pode ser associada a cada processador de cartão. Cada processador de cartão pode ser apresentado ao tema associado ao processador de cartão quando da interação com o sistema de gerenciamento de produto de cartão através da interface gráfica do usuário. Os processadores de cartão podem ser configurados para associar BINS correspondentes aos produtos de cartão. O módulo de portal de agente pode ser configurado para alocar números de cartão correspondentes a cada BIN para os produtos de cartão. O módulo de portal de agente pode ser configurado para exibir um resumo dos números de cartão para cada BIN através da interface gráfica do usuário.
De acordo com o segundo aspecto, o identificador singular pode compreender um número de identificação de banco (BIN) . Cada produto de cartão pode compreender um número de produto de cartão. O número de produto de cartão pode compreender uma primeira parte de dígitos e uma segunda parte de dígitos. A primeira parte de dígitos pode compreender um BIN. Os processadores de cartão podem ser configurados para associar BINs aos produtos de cartão. 0 módulo de portal de agente pode ser configurado para alocar números de cartão a substancialmente toda a segunda parte de dígitos para cada BIN. O produto de cartão pode compreender um cartão de presente. O cartão de presente pode ser emitido por uma instituição financeira. 0 produto de cartão pode compreender um cartão de débito. Ó produto de cartão pode compreender um cartão de conta de economia de saúde (HSA). O produto de cartão pode compreender um cartão de conta de gastos flexíveis (FSA). 0 produto de cartão pode compreender um cartão de folha de pagamento recarregável. Pelo menos um da pluralidade de processadores de cartão pode compreender um banco ou assemelhado.
De acordo com um terceiro aspecto da presente invenção, um sistema para processar produtos de cartão inclui uma pluralidade de produtos de cartão. Cada produto de cartão compreende um número de produto de cartão. 0 número de produto de cartão compreende uma primeira parte de dígitos e uma segunda parte de dígitos. A primeira parte de dígitos compreende um número de identificação de banco (BIN) . Cada BIN é designado a um processador de cartão. 0 sistema inclui um não processador. 0 não processador é configurado para gerenciar informação associada à pluralidade de produtos de cartão. 0 não processador é configurado para designar valores a substancialmente toda a segunda parte de dígitos de cada produto de cartão.
De acordo com o terceiro aspecto, os valores designados a substancialmente toda a segunda parte de dígitos de cada produto de cartão pode compreender um número de cartão. 0 não processador pode ser configurado para alocar números de cartão para cada BIN. Números de cartão podem ser alocados seqüencialmente para cada BIN. Alternativamente, números de cartão podem ser alocados aleatoriamente para cada BIN. Os valores associados a substancialmente toda a segunda parte de dígitos de cada produto de cartão pode corresponder a usuários separados.
De acordo com um quarto aspecto da presente invenção, um método de gerenciar informação de produto de cartão inclui as etapas de: a) fazer interface com cada um da pluralidade de processadores de cartão; e b) selecionar um da pluralidade de processadores de cartão de acordo com um identificador singular associado a um produto de cartão para processar a informação associada ao produto de cartão.
De acordo com o quarto aspecto, o método pode incluir as etapas de: c) gerenciar a informação associada a produtos de cartão para a pluralidade de processadores de cartão; e d) transformar mensagens para a comunicação a um processador de cartão respectivo dentro de um formato utilizado pelo processador de cartão respectivo. Mensagens aos processadores de cartão podeni incluir uma consulta que compreende um endereço de rede de computador de um arquivo. 0 método pode incluir as etapas de: e) criptografar o endereço de rede de computador; f) apensar o endereço de rede de computador criptografado ao final da consulta; e g) detectar adulterações com o endereço de rede de computador ao comparar o endereço de rede de computador e uma descriptografia do endereço de rede de computador criptografado. Alternativamente, a etapa (g) pode compreender a etapa de: g) detectar a adulteração do endereço de rede de computador ao comparar o endereço de rede de computador criptografado e uma re-criptografação do endereço de rede de computador. Por exemplo, de acordo com uma versão exemplar do quarto aspecto, a etapa (e) pode ser efetuada utilizando uma função aleatória (hash) criptográfica. O método pode incluir as etapas de: h) receber informação associada aos produtos de cartão de cada um dos processadores de cartão; e i) normalizar a informação de cada um dos processadores de cartão para transformar a informação em um formato uniforme. A informação de cada processador de cartão pode compreender uma pluralidade de relatórios. A pluralidade de relatórios pode compreender pelo menos um de um relatório geral, um relatório lançado e um relatório de autorização.
De acordo com o quarto aspecto, o método pode incluir as etapas de: j) validar a informação transformada para assegurar a precisão da informação; k) gerar relatórios para a informação associada ao produto de cartão; 1) preencher cada relatório com informação de acordo com a identificação do usuário; m) armazenar a informação associada a produtos de cartão; e n) fornecer acesso aos usuários para gerenciar a informação associada a produtos de cartão; o) exibir uma interface gráfica de usuário através da qual os usuários acessam a informação associada a produtos de cartão; p) conceder acesso ao usuário através da interface gráfica do usuário utilizando uma senha e um endereço de rede de computador associado do usuário; e q) apresentar produtos ao usuário através da interface gráfica do usuário de acordo com a pelo menos uma de identificação do usuário e uma associação com uma instituição financeira.
O tema da interface gráfica de usuário pode ser associada a cada processador de cartão. 0 método pode incluir a etapa de: r) apresentar cada processador de cartão com o tema associado ao processador de cartão quando da interação através da interface gráfica do usuário. Os processadores de cartão podem ser configurados para associar números de identificação de banco correspondentes (BINs) aos produtos de cartão. O método pode incluir a etapa de: s) alocar números de cartão correspondentes a cada BIN para os produtos de cartão. De acordo com o quarto aspecto, o método pode incluir a etapa de: t) exibir um resumo dos números de cartão para cada BIN.
De acordo com o quarto aspecto, o identificador singular pode compreender um número de identificação de banco (BIN) . Cada produto de cartão pode compreender um número de produto de cartão. 0 número de produto de cartão pode compreender uma primeira parte de dígitos e uma segunda parte de dígitos. A primeira parte de dígitos pode compreender um BIN. Os processadores de cartão podem ser configurados a associar BINs aos produtos de cartão. 0 método pode incluir a etapa de: v) alocar números de cartão a substancialmente toda a segunda parte de dígitos para cada BIN. O produto de cartão pode compreender um cartão de presente. O cartão de presente pode ser emitido por uma instituição financeira. O produto de cartão pode compreender um cartão de débito. O produto de cartão pode compreender um cartão de conta de economia de saúde (HSA). O produto de cartão pode compreender um cartão conta de gastos flexíveis (FSA). O produto de cartão pode compreender um cartão de folha de pagamento recarregável. Pelo menos um da pluralidade de processadores de cartão compreende um banco.
De acordo com um quinto aspecto da presente invenção, um método de processar produtos de cartão inclui as etapas de: a) associar um número de identificação de banco (BIN) a cada um da pluralidade de produtos de cartão por um processador de cartão, em que cada produto de cartão compreende um número de produto de cartão, em que o número de produto de cartão compreende uma primeira parte de dígitos e uma segunda parte de dígitos, e em que a primeira parte dos dígitos compreende o BIN; e b) designar valores a substancialmente toda a segunda parte de dígitos de cada produto de cartão por um não processador, em que o não processador é configurado para gerenciar a informação associada à pluralidade de produtos de cartão.
De acordo com o quinto aspecto, os valores designados a substancialmente toda a segunda parte dos dígitos de cada produto de cartão pode compreender um número de cartão. O método pode incluir a etapa de: c) alocar números de cartão para cada BIN pelo não processador. A etapa (c) pode compreender a etapa de: d) alocar seqüencialmente números de cartão para cada BIN. Alternativamente, a etapa (c) pode compreender a etapa de: e) alocar aleatoriamente números de cartão para cada BIN. Os valores designados a substancialmente toda a segunda parte de dígitos de cada produto de cartão podem corresponder a usuários separados.
De acordo com um sexto aspecto da presente invenção, um sistema para gerenciar informação de produto de cartão inclui meio para fazer interface com cada um de uma pluralidade de processadores de cartão. O sistema inclui meio para selecionar um da pluralidade de processadores de cartão de acordo com um identificador singular associado a um produto de cartão para processar informação associada ao produto de cartão.
De acordo com o sexto aspecto, o sistema pode incluir meio para gerenciar a informação associada a produtos de cartão para a pluralidade de processadores de cartão. 0 sistema pode incluir meio para transformar mensagens para comunicação a um processador de cartão respectivo em um formato utilizado pelo processador de cartão respectivo. Mensagens para os processadores de cartão incluem uma consulta que compreende um endereço de rede de computador de um arquivo. O sistema pode incluir meio para criptografar o endereço de rede de computador. O sistema pode incluir meio para apensar o endereço de rede de computador criptografado ao final da consulta. O sistema pode incluir meio para detectar adulterações com o endereço de rede de computador ao comparar o endereço de rede de computador e uma descriptografação do endereço de rede de computador criptografado. Alternativamente, o sistema pode incluir meio para detectar a adulteração do endereço de rede de computador ao comparar o endereço de rede de computador criptografado e uma re-criptografação do endereço de rede de computador. Por exemplo, o meio de criptografar pode utilizar uma função aleatória (hash) criptográfica para criptografar o endereço de rede de computador.
De acordo com o sexto aspecto, o sistema pode incluir meio para receber informação associada a produtos de cartão de cada um dos processadores de cartão. O sistema pode incluir meio para normalizar a informação de cada um dos processadores de cartão para transformar a informação em um formato uniforme. A informação de cada processador de cartão pode compreender uma pluralidade de relatórios. A pluralidade de relatórios pode compreender pelo menos um de um relatório geral, um relatório lançado e um relatório de autorização. O sistema pode incluir meio para validar a informação transformada para assegurar a precisão da informação. O sistema pode incluir meio para gerar relatórios para informação associada ao produto de cartão.
O sistema pode incluir meio para preencher cada relatório com informação de acordo com a identificação do usuário. O sistema pode incluir meio para armazenar a informação associada a produtos de cartão. O sistema pode incluir meio para fornecer acesso a usuários para gerenciar a informação associada a produtos de cartão. O sistema pode incluir meio para exibir uma interface gráfica de usuário através da qual os usuários acessam a informação associada a produtos de cartão.
De acordo com o sexto aspecto, o sistema pode incluir meio para conceder acesso ao usuário através da interface gráfica do usuário utilizando uma senha e um endereço de rede de computador associado do usuário. 0 sistema pode incluir meio para apresentar produtos ao usuário através da interface gráfica do usuário de acordo com pelo menos um de identificação do usuário e associação com uma instituição financeira. O tema da interface gráfica do usuário está associado a cada processador de cartão. O sistema pode incluir meio para apresentar cada processador de cartão com o tema associado ao processador de cartão quando da interação através da interface gráfica do usuário. Os processadores de cartão podem ser configurados para associar números de identificação de banco correspondentes (BINs) aos produtos de cartão. O sistema pode incluir meio para alocar números de cartão correspondentes a cada BIN para os produtos de cartão. Ô sistema pode incluir meio para exibir um resumo dos números de cartão para cada BIN.
De acordo com o sexto aspecto, o identificador singular pode compreender um número de identificação de banco (BIN). Cada produto de cartão pode compreender um número de produto de cartão. O número de produto de cartão pode compreender uma primeira parte de dígitos e uma segunda parte de dígitos. A primeira parte de dígitos pode compreender um BIN. Os processadores de cartão podem ser configurados para associar BINs aos produtos de cartão. O sistema pode incluir meio para alocar números de cartão a substancialmente toda a segunda parte dê dígitos para cada BIN. O produto de cartão pode compreender um cartão de presente. O cartão de presente pode ser emitido por uma instituição financeira. O produto de cartão pode compreender um cartão de débito. O produto de cartão pode compreender um cartao de conta de economia de saúde (HSA). O produto de cartão pode compreender um cartão de conta de gastos flexíveis (FSA). O produto de cartão pode compreender um cartão de folha de pagamento recarregável.
Pelo menos um da pluralidade de processadores de cartão compreende um banco.
De acordo com um sétimo aspecto da presente invenção, um sistema para processar produtos de cartão inclui meio para associar um número de identificação de banco (BIN) a cada um da pluralidade de produtos de cartão por um processador de cartão. Cada produto de cartão compreende um número de produto de cartão. 0 número de produto de cartão compreende uma primeira parte de dígitos e uma segunda parte de dígitos. A primeira parte de dígitos compreende o BIN. O sistema inclui meio para designar valores a substancialmente toda a segunda parte de dígitos de cada produto de cartão por um não processador. 0 não processador é configurado para gerenciar a informação associada à pluralidade de produtos de cartão.
De acordo com o sétimo aspecto, os valores designados a substancialmente toda a segunda parte de dígitos de cada produto de cartão pode compreender um número de cartão. 0 sistema pode incluir meio para alocar números de cartão para cada BIN pelo não processador. 0 sistema pode incluir meio para alocar seqüencialmente números de cartão para cada BIN. Alternativamente, o sistema pode incluir meio para alocar aleatoriamente números de cartão para cada BIN. Os valores designados a substancialmente toda a segunda parte de dígitos de cada produto de cartão pode corresponder a usuários separados.
De acordo com um oitavo aspecto da presente invenção, um meio lido por computador contém um programa de computador para gerenciar a informação de produto de cartão. 0 programa de computador efetua as etapas de: a) fazer interface com cada um de uma pluralidade de processadores de cartão; e b) selecionar um da pluralidade de processadores de cartão de acordo com um identificador singular associado a um produto de cartão para processar a informação associada ao produto de cartão.
De acordo com o oitavo aspecto, o programa de computador pode efetuar as etapas de: c) gerenciar a informação associada a produtos de cartão para a pluralidade de processadores de cartão; e d) transformar mensagens para comunicação a um processador de cartão respectivo dentro de um formato utilizado pelo processador de cartão respectivo. Mensagens aos processadores de cartão podem incluir uma consulta que compreende o endereço de rede de computador de um arquivo. O programa de computador pode efetuar as etapas de: e) criptògrafar o endereço de rede de computador; f) apensar o endereço de rede de computador criptografado ao final da consulta; e g) detectar adulteração com o endereço de rede de computador ao comparar o endereço de rede de computador e uma descriptografação do endereço de rede de computador criptografado. Alternativamente, para a etapa (g), o programa de computador pode efetuar a etapa de: g) detectar a adulteração do endereço de rede de computador ao comparar o endereço de rede de computador criptografado e uma re- criptografação do endereço de rede de computador. Por exemplo, a etapa (e) pode ser efetuada pelo programa de computador utilizando uma função aleatória (hash) criptográfica. O programa de computador pode efetuar as etapas de: h) receber informação associada a produtos de cartão de cada um dos processadores de cartão; e i) normalizar a informação de cada um dos processadores de cartão para transformar a informação em um formato uniforme. A informação de cada processador de cartão pode compreender uma pluralidade de relatórios. A pluralidade de relatórios pode compreender pelo menos um de um relatório geral, um relatório lançado e um relatório de autorização. De acordo com o oitavo aspecto, o programa de computador pode efetuar as etapas de: j) validar a informação transformada para assegurar a precisão da informação; k) gerar relatórios para a informação associada ao produto de cartão; 1) preencher cada relatório com informação de acordo com a identificação do usuário; m) armazenar a informação associada a produtos de cartão; n) fornecer acesso aos usuários para gerenciar a informação associada a produtos de cartão; o) gerar uma interface gráfica do usuário através da qual usuários acessam a informação associada a produtos de cartão; p) conceder acesso ao usuário através da interface gráfica do usuário utilizando uma senha e um endereço de rede de computador associada do usuário; e q) gerar uma apresentação dos produtos ao usuário através da interface gráfica do usuário de acordo com pelo menos um de uma identificação do usuário e uma associação com uma instituição financeira. 0 tema da interface gráfica do usuário pode ser associado a cada processador de cartão. 0 programa de computador pode efetuar a etapa de: r) gerar o tema associado ao processador de cartão para cada processador de cartão quando da interação através da interface gráfica do usuário. Os processadores de cartão podem ser configurados para associar números de identificação de banco correspondentes (BINs) aos produtos de cartão. 0 programa de computador pode efetuar as etapas de: s) alocar números de cartão correspondentes a cada BIN para os produtos de cartão, e t) gerar um resumo dos números de cartão para cada BIN.
De acordo com o oitavo aspecto, o identificador singular pode compreender um número de identificação de banco (BIN). Cada produto de cartão pode compreender um número de produto de cartão. O número de produto de cartão pode compreender uma primeira parte de dígitos e uma segunda parte de dígitos. A primeira parte de dígitos pode compreender um BIN. Os processadores de cartão podem ser configurados a associar BINs aos produtos de cartão. O programa de computador pode efetuar a etapa de: v) alocar números de cartão a substancialmente toda a segunda parte de dígitos para cada BIN. O produto de cartão pode compreender um cartão de presente. O cartão de presente pode ser emitido por uma instituição financeira. O produto de cartão pode compreender um cartão de débito. O produto de cartão pode compreender um cartão de conta de economia de saúde (HSA). O produto de cartão pode compreender um cartão de conta de gastos flexíveis (FSA). O produto de cartão pode compreender um cartão de folha de pagamento recarregável. Pelo menos um da pluralidade de processadores de cartão pode compreender um banco.
DESCRIÇÃO SUCINTA DOS DESENHOS
Outros objetos e vantagens da presente invenção tornar-se-ão aparentes para aqueles habilitados na tecnologia quando da leitura da descrição detalhada seguinte das versões preferidas, em conjunto com os desenhos acompanhantes, em que números de referência iguais foram utilizados para designar elementos iguais, e em que:
A Figura 1 é um diagrama que ilustra um sistema de gerenciamento de produto de cartão, de acordo com uma versão exemplar da presente invenção.
A Figura 2 é uma especificação de relatório para um relatório geral ou não financeiro, de acordo com uma versão exemplar da presente invenção.
A Figura 3 é uma especificação de relatório para um relatório lançado, de acordo com uma versão exemplar da presente invenção.
A Figura 4 é uma especificação de relatório para um relatório de autorização, de acordo com uma versão exemplar da presente invenção.
A Figura 5 é um exemplo de uma interface gráfica do usuário para visualizar ordens através do sistema de gerenciamento de produto de cartão, de acordo com uma versão exemplar da presente invenção.
A Figura 6 é um diagrama que ilustra o fluxo de transação para um cartão de presente emitido por um processador de cartão, de acordo com uma versão exemplar da presente invenção.
A Figura 7 é uma ilustração de uma página de visão geral para o módulo servidor de aplicação de gerenciamento, de acordo com uma versão exemplar da presente invenção.
As Figuras 8A, 8B e 8 C ilustram uma página de processadores, uma página de clientes e uma página de programas, respectivamente, de acordo com uma versão exemplar da presente invenção.
A Figura 9 ilustra uma página de detalhe dé cliente, de acordo com uma versão exemplar da presente invenção.
A Figura 10 ilustra uma página de detalhes de programa, de acordo com uma versão exemplar da presente invenção.
A Figura 11 uma página de contratos de clientes, de acordo com uma versão exemplar da presente invenção. A Figura 12 ilustra uma página de qualidade do cliente, de acordo com uma versão exemplar da presente invenção.
A Figura 13 ilustra uma página de planos de projeto de programa, de acordo com uma versão exemplar da presente invenção.
A Figura 14 ilustra uma página de fundos de programa, de acordo com uma versão exemplar da presente invenção.
A Figura 15 ilustra uma página de atributos de programa, de acordo com uma versão exemplar da presente invenção.
A Figura 16 ilustra uma página de relatório de cartão de presente, de acordo com uma versão exemplar da presente invenção.
A Figura 17 ilustra uma página de relatório de fila de trabalho, de acordo com uma versão exemplar da presente invenção.
A Figura 18 ilustra uma página de relatório resumo de comissão a pagar, de acordo com uma versão exemplar da presente invenção.
A Figura 19 ilustra uma página de arquivos de relatório, de acordo com uma versão exemplar da presente invenção.
A Figura 20 ilustra uma página de relatório financeiro, de acordo com uma versão exemplar da presente invenção.
A Figura 21 ilustra uma página de relatório de reconciliação de conta, de acordo com uma versão exemplar da presente invenção.
A Figura 22 ilustra um balancete gerado pelo sistema de gerenciamento de produto de cartão, de acordo com uma versão exemplar da presente invenção.
A Figura 23 ilustra uma página de relatório de definição de balancete, de acordo com uma versão exemplar da presente invenção.
A Figura 24 ilustra uma página de relatório de exceção, de acordo com uma versão exemplar da presente invenção.
As Figuras 25A e 25B ilustram páginas de relatório de detalhe de exceção, de acordo com uma versão exemplar da presente invenção.
A Figura 26 ilustra uma página de relatórios financeiros, de acordo com uma versão exemplar da presente invenção.
As Figuras 27A e 27B ilustram páginas de relatório financeiro, de acordo com uma versão exemplar da presente invenção.
A Figura 2 8 ilustra uma página de resumo de número de cartão, de acordo com uma versão exemplar da presente invenção.
A Figura 29 é um fluxograma que ilustra etapas para gerenciar a informação de produto de cartão, de acordo com uma versão exemplar da presente invenção.
A Figura 30 é um fluxograma que ilustra etapas para detectar adulteração na informação comunicada a um processador de cartão, de acordo com uma versão exemplar da presente invenção.
A Figura 31 é um fluxograma que ilustra etapas para processar produtos de cartão, de acordo com uma versão exemplar da presente invenção. DESCRIÇÃO DETALHADA DAS VERSÕES PREFERIDAS
Versões exemplares da presente invenção são dirigidas a um sistema para gerenciar a informação associada a produtos de cartão e a um método para gerenciar a informação de produto de cartão através de múltiplos processadores de cartão. De acordo com versões exemplares, um único portal de agente de banco fornece uma interface para múltiplos processadores de cartão para suportar a administração e o gerenciamento de cartões ou de outros produtos de cartão emitidos por diferentes entidades, como, por exemplo, instituições financeiras (por exemplo, bancos) e assemelhados. O portal de agente de banco pode então escolher um dos processadores de cartão para processar informação associada aos produtos de cartão utilizando informação de identificação singular associada a cada produto de cartão. Os produtos de cartão podem incluir, por exemplo, cartões de presentes (por exemplo, cartões de presente emitidos por bancos), cartões de débito, e outros produtos de cartão não recarregáveis, bem como produtos de cartão recarregáveis, como, por exemplo, cartões de contas de economias de saúde (HSA), cartões de contas de gastos flexíveis (FSA), cartões de folha de pagamento recarregáveis, e assemelhados. Ao fornecer uma única interface para múltiplos processadores de cartão, o usuário pode eficaz e facilmente gerenciar qualquer uma ou a totalidade desses produtos de cartão e outros tipos de transações financeiras semelhantes de um único sítio, independentemente da entidade que emitiu o cartão.
De acordo com versões exemplares, o portal de agente de banco fornece uma camada de abstração entre o usuário e os processadores de cartão. Em outras palavras, a presente invenção lida com qualquer uma e todas as inconsistências e diferenças em interfaces, em comunicação, em formatos de dados e assemelhados entre os vários processadores de cartão, de modo que o usuário precisa apenas interagir com uma única interface unificada. Assim, o usuário pode comprar, gerenciar, e conduzir funções administrativas para qualquer número de produtos de cartão de qualquer número de instituições financeiras sem a necessidade de conduzir negócios separadamente com cada instituição (por exemplo, através do sitio da Web de cada instituição financeira). Por exemplo, o usuário pode gerar e visualizar relatórios resumidos de informação financeira associada aos produtos de cartão emitidos de diferentes instituições financeiras.
De acordo com uma versão exemplar adicional da presente invenção, o sistema de gerenciamento de produto de cartão pode ser utilizado para alocar números de cartão a produtos de cartão emitidos pelas instituições financeiras. Cada produto de cartão inclui um número de produto de cartão que identifica singularmente o cartão, por exemplo, um número de dezesseis dígitos ou assemelhados. Por exemplo, os primeiros seis dígitos do número de produto de cartão pode ser um número de identificação de banco (BIN) designado pela instituição financeira ao processador de cartão. Para a ilustração de cartões de presentes emitidos por banco, os dígitos restantes (por exemplo, dez) são utilizados convencionalmente para designar uma extensão BIN (por exemplo, seis dígitos), o número de cartão (por exemplo, três dígitos) , e um bit de verificação (por exemplo, um dígito). Os valores desses dígitos restantes também são designados convencionalmente pela instituição financeira. No entanto, de acordo com a versão exemplar adicional, o sistema de gerenciamento de produto de cartão pode designar números de cartão para os produtos de cartão ao utilizar a inteireza dos dígitos restantes (por exemplo, todos os dez dígitos restantes) para alocar números de cartão para um BIN particular. O usuário autorizado poderá então visualizar, por exemplo, um resumo de distribuição dos números de cartões disponíveis para cada BIN.
Estes e outros aspectos da presente invenção serão descritos agora em maior detalhe. A Figura 1 é um diagrama que ilustra um sistema de gerenciamento de produto de cartão 100, de acordo com uma versão exemplar da presente invenção. O sistema de gerenciamento de produto de cartão 100 (também aqui referido simplesmente como o "sistema 100") inclui um módulo de portal de agente 105. Uma pluralidade de processadores de cartão 110 (processador de cartão 1, processador de cartão 2, processador de cartão 3, . . . , processador de cartão N, em que N pode ser qualquer número adequado) estão em comunicação com o módulo de portal de agente 105. Cada processador de cartão 110 pode comunicar com o módulo de portal de agente 105 utilizando qualquer forma adequada de meio de comunicação e de protocolo, como, por exemplo, uma conexão de rede local ou remota (por exemplo, através de uma intranet ou da Internet ou assemelhados) , uma conexão direta (por exemplo, um cabo, como a conexão RS-232), ou qualquer outra conexão direta ou em rede, de fiação ou sem fio, adequada.
De acordo com versões exemplares, o módulo de portal de agente 105 é configurado para fazer interface com cada um dos processadores de cartão110. Cada processador de cartão110 pode comunicar com o módulo de portal de agente 105 de uma maneira que pode ser diferente do que qualquer um ou a totalidade dos demais processadores de cartão 110.
Em outras palavras, cada processador de cartão 110 pode comunicar com o módulo de portal de agente 105 utilizando uma tecnologia de comunicação, protocolo pacote de protocolo, meio e assemelhados, diferente. Para fins de ilustração e não de limitação, o primeiro e o terceiro processadores de cartão 110 podem utilizar SOAP (Simple Object Access Protocol - Protocolo de Acesso a Objeto Simples) para comunicar com o módulo de portal de agente 105, enquanto o segundo e o Nesimo processadores de cartão 110 podem utilizar XML-RPC para comunicar com o módulo de portal de agente 105, embora qualquer protocolo de comunicação adequado possa ser utilizado pelos processadores de cartão 110. O módulo de portal de agente 105 é configurado para encapsular a interface para cada processador de cartão 110 de modo que o módulo portal de agente 105 pode comunicar com cada processador de cartão 110 utilizando o protocolo de comunicação utilizado e compreendido pelo processador de cartão respectivo110. Continuando com a presénte ilustração, para comunicar com o primeiro e o terceiro processadores de cartão110, o módulo de portal de agente 105 utilizaria SOAP, enquanto XML-RPC seria utilizado para comunicar com o segundo e o Nesimo processadores de cartão 110. O módulo de portal de agente 105 pode suportar qualquer protocolo de comunicação adequado. À medida que processadores de cartão adicionais 110 são colocados em comunicação com o módulo de portal de agente 105, os parâmetros de comunicação (protocolo, formato de mensagem, e assemelhados) para cada novo processador de cartão 110 pode ser fornecido de modo que o módulo de portal de agente 105 pode ser configurado para comunicar com cada novo processador de cartão 110 na maneira designada.
Como é aqui utilizado, o "processador de cartão" é qualquer entidade adequada que serve ou processa produtos de cartão. Como é aqui utilizado, o "emissor de cartão" é qualquer entidade adequada que emite produtos de cartão (por exemplo, um banco emissor ou outra entidade assemelhada que seja capaz de emitir produtos de cartão) . Por exemplo, o emissor de cartão designa BINs para cada processador de cartão. Como é aqui utilizado, o "produto de cartão" pode ser qualquer tipo adequado de cartão não recarregável ou recarregável ou produto com base em cartão, como, por exemplo, cartões de presentes (por exemplo, cartões de presentes emitidos por bancos), cartões de débito, cartões de contas de economias de saúde (HSA), cartões de contas de gastos flexíveis (FSA), cartões de folha de pagamento recarregãveis, cartões de viagem, cartões de times profissionais ou universitários, cártões de contas de economias) cartões de crédito, ou assemelhados. Por exemplo, na indústria de cartão de presente emitida por banco, o processador de cartão 110 é referido simplesmente como "processador" ou "processador de cartão". O processador efetua funções tais como, por exemplo, criar e manter cartões e informação de produto de cartão, conectar com redes de pagamento e agentes de vendas para autorizar transações de compra e de vendas de cartões, lançar transações de cartão e emolumentos no cartão apropriado, fornecer dados de relatório de cartão, e assemelhados. Assim, como é aqui utilizado, o "não processador" refere-se a uma entidade que não o "processador" (isto é, que não uma entidade que processa ou serve produtos de cartão). Por exemplo, o módulo de portal de agente 105 pode ser considerado um "não processador" . No entanto, aqueles de habilidade ordinária na tecnologia reconhecerá que o processador de cartão 110 pode ser qualquer entidade adequada que seja capaz de processar ou de servir qualquer tipo adequado de produto de cartão. De acordo com versões exemplares, o sistema de gerenciamento de produto de cartão 100 é configurado para gerenciar a informação associada aos produtos de cartão para a pluralidade de processadores de cartão 110.
O módulo de portal de agente 105 é configurado para escolher um da pluralidade de processadores de cartão 110 de acordo com o identificador singular associado ao produto de cartão para processar a informação associada ao produto de cartão. De acordo com versões exemplares, cada produto de cartão tem um identificador singular que permite ao sistema de gerenciamento de produto de cartão 100 associar o produto de cartão ao processador de cartão 110 que gerou aquele identificador de produto de cartão. 0 identificador singular pode ser qualquer cadeia numérica ou alfanumérica de caracteres, ícones, símbolos, imagens, ou assemelhados, que seja capaz de identificar singularmente um produto de cartão e associar o produto de cartão ao processador de cartão 110 que gerou o identificador de produto de cartão. Para os fins de ilustração e não de limitação, suponha que o produto de cartão seja um cartão de presente emitido por banco. Esses cartões de presente podem incluir uma cadeia numérica de dezesseis dígitos, geralmente da forma: XXXX XXXX XXXX XXXX, em que "X" pode ser qualquer dígito de 0 a 9 inclusive. Os seis primeiros dígitos podem compreender um número de identificação de banco (BIN), isto é, um número que identifica singularmente a instituição financeira (por exemplo, banco) que serve e/ou processa o cartão de presente, embora qualquer número adequado de dígitos possam ser utilizados para especificar o BIN. BINs podem ser designados a cada processador de cartão 110 pelos emissores de cartão, e os processadores de cartão 110 geralmente associam BINs autorizados aos produtos de cartão. O módulo de portal de agente 105 pode então utilizar o BIN associado a um produto de cartão para determinar qual da pluralidade de processadores de cartão 110 comunicar informação associada ao produto de cartão. Uma vez tenha sido determinado o processador de cartão 110 apropriado, o módulo de portal de agente 105 pode então comunicar com o processador de cartão 110 utilizando o método de comunicação e de protocolo nativo ao processador de cartão 110. É observado mais uma vez que o presente exemplo é meramente para fins de ilustração. Qualquer identificador singular adequado pode ser utilizado para cada produto de cartão, pois alguns produtos com base no cartão poderão não utilizar BINs.
Aqueles de habilidade ordinária reconhecerão que o módulo de portal de agente 105 pode ser escalonado para múltiplos módulos de portais de agentes 105 interconectados por comunicação de rede de computador adequada para lidar com qualquer número adequado de processadores de cartão 110.
O módulo de portal de agente 105 inclui um módulo servidor de aplicação de cliente 115. De acordo com uma versão exemplar, o módulo servidor de aplicação de cliente 115 é configurado para lidar com a comunicação e a passagem de mensagens com os processadores de cartão 110 em prol do módulo de portal de agente 105. 0 módulo servidor de aplicação de cliente 115 é configurado para escolher o processador de cartão 110 com o qual comunicar informação associada ao produto de cartão com base no identificador singular do produto de cartão. Por exemplo, o módulo servidor de aplicação do cliente 115 pode manter ou de outra forma armazenar uma tabela de pesquisa que mapeia os identificadores singulares com os processadores de cartão correspondentes 110. Para fins de ilustração e não de limitação, supondo que os produtos de cartão são cartões de presente emitidos por bancos ou assemelhados, então a tabela de pesquisa pode incluir um mapeamento de BINs aos bancos, tal que a informação associada a um produto de cartão pode ser enviada ao banco com base no FIN do produto de cartão.
Além disso, o módulo servidor de aplicação do cliente 115 é configurado para transformar mensagens para comunicação a um processador de cartão 110 respectivo no formato de mensagem utilizado pelo processador de cartão 110 respectivo. Como foi discutido anteriormente, qualquer um ou a totalidade dos processadores de cartão 110 pode utilizar um protocolo de comunicação diferente para passar mensagens, dados e outra informação. Uma vez que o módulo servidor de aplicação do cliente 115 determina qual dos processadores de cartão 110 enviar a informação, o módulo servidor de aplicação do cliente 115 pode então formatar a mensagem de maneira apropriada (por exemplo, pré-apensar um cabeçalho e apensar um checksum e assemelhados ao corpo da mensagem) para enquadrar ao protocolo utilizado pelo processador de cartão 110 selecionado. Por exemplo, o módulo servidor de aplicação do cliente 115 pode manter uma tabela de pesquisa que associa processadores de cartão 110 a protocolos de comunicação, de modo que para qualquer processador de cartão 110 particular, o módulo servidor de aplicação do cliente pode determinar qual protocolo de comunicação e outros parâmetros semelhantes são suportados pelo processador de cartão 110 selecionado. Uma vez formatado de modo apropriado, o módulo servidor de aplicação do cliente 115 pode transmitir a mensagem formatada para o processador de cartão 110. Ao gerenciar os detalhes de cada enlace de comunicação com cada processádor de cartão 110, em vez de fazer os processadores de cartão 110 se enquadrarem em um protocolo de comunicação estabelecido pelo sistema de gerenciamento de produto de cartão 100, processadores de cartão 110 adicionais podem ser facilmente acrescentados ou de outra forma conectados ao sistema 10 0 com pouca ou nenhuma modificação aos sistemas dos processadores de cartão 110. Alternativamente, o processador de cartão 110 pode optar por comunicar com o módulo servidor de aplicação do cliente 115 através de um formato de comunicação padrão e protocolo estabelecido pelo sistema de gerenciamento de produto de cartão 100.
O módulo servidor de aplicação do cliente 115 também é configurado para receber informação associada a produtos de cartão de cada um dos processadores de cartão 110. Entretanto, qualquer um ou todos os processadores de cartão 110 pode enviar informação (isto é, os dados contidos nas mensagens) em diferentes formatos de dados ou em um formato padrão fornecido pelo sistema de gerenciamento de produto de cartão 100. Por exemplo, valores numéricos de informação podem ser especificados utilizando casas decimais variadas ou nenhuma, códigos ou respostas para uma resposta particular podem ser especificados de modos diferentes, e as estruturas de dados correspondentes a cada processador de cartão 110, tal processamento tende a aumentar a complexidade do sistema 100.
De acordo com uma versão exemplar, o módulo servidor de aplicação do cliente 115 é configurado para normalizar ou de outra forma mapear a informação contida em cada mensagem de cada um dos processadores de cartão 115 para transformar a informação em um formato uniforme utilizado pelo sistema de gerenciamento de produto de cartão 100. 0 módulo servidor de aplicação do cliente 115 pode utilizar qualquer formato de dados adequado para todo ou substancialmente todo o processamento dentro do sistema 100. Por exemplo, o módulo servidor de aplicação do cliente 115 pode manter ou de outra forma armazenar uma tabela de tradução ou de pesquisa adequada para normalizar ou de outra forma converter a informação do formato suportado pelo processador de cartão 110 para o formato suportado pelo sistema de gerenciamento de produto de cartão 100, e vice versa. Por exemplo, o módulo servidor de aplicação do cliente 115 pode transformar dados como, por exemplo, códigos de estado, respostas, detalhes de transação, ou qualquer outra informação adequada dentro dos códigos de estado, respostas, detalhes de transação correspondentes utilizados pelo módulo servidor de aplicação do cliente 115.
Para os fins de ilustração e não de limitação, suponha que o servidor de aplicação do cliente 115 recebe uma mensagem de um processador de cartão 110 particular que inclui dois campos. O módulo servidor de aplicação do cliente 115 utiliza um formato de dados uniforme em que o primeiro campo é um valor em dólares do cartão de presentes, especificado com duas casas decimais. O segundo campo é um campo de autorização, especificado como "ACCEPT" ou "DENY". No entanto, o processador de cartão 110 particular especifica os dois campos de modo diferente - o primeiro campo é especificado em números inteiros (isto é, sem decimais), e o segundo campo é "0K" ou "N0T 0K". Assim, os dois campos são preenchidos pelo processador de cartão 110, por exemplo, com o valor "5000" e a resposta "ÓK". O módulo servidor de aplicação do cliente 115 pode determinar o processador 110 particular do qual a mensagem foi recebida (por exemplo, ao utilizar o identificador singular associado ao produto de cartão ao qual a mensagem pertence). O módulo servidor de aplicação do cliente 115 pode então efetuar uma pesquisa ou tradução da tabela para determinar que, para este processador de cartão 110 em particular, o valor no primeiro campo (isto é, "5000") precisa ser dividido por 100 para obter o valor com duas casas decimais, e que a resposta de autorização de "OK" corresponde a "ACCEPT". Assim, ao normalizar os dados de cada processador de cartão 110 em um formato de dados uniforme, o módulo servidor de aplicação do cliente 115 pode gerenciar quaisquer diferenças entre formatos de dados através da pluralidade de processadores de cartão 110. Além disso, ao gerenciar os detalhes do formato de dados suportado por cada processador de cartão 110, em vez de ter os processadores de cartão 110 se enquadrarem no formato de dados utilizado pelo sistema de gerenciamento de produto de cartão 100, processadores de cartão 110 adicionais podem ser facilmente acrescentados ou de outra forma conectados ao sistema 100 com pouca ou nenhuma modificação aos sistemas dos processadores de cartão 110.
Quando da normalização dentro do formato suportado pelo sistema de gerenciamento de produto de cartão 100, o módulo servidor de aplicação do cliente 115 é configurado para validar ou de outra forma verificar os dados normalizados para assegurar a precisão daqueles dados. Por exemplo, como o módulo servidor de aplicação do cliente 115 "compreende" o formato em que os dados estão, o módulo servidor de aplicação do cliente 115 pode efetuar, por exemplo, limites ou faixa na verificação dos dados, verificação dos dados, e outras conferências adequadas nos dados normalizados. Por exemplo, continuando com a ilustração anterior, suponha que o primeiro campo (isto é, o valor em dólares do cartão de presente) deve ser especificado com duas casas decimais e conter o valor entre $0.00 e $100.00. Portanto, após a normalização, se o valor enviado pelo processador de cartão 110 estiver fora dessa faixa (por exemplo, inferior a $0.00 ou maior que $100.00), então uma mensagem de errò adequada pode ser enviada pelo sistema 100 ao processador de cartão 110 fornecendo notificação do erro e, se necessário, uma solicitação para dados corrigidos. Adicionalmente, um registro adequado do erro pode ser mantido pelo sistema de gerenciamento de produto de cartão 100 (por exemplo, em um diário de erro apropriado ou assemelhado). Outras técnicas de verificação e de validação de dados adequadas semelhantes podem ser efetuadas pelo módulo servidor de aplicação do cliente 115 nos dados normalizados recebidos de cada processador de cartão 110. Aqueles de habilidade ordinária reconhecerão que a verificação e a validação dos dados pode ser efetuada pelo módulo servidor de aplicação do cliente 115 quer antes ou após a normalização dos dados dentro do formato suportado pelo sistema de gerenciamento de produto de cartão 100.
Qualquer tipo adequado de informação associada aos produtos de cartão pode ser comunicada entre o módulo de portal do agente 105 e a pluralidade de processadores de cartão 110, incluindo, por exemplo, informação financeira, situação, consultas, e qualquer outra resposta e reações apropriadas, bem como informação para o gerenciamento e a administração dos produtos de cartão, como a informação relacionada aos usuários, inscrição, e assemelhados. Como foi discutido anteriormente, o formato das mensagens e a informação ou dados contidos dentro dessas mensagens dependerá de numerosos fatores como, por exemplo, o protocolo de comunicação utilizado pelos processadores de cartão 110, a natureza e tipo da informação associada aos produtos de cartão, e outros fatores semelhantes. De acordo com uma versão exemplar da presente invenção, a informação recebida de cada processador de cartão 110 pode compreender uma pluralidade de relatórios. Por exemplo, um único relatório pode conter a totalidade ou substancialmente toda a informação relevante associada a um ou mais produtos de cartão mantidos pelo sistema de gerenciamento de produto de cartão 100. Alternativamente, múltiplos relatórios podem ser utilizados, com cada relatório contendo um subconjunto predeterminado da informação associada ao um ou mais produtos de cartão.
Por exemplo, de acordo com uma versão exemplar da presente invenção, três desses relatórios podem ser utilizados para comunicar informação associada a produtos de cartão, como, por exemplo, um relatório "geral", um relatório "lançado" e um relatório de "autorização". Os relatórios gerais podem incluir qualquer dado geral ou não financeiro adequado associado aos produtos de cartão, incluindo, por exemplo, nomes e endereços de detentores de cartão, dados demográficos associados aos detentores de cartão, situação dos produtos de cartão, e outra informação assemelhada. No entanto, os relatórios gerais também podem incluir qualquer dado financeiro adequado, como, por exemplo, balancetes de cartões e assemelhados. Òs relatórios lançados podem incluir qualquer informação adequada sobre transações lançadas, como, por exemplo, uma listagem das transações lançadas do dia de negócios anterior ou assemelhados. Os relatórios de autorização podem incluir qualquer informação adequada sobre autorizações de transações financeiras ou outras, incluindo, por exemplo, tentativas de autorização, transações não resolvidas e assemelhados. No entanto, qualquer número adequado de relatórios, cada um deles contendo qualquer tipo apropriado de informação, pode ser utilizado para comunicar informação associada aos produtos de cartão, por exemplo, dos processadores de cartão 110.
Por exemplo, a Figura 2 é uma especificação de relatório para um relatório geral ou não financeiro 200, de acordo com uma versão exemplar da presente invenção. 0 relatório geral 200 inclui várias seções, incluindo uma seção de cabeçalho 205, uma seção de detalhe (corpo) 210, e uma seção de cauda 215. A especificação de relatório ilustrada na Figura 2 descreve os campos que podem preencher a seção de cabeçalho 205, a seção de detalhe 210, e a seção de cauda 215, bem como, por exemplo, o comprimento máximo 220 de cada campo, o formato 225 de cada campo, e a descrição 230 de cada campo dentro de cada uma das seções. A seção de cabeçalho 205 pode incluir qualquer campo de cabeçalho adequado, como, por exemplo, HEADER (por exemplo, para especificar o início da seção de cabeçalho 205) ; PROCESSOR NAME (por exemplo, nome do processador de cartão 110) ; REPORT/DATA FEED NAME (por exemplo, para especificar o relatório como um relatório geral ou não financeiro 2 00) ; FILEDATE (por exemplo, a data em que o relatório é recebido do processador); RUNDATE BEGIN (por exemplo, a data inicial a que a informação no relatório geral 200 está se referindo) ; e RUNDATE END (por exemplo, a data final a que a informação no relatório geral 200 está se referindo). Campos adicionais e/ou alternativos podem ser incluídos na seção de cabeçalho 205.
A seção de detalhe 210 pode incluir qualquer campo de detalhe ou corpo adequados, como, por exemplo: CARD NUMBER (por exemplo, o número no plástico emitido ao detentor do cartão); OPEN DATE (por exemplo, a data em que o cartão particular foi aberto); EXPIRATION DATE (por exemplo, a data de expiração do cartão); CARDHOLDER IDENTIFICATION CODE (por exemplo, o código utilizado para identificar o valor de identificação do detentor do cartão, como, por exemplo, "1" para o número de seguro social, "2" para o número da carteira de motorista, w3" para o número consular matricular, "4" para passaporte, "5" para o visto, "6" para o cartão verde ou assemelhado); CARDHOLDER IDENTIFICATION VALUE (por exemplo, o valor utilizado para identificar o cliente); PRIMARY CARDHOLDER FIRST NAME; PRIMARY CARDHOLDER LAST NAME; ADDRE S S LINE 1; ADDRES S LINE 2 (por exemplo, primeira e segunda linhas do endereço do detentor do cartão); CITY; STATE; ZIP CODE (por exemplo, cidade, estado e código zip (de endereçamento postal) do endereço do detentor do cartão); PRIMARY PHONE NUMBER; SEC0NDARY PHONE NUMBER (por exemplo, números de telefone principal e secundário do detentor do cartão); STATUS (por exemplo, o estado de determinado cartão); CURRENT BALANCE (por exemplo salto atual no cartão); CURRENT BALANCE SIGN (por exemplo, sinal se o saldo for positivo ( + ) ou negativo (-)); PR0GRAM IDENTIFICATION VALUE (por exemplo, um valor designado pelo processador, se aplicável); e SUB-PR0GRAM IDENTIFICATION VALUE (por exemplo, um valor designado pelo processador, se aplicável). De acordo com uma versão exemplar, o campo CARDHOLDER IDENTIFICATION VALUE é compreendido de uma concatenação de sub-campos, incluindo, por exemplo: VALUE (por exemplo, até 25 caracteres alfanuméricos que especificam um valor de identificação); C0UNTRY (por exemplo, até 2 caracteres alfanuméricos que especificam o país da emissão da identificação); EXPIRATION DATE (por exemplo, especificada como MMDDYYY, MMYYY, YYYY ou assemelhado); e COMMENTS (por exemplo, até 50 caracteres alfanuméricos que especificam os comentários). Campos e sub-campos adicionais e/ou alternativos podem ser incluídos na seção de detalhe 210. Qualquer número adequado de cartões ou de produtos de cartão pode ser levado no relatório geral 200, e cada cartão ou produto de cartão (por exemplo, cada conta associada a cada cartão ou produto de cartão) pode ter um registro de detalhe na seção de detalhe 210.
A seção de cauda 215 pode incluir qualquer campo de cauda adequado, como, por exemplo: TRAILER (por exemplo, para especificar o início da seção de cauda 215) ; e COUNT (por exemplo, para especificar o número ou contagem de registros de detalhe contidos na seção de detalhe 210). Campos adicionais e/ou alternativos podem ser incluídos na seção de cauda 215.
Por exemplo, a Figura 3 é uma especificação de relatório para um relatório lançado 3 00, de acordo com uma versão exemplar da presente invenção. O relatório lançado 300 inclui várias seções, incluindo uma seção de cabeçalho 3 05, uma seção de detalhe (corpo) 310, e uma seção de cauda 315. A especificação de relatório ilustrada na Figura 3 descreve os campos que podem preencher a seção de cabeçalho 305, a seção de detalhe 310, e a seção de cauda 315, bem como, por exemplo, o comprimento máximo 32 0 de cada campo, o formato 325 de cada campo, e a descrição 330 de cada campo dentro de cada uma das seções. A seção de cabeçalho 305 pode incluir qualquer campo de cabeçalho adequado, como o mesmo ou campos diferentes de cabeçalho que os especificados para a seção de cabeçalho 205 do relatório geral 200 (por exemplo, com o valor do campo REPORT/DATA FEED NAME especificando o relatório como um relatório lançado 300).
A seção de detalhe 310 pode incluir qualquer campo de detalhe ou corpo adequado, como, por exemplo: CARD NUMBER (por exemplo, o número no plástico emitido ao detentor do cartão); TRANSACTIÒN DATE (por exemplo, a data da transação original); TRANSACTION CODE (por exemplo, código que representa o tipo de transação monetária); TRANSACTION AMOUNT (por exemplo, a quantidade da transação que foi lançada no cartão); TRANSACTION AMOUNT SIGN (por exemplo, sinal se a transação for positiva ( + ) òu negativa ( - ), com o sinal negativo designando a remoção de recursos, enquanto o sinal positivo designa o acréscimo de recursos); TRANSACTION CURRENCY CODE (por exemplo, código que representa a moeda da quantidade da transação); AUTHORIZATION CODE (por exemplo, o número de identificação designado à transação aprovada, e pode ser branco se a solicitação de autorização foi negada); POST DATE (por exemplo, data em que a transação foi lançada no cartão); NETWORK CODE (por exemplo, código que identifica a trilha da rede (por exemplo, Pulse, NYCE, STAR ou assemelhados) utilizada para processar a transação); MERCHANT NUMBER (por exemplo, número que identifica o comerciante que submete a transação); MERCHANT NAME (por exemplo, Noé do comerciante que aceitou a transação original); MERCHANT CATEGORY CODE (por exemplo, código que representa o ramo de negócio do comerciante); MERCHANT COUNTRY CODE (por exemplo, código que representa o país onde o negócio dõ comerciante está localizado); INTERCHANGE FEE AMOUNT (por exemplo, quantidade de intercâmbio associada a presente transação) ;
ACH ROUTING NUMBER (por exemplo, número de roteamento onde os recursos serão distribuídos); ACH ACCOUNT NUMBER (por exemplo, número da conta onde Os recursos serão distribuídos); e ACH CONFIRMATION NUMBER (por exemplo, código de confirmação para a transação ACH que pode aparecer na fatura do detentor do cartão quando os recursos estiverem sendo distribuídos). Campos adicionais e/ou alternativos e sub-campos podem ser incluídos na seção de detalhe 310. A seção de cauda 315 pode incluir qualquer campo de cauda adequado, como o mesmo ou diferentes campos de cauda como os especificados para a seção de cauda 215 do relatório geral 200.
Por exemplo, a Figura 4 é uma especificação de relatório para um relatório de autorização 400, de acordo com uma versão exemplar da presente invenção. 0 relatório de autorização 4 00 inclui várias seções, incluindo uma seção de cabeçalho 405, uma seção de detalhe (corpo) 410, e uma seção de cauda 415. A especificação de relatório ilustrada na Figura 4 descreve os campos que podem preencher a seção de cabeçalho 4 05, a seção de detalhe 410 e a seção de cauda 415, bem como, por exemplo, o
comprimento máximo 42Ô de cada campo, o formato 4 25 de cada campo, e a descrição 43 0 de cada campo dentro de cada uma das seções. A seção de cabeçalho 405 pode incluir qualquer campo de cabeçalho adequado, como o mesmo ou campos de cabeçalhos diferentes conforme especificados para a seção de cabeçalho 205 do relatório geral 200 (por exemplo, com o valor do campo REPORT/DATA FEED NAME especificando o relatório como m relatório de autorização 4 00).
A seção de detalhe 410 pode incluir qualquer campo de detalhe ou corpo, como, por exemplo: CARD NUMBER (por exemplo, o número no plástico emitido para o detentor de cartão); TRANSACTION DATE/TIME (por exemplo, data e hora da transação original); TRÀNSACTΪON CURRENCY CODE (por exemplo, código que representa a moeda da quantidade da transação); ADDRESS VERIFICATION RESPONSE (por exemplo, mensagem que representa a resposta se a verificação de endereço foi utilizada); AUTHORIZATION RESPONSE (por exemplo, mensagem que representa porque a solicitação foi autorizada ou negada); AUTHORiZATION AMOUNT (por exemplo, quantidade da solicitação de autorização); AUTHORIZATION CODE (por exemplo, número de identificação designado à transação aprovada, e pode ser branco se a solicitação de autorização foi negada); NETWORK CODE (por exemplo, código que identifica as trilhas da Rede (por exemplo, Pulse, NYCE, STAR ou assemelhadas) utilizada para processar a transação); MERCHANT NUMBER (por exemplo, número que identifica o comerciante que submete a transação); MERCHANT NAME (por exemplo, nome do comerciante que aceitou a transação original); MERCHANT CATEG0RY CODE (por exemplo, código que representa ó ramo de negócios do comerciante) ; e MERCHANT COUNTRY CODE (por exemplo, código que representa o país onde o negócio do comerciante está localizado). Campos e sub-campos adicionais e/ou alternativos podem ser incluídos na seção de detalhe 410. A seção de cauda 415 pode incluir qualquer campo de cauda adequado, como o mesmo ou diferentes campos de cauda conforme especificado para a seção de cauda 215 do relatório geral 200.
Como foi discutido acima, BINs são designados a processadores de cartão 110 pelos emissores do cartão. Por exemplo, um BIN ou outro identificador singular pode ser designado a cada processador de cartão 110 por MASTERCARD™ ou VISA™ ou outro emissor de cartão. Os processadores de cartão 110 associam BIN aos produtos de cartão. Os BINs podem ser utilizados para identificar singularmente o processador de cartão 110 que serve e/ou processa um produto de cartão particular. Para a ilustração de cartões de presente emitidos por bancos ou assemelhados com números de produto de cartão de dezesseis dígitos, os seis primeiros dígitos do número do produto de cartão pode compreender o BIN, embora qualquer número adequado de dígitos possa ser utilizado para especificar o BIN. Convencionalmente, os dígitos restantes do número de produto de cartão podem ser utilizados para identificar singularmente o usuário (por exemplo, o detentor do cartão), e também são designados pelos processadores de cartão 110. Para a ilustração de cartões de presente emitidos por bancos ou assemelhados, os dígitos restantes (por exemplo, dez) são comumente utilizados para designar uma extensão BIN (por exemplo, seis dígitos) , um número de cartão (por exemplo, três dígitos) , e um bit de verificação (por exemplo, um dígito). 0 número de produto de cartão inteiro assim identifica singularmente tanto o processador de cartão 110 que serve e/ou processa o produto de cartão e o detentor de cartão daquele produto de cartão.
Contudo, de acordo com uma versão exemplar alternativa da presente invenção, o módulo servidor de aplicação do cliente 115 pode ser configurado para alocar e designar números de cartão correspondentes a cada BIN (ou outro identificador singular) para os produtos de cartão. Mais particularmente, o número de produto de cartão pode ser compreendido de duas partes de dígitos - uma primeira parte de dígitos e uma segunda parte de dígitos. Para fins de ilustração e não de limitação, para um número de produto de cartão de dezesseis dígitos, por exemplo, para um cartão de presente emitido por banco ou assemelhado, a primeira parte dos dígitos pode incluir os seis primeiros dígitos do número de produto de cartão, enquanto a segunda parte de dígitos pode incluir os dez dígitos restantes. A primeira parte de dígitos pode compreender o BIN (ou outro identificador singular adequado) . Para cada BIN, a segunda parte de dígitos pode ser utilizada para designar números de cartão para o BIN dado. O módulo servidor de aplicação do cliente 115 pode alocar números de cartão que compreendem a totalidade ou substancialmente toda a segunda parte de dígitos para cada BIN, embora o módulo servidor de aplicação do cliente 115 possa utilizar qualquer subconjunto da segunda parte dos dígitos para alocar números de cartão.
Em outras palavras, de acordo com uma versão exemplar, o módulo servidor de aplicação do cliente 115 pode ser configurado para alocar ê designar números de cartão para cada BIN (ou outro identificador singular adequado) ao utilizar a totalidade ou substancialmente todos os dígitos restantes que não o BIN em um número de produto de cartão. Para o exemplo de um número de produto de cartão de dezesseis dígitos com um BIN de seis dígitos, os dez dígitos restantes (ou qualquer subconjunto deles) podem ser utilizados para designar qualquer um de um bilhão de números de cartão para um BIN particular. Conseqüentemente, para um número de produto de cartão de dezesseis dígitos com um BIN de seis dígitos e dez dígitos restantes, até um bilhão de produtos de cartão podem ser emitidos para cada processador de cartão 110, embora o número de cartões disponíveis dependa de fatores como, por exemplo, o comprimento do número de produto de cartão utilizado, o comprimento do BIN ou outro identificador que forma parte do número de produto de cartão, e outros fatores assemelhados. Assim, um "não processador" em particular o sistema de gerenciamento de produto de cartão 100 de acordo com versões exemplares, pode alocar e designar valores (por exemplo, números de cartão) a toda a segunda parte de dígitos, ou qualquer subconjunto dela, do número de produto de cartão de cada produto de cartão. Por exemplo, os números de cartão para à segunda parte de dígitos podem ser alocados seqüencial ou aleatoriamente para cada BIN. De acordo com uma versão exemplar, a primèira parte de dígitos pode preceder a segunda parte de dígitos dentro de cada número de produto de cartão. De acordo com uma versão exemplar alternativa, a segunda parte pode preceder a primeira parte de dígitos. Alternativamente, a primeira e a segunda parte de dígitos pode ser adequadamente entrelaçada ou misturada dentro do número de produto de cartão. O comprimento (em dígitos) do número de produto de cartão e os tamanhos das primeira e segunda partes correspondentes dos dígitos dependerá de fatores como, por exemplo, o tipo de número de cartão utilizado para cada produto de cartão, o tamanho ou comprimento (em dígitos) do BIN ou outro identificador singular, o tamanho ou comprimento (em dígitos) dos números de cartão correspondentes, e outros fatores semelhantes. De acordo com mais uma versão exemplar, o módulo servidor de aplicação do cliente 115, e não os emissores de cartão, pode alocar e designar os BINS para cada processador de cartão 110.
Métodos e mecanismos adequados e apropriados podem ser utilizados para assegurar a segurança da informação comunicada entre o módulo de portal de agente 105 e os processadores de cartão 110. Por exemplo, conexões seguras (por exemplo, através de HTTPS ou assemelhado) podem ser mantidas entre o módulo de portal de agente 105 e cada um dos processadores de cartão 110. Adicional ou alternativamente, os dados e informação podem ser adequadamente criptografadas utilizando qualquer algoritmo ou técnica de criptografia ou criptográfica apropriada, incluindo, por exemplo, qualquer sistema de infra-estrutura de chave pública adequado (PKI), RC4, MD5, codificação base 64 ou assemelhados.
As mensagens comunicadas aos processadores de cartão 110 podem incluir, por exemplo, uma consulta ou assemelhado que inclui um endereço de rede de computador (por exemplo, uma URL, endereço IP ou assemelhado) de um arquivo. Por exemplo, a consulta pode compreender uma consulta de busca convencional enviada pelo módulo de portal de agente 105 para obter um arquivo ou outros dados localizados em uma URL de sítio da Web particular ou outro endereço singular.
No entanto, se interceptado, um hacker ou intruso malicioso pode potencialmente adulterar a consulta. Por exemplo, a URL ou endereço de rede de computador poderia ser modificada para obter um arquivo ou dados diferentes, como o arquivo ou dados seguros que não foi feito para ser acessado ou obtido pelos processadores de cartão 110. Essa atividade maliciosa poderia tornar os dados mantidos pelos processadores de cartão 110 e o sistema de gerenciamento de produto de cartão 100 vulnerável a roubo ou corrupção.
De acordo com uma versão exemplar, para encarar essas questões de segurança, o endereço de rede de computador contido na consulta pode ser criptografado. 0 endereço de rede de computador criptografado é então apensado ao final da consulta. Ao apensar o endereço de rede de computador criptografado ao final da consulta, a consulta pode ser processada (por exemplo, pelos processadores de cartão 110) da maneira convencional (enquanto ignora o endereço de rede de computador criptografado apensado) para obter o arquivo ou dados no endereço de rede de computador especificado. A resposta à consulta (por exemplo, enviada ao módulo de portal de agente 105) também pode incluir a própria consulta, com o endereço de rede de computador e o endereço de rede de computador criptografado na resposta. 0 módulo servidor de aplicação do cliente 115 é configurado para detectar a adulteração do endereço de rede de computador ao descriptografar o endereço de rede de computador criptografado, e então comparar o endereço de rede de computador e o endereço de rede de computador descriptografado. Se os dois endereços de rede de computador forem o mesmo, nenhuma adulteração ocorreu.
Entretanto, se o endereço de rede de computador não casar com o endereço de rede de computador descriptografado, uma adulteração ocorreu. Em tal caso, medidas de segurança adequadas podem ser levadas a cabo (por exemplo, apagar a mensagem) e alertas e avisos apropriados podem ser comunicados aos clientes afetados.
De acordo com uma versão exemplar alternativa, o módulo servidor de aplicação de cliente 115 é configurado para detectar a adulteração do endereço de rede de computador ao re-criptografar o endereço de rede de computador, e então comparar o endereço de rede de computador recriptografado e o endereço de rede de computador originalmente criptografado (que havia sido apensado ao final da consulta). Se o endereço original e o endereço de rede de computador recém criptografado forem diferentes, então uma adulteração ocorreu. Para fins de ilustração e não de limitação, para criar um eridereço de rede de computador criptografado de acordo com essa versão exemplar alternativa, um hás MÍ)5 de uma criptografação RC4 da cadeia de consulta de uma URL pode ser efetuada para gerar um hash criptografado. O hash criptografado pode ser apensado à cadeia de consulta como um par de valor de chave singular. Para verificar a validade de uma cadeia de consulta codificada, o hás do par de valor de chave única pode ser removido da cadeia de consulta. Um hás MD5 de uma criptografação RC4 da cadeia de consulta restante pode ser criado. O resultado da criptografia pode ser comparado ao valor de chave singular que foi removido anteriormente da cadeia de consulta. Se os dois hashes criptografados forem diferentes, então a adulteração da cadeia de consulta ocorreu. Qualquer técnica de criptografia adequada pode ser utilizada para criptografar o endereço de rede de computador. Por exemplo, de acordo com uma versão exemplar, uma função hash criptográfica pode ser utilizada. Como foi ilustrado anteriormente, o endereço de rede de computador pode ser criptografado (por exemplo, utilizando RC4, MD5, base64 ou assemelhado ou qualquer combinação adequada deles) para gerar um endereço de rede de computador criptografado. Uma função hash adequada pode então ser aplicada ao endereço de rede de computador criptografada para gerar um hash criptografado. Embora endereços de rede de computador tenham sido discutidos, é observado que qualquer dado adequado dentro da consulta, incluindo a própria consulta inteira ou qualquer parte dela, pode ser criptografada e apensada ao final da consulta para fins de detectar a adulteração de acordo com a versão exemplar.
Para manter e administrar os produtos de cartão, o sistema de gerenciamento de produto de cartão 100 inclui um módulo de base de dados 120 em comunicação com o módulo servidor de aplicação do cliente 115. 0 módulo de base de dados 120 é configurado para armazenar, por exemplo, informação associada aos produtos de cartão e outra informação assemelhada. 0 módulo servidor de aplicação do cliente 115 pode consultar ou de outra forma acessar o módulo de base de dados 120 para armazenar ou recuperar essa informação de acordo com solicitações dos usuários dos processadores de cartão 110, ou do próprio sistema 100. Por exemplo, o módulo de base de dados 120 pode ser utilizado para armazenar tabelas de números de cartão correspondentes a cada BIN e outra informação assemelhada para suportar o gerenciamento e a administração de produtos de cartão. 0 módulo de base de dados 12 0 pode ser qualquer tipo adequado de base de dados de computador ou meio de armazenamento ou memória, produto de base de dados (por exemplo, SQL) que interage com qualquer desse meio ou memória, ou outro dispositivo de armazenamento elétrico ou eletrônico assemelhado ou instalação que seja capaz de armazenar informação elétrica e eletrônica para recuperação posterior.
De acordo com versões exemplares, processadores de cartão 110, administradores, e outras entidades e indivíduos (coletivamente referidos como "usuários") podem acessar informação sobre produtos de cartão através do sistema de gerenciamento de produto de cartão 100. Em outras palavras, o módulo de portal de agente 105 é configurado para permitir o acesso pelos usuários para gerenciar a informação associada a produtos de cartão. Para suportar esse acesso, o módulo de portal de agente 105 inclui um módulo de interface gráfico de usuário 130. 0 módulo de interface gráfico de usuário 130 é configurado para exibir, quer local ou remotamente, uma interface gráfica de usuário (GUI) através da qual usuários podem interagir com o sistema de gerenciamento de produto de cartão 100. O GUI, por exemplo, pode ser uma interface gráfica de proprietário, qualquer browser da Web adequada (por exemplo, Internet Explorer, Netscape, Firefox, Safari, Opera, ou qualquer outro browser da Web adequado) ou outra interface assemelhada que seja capaz de exibir a informação gráfica e/ou de texto, e que pode suportar conexões seguras e acesso remoto ao sistema de gerenciamento de produto de cartão 100. Por exemplo, um computador pessoal (PC) 140 ou outro tipo adequado de sistema ou dispositivo de computador (por exemplo, laptop, assistente digital pessoal (PDA) , telefone celular ou assemelhado) pode ser utilizado pelo detentor do cartão 143, a instituição financeira 147 ou outro usuário assemelhado para acessar remotamente a informação a respeito de produtos de cartão através do sistema de gerenciamento de produto de cartão 100 utilizando o GUI do módulo de interface gráfico de usuário 130, por exemplo, através de um browser da Web adequado através de uma conexão segura pela Internet ou a World Wide Web.
O GUI pode suportar uma tela de registro que orienta os usuários a entrar com o nome de usuário (ou o endereço de correspondência eletrônica) e uma senha singularmente designada para obter o acesso inicial ao sistema de gerenciamento de produto de cartão 100 quando da entrada bem sucedida de ambos. As senhas podem ser criptografadas utilizando qualquer técnica de criptografia adequada (por exemplo, MD5 ou assemelhado) , e os usuários podem ser impedidos de entrar no sistema após três tentativas mal sucedidas de entrar. Outras medidas de segurança adicionais ou alternativas podem ser utilizadas para registrar no sistema 100, incluindo, por exemplo, a biometria e assemelhados. De acordo com uma versão exemplar, o módulo de interface gráfico de usuário 130 é configurado para determinar o endereço de rede de computador do usuário (por exemplo, o endereço IP do computador do qual o usuário está acessando o sistema 100) . Como um recurso de segurança adicional, o módulo de interface gráfico de usuário 130 pode comparar o endereço de rede de computador do usuário com o endereço de rede de computador que foi armazenado para o nome de usuário do usuário (por exemplo, um endereço IP que é entrado ou de outra forma gravado para o usuário por ocasião da assinatura ou registro com o sistema 100). Além do nome de usuário e da senha, se o endereço de rede de computador do usuário não casar com o endereço de rede de computador gravado correspondente ao nome de usuário do usuário, então o acesso ao sistema de gerenciamento de produto de cartão 100 pode ser negado. Assim, o usuário pode ter o acesso concedido ao sistema de gerenciamento de produto de cartão 100 através do GUI utilizando ambos ou qualquer um da senha e do endereço de rede de computador associado do usuário.
O sistema de gerenciamento de produto de cartão 100 é um sistema com base no desempenho de papel. Em outras palavras, a funcionalidade, recursos e informação apresentados e acessíveis por cada usuário através do GUI pode ter por base o papel estabelecido do usuário ante o sistema 100. Por exemplo, ò detentor de cartão pode ter o acesso concedido e gerenciar a informação que pertence apenas aos produtos de cartão mantidos pelo detentor do cartão. Em contraste, o processador de cartão 110 pode receber acesso e gerenciar informação que pertence a todos os produtos de cartão emitidos pelo processador de cartão 110. No entanto, o administrador do sistema de gerenciamento de produto de cartão 100 pode receber acesso e gerenciar a informação que pertence a todos os produtos de cartão mantidos pelo sistema 100. Em cada caso, o GUI é configurado para permitir ao usuário dado o acesso apenas desses recursos, funcionalidade e informação que sejam apropriadas para o usuário dado o papel daquele usuário no sistema de gerenciamento de produto de cartão 100.
Para auxiliar na delineação da funcionalidade entre vários usuários, cada tipo de usuário pode acessar o sistema de gerenciamento de produto de cartão 100 através de diferentes endereços de sítio da Web(por exemplo, URLs). Por exemplo, detentores de cartão podem acessar o sistema 100 ao navegar seus browsers da Web para um sítio como, por exemplo, "meusaldoprepago.com" ou
"minhacontaprepaga.com.br" ou outro endereço de sítio da Web adequado. Os processadores de cartão 110 podem acessar o sistema 100 ao dirigir seus browsers da Web para um endereço diferente, como, por exemplo, "prepagoadmin.com" ou outro endereço de sítio da Web adequado. Embora diferentes URLs possam ser utilizadas para cada tipo de usuário, cada endereço de sítio da Web ainda leva o usuário respectivo para dentro do sistema de gerenciamento de produto de cartão 100, embora através de pontos de entrada diferentes.
Adicionalmente ou alternativamente, o GUI pode ser configurado para apresentar um tema, aparência ou "pele" diferente para o usuário, dependendo do papel do usuário e/ou sua afiliação com o processador de cartão 110. Por exemplo, com base na identificação do usuário através de seu nome de usuário e senha correspondentes (e, se desejado, o endereço de rede de computador), o módulo de interface gráfica do usuário 130 pode mudar a configuração da aparência do GUI exibido para o usuário. Por exemplo, para os detentores de cartão, o GUI pode ser bastante "exibido" ou de outra forma decorado elaboradamente para aprimorar a experiência do detentor de cartão. Além disso, anúncios, promoções, informação de marketing, dicas de uso, informação de navegação e assemelhados de interesse potencial para o detentor de cartão podem ser exibidos através do GUI para o detentor do cartão. Em contraste, um administrador pode ser apresentado a um GUI que é mais "severo", focalizando os recursos e a funcionalidade, e não na apresentação elaborada. Ademais, cada processador de cartão 110 pode ter um tema ou "pele" associado para o GUI. Assim, quando o processador de cartão 110 registrar em um sistema de gerenciamento de produto de cartão 100 através do GUI, o tema gráfico correspondente ou "pele" também ou alternativamente pode ser apresentado para os usuários (por exemplo, detentores de cartão) quando do gerenciamento de produtos de cartão emitidos pelo processador de cartão 110.
Quando obtiver o acesso, os usuários do sistema de gerenciamento de produto de cartão 100 podem visualizar e gerenciar a informação associada a produtos de cartão. 0 sistema de gerenciamento de produto de cartão 100 é configurado para permitir aos usuários efetuar aquelas funções associadas ao gerenciamento de produtos de cartão. Por exemplo, para um "pedido de plástico", os usuários podem pedir os cartões de plástico que são (em última instância) distribuídos para os detentores de cartão, incluindo especificar o projeto ou o layout dos cartões, fornecer mensagens sob medida para aparecer nos cartões, e outros recursos assemelhados dos cartões. Uma vez que o usuário tenha adquirido os cartões de plásticos efetivos através do sistema 100, os cartões podem ser carregados com valor (por exemplo, uma quantia em dólares) , ativado e emitido. Para a ilustração de cartões de presentes, que utilizam uma "emissão instantânea", o cartão individual pode, por exemplo, ser designado um número de cartão, a data de expiração, a quantia carregada, número CW2/CVC2, código de segurança e outra informação identificadora. 0 cartão individual pode então ser registrado utilizando o nome, endereço, número de telefone e assemelhados do detentor do cartão. 0 cartão então está pronto para uso pelo detentor do cartão. Além disso, o "pedido ao atacado" pode ser considerada uma combinação de "pedido de plástico" e "emissão instantânea". Para um pedido ao atacado, os cartões de plásticos são pedidos e podem ser pré-carregados com um valor monetário que pode ser acessado quando da ativação dos cartões. Assim, esses pedidos ao atacado podem permitir ao usuário tanto especificar os valores de carga do cartão por ocasião do pedido e personalizar/ individualizar aqueles cartões para venda ou distribuição.
É observado que qualquer tipo adequado de cartão ou de produtos com base no cartão pode ser ofertado ou de outra forma vendido ou distribuído através do sistema de gerenciamento de produto de cartão 100. Para um tipo particular de produto de cartão, cada um dos cartões individuais do tipo de produto de cartão dado pode ser servido e/ou processado por qualquer um dos processadores de cartão 110. Em outras palavras, um tipo de produto de cartão pode utilizar múltiplos processadores de cartão 110.
Por exemplo, suponha que o emissor de cartão tem um estoque de cartões do tipo de produto de cartão X. Um primeiro pedido de cartões do tipo de produto de cartão X pode ser designado um primeiro BIN ou outro identificador singular a ser servido e/ou processado pelo primeiro processador de cartão 110. 0 segundo pedido de cartões do tipo de produto de cartão X pode ser designado um segundo BIN ou outro identificador singular para ser servido e/ou processado pelo segundo processador de cartão 110. 0 terceiro pedido de cartões do tipo de produto de cartão X pode ser designado um terceiro BIN ou outro identificador singular para ser servido e/ou processado por um processador de cartão 110 particular. Assim, embora cada cartão individual seja servido e/ou processado por um processador de cartão 110 particular, qualquer um dos processadores de cartão 110 pode ser escolhido para servir e/ou processar os cartões de um tipó particular de produto de cartão.
O sistema de gerenciamento de produto de cartão 100 pode permitir ao usuário visualizar pedidos anteriores. Por exemplo, a Figura 5 é um exemplo de uma interface gráfica de usuário GUI 500 para visualizar pedidos através do sistema de gerenciamento de produto de cartão 100, de acordo com uma versão exemplar da presente invenção. Ó GUI 50 0 pode exibir informação adequada para resumir, por exemplo, a totalidade ou os pedidos mais recerites para pedidos de plástico 505, emissões instantâneas 510 e pedidos ao atacado 515. A informação resumida, por exemplo, pode incluir o número do pedido, a data do pedido, ò nome do cliente, o nome do programa, o nome do produto, o estado do pedido, a quantidade total de cartões pedidos, o valor de carga total e qualquer outra informação adequada. Além disso, um campo de busca 520 é configurado para permitir ao usuário pesquisar e filtrar (utilizando algoritmos e técnicas de busca e de filtragem padrão) o histórico de pedidos de acordo com qualquer uma das informações resumidas citadas anteriormente, e incluindo campos adicionais como o número do cliente, o nome do detentor do cartão, o nome da empresa, o telefone da empresa, o número do cartão, ID para fins de imposto, data de nascimento do detentor do cartão, código CEP, código de segurança e assemelhados. Ao utilizar tal busca/filtragem, o usuário pode visualizar qualquer nível desejado de granularidade da informação de produto de cartão, de cartões individuais até pedidos inteiros de cartões através de qualquer um ou da totalidade dos processadores de cartão 110.
O sistema de gerenciamento de produto de cartão 100 também é configurado para gerar relatórios para a informação associada aos produtos de cartão. Por exemplo, o módulo servidor de aplicação do cliente 115 pode formatar os relatórios com base nas solicitações do usuário, que podem então ser exibidas através do GUI pelo módulo de interface gráfico do usuário 130. Qualquer tipo adequado de relatório pode ser fornecido pelo sistema 100 para o usuário incluindo, por exemplo, um resumo de pedido para o usuário, um resumo do total das vendas, um resumo das vendas totais por filial, um resumo dos pedidos de plástico, um resumo do estoque, detalhes do cartão, uma listagem ou resumo de solicitações ACH e assemelhados. De acordo com uma versão exemplar, cada relatório pode ser preenchido com informação de acordo com a identificação do usuário. Em outras palavras, uma vez registrado no sistema 100, a identidade do usuário registrado é conhecida do sistema de gerenciamento de produto de cartão 100 através do nome do usuário e da senha do usuário. Como a identidade do usuário é conhecida, a informação de produto de cartão para aquele usuário pode ser apresentada ou de outra forma exibida para aquele usuário através do GUI, por exemplo, na forma de relatórios. Além disso, como a identidade do usuário é conhecida, o próprio GUI pode ser configurado para exibir outra informação associada ao usuário dado, como, por exemplo, uma lista dos produtos disponíveis para aquele usuário, funções do menu GUI (por exemplo, menus de janela descendente ou instantâneos e sub-menus) que estão disponíveis para aquele usuário, e assemelhados. Por exemplo, produtos de cartão podem ser apresentados ao usuário através do GUI com base na identificação do usuário e a associação ou afiliação do usuário a uma instituição financeira como o processador de cartão 110. Assim, o sistema de gerenciamento de produto de cartão 100 pode personalizar a interface e a informação apresentada a cada usuário (por exemplo, com base na idèntidade do usuário) para melhorar a facilidade de usò e acessibilidade ao sistema 100 e a informação de produto de cartão mantida pelo sistema 100.
Para fins de ilustração e não de limitação, a Figura 6 é um diagrama que ilustra o fluxo de transação para um cartão de presentes emitido por um processador de cartão 110, de acordo com uma versão exémplar da presente invenção. A Figura 6 ilustra a interação entre detentores de cartão, agentes de vendas (por exemplo, aqueles que vendem e distribuem cartões nos pontos de venda) , processadores e o sistema de gerenciamento de produto de cartão 100. No bloco 605, o consumidor adquire um cartão de presentes de um agente de vendas no ponto de venda. No bloco 610, o agente de vendas entra a informação da transação dentro da aplicação com base na Web (por exemplo, o GUI) do sistema de gerenciamento de produto de cartão 100 e transmite os dados de venda para o processador de cartão 110 que emite os cartões de presente dados. No bloco 615, o processador de cartão 110 valida a transação, carrega valor na conta do cartão e ativa o cartão. No bloco 620, o processador de cartão 110 transmite a autorização de volta para o agente de vendas. No bloco 625, o processador de cartão 110 cria e envia arquivos diários para a instituição financeira (por exemplo, um banco ou assemelhado) para o movimento de recursos, incluindo cargas de valor, vendas, e assemelhados. No bloco 630, o agente de vendas dá ao cliente o cartão de presentes (carregado e ativado), revelações de emolumentos apropriados ê acordos de detentores de cartão, recibo e assemelhados. De acordo com uma versão exemplar, essas revelações ao consumidor (impressas) podem ser visualizadas eletronicamente pelo consumidor ou outro usuário através do sistema 110 através do GUI, pois o sistema 100 é configurado para armazenar eletronicamente (por exemplo, no módulo de base de dados 120) essas revelações e outra documentação para acesso pelos usuários.
No bloco 635, o agente de vendas deposita os recebimentos da venda dentro da conta bancária do agente de vendas. No bloco 64 0, o banco ou outra instituição financeira cria um arquivo ACH para acertar com o agente de vendas, e mantém os recursos em prol do detentor do cartão. Após o consumidor receber o cartão de presentes "vivo" no bloco 63 0, então no bloco 64 5 ò consumidor (agora o detentor do cartão) pode utilizar o cartão de imediato para comprar bens e serviços em milhões de localidades em que a marca principal do cartão de presentes for aceita. No bloco 650, o detentor do cartão pode interagir com o sistema de gerenciamento de produto de cartão 100 através do GUI para obter informação do saldo atualizado do cartão (por exemplo, através de uma URL citada nas costas do cartão de presentes). De acordo com uma versão exemplar alternativa, o detentor do cartão pode interagir com o sistema 100 através de um telefone utilizando um sistema de resposta de voz interativa (IVR) adequado ou assemelhado, em vez do GUI.
Com referência à Figura 1, o sistema de gerenciamento de produto de cartão 100 inclui um módulo servidor de aplicação de gerenciamento 125. 0 módulo servidor de aplicação de gerenciamento está em comunicação com o módulo de base de dados 120. De acordo com versões exemplares, o módulo servidor de aplicação de gerericiamento 125 é configurado para gerenciar qualquer um e todos os aspectos do sistema de gerenciamento de produto de cartão 100 e os produtos de cartão mantidos pelo sistema 100. Por exemplo, o módulo servidor de aplicação de gerenciamento 125 é configurado para monitorar a atividade do produto de cartão e fornecer relatórios de vendas e de exceção em base diária. Por exemplo, a atividade de vendas que aparece em múltiplos relatórios de exceção pode ser révista quanto à possível atividade suspeita. Relatórios de exceção podem incluir, por exemplo, transações em dólares altas, verificações de velocidade para as cargas de valor e as transações, créditos ou retornos excessivos, transações no estrangeiro e outras atividades semelhantes que poderão ser suspeitas. Além disso, estruturas de tempo de saldo e de inatividade para cada produto de cartão podem ser monitoradas diariamente pelo módulo servidor de aplicação de gerenciamento 125. Acertos de transações são automatizadas, e os saldos da conta de recursos pode ser monitorada diariamente por adequação pelo módulo servidor de aplicação de gerenciamento 125. 0 módulo servidor de aplicação de gerenciamento 125 é configurado para monitorar qualquer uma e todas as contas de produto de cartão e automatizar o processo de acertos em base de estado para estado. Assim, o módulo servidor de aplicação de gerenciamento 125 pode monitorar, acompanhar e reportar sobre os processadores de cartão 110, usuários, programas, fornecedores, contratos e assemelhados em base diária ou outra base de tempo oportuna.
Administradores e outros usuários apropriados podem acessar e gerenciar o sistema 100 e visualizar a informação associada aos produtos de cartão utilizando o módulo servidor de aplicação dè gerenciamento 125 através de um GUI adequado, como o mesmo ou um GUI diferente fornecido pelo módulo de interface gráfico do usuário 13 0 do módulo de portal do agente 105. De acordo com uma versão exemplar, o GUI para o módulo servidor de aplicação de gerenciamento 125 é um GUI separado que é fornecido por um segundo módulo de interface gráfica de usuário ou assemelhado que é um componente do módulo servidor de aplicação de gerenciamento 125. No entanto, o módulo de interface gráfico de usuário 130 pode fornecer GUIs tanto para o módulo de portal de agente 105 como o módulo servidor de aplicação de gerenciamento 125.
O módulo servidor de aplicação de gerenciamento 125 pode exibir qualquer informação adequada para administradores e outros usuários assemelhados em qualquer formato ou configuração apropriados para gerenciar o sistema de gerenciamento de produto de cartão 100. Por exemplo, a Figura 7 é uma ilustração de uma página de visão geral 700 para o módulo servidor de aplicação de gerenciamento 125, de acordo com uma versão exemplar da presente invenção. A página de visão geral 700 pode fornecer informação de resumo sucinto, por exemplo, contagens dos processadores de cartão 110, de clientes, de programa e de fornecedores por estado, dados de produto de cartão, e decomposição do programa por associação. Por exemplo, a página de visão geral 700 pode exibir um resumo de cartão 705, resumo de estado 710, resumo da data de lançamento do programa 715, e resumo de associação 720. Outra informação assemelhada pode ser exibida na página de visão geral 700 como, por exemplo, um resumo de produto de cartão (por exemplo, o cartão de presentes) ou assemelhados. A página de visão geral 700 é configurada para exibir um menu de nível superior de outras páginas as quais o administrador pode navegar para obter informação mais detalhada, incluindo rótulos para acessar, por exemplo, "Processadores", "Clientes", "Programas", "Fornecedores", "Entidade", "Contatos", "Materiais", "Contratos", "Recursos", "Relatórios", "Ferramentas" e outra informação adequada. Vários desses itens de menu exemplares serão discutidos. Selecionar òs rótulos "Processadores", "Clientes", "Programas" ou "Fornecedores" pode levar ao administrador a uma página de listagem para aquele tipo de entidade. As Figuras 8A, 8B, e 8C ilustram uma página de processador 805, uma página de clientes 810, e uma página de programas 815, respectivamente, de acordo com uma versão exemplar da presente invenção. Cada uma dessas páginas de listagens lista dados como, por exemplo, o nome e dados de resumo relevantes para cada entidade. De acordo com uma versão exemplar, clicar ou de outra forma selecionar o nome da entidade (por exemplo, através de entrada do mouse ou de dispositivo apontador adequado) da lista pode levar ao administrador uma página detalhada para aquela entidade.
Por exemplo, a Figura 9 ilustra uma página de detalhe de cliente 900, de acordo com uma versão exemplar da presente invenção. A página de detalhe do cliente 900 pode ser acessada, por exemplo, ao selecionar o rótulo "Clientes" no mènu de nível superior 730 e o rótulo "Detalhe" 902 ήο sub-menu correspondente. Cada página de detalhe é configurada para fornécer uma visão geral da entidade, e pode ser utilizada para acrescentar e editar dados associados à entidade. Por exemplo, a página de detalhe de cliente 900 pode manter dadós como a informação de detalhe do cliente 905, dados do programa dó cliente 910, planos de projetos do cliente 915, e assemelhados. Outra informação assemelhada pode ser exibida na página de detalhe do cliente 900 incluindo, por exemplo, contatos do cliente (por exemplo, nome, cargo, número de telefone, tipo de contato e assemelhados), contratos do cliente, endereços do cliente, definições da fatura do cliente, relações com o cliente (por exemplo, agentes, co-marcas, distribuidores, localizações, marqueteiros, provedores de serviços e assemelhados) e outra informação adequada, como, por exemplo, localizações do cliente, clientes menores, clientes de comissão e produtos, e assemelhados.
De cada rótulo na página de visão geral 700, o administrador pode "perfurar" para informação mais detalhada associada a cada rótulo. Por exemplo, a Figura 10 ilustra uma página de detalhes de programa 1000, de acordo com uma versão exemplar da presente invenção. Ao selecionar o rótulo "Programas" no menu de nível superior 730, o administrador pode ser apresentado a um sub-menu apropriado 1005 de opções de listagem de páginas para o rótulo dado. Por exemplo, para o rótulo "Programas" 1010, o sub-menu 1005 correspondente pode incluir rótulos adicionais como "Detalhes", "Contatos", "Observações", "Planos de Projetos", "Atributos", "Recursos", "Produtos",
"Contratos", "Relações", "Localizações", "Qualidade" e assemelhados. Ao selecionar o rótulo "Detalhes" 1015 do sub-menu 1005, o administrador pode ser apresentado à página de detalhes de programa 100. A página de detalhes de programa 100 pode exibir qualquer informação de detalhe do programa adequada, còmo, por exemplo, nome, cliente, tipo de programa, associação, processador, estado, e outras informações assemelhadas. O administrador pode utilizar essa página de listagem para acrescentar e editar a informação de programa para uma entidade. Outros rótulos ou itens do sub-menu 1005 podem ser selecionados pelo administrador e a ele exibidos.
Por exemplo, a Figura 11 ilustra uma página de contratos do cliente 1100, de acordo com uma versão exemplar da presente invenção. Ao selecionar o rótulo "Clientes" no menu de nível superior 730, o administrador pode ter a ele apresentado um sub-menu 1102 apropriado de opções de listagem de página para o rótulo dado (que pode ser uma listagem de opções similar ou diferente do sub-menu 1005 ilustrado na Figura 10) . Por exemplo, para o rótulo "Clientes" 1101, o sub-menu 1102 correspondente pode incluir rótulos adicionais como "Detalhe", "Contatos", "Endereços", "Observações", "Planos de Projetos", "Recursos", "Programas". "Contratos", "Relações", "Localidades", "Qualidade" e assemelhados. Ao selecionar o rótulo "Contratos" 1103 do sub-menu 1102, o administrador pode ser apresentado à página de contratos do cliente 1100.
De acordo com uma versão exemplar, o administrador pode fazer uma entrada através do módulo servidor de aplicação de gerenciamento 125 através da página de contratos 1100 quando cada contrato for assinado. A informação gravada na página de contratos 1100 inclui detalhes relevantes e datas associadas ao contrato. Por exemplo, datas de ação 1105 podem ser fornecidas. Um campo de data de aviso 1110 sob as datas de ação 1105 pode ser estabelecido para seis meses (ou outro período de tempo adequado) antes da data de expiração 1115 para permitir a renegociação ou o aviso de terminação. Uma vez atingida a data do aviso, o módulo servidor de aplicação de gerenciamento 125 pode enviar uma correspondência eletrônica ou outra notificação adequada ao usuário listado como o contato de notificação 1120, com essas notificações sendo enviadas diariamente ou periodicamente até medidas apropriadas serem tomadas. Adicionalmente, uma correspondência eletrônica ou outra notificação adequada também pode ser enviada para o departamento de operações ou de pessoal apropriado para notificá-los do novo contrato e orientá-los a entrar com uma definição de balancete para aquele contrato. Outra informação assemelhada pode ser exibida na página de contratos 1100, incluindo, por exemplo, notas de acompanhamento que podem ser acrescentadas ao contrato. Outros rótulos ou itens no sub-menu 1102 podem ser selecionados e exibidos pelo administrador.
Por exemplo, ao selecionar o rótulo "Qualidade" do sub-menu 1102, o administrador pode ser apresentado à página de qualidade do cliente 1200. A Figura 12 ilustra uma página de qualidade de cliente 1200, de acordo com uma versão exemplar da presente invenção. A página de qualidade do cliente 1200 sob o rótulo "Qualidade" 1205 pode exibir informação para o acompanhamento de diligência devida, revisão de qualidade e documentação empresarial apropriada e outra informação assemelhada para o cliente. Por exemplo, a seção de diligência devida 1210 pode ser completada quando a informação sobre a entidade for entrada. A seção de revisão 1215 pode fornecer ao sistema de gerenciamento de produto de cartão 100 uma data pela qual a revisão será necessária com base na classificação de risco do cliente. A seção de acompanhamento 122 0 pode indicar a documentação e outra informação necessária para efetuar a diligência devida, e a data da versão mais recente dessa documentação que está nos arquivos. Um relatório pode ser gerado pelo módulo servidor de aplicação de gerenciamento 125 para acompanhar qual documentação é necessária anualmente (ou outra estrutura de tempo adequada) da entidade.
Voltando às opções de exibir ou listar opções sob o rótulo "Programas 1010 no menu de nível superior 730, a Figura 13 ilustra uma página de planos de projetos de programa 1300, de acordo com uma versão exemplar da presente invenção. A página de planos de projeto 1300 pode ser acessada, por exemplo, ao selecionar o rótulo "Programas" 1010 no menu de nível superior 730 e o rótulo "Planos de Projeto" 1301 no sub-menu 1005 correspondente. A página de plaiios de projeto de programa 1300 pode orientar o administrador através de um processo predefinido para estabelecer um processador de cartão 110 ou programa. A página de planos de programa 1300 pode permitir ao administrador entrar com qualquer nome de tarefa do plano de projeto 1305 adequado correspondente a cada tarefa. Por exemplo, quando um novo plano de projeto for criado, o módulo servidor de aplicação de gerenciamento 125 pode calcular as datas inicial e final 1310 e 1315, respectivamente, para cada nome de tarefa 1305. O administrador também pode entrar com a data inicial e a data final efetivas 1320 e 1325, para cada nome de tarefa 1305. Cada tarefa pode ser desativada se ela não for necessária ao desselecionar de maneira apropriada o nome de tarefa 1305. Observações 1330 podem ser entradas para cada nome de tarefa 1305. O tempo 1335 pode ser acompanhado para cada nome de tarefa 1305, e entradas de tempo faturáveis podem, por exemplo, tornar-se um item de linha no balancete ou fatura do cliente.
Também sob o rótulo "Programas" 1010 no menu de nível superior 730, a Figura 14 ilustra uma página de recursos do programa 14 00, de acordo com uma versão exemplar da presente invenção. A página de recursos 1400 pode ser acessada, por exemplo, selecionando o rótulo "Programas" 1010 no menu de nível superior 730 e o rótulo "Recursos" no sub-menu 1005 correspondente. As opções de recursos do programa 14 05 na página de recursos de programa 1400 pode exibir a data em que o sistema 100 precisará gerar automaticamente os recursos ACH para o programa. Por exemplo, cada transação lançada que está no relatório lançado 300 do processador de cartão 110 pode ser carimbada com um tipo de transação. Quando os recursos de compra são ativados, registros ACH podem ser criados a cada dia (ou periodicamente de maneira adequada) para mover os recursos para um nível de programa de acerto para recursos ou de recursos para acertos com base no sinal da transação. Por exemplo, um recuo de tempo de lançamento 1410 pode informar o sistema 100 para ajustar o tempo da transação por um número de horas (ou outro período de tempo apropriado) de modo que a transação possa ser rolada para o dia comercial apropriado. Outra informação assemelhada pode ser exibida na página de recursos do programa 14 00. Por exemplo, parâmetros de limites FSA podem incluir valores limites e porcentagem de recursos que podem ser utilizados para manter os recursos apropriados na conta. O valor limite pode ser aumentado automaticamente quando mais valor for carregado no programa. Os recursos podem ser renovados periodicamente (por exemplo, diariamente) com base nas compras. Contas bancárias 1430 podem ser designadas para cada tipo de movimento de recurso que estiver por ocorrer na seção opções de recursos 1405. Ainda sob o rótulo "Programas" 1010 no menu de nível superior 73 0, a Figura 15 ilustra uma página de atributos de programa 1500, de acordo com uma versão exemplar da presente invenção. A página de atributos de programa 1500 pode ser acessada, por exemplo, ao selecionar o rótulo "Programas" 1010 no menu de nível superior 730 e o rótulo "Atributos" 1501 no sub-menu 1005 correspondente. A página de atributos de programa 1500 pode permitir aos administradores fixarem valores que podem ser utilizados para gerenciar a funcionalidade do programa. Por exemplo, um administrador pode utilizar esses valores para impor restrições nos produtos de cartão incluindo, por exemplo, a quantia de carga mínima (por exemplo, quantia de carga mínima 15 05 para pedidos instantâneos/personalizados, quantia de carga mínima 1515 para pedidos ao atacado), a quantia de carga máxima (por exemplo quantia de carga máxima 1510 para pedidos instantâneos/personalizados, quantia de carga máxima 1520 para pedidos ao atacado), data de expiração (por exemplo data de expiração 1525 para os pedidos instantâneos/personalizados, data de expiração 153 0 para os pedidos ao atacado), emolumentos do cliente 1535 por produto de cartão (incluindo, por exemplo, emolumentos mínimo e máximo do cliente por produto de cartão 154 0 e 1545, respectivamente), e outros atributos assemelhados. módulo servidor de aplicação de gerenciamento 125 é configurado para exibir vários tipos adequados de relatórios para o administrador ou outros usuários apropriados. A Figura 16 ilustra uma página de relatório de cartão de presentes 1600, de acordo com uma versão exemplar da presente invenção. Ao selecionar o rótulo "Relatórios" 1610 no menu de nível superior 730, o administrador pode ser apresentado ao sub-menu apropriado 1615 de opções de relatórios para o rótulo dado. Por exemplo, para o rótulo "Relatórios" 1610, o sub-menu 1615 correspondente pode incluir rótulos adicionais como "Arquivos", "Financeiro", "Exceção", "Balancetes", "Acompanhamento do tempo", "Tradução NCR", "Cartão de Presente", "Qualidade", "Serviços ao cliente", "Desenvolvimento", e outros relatórios assemelhados. Para fins de ilustração e não de limitação, ao selecionar o rótulo de cartão de presentes 1620 do sub-menu 1615, o administrador pode visualizar ou gerar vários tipos de relatórios para cartões de presentes (ou outros produtos de cartão) e ferramentas de suporte, incluindo, por exemplo, fluxo de trabalho de cartão de presente 1625 (por exemplo, filas de trabalho, inscrições, pedidos pendentes de recursos, pedidos aguardando números de cartão, pedidos prontos para gravação em alto relevo, pedidos aguardando ativação e assemelhados) , relatórios 1630 (por exemplo, entradas de cliente de comissão, resumo de comissão a pagar, rolagem de relatório de programa, exceções de recursos de pedidos, resumo de cliente de processador, lista mestre de clientes, estoque de plástico, cartões perdidos/roubados, cartõès "com dinheiro esgotado", visão geral de pedidos completados, grupo de número de cartão disponível, resumo de pedidos por estado e outros relatórios assemelhados) e ferramentas de cartões de presentes 1635 (por exemplo, consulta de cartão e assemelhados). Por exemplo, uma página de relatório de resumo de pedidos de cartões de presentes pode exibir uma listagem resumida (por exemplo, por dia, semana, mês, ou assemelhado) de qualquer um ou de todos os pedidos de cartões de presentes, incluindo informação como número do pedido, data do pedido, tipo de pedido, estado do pedido, cliente, quantidade, quantia da carga total, emolumentos de plástico, ajustes, quantia total, e outra informação assemelhada.
Continuando com a presente ilustração, com relação aos tipos exemplares de relatórios que podem ser visualizados para os cartões de presentes (ou outros produtos de cartão) da pagina de relatório de cartão de presente 1600, a Figura 17 ilustra uma página de relatório de fila de trabalho 1700 selecionada da lista dò fluxo de trabalho de cartão de presente 1625, de acordo com uma versão exemplar da presente invenção. O administrador pode utilizar a página de relatório de fila de trabalho 1700, por exemplo, para aprovar, negar, mover e monitorar inscrições, pedidos ao atacado e de plástico e assemelhados, para, por exemplo, um cartão de presente ou outro programa produto de cartão adequado. Alguns dos tipos de informação que podem ser visualizados na página de relatório de fila de trabalho 1700 inclui inscrições 1705. Por exemplo, inscrições online podem ser completadas pelos agentes de vènda para cada novo cliente de produto de cartão, que pode iniciar o contrato apropriado, estabelecimento de diligência devida e de programa pelo sistema de gerenciamento de produto de cartão 100. Pedidos pendentes de recursos 1710 podem exibir aqueles pedidos que precisam ter os recursos verificados e/ou aprovados. Pedidos com recursos aguardando números de cartão 1715 podem apresentar uma lista dos pedidos que precisam da criação e da designação de números de cartão (por exemplo, na maneira descrita anteriormente para alocar e designar números de cartão). Pedidos com recursos aguardando gravação em alto relevo 1720 inclui uma tela dos pedidos que precisam ser enviados para o gravador. Pedidos aguardando o arquivo de retorno do gravador 1725 pôde listar os pedidos no gravador que precisam de um arquivo de resultado ou assemelhado para ser processado. Outra informação adequada pode ser exibida na página de relatório de fila de trabalho 1700 incluindo, por exemplo, pedidos ao atacado aguardando a solicitação de ativação do cliente 1727 (por exemplo, uma lista dos pedidos a caminho do cliente que estão aguardando que o cliente inicie a ativação e a carga do produto de cartão), pedidos aguardando ativação pelo sistema 100 (por exemplo, uma lista dos pedidos que foram recebidos do cliente e que o cliente solicitou ativação e carga do produto de cartão) e outra informação assemelhada. Também é observado que uma faixa de números de cartões disponíveis de acordo com versões exemplares pode ser exibida nos pedidos com recursos aguardando números de cartão 1715, por exemplo, fornecendo os números de cartão inicial 1730 e final 1735 (por exemplo, em que os primeiros seis dígitos de um número de produto de cartão compreende um BIN, e os dez dígitos restantes - 0000000000 a 9999999999 - estão disponíveis para alocação de número de cartão.
A Figura 18 ilustra uma página de relatório de resumo de comissão a pagar 1800, de acordo com uma versão exemplar da presente invenção. A página de relatório de resumo de comissão a pagar 1800 pode ser acessada da seção de relatórios 163 0 da página de relatório de cartão de presentes 1600. Por exemplo, o resumo de comissão a pagar de cartões de presentes 1805 pode exibir e acompanhar qualquer uma ou todas as comissões pagas ao nível de tipo de pedido ou assemelhado. De acordo com uma versão exemplar, a entrada de comissão pode ser gerada automaticamente para o agente de vendas quando uma inscrição é aprovada pelo sistema 100. Comissões podem ser enviadas através de ACH ou outro meio adequado para a transferência de recursos eletrônicos para o agente de vendas. O administrador pode filtrar a informação exibida no resumo de comissão a pagar de cartões de presentes 1805 ao entrar com critérios de relatório apropriados na seção de critérios de filtragem de relatório 1810 para visualizar qualquer subconjunto adicional ou alternativo adequado do resumo da comissão a pagar de cartões de presentes 18 05.
Outros relatórios podem ser gerados e visualizados ao selecionar o rótulo ou item de menu apropriado do rótulo "Relatórios" 1610, como a listagem de "Arquivos". Por exemplo, a Figura 19 ilustra uma página de arquivos de relatório 1900 de acordo com uma versão exemplar da presente invenção. A página de arquivos de relatório 1900 é acessada ao selecionar o rótulo Arquivos 1905. Como foi discutido anteriormente, o sistema 100 pode receber qualquer número adequado de relatórios de cada processador de cartão 110, incluindo, sem a eles se limitar, por exemplo, um relatório geral ou não financeiro 200, um relatório lançado 300 e um relatório de autorização 400. Esses dados podem ser carregados dentro de um depósito central (por exemplo, módulo de base de dados 120) e cada transação listada nos relatórios pode ser carimbada com um código de transação comum e tipo de produto definido pelo sistema 100. O estado de cada arquivo de relatório pode ser monitorado durante o processo de carregamento utilizando a página de arquivos de relatório 1900. Para cada processador de cartão 110, a página de arquivos de relatório 1900 pode listar se cada um do relatório geral 200, do relatório lançado 300 e do relatório de autorização 400 foi recebido 1910, processado 1915 e/ou carregado 1920. Como foi observado acima, dados nos relatórios podem ser validados contra, por exemplo, uma matriz de tradução para cada processador de cartão 110 que é definido pelo processador de cartão 110 e pelo sistema 100 durante o estabelecimento do processador. Qualquer erro encontrado em qualquer um dos relatórios pode ser pesquisado e corrigido antes dos dados serem aceitos. Uma vez a totalidade dos dados é carregada com sucesso dentro do módulo de base de dados 120, o sistema 100 pode iniciar solicitações ACH ou outros procedimentos de transferência de recursos similar para o movimento de recursos periódico (por exemplo, diário). O administrador pode filtrar a informação exibida na página de arquivos de relatório 1900 ao entrar com critérios de relatório apropriados na seção de critérios de filtragem de relatório 1925 para visualizar qualquer subconjunto adicional ou alternativo adequado da informação de arquivos de relatório. Assim, o sistema de gerenciamento de produto de cartão 100 pode relatar dados coletados através de qualquer combinação de programas, de clientes, de processadores, de associações, de tipos de transação, e assemelhados.
Para monitorar o movimento dos recursos, o administrador pode selecionar ura rótulo "Financeiro" sob o rótulo "Relatórios" 1610. A Figura 20 ilustra uma página de relatório financeiro 2000, de acordo com uma versão exemplar da presente invenção. A página de relatório financeiro 2000 é acessada ao selecionar o rotulo financeiro 2005 no sub-menu 1605. O movimento de recursos pode ter por base regras de recursos definidas por ocasião do estabelecimento do programa e os dados de transação periódicos (por exemplo, diários). Solicitações ACH ou outras solicitações de transferência de recursos adequada podem ter por base, por exemplo, movimentos de dinheiro no agregado para cada programa por tipo de transação e sinal. O modulo servidor de aplicação de gerenciamento 125 pode reconciliar as quantias ACH solicitadas contra as quantias calculadas e discrepâncias do relatório. Adicionalmente, o módulo servidor de aplicação de gerenciamento 125 é configurado para reconhecer transações pré- e pós-datadas, e pode iniciar solicitações ACH ou outras solicitações de transferência de recursos adequadas de acordo. Assim, a página de relatório financeiro 2000 pode exibir informação para o administrador ou outro usuário apropriado para cada processador de cartão 110, como, por exemplo, data de acerto, tipo de transação, sinal da transação (por exemplo, indicando crédito ou débito) , o tipo de conta de e para recursos que será transferida, quantia da transferência, quantia ACH, estado da transferência e outra informação adequada. O administrador pode filtrar a informação exibida na página de relatório financeiro 2000 ao entrar com critérios de relatório apropriados na seção de critérios de filtragem do relatório 2010 para visualizar qualquèr subconjunto adicional ou alternativo da informação financeira.
Adicionalmente, a página de relatório financeiro 2000 pode exibir uma listagem de reconciliações de conta e outra informação similar. A Figura 21 ilustra uma página de relatório de reconciliação de contas 2100 de acordo com uma versão exemplar da presente invenção. Periodicamente (por exemplo, a cada dia), o sistema 100 pode carregar atividade de contas diárias ou periódicas GL (Livro Razão) e DDA (Conta Depósito de Demanda) e outra informação adequada. 0 módulo servidor de aplicação de gerenciamento 125 é configurado para reconciliar sistematicamente cada transação contra a solicitação ACH original criada pelo processo de movimento de recursos diário ou periódico. O administrador pode revisar essa informação e fazer entradas de reconciliação manual quando necessário, e entradas sistêmicas podem ser editadas pelo administrador, se necessário. Novamente, o administrador pode filtrar a informação exibida na página de reconciliação de contas 2100 ao entrar critérios de relatório apropriados na seção de critérios de filtragem de relatório 2110 para visualizar qualquer subconjunto adicional ou alternativo adequado da informação de reconciliação de contas.
Para cada processador de cartão 110 ou outro cliente, freguês ou usuário, o sistema de gerenciamento de produto de cartão 100 pode gerar balancetes ou faturas apropriados para produtos de cartão comprados utilizando o sistema 100. A Figura 22 ilustra o balancete 2200 gerado pelo sistema de gerenciamento de produto de cartão 100, de acordo com uma versão exemplar da presente invenção. O balancete 2200 pode ser gerado automaticamente com base em definições do balancete. Esses balancetes 2200 podem ser no modo rascunho até todos os substancialmente todos os dados estarem completos. Qualquer dado do balancete que não pode ser criado automaticamente pode colocar o balancete em estado de "aprovação pendente" ou assemelhado, e o administrador pode entrar manualmente com qualquer dado de balancete que não poderia ser criado automaticamente. 0 balancete 2200 pode fornecer ao cliente uma listagem ou fatura adequado das compras que exigem pagamento pelo cliente, incluindo a decomposição de compras individuais e totais de compras, e quantias totais devidas.
Como foi discutido anteriormente, os balancetes 2200 podem ser gerados com base em definições de balancete. A Figura 23 ilustra uma página de relatório de definição de balancete 23 00, de acordo com uma versão exemplar da presente invenção. A página de relatório de definição de balancete 2300 pode ser acessada ao selecionar, por exemplo, o rótulo balancete 23 05 no sub-menu 1615 sob o rótulo "Relatórios" 1610 no menu de nível superior 730. Definições de balancete podem ser estabelecidas com base nas regras especificadas, por exemplo, no contrato ou outro acordo de obrigações com o processador de cartão 110. O balancete (por exemplo, o balancete 22 00) pode ser criado no dia e/ou hora apropriados com base na programação estabelecida em contrato. O módulo servidor de aplicação de gerenciamento 125 pode ser configurado para limitar as mudanças que possam ocorrer a uma definição uma vez tenha sido criado o balancete (por exemplo, através de regras, restrições e recursos de segurança apropriados). Além disso, o módulo servidor de aplicação de gerenciamento 125 é configurado para permitir ao administrador acrescentar manualmente entradas de uma-vez-só a um balancete. A página de relatório de definição de balancete 2300 pode incluir qualquer informação adequada para gerar balancetes, como, por exemplo, detalhes do cliente (por exemplo, endereços do cliente 2310), detalhes da definição do balancete 2315, detalhes do grupo de item de linha 2320, detalhes de definição do item de linha 2325, detalhes do parâmetro de item de linha 2330 e outra informação assemelhada.
0 módulo servidor de aplicação de gerenciamento 125 também é configurado para fornecer extensas ferramentas de relatórios de exceção. A Figura 24 ilustra uma página de relatório de exceção 24 00, de acordo com uma versão exemplar da presente invenção. A página de relatório de exceção 24 00 pode ser acessada ao selecionar, por exemplo, o rótulo exceção 24 05 no sub-menu 1615 sob o rótulo "Relatórios" 1610 do menu de nível superior 730. De acordo com uma versão exemplar, em base periódica, exceções ao nível de produto de cartão podem ser reportadas utilizando filtros apropriados para filtragem (por exemplo, com base em regras predefinidas ou outros parâmetros de filtragem adequados). Exemplos desses relatórios de exceção disponíveis incluem, por exemplo: "Gerar Exceções" (por exemplo, sinalizar exceções a gerar para uma determinada data); "Resumo de Exceção" (por exemplo, um resumo de qualquer uma ou todas as exceções por número de cartão ou de conta); "Sinal de Mudança de Saldo do Cartão" (por exemplo, cartões de débito e assemelhados que tinham um saldo negativo, e que agora ficaram positivos, e vice versa para cartões de crédito e assemelhados); "Saldos de Créditos"; "AutoriSzações excessivas" (por exemplo, produtos de cartão com um número excessivo de autorizações por dia); "Emolumentos Excessivos" (por exemplo, produtos de cartão com emolumentos excessivos por dia); "Retornos Excessivos" (por exemplo, produtos de cartão com retornos excessivos por dia); "Transações Estrangeiras" (por exemplo, produtos de cartão com transações estrangeiras) ; "Transações Altas ém Dólares" (por exemplo, produtos de cartão com altas transações em dólar por dia) ; "MCC de Alto Risco" (por exemplo, produtos de cartão sinalizados com transações MCC de alto risco) ; "Cargas de Alto Valor" (por exemplo, produtos de cartão sinalizados com transações de alto valor de carga); "Saldos Negativos"; "Saldos Negativos (30 dias)"; "Saldos Negativos (60 dias)"; "Saldos Negativos (90 dias)"; "Fora do Balanço"; "Verificações de Velocidade"; e qualquer outro relatório de exceção adequado. Ao selecionar qualquer uma dessas entradas, o administrador pode visualizar os detalhes do relatório de exceção escolhido.
Por exemplo, as Figuras 25A e 25B ilustram páginas de relatório de detalhe de exceção, de acordo com uma versão exemplar da presente invenção. Como é ilustrado na Figura 25A, a página de resumo MCC de alto risco 25Ô5 pode listar um resumo dos cartões sinalizados com transações MCC de alto risco por programa, incluindo itens como o nome do programa, BIN, número das contas, e quantias em dólares da transação não revisada, revisada e alertada, bem como outra informação de resumo adequada. Como é ilustrado na Figura 25B, a página de detalhe MCC de alto risco 2510 pode apresentar uma tela dos detalhes de produtos de cartão com transações MCC de alto risco para o dia por programa, incluindo itens similares ou diferentes daqueles listados na página de resumo MCC de alto risco 2505. As exceções podem ser construídas do detalhe de transação diária ou periódica que pode ser fornecida nos relatórios (por exemplo, relatório gèral 200, relatório lançâdo 3 00 e relatório de autorização 4 00 ou qualquer õutro relatório adequado)) recebidos dos processadores de cartão 110. As exceções podem ser marcadas, por exemplo, como não revistas, revistas òu alertadas, conforme está ilustrado nas páginas do relatório de detalhe de exceção exemplar das Figuras 25A e 25B. Um histórico de exceção pode ser mantido (por exemplo, no módulo de base de dados 120) para fins de pesquisa e de relatórios. Como còm outras páginas de relatórios, o administrador pode filtrar a informação exibida nas páginas de relatórios de exceção ao entrar com critérios de relatório apropriados nas respectivas seções de critérios de filtro de relatório (por exemplo, seção 2515 da página de resumo MCC de alto risco 2505 e/ou seção 2520 da página de detalhe MCC de alto risco 2510) para visualizar qualquer subconjunto adicional óu alternativo adequado da informação de exceção detalhada.
O módulo servidor de aplicação de gerenciamento 125 pode fornecer ao administrador ou outro usuário apropriado qualquer relatório financeiro adequado com base na informação associada aos produtos de cartão. Por exemplo, a Figura 26 ilustra uma página de relatórios financeiros 26 00, de acordo com uma versão exemplar da presente invenção. A página de relatórios financeiros 2600 pode ser alcançada ao selecionar, por exemplo, o rótulo "Financeiro" 2005 no sub-menu 1615 sob o rótulo "Relatórios" 1610 do menu de nível superior 73Ô. Comò é ilustrado na Figura 26, os relatórios financeiros podem ser agrupados, por exemplo, como relatórios com base em pasta 2605, relatórios DDA 2610, relatórios GL 2615 e relatórios com base em cartões 2620. Exemplos de relatórios financeiros disponíveis incluem, por exemplo: "Saldos Diários" (por exemplo, saldos diários por programa); "Saldos DDA de Conta Bancária
Diário"; "Saldos GL de Conta Bancária Diário (Confidencial)"; "Reconciliações de Conta Bancária Diária"; "Transações Não Lançadas" (por exemplo, contas de recursos diários/transações não lançadas"; "Relatório de Acertos" (por exemplo, contas de recursos diários/transações não lançadas); Relatório de Acertos" (por exemplo, recursos de conta de acertos); "Visão Geral da Pasta" (por exemplo, visão geral da pasta atual/resumo de cartão); "Saldos Negativos de 0/30 Dias"; Movimento de Recursos Diário" (por exemplo, dados MIS para uma faixa de data conhecida) ;
"Freqüência de Estado" (por exemplo, número de cartões por estado/tipo de programa); "Não Financeiro Faltante" (por exemplo, transações sem informação nãõ financeira); "Perdido/Roubado (Últimos Sete Dias)" (por exemplo, cartões sinalizados como perdidos/roubados dentro dos últimos sete dias); "Detalhe de Transação de Cartão" (por exemplo, detalhes de cartão e histórico de autorização/lançamento) ; "Resumo de Programa de Cartão de Presente" (por exemplo, detalhes e autorização/histórico lançado); "Resumo de Programa de Cartão de Presente"; "Financiamento ACH de Cartão de Presente" (por exemplo, financiamento de produto de cartão diário); "Registro de Arquivo ACH" (por exemplo, arquivos ACH de cliente/trilha de auditoria); "Fila ACH" (solicitações/fila ACH) ; e qualquer outro relatório financeiro adequado. Ao selecionar qualquer uma dessas entradas sob o grupo de relatórios apropriado, o administrador pode visualizar os detalhes do relatório financeiro escolhido. Qualquer um ou a totalidade dos relatórios financeiros pode ter faixa e outros filtros específicos do relatório de modo que os dados podem ser gerados em um ponto no tempo em muitas visões diferentes. Para gerar esses relatórios financeiros, a base de dados (por exemplo, o módulo de base de dados 120) não pode construir dos arquivos de relatórios diários ou periódicos (por exemplo, relatório geral 200, relatório lançado 300 e relatório de autorização 400) dos processadores de cartão 110. Quaisquer características de tipos, ordenação, agrupamento adequados e outras características semelhantes dos relatórios financeiros pode ser exibida e estar disponível ao usuário através da página de relatórios financeiros 2600.
As Figuras 27A e 27B ilustram páginas de relatório financeiro, de acordo com uma versão exemplar da presente invenção. Como é ilustrado na Figura 27A, a página de resumo não lançado 2705 pode listar as contas de recursos diários e as transações não lançadas. Por exemplo, o módulo servidor de aplicação de gerenciamento 125 pode tomar o saldo de cartão agregado menos as cargas de valor, e subtrair o gasto e os emolumentos de detentores de cartão para os dois ou quatro dias anteriores (ou qualquer espaço de tempo adequado) para gerar um saldo calculado, que deve ser inferior ao saldo da conta de recursos também listada na página de resumo não lançada 2705. Como é ilustrado na Figura 27B, a página de resumo de acertos 2710 pode exibir recursos da conta de acertos. Por exemplo, o módulo servidor de aplicação de gerenciamento 125 pode tomar o saldo da conta de acertos para o período de tempo selecionado (por exemplo, dia) e acrescentar o acerto pago para os últimos dois dias para gerar um saldo ajustado. Como com outras páginas exibidas, o administrador pode filtrar a informação exibida nas páginas de relatórios financeiros ao entrar critérios de relatório apropriados nas respectivas seções de critérios de filtro de relatório (por exemplo, seção 2715 da página de resumo não lançado 2705 e/ou seção 2720 da página de resumo de acertos 2710) para visualizar qualquer subconjunto adicional ou alternativo da informação financeira detalhada.
O módulo servidor de aplicação de gerenciamento 125 pode exibir qualquer outro relatório ou informação adequada através do GUI associado. Como foi discutido anteriormente, o módulo servidor de aplicação de cliente 115 pode ser configurado para alocar e designar números de cartão correspondentes a cada BIN (ou outro identificador singular) para os produtos de cartão. De acordo com versões exemplares, o sistema 100 pôde ser configurado para exibir um resumo (por exemplo, um resumo de distribuição) de números de cartão para cada BIN através de um GUI, como o GUI utilizado para o módulo servidor de aplicação de gerenciamento 125. Por exemplo, a Figura 28 ilustra uma página de resumo de número de cartão 2800, de acordo com uma versão exemplar da presente invenção. A página de resumo de número de cartão 28 00 pode ser alcançada ao selecionar, por exemplo, o rótulo "Cartão de Presentes" (ou um "Produto de Cartão" adequado) 1620 no sub-menu 1615 sob o rótulo "Relatórios" 1610 no menu de nível superior 730.
Por exemplo, a página de resumo de número de cartão 2800 pode exibir a contagem do número "Disponível" de cartão por BIN (por exemplo, em que, meramente para fins de ilustração, os últimos seis dígitos de cada um dos números listados na linha "Estado do Cartão" pode compreender um BIN ou outro identificador singular). Outra informação de resumo de número de cartão pode ser exibida ao usuário na página de resumo de número de cartão 2800, incluindo, por exemplo, a contagem de cartões "Despachados", "Ativados", "Ativados e Carregados" e "Destruídos" e/ou números de cartões por BIN e outra informação assemelhada. Além disso, o sistema 100 pode ser configurado para exibir uma lista de números de cartão disponíveis para cada BIN através do GUI para gerenciar os produtos de cartão através dos processadores de cartão 110, embora esse recurso possa ser desativado pelo sistema 100 para fins de segurança quando apropriado.
Embora o sistema de gerenciamento de produto de cartão 100 pode ser utilizado para gerenciar informação associada a cartões e produtos de cartão, o sistema 100 pode ser utilizado para gerenciar informação financeira e conduzir tipos adequados de transações financeiras, como, por exemplo, transmissões de dinheiro ou transferências e assemelhados, quer com ou sem a utilização de um produto de cartão acompanhante. Por exemplo, um usuário local pode solicitar que uma instituição financeira local (por exemplo, um banco) transfira ou de outra forma transmita uma soma de dinheiro para um indivíduo em uma localização remota (por exemplo, outro banco ou varejo em outro país) utilizando o sistema 100. A instituição financeira local pode acessar o sistema 100 para efetuar a transferência monetária (por exemplo, transferir o dinheiro de uma conta de usuário para outra, de um processador de cartão 110 para outro, de uma instituição financeira para outra, ou outra transação semelhante). O indivíduo na localização remota pode então ir ao banco remoto que recebeu a transferência monetária, e apresentar uma identificação apropriada para o banco remoto. A identidade do indivíduo pode ser verificada pelo banco remoto utilizando o sistema 100 (por exemplo, o nome, endereço e, por exemplo, o número de identificação pessoal (PIN) pode corresponder a registros mantidos no sistema 100 para a transmissão do dinheiro) . Uma vez verificado, o indivíduo pode receber o dinheiro transferido. O sistema de gerenciamento de produto de cartão 100 pode ser utilizado para ouras transações financeiras desse tipo, como, por exemplo, contas de "passe de pagamento", contas biométricas e assemelhadas, quer com ou sem a utilização de um cartão ou produto de cartão.
O sistema de gerenciamento de produto de cartão 100 é configurado para se enquadrar com todas as leis e regulamentos aplicáveis federais e estaduais, incluindo leis estaduais que limitam emolumentos e datas de expiração, leis de revelação estadual, leis estaduais que exigem o repagamento de pequenos saldos no ponto de venda, leis de licenciamento do transmissor de dinheiro no estado, leis de propriedade abandonada estadual, e assemelhados. Cada um dos módulos do sistema de gerenciamento de produto de cartão 100, incluindo o módulo de portal de agente 105, o módulo servidor de aplicação do cliente 115, o módulo servidor de aplicação de gerenciamento 125, e o módulo de interface gráfica do usuário 130, ou qualquer combinação destes, pode ser compreendido de qualquer tipo adequado de componente ou dispositivo elétrico ou eletrônico que seja capaz de efetuar as funções associadas ao elemento respectivo. De acordo com essa versão exemplar, cada componente ou dispositivo pode estar em comunicação com outro componente ou dispositivo utilizando qualquer tipo apropriado de conexão elétrica que seja capaz de portar informação elétrica. Alternativamente, cada um dos módulos do sistema de gerenciamento de produto de cartão 100 pode ser compreendido de qualquer combinação de hardware, firmware e de software que seja capaz de efetuar as funções associadas ao módulo respectivo.
Alternativamente, o sistema de gerenciamento de produto de cartão 100 pode ser compreendido de um ou mais microprocessadores e memórias associadas que armazenam as etapas de um programa de computador para efetuar as funções dos módulos do sistema 100. O microprocessador pode ser qualquer tipo adequado de processador, còmo, por exemplo, qualquer tipo de microprocessador de finalidade geral ou microcontroladora, um processador de processamento de sinal digital (DSP), um circuito integrado específico da aplicação (ASIC), uma memória de apenas leitura programável (PROM), uma memória de apenas leitura programável apagável (EPROM), uma memória de apenas leitura programável e eletricamente apagável (EEPROM), um meio lido por computador, ou assemelhado. A memória pode ser qualquer tipo adequado de memória de computador ou qualquer outro tipo de meio de armazenamento eletrônico, como, por exemplo, memória de apenas leitura (ROM), memória de acesso aleatório (RAM), memória cachê, memória de apenas leitura de disco compacto (CDROM), memória eletro-óptica, memória magneto-óptica, ou assemelhados. Como será apreciado com base na descrição que antecede, a memória pode ser programada utilizando técnicas convencionais conhecidas daqueles dotados de habilidade ordinária na tecnologia de programação de computador. Por exemplo, o código fonte efetivo ou código objeto do programa de computador pode ser armazenado na memória. Por exemplo, de acordo com uma versão exemplar, o módulo de portal de agente 105 e o módulo servidor de aplicação de gerenciamento 125 podem, cada um, ser implementado utilizando um servidor WINDOWS™ (por exemplo, servidor WINDOWS™ 2003 ou servidor XP) processando em um PC equipado adequadamente, ou outra arquitetura de computador ou sistemas de computador (por exemplo, servidores HEWLETT-PACKARD™). De acordo com uma versão exemplar, o módulo de base de dados 120 pode ser implementado utilizando um servidor SQL e a base de dados SQL correspondente.
O sistema de gerenciamento de produto de cartão 100 pode incluir outros módulos e componentes adequados (quer implementados em hardware, software, firmware ou qualquer combinação deles) para uso no gerenciamento do sistema 100, incluindo módulos de diários, módulos de erro, módulos de segurança, e assemelhados. Por exemplo, o sistema 100 pode incluir uma primeira parede de fogo 150 adequada localizada entre os processadores de cartão 110 e o módulo de portal de agente 105 para impedir qualquer intrusão maliciosa ou ataques de computador no sistema 100. Uma segunda parede de fogo 155 adequada pode estar localizada entre o módulo de portal de agente 105 e a combinação do módulo de base de dados 120 e o módulo servidor de aplicação de gerenciamento 125 para impedir o acesso irrestrito do usuário ao módulo servidor de aplicação de gerenciamento 125 e à informação armazenada e mantida no módulo de armazenamento 120.
A Figura 29 é um fluxograma que ilustra etapas para gerenciar a informação de produto de cartão, de acordo com uma versão exemplar da presente invenção. Cada um da pluralidade de processadores de cartão são interfaceados na etapa 2905. Na etapa 2910, um da pluralidade de processadores de cartão é selecionada de acordo com um identificador singular associado a um produto de cartão para processar a informação associada ao produto de cartão. Na etapa 2 915, a informação associada a produtos de cartão é gerenciada para a pluralidade de processadores de cartão.
Na etapa 2920, mensagens para comunicação a um processador de cartão respectivo são transformadas em um formato utilizado pelo processador de cartão respectivo. Na etapa 2925, a informação associada a produtos de cartão é recebida de cada um dos processadores de cartão. De acordo com uma versão exemplar, a informação de cada processador de cartão compreende uma pluralidade de relatórios. Por exemplo, a pluralidade de relatórios pode incluir pelo menos de um relatório geral, um relatório lançado, e um relatório de autorização. Na etapa 2930, a informação de cada um dos processadores de cartão é normalizada para transformar a informação em um formato uniforme. Na etapa 2935, a informação transformada é validada para assegurar a precisão da informação. Na etapa 2940, relatórios podem ser gerados para a informação associada aos produtos de cartão.
Por exemplo, cada relatório pode ser preenchido com informação de acordo com a identificação do usuário.
Além disso, de acordo com versões exemplares, a informação associada a produtos de cartão pode ser armazenada. Os usuários podem obter acesso para gerenciar a informação associada a produtos de cartão. Por exemplo, uma interface gráfica de usuário pode ser exibida através da qual os usuários acessam a informação associada aos produtos de cartão. De acordo com uma versão exemplar, acesso pode ser concedido ao usuário através da interface gráfica do usuário utilizando uma senha e um endereço de rede de computador do usuário associado. Uma vez concedido o acesso, produtos podem ser apresentados ou de outra forma exibidos ao usuário através da interface gráfica do usuário de acordo com pelo menos um de identificação do usuário e de associação a uma instituição financeira. Por exemplo, um tema da interface gráfica de usuário pode ser associado a cada processador de cartão. Cada processador de cartão pode ser apresentado com o tema associado ao processador de cartão quando da interação através da interface gráfica do usuário.
De acordo com uma versão exemplar da presente invenção, os processadores de cartão são configurados para associar BINS correspondentes aos produtos de cartão. Números de cartão podem ser alocados correspondentes a cada BIN para os produtos de cartão. Um resumo dos números de cartão para cada BIN pode ser exibido. Cada produto de cartão pode compreender um número de produto de cartão. 0 número de produto de cartão pode compreender uma primeira parte de dígitos e uma segunda parte de dígitos. A primeira parte dos dígitos compreende um BIN. Os processadores de cartão são configurados para associar BINs aos produtos de cartão. Números de cartão podem então ser alocados a substancialmente toda a segunda parte de dígitos para cada BIN.
A Figura 30 é um fluxograma que ilustra as etapas para detectar adulteração com a informação comunicada a um processador de cartão, de acordo còm uma versão exemplar da presente invenção. Mensagens aos processadores de cartão podem incluir uma consulta que compreende um endereço de rede de computador de um arquivo ou assemelhado. Na etapa 30305, o endereço de rede de computador pode ser criptografado. Por exemplo, uma função hash criptográfica ou outra técnica de criptografia semelhante pode ser utilizada para criptografar o endereço de rede de computador. Na etapa 3010, o endereço de rede de computador criptografado pode ser apensado ao final da consulta. Na etapa 3 015, adulteração com o endereço de rede de computador pode ser detectada ao comparar o endereço de rede de computador com a descriptografação do endereço de rede de computador criptografado. Alternativamente, na etapa 3020, a adulteração nò endereço de rede de computador pode ser detectada ao comparar o endereço de rede de computador criptografado e uma re-criptografação do endereço de rede de computador.
A Figura 31 é um fluxograma que ilustra as etapas para processar produtos de cartão, de acordo com uma versão exemplar da presente invenção. Na etapa 3105, um BIN pode ser associado a cada um da pluralidade de produtos de cartão por um processador de cartão. Cada produto de cartão pode compreender um número de produto de cartão. O número de produto de cartão pode compreender uma primeira parte de dígitos e uma segunda parte de dígitos. A primeira parte de dígitos pode compreender o BIN. Na etapa 3110, valores podem ser designados a substancialmente toda a segunda parte de dígitos de cada produto de cartão por um não processador. O não processador é configurado para gerenciar a informação associada à pluralidade de produtos de cartão. Os valores designados a substancialmente toda a segunda parte de dígitos de cada produto de cartão pode compreender um número de cartão. Os números de cartão podem ser alocados para cada BIN pelo não processador. Por exemplo, números de cartão podem ser alocados seqüencialmente para cada BIN. Alternativamente, números de cartão podem ser alocados aleatoriamente para cada BIN. Os valores designados a substancialmente toda a segunda parte de dígitos de cada produto de cartão pode corresponder a usuários separados.
Qualquer uma ou todas as etapas de um programa de computador conforme ilustrado nas Figuras 29 a 31 pode ser incorporada em qualquer meio lido por computador para uso ou em conexão com um sistema ou dispositivo de execução de instrução, como um sistema com base em computador, um sistema contendo processador, ou outro sistema que possa apanhar as instruções do sistema, aparelho ou dispositivo de execução de instrução e executar as instruções. Como é aqui utilizado, o "meio lido por computador" pode ser qualquer meio que possa conter, armazenar, comunicar, propagar, ou transportar o programa para uso pelo ou em conexão com o sistema, aparelho ou dispositivo de execução de instrução. Por exemplo, o meio lido por computador pode ser, mas não é limitado a, um aparelho, dispositivo ou meio de programação eletrônico, magnético, óptico, eletromagnético, infravermelho, ou semicondutor. Exemplos mais específicos (uma lista não abrangente) do meio lido por computador pode incluir o seguinte: uma conexão elétrica tendo um ou mais fios, um disquete de computador portátil, uma memória de acesso aleatório (RAM), uma memória apenas de leitura (ROM) , uma memória de apenas leitura programável e apagável (EPROM ou memória Flash) , uma fibra óptica, e uma memória de apenas leitura em disco compacto portátil (CDROM).
Versões exemplares da presente invenção podem ser utilizadas em conjunto com qualquer dispositivo, sistema, processo ou transação que processe a informação de produto de cartão. Versões exemplares podem ser utilizadas pelas instituições financeiras como parte de programas de produto de cartão recarregáveis ou não recarregáveis para acessar, administrar e gerenciar a informação associada aos produtos de cartão ou efetuar outros tipos adeq2uados de transações financeiras quer com ou sem a utilização dos produtos de cartão associados.
Será apreciado por aqueles de habilidade ordinária na tecnologia que a presente invenção pode ser incorporada de várias formas específicas sem desviar do espírito ou características essenciais desta. As versões reveladas presentemente são consideradas em todos os respeitos como sendo ilustrativas e não restritivas. 0 escopo da invenção é indicado pelas reivindicações apensas, e não pela descrição anterior, e todas as mudanças que vierem dentro do significado e alcance da equivalência deles pretende-se que sejam abrangidas.
Todas as patentes e aplicações dos Estados Unidos, patentes do estrangeiro, e publicações discutidas acima são aqui incorporadas por referência em suas inteirezas.
Claims (35)
1. Sistema de gerenciamento da informação, caracterizado pelo fato de compreender: um servidor de computador, em que o servidor de computador inclui um módulo de interface; e uma pluralidade de processadores de cartão em comunicação com o servidor de computador através do módulo de interface, em que o servidor de computador é configurado para fazer interface com cada um da pluralidade de processadores de cartão através do módulo de interface, e em que o servidor de computador é configurado para escolher um da pluralidade de processadores de cartão de acordo com um identificador singular associado a um produto de cartão para processar iriformação associada ao produto de cartão.
2. Sistema de gerenciamento da informação, de acordo com a reivindicação 1, caracterizado pelo fato de o módulo de interface ser configurado para transformar mensagens para comunicação a um processador de cartão respectivo em um formato utilizado pelo processador de cartão respectivo.
3. Sistema de gerenciamento da informação, de acordo com a reivindicação 1, caracterizado pelo fato de compreender: uma base de dados em comunicação com o servidor de computador, em que o módulo de base de dados é configurado para armazenar informação associada a produtos de cartão.
4. Sistema de gerenciamento da informação, de acordo com a reivindicação 3, caracterizado pelo fato de compreender: um módulo de gerenciamento em comunicação com a base de dados, em que o módulo de gerenciamento é configurado para gerenciar o sistema de gerenciamento da informação.
5. Sistema de gerenciamento da informação, de acordo com a reivindicação 1, caracterizado pelo fato de cada produto de cartão compreender um número de cartão, em que o número de cartão compreende uma primeira parte de dígitos e uma segunda parte de dígitos, em que a primeira parte de dígitos compreende um número de identificação de banco (BIN), em que os processadores de cartão são configurados para associar BINs aos produtos de cartão, e em que o servidor de computador é configurado para alocar números de cartão a substancialmente toda a segunda parte de dígitos para cada BIN.
6. Sistema de gerenciamento de produto de cartão, caracterizado pelo fato de compreender: um módulo de portal de agente; e uma pluralidade de processadores de cartão em comunicação com o módulo de portal de agente, em que o módulo de portal de agente é configurado para fazer interface com cada um da pluralidade de processadores de cartão, e em que o módulo de portal de agente é configurado para escolher um da pluralidade de processadores de cartão de acordo com um identificador singular associado a um produto de cartão para processar informação associada ao produto de cartão.
7. Sistema de gerenciamento de produto de cartão, de acordo com a reivindicação 6, caracterizado pelo fato de o módulo de portal de agente compreender: um módulo servidor de aplicação do cliente.
8. Sistema de gerenciamento de produto de cartão, de acordo com a reivindicação 7, caracterizado pelo fato de o módulo servidor de aplicação do cliente ser configurado para transformar mensagens para comunicação a um processador de cartão respectivo em um formato utilizado pelo processador de cartão respectivo.
9. Sistema de gerenciamento de produto de cartão, de acordo com a reivindicação 8, caracterizado pelo fato de mensagens aos processadores de cartão incluem uma consulta que compreende o endereço de rede de computador de um arquivo, e em que a criptografação do endereço de rede de computador é apensada ao final da consulta.
10. Sistema de gerenciamento de produto de cartão, de acordo com a reivindicação 9, caracterizado pelo fato de o módulo servidor de aplicação do cliente ser configurado para detectar a adulteração do endereço de rede de computador ao comparar o èndereço de rede de computador e uma descriptografação do endereço de rede de computador criptografado.
11. Sistema de gerenciamento de produto de cartão, de acordo com a reivindicação 9, caracterizado pelo fato de o módulo servidor de aplicação do cliente ser configurado para detectar a adulteração do endereço de rede do computador ao comparar o endereço de rede de computador criptografado com a re-criptografação do endereço de rede de computador.
12. Sistema de gerenciamento de produto de cartão, de acordo com a reivindicação 11, caracterizado pelo fato de a criptografação do endereço de rede de computador compreender uma função hash criptográfica.
13. Sistema de gerenciamento de produto de cartão, de acordo com a reivindicação 7, caracterizado pelo fato de o módulo servidor de aplicação dò cliente ser configurado 10 para receber informação associada a produtos de cartão de cada um dos processadores de cartão, e em que a informação de cada um dos processadores de cartão é normalizada para transformar a informação em um formato uniforme utilizado pelo módulo de portal de agente.
14. Sistema de gerenciamento de produto de cartão, de acordo com a reivindicação 13, caracterizado pelo fato de a informação de cada processador de cartão compreender uma pluralidade dè relatórios.
15. Sistema de gerenciamento de produto de cartão, de acordo com a reivindicação 14, caracterizado pelo fato de a pluralidade de relatórios compreender pelo menos um de um relatório geral, um relatório lançado, e um relatório de autorização.
16. Sistema de gerenciamento de produto de cartão, de acordo com a reivindicação 13, caracterizado pelo fato de a informação transformada ser validada para assegurar a precisão da informação.
17. Sistema de gerenciamento de produto de cartão, de acordo com a reivindicação 7, caracterizado pelo fato de o módulo servidor de aplicação do cliente ser configurado para gerar relatórios para informação associada a produtos de cartão.
18. Sistema de gerenciamento de produto de cartão, de acordo com a reivindicação 17, caracterizado pelo fato de cada relatório ser preenchido com informação de acordo com a identificação do usuário.
19. Sistema de gerenciamento de produto de cartão, de acordo com a reivindicação 7, caracterizado pelo fato de compreendér: um módulo de base de dados em comunicação com o módulo servidor de aplicação do cliente, em que o módulo de base de dados é configurado para armazenar informação associada a produtos de cartão.
20. Sistema de gerenciamento de produto de cartão, de acordo com a reivindicação 19, caracterizado pelo fato de compreender: um módulo servidor de aplicação de gerenciamento em comunicação com o módulo de base de dados, em que o módulo servidor de aplicação de gerenciamento é configurado para gerenciar o sistema de gerenciaménto de produto de cartão.
21. Sistema de gerenciamento de produto de cartão, de acordo com a reivindicação 19, caracterizado pelo fato de o módulo de portal de agente ser configurado para permitir o acesso por usuários para gerenciar a informação associada aos produtos de cartão.
22. Sistema de gerenciamento de produto de cartão, de acordo com a reivindicação 19, caracterizado pelo fato de o módulo de portal de agente compreender: um módulo de interface gráfico de usuário, em que o módulo de interface gráfico de usuário é configurado para exibir uma interface gráfica de usuário através da qual os usuários interagem com o sistema de gerenciamento de produto de cartão.
23. Sistema de gerenciamento de produto de cartão, de acordo com a reivindicação 22, caracterizado pelo fato de ao usuário ser concedido o acesso ao sistema de gerenciamento de produto de cartão através da interface gráfica do usuário utilizando uma senha e um endereço de rede de computador associado do usuário.
24. Sistema de gerenciamento de produto de cartão, de acordo com a reivindicação 22, caracterizado pelo fato de produtos serem apresentados ao usuário através da interface gráfica do usuário de acordo com pelo menos um de identificação do usuário e associação com uma instituição financeira.
25. Sistema de gerenciamento de produto de cartão, de acordo com a reivindicação 22, caracterizado pelo fato de o tema da interface gráfica do usuário ser associado a cada processador de cartão, e em que cada processador de cartão é apresentado com o tema associado aõ processador de cartão quarido da interação com o sistema de gerenciamento de produto de cartão através da interface gráfica do usuário.
26. Sistema de gerenciamento de produto de cartão, de acordo com a reivindicação 6, caracterizado pelo fato de os processadores de cartão serem configurados para associar números de identificação de banco (BINs) correspondentes aos produtos de cartão, e em que o módulo de portal de agente é configurado para alocar números de cartão correspondentes a cada BIM para os produtos de cartão.
27. Sistema de gerenciamento de produto de cartão, de acordo com a reivindicação 6, caracterizado pelo fato de o módulo de portal de agente ser configurado para exibir um resumo de números de cartão para cada BIN através de uma interface gráfica do usuário.
28. Sistema de gerenciamento de produto de cartão, de acordo com a reivindicação 6, caracterizado pelo fato de o identificador singular compreender um número de identificação de banco (BIN).
29. Sistema de gerenciamento de produto de cartão, de acordo com a reivindicação 6, caracterizado pelo fato de cada produto de cartão compreender um número de produto de cartão, em que o número de produto de cartão compreende uma primeira parte de digitos e uma segunda parte de dígitos, em que a primeira parte de dígitos compreende um número de identificação de banco (BIN), em que os processadores de cartão sãó configurados para associar BINs aos produtos de cartão, e em que o módulo de portal de agente é configurado para alocar números de cartão a substancialmente toda a segunda parte de dígitos para cada BIN.
30. Sistema de gerenciamento de produto de cartão, de acordo com a reivindicação 6, caracterizado pelo fato de o produto de cartão compreender um cartão de presente.
31. Sistema de gerenciamento de produto de cartão, de acordo com a reivindicação 6, caracterizado pelo fato de o produto de cartão compreender pelo menos um de um cartão de débito, um cartão de conta de economias de saúde ( HSA) , um cartão de conta de gastos flexíveis (FSA), e um cartão de folha de pagamento recarregável.
32. Sistema para processar produtos de cartão, caracterizado pelo fato de compreender: uma pluralidade de produtos de cartão, em que cada produto de cartão compreende um número de produto de cartão, em que o número de produto de cartão compreende uma primeira parte de dígitos e uma segunda parte de dígitos, em que a primeira parte de dígitos compreende um número de identificação de banco (BIN), e em que cada BIN é designado a um processador de cartão; e um não processador, em que o hão processador é configurado para gerenciar a informação associada a uma pluralidade de produtos de cartão, e em que o não processador é configurado para designar valores a substancialmente toda a segunda parte de dígitos de cada produto de cartão.
33. Método de gerenciar a informação de produto de cartão, caracterizado pelo fato de compreender as etapas de: a) fazer interface com cada um da pluralidade de processadores de cartão; e b) selecionar um da pluralidade de processadores de cartão de acordo com um identificador singular associado a um produto de cartão para processar a informação associada ao produto de cartão.
34. Método, de acordo com a reivindicação 33, caracterizado pelo fato de os processadores de cartão serem configurados para associar números de identificação de banco (BINs) correspondentes aos produtos de cartão, e em que o método compreende a etapa de: c) alocar números de cartão correspondentes a cada BIN para os produtos de cartão.
35. Método, de acordo com a reivindicação 33, caracterizado pelo fato de cada produto de cartão compreender um número de produto de cartão, em que o número de produto de cartão compreende uma primeira parte de dígitos e uma segunda parte de dígitos, em que a primeira parte de dígitos compreende um número de identificação de banco (BIN), em que os processadores de cartão são configurados para associar BINs aos produtos de cartão, e em que o método compreende a etapa de: c) alocar números de cartão a substancialmente toda a segunda parte de dígitos para cada BIN.
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| PCT/US2006/011148 WO2007123513A1 (en) | 2006-03-24 | 2006-03-24 | Information management system and method |
Publications (1)
| Publication Number | Publication Date |
|---|---|
| BRPI0621426A2 true BRPI0621426A2 (pt) | 2011-12-13 |
Family
ID=38625303
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| BRPI0621426-6A BRPI0621426A2 (pt) | 2006-03-24 | 2006-03-24 | sistema e método de gerenciamento de informação |
Country Status (8)
| Country | Link |
|---|---|
| US (2) | US20090078757A1 (pt) |
| EP (1) | EP2005628A1 (pt) |
| CN (1) | CN101461163A (pt) |
| AU (1) | AU2006342506A1 (pt) |
| BR (1) | BRPI0621426A2 (pt) |
| CA (1) | CA2647250A1 (pt) |
| MX (1) | MX2008012200A (pt) |
| WO (1) | WO2007123513A1 (pt) |
Families Citing this family (40)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US7987512B2 (en) * | 2006-05-19 | 2011-07-26 | Microsoft Corporation | BIOS based secure execution environment |
| US20080005560A1 (en) * | 2006-06-29 | 2008-01-03 | Microsoft Corporation | Independent Computation Environment and Provisioning of Computing Device Functionality |
| US20080046380A1 (en) * | 2006-08-16 | 2008-02-21 | Kurt Wise | System and apparatus for transactions using certificates |
| US20080243640A1 (en) * | 2007-03-27 | 2008-10-02 | The Friendship Gift Bag Company, Llc | Interactive product and method of fabricating the same |
| US8546816B2 (en) * | 2007-04-30 | 2013-10-01 | Novaled Ag | Light-emitting component and method for the production thereof |
| US20080313034A1 (en) * | 2007-06-12 | 2008-12-18 | Kurt Wise | Credit item tracking system |
| US8065123B2 (en) | 2007-09-10 | 2011-11-22 | Autodesk, Inc. | Systems and methods for performing quantity takeoff computations from computer aided design drawings |
| US8055557B2 (en) | 2007-12-21 | 2011-11-08 | Metabank | Transfer account systems, computer program products, and associated computer-implemented methods |
| US8108279B2 (en) * | 2007-12-21 | 2012-01-31 | Metabank | Computer-implemented methods, program product, and system to enhance banking terms over time |
| US8108272B2 (en) | 2007-12-21 | 2012-01-31 | Metabank | Transfer account systems, computer program products, and computer-implemented methods to prioritize payments from preselected bank account |
| US20090228391A1 (en) * | 2008-02-20 | 2009-09-10 | Trent Sorbe | Methods To Advance Loan Proceeds On Prepaid Cards, Associated Systems And Computer Program Products |
| US10515405B2 (en) | 2008-03-03 | 2019-12-24 | Metabank | Person-to-person lending program product, system, and associated computer-implemented methods |
| US20090240627A1 (en) * | 2008-03-21 | 2009-09-24 | Hector Javier Rodriguez | Payment processing system trusted agent identification |
| US8150764B2 (en) * | 2008-04-04 | 2012-04-03 | Metabank | System, program product, and method to authorize draw for retailer optimization |
| WO2009124264A1 (en) * | 2008-04-04 | 2009-10-08 | Metabank | System, program product, and method for debit card and checking account autodraw |
| US11227331B2 (en) | 2008-05-14 | 2022-01-18 | Metabank | System, program product, and computer-implemented method for loading a loan on an existing pre-paid card |
| US8244608B2 (en) * | 2008-07-28 | 2012-08-14 | Autodesk, Inc. | Takeoff list palette for guiding semi-automatic quantity takeoff from computer aided design drawings |
| WO2010028266A1 (en) | 2008-09-04 | 2010-03-11 | Metabank | System, program product and methods for retail activation and reload associated with partial authorization transactions |
| US8666854B2 (en) * | 2008-09-05 | 2014-03-04 | Oracle International Corporation | Providing a unified view of contract revenue and invoice details |
| US9569528B2 (en) * | 2008-10-03 | 2017-02-14 | Ab Initio Technology Llc | Detection of confidential information |
| US9213965B1 (en) | 2008-11-26 | 2015-12-15 | Metabank | Machine, methods, and program product for electronic inventory tracking |
| US8286863B1 (en) | 2009-02-04 | 2012-10-16 | Metabank | System and computer program product to issue a retail prepaid card including a user-designed external face using a chit and related computer implemented methods |
| US20110060684A1 (en) * | 2009-03-25 | 2011-03-10 | Jucht Scott J | Machine, program product, and computer-implemented methods for confirming a mobile banking request |
| US20110082737A1 (en) | 2009-09-28 | 2011-04-07 | Crowe Andrew B | Computer-implemented methods, computer program products, and systems for management and control of a loyalty rewards network |
| CN103608806A (zh) * | 2010-11-15 | 2014-02-26 | E半球股份有限公司 | 使用基于网络的门户对产品和服务的性能报告 |
| US20120130899A1 (en) * | 2010-11-18 | 2012-05-24 | Mcmonagle Patrick Shawn | Check21 processing of non-dda transactions |
| US20140114815A1 (en) * | 2011-05-25 | 2014-04-24 | Jpmorgan Chase Bank, N.A. | System And Method For Managing And Using A Third Party Subsidy Account |
| US9135311B2 (en) * | 2012-03-20 | 2015-09-15 | Tagboard, Inc. | Gathering and contributing content across diverse sources |
| US8572083B1 (en) * | 2012-05-30 | 2013-10-29 | Ncino, Llc | Financial-service structured content manager |
| US10282461B2 (en) | 2015-07-01 | 2019-05-07 | Ncino, Inc. | Structure-based entity analysis |
| US10192262B2 (en) | 2012-05-30 | 2019-01-29 | Ncino, Inc. | System for periodically updating backings for resource requests |
| US10013237B2 (en) * | 2012-05-30 | 2018-07-03 | Ncino, Inc. | Automated approval |
| US8935799B1 (en) * | 2012-08-29 | 2015-01-13 | Sprint Communications Company L.P. | Report generation system and method |
| WO2014066794A1 (en) * | 2012-10-25 | 2014-05-01 | Global Edge Llc | Purchase card management |
| US9858571B2 (en) * | 2013-01-02 | 2018-01-02 | Mastercard International Incorporated | Methods and systems for mitigating fraud losses during a payment card transaction |
| US8931093B2 (en) * | 2013-03-15 | 2015-01-06 | Bank Of America Corporation | Malicious request attribution |
| US9251478B2 (en) * | 2013-07-29 | 2016-02-02 | Amadeus S.A.S. | Processing information queries in a distributed information processing environment |
| US20160013976A1 (en) * | 2014-07-14 | 2016-01-14 | Futurewei Technologies, Inc. | Wireless Through Link Traffic Reduction |
| US20160048913A1 (en) * | 2014-08-15 | 2016-02-18 | Mastercard International Incorporated | Systems and Methods for Assigning a Variable Length Bank Identification Number |
| US10776766B2 (en) | 2016-01-27 | 2020-09-15 | Visa International Service Association | Accepting issuer credentials at checkout |
Family Cites Families (29)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US5555496A (en) * | 1994-05-06 | 1996-09-10 | Mary T. Tackbary | Method and apparatus for communicating with a card distribution center for management, selection, and delivery of social expression cards |
| US6328217B1 (en) * | 1997-05-15 | 2001-12-11 | Mondex International Limited | Integrated circuit card with application history list |
| US5984180A (en) * | 1997-10-06 | 1999-11-16 | Albrecht; Jerry L. | Method and system for gift credit card |
| CA2311548A1 (en) * | 1997-12-02 | 1999-06-10 | Cash Technologies, Inc. | Multi-transactional network architecture |
| US6636833B1 (en) * | 1998-03-25 | 2003-10-21 | Obis Patents Ltd. | Credit card system and method |
| US6175823B1 (en) * | 1998-09-15 | 2001-01-16 | Amazon.Com, Inc. | Electronic gift certificate system |
| US6597746B1 (en) * | 1999-02-18 | 2003-07-22 | Globespanvirata, Inc. | System and method for peak to average power ratio reduction |
| US6675153B1 (en) * | 1999-07-06 | 2004-01-06 | Zix Corporation | Transaction authorization system |
| US7222097B2 (en) * | 2000-01-18 | 2007-05-22 | Bellosguardo Philippe A | Anonymous credit card |
| US20020032605A1 (en) * | 2000-06-05 | 2002-03-14 | Jonas Lee | System and method for providing a selectable gift certificate |
| US20020013766A1 (en) * | 2000-07-25 | 2002-01-31 | Chiharu Kumaki | Commercial settlement system with prepaid type credit card |
| US7130817B2 (en) * | 2000-12-15 | 2006-10-31 | First Data Corporation | Electronic gift linking |
| US20020100797A1 (en) * | 2001-02-01 | 2002-08-01 | Hollingsworth James R. | Gift card envelope |
| US7401049B2 (en) * | 2001-05-29 | 2008-07-15 | American Express Travel Related Services Company, Inc. | System and method for a prepaid card issued by a foreign financial institution |
| US7249092B2 (en) * | 2001-05-29 | 2007-07-24 | American Express Travel Related Services Company, Inc. | System and method for facilitating a subsidiary card account with controlled spending capability |
| US7899742B2 (en) * | 2001-05-29 | 2011-03-01 | American Express Travel Related Services Company, Inc. | System and method for facilitating a subsidiary card account |
| US7865432B2 (en) * | 2002-02-15 | 2011-01-04 | Coinstar, Inc. | Methods and systems for exchanging and/or transferring various forms of value |
| KR100445868B1 (ko) * | 2002-04-01 | 2004-08-30 | 성미선 | 신용카드 거래를 이용하여 신용카드 상품권을 운용하는시스템 및 방법 |
| US7014104B2 (en) * | 2002-05-31 | 2006-03-21 | First Data Corporation | Gift matching method |
| AU2003243523B2 (en) * | 2002-06-12 | 2008-04-10 | Cardinalcommerce Corporation | Universal merchant platform for payment authentication |
| US20040007618A1 (en) * | 2002-07-10 | 2004-01-15 | Scott Oram | Prepaid credit card method |
| US8015060B2 (en) * | 2002-09-13 | 2011-09-06 | Visa Usa, Inc. | Method and system for managing limited use coupon and coupon prioritization |
| US8374960B2 (en) * | 2002-10-29 | 2013-02-12 | Verizon Business Global Llc | Prepaid transaction tracking |
| US20050097039A1 (en) * | 2003-11-05 | 2005-05-05 | Laszlo Kulcsar | Multiple credit card management system |
| US7039611B2 (en) * | 2003-11-06 | 2006-05-02 | Visa U.S.A., Inc. | Managing attempts to initiate authentication of electronic commerce card transactions |
| US20050145691A1 (en) * | 2004-01-05 | 2005-07-07 | Dillard Regina F. | Reprove prepaid credit card |
| US7494048B2 (en) * | 2004-04-08 | 2009-02-24 | International Business Machines Corporation | System and method for brand name gift card exchange |
| US7082891B2 (en) * | 2004-11-01 | 2006-08-01 | Watson Travis L | Food product flavoring apparatus |
| US7506804B2 (en) * | 2005-05-27 | 2009-03-24 | U.S. Bancorp Licensing, Inc. | System and method for an integrated payment and reward card |
-
2006
- 2006-03-24 BR BRPI0621426-6A patent/BRPI0621426A2/pt not_active IP Right Cessation
- 2006-03-24 WO PCT/US2006/011148 patent/WO2007123513A1/en active Application Filing
- 2006-03-24 MX MX2008012200A patent/MX2008012200A/es not_active Application Discontinuation
- 2006-03-24 CA CA002647250A patent/CA2647250A1/en not_active Abandoned
- 2006-03-24 EP EP06739755A patent/EP2005628A1/en not_active Withdrawn
- 2006-03-24 AU AU2006342506A patent/AU2006342506A1/en not_active Abandoned
- 2006-03-24 CN CN200680054639.1A patent/CN101461163A/zh active Pending
- 2006-03-24 US US10/590,439 patent/US20090078757A1/en not_active Abandoned
-
2012
- 2012-07-23 US US13/555,485 patent/US20130161384A1/en not_active Abandoned
Also Published As
| Publication number | Publication date |
|---|---|
| CN101461163A (zh) | 2009-06-17 |
| WO2007123513A9 (en) | 2007-12-27 |
| MX2008012200A (es) | 2009-03-31 |
| EP2005628A1 (en) | 2008-12-24 |
| CA2647250A1 (en) | 2008-11-01 |
| US20130161384A1 (en) | 2013-06-27 |
| WO2007123513A1 (en) | 2007-11-01 |
| AU2006342506A1 (en) | 2007-11-01 |
| US20090078757A1 (en) | 2009-03-26 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| BRPI0621426A2 (pt) | sistema e método de gerenciamento de informação | |
| TW381241B (en) | Electronic wallet based on distributed network | |
| US8121941B2 (en) | System and method for automatic reconciliation of transaction account spend | |
| US8412639B2 (en) | System and method for facilitating a secured financial transaction using an alternate shipping address | |
| WO2012040820A1 (en) | System and method for tracking transaction records in a network | |
| US20130282480A1 (en) | System and method for collaborative affinity marketing | |
| US20100286993A1 (en) | Method and system for comunication, advertisement, commerce, marketplace, customer relationship management, content management, internet accounting and verification of information pertaining to legal marijuana over a network | |
| US20080306877A1 (en) | Secure Internet E-Commerce | |
| US20100057621A1 (en) | Payment processing system secure healthcare data trafficking | |
| US12118519B2 (en) | Intelligent payment routing and payment generation | |
| US11068898B2 (en) | Virtual payment card fraud detection | |
| US11599885B1 (en) | System and method for virtual payment card fraud detection | |
| WO2016189311A1 (en) | Computer system for implementing a transaction payment | |
| AU2024203478A1 (en) | Systems and methods for payment transaction coding and management | |
| US20200202353A9 (en) | Electronic Wallet Enterprise System Comprising Guaranteed Electronic Payment Transactions | |
| US11004063B1 (en) | Intermediary payment method using interchange differential | |
| KR20020035244A (ko) | 국제전자무역거래 처리방법 및 국제전자무역거래 처리시스템 | |
| KR20000037129A (ko) | 인터넷 쇼핑몰을 통한 상품, 용역 구매시 전자 결제 보안시스템 및 그 방법 |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| B08F | Application dismissed because of non-payment of annual fees [chapter 8.6 patent gazette] |
Free format text: REFERENTE AS 3A E 6A ANUIDADES. |
|
| B08K | Patent lapsed as no evidence of payment of the annual fee has been furnished to inpi [chapter 8.11 patent gazette] |
Free format text: REFERENTE AO DESPACHO 8.6 PUBLICADO NA RPI 2161 DE 05/06/2012. |